パスキー導入の全体像: パスワードレス認証の仕組み・メリット・注意点と最新動向

2026.05.28

はじめに

パスワードの使いまわし率は依然として8割を超えており、フィッシング被害も深刻さを増しています。こうした状況のなかで、パスワードそのものを使わないパスワードレス認証の手段として「パスキー」への関心が高まっています。では、パスキーの導入を検討するうえで、どのような仕組みや注意点を押さえておく必要があるのでしょうか。

パスキーは公開鍵暗号をベースにした認証方式であり、フィッシングへの耐性やログイン体験の向上といった利点がある一方、デバイス紛失時の復旧やパスワードからの段階的な移行など、導入にあたって考慮すべき点も存在します。本記事では、パスワード認証の課題からパスキーの技術的な仕組み、導入のステップ、国内外の事例までを順に整理していきます。

パスワード認証の限界と課題

使いまわしの実態と利用者心理

パスワードの使いまわしは、不正ログインの温床となる代表的な行動です。Webサービスの利用者1,034人を対象にした2026年の調査では、84.3%にあたる872人が複数のWebサービスでパスワードを使いまわしていました。2023年調査の83.8%と比べてもほぼ横ばいであり、長期にわたって改善が進んでいません（参照*1）。

使いまわしの理由にも特徴があります。同調査で使いまわしをしている872人に理由を尋ねたところ、「異なるパスワードを設定すると忘れてしまう」が74.3%、「異なるパスワードを考えるのが面倒」が48.3%でした（参照*1）。

これらの数字が示すのは、利用者がセキュリティを軽視しているというよりも、「覚えきれない」「考えるのが手間」という認知的負荷の高さが使いまわしを引き起こしているという構造です。パスワードの複雑さや数を増やすアプローチだけでは、利用者の行動を変えることが難しいといえます。

フィッシング被害の深刻化

パスワード認証が抱えるもうひとつの大きな問題は、フィッシング攻撃への脆弱さです。米国国立標準技術研究所（NIST）は、パスワードはフィッシング耐性を持たないと述べています（参照*2）。偽サイトにIDとパスワードを入力させる手口に対して、パスワード単体では防御できません。

金融業界ではこの問題が実被害に直結しています。フィッシングサイトへの誘導や不正ログインによる被害の深刻化を受け、金融庁と日本証券業協会は2025年7月に「インターネット取引における不正アクセス等防止に向けたガイドライン」の改正案を公表しました。この改正案では、フィッシングに耐性のある多要素認証の実施と必須化を求めています（参照*3）。

パスワードが持つ構造的な弱点と、規制当局がフィッシング耐性のある認証を求め始めた動きの両面から、従来のパスワード認証だけに頼り続けることのリスクが明確になっています。

パスキーの定義と技術的仕組み

公開鍵暗号とWebAuthnの基本構造

パスキーは、公開鍵暗号化を用いるWebAuthentication（WebAuthn）標準に則って開発された認証方式です。アカウントの登録時に、端末のOSが一意の暗号化鍵のペアを作成し、該当するアプリやWebサイトのアカウントと紐づけます。これらの鍵はアカウントごとにデバイスによって安全かつ一意に生成されます（参照*4）。

公開鍵暗号とは、「秘密鍵」と「公開鍵」という2つの鍵をペアで使う暗号技術です。秘密鍵は利用者のデバイスだけに保存され、公開鍵はサービス側に登録されます。ログイン時には秘密鍵で署名したデータをサービス側が公開鍵で検証するため、パスワードのように秘密そのものがネットワーク上を流れることはありません。

WebAuthnでは、特定のサイトに紐づいた公開鍵ベースの資格情報を作成・使用できるAPIが定義されています。公開鍵資格情報はWebAuthn認証器によって作成・保存され、利用者の同意のもとでのみ、その資格情報を作成したサイトからアクセスできます（参照*5）。つまり、あるサイト用に作った鍵を別のサイトが勝手に呼び出すことはできない設計です。

同期パスキーとデバイス固定パスキー

パスキーには大きく分けて2つの種類があります。ひとつは複数のデバイス間で同期できる「同期パスキー」、もうひとつは特定のデバイスに固定される「デバイス固定パスキー」です。

同期パスキーは、クラウドベースのパスキーサービスを使い、Apple端末やAndroid端末、パスワード管理ソフトなどの間で鍵を同期できます。1つの端末でパスキーを設定すれば、同じサービスを使う複数の端末で利用でき、紛失のリスクも抑えられます（参照*6）。

一方、デバイス固定パスキーは端末から取り外せない認証器と、端末から取り外して別の端末に接続できる認証器の2種類に分かれます。前者はOSに組み込まれたTouch IDやWindows Helloなどのプラットフォーム認証器であり、後者はYubiKeyのようなUSBキー型のローミング認証器です（参照*7）。用途やセキュリティ要件に応じて、どちらの方式を採用するかを検討する必要があります。

パスキー導入のメリットと注意点

フィッシング耐性とUX向上

パスキー導入の最大のメリットは、フィッシング攻撃に対する構造的な耐性です。NISTは、WebAuthnを実装した認証器について、認証されたドメイン名に基づいて認証の秘密を選択する「検証者名バインディング」によってフィッシング耐性を提供すると説明しています（参照*8）。

具体的には、パスキーのスコープルールにより、https://examp1e.comのような偽サイトでは、https://example.comのために作成されたパスキーを使うことができません（参照*7）。利用者が偽サイトにアクセスしてしまっても、パスキー自体がドメインの違いを検知するため、認証情報が漏れにくい設計です。

UX（利用体験）の面でも利点があります。生体認証と組み合わせれば、パスワードの記憶や入力が不要になります。パスキーはパスワードの代わりにアカウントの認証ができる仕組みであり、端末にあらかじめ保存した認証情報を指紋や顔などの生体認証で呼び出して照合します。生体情報は端末上の認証時にのみ使用され、サーバーには送信されません（参照*9）。

アカウント復旧とデバイス紛失リスク

パスキーの導入にあたっては、デバイスの紛失や機種変更への対応を設計段階から考慮する必要があります。端末の機種変更や紛失によってパスキーが使用できなくなる場合があることは、サービス提供側も利用者向けに案内しています（参照*9）。

同期パスキーを採用すれば、クラウド経由で鍵が複数端末に保持されるため、1台を紛失してもすぐにアクセスを失うわけではありません。iCloudキーチェーンの場合、エンドツーエンドの強力な暗号化鍵で保護されており、この暗号化鍵をAppleが知ることはないとされています。さらに、レート制限（短時間に試行できる回数の制限）によって総当たり攻撃を阻止し、すべてのデバイスをなくした場合でも鍵の復旧が可能な仕組みが備わっています（参照*4）。

ただし、すべての利用者が同期パスキーを使うとは限りません。デバイス固定パスキーの場合、端末を失えば認証手段そのものが消失します。そのため、複数のパスキー登録を促す仕組みや、代替の復旧手段をあらかじめ用意しておくことが、サービス設計の重要な検討項目になります。

導入の進め方と移行ステップ

パスワード併用からの段階的移行

パスキーの導入は、既存のパスワード認証をいきなり廃止するのではなく、段階的に進めるのが基本的な流れです。まず、利用者がパスワードで正常にサインインした際にパスキーの作成を提案します。次のステップとして「条件付き作成」と呼ばれる機能を活用し、パスキーの利用率を高めます。最終的に、利用者がパスワードそのものを削除できる段階へ移行します（参照*7）。

実装基盤の観点では、既存アカウントへの追加登録とパスワードレスでの新規アカウント作成の両方に対応する必要があります。パスワードベースのアカウントを持つ利用者が追加の認証方法としてパスキーを登録できること、新規利用者がアカウント作成時にパスキーだけで登録できること、そしてパスワードを入力せずパスキーのみで認証できること、この3つの機能が段階的移行を支える柱となります（参照*10）。

段階的移行の各フェーズで利用者にかかる負担が異なるため、どのタイミングでパスワード削除を許可するかは、サービスの利用者層や復旧手段の充実度にあわせて判断する必要があります。

実装チェックリストとUX設計

パスキー導入時の実装品質を高めるうえで、確認すべきポイントがあります。パスキーの作成を許可する前に、利用者が使用できるなかで最も強力な認証方法で本人確認を行うことが求められます。これは、乗っ取られたアカウントで攻撃者がパスキーを作成するのを防ぐために欠かせない手順です。また、excludeCredentialsの設定により、同じパスキー提供元で重複するパスキーが作成されないようにすることも推奨されています（参照*11）。

UX設計の面では、FIDOアライアンスがパスキーの導入と展開を加速するための設計ガイドラインを公表しています。このガイドラインは、オンラインサービス提供者がパスキーでサインインする際に、より優れた一貫性のあるUXを実現できることを目的としています（参照*12）。

技術的な正しさだけでなく、利用者がパスキーの作成から日常のログインまで迷わず操作できる画面設計が、導入後の利用率を左右します。実装チェックとUX設計の両面をあわせて進めることが、パスキー導入を成功に近づける鍵です。

国内外の導入事例と成果

金融・証券領域の事例

金融・証券領域では、フィッシング被害への対策としてパスキーの導入が進んでいます。楽天証券は、国内主要証券として初めてパスキーを導入し、パソコンやスマートフォンを使ったすべてのチャネルで利用できるようにしました。パスキーを指紋や顔などの生体認証と組み合わせることで、ログインパスワードを記憶する必要がなくなり、ログインの都度入力する手間も省けるようになるため、利便性の向上とセキュリティの強化が期待されています（参照*13）。

SMBC日興証券は2026年1月30日、個人顧客向けのオンライン取引サービスにおいてパスキー認証を用いたオンライン生体認証サービスの運用を開始しました。FIDO2規格準拠のパスキー認証サービスを導入して仕組みを構築しており、SDK（ソフトウェア開発キット）の活用により約5か月で導入を完了させています（参照*3）。

いずれの事例も、パスワード認証の限界に対する具体的な回答としてパスキーを位置づけている点が共通しています。導入期間や対応チャネルの範囲は、自社の導入計画を立てる際の参考になります。

Webサービス・ゲーム領域の事例

Webサービスやゲーム領域でも、パスキーの導入による具体的な成果が報告されています。国内では、pixivがパスキー利用者のログイン成功率を29%向上させました。東急はパスキーによってログインを12倍高速化し、毎日数千人の通勤者の利用を支えています。メルカリではパスキー認証によりログイン速度が3.9倍に向上しました（参照*14）。

ログイン成功率や導入率、費用削減などの変化も報告されています。Xはパスキーの導入後にログイン成功率が2倍に向上しています。Yahoo! JAPANではパスキーの導入率が11%に増加し、SMS OTP（ショートメッセージを使ったワンタイムパスワード）の費用が削減されました（参照*14）。

ゲーム領域では、ニンテンドーアカウントがパスキーに対応しています。端末に保存した認証情報を生体認証で呼び出し、サーバー側で照合する仕組みを採用しており、生体情報がサーバーに送信されない設計です（参照*9）。業種を問わず、ログイン成功率やログイン速度の改善が数値として確認されている点は、導入を検討する際の判断材料になります。

おわりに

パスワードの使いまわし率が8割を超え、フィッシング耐性のある認証が規制面でも求められるなかで、パスキーによるパスワードレス認証は「知っているけれど使っていない」段階から「実際に導入する」段階へ移りつつあります。金融・Webサービス・ゲームといった幅広い領域で成果が報告されており、導入の現実味は高まっています。

導入にあたっては、公開鍵暗号の仕組みを正しく理解したうえで、パスワード併用からの段階的移行、デバイス紛失時の復旧設計、そしてUXの一貫性という3つのポイントを押さえることが欠かせません。自社のサービス特性と利用者層に照らしながら、各ステップの優先度を見極めてみてください。

お知らせ

パスキーやパスワードレス認証の導入は、認証方式を変えるだけの取り組みではありません。ID管理、アクセス制御、端末管理、クラウド環境との連携など、インフラエンジニアが関わる領域にも影響します。
インフラエンジニアが自身の仕事内容を把握することは、案件選びやスキル棚卸しに不可欠です。業務範囲や必須スキルを確認し、フリーランス向けの最新案件情報も参考にしましょう。
cyseekではフリーランスのITエンジニア向けの案件をご紹介しています。
案件に関する新着情報は、以下のリンクからご覧いただけます。

参照

cyseekはサイバーセキュリティ人材向けの案件紹介サービスサイトです。

サイバーセキュリティ業界に精通したエージェントが求人紹介、年収交渉、キャリアアップの実現など、採用課題の整理から稼働後のフォローまでトータルにサポートするほか、保有するノウハウを活かしフリーランスやサイバーセキュリティ人材に向けたコラムを発信しています。