🫥
パスキーで変わる認証設計 ritouさんに聞く実装における課題とベストプラクティス イベントレポート
公開
2025-04-14
更新
2025-04-14
文章量
約2852字
Yard 編集部
Yardの編集部が、テック業界の最新トレンドや知見について発信します。
はじめに
2025年3月25日、「パスキーで変わる認証設計 ritouさんに聞く実装における課題とベストプラクティス」というオンラインイベントが開催されました。近年パスキーへの注目が急速に高まる中、本イベントでは OpenID ファウンデーション・ジャパン エバンジェリストのritouさんが登壇。パスキーの仕組みや現状の運用、導入における課題、そして今後の展望が具体的に語られました。
本記事では、イベント全体の流れを追いながら、パスキーが「なぜここまで注目されているのか」「導入の際に何を考慮するべきか」をまとめます。
パスキー登場までの経緯
パスワード認証の限界
オンライン認証の歴史を振り返ると、まずパスワード認証が基本でした。しかしユーザー、サービス双方にとって以下のような課題が大きくなってきています。
ユーザー側
「推測困難なパスワードを使う」「使い回しを避ける」といった実践が難しく、漏えい時の被害が拡大しがち。
フィッシングサイトを見極めることは現実的に困難。
サービス側
パスワードを安全に管理（適切なハッシュ化など）しないと漏えいリスクが高まる。
フィッシングやブルートフォース攻撃への対策にコストがかかる。
こうした課題に対処するため、多要素認証（2段階認証など）を導入する動きが広がりました。ところが、メールやSMSによるワンタイムパスワードなどはリアルタイム中継型のフィッシング攻撃に弱く、十分な防御とはいえない面もあります。
ファイド（FIDO）認証の考え方
そこで登場したのがFIDO方式。パスワードそのものを使わず、公開鍵暗号を用いて認証する仕組みです。従来のパスワードとは異なり、サービスがユーザーの秘密鍵を一切持たないため、漏えいリスクが大幅に抑えられます。さらに、ブラウザがフィッシング対策として「オリジンを厳密チェックする」特性を利用するため、フィッシングサイトでは正しい認証処理を実行できないのもポイントです。
初期のFIDO認証はUSBセキュリティキーが代表的でしたが、スマートフォンやPCの生体認証と組み合わせることで、「端末所持 + ローカル認証」という多要素認証を自然な操作感で実現しやすくなりました。
パスキー（Passkey）への発展
ファイド認証そのものは以前から存在していたものの、端末の買い替えや紛失時に「秘密鍵が端末のセキュア領域に固定されていて移行が面倒」という課題も指摘されていました。 ここで登場したのが「パスキー」という概念です。秘密鍵をプラットフォームやパスワードマネージャーで同期し、ユーザーが複数デバイス間でシームレスに使えるようになったことで、実用性が高まりました。
導入時のパターンと検討すべきポイント
オプショナル追加パターン
既存の認証方式（たとえばID・パスワード）に対して、パスキーを「追加要素」として導入するやり方です。具体的には：
パスキーの管理画面を用意
いつでも登録・削除が行える画面を用意し、ユーザーが自分のタイミングでパスキーを設定できるようにする。
設定誘導（利用促進）
既存のID・パスワードでログインしたユーザーに対し、「パスキーを使ってみませんか」と誘導する。
ログイン画面のUI
パスキーオートフィル対応ブラウザなら、自動的に「パスキーでログイン」が選択肢に出る場合がある。対応ブラウザが不明な場合は別途ボタンを設置するなど、ユーザー混乱を防ぐ工夫が必要。
オプショナルの利点は、「わからない・使えない」というユーザーには従来の手段をそのまま提供できること。問い合わせ増を抑えやすく、スムーズな並行運用が期待できます。
必須化パターン
サービスや特定機能で「パスキーが必須」となるケースもあります。金融や高度にセキュリティを求める領域では、このやり方でフィッシング被害を大幅に抑えようとする流れが見られます。
ただし、「パスキーが使えない環境」や「端末が故障して使えなくなる状況」への対策が不可欠です。救済手段を設けないまま必須化すると、ユーザーがログイン不可能に陥り、問い合わせが急増する恐れがあるため慎重な設計が求められます。
Q&Aで語られたポイント
イベント後半のQ&Aでは、視聴者から多くの質問が寄せられました。その中で印象的だったポイントをいくつか紹介します。
Q1. フィッシング攻撃で中継された場合、パスキーは安全ですか？ A. リアルタイム中継型のフィッシングも、ブラウザがオリジンを照合して動作をブロックするため、パスキー情報を盗まれることはありません。これはファイド認証の核となる仕組みです。
Q2. パスキー認証とオープンID Connect / OAuthの共存は可能？ A. 可能です。たとえばGoogleがパスキーを導入しており、「Googleログイン」で他サービスに連携する際、Google側がパスキーを使って安全に認証する構成も一般的に実現できます。
Q3. デバイス間同期の弱点があるなら、QRコードで乗っ取られる危険も？ A. スマホでのログインをQR経由で行う仕組みは便利ですが、悪用されると「ユーザーに正規サイトと思わせて別のQRを読み込ませる」などのリスクがあります。結局は“弱い部分”を狙われる可能性があるため、UI設計や利用フローの整合が欠かせません。
全体を踏まえた感想 〜これからのパスキー導入にむけて〜
パスキーは、「パスワード認証の抱えるフィッシングや漏えいリスク」に正面から取り組んできたFIDOの技術を、一段と使いやすくアップデートしたものだといえます。すでに各OSやブラウザが積極的にサポートしており、数年前まで難しかった「複数デバイスでの使い回し」問題も着実に解決へ向かっています。
一方で、デバイスを失った場合のリカバリーや、古い環境への対応、ユーザーへの分かりやすいUI設計など、新たな課題も浮かび上がります。便利な裏側には、スマートフォンの物理所持やローカル生体認証に頼る部分があり、導入時には「どの範囲で必須にするのか」「非対応環境やトラブル時にどう対処するか」をしっかり考えないと、かえってユーザーを混乱に陥れかねません。
最終的に、イベントを通じて感じたのは「パスキーは“パスワード卒業”への大きな一歩となるが、ゴールではない」ということです。狙われるポイントが変われば、新しい攻撃手段も生まれます。サービス提供者はパスキー導入によって生まれるUX向上とセキュリティ強化の恩恵を最大化しながら、リカバリーやエラーフローもデザインする必要があります。そこまで意識してこそ、パスキーが本当に“認証設計を変える”力を発揮するのではないでしょうか。
Yardでは、テック領域に特化したスポット相談サービスを提供しています。
興味がある方は、初回の無料スポット相談をお申し込みください。
また、資料請求やお問い合わせもお待ちしております。テック領域の知見を獲得し、事業成長を一緒に実現していきましょう。
