パスキーとは?仕組みと「導入前に知るべき課題」を解説

パスキー(Passkeys)は、パスワードに代わる次世代認証技術として急速に普及が進んでいます。政府の「国民を詐欺から守るための総合対策2.0」でも導入促進が掲げられ、金融機関やEC事業者への実装要請が強まっています。

しかし、パスキーの導入を検討する事業者にとっては、技術的なメリットだけでなく、デバイス依存やプラットフォームロックイン、スマホ非保有層への対応など、見過ごせない課題も存在します。2025年10月に公表された日本証券業協会のパブリックコメントでは、 44の事業者等から115件の意見が寄せられ、「パスキー一本化」への懸念が業界の声として示されました。

本記事では、パスキーの仕組みとメリットを解説したうえで、事業者が導入前に把握すべき課題を整理し、パスキーだけに頼らない認証戦略の選択肢を提示します。

パスキーとは何か? ―仕組みとメリット

パスキーは、パスワードに代わる次世代認証技術として注目を集めています。政府の「国民を詐欺から守るための総合対策2.0」でも普及促進が掲げられ、金融機関やEC事業者への導入要請が進んでいます。本章では、パスキーの技術的な仕組みとメリットを解説したうえで、導入検討にあたって知っておくべき課題の全体像を示します。

FIDO2/WebAuthnに基づくパスワードレス認証

パスキー(Passkeys)とは、パスワードを使わずに本人認証を行うための技術です。パスワードに依存しない認証技術の標準化を推進する業界団体FIDOアライアンス(Fast IDentity Online)とWeb標準化団体W3Cが共同で規格化しました。

パスキーの技術基盤となっているのが、2018年にFIDOアライアンスが公開した認証規格「FIDO2」です。FIDO2は、WebAuthn(Web Authentication)とCTAP2(Client to Authenticator Protocol 2)という2つの技術仕様で構成されています。WebAuthnはWebアプリケーション(サーバー側)とWebブラウザ間の認証を定義するJavaScript API仕様、CTAP2はクライアントデバイス(PCやスマートフォン)と認証デバイス(セキュリティキーや生体認証センサー)間の通信を定義するプロトコルです。

パスキーによる認証の仕組みは、公開鍵暗号方式に基づいています。初回登録時に、アカウントとサイトに紐づいた一意の「公開鍵」と「秘密鍵」のペアが生成されます。公開鍵はサーバー側に登録され、秘密鍵はユーザーのデバイス側に保管されます。次回以降のログイン時には、サーバーから送信されるデータに対してデバイス上の秘密鍵で署名を行い、サーバー側がペアとなる公開鍵で署名を検証することで認証が完了します。パスワードのようにサーバーとの間で秘密情報をやり取りしないため、通信経路上での漏えいリスクがありません。

なお、パスキーには2つの種類があります。「同期パスキー(Synced Passkey)」は、Apple・Google・Microsoftなどのクラウドアカウントを通じて複数のデバイス間で秘密鍵を同期する方式です。機種変更時にも再登録が不要で利便性が高い一方、後述するセキュリティ上の懸念もあります。もう一つの「デバイス固定パスキー(Device-bound Passkey)」は、秘密鍵を特定のデバイスやセキュリティキーに紐づけ、外部に持ち出さない方式です。

パスキーのメリット ―フィッシング耐性と利便性

パスキーの最大のメリットは、フィッシング耐性の高さです。パスキーにはサイトのドメイン情報がメタデータとして保存されており、WebAuthnはドメインを確認したうえで認証情報を渡す仕様になっています。ドメイン情報が一致しなければ認証が行われないため、正規サイトに類似したURLのフィッシングサイトに認証情報が渡ることはありません。

利便性の面でも、パスキーはパスワード認証の課題を解決します。ユーザーは複雑なパスワードを記憶・管理する必要がなく、指紋や顔認証などの生体認証で認証が完了します。パスワード忘れによる再設定の手間も発生しません。

こうしたメリットから、パスキーは次世代の認証方式として急速に普及が進んでいます。政府が令和7年4月22日に決定した「国民を詐欺から守るための総合対策2.0」(犯罪対策閣僚会議)では、「ID・パスワード等の窃取対策」の一環として「パスキーの普及促進」が明記されています。同対策では、フィッシングによるSMS認証コードのリアルタイム窃取被害が発生していることを踏まえ、関係省庁と連携した金融機関・EC事業者等へのパスキー導入促進が施策として盛り込まれています。

導入には課題もある

パスキーは技術的に優れた認証方式ですが、事業者が導入を検討するうえでは、見過ごせない課題とリスクも存在します。

実際、2025年7月に日本証券業協会が公表した「インターネット取引における不正アクセス等防止に向けたガイドライン」改正案に対して行われたパブリックコメントでは、44の事業者等から115件の意見が寄せられ、パスキーの技術的課題やリスクに関する詳細な懸念が多数示されました。
次章では、このパブリックコメントの内容も踏まえながら、パスキー導入における具体的な課題を整理します。

パスキー導入の課題とリスク ―事業者が知るべき「影」の部分

パスキーはフィッシング耐性に優れた認証方式ですが、事業者が導入を検討するうえでは、技術的・運用的な課題も見えてきています。2025年10月に公表された日本証券業協会のパブリックコメント結果では、証券会社やセキュリティベンダーから具体的な懸念が多数寄せられました。本章では、パブコメの内容も踏まえながら、事業者が導入前に把握すべき課題を整理します。

デバイス依存問題 ―スマホ紛失・機種変更で認証不能になるリスク

パスキーは秘密鍵をデバイスに保存する設計であるため、デバイスの紛失や故障が認証不能に直結するリスクがあります。

日証協のパブリックコメントでは、「多量に作成したパスキーが単一のデバイスに集中することでの紛失時に何もできなくなることのリスク」や「デバイス間での連携方法」への懸念が示されています。

同期パスキーを利用すれば、Apple・Google・Microsoftのクラウドアカウントを介して複数デバイスで秘密鍵を共有できるため、機種変更時の再登録は不要です。しかし、この利便性は次に述べるプラットフォーム依存や、パスキーハイジャックのリスクと表裏一体です。

プラットフォーム依存 ―Apple/Google/Microsoftのエコシステムにロックインされる

同期パスキーは秘密鍵の管理をApple・Google・Microsoftのクラウド基盤に依存します。この構造は、単なる利便性の問題にとどまらない懸念を生んでいます。

パブコメでは、「Googleアカウントが不正アクセスされるとパスキーが不正登録され、複数の金融機関へ不正侵入が可能となる」というリスクが指摘されています。さらに、「実質的に国産技術を排除し海外依存を強制することは、国防・国益・金融安定性の観点から不適切」「海外事業者従業員の属性や地政学リスクを考慮せず国民資産の鍵を『単一貸金庫』に預けることは危険」という踏み込んだ意見も寄せられています。

とりわけ金融業界では、認証基盤を海外プラットフォーマーに全面的に依存することの是非は、セキュリティだけでなく事業継続性の観点からも慎重な判断が求められます。

スマホ非保有層の切り捨て問題

パスキーは原則としてスマートフォンやPCの生体認証を利用する設計であり、これらの機器を所有していない、または操作に不慣れな利用者は認証を受けることができません。

パブコメでは、「特に高齢者がパスキーを自身で運用することの難易度は非常に高い」と指摘されています(パブコメP11)。実際、総務省の令和6年通信利用動向調査によれば、80歳以上ではモバイル端末を保有していない人の割合が2割を超えています。

また、パブコメでは「パスキーのような新しい技術仕様を実質的に強制となるような標準にするということは個人投資家にとっても大きな負担」であるとの意見も寄せられており、金融包摂の観点からパスキーの一律必須化に対する慎重論が存在しています。

パスキーハイジャックのリスク

デバイス固定パスキーの場合、秘密鍵はデバイスのセキュリティチップに保存されるため、秘密鍵そのものを盗み出すことはできないとされています(ただし同期パスキーでは、暗号化された秘密鍵がクラウド経由で同期されます)。しかし、パブコメでは「パスキーハイジャック」と「生体ハイジャック」という2つの攻撃手法が詳細に解説されています。

パスキーハイジャックとは、同期パスキーの仕組みを悪用した攻撃です。同期パスキーはクラウドアカウント(Apple ID、Googleアカウント等)を介して秘密鍵を複数デバイスに同期します。このアカウント自体が乗っ取られた場合、攻撃者のデバイスに秘密鍵がダウンロードされ、攻撃者自身の生体情報でパスキー認証が成立してしまいます。

パブコメでは、この攻撃は「完全に遠隔からの攻撃が可能で、物理的に攻撃対象のスマートフォン等を入手する必要がありません」と明記されています。

もう一つの「生体ハイジャック」は、デバイスを物理的に入手したうえで、攻撃者の生体情報を追加登録する手法です。パスコードを知っていれば生体情報の追加登録が可能であるため、デバイスの窃盗と組み合わせることでパスキー認証を突破できます。

これらの攻撃への対策として、クラウドアカウントの二要素認証にFIDO対応のセキュリティキーを設定することや、盗難デバイス保護機能の有効化が挙げられていますが、いずれも利用者のリテラシーと追加対応を前提とするものであり、全利用者への徹底は容易ではありません。

レガシーシステムとの共存問題

パスキーの導入はWebAuthnの実装を前提としますが、企業が提供する取引ツールや業務システムのすべてが即座に対応できるわけではありません。

パブコメでは、「Windows端末のブラウザによるアクセスに対してのパスキーを代表する『フィッシング耐性のある多要素認証』の提供は広範に安定的な運用実績が乏しい技術領域」であり、「モバイル端末のネイティブアプリケーションと比べると、それを実際に導入しようと考えた時のロードマップは大きく異なることが予想されます」と指摘されています。

つまり、モバイルアプリではパスキーを導入できても、Webブラウザ経由の取引ツールやレガシーシステムでは対応に時間を要する可能性が高く、「各取引ツールで同じ水準の機能・仕様を実装する」というガイドラインの要件を短期間で満たすことは難しいという現実があります。

日本証券業協会のパブリックコメントに見る「パスキー一本化」への懸念

前章ではパスキーの技術的な課題を整理しました。本章では視点を変え、業界団体としての制度的な議論に目を向けます。2025年10月に公表された日本証券業協会のパブリックコメント結果から、「フィッシング耐性のある多要素認証」の必須化に対して業界がどのような懸念を示しているのかを読み解きます。

ガイドライン改正案へのパブコメで示された懸念事項

2025年7月15日、日本証券業協会は「インターネット取引における不正アクセス等防止に向けたガイドライン」の改正案を公表しました。改正案では、ログイン時・出金時・出金先銀行口座の変更時などに「フィッシングに耐性のある多要素認証」の実装と必須化(デフォルトとして設定)を【スタンダード】として求めており、その例としてパスキーによる認証、PKI(公開鍵基盤)をベースとした認証が挙げられています。

このガイドライン改正案に対して、2025年7月15日から8月18日までの約1か月間にパブリックコメントが募集され、44の事業者等から115件の意見が寄せられました。
寄せられた意見のなかで、パスキーの例示に関する懸念は大きく3つに整理できます。
第一に、例示が事実上の強制力を持つという懸念です。パブコメでは、「例示は事実上の強制力を持ち、同等以上の効果を持つ他技術導入を妨げる」という意見が寄せられています。ガイドラインはあくまで「例」としてパスキーとPKI認証を挙げているに過ぎませんが、実務上は例示された方式が標準として受け取られやすく、それ以外の認証技術を採用しにくくなるという懸念です。

第二に、パスキーのフィッシング耐性そのものへの疑義です。同じ意見のなかで、「パスキーは厳密にはリアルタイムフィッシング耐性を有しておらず、単なるパスワード代替に過ぎない」という指摘がなされています。具体的には、WebAuthnのクロスデバイス認証(QRコードを介したログイン)において、攻撃者がPC上のログイン用QRコードを偽装サイトに表示し、利用者がスマートフォンでQRコードを読み取ってパスキー認証を行うと、攻撃者のPC側でログインが成立するというシナリオが示されています。

第三に、導入の現実性に対する懸念です。「急ぎ、セキュリティを向上させる必要がある現状に対して、『スタンダード』として過剰にパスキーへの依存性を強制してしまうのは、各証券会社の実装ロードマップを歪ませると共に、稚拙な実装による認証外の部分による脆弱性を誘引することにもなりかねない」と指摘されています。

「パスキー一本化」は時期尚早 ―業界が示した複数の懸念

こうした意見に対して、日証協はどのように回答しているのでしょうか。

日証協は、パスキーとPKI認証について「現時点においてフィッシングに耐性があると考えられる認証方式」であるとしたうえで、「今後の認証技術の進展を踏まえて、その他の技術を用いた認証の実装を妨げるものではありません」と繰り返し回答しています。
つまり、ガイドライン自体はパスキー以外の技術を排除していないという立場です。しかし、複数のパブコメ提出者が「例示=事実上の強制」と受け取っている現実は、事業者にとって重要な示唆を含んでいます。

また、ガイドラインの注釈4では、「フィッシングに耐性のある多要素認証」の定義として、パスキーやPKI認証以外にも「一定の利用実績によりフィッシング事案が確認されていない認証など」が含まれることが示されています。この注釈は、パスキー以外の認証方式であっても、フィッシング耐性の実績があればガイドラインの要件を満たし得ることを意味しています。

さらに、「代替的な多要素認証」に該当する方式についての具体的な記載を求める意見に対しても、日証協は「認証方式の安全性・リスクについては、流動的であり、技術の進展等により逐次変化するものであると想定されます」と回答しており、特定の技術に固定しない柔軟な姿勢を示しています。

パブコメ全体を通じて浮かび上がるのは、パスキーという技術そのものへの否定ではなく、「単一技術への過度な依存」に対する業界の警戒感です。セキュリティ技術は多様性と相互補完が重要であり、パスキーだけに頼る認証戦略には構造的なリスクが伴うという認識が、業界の複数の声として示されています。

パスキーの課題を解消する「電話認証」という選択肢

ここまで、パスキーの技術的課題と業界の懸念を整理してきました。
では、パスキーを導入できない環境や、パスキーだけに頼ることへのリスクに対して、事業者はどのような選択肢を持っているのでしょうか。本章では、「認証コードを使わない」という設計思想を共有しながら、パスキーとは異なるアプローチで課題を解消する「電話認証」について紹介します。

パスキーの弱点を電話認証が埋める ―課題対応表

前章までに整理したパスキーの課題に対して、電話認証がどのように対応するかを以下の表で整理します。

パスキーの課題 電話認証による対応
デバイス依存(紛失・機種変更で認証不能) 電話番号に紐づくため、デバイスに依存しない。機種変更しても電話番号が変わらなければ影響なし
プラットフォーム依存(Apple/Google/MSにロックイン) 電話網(PSTN)で完結し、海外プラットフォーマーへの依存がない
スマホ非保有層の切り捨て 固定電話でも利用可能。高齢者やスマートフォンを持たない利用者も認証を受けられる
パスキーハイジャック(クラウドアカウント乗っ取りによる認証情報の窃取) 認証情報にあたる認証コードの入力が一切不要なため、コードを中継・窃取する攻撃が原理的に成立しない
レガシーシステムとの共存 API連携方式のため、既存システムへの組み込みが比較的容易。WebAuthn対応の有無に依存しない

電話認証は、利用者が認証用の電話番号に発信するだけで認証が完了する仕組みです。認証コードの入力が存在しないため、フィッシングで「コードを中継する」という攻撃手法そのものが成立しません。

電話認証の仕組み ―コード不要・デバイス不問の認証フロー

前章で整理したとおり、パスキーにはデバイス依存・プラットフォーム依存・スマホ非保有層の排除といった課題があります。電話認証は、これらの課題を構造的に回避できる認証方式です。
電話認証では、利用者があらかじめ登録した電話番号から、認証用の電話番号に発信するだけで本人確認が完了します。認証コードの送信・入力が一切なく、スマートフォンも専用アプリも不要です。利用フローは以下の4ステップで完結します。


STEP 1:

認証開始 利用者がWebサイト上で送金や個人情報変更などの操作を行い、電話認証の画面に進みます。

STEP 2:

認証に使う電話番号の選択 利用者は、あらかじめ登録してある電話番号(自宅の固定電話や携帯電話など)のなかから、認証に使用する番号を選択します。

STEP 3:

認証用電話番号への架電 画面に認証専用の電話番号が表示されます。利用者は、STEP 2で選択した電話番号から、表示された認証専用番号に電話をかけます。

STEP 4:

認証完了 発信元の電話番号が登録済みの番号と一致すれば、認証が完了します。

この仕組みにより、パスキーが抱える課題の多くが解消されます。秘密鍵をデバイスに保存する必要がないためデバイス依存が発生せず、Apple・Google・Microsoftのクラウド基盤にも依存しません。固定電話でも認証できるため、スマートフォンを持たない高齢者層も排除されません。


*電話認証サービスの詳細は、こちらのページをご覧ください。

サービス紹介電話認証サービス

まとめ|パスキーだけに頼らない認証戦略を

パスキーは、パスワードを使わない次世代認証技術として大きな可能性を持っています。政府の「国民を詐欺から守るための総合対策2.0」でも普及促進が掲げられ、金融業界でのフィッシング対策の柱として期待されていることは間違いありません。

しかし、本記事で見てきたとおり、事業者がパスキーを導入するうえでは、デバイス依存・プラットフォーム依存・スマホ非保有層の排除・パスキーハイジャック・レガシーシステムとの共存という課題が存在します。日本証券業協会のパブリックコメントでも、「単一技術への過度な依存」に対する業界の警戒感が複数の意見として示されました。

重要なのは、パスキーを否定することではなく、パスキーだけに頼らない認証戦略を設計することです。パスキーを導入できる環境にはパスキーを、導入が困難な環境や利用者には電話認証を――こうした複数の認証方式を組み合わせる「多層的な認証戦略」が、すべての利用者を守る現実的なアプローチです。


*電話認証サービスにおけるリアルタイムフィッシング対策機能の詳細については、こちらの記事をご参照ください。

関連記事新機能:「認証目的の確認」でリアルタイムフィッシングを未然に防止

公開日 2026年04月01日

資料ダウンロード

  • 電話認証サービス

    リアルタイムフィッシングにも対応できる「電話認証サービス」の特長や提供イメージをご紹介しています。
    セキュリティ強化を検討されている方は、以下よりサービスパンフレットをダウンロードしてください。

お問い合わせ

Webから問い合わせる

あわせて読まれているコラム

関連する商品・サービス

同じカテゴリのコラム

お問い合わせ

インテックへのお問い合わせは、こちらからお願いいたします。

Webから問い合わせる
ページトップへ戻る