「パスキー」という言葉を、スマホの設定画面やログイン時の案内で見かける機会が増えてきたのではないだろうか。
GoogleやApple、Amazonといった大手サービスが次々と対応を進め、国内でもメルカリやSBI証券、楽天証券など身近なサービスへの導入が相次いでいる。
しかし、「名前は知っているが、何がどう変わるのかよくわからない」という人も多いはずだ。
トレンドマイクロが2026年2月に実施した調査によると、パスキーの認知率は91.1%に達した一方、「仕組みまで理解している」と回答したのは41.9%にとどまった。
パスキーが注目される背景には、深刻化するフィッシング詐欺の問題がある。
フィッシング対策協議会の「フィッシングレポート2025」によると、2024年に国内で報告されたフィッシング件数は171万8,036件にのぼり、前年の約1.4倍と過去最多を大きく更新した。
こうした状況を受け、金融庁も2025年1月の資料において、フィッシング被害への対策として「パスキー利用の促進」を明記している。
パスキーはそもそも何なのか。
パスワードと何が違うのか。
本当に安全なのか。
デメリットはないのか。
本記事では、情報処理安全確保支援士・応用情報技術者・情報セキュリティマネジメントといったIT系の国家資格に合格し、実機での検証を行う筆者が、パスキーについて仕組みから安全性・デメリットまで順を追って解説する。
パスキーとは何か
まずはパスキーについて、概要を整理する。
パスキーをひと言で説明すると
パスキーとは、スマホや PCに保存された「鍵」を使って、パスワードを入力せずにログインできる仕組みだ。
もう少し具体的に言うと、ログイン時に「パスワードを打ち込む」のではなく、「スマホの顔認証や指紋認証でログインを承認する」という形に変わる。
パスキーはFIDOアライアンス（後述）とW3Cという国際的な標準化団体が策定した仕様に基づいている。（特に名前を覚える必要はない。）
これにGoogle・Apple・Microsoftの三社が2022年に共同でサポートを表明したことで、一気に普及が加速した。
特定の会社が独自に作った仕組みではなく、業界全体で決めた「共通ルール」である点は、信頼性の根拠として押さえておきたい。
パスワードと何が違うのか
パスワードとパスキーの最大の違いは、「あなたが何かを覚えて入力する」か「デバイスが代わりに証明する」かという点にある。
| パスワード | パスキー | |
|---|---|---|
| 認証の方法 | 文字列を入力する | デバイスの生体認証などで承認する |
| サーバーへの保存 | パスワードが保存される | パスワード自体は存在しない |
| フィッシング詐欺 | 偽サイトで入力すると盗まれる | 偽サイトでは認証が成立しない |
| 漏洩リスク | サーバーが攻撃されると流出しうる | 流出するものがそもそもない |
| 利便性 | 覚える・打ち込む手間がある | 指紋・顔認証で即完了 |
| 端末を失ったとき | 別の端末からでもログインできる | 別途復旧手段が必要 |
パスワードの場合、ログインのたびに文字列をサーバーへ送信する。
つまり「正解の文字列をサーバーと共有している」状態だ。
これが漏洩やフィッシングの根本的な原因になる。
一方パスキーは、そもそも「共有する秘密の文字列」が存在しない。
詳しい仕組みは次の章で解説するが、かんたんに言うと、サーバーには「照合用の鍵」しか保存されておらず、本物の鍵はデバイスの外に出ない設計になっている。
パスキーが登場した背景
パスキーが生まれたのは、パスワードという仕組み自体が限界を迎えつつあったからだ。
フィッシング対策協議会の「フィッシングレポート2025」によると、2024年に国内で報告されたフィッシング件数は171万8,036件にのぼり、前年の約1.4倍と過去最多を大きく更新した。
どれだけ複雑なパスワードを設定していても、偽サイトに入力してしまえば意味がない。
また、パスワードの管理自体も問題を抱えている。
複数のサービスで同じパスワードを使い回す「パスワードの使い回し」は非常に危険だが、現実には多くのユーザーが行っている。
あるサービスから漏洩したID・パスワードを別のサービスに試す「リスト型攻撃」が横行しているのはこのためだ。
二段階認証（ログイン時にSMSで届くコードを入力する方法）もある程度有効だ。
しかし、近年はSMSのコードをリアルタイムで盗み取る高度なフィッシング攻撃も登場しており、完全な対策とは言いきれない状況になっている。
こうした「パスワードが抱える構造的な問題」を根本から解決するために設計されたのがパスキーだ。
金融庁も2025年1月の資料において、フィッシング被害への対策として「パスキー利用の促進」を明記している。
つまり、パスキーはもはや一部の技術好きだけが使うものではなく、社会インフラレベルで普及が求められる技術になりつつある。
パスキーの仕組みをわかりやすく解説
つぎにパスキーの仕組みについて解説していく。
2つの鍵 | 公開鍵と秘密鍵とは
パスキーの仕組みを理解するうえで、まず「公開鍵」と「秘密鍵」という2種類の鍵の概念を押さえておく必要がある。
難しそうに聞こえるが、イメージとしては「南京錠と鍵」の関係だ。
南京錠（公開鍵）は誰に見せても構わない。
サーバー側が持つのはこの南京錠だけだ。
一方、南京錠を開けられる鍵（秘密鍵）はあなたのデバイスの中にだけ存在し、外部に出ることは一切ない。
つまり、サーバーに保存されているのは「南京錠」だけであり、それが流出したとしても、対応する「鍵」がなければ何もできない。
パスワードのように「正解の文字列をサーバーと共有する」構造とは根本的に異なる点がここだ。
秘密鍵はデバイスのセキュリティチップ（iPhoneであればSecure Enclave、AndroidであればStrongBoxなど）という、OSからも直接アクセスできない領域に厳重に保管される。
取り出すには生体認証（指紋・顔認証）またはデバイスのPINコードによる本人確認が必要だ。
注：厳密にはパスキーは生体認証である必要はない。一般的には生体認証が使われるため、わかりやすさを重視して生体認証と記載している。
ログイン時に何が起きているか
実際にパスキーでログインするとき、裏側では以下の3つのステップが瞬時に行われている。
ステップ① サーバーが「問題」を出す
ログインボタンを押すと、サーバーは「チャレンジ」と呼ばれるランダムな文字列を生成してデバイスに送る。
これは「あなたが本人かどうかを確かめるための問題をスマホに解かせている」と思えばいい。
毎回異なる使い捨ての問題なので、たとえ盗み見られても再利用できない。
ステップ② デバイスが生体認証を経て「回答」を作る
問題を受け取ったデバイスは、生体認証でユーザーの本人確認を行う。
認証が通ると、秘密鍵を使って問題に「署名」し、回答をサーバーへ返す。
このとき秘密鍵そのものは送信されない。
あくまで「署名した結果」、つまり本人確認の結果だけが送られる。
ステップ③ サーバーが公開鍵で「答え合わせ」をする
サーバーは保存している公開鍵（南京錠）を使って、受け取った署名が正しいかどうかを検証する。正しければログイン成功だ。
偽サイトに誘導されたとしても、チャレンジの送信元が正規のサーバーでなければ署名は成立しないため、フィッシングが原理的に効かない設計になっている。
FIDO2・WebAuthnとは何か(上級者向け)
パスキーの仕組みを調べると、「FIDO2」や「WebAuthn」という言葉が出てくることがある。
これらは「パスキーのベースになっている業界標準の規格名」だと理解しておけば十分だ。
覚える必要はない。
かんたんに説明すると、FIDO2はFIDOアライアンスという業界団体が策定したパスワードレス認証の標準規格であり、WebAuthnはその一部としてW3CというWeb標準を決める国際団体が定めたブラウザ向けの仕様だ。
パスキーはこのFIDO2規格に基づいて実装されている。
「規格に基づいている」ということは、GoogleやApple、Microsoftといった異なるプラットフォーム間でも同じ仕組みで動作することを意味する。
iPhoneで登録したパスキーがWindowsのChromeでも使えるのは、この共通規格があるからだ。
FIDO2・WebAuthnの技術的な詳細については、別記事で詳しく解説する予定だ。
【準備中】
パスキーの3つのメリット
次にパスキーの3つのメリットについて。
パスキーには主に以下の3つのメリットがある。
- フィッシング詐欺にほぼ引っかからない
- パスワード漏洩のリスクがなくなる
- ログインが速くなり、パスワードを覚えなくてよい
パスワードと比べるとどれも大きなメリットと言える。
それぞれ詳しく見ていこう。
フィッシング詐欺にほぼ引っかからない
1つ目はフィッシング詐欺にほぼ引っかからないという点。
フィッシング詐欺とは、本物そっくりの偽サイトに誘導し、IDやパスワードを入力させて盗み取る攻撃手法だ。
パスワード認証の場合、見た目が本物と区別がつかない偽サイトであっても、ユーザーが気づかずに入力してしまえばそれで終わりだ。
パスキーの場合はそもそも「入力する文字列」が存在しない。
前述の通り、ログイン時にサーバーから送られてくる使い捨ての文字列に対してデバイスが処理したデータ(署名)のみを返す仕組みになっている。
この「署名」は、登録した正規サイトのドメイン（≒URL）に紐づいて生成される。
つまり、偽サイトのドメイン（≒URL）に対しては署名が成立しないため、仮に偽サイトに誘導されても認証自体が完了しない。
ユーザーが「怪しいと気づく」かどうかに依存しないセキュリティ、という点がパスワードとの決定的な違いだ。
なお、パスキーでも防ぎきれない高度な攻撃手法（リアルタイムフィッシング）も一部存在する。
この点については後述の「パスキーは本当に安全なのか？」の章で詳しく解説する。
パスワード漏洩のリスクがなくなる
2つ目はパスワード漏洩のリスクがなくなるという点。
パスワード認証では、サービス側のサーバーにパスワードの情報（正確にはハッシュ化されたもの）が保存されている。
ハッシュ化とは、パスワードを一定の計算式で変換し、元の文字列がわからないようにする処理のことだ。
暗号化のようなものだと思ってもらえば良い。
しかし、このハッシュ化されたデータが大量に流出した場合、総当たり攻撃（手当たりしだいに試す攻撃）などによって元のパスワードが解析されるリスクが残る。
パスキーの場合、サーバーに保存されるのは公開鍵だけだ。
公開鍵は「南京錠」、つまりただの錠であり、それだけでは何もできない。
仮にサーバーが攻撃を受けて公開鍵が流出したとしても、対応する秘密鍵（南京錠を開けるための鍵）はユーザーのデバイスの中にしか存在しないため、不正ログインには使えない。
つまり、「サービス側が攻撃されて自分のアカウントが乗っ取られる」というパターンのリスクが、構造的になくなる。
ログインが速くなり、パスワードを覚えなくてよい
3つ目はログインが速くなり、パスワードを覚えなくてよい点。
セキュリティ面だけでなく、使い勝手の面でもパスキーには明確なメリットがある。
パスワードによるログインでは、サービスごとに異なるパスワードを設定・記憶し、ログインのたびに入力する必要がある。
パスワードを忘れれば再設定の手続きが必要になり、二段階認証が設定されていればSMSのコードを待つ手間も加わる。
パスキーであれば、スマホを手に取って顔認証や指紋認証を行うだけでログインが完了する。
筆者も日頃からパスキーを使用しているが、実際にGoogleアカウントへのログインで比較したところ、パスワード＋SMS認証の組み合わせでは10〜15秒程度かかっていた操作が、パスキーでは2〜3秒で完了した。
また「パスワードを忘れた」という状況自体が発生しなくなる。
サービスごとに異なる複雑なパスワードを管理する必要がなくなるため、認知的な負担も大幅に減る。
セキュリティと利便性はしばしば相反しがちだが、パスキーはその両方を同時に改善できる。
この点がパスキーがこれだけ急速に普及が進んでいる理由のひとつだろう。
パスキーのデメリット・注意点
何ごともメリットがあればデメリットがある。
パスキーも例外ではない。
ここではパスキーのデメリットや注意点について、以下の3点を中心に解説する。
- スマホを紛失・機種変更したときのリスク
- まだ使えないサービス・端末がある
- iCloud・Googleアカウントが乗っ取られたらマズい
こちらも1つずつ見ていこう。
スマホを紛失・機種変更したときどうなるか
パスキーの弱点として最もよく挙げられるのが、端末の紛失や機種変更時のリスクだ。
トレンドマイクロの調査でも、パスキーへの不安点として「機種変更時の引き継ぎが不安」が35.6%、「スマホの紛失・故障時にログインできなくなりそう」が35.3%と、それぞれ上位に挙がっている。
この不安は理解できるが、実際には適切な対処法が用意されている。
現在の主流な運用では、パスキーはiCloudキーチェーン（Apple）やGoogleパスワードマネージャーを通じてクラウドに同期される。
つまり、iPhoneを機種変更した場合でも、同じApple IDでサインインすれば新しい端末にパスキーが引き継がれる仕組みだ。
Androidも同様に、Googleアカウント経由で同期される。
端末を突然紛失した場合は、パスキーを登録した各サービスのアカウント設定から、パスキーを削除・無効化する操作が必要になる。
パスワード認証と同様に「アカウントへのアクセスを別の手段（メールや電話番号）で復旧する」フローが用意されているサービスがほとんどだ。
ただし、クラウド同期を使わずにデバイス単体でパスキーを管理している場合は、端末の紛失がそのままアクセス不能につながるリスクがある。
機種変更時の具体的な手順については、別記事で詳しく解説する予定だ。
【準備中】
まだ使えないサービス・端末がある
パスキーは急速に普及が進んでいるとはいえ、2026年現在、すべてのサービスや端末で使えるわけではない。
サービス側の対応については後述の「パスキーの対応状況」の章でまとめるが、国内でも対応していないサービスはまだ多く残っている。
端末側の条件としては、iOSであればiOS 16以降、AndroidであればAndroid 9以降が必要だ。
数年以上前のスマホを使い続けている場合は、OSのバージョンが条件を満たしていない可能性がある。
また、ブラウザ側もChrome、Safari、Edgeなど、それぞれの比較的新しいバージョンが必要になる。
現実的には、パスキーに完全移行できるのはまだ先の話であり、当面はパスワード認証との併用が続く。
パスキー非対応のサービスも含めて、複数のアカウントを安全に管理する手段としてパスワードマネージャーの活用が有効だ。
この点については後述する。
iCloud・Googleアカウントが乗っ取られたら、凍結したら
パスキーをクラウドに同期して使う場合、利便性と引き換えにひとつのリスクが生じる。
iCloudやGoogleアカウント自体が乗っ取られた場合、同期されたパスキーにも不正アクセスされる可能性がある点だ。
イメージとしては、パスワードマネージャーのマスターパスワードが漏れた場合に似ている。
保管庫ごと奪われるリスクだ。
そしてもうひとつ、見落とされがちなリスクがある。
Googleアカウントの凍結・停止だ。
Googleアカウントは規約違反と判断された場合、予告なく突然停止されることがある。
本人に悪意がなくても、スパム判定・不正アクセスの疑い・支払いトラブルなどを機械的に検知してアカウントが凍結されるケースが報告されており、復旧にはGoogleへの申請が必要になる。
ここ最近では申請しても解除されないことが多くなっているようだ。
凍結中はGmailもGoogleドライブも使えなくなるが、問題はそれだけではない。
Googleパスワードマネージャーに同期していたパスキーも、凍結と同時にアクセスできなくなる。
iCloudも同様で、Apple IDが停止・ロックされた場合、iCloudキーチェーンに保存したパスキーにアクセスできなくなる。
つまり、GoogleやAppleという巨大プラットフォームにパスキーを預ける構造は、「そのプラットフォーム自体のトラブルが、自分のすべての認証情報に波及する」という一点集中リスクを抱えている。
この対策として有効なのが、プラットフォームに依存しないパスワードマネージャーへのリスク分散だ。
パスワードマネージャーの代表例として1Passwordが挙げられる。
1Passwordは自身のアカウントでパスキーを管理するため、GoogleやAppleのアカウント状況に左右されない。
GoogleアカウントやApple IDという「すべての卵を入れた一つのカゴ」に依存するのではなく、1Passwordというカゴを別に用意しておくことが、パスキー運用における現実的なリスク分散策だ。
Googleアカウント凍結の具体的なリスクと対策については、別記事で詳しく解説する予定だ。
【準備中】
「めんどくさい」と感じる場面とその対処
パスキーに対して「なんかめんどくさそう」「うざい」と感じるユーザーの声も少なくない。
実際にどういった場面で不便を感じやすいか、正直に整理しておく。
まず、初期設定の手間だ。
パスキーを登録するには、各サービスのアカウント設定から手動で有効化する操作が必要なケースが多い。
サービスによっては設定画面がわかりにくく、登録完了まで戸惑うこともある。
次に、サービス側からパスキーへの移行を強く促されるケースだ。
ログインのたびに「パスキーを設定しませんか？」と案内が表示されたり、一部のサービスでは事実上の強制移行に近い誘導が行われることがある。
こうした体験が「うざい」と感じさせる原因のひとつになっている。
また、共有端末（家族や職場のPC）での利用は想定されていない点も注意が必要だ。
パスキーは「そのデバイスを使う本人」であることを前提とした仕組みであるため、複数人が同じ端末を使う環境には向かない。
こうした不便さの多くは「慣れ」と「環境整備」で解消されていくものではあるが、現時点では過渡期特有の煩雑さがあることは否定できない。
パスキー非対応サービスはパスワードマネージャーで補う
パスキーが普及途上にある現状では、パスキー対応サービスとパスワード認証のサービスが混在する状態がしばらく続く。
この状況を安全かつ効率的に乗り越えるための現実解が、パスワードマネージャーの活用だ。
パスワードマネージャーとは、複数サービスのIDとパスワードを一元管理し、ログイン時に自動入力してくれるツールだ。
サービスごとに異なる複雑なパスワードを設定しつつ、自分では覚えなくてよい状態を実現できる。
なかでも1Passwordは、パスワード管理ツールとしての完成度が高いだけでなく、パスキー自体の保存・管理にも対応している数少ないツールのひとつだ。
パスキーへの完全移行が完了するまでの「つなぎ」としてだけでなく、移行後も認証情報の管理ツールとして長く使い続けられる点が1Passwordの強みだ。
1Passwordはカナダの企業が提供しており、通常であれば米ドルでの支払いとなる。
しかし、日本の上場企業であるソースネクストが代理店となっており、ソースネクストのサイトからであれば日本語かつ日本円で購入ができる。
セキュリティ対策の入口として、パスキーの導入と合わせて検討する価値がある。
パスキーは本当に安全なのか？セキュリティの観点から検証
ここまで読んで「パスキーって完璧なんじゃないか」と感じた方もいるかもしれない。
しかし正直に言うと、パスキーは非常に優れた認証方式ではあるものの、すべての攻撃を無効化できる万能な仕組みではない。
どういった攻撃には強く、どういった攻撃には限界があるのかを防御側の視点で整理しておく。
パスキーを突破する攻撃手法は存在するか
現時点でパスキーを突破しうる攻撃として、主に以下の3つのパターンが考えられる。
- デバイスの物理的な盗難
- 生体認証の偽装
- クラウドアカウントの乗っ取り
① デバイスの物理的な盗難
パスキーの秘密鍵はデバイスの中に保存されているため、デバイスそのものを盗まれた場合にリスクが生じる。
ただし、秘密鍵を使うには生体認証またはPINコードによる本人確認が必要だ。
つまり、デバイスを盗まれただけでは不正ログインはできない。
問題になるのは、PINコードを盗み見られた状態でデバイスも奪われるケースだ。
実際に2023年頃から海外では、バーやクラブで被害者のスマホのPINを盗み見たうえで端末を盗む手口が報告されている。
このリスクへの対策としては、PINコードを人目のある場所で入力しない、生体認証を主な認証手段にする、といった運用上の注意が有効だ。
② 生体認証の偽装
顔認証や指紋認証を偽装してパスキーを突破できるのではないか、と疑問に思う方もいるだろう。
理論上はゼロではないが、現実的な脅威としての難易度は非常に高い。
現代のスマホに搭載されている生体認証は、写真や型取りによる偽装に対して高い耐性を持つよう設計されている。
一般ユーザーがこの攻撃のターゲットになる可能性は、現時点では極めて低いと考えてよい。
③ クラウドアカウントの乗っ取り
パスキーをiCloudやGoogleパスワードマネージャーに同期している場合、そのクラウドアカウントが乗っ取られると、保存されたパスキーへの不正アクセスが起こりうる。
この点は前述のデメリットの章でも触れた通りだ。
加えてここで強調しておきたいのが、乗っ取りだけでなくアカウント凍結のリスクだ。
特にGoogleアカウントは規約違反・不正アクセスの疑いなどを機械的に検知した場合、予告なく停止されることがある。
その場合、Googleパスワードマネージャーに預けていたパスキーへのアクセスも同時に失われる。
このリスクへの現実的な対策は、GoogleやAppleといった特定のプラットフォームへの依存を減らし、1Passwordのようなプラットフォーム非依存のパスワードマネージャーにパスキーを保存・管理することだ。
1Passwordであれば、GoogleアカウントやApple IDの状況に関係なく、自分のアカウントで認証情報を管理し続けることができる。
3つのパターンいずれも、従来のパスワード認証と比べれば攻撃の難易度は格段に高い。
パスキーはノーリスクとは言えないが、パスワードと違い漏洩のリスクは低く、生体認証を利用することで他人に使われるリスクも減る。
現時点で一般ユーザーが使える認証手段の中では、最も実用的かつ安全なもののひとつと言えるだろう。
パスキーでも防げない攻撃「リアルタイムフィッシング」とは
パスキーが苦手とする攻撃として、セキュリティの専門家の間で注目されているのが「AiTM攻撃（Adversary-in-the-Middle：中間者攻撃）」、いわゆるリアルタイムフィッシングだ。
通常のフィッシング詐欺は「偽サイトにパスワードを入力させる」手口だが、AiTM攻撃はより高度だ。
攻撃者がユーザーと本物の正規サイトの間に中継サーバーを設置し、通信をリアルタイムで中継することで認証情報を盗み取ろうとする。
本物のサイトのソースコードをリアルタイムで読み込み、見た目では判別不可能な偽サイトを生成するため、ユーザーが気づくのは非常に難しい。
従来の二段階認証（SMSのワンタイムパスワード）はこの攻撃に対して無力に近い。
2025年初頭には国内の証券口座で乗っ取り被害が多発し、MFAを有効にしていたにもかかわらず不正アクセスされたケースもあった。
その背景としてAiTM攻撃を含む複数の手口が悪用されていたと考えられている。
では、パスキーはAiTM攻撃に対してどうなのか。
パスキーは「登録した正規サイトのドメイン(≒URL)に紐づいた署名」しか生成しないため、中継サーバーが介在してもその署名は正規サーバーに対してのみ有効であり、通常のAiTM攻撃に対しては強い耐性を持つ。
ただし、AiTM攻撃はブラウザ内部の通信チャネルを悪用するなど、より検知しにくい手法が研究されており、完全に安全とは言い切れない状況が続いている。
この攻撃手法の詳細と具体的な対策については、別記事で詳しく解説する予定だ。
【準備中】
主要サービス・OSのパスキー対応状況（2026年版）
ここでは主要なサービスやOSのパスキーの対応状況を解説する。
対応済みの主要サービス一覧
パスキーへの対応は、国内外を問わず主要なサービスで急速に進んでいる。
FIDOアライアンスによると、世界では150億を超えるアカウントでパスキーが利用可能になっている。
国内でも身近なサービスへの導入が相次いでいる状況だ。
以下は2026年5月時点での主要サービスの対応状況をまとめたものだ。
| サービス名 | 対応状況 |
|---|---|
| Google アカウント | ◎ 対応済み |
| Apple ID | ◎ 対応済み |
| Microsoft アカウント | ◎ 対応済み |
| Amazon | ◎ 対応済み |
| PayPal | ◎ 対応済み |
| Yahoo! JAPAN | ◎ 対応済み |
| メルカリ | ◎ 対応済み |
| NTTドコモ （dアカウント） | ◎ 対応済み |
| LINEヤフー | ◎ 対応済み |
| マネーフォワード | ◎ 対応済み |
| 楽天 （一部サービス） | △ 一部対応 |
| SBI証券 | ◎ 対応済み |
| 楽天証券 | ◎ 対応済み |
| Adobe | ◎ 対応済み |
| Nintendoアカウント | ◎ 対応済み |
| PlayStation | ◎ 対応済み |
| X（旧Twitter） | ◎ 対応済み |
| Meta （Facebook） | △ 段階的移行中 |
ただし、「対応済み」と一口に言っても、サービスによって細かな違いがある点には注意が必要だ。
完全対応といえるサービスは少数派で、パスキーの保存先などにかなりの違いがあり、スマホのみ対応でPCは非対応というサービスも存在する。
また、MicrosoftとYahoo! JAPANではパスワードの完全削除が可能だが、多くのサービスは従来のパスワードとの併用が前提になっている。
楽天証券については特に注意点がある。
パスキーへの対応は進んでいるものの、現時点ではBluetooth非対応のPCからは利用できないなど、環境によって使えないケースがある。
各サービスの具体的な設定手順については、別記事で詳しく解説する予定だ。
【準備中】
対応しているOS・ブラウザの条件
パスキーを利用するには、使っているOSとブラウザが一定のバージョンを満たしている必要がある。
以下の表で自分の環境が対応しているか確認してほしい。
OS・プラットフォームの条件
| OS・プラットフォーム | 最低要件 | 同期方法 |
|---|---|---|
| iOS / iPadOS | iOS 16 以降 | iCloudキーチェーン |
| Android | Android 9（API 28）以降 | Googleパスワードマネージャー |
| macOS | Ventura（13）以降 | iCloudキーチェーン |
| Windows | Windows 10 以降 + Windows Hello | Microsoftアカウント / 1Password等 |
AndroidのパスキーサポートはAndroid 9（APIレベル28）以降が対象となる。
Android 14以降ではシステム設定からパスキーの保存先として1Passwordなどの外部のパスワードマネージャーをGoogleパスワードマネージャーの代わりに選択することもできる。
ブラウザの条件
ブラウザのバージョンの条件は以下になっている。
| ブラウザ | 最低バージョン |
|---|---|
| Google Chrome | 108 以降 |
| Safari | 16 以降 |
| Microsoft Edge | 108 以降 |
| Firefox | 122 以降 |
最近のブラウザは自動的にアップデートされるため、基本的には特に心配する必要はない。
ただし、数年前のスマホやPCをそのまま使い続けている場合、OSやブラウザのバージョンが条件を満たしていない可能性がある。
まずは自分のデバイスのOSバージョンを確認してみてほしい。
各サービスへのパスキー設定方法
パスキーの設定は各サービスのアカウント設定画面から行うのが基本だ。
大まかな流れとしては「アカウント設定→セキュリティ→パスキーを追加」という手順がほとんどのサービスで共通している。
ただし、サービスによって設定画面の場所や手順が異なるため、各サービス別の具体的な設定手順についてはそれぞれのサイトで確認してほしい。
パスキーへの移行を検討すべき人・まだ様子見でいい人
ここまでパスキーの仕組み・メリット・デメリット・安全性・対応状況を一通り解説してきた。
最後に「自分はパスキーを使うべきなのか」という問いに対して、率直にまとめておく。
パスキーへの移行を今すぐ検討すべき人
以下に当てはまる人は、パスキーへの移行を積極的に検討する価値がある。
オンラインバンキングや証券口座を使っている人
金融系サービスは最もフィッシング詐欺の標的になりやすい領域だ。
2025年初頭には国内の証券口座を狙ったサイバー攻撃が急増し、わずか4ヶ月で不正取引件数が39件から2,746件、不正取引総額が約1.5億円から約2,789億円にまで膨れ上がった。
SBI証券・楽天証券など対応サービスからパスキーを設定しておくだけで、このリスクを大幅に下げられる。
複数のサービスで同じパスワードを使い回している人
パスワードの使い回しは、ひとつのサービスで漏洩が起きた瞬間に複数のアカウントが芋づる式に危険にさらされる。
パスキーに移行することで、この連鎖リスクを根本から断ち切ることができる。
「パスワードを忘れた」が多い人
パスキーに移行すれば、パスワードを覚える必要も、再設定の手間も不要になる。
セキュリティを上げながら使い勝手も良くなるため、一石二鳥だ。
iPhoneまたはAndroidを日常的に使っており、OSが最低要件を満たしている人
パスキーの恩恵を最も受けやすいのはスマホユーザーだ。
設定さえ済ませれば、以降のログインは指紋・顔認証で完結する。
まだ様子見でもよい人
一方で、以下のような状況であれば、無理に急ぐ必要はない。
古いスマホやPCを使っており、OSが最低要件を満たしていない人
iOS 16未満、Android 9未満の端末ではパスキーを利用できない。
この場合はまずデバイスやOSのアップデートが先決だ。
利用しているサービスがまだパスキーに対応していない人
使っているサービスが非対応であれば、そもそも設定できない。
定期的に対応状況をチェックしつつ、対応が始まったタイミングで移行を検討すればよい。
共有端末をメインで使っている人
家族や職場で複数人が同じPCを使う環境は、パスキーの前提と合わない。
この場合はパスワードマネージャーで管理水準を上げる方向から始めるのが現実的だ。
移行前にやっておくべき3つのこと
パスキーへの移行を始める前に、以下の3点を済ませておくことを強く勧める。
連携先のアカウントのセキュリティを強化する
まず、AppleIDまたはGoogleアカウントのセキュリティを固めることだ。
パスキーはこれらのアカウントにクラウド同期されるため、ここが突破されると意味がなくなる。
強力なパスワードと二段階認証の設定は必須だ。
パスワードマネージャーの導入
次に、パスワードマネージャーを導入することだ。
パスキーへの完全移行には時間がかかるため、移行期間中はパスワード認証のサービスも混在する。
この期間を安全に乗り越えるには、パスワードの一元管理が不可欠だ。
代替手段の登録
そして、バックアップの認証手段を各サービスに登録しておくことだ。
パスキーのみに頼り切ると、端末の紛失時にアカウントにアクセスできなくなるリスクがある。
メールアドレスや電話番号による復旧手段が有効になっているかを事前に確認しておこう。
パスワードマネージャーとの併用が現実的な最善策
パスキーは非常に優れた認証手段だが、2026年現在はまだ過渡期だ。
すべてのサービスがパスキーに対応するまでには、まだ時間がかかる。
そこで現時点での現実的な最善策は、「対応サービスにはパスキーを設定し、非対応サービスはパスワードマネージャーで管理する」という二段構えの運用だ。
パスワードマネージャーはいくつかあるが、中でも1Passwordはこの運用に最も適したツールのひとつだ。
パスキーの保存・管理に対応しており、パスワード認証のサービスのIDとパスワードも一元管理できる。
つまり、パスキー対応・非対応を問わず、すべての認証情報を1Passwordひとつで管理できる体制を作ることができる。
移行期間中の「つなぎ」として使い始めても、パスキーへの移行が完了したあとも、認証情報の管理ツールとして長く活用できる。
セキュリティ対策の土台として、パスキーの導入と合わせて検討してほしい。
1Passwordは日本の上場企業「ソースネクスト」が運営するサイトから1Passwordの公式よりも15%以上安く購入できる
参考文献
- FIDO Alliance「Passkeys Overview」https://fidoalliance.org/passkeys/
- W3C「Web Authentication (WebAuthn) Level 3」https://www.w3.org/TR/webauthn-3/
- Google Developers「Android と Chrome でのパスキーのサポート」https://developers.google.com/identity/passkeys/supported-environments?hl=ja
- トレンドマイクロ「パスワード・パスキーの利用実態調査2026」https://www.trendmicro.com/ja_jp/about/newsroom/press-releases/2026/pr-20260324-01.html
- フィッシング対策協議会「フィッシングレポート2025」https://www.antiphishing.jp/report/phishing_report_2025.pdf
- CAPY「海外＆日本のパスキー導入事例39社まとめ」https://corp.capy.me/blog/passkey/2025/02/
- キヤノンITソリューションズ「AiTM攻撃の脅威と対策（2025年12月マルウェアレポート）」https://eset-info.canon-its.jp/malware_info/malware_topics/detail/malware2512.html
- CloudGate「証券口座を狙う最新サイバー攻撃とMFA必須化の波」https://www.cloudgate.jp/blog/2025/5/cyberattacks-on-securities-and-mfa-passkeys-phishing-resistant-future
- 崎村夏彦「ワンタイムパスワードでは防げない、リアルタイムフィッシングの脅威」https://www.sakimura.org/2025/06/7160/
- FIDOアライアンス「パスキー普及状況（マイナビニュース取材記事）」https://news.mynavi.jp/techplus/article/20241220-3089943/
