--- > [!NOTE] 目次 ```table-of-contents title: minLevel: 0 maxLevel: 0 includeLinks: true ``` --- > [!NOTE] リスト掲載用文字列 - [パスキー管理の注意点：変更も削除もあなたの手で--実はけっこう複雑な仕組みとは](https://japan.zdnet.com/article/35236443/)【ZDNET JAPAN】(2025年08月12日) --- > [!NOTE] この記事の要約（箇条書き） - パスキーはパスワードに代わる安全な認証手段として普及が進んでいる。 - しかし、その管理、特に「変更」や「削除」は直感的ではなく複雑。 - パスキーの「変更」は、新しいパスキーの作成と不要なパスキーの削除を手動で行う必要がある。 - パスキーは依拠当事者（ウェブサイトなど）が持つ公開鍵情報と、ユーザーの認証器が持つ秘密鍵の2つの記録で構成される。 - 現在、これら2つの記録を同時に削除する一括プロセスは存在しない。 - ユーザーは依拠当事者側と認証器側のパスキー記録をそれぞれ個別に手動で削除する必要がある。 - 依拠当事者側での削除には、再認証が求められる場合がある。 - 依拠当事者からの削除通知メールは、不審な動きを察知するために推奨される。 > [!NOTE] 要約おわり --- - - [noteで書く](https://note.mu/intent/post?url=https%3A%2F%2Fjapan.zdnet.com%2Farticle%2F35236443%2F&ref=https%3A%2F%2Fjapan.zdnet.com%2Farticle%2F35236443%2F&hashtags=ZDNET) - - 印刷する - - メールで送る - テキスト - HTML - 電子書籍 - PDF - - ダウンロード - テキスト - 電子書籍 - PDF - - クリップした記事をMyページから読むことができます 　好きか嫌いかはさておき、「パスキー」と呼ばれるログイン認証情報（ユーザー名とパスワードよりもはるかに安全な認証方式）は、確実に私たちのもとにやってきている。 　FIDO Allianceの「FIDO2」やWorld Wide Web Consortium（W3C）の「WebAuthn」といった業界標準は、パスキーの基盤となる技術であり、Apple、Google、Microsoftといった巨大テック企業によって開発・支援されている。最近では、MetaがiOS/Android版の「Facebook」と「Messenger」アプリにパスキー対応を追加したことで、普及の勢いはさらに加速している。 　ユーザー名とパスワードの代替としてのパスキーが、まるで強制的に押し付けられているように感じるかもしれない。しかし実際には、私たちがその概念に慣れ、使いこなすための時間はまだ十分に残されている。とはいえ、パスキーは従来の認証方式よりもはるかに優れていて安全であるにもかかわらず、その使用方法は決して直感的とは言えない。業界もこの点を認識しており、ユーザーが一斉にパスキーへ移行するまでの間は、従来のユーザー名とパスワードも引き続き利用可能である可能性が高い。 　では、なぜ移行が進まないのか。それは、ユーザーがパスキーを利用する際の体験が、ウェブサイトやアプリの運営者（「依拠当事者」と呼ばれる）によって予測不能かつ混乱を招く形で異なる場合があるからだ。その理由の1つとして、ほとんどのパスキーのワークフロー（登録および認証の“セレモニー”と呼ばれるプロセス）が、通常3〜4種類の技術を含んでおり、それぞれが異なるベンダーによって管理されている点が挙げられる。 　例えば、このシリーズで紹介している例では、Shopify.comが依拠当事者、Googleの「Chrome」がウェブブラウザー、Appleの「macOS」が基盤となるOS、「Bitwarden」が認証情報マネージャーおよびWebAuthn／パスキー準拠のオーセンティケーター（認証器）として機能している。これら4つの技術／ベンダーの間で、パスキーのエンドツーエンドのユーザー体験の一部がそれぞれの手に委ねられているのだ。 　さらに、他のパスキーのワークフローでは、あらかじめ組み立てられたユーザー体験そのものが存在しない場合もある。パスキーにおける「登録セレモニー」は、ユーザー名とパスワードを設定するプロセスに相当し、「認証セレモニー」は、依拠当事者のウェブサイトやアプリにログインする行為に相当する。現在体験できるパスキーのセレモニーは、依拠当事者が、介在する技術の影響を考慮しながら、ユーザーが登録や認証を完了できるように細心の注意を払って設計したものだ。 　Microsoftは、依拠当事者がどのようにパスキーのユーザー体験を設計すべきかについて [詳細な文書を公開](https://www.microsoft.com/en-us/security/blog/2024/12/12/convincing-a-billion-users-to-love-passkeys-ux-design-insights-from-microsoft-to-boost-adoption-and-security/) しているが、筆者としてはその全ての主張に賛同しているわけではない。 　ユーザー名やパスワードの変更・削除に関するワークフローはすでに整備されているが、パスキーに関しては、それに相当するユーザー体験がまだ存在していない。これは、パスキーの標準仕様が、同一の依拠当事者に対して1つのユーザーアカウントに複数のパスキーを持つことを可能にしているためだ。 　例えば、Shopify.comでは同時に複数のパスキーを保持できるが、パスワードは常に1つしか設定できない。パスワードは変更可能だが、パスキーは変更できない。代わりに、新しいパスキーをゼロから作成（登録セレモニーを使用）し、不要なパスキーを削除する必要がある。つまり、パスキーの「変更」に相当する操作をするには、ユーザー自身が一連の「セレモニー」を組み立てなければならない。 　そして、ここにもう1つの問題がある。パスキーを削除するための一括プロセスは存在しない。これこそが、本シリーズ最終回のテーマである「パスキーの削除方法」である。このプロセスは、パスキーの基盤となるW3CのWebAuthn標準において「廃止（decommissioning）」と呼ばれている。 　このシリーズの前半では、パスキーが本質的に2つの部分から構成されていることを学んだ。まず1つ目は、赤枠で示された部分（図1）で、パスキーの一意な公開鍵に関する情報である。これは、依拠当事者が記録として保持する部分である。  図1：パスキーが登録されるたびに、依拠当事者（今回のケースではShopify）は、そのパスキーに関連する幾つかの要素を記録として保持する。その中には、公開鍵、機械的に割り当てられたCredential ID、そしてuser.idが含まれており、これらはいずれもそのパスキーに固有のものである。しかしながら、ユーザーが確認できるのは、Shopifyによって付けられたパスキーの名称（この場合は「Passkey 」）や、作成日時といった軽微なメタデータに限られており、実際にひも付けられている公開鍵など、記録の中身を詳しく確認することはできない（提供：Screenshot by David Berlind/ZDNET） 　図2のスクリーンショット（BitwardenのChrome拡張機能）に示されているように、パスキーにはもう1つの重要な側面がある。それは、パスキーに固有の秘密鍵が常にユーザーの手元に保持されるという点である。通常、この秘密鍵は、ユーザーが選択したオーセンティケーターが使用する安全なストレージ内に保存される。 　この秘密鍵こそが、パスキーの「秘密の部分」であり、公開鍵暗号方式の仕組みに基づいて、パスワードのように依拠当事者と共有されることは決してない。パスキーの考え方はこうだ。正当な依拠とさえパスキーを共有する必要がなければ、フィッシングやスミッシングなどの攻撃に遭った際に、脅威アクターに誤って共有してしまうリスクもなくなる、というわけである。  図2：依拠当事者が自らの記録として保持するパスキーの構成要素に加えて、ユーザーのオーセンティケーター（この場合はBitwarden）も、独自の構成要素を記録として保持している（提供：Screenshot by David Berlind/ZDNET） 　ユーザーがパスキーを使って依拠当事者に対して認証を試みる際、そのサイトやアプリは「チャレンジ」と呼ばれるランダムな文字列をユーザーが選択したオーセンティケーターに送信する。このチャレンジは、実際にはチャレンジ自体とその他のデータを組み合わせたハッシュであり、オーセンティケーターはそれをコピーし、秘密鍵を使ってデジタル署名を行う。 　署名されたデータパッケージは依拠当事者に返送され、依拠当事者は、登録時に記録しておいた公開鍵を使って、返送されたチャレンジのコピーが元のチャレンジと一致しているか、そしてそれが対応する秘密鍵によって署名されたものであるかを検証する。もし一致しなければ、認証は失敗する。 　本質的に、パスキーには2つの記録が存在する。1つはユーザー側のシステムに、もう1つは依拠当事者側のシステムに保存されており、これらは互いに整合していなければならない。さらに、パスキーを使った継続的な認証のためには、どちらか一方の記録が破損または削除されてしまうと、もう一方の記録も無意味になってしまう。こうしたパスキーの構造（秘密鍵に根ざした一方と、それに対応する公開鍵に根ざしたもう一方）は、公開鍵暗号方式の仕組みによるものである。 　しかしながら、この構造はユーザーにとって1つの難題をもたらす。というのも、どちらか一方の記録が削除されてしまうと、もう一方の記録も無用となり、本来は両方を削除すべきだからである。残念ながら、現時点では両方の記録を同時に削除する技術は存在していない。筆者が話を聞いたパスキー推進派たちは、このギャップを認識しており、将来的には解決される見込みだと述べている。 　それまでは、パスキーの痕跡を完全に削除するにはどうすればよいのか。両方の記録を一括で削除する機能が存在しない以上、ユーザーは依拠当事者側の記録とオーセンティケーター側の記録をそれぞれ個別に削除する必要がある。 　この手順を示すために、筆者は依拠当事者にShopify.comを、オーセンティケーター兼認証情報マネージャーにBitwardenのChrome拡張機能を、ウェブブラウザーにChromeを、基盤となるOSにmacOSを使用して説明を続ける。ただし、念のため付け加えておくが、これらの製品を使用しているものの、推奨しているわけではない。 [PAGE 2](https://japan.zdnet.com/article/35236443/2/) 　最初のステップは、Shopify側のパスキー記録を削除することである。これを行うには、図1に示したShopifyのセキュリティ設定画面に戻り、赤い「Remove（削除）」をクリックする。 　ただし、誤って別のパスキーを削除してしまわないよう注意が必要である。今回の場合、登録時に作成した「Passkey No. 1」しか存在しないため、削除対象は明確である。しかし、パスキーの特徴の1つは、1つの依拠当事者に対して複数のパスキーを持つことができる点にある。仮にShopifyに対して2つ目のパスキーを作成していた場合、それは「Passkey No. 2」として表示されていたはずだ。 　複数のパスキーが存在する場合、削除する際には対応するセットを慎重に選ばなければならない。依拠当事者側の記録を削除したら、オーセンティケーター側の対応するパスキーも削除する必要がある。一部の依拠当事者では、ユーザーがパスキーに任意の名前を付けられる機能を提供しており、これにより識別が容易になるが、Shopifyではパスキー名を変更できない。 　対応するセットを識別するもう1つの方法は、依拠当事者のウェブサイトと認証情報マネージャーの両方に表示されるパスキーのタイムスタンプを比較することである。筆者の場合、図1と図10に示されているように、ShopifyとBitwardenの両方で、パスキーの作成日時が一致しているのを確認できた。これにより、両システムにおける対応する記録を特定できた。 　ただし、Shopifyがパスキーの記録を削除する前に、そのパスキーの実際の所有者が削除を要求していることを確認するための認証を求めてくる。以下のスクリーンショットに示されているように、Shopifyは再認証を要求し、ユーザーに対して有効な認証情報のいずれか（削除予定のパスキー、またはユーザー名とパスワード）で認証するよう求めてくる。  図3：Shopifyのパスキー記録を削除するためのリンクをクリックすると、Shopifyはユーザーに対して再認証を求めてくる。これは、実際にパスキーの削除を希望しているのが本人であり、かつその人物が現在コンピューターの前にいることを確認するためである（提供：Screenshot by David Berlind/ZDNET） 　筆者の場合（図4参照）、パスキーによる再認証を選択した。これにより、 [前回](https://japan.zdnet.com/article/35235995/) で説明したのと同じ認証セレモニーを再度実行する必要がある。まずは、認証情報マネージャー（この場合はBitwardenのChrome拡張機能）を起動し、ロックを解除するところから始まる。  図4：パスキーを削除する目的で再認証を選択すると、ユーザーはパスキー認証セレモニーを実行する必要がある。このセレモニーには、PINコード、生体認証、または指紋認証によってオーセンティケーター（ここではBitwardenだが、他のパスワードマネージャーでも構わない）のロックを解除する工程が含まれる（提供：Screenshot by David Berlind/ZDNET） 　認証情報マネージャー（Bitwarden）は、依拠当事者（Shopify）に対して使用可能なパスキーのみを自動的に表示する仕組みになっている（図5参照）。  図5：パスキー認証セレモニーの一環として、オーセンティケーター（Bitwarden）は使用可能なパスキーの選択肢を提示する。上記では、Shopify.comに対して記録されている唯一のパスキーが表示されている（提供：Screenshot by David Berlind/ZDNET） 　認証セレモニーが完了すると、筆者はShopifyのセキュリティ設定画面に戻される（図6参照）。注目すべき点として、先ほどまでこのページに表示されていたパスキー（Passkey が一覧から消えており、「A passkey was removed.（パスキーが削除されました）」という通知が表示されている。  図6：ユーザーが再認証を完了すると、Shopifyのセキュリティ設定画面からパスキーの記録が消え、「A passkey was removed.（パスキーが削除されました）」という通知が表示される（提供：Screenshot by David Berlind/ZDNET） 　さらに、図7に示されているように、Shopifyは筆者に対して、パスキーがアカウントから削除されたことをメールで通知してきた。このステップは依拠当事者に義務付けられているわけではないが、強く推奨される対応である。というのも、筆者は依然として従来のユーザー名とパスワードを使ってShopifyアカウントにログインできるため、悪意ある第三者がそれらの認証情報を入手してログインし、パスキーを削除する可能性が残っているからだ。依拠当事者がパスキー削除の通知を自動的にメールで送ってくれることで、アカウント上で不審な動きがあったことをユーザーが察知できる可能性が高まる。  図7：Shopifyのシステムからパスキーの記録が削除されると、Shopifyユーザーには削除の確認メールが送信される（提供：Screenshot by David Berlind/ZDNET） 　残念ながら、依拠当事者側のパスキー記録を削除できたからといって、それで作業が完了したわけではない。理想を言えば、まずその記録を削除した時点で、もう一方の記録（つまり、認証情報マネージャーがユーザーのシステム上に保持している秘密鍵の部分）も自動的に削除されてほしいところである。あるいは逆に、認証情報マネージャー側のパスキー記録を先に削除した場合に、依拠当事者側の対応する記録も自動的に削除されるようになっていれば、なお良いと思わないだろうか。 　しかし現実には、これはパスキーエコシステムの中でも最も未整備な領域の1つである。登録セレモニーや認証セレモニーといったプロセスでは、ユーザーが選択した認証情報マネージャーと依拠当事者のシステムとの間で、自動的に連携するワークフローがかなり精密に設計されている。だが、パスキーを削除するための統合的な仕組みやセレモニーは、今のところ存在していない。 　そのため、プロセスを完了させるには、ユーザー自身が認証情報マネージャーからパスキーのもう一方の記録を手動で削除する必要がある。 ZDNET Japan 記事を毎朝メールでまとめ読み（登録無料） [メールマガジン登録のお申し込み](https://japan.zdnet.com/newsletter/) ## ZDNET Japan クイックポール 所属する組織のデータ活用状況はどの段階にありますか？ ZDNET Japanは、CIOとITマネージャーを対象に、ビジネス課題の解決とITを活用した新たな価値創造を支援します。 ITビジネス全般については、 [CNET Japan](https://japan.cnet.com/) をご覧ください。