パスキー（passkey）とはパスワードの代わりに指紋・顔・PINでログインする、FIDO標準に基づく認証情報（パスキー認証）。フィッシングに強いと説明される理由、iPhone・Android・Windows・Macの保存先、設定の入口、端末をなくした時の公式の説明【2026年10月版】

2026年10月13日・日本時間時点の情報です。 パスキー（passkey）とは、パスワードの代わりに、端末のロックを解除するときと同じ指紋・顔・PIN（数字の暗証番号）などで、アプリやウェブサイトにログインするための認証情報です。標準化団体のFIDO Alliance（ファイドアライアンス）は、パスキーをFIDO標準に基づく認証情報と説明しています。日本の証券会社や携帯会社の案内で「パスキー認証」と書かれているのは、このパスキーでログインする方法のことです。

パスキーは、ログインするサービスが対応していれば、設定画面から作れます。保存先はiPhone・MacならAppleのiCloudキーチェーン、AndroidならGoogleのパスワードマネージャー、WindowsならWindows Helloなどで、端末をなくした時にどうなるかは、どこに保存したかで変わります。

3行まとめ

1. パスキーはFIDO標準に基づく認証情報で、生体認証（指紋・顔）・PIN・パターンで承認してログインする。パスワードの入力は要らない（FIDO Alliance、2026年10月13日取得）。
2. フィッシングに強いと説明される理由は、パスキーが作ったサイトのドメインに結び付き、似せた偽サイトには端末が出さないため（Microsoft）。金融庁の監督指針と日本証券業協会のガイドラインは、2025年10月15日にパスキーを例として挙げ、証券会社に「フィッシングに耐性のある多要素認証」の必須化を求める文面を載せた。
3. 保存先はiPhone・MacがiCloudキーチェーン、AndroidとChromeがGoogleパスワードマネージャー、Windowsは端末内のWindows Helloか同期型のパスワードマネージャー。端末をなくした時は、同期していれば別の端末で使える。Windows Helloだけに保存したものは、パソコンをなくすと復元できない（Google）。

この記事は、パスキーの意味、パスワードとの違い、フィッシングに強いと言われる理由、保存先、設定の入口、端末をなくした時の扱いを、FIDO Alliance・Apple・Google・Microsoft・日本の公的機関・各社の公式ページの原文で確かめながら書いています。筆者は2026年10月13日の2時台に、ログインせずに開ける公式ページを開いて確かめ、ブラウザの仮想認証器（ソフトウェアで作った試験用の認証器）で、パスキーの動きも試しました。ChatGPT・GitHub・Notion・Canvaなど個別のサービスのパスキーは、それぞれのログイン記事に任せ、リンクで送ります。

パスキーとは何か。FIDO Allianceは、FIDOの標準に基づく認証情報と定義している

FIDO Allianceのパスキーのページは、冒頭で次のように定義しています（2026年10月13日2時1分取得）。

「A passkey is an authentication credential based on FIDO standards, that can be stored on your phone or computer, or in a hardware security key allowing a user to sign in to apps and websites with the same process that they use to unlock their device (biometrics, PIN, or pattern).」

（訳：パスキーは、FIDO標準に基づく認証情報で、スマートフォンやパソコン、またはハードウェアのセキュリティキーに保存でき、端末のロックを解除するのと同じ方法（生体認証、PIN、パターン）で、アプリやウェブサイトにサインインできる。）

認証情報は、ログインの時に「本人だ」と示すためのデータです。同じページは、パスキーによるサインインがFIDO2（WebAuthnとCTAP）として知られる標準を使い、WebAuthnがパスキーを管理するブラウザーのAPI（ソフトウェア同士が機能を呼び出す窓口）を扱うと書いています。

日本の公的機関の説明もあります。情報処理推進機構（IPA）が2025年8月28日に公開した注意喚起は、脚注で次のように書きます。

「パスキーとは、パスワードの代わりに生体認証（指紋認証や顔認証など）やデバイスのロック解除機能（PINコードなど）を使って、サービスのアカウントにログインする新しい認証方式のことです。パスワードの漏えいリスクが無く、より安全にログインできます。」

同じ注意喚起は、「パスワードに代わる新たなログイン認証方法として、パスキー（脚注2）の利用を推奨します」と書き、続けて「但し、パスキーの利用については、サービス側で対応している必要があります」と断っています。自分のサービスが対応しているかは、そのサービスのヘルプで確かめることになります。

「パスキー認証」はサービス側の言葉です。東海東京証券の2026年2月6日付のお知らせは「パスキー認証とは、スマートフォンやパソコンなどに組み込まれた生体認証（指紋認証や顔認証）や、PINコード、パターン認証などを使って本人確認をする認証方法です」と書きます。NTTドコモのdアカウントは、2023年4月5日から名称を「パスワードレス認証」から「パスキー認証」に変えたと、2023年3月13日付のお知らせに書いています。この記事では、パスキーでログインすることを「パスキー認証」と書きます。

パスワードと何が違うのか。入力するものがなく、サイトごとの鍵が使われる

公式ページが書いている違いを、観点ごとに並べます。

仕組みは、Microsoftのサポートが書く内容を要約すると、端末が秘密鍵と公開鍵のペアを作り、秘密鍵は端末の中に、公開鍵はサービスに置く、というものです。ログインの流れを、MicrosoftとPasskey Centralの説明から並べると次のとおりです。

1. 登録の時、端末が鍵のペアを作る。秘密鍵は端末に残り、公開鍵だけがサービスに渡る。
2. ログインの時、サービスが乱数（チャレンジ）を送る。
3. 利用者が指紋・顔・PINで承認すると、端末が秘密鍵で乱数に署名して返す。
4. サービスは、持っている公開鍵で署名を確かめ、ログインを許可する。

Microsoftの英語版の説明は、3と4をこう書いています。

「After you unlock your private key, your device digitally signs a challenge from the website or application. The website or application verifies the signature using the public key and grants you access.」

（訳：秘密鍵のロックを解除すると、端末はウェブサイトやアプリから届いた「チャレンジ」にデジタル署名をする。ウェブサイトやアプリは公開鍵で署名を確かめ、アクセスを許可する。）

Appleのサポートも同じ構造を書き、「秘密鍵が何かサーバ側が知ることはありません」とします。生体情報について、FIDO Allianceは、生体情報とその処理は端末の中にとどまり遠隔のサーバーには送られず、サーバーが見るのは生体認証が成功したという保証だけだと書いています。Googleのヘルプも、指紋や顔の生体認証データはデバイスに保存され、Googleと共有されないと書きます。

なぜフィッシングに強いと説明されているのか

フィッシングは、本物そっくりの偽サイトに誘導して、IDやパスワードを入力させて盗む詐欺です。パスキーがこれに強いと説明される理由を、Microsoftのサポートは次のように書きます。

「For example, a passkey created for netflix.com can only be used with netflix.com. While you may be tricked into landing on a similar looking website, your device won't present your passkey to the malicious website.」

（訳：例えば、netflix.comのために作ったパスキーは、netflix.comでしか使えない。似たような見た目のウェブサイトに誘い込まれたとしても、端末が悪意のあるウェブサイトにパスキーを差し出すことはない。）

直前の説明は、パスキーは作られた時に、ウェブサイトやアプリが登録されている特定のドメインに結び付けられる、というものです。ドメインは、アドレスのうち「netflix.com」にあたる部分です。FIDO Allianceが運営するPasskey Centralも、同じことを書いています。

「By design, a passkey is only presented to the site it was registered with. There is no way for the user to inadvertently type it on an attacker’s site.」

（訳：設計上、パスキーは登録されたサイトにだけ提示される。利用者が攻撃者のサイトにうっかり入力してしまう方法はない。）

Appleは「パスワードとは違い、フィッシング詐欺対策に優れ」た設計だと書き、Chromeのヘルプは「パスキーは作成された対象のアプリやウェブサイトのみと関連付けられる」と書きます。

日本の公的文書にも記述があります。国家公安委員会・総務大臣・経済産業大臣が令和8年3月12日に公表した資料（令和7年の不正アクセス行為の発生状況など）は、アクセス管理者（サービスを運営する側）が講ずべき措置として「ワンタイムパスワード等の二要素認証や二経路認証に加え、フィッシングに耐性のある認証技術（例：パスキー注15）の積極的な導入等により認証を強化する」と書き、注15の脚注で次のように説明します。

「FIDO Alliance と World Wide Web Consortium により規格化されているパスワードが不要な認証技術。フィッシングサイト等の正規サイト以外のウェブサイトにおいては、認証が機能しないといった観点から認証技術の漏えいリスクを低減できる効果があるとされている。」

前年の令和7年3月13日に公表された同じ資料は、この箇所を「次世代認証技術（パスキー注13）」と書いていました。

ワンタイムパスワード（使い捨ての数字のコード）との比べ方も書かれています。FIDO Allianceは、ワンタイムパスワードや、アプリでの端末承認は「still phishable」（今もフィッシングされうる）と書きます。日本証券業協会の2026年3月25日付の注意喚起は、偽のワンタイムパスワード入力画面に入力された番号を直ちに使って口座を乗っ取る「リアルタイムフィッシング」の被害が拡大していると書き、対策としてパスキーによる認証等の必須化を挙げています。

強いと言われても、守れないものはある

公式ページは、限界も書いています。FIDO Allianceは、セキュリティキーの説明の中で次のように書きます。

「Passkeys are more secure and easier to use than passwords, but how you create them matters. Passkeys backed by passwords or synced across devices are vulnerable to theft. Device-bound passkeys offer a phishing-resistant, hardware backed root of trust.」

（訳：パスキーはパスワードより安全で使いやすいが、どう作るかが重要である。パスワードで裏付けられたパスキーや、端末間で同期されるパスキーは、盗まれるおそれがある。端末に固定されたパスキーは、フィッシングに耐性があり、ハードウェアに裏付けられた信頼の起点になる。）

日本証券業協会は、「クラウド上にパスキーをバックアップする場合、Apple アカウントやGoogleアカウントについても多要素認証を設定する等、厳重に管理してください」と書き、「パスキー登録時を狙ったフィッシングが懸念されます。パスキー登録時は証券会社の公式サイトや公式アプリからお願いします」とも書きます。Googleのヘルプは「パスキーを使って Google アカウントにログインできるということは、そのデバイスにアクセスしてロックを解除できる状態にあることを意味します」と書き、共有デバイスではパスキーを作らないよう求めます。

筆者が試した：試験用のパスキーは、作ったドメインの外では使えなかった

作ったサイトにしか使われない、という説明を、筆者がこのMacの中の試験環境で試しました。2026年10月13日2時12分から13分にかけて、Playwright付属のChromium（バージョン148.0.7778.96、画面を出さない動作）に、ソフトウェアで作った仮想認証器を付けました。この認証器は試験用で、このMacのキーチェーンやパスワードアプリ、実際のアカウントには触れていません。自分のMacの中の127.0.0.1だけで小さなサーバーを動かし、a.localhostとb.localhostという2つの別のドメインに見立てて、次の4つを試しました。

手順1と2でブラウザが返したデータ（clientDataJSON）には、要求したページのアドレス（origin）と、サイトが送った乱数（challenge）が入っていました。originは、手順1と2のどちらも「http://a.localhost:」に、実行ごとに変わるポート番号が付いたものでした。筆者が見たのは、ブラウザが返すデータの中にページのアドレスが入っている、というところまでです。

手順4のエラーメッセージは次のとおりです。

「The relying party ID is not a registrable domain suffix of, nor equal to the current domain. Subsequently, an attempt to fetch the .well-known/webauthn resource of the claimed RP ID failed.」

（訳：リライングパーティID（サイトの識別子）が、現在のドメインの登録可能なドメイン接尾辞でも、現在のドメインと同じでもない。続いて、名乗られたRP IDの.well-known/webauthnの取得も失敗した。）

1文目が理由です。2文目は、名乗られたサイト側の宣言を探しに行って見つからなかったという意味に読めますが、この仕組みの中身は筆者は確かめていません。この実験が示すのは、このブラウザ（Chromium 148）と仮想認証器の組み合わせで、ブラウザが別のドメインのページにパスキーを渡さず、他のサイトの名前を名乗ることも許さなかった、というところまでです。実在のサービスの動きや、iPhone・Android・Windows Helloなど実際の端末に保存したパスキーの動き、サービス側のサーバーがoriginを検査する部分は、試していません。

パスキーはどこに保存されるのか。iPhone・Android・Windows・Mac

保存先は、使うOSとブラウザで違います。公式ページが書いている主なものを並べます。

同期型は、クラウド経由で自分の端末の間でパスキーが共有されるもの、端末固定型は、作った端末（またはセキュリティキー）にだけ残るものです。FIDO Allianceは、この2つを「synced passkeys」「device-bound passkeys」と書き分け、パスキーの作成と管理を担うものを「passkey provider」と呼んで、OSやブラウザの提供元の標準のもの（iCloudキーチェーン、Googleパスワードマネージャー）と、サードパーティのものがあると書きます。

対応するOSの下限は、GoogleもMicrosoftも、Windows 10以降、macOS Ventura以降、ChromeOS 109以降、Android 9以降、iOS 16以降と書き、Googleのヘルプはブラウザの下限にChrome 109・Safari 16・Edge 109・Firefox 122を挙げています。筆者のMacは、2026年10月13日2時13分に確かめるとmacOS 26.6、Safariも26.6で、この条件より新しい番号です。ただし、このMacでパスキーを作って使うことはしていません。

パスキーの設定はどこから始めるのか。サービス別の入口

設定の画面や名前はサービスごとに違い、筆者はログインしていないので、ログイン後の画面は見ていません。下の表は、各社の公式ヘルプとお知らせの記述です（2026年10月13日取得）。

Googleのヘルプによると、パスキーを作るとパスキー優先（パスワードなし）のログイン方法に切り替わり、新しいパスキーが使えるまで7日間ほどかかる場合があります。作るのは自分が所有し使用しているデバイスだけにするよう求め、既存の認証要素や復元要素は変更・削除されないと書きます。パスワードを先に求められる状態に戻すには、「Google にログインする方法」の「可能な場合はパスワードをスキップする」をオフにします。

筆者が2026年10月13日2時4分に、ログインせずに開いたGoogleアカウント ヘルプのページです。

Appleの手順の前提は、iCloudキーチェーンと2ファクタ認証がオンであることです。iPhoneユーザガイド（iOS 27版。iOS 26版も同じ手順）によると、iCloudキーチェーンは「設定」で自分の名前、「iCloud」、「iCloudに保存済み」の横の「すべてを表示」、「パスワードとキーチェーン」の順に開き、「このiPhoneと同期」をオンにします。同じガイドは「パスキーオプションが表示されない場合は、ウェブサイトまたはアプリがパスキーに対応していません」とも書いています。

Microsoftの同じページは、Edgeでパスキーが自動で作られる場合があり、その設定が「パスキーに自動的にアップグレードする」であることも書いています。Windowsの設定でのパスキーの管理は、英語版のヘルプでは「Settings」の「Accounts」の「Passkeys」です。日本語の画面名は、筆者は確かめていません。

LINEヤフーは2026年4月14日に、Yahoo! JAPAN IDのログイン方法を「パスキー」に一本化すると発表しました。第一段階として、2027年春頃までに「パスワードのみでのログイン」の終了を予定し（スケジュールは移行状況により変わる可能性があると注記）、同日から、パスワードのみでログインしている利用者にパスキーやSMS認証の設定の案内を出し始めたとしています。dアカウントは、ドコモ回線の契約者がモバイル回線で「パスキー端末設定」をする時に、ネットワーク暗証番号（契約時に設定した4桁の数字）を入力すると書きます。

証券会社のパスキー必須化と、その元になった文書

日本証券業協会の2026年3月25日付の注意喚起は、金融庁・日本証券業協会・警察庁が、パスキーによる認証等の提供と必須化をすべての証券会社に要請してきたと書いています。元になった文面は次のとおりです。

• 金融庁の「金融商品取引業者等向けの総合的な監督指針」の改正後の文面（令和7年10月15日公表・同日から適用）には、証券会社が講じているかを見る項目として、「ログイン、出金、出金先銀行口座の変更など、重要な操作時におけるフィッシングに耐性のある多要素認証（例：パスキーによる認証、ＰＫＩ（公開鍵基盤）をベースとした認証）の実装及び必須化（デフォルトとして設定）」があります。
• 日本証券業協会のガイドラインにも同じ趣旨の項目があり、付則は「この改正は、2025 年 10 月 15 日から施行する」と書きます。

東海東京証券は、必須化の理由に、偽サイトで盗まれたID・パスワードによる不正取引の被害の急増を挙げています。表の日付は各社のお知らせに書かれたもので、2026年10月13日時点の運用を筆者は各社の画面で確かめていません。日本証券業協会は同じ注意喚起で、メールやSMSのリンクからはログインせず、公式サイトのブックマークや公式アプリからログインするよう求めています。

端末をなくした時、機種変更した時はどうなるのか

結論は、どこにパスキーを保存したかで変わります。公式ページの記述を、保存先ごとに並べます。

iCloudキーチェーン（Apple）。 Appleのサポートは、パスキーを同期すれば「デバイスを 1 台紛失した場合に備えて冗長性も確保できます」と書きます。すべてのデバイスを失った場合は、iCloudキーチェーンのエスクロー（Appleが暗号化されたコピーを預かる仕組み。Appleは中身を読めないと書く）で復旧できます。「パスキーのセキュリティについて」によると、iCloudアカウントとパスワードで本人確認をし、登録済みの電話番号に届いたSMSに応答し、デバイスのパスコードを入力します。認証を試せるのは10回までで、合計10回失敗するとエスクローレコードは破棄されます。

Googleパスワードマネージャー。 同じGoogleアカウントでChromeまたはAndroidにログインしている端末なら、どの端末でもパスキーを使えます（Chromeのヘルプ）。Googleアカウント自体にログインするためのパスキーについては、そのパスキーが入った端末をなくした時、使える端末でGoogleアカウントにログインし、紛失した端末のパスキーを削除するよう、Googleアカウント ヘルプは書いています。手順は、「セキュリティとログイン」の「Google にログインする方法」の「パスキーとセキュリティ キー」から、削除したいパスキーを選んで削除アイコンを押す、です（Googleアカウント ヘルプ）。

Windows Helloなど、端末だけに保存したパスキー。 Chromeのヘルプは「パスキーを Windows Hello に保存した場合、パソコンを紛失したり、オペレーティング システムを再インストールしたりすると、パスキーを復元できなくなります」と書き、Chromeプロファイルに保存した場合も、パソコンの紛失やプロファイルの削除で復元できなくなると書きます。Microsoftのサポートも、端末固定型について次のように書きます。

「You can only sign in from that device (or with a backup passkey). If you lose the device, you lose the passkey unless you have another recovery method.」

（訳：その端末（またはバックアップのパスキー）からしかサインインできない。端末をなくすと、ほかの復旧の方法がない限り、パスキーも失う。）

Microsoftは、端末を替える時の順序も書いています。同期型のパスワードマネージャーに保存していれば、新しい端末で「Just sign in with your credential manager account」（資格情報マネージャーのアカウントでサインインするだけ）です。端末に保存していた場合は、新しいパスキーを先に作り、そのあとで古いパスキーを削除します。

FIDO Allianceの説明。 別のOSのスマホに替える時、複数のOSにまたがる資格情報マネージャーを使っておらず、古い端末が手元にあるなら、古い端末のパスキーで新しい端末にサインインし、そのあと新しい端末でパスキーを作れると書きます。同期したすべての端末を失った場合は、FIDOのセキュリティキーが回復用の認証情報になりうるとも書きます。

サービスごとの案内。 Yahoo! JAPANのヘルプは、機種変更・端末の初期化・パスキーの削除をする前に、ログインに使えるパスキーが残っているか確かめるよう求め、使えるパスキーも他のログイン方法もない場合は「ログインできない場合のお手続き」を案内します。dアカウントは、「いつもパスキー設定」中にパスキーが使えない場合、IDとパスワードに加え、連絡先メールアドレスと連絡先携帯電話番号に届くセキュリティコードで設定を解除するページを案内しています。楽天証券は、パスキーを作ったスマホを紛失しても「生体認証などの情報はご本人にしか利用できないため、他人がパスキーでログインすることはできません」と書き、別の端末でパスキーを追加か削除するよう案内します。自動音声ダイヤルに連絡すると、一時的（30分間）にログインIDとパスワードでログインできるとも書いています。

iPhoneの機種変更全般は、iPhoneの機種変更でデータを移す方法に、「パスワード」アプリと「パスワードとキーチェーン」の同期を確かめる順序がまとまっています。GitHubで認証の手段をすべて失った時の公式の手順は、GitHub Copilotのログイン方法にあります。

パスキーは二段階認証（多要素認証）の代わりになるのか

二段階認証は、パスワードに加えて、もう1つ別のものを確かめる方法です。パスキーは別の仕組みですが、Microsoftのサポートはパスキーを多要素認証の一形態と書きます。FIDO Allianceは、パスキーが単独で「password + OTP」（パスワードとワンタイムパスワード）や「password + phone approval」（パスワードと端末承認）の組み合わせより安全と書き、一部の規制の枠組みは、パスキーを正式な多要素認証の一つとして認めるところまで、まだ追いついていないとも書いています。Googleのヘルプによると、2段階認証プロセスを有効にしているアカウントでも、パスキーを使うと2つ目の手順は省略されます。

個別のサービスでの扱いは、ChatGPTのログイン方法（多要素認証の方法にパスキー）、Microsoft 365のログイン方法（サインインオプションの「顔、指紋、PIN、またはセキュリティ キー」）、Notionのログイン方法（個人のパスキーの追加）、Canvaのログイン方法（パスキーの追加の場所）に、それぞれ書いてあります。

この記事で確かめられていない点：ログイン後の画面と、実機でのパスキーの作成

• ログイン後の画面を見ていません。 アカウントの作成とログインをしない方針で調べたため、各サービスの設定画面は公式ヘルプの記述を引いただけです。自分のパスキーを作って使うことも、このMacのキーチェーンやパスワードアプリを開くこともしていません。
• Microsoftの日本語ページが英語に移りました。 「パスキーとは何か」と「保存したパスキーを管理する」は、サイト内の一覧には日本語の題名で載っていますが、日本語版のアドレス（古い形式やWindowsの節のアドレスも）を開くと、curlでも日本語設定のヘッドレスブラウザでも英語版に移りました（2時3分と2時28分〜40分に確認）。理由は確かめていません。この2つは英語の原文と訳で引いています。
• 仕様書では確かめていません。 WebAuthnの仕様を載せたW3Cのページは、自動判定の確認画面（ボット確認）が出て開けなかったため、そこは押さずに諦めました。サーバーがoriginをどう検査するかは、条文でも実験でも確かめていません。
• 証券会社の必須化の日付は、各社のお知らせの日付です。 2026年10月13日時点の運用は確かめていません。マネックス証券のお知らせはアクセス拒否（403）で開けず、今回取得したSBI証券のヘルプのページにはパスキーの記述が無かったため、この2社は使っていません。
• Googleの日本語ヘルプには、「AI 技術を使用して翻訳されたコンテンツが含まれている場合があります」という注記がありました。 引用した日本語は、筆者が開いた2026年10月13日の時点の表示です。

パスキーの記述を確かめた公式ページと、開いた時刻（2026年10月13日）

本文で引いた公式ページは、2026年10月13日の2時1分から2時13分の間に、ログインせずに開きました（AppleのiCloudキーチェーンのページのiOS 27版だけは2時32分。各ページの取得時刻は出典欄にあります）。Apple・Google・Microsoft・Yahoo! JAPAN・FIDO Alliance・Passkey Central・LINEヤフー・金融庁のページは、1280×800と390×844の大きさで撮影し、画面の文字も保存しました。

筆者が2026年10月13日2時4分に、スマホの大きさで開いたAppleサポートのページの冒頭です。出典のアドレスは、記事の出典欄にまとめています。