この記事でわかること
- パスワード認証が抱える構造的な脆弱性
- パスキーとFIDO2認証の仕組み（公開鍵暗号方式）
- Apple、Google、Microsoft、Amazon等の対応状況
- パスキー導入時に知っておくべき注意点
- 今すぐ始められるパスキー設定の手順
パスワードの限界──なぜ「知識認証」は破綻したのか
フィッシング攻撃の深刻化
パスワード認証の最大の弱点は、フィッシング攻撃に対して構造的に脆弱であることだ。フィッシングとは、正規のサイトに酷似した偽サイトにユーザーを誘導し、パスワードを入力させて盗む手法である。 手口は年々巧妙化しており、AI生成による精巧な偽メールや偽サイトにより、セキュリティリテラシーの高い人でも見分けがつかないケースが増えている。Verizonの2025年データ漏洩調査報告書によると、データ漏洩の60%以上に人的要素（フィッシング・認証情報の悪用等）が関与している。 多要素認証（MFA）としてSMS OTP（ワンタイムパスワード）を追加する対策も広がったが、SIMスワッピング攻撃やリアルタイムフィッシングプロキシにより、OTPも突破されるケースが報告されている。UAEの中央銀行は2026年3月までにSMSおよびメールOTPの廃止を全金融機関に義務付け、インド準備銀行も2026年4月からOTPベース認証の新規制を施行するなど、OTPからの脱却は世界的な潮流となっている。パスワードの使い回し問題
一般的なインターネットユーザーが管理するアカウントは100以上に達するとされる。これだけの数のアカウントに対して、それぞれ異なる強力なパスワードを設定・記憶することは現実的に不可能である。結果として、多くのユーザーが同じパスワードを複数のサイトで使い回している。 一つのサービスからパスワードが漏洩すると、攻撃者はその認証情報を他のサービスで自動的に試行する「クレデンシャルスタッフィング」攻撃を実行する。ユーザー一人のパスワード漏洩が、連鎖的な被害を引き起こすのである。 パスワードマネージャーの利用は有効な対策だが、普及率は依然として低い。「マスターパスワードを忘れたらすべてのパスワードにアクセスできなくなる」という恐怖が導入のハードルになっている。パスワードマネージャーで問題を「管理」するのではなく、パスワードそのものを「なくす」アプローチが求められている。サーバー側のリスク
パスワード認証には、サービス提供者側にも大きなリスクがある。ユーザーのパスワード（またはそのハッシュ値）をサーバーに保存する必要があるため、データベースが侵害されれば大量のパスワードが一度に流出する。 2024年だけでも、数十億件規模のパスワード漏洩事件が複数発生している。いくらハッシュ化やソルトの付加で保護しても、十分な計算資源があればオフラインでのブルートフォース攻撃により復元される可能性がある。 パスキーが根本的に異なるのは、サーバー側に秘密情報を保存しないことである。たとえサーバーが侵害されても、攻撃者が手に入れるのは公開鍵のみであり、それだけでは認証を突破できない。パスキー・FIDO2の仕組み──公開鍵暗号が変えるログイン体験
FIDO2の基本アーキテクチャ
FIDO2は、FIDOアライアンスとW3C（World Wide Web Consortium）が共同策定した認証規格である。「WebAuthn」（ブラウザとサーバー間の通信プロトコル）と「CTAP」（デバイスと認証器間の通信プロトコル）の2つのコンポーネントで構成されている。 FIDO2の核心は公開鍵暗号方式にある。ユーザーがサービスにアカウントを登録する際、デバイス内で公開鍵と秘密鍵のペアが生成される。公開鍵はサーバーに送信されて保存されるが、秘密鍵はデバイスの安全な領域（TPM、Secure Enclaveなど）に格納され、外部に出ることは決してない。 ログイン時には、サーバーが「チャレンジ」と呼ばれるランダムなデータを送信し、デバイスが秘密鍵で署名して返す。サーバーは保存済みの公開鍵で署名を検証し、正当なユーザーであることを確認する。このプロセス全体で、パスワードのような「秘密の文字列」は一切やり取りされない。パスキーの登場と同期機能
「パスキー」は、FIDO2認証情報の一種であり、特にクラウド同期に対応したものを指す。従来のFIDO2セキュリティキー（YubiKeyなど）は物理デバイスに紐付いていたため、そのデバイスを紛失するとアカウントにアクセスできなくなるリスクがあった。 パスキーは、AppleのiCloudキーチェーン、GoogleのパスワードマネージャーGoogleパスワードマネージャー、Microsoftアカウントを通じて、同一エコシステム内のデバイス間で自動的に同期される。iPhoneで作成したパスキーがiPadやMacでもそのまま使え、機種変更時のデータ移行もシームレスに行える。 認証の操作はシンプルだ。Face ID、Touch ID、指紋認証、デバイスのPINなど、デバイスのロック解除と同じ方法でログインが完了する。パスワードを記憶する必要がなく、入力ミスもない。FIDOアライアンスの調査では、パスキーを使ったことのあるユーザーの38%が「可能な限りパスキーを有効化している」と回答している。フィッシング耐性の仕組み
パスキーがフィッシングに強い理由は、認証プロセスにドメイン情報が組み込まれているためである。パスキーはサービスのドメイン（例：google.com）と紐付けて作成される。偽サイト（例：g00gle.com）にアクセスしても、ドメインが一致しないため、パスキーは自動的に動作しない。 つまり、ユーザーが偽サイトを本物と勘違いしてパスキーを使おうとしても、そもそも認証が成立しないのである。人間の判断に依存せず、技術的にフィッシングを防止する仕組みである。これはパスワードやOTPでは実現できなかった根本的な安全性の向上である。 また、パスキーの認証情報はサービスごとに固有であるため、一つのサービスのパスキーが漏洩しても（そもそも漏洩のリスクが極めて低いが）、他のサービスには一切影響しない。クレデンシャルスタッフィング攻撃が原理的に不可能になる。Point：パスキーは「人間の注意力」に頼らないセキュリティ
ドメイン紐付けによるフィッシング耐性は、ユーザーの判断ミスに依存しない構造的な防御である。セキュリティリテラシーに関係なく、すべてのユーザーが同じレベルの保護を受けられる。主要サービスの対応状況──2026年のパスキー導入マップ
プラットフォーム事業者の対応
Apple、Google、Microsoftの3大プラットフォームは、OSレベルでパスキーをサポートしている。Appleは iOS 16以降、macOS Ventura以降でパスキーに対応し、iCloudキーチェーンを通じた同期を提供。Googleは Android 14以降で「パスワードマネージャーにパスキーを保存」機能を搭載し、Chromeブラウザでもパスキーをフルサポートしている。 Microsoftは Windows 11でパスキーに対応し、Microsoft Authenticatorアプリでの管理・同期を提供。Edgeブラウザもパスキーの作成・利用に対応済みである。2025年には、対応サイトでパスワードログインした際に自動的にパスキーの作成を促す機能がChromeに搭載されるなど、パスキーへの移行が積極的に進められている。 サードパーティのパスワードマネージャーも対応を拡大している。1Password、Bitwarden、Dashlaneなどが、パスキーの保存・同期に対応。エコシステムをまたいだパスキーの管理（iPhoneで作成してWindowsで使用するなど）が可能になり、利便性が大きく向上した。大手Webサービスの対応
主要なWebサービスのパスキー対応は急速に広がっている。ECでは、Amazonが2024年に日本を含む全ユーザーへのパスキー提供を完了し、1億7,500万個以上のパスキーが作成されている。eBay、Shopifyも対応済みだ。 SNS・コミュニケーション分野では、X（旧Twitter）、LinkedIn、WhatsApp、GitHubがパスキーに対応。特にGitHubは、開発者コミュニティへの影響が大きく、パスキーの普及を加速させる効果があった。 金融分野では、PayPalが早期から対応。米国ではChase銀行が2026年初頭にリテール顧客へのパスキーロールアウトを開始し、Wells Fargoもモバイルアプリとウェブサイトでパスキーをサポートしている。 日本国内では、NTTドコモのdアカウントがパスキー認証率50%を達成し、不正購入被害が2年以上ゼロを記録している。メルカリはパスキー登録者数が700万人に達し、登録済みユーザーにはパスキーログインを必須化した。Yahoo! JAPANもパスキーに対応済みである。今後対応が期待される分野
銀行・証券などの金融機関のパスキー対応はまだ途上である。日本のメガバンクでは三菱UFJ銀行がパスキー対応を発表しているが、全銀行に広がるまでには時間がかかる見通しだ。ただし、インドや UAE の中央銀行がOTP廃止を義務化する動きは、日本の金融庁にも影響を与える可能性がある。 行政サービスの対応も注目される。マイナンバーカードを活用した公的個人認証サービスとパスキーの連携が実現すれば、行政手続きの利便性とセキュリティが同時に向上する。 医療分野では、電子カルテや医療情報システムへのアクセスにパスキーを導入する動きが始まっている。患者の個人情報を扱う医療機関にとって、フィッシング耐性の高い認証方式のニーズは特に高い。導入時の注意点──パスキーにも課題はある
デバイス紛失時のリカバリー
パスキーの最大の懸念は「デバイスを紛失したらどうなるか」である。クラウド同期されたパスキーであれば、同じアカウント（Apple ID、Googleアカウントなど）にログインできる別のデバイスがあれば問題ない。新しいデバイスにアカウントを設定すれば、パスキーは自動的に同期される。 問題は、すべてのデバイスを同時に失った場合や、クラウドアカウント自体にアクセスできなくなった場合である。多くのサービスはパスキー登録時に従来のリカバリー手段（メール、SMS、リカバリーコード）を併設しているが、これらの手段自体にセキュリティリスクがある点は矛盾を孕んでいる。 物理的なFIDO2セキュリティキー（YubiKeyなど）をバックアップとして1〜2本保管しておくことを推奨する。デバイス紛失とは独立した認証手段を確保でき、リカバリーの信頼性が大幅に向上する。エコシステム間の互換性
2025年時点で、パスキーのクラウド同期は基本的にエコシステム内に限定されている。Apple IDで同期されたパスキーはAppleデバイス間でのみ共有され、Androidデバイスでは直接使えない。ただし、QRコードやBluetoothを使った「クロスデバイス認証」により、一時的に別のデバイスから認証することは可能である。 1PasswordやBitwardenなどのサードパーティパスワードマネージャーは、プラットフォームをまたいだパスキーの同期を提供しており、この問題を実質的に解消している。Apple、Google、Microsoftもエコシステム間の互換性向上に取り組んでおり、将来的にはよりシームレスな移行が実現する見込みだ。サービス提供者側の実装課題
パスキー導入を検討するサービス提供者にとって、既存の認証基盤からの移行は簡単ではない。パスキー認証のバックエンド実装にはWebAuthn APIの理解が必要であり、リライイングパーティ（RP）サーバーの構築、認証フローの設計、UIの変更などが求められる。 OktaやAuth0、Descope、Corbadoなどの認証プラットフォームが、パスキー対応のSDKやAPIを提供しており、実装の負担を大幅に軽減できる。自社で一から構築するよりも、これらのマネージドサービスを活用する方が、セキュリティ面でも安全である。 段階的な移行も重要だ。いきなり全ユーザーにパスキーを強制するのではなく、オプトイン方式で提供を開始し、利用率を見ながら段階的に移行を進めるアプローチが推奨される。NTTドコモやメルカリの成功事例は、この段階的アプローチの好例である。まとめ
パスキーとFIDO2認証は、30年以上にわたってインターネットのセキュリティ基盤であったパスワードを、構造的に安全な仕組みへと置き換えるものである。フィッシング耐性、使い回し防止、サーバー漏洩リスクの排除という3つの利点は、パスワードでは原理的に実現できなかった。
| タイプ | おすすめアクション | 優先度 |
|---|---|---|
| すぐにパスキーを使いたい個人 | Google、Apple、Amazonのアカウント設定からパスキーを有効化。まず主要3サービスから始める | 高 |
| セキュリティ意識の高い個人 | パスキー＋物理セキュリティキー（YubiKey）のバックアップ体制を構築 | 高 |
| Webサービスの運営者 | パスキー対応の認証プラットフォーム（Auth0、Okta等）を導入し、段階的にパスキーログインを提供 | 中 |
| 企業のIT管理者 | 社内システムへのFIDO2認証導入を検討。Azure ADやOktaのパスキー機能を評価 | 中 |
| 金融・医療など規制業種の担当者 | UAE・インドの規制動向を参考に、OTPからパスキーへの移行ロードマップを策定 | 高 |
