みんなパスキーに期待しすぎている。MIXI伊東氏に聞く「認証のゴール地点」の考え方

パスワードレス認証の代名詞として普及が進むパスキー。2022年の登場から数年、世間的な認知度も向上し、オンラインサービスのユーザー認証の仕様を検討するうえでは避けて通れない存在となりつつあります。

株式会社MIXIの伊東 諒さんは、日本でパスキーの推進を積極的に行う一人です。MIXIの認証基盤におけるパスキーの導入も伊東さんの専門性を活かしながら進められました。

パスキーはパスワードの課題を根本から解決することを目的としており、「パスワードに置き換わる認証方式」と呼ばれることも多い一方で、導入を検討する議論においては“誤解”が生まれているのではないかと伊東さんは指摘します。

現実的なパスキーとの付き合い方、「認証のゴール地点」の考え方を、MIXIにおけるパスキー導入の経緯と共に聞きました。

• keyboard_arrow_down たったひとつの「パスキーの革新性」
• keyboard_arrow_down 「パスキーを実装するなら完璧にやるべき」というプレッシャー
• keyboard_arrow_down MIXIにおけるパスキー対応
• keyboard_arrow_down 「認証のゴール地点」はどこにあるのか

――2024年は多くのサービスが続々とパスキーに対応し、世間的にも広く知られる年になったと思います。そもそもパスキーはどのような仕組みなのでしょうか。

伊東：公開鍵暗号方式を用いたパスワードレスの認証方式です。ユーザー側のデバイスには秘密鍵が、サービス側のサーバーには公開鍵が保管され（※1）、「秘密鍵で生成されたデジタル署名を公開鍵で検証する」という仕組みで認証が行われます。

MIXIのユーザー向けFAQでは「パスキーとは、生体認証 (指紋・顔) などを利用してウェブサイトやアプリにログインできる簡単で安全な認証方法」と説明しています。

※1 より正確には、初回登録時にユーザー側のデバイスが秘密鍵と公開鍵のペアを生成し、サービス側のサーバーに公開鍵が共有される。

――それでは、ずばりサービス提供者がパスキーを導入するメリットとは何でしょうか。

伊東：まず意識しておきたいのは、パスキーの新規性である「フィッシング攻撃への強固な耐性」です。

このフィッシング耐性をどれだけ重要と捉えるかは、各社の事業内容や扱っているデータの機密性に左右されると思います。

パスキーがフィッシングに強いといわれる理由は、認証情報を「人間に生成させない」「人間に記憶させない」「人間に入力させない」ことで、ヒューマンエラーが発生するリスクを限りなく0に近づけているからです。

パスキー認証に用いる秘密鍵は、ユーザーのデバイス内のパスワードマネージャーで管理されます。秘密鍵はユーザーではなくパスワードマネージャーが「生成」「管理」するものであり、ユーザーが「記憶」する必要はありません。

また、パスキー認証では、ブラウザがアクセス先のオリジン（プロトコル・ホスト名・ポート番号の組み合わせ）を照合し、それがパスキー認証を要求しているWebサイトから指定されたものと一致した場合のみ、認証情報の照合が行われます。このパスワードの「入力」にあたるプロセスも、システムにより自動的に行われるわけです。

システムが人間に代わってフィッシングサイトを検知してくれることにより、万が一騙されてしまっても正規の認証フロー以外では認証情報を受け渡すことができない。このヒューマンエラーを防ぐフィッシング耐性こそが、パスキーのセキュリティのコアといえる部分です。

――ユーザーのパスワードを自サービスで管理する必要がないことは、サービス提供者にとってのメリットといえませんか？

伊東：たしかにおっしゃる通りです。パスワードはたとえハッシュ化や暗号化をしていても、盗取された後で解読される可能性があり、サービス側の管理も重要です。さらに、流出したパスワードをユーザーが様々なサービスで使い回していた場合、芋づる式に様々なサービスに不正ログインできてしまう可能性もあるため、影響は自サービスに留まりません。

それに対して、パスキー認証でサービス側が保管する公開鍵は、それだけではパスキー認証に必要なデジタル署名を生成できないため、公開鍵だけが盗まれたとしても悪用はされにくい。

ただし、パスワードを保管するリスクは「パスキーでしか回避できない」というわけではありません。パスキーが登場する以前から、パスワードレスな認証方式は利用されてきました。

たとえば、SMSで送信したワンタイムパスワードを認証情報とする方法があります。SMS認証は「パスワード認証＋SMS認証」という二段階認証の一要素として使われることが多いのですが、このうち大本のパスワード認証の方を取り除いてしまうイメージです。

もしも電話番号が流出したとしても、その電話番号に紐づくSIMカードがユーザーの手元にある限り、第三者が不正にログインすることは難しい。もちろんSMS認証にもSIMスワッピング（※2）のような脆弱性は存在するのですが、パスワードと比較すれば不正アクセスにつながるリスクは幾分低いといえます。

「パスキーだからこそ解決できる問題」に焦点を当てるならば、やはりフィッシング耐性がポイントになるのではないでしょうか。

※2 SIMスワッピング：攻撃者が携帯電話会社を騙して、標的の電話番号を別のSIMカードに転送してしまう攻撃のこと。

――なるほど。ちなみにワンタイムパスワードではフィッシングを防げないのでしょうか。

伊東：残念ながら、ワンタイムパスワードは「リアルタイムフィッシング」や「中継型フィッシング」と呼ばれる方法で突破されてしまいます。入力されたログイン情報をリアルタイムで本物のサイトへ転送し、ワンタイムパスワードまで盗み取る手口ですね。

偽メールや偽サイトは非常に巧妙化しており、ユーザーが騙される可能性を0にはできません。だとすれば、ユーザーにパスワードやワンタイムパスワードなどのクレデンシャルを生成・記憶・入力させている限り、ヒューマンエラーによるフィッシング被害を防ぎきることは難しい。

こうした考え方に基づき、公開鍵暗号方式を用いた「FIDO認証」（※3）というものが考案され、そのFIDO認証をユーザーフレンドリーにする形でパスキー認証が誕生した、という経緯があります。

パスキーが普及すれば、フィッシング攻撃との戦いの歴史にひとつのピリオドが打たれるかもしれない。その革新性こそが、私がパスキーに期待を寄せている理由なのです。

※3 FIDO認証：FIDOアライアンスが策定した認証規格。外付けのセキュリティキーやPC・スマートフォンのセキュア領域で秘密鍵を生成・保存するため、セキュリティキーを紛失するリスクや、デバイス間の互換性がない不便さがあった。その後、パスワードに対する「パスキー」という名前が付けられるとともにパスワードマネージャーによる秘密鍵の管理を許容したことで、クラウド同期による複数デバイスでの利用が可能となり、より実用的な認証方式として注目されるようになった。

――だからパスキーは「パスワードに代わる認証方式」といわれるのですね。

伊東：その通りです。ただし、パスキーが本当に「パスワードに代わる認証方式」になるまで、すなわち「パスワードが使われなくなり、パスキーだけが残る」状態が実現するまでには、ユーザーへの普及の観点から時間がかかると考えています。

現在は多くのユーザーが人力でパスワードを生成・記憶・入力している状態です。

しかし、先に述べたように、パスキーの認証プロセスはブラウザとパスワードマネージャーといったシステムが仲介して行われ、認証情報の生成・記憶・入力というプロセスが存在しません。ユーザーからすれば、慣れ親しんだパスワード認証と体験が大きく変わるため、受け入れ難い面はあるでしょう。

開発者からすれば「やらなくてよくなる」という認識ですが、それがユーザーに伝わるとは限りません。ユーザーは、パスキーという未知の存在を本当に信頼してよいのかどうかも分からない状態で、自分自身で認証情報を管理しているという“安心感”を捨てなければならない。抵抗を覚えるユーザーの方が多いでしょう。このようなギャップは、変化を受け入れる際のハードルとも捉えられます。

一方、開発者にとってもパスキー対応のハードルを上げており、プレッシャーを感じる原因になっていると考えられます。

――パスキーに対するプレッシャーですか？

伊東：はい。より正確にいえば「パスキーを実装するならパスワードは廃止すべき。でなければパスキーを実装する意味がない」というプレッシャーです。

先述の通り、パスキーの特徴であるフィッシング耐性の恩恵を得るためには、パスキー以外の認証方法を廃止し、全てのユーザーにパスキーを利用してもらうことが理想です。たとえパスキーが導入されても、従来のパスワード認証が残っていれば、ユーザーは依然としてフィッシングの標的となりますし、サービス側でパスワードを管理するリスクも残り続けますからね。

しかし一方で、パスワード認証を廃止してパスキー認証だけを採用する・特定機能を利用するためにパスキー認証を強制するアプローチは、パスキー非対応環境やクロスデバイス、クロスプラットフォームの課題によりユーザーからネガティブな反応が見られているのが現状であり、パスキーと共にサービスが嫌われる事態につながってしまっています。たとえばフィッシングの被害を抑えるためだとしても「ユーザーから嫌われてまでパスキーを実装する意味はあるのか？」と考え、理想と現実の狭間で葛藤する開発者がいても当然でしょう。

――なるほど……。それでは、伊東さんはどのように考えているのでしょうか。

伊東：なんというか、パスキーは漠然とした期待を背負わされすぎているようにも感じています。そもそも、どんな認証方式にもメリットとデメリット、リスクはあり、認証方式をパスキーのみにしても完璧なセキュリティが実現するわけではありません。あくまで解決すべき課題であるフィッシングの課題をクリアしたに過ぎないのです。

極論ですが、認証もまたサービス全体のUXを構成する要素のひとつでしかないんです。認証の目的は「安心してサービスを使える」という観点からユーザーの体験を向上させること。本来そのサービスで提供したい価値を棄損してまで、ユーザーが使いにくいと感じる認証方式を採用すべきとは思いません。

安全性と利便性はトレードオフであるとよくいわれています。私としてはその天秤を破壊する「安全かつ便利」な方法がパスキーだと考えているのですが、万人がそう感じるとは限りません。特にパスキーが普及していない現状では、パスキーの使用を強制されることで「利便性が損なわれた」と捉えるユーザーが多いでしょう。

現時点でパスキーを実装しているサービスの多くは、パスワードのような既存の認証方式を残しつつ、パスキーをオプションとして提供するスタイルを採用しています。まずは「ユーザーにとって便利な選択肢を増やす」という考え方ですね。このやり方であれば、自ら進んでパスキーを利用してくれるユーザーのUXは向上し、パスキーを使いたくないユーザーから不満が出ることも少ないはずです。

――他にはどんなプラクティスがありますか？

伊東：ユーザーがパスキーを紛失した際のリカバリー方法は、しばしば議論が巻き起こるテーマですね。結論からいえば、これはパスキー導入の目的によって最適解が変わる部分だと思います。

先述のように「ユーザーにとって便利な選択肢を増やす」という考え方でゆるやかにパスキーを導入するのであれば、既存の認証方式で採用しているリカバリー方法をそのまま踏襲する形でよいと考えています。ユーザー自身がメールやマイページでパスワードをリセット可能なサービスであれば、パスキーも同様にセルフリカバリーできるようにしてしまうわけです。

一方で、「今すぐセキュリティを向上させたい」という強い目的意識を持ってパスキーの導入に臨むのであれば、リカバリー方法も合わせて見直す必要はあるかもしれません。

当然ながら「仮に電話番号でパスキーをリセットできるなら、それってSMS認証とセキュリティレベルの最低値は変わらないじゃないか」という考え方もできるわけで。金融やヘルスケアといった機密性の高い情報を扱うサービスのように、身分証で本人確認を行ってからパスキーをリセットするといったリカバリー方法の強度は相応に求められるでしょう。

ただ、身分証を用いた本人確認はユーザーの負担はもちろん、偽装された身分証の利用を防ぐ必要があるといったサービスの負担も大きい仕組みです。この点については、マイナンバーカードそのものや、スマートフォンに搭載されたものを利用する技術が進んでおり、それにより安全性と利便性の向上が期待できます。パスキーの普及と平行して発展を期待したい分野になりますね。

――サービスが提供したいUXの本質と照らし合わせながら、今は現実的な範囲で実装を進めていけばよいのですね。

伊東：幸いなことに、最近はパスキーに関するライブラリやツールが充実し、必ずしもゼロから仕組みを学ぶ必要はなくなりつつあります。RubyやJavaScriptなどのカンファレンスでも、パスキーに関する発表を見る機会が増えました。GoogleもUI／UXのガイドラインを公開し、ようやく実践的なプラクティスがまとまってきた状態です。

総じて、サービスの価値を高めることを念頭に置きながら、そのための手段のひとつとしてパスキーの実装を検討するような余裕が生まれてきたように思います。

――実際にMIXIでパスキーを導入してきた経験についても聞かせてください。MIXIで最初にパスキー認証が実装されたのは2023年9月。導入先はキャッシュレス決済サービスの「MIXI M」でした。具体的にどのような検討を経て実装に至ったのでしょうか。

伊東：そもそもMIXI Mとは、アプリ上でプリペイドカードを発行し、Visa/JCB加盟店でのショッピングに利用できるサービスです。

MIXI Mでは、「6gram」という名称だった2019年のリリース当初からパスワード認証を実装せず、SMS認証のみでログインするフルパスワードレスを採用していました。

これは、パスワード認証における不正ログインのリスクと運用コストを回避する目的です。決済サービスは特に狙われやすいドメインですから、最初からパスワード認証を実装せず、パスワードを不正に抜き取られるリスクも対策コストも丸ごとカットした方が合理的だと判断しました。

――パスワード認証の脆弱性への対策は最初から講じていたのですね。

伊東：はい。しかし、SMS認証では解決できない課題も数多く存在しました。

SMS認証の認証場面を標的としたフィッシング攻撃の手口や、SIMカードの脆弱性を突いて電話番号を乗っ取る手段が存在することは先に述べた通りです。また、SMSは遅延・不達が発生する可能性があり、ユーザーの増加に伴い通信コストも増していきます。

こうしたリスクを軽減する手段として、パスキーに白羽の矢が立ったという経緯です。

――「パスキーを実装してもユーザーが使ってくれないのではないか」という懸念はありましたか。

伊東：もちろん、ありました。MIXI Mにパスキーを導入するかどうかの議論は、パスキーが登場した初期段階から行っていたので、検討開始から実装まで1年以上かかったことになります。これだけ決断に時間を要した理由は、まさにUXへの懸念によるものです。

パスキーが登場した2022年頃は、認証画面に設置された「パスキーでログイン」ボタンをクリックしてログインするようなUIが一般的でした。つまり、パスキーとは何かを理解しているユーザーが、自らの意志でボタンを押してくれることを期待するということです。当時は今よりもさらにパスキーの知名度が低かったわけで、これでは到底使ってもらえないだろうと感じていました。

また、ユーザーがパスキーを登録済みでも、ログインを試みている環境でそのパスキーが利用可能かを判別する手段がなく、結果として「利用可能なパスキーが存在しない」というエラーが表示されてしまう問題もあります。

――それでは、何が状況を変えたのでしょうか。

伊東：ログインしようとする環境において、利用可能なパスキーを提案する機能「Passkey Autofill」が様々なブラウザでサポートされたことです。実装に踏み切るタイミングとしてはiOSとAndroidへの対応に注目していました。

Passkey Autofillは、その環境で利用可能なパスキーがあるかを判断し、パスワードマネージャーと同様のUIでパスキーの利用を提案します。従来であれば「このユーザーとパスワードの組み合わせを利用しますか？」と候補を表示させていた場面で、パスキーも含まれるようなイメージです。

ユーザーが慣れ親しんだ直感的な流れを変えることなくパスキー認証を利用可能なため、覚えなければならない新しいことを増やさないという点でユーザーのハードルを下げられます。既存のSMS認証と併用する形でPasskey Autofillへの対応を行えば、ユーザー体験を大きく損なわずに、パスキー認証という選択肢をユーザーに提供できると判断したわけです。

――先ほどの話にあった「まずはユーザーにとって便利な選択肢を増やす」という考え方ですね。社内での合意形成はすんなりと進みましたか。

伊東：ユーザーには提供しない内部ツールにFIDO認証を導入して体験してもらうなど、以前から周知活動を行っていたこともあり、開発チーム内での戸惑いは最小限で済んだと思います。

もちろん、それだけではユーザーから歓迎されるとは限りません。特に運用面でリリース後に不満が生じる可能性はできるだけ潰しておきたいと考えました。

パスキーの利用を必須としなかった背景には、パスキーに起因する問い合わせの件数をできるだけ抑え、カスタマーサポートの負担を低減させる狙いもありました。

――安全性、利便性、加えて運用コストのバランスをそのようにつくり出してきたと。今後も様々なサービスにパスキーを展開していく予定ですか。

伊東：MIXI Mという前例があったことで、昨年4月にリリースした当社サービスの共通アカウント「MIXI ID」では、より短期間でパスキーを実装できました。また、MIXI IDではパスキー未登録のユーザーがログインした際に、パスキーの登録を訴求する表示を出すなどして利用促進を行っています。

現在、MIXI IDは「パスキー」「ワンタイムパスワード（メールアドレス／SMS）」「ソーシャルログイン」に対応しています。

これはまさに、先ほどお話しした「サービスごとに認証の最適解は異なる」という考え方に基づいています。MIXI IDという認証基盤でパスキーが実装されていることで、利用するサービスは容易にパスキーを導入できます。一方で、パスキーが利用できない状況や個々のサービスを提供する環境に対して最適な認証方式を利用可能にしておくことも重要視しています。

――つまり、MIXIのサービスにパスキーを導入したいと思った際には、すぐに導入できる準備が整っていると。

伊東：その通りです。パスキーに限らず、今後新しい認証方式が生まれたら速やかにMIXI IDへ導入することで、各サービスが最適な認証方法を提供できるようにしていきたいですね。

――ここまでのお話にもあったように、現在はパスキーが一般ユーザーにまで浸透しているとはいえない状況です。あらゆるユーザーが当たり前にパスキーを利用するような未来は本当にやってくるのでしょうか。

伊東：「ユーザーがパスキーを使うことが一般的な社会」をセキュリティにおけるひとつの転換点とした場合、おっしゃる通り、そのような未来へ向かう道のりは未だ始まったばかりです。正直なところ乗り越えなければならない壁は大きいでしょう。

ユーザーからすればパスワードとパスキーの間には大きな隔たりがある。パスワード認証では当たり前にできていた「認証情報の生成・記憶・入力」というプロセスができなくなるのですから。

だとすれば、漫然と「新しい仕組みを使ってみよう！」と叫んでいるだけでは、変化を受け入れてもらうのは難しいと思うのです。

――それでは、パスキーが普及するにはどうすればよいのでしょうか。

伊東：一足飛びに「パスキーが当たり前」の世界を目指すのではなく、段階的に移行する必要があるでしょう。

その具体的な手段として、私はパスワードマネージャーの普及を推奨しています。

パスワードマネージャーであれば、パスワードという認証方式はそのままに、まずは生成・記憶・入力をユーザーが自分でやらないことに少しずつ慣れてもらえます。「できない」ではなく「システムにやってもらう」と受け入れてもらうわけですね。

今のところ、社会全体におけるパスワードマネージャーの利用率は高くなく、また利用の仕方も人によってばらつきがあります。最近はデフォルトでパスワードマネージャーが利用可能な環境が増えてきており、「手動で入力したパスワードを記憶させる」「記憶しているものが表示されたので利用する」といったユーザーは増えてきたように思います。しかし、それらのユーザーが「サービスごとに異なるパスワードを生成する」ところまでしっかり利用しているとは限りません。

したがって、目下の課題は「パスワードマネージャーの利用率を大きく底上げすること」「パスワードマネージャーに生成・記憶・入力を全て委ねる使い方を浸透させること」の2点だと考えます。

これらが達成され、ユーザーがパスワードマネージャーを信頼している状態になれば、パスワードマネージャーと同様のUIで動くパスキーのことも自然と信頼してくれるはず。パスキーを信頼できれば、パスワード認証を使えるサービスであっても、ユーザー自ら行う生成・記憶・入力のプロセスを完全に手放し、パスキーを使うことも受け入れられるでしょう。

このようなステップを踏んで、段階的にユーザーのハードルを壊していくことが、「ユーザーがパスキーを使うことが一般的な社会」を実現するための道筋ではないでしょうか。

――その場合、ユーザーにとっての安全性も段階的に向上するのでしょうか。

伊東：そうですね。フィッシング耐性に関しては、実はパスワードマネージャーを使うことが当たり前になった時点で相当な効果があります。

パスワードマネージャーによるログインは、サイトドメインに対応した認証情報を自動で送信する形で行われますから、ドメインが異なる偽サイトには正規のサービスのパスワードが入力されません。これは、冒頭で述べたパスキーのフィッシング耐性の根幹と同様の仕組みです。

しかし、パスワードマネージャーではヒューマンエラーを防ぎきることはできません。パスワードマネージャーに保存されたパスワードは、ユーザーが参照しようと思えばできてしまう。そのため、パスワードマネージャーへの信頼が揺らぐほど巧妙な偽サイトや攻撃者による誘導があった場合、騙されたユーザーがIDとパスワードをコピペや手入力しかねない。

これがパスキーを使うようになると、仮にユーザーが不正サイトにログインしたいと思っても、認証情報を渡す手段がなくなります。ヒューマンエラーによるフィッシング被害が発生するリスクを回避できることが、「パスワードマネージャーからパスキー」という二段階目の移行を受け入れるユーザー視点のメリットといえますね。

――サービス提供者にとってはどのような変化がありますか。

伊東：ユーザーがパスワードマネージャーでパスワードを生成することが当たり前になれば、ひとまず「パスワードの使い回し」による懸念は解消されます。パスワードマネージャーはサービスごとにランダムなパスワードを生成しますから、他所から漏洩したパスワードで不正ログインされる玉突き事故におびえなくて済みます。

ただし、パスワード認証を採用している以上、自社のデータベースで保管しているパスワードが漏洩するリスクからは逃れられません。このリスクを根本的に解消できることが、認証方式をパスキーに一本化できるメリットになりますね。

おさらいになりますが、パスキー認証ではユーザーのデバイス上のパスワードマネージャーに公開鍵と秘密鍵のペアが生成され、そのうち公開鍵のみがサービス側に登録されます。ログイン時には、デバイスに保存された秘密鍵を使ってデジタル署名が生成され、サーバーはこの署名と公開鍵を使ってユーザーを認証するという流れです。

つまり、パスキーにおける認証情報とは「秘密鍵が生成するデジタル署名」ですから、公開鍵が万が一サービス側から漏洩したとしても悪用されにくい。

――ユーザーと企業、双方のセキュリティが段階的に向上していくのですね。それでは、パスキーが普及した後は“理想のセキュリティ”が実現されるのでしょうか？

伊東：残念ながら攻撃者とのいたちごっこは続きます。これは認証方式の歴史を見ても明らかです。

パスキーが普及すれば、今度はパスキーを管理するプラットフォームアカウントが攻撃対象になるかもしれません。また、現在はFIDOアライアンスが中心となり、プラットフォーム間でパスキーを共有するためのエクスポート/インポート機能を検討しています。つまり、秘密鍵をデバイスから抽出できるようになるということです。この機能を悪用して秘密鍵の受け渡しを要求するようなソーシャルネットワーキングと呼ばれる手口が現れる未来は容易に想像できます。

さらに、パスキーであまり注目されていないのが「物理的な脅威」です。たとえば「寝ている間に指紋でロック解除されたらどうなるのか」というリスクはパスキーがフォーカスしていた課題とは別なので、そちらが問題になることもあるかもしれません。

このように考えると、パスキーの普及がゴールとはいえません。

――それでは、認証に関わる開発者は何を目指せばよいのでしょうか。

伊東：認証に絶対的な正解はありません。繰り返しになりますが、どんな認証方式にもそれぞれ異なるメリット、デメリット、リスクが存在しています。認証機能は重要ですが、サービスの本質ではないので、どこかで折り合いを付ける必要があります。

求められる「安全かつ快適」の基準はサービスによって異なり、技術の進歩や新たな脅威の出現によって変化もしていきます。だからこそ、目標とするセキュリティレベルを適切に設定し、その実現のために最適な技術を選択・実装できる環境を維持することが重要です。これが認証における一種のゴールといえるのではないでしょうか。

ただ、各社が独自に判断して適切な認証方式を選ぶのはなかなか難しい。

認証はあくまでサービスの一部でしかないので、その検討や実装にあまりに時間を取られてしまうのは健全とはいえません。また、あまりよくないUXの実装が広まってしまうと、技術そのものがユーザーから嫌われてしまう懸念もあります。そこは業界団体、パスキーでいえばFIDOアライアンスに音頭を取ってもらいたいポイントでもありますし、私も啓発に協力したい部分です。

やはり新しい技術を浸透させるのは大変で、パスキーの普及も先は長いと痛感しています。漠然とではありますが、認証技術に関わってきた者として、自分にできることを考えているところです。

取材：戸部マミヤ、光松瞳
執筆：戸部マミヤ
編集：光松瞳