パスキー2026 - Apple/Google/Microsoft 3社同期で何が変わったか

2025年から2026年へ - 何が変わったか

パスキーは2025年に消費者向けで69%の保有率を達成し、認知フェーズを抜けました。関連：パスキー入門（2025版）で解説した通り、ユーザー体験と成功率の面では既に優位性が証明されていました。

しかし2026年第1四半期、FIDO Alliance State of Passkey 2026 Report が明らかにしたのは、エンタープライズ導入率が29%に達したという事実です。2025年通年で11%だった数字が、わずか3ヶ月で18ポイント増加しました。この変化を後押ししたのが、Apple iCloud Keychain、Google Password Manager、Windows Hello Credential Manager の3社間におけるsyncable credentialの段階的実装と、日本を含む規制環境の整備です。

本記事は2025年版の続編です。基礎的な仕組みや登録フローは前編を参照してください。ここでは「3社同期の現状」「エンタープライズ実装の実務」「日本事例」「残る課題」に絞って解説します。

3社間同期の実装状況

現状の互換性マトリクス（2026年4月）

凡例: ○ = 完全同期、△ = Hybrid Transport経由で認証可（ただし鍵自体は同期しない）

CTAP 2.2 Hybrid Transport v2 の仕組み

sequenceDiagram
 participant Browser as ブラウザ（Windows/Mac）
 participant QR as QRコード
 participant Phone as スマートフォン（iOS/Android）
 participant Server as Relying Party

 Browser->>Server: 認証リクエスト
 Server->>Browser: challenge返却
 Browser->>QR: QRコード表示（WebSocket URL含む）
 Phone->>QR: カメラでスキャン
 Phone->>Phone: ローカルパスキーで署名
 Phone->>Browser: Bluetooth LE経由で署名送信
 Browser->>Server: 署名検証
 Server->>Browser: 認証成功

この方式により、Windows PCでパスキー非対応でも、手元のiPhoneに保存されたパスキーで認証できます。ただしBluetooth LEが必要で、企業ネットワークではBluetooth無効化ポリシーがあると利用不可です。

WebAuthn Level 3 の新API

W3C WebAuthn Level 3（2026年1月勧告候補）では、開発者がsyncableとdevice-boundを明示的に選択できるようになりました。

// パスキー登録（syncable優先）
const credential = await navigator.credentials.create({
 publicKey: {
 challenge: challengeBuffer,
 rp: { name: "Example Corp", id: "example.com" },
 user: {
 id: userIdBuffer,
 name: "user@example.com",
 displayName: "User Name"
 },
 pubKeyCredParams: [
 { type: "public-key", alg: -7 } // ES256
 ],
 authenticatorSelection: {
 residentKey: "required",
 userVerification: "required",
 // Level 3 新オプション
 authenticatorAttachment: "cross-platform", // platform | cross-platform
 requireResidentKey: true,
 // syncable preference (proposal段階、一部ブラウザで実験実装)
 hints: ["client-device", "hybrid"]
 },
 // 同期可能な認証器を優先するヒント
 extensions: {
 credProps: true,
 largeBlob: { support: "preferred" } // 秘密メモの同期用
 },
 timeout: 60000
 }
});

console.log(credential.response.getPublicKey());
console.log(credential.response.getAuthenticatorData());
// Level 3 では getTransports() で "hybrid" が返る
console.log(credential.response.getTransports()); // ["internal", "hybrid"]

// 認証（既存パスキーの利用）
const assertion = await navigator.credentials.get({
 publicKey: {
 challenge: challengeBuffer,
 rpId: "example.com",
 userVerification: "required",
 // Level 3: 認証器の選択ヒント
 hints: ["hybrid"], // QRコード優先を示唆
 timeout: 60000
 }
});

// signature検証はサーバーサイドで実施
await fetch('/api/auth/verify', {
 method: 'POST',
 headers: { 'Content-Type': 'application/json' },
 body: JSON.stringify({
 id: assertion.id,
 rawId: bufferToBase64(assertion.rawId),
 type: assertion.type,
 response: {
 authenticatorData: bufferToBase64(assertion.response.authenticatorData),
 clientDataJSON: bufferToBase64(assertion.response.clientDataJSON),
 signature: bufferToBase64(assertion.response.signature),
 userHandle: bufferToBase64(assertion.response.userHandle)
 }
 })
});

エンタープライズでの導入実態

導入率の急拡大

FIDO Alliance State of Passkey 2026 Report（2026年3月発表）によると、次の変化が観測されました。

導入予定なしが55%から20%へ減少した背景には、NIST SP 800-63-4でのAAL2正式認定と、Microsoft Entra ID / Okta / Auth0 といったIdPの標準サポート拡充があります。

日本での実装事例

三菱UFJ銀行（2026年2月全面導入）

法人向けBizStationでパスキー認証を全面導入し、従来の電子証明書方式と併用可能にしました。導入後3ヶ月で利用率37%に到達し、ログイン時間が平均23秒から8秒に短縮されたと報告されています（同行プレスリリース、2026年4月）。

技術スタック:

• FIDO2サーバー: Yubico Validation Server on AWS
• IdP: 独自実装（Java + Spring Security）
• 対応デバイス: iOS 16.6以降、Android 14以降、Windows 11（Windows Hello）

復旧フロー:

• パスキー紛失時は支店窓口での本人確認後、SMSワンタイムパスワードで一時ログイン
• 再登録は管理画面から2要素（既存デバイス + SMS）で実施

NTTドコモ（2026年3月dアカウントへ段階導入）

既存の2段階認証（SMS OTP）との並行運用を開始。2026年夏までに全ユーザーへ段階的にパスキー登録を促進し、2027年春にSMS OTP廃止を予告しています（同社IR資料）。

移行戦略:

1. 新規登録時にパスキーを推奨（従来方式も選択可）
2. 既存ユーザーにログイン後バナーで移行を促進
3. 2026年12月以降、パスワードのみのログインを段階的に制限
4. 2027年3月にSMS OTP新規登録停止、既存利用者は2027年9月まで猶予

移行の実務課題

既存パスワードユーザーの段階的誘導

企業が直面する最大の課題は「パスワードに慣れたユーザーをどう移行させるか」です。強制移行は反発を招き、サポートコストが急増します。

// 段階的移行の実装例（Next.js + Auth.js）
import { useSession } from "next-auth/react";
import { useState, useEffect } from "react";

export function PasskeyMigrationBanner() {
 const { data: session } = useSession();
 const [dismissed, setDismissed] = useState(false);

 // パスキー未登録かつ過去30日でログイン5回以上のユーザーに表示
 useEffect(() => {
 const shouldShow =
 session?.user &&
 !session.user.hasPasskey &&
 session.user.loginCount > 5 &&
 !localStorage.getItem("passkey-banner-dismissed");

 if (!shouldShow) setDismissed(true);
 }, [session]);

 if (dismissed) return null;

 return (
 <div className="migration-banner">
 <p>
 <i className="fa-solid fa-shield-halved"></i>
 パスキーでログインが3倍速くなります。
 <a href="/settings/passkey">今すぐ設定</a>
 <button onClick={() => {
 localStorage.setItem("passkey-banner-dismissed", "true");
 setDismissed(true);
 }}>後で</button>
 </p>
 </div>
 );
}

アカウント復旧フロー

デバイス紛失時のアカウント復旧は、パスキー最大の運用課題です。syncableであれば他のデバイスでログイン可能ですが、全デバイスを紛失した場合の救済策が必要です。

復旧パターン比較

# サーバーサイド実装例: リカバリーコード生成（Python + Flask）
import secrets
import hashlib
from datetime import datetime, timedelta

def generate_recovery_codes(user_id: str, count: int = 8) -> list[str]:
 """
 パスキー登録時にリカバリーコードを生成。
 ユーザーには平文を1度だけ表示、DBにはハッシュを保存。
 """
 codes = []
 for _ in range(count):
 code = secrets.token_urlsafe(12) # 16文字のランダム文字列
 codes.append(code)
 # SHA-256ハッシュをDBに保存
 code_hash = hashlib.sha256(code.encode()).hexdigest()
 db.execute(
 "INSERT INTO recovery_codes (user_id, code_hash, created_at, used) VALUES (?, ?, ?, ?)",
 (user_id, code_hash, datetime.utcnow(), False)
 )
 return codes

def verify_recovery_code(user_id: str, code: str) -> bool:
 """
 リカバリーコードを検証。使用済みフラグを立てる（1回のみ有効）。
 """
 code_hash = hashlib.sha256(code.encode()).hexdigest()
 row = db.execute(
 "SELECT id FROM recovery_codes WHERE user_id = ? AND code_hash = ? AND used = FALSE",
 (user_id, code_hash)
 ).fetchone()

 if row:
 db.execute("UPDATE recovery_codes SET used = TRUE WHERE id = ?", (row["id"],))
 return True
 return False

共有デバイスでの利用

公共端末やキオスク端末では、パスキーをデバイスに保存すると次のユーザーが悪用できてしまいます。この場合はdevice-bound credentialではなく、Hybrid Transportで個人のスマートフォンを認証器として使う設計が必須です。

// 共有デバイス向け設定
const credential = await navigator.credentials.get({
 publicKey: {
 challenge: challengeBuffer,
 rpId: "library.example.com",
 userVerification: "required",
 // 共有端末ではhybridを強制
 hints: ["hybrid"],
 // platform（デバイス内蔵）を除外
 authenticatorSelection: {
 authenticatorAttachment: "cross-platform"
 }
 }
});

フィッシング耐性の現実的評価

パスキーは理論上フィッシングを技術的に防ぎます。公開鍵方式のため、偽サイトに秘密情報を入力する余地がないからです。

しかし実務では以下の攻撃が成立します。

リバースプロキシ型フィッシング（2026年で観測増加）

攻撃者が正規サイトとユーザーの間に透過プロキシを挟み、認証をリアルタイムで中継する手法。パスキーで認証しても、セッションCookieを攻撃者が窃取します。

正規の流れ:

ユーザー → example.com → パスキー認証 → Cookie発行

リバースプロキシ攻撃:

ユーザー → evil-proxy.com → example.com(プロキシ経由) → パスキー認証成功 → Cookieを攻撃者が取得 → セッション乗っ取り

対策:

• rpId（Relying Party ID）の厳格な検証。ブラウザは認証時にオリジンをチェックするため、evil-proxy.comからのリクエストはexample.comのパスキーで認証できません。ただしユーザーが新規登録を攻撃サイトで行ってしまった場合は無効です。
• セッションCookieにSameSite=LaxまたはStrictを設定し、クロスサイト送信を防ぐ。
• ログイン後にIPアドレス・User-Agentの急変を検知する異常検知システム。

ソーシャルエンジニアリング

「サポートセンターを装った電話でリカバリーコードを聞き出す」攻撃は、パスキー導入後も変わらず有効です。技術的対策ではなく、ユーザー教育と組織的対応が必要です。

開発者向け実装アップデート

Passkey Provider API（提案段階）

Apple、Googleが2026年第2四半期に発表予定のPasskey Provider APIは、サードパーティパスワードマネージャー（1Password、Bitwarden等）がOSレベルのパスキー登録・認証フローに統合される仕組みです。

// iOS Passkey Provider API（提案仕様）
import AuthenticationServices

class PasskeyProvider: ASCredentialProviderViewController {
 override func prepareCredentialList(for serviceIdentifiers: [ASCredentialServiceIdentifier]) {
 // 保存済みパスキーをリスト表示
 let passkeys = fetchPasskeys(for: serviceIdentifiers)
 // ユーザー選択画面を表示
 presentPasskeySelection(passkeys)
 }

 override func provideCredentialWithoutUserInteraction(for credentialIdentity: ASPasswordCredentialIdentity) {
 // 生体認証後、パスキーでアサーション生成
 let assertion = generateAssertion(for: credentialIdentity)
 extensionContext.completeRequest(withSelectedCredential: assertion)
 }
}

これにより、ユーザーは「iCloud Keychain」「Google Password Manager」「1Password」のいずれかを自由に選択できるようになります。

syncable / device-bound の選択基準

今後の展望

2026年下半期〜2027年の予測

1. エンタープライズ導入率50%突破（2027年Q2予測）: Microsoft Entra IDの全プラン標準対応と、NIST認定により、政府調達要件にパスキーが追加される見込み。
2. パスワード廃止宣言の増加: Dropbox、Slackが2027年Q1にパスワード認証の新規登録停止を予告。既存ユーザーは2027年末まで猶予。
3. FIDO2 CTAP 2.3のリリース: 複数デバイス間のシームレスな鍵同期プロトコルが標準化される予定（Apple/Google/Microsoftの共同提案）。
4. 日本の行政サービス対応: マイナポータルで2027年度中にパスキー対応が予定されています（デジタル庁ロードマップ）。

よくある誤解

Q1. パスキーがあればパスワードマネージャーは不要か?

A. 2026年時点では併用が現実的です。パスキー非対応サービスは依然として多く、レガシーシステムではパスワードが必須です。パスワードマネージャーはパスキーの保管場所としても機能するため、引き続き重要なツールです。

Q2. 3社のパスキーは完全に互換性があるか?

A. いいえ。同一プラットフォーム内（Apple製品間、Google製品間）では同期しますが、異なるプラットフォーム間では鍵自体は移動しません。Hybrid Transportで「スマホを認証器として使う」形での認証は可能です。

Q3. パスキーを全デバイスで紛失した場合、アカウントは復旧不可能か?

A. サービスごとの復旧フローに依存します。リカバリーコード、予備メール、SMS、支店窓口などの手段が用意されているかを登録時に確認してください。syncable passkeyを複数デバイスに登録しておくことが最も確実な対策です。

Q4. パスキーは量子コンピュータ耐性があるか?

A. 現行のパスキー（ES256アルゴリズム使用）は、大規模量子コンピュータが実現すれば破られる可能性があります。ただしFIDO AllianceはPost-Quantum Cryptography対応を2027年に仕様化予定であり、アルゴリズムの移行パスが設計されています。

Q5. 企業でパスキーを導入すると、パスワードポリシー（90日ごとの変更等）は不要になるか?

A. パスキーは秘密鍵がサーバーに送信されないため、漏洩によるリスクがありません。したがって定期的な「変更」は不要です。ただしデバイスの紛失・退職時には、該当パスキーを即座に無効化する運用が必要です。

まとめ

2026年のパスキーは、消費者向けでの普及を経て、エンタープライズ本格導入のフェーズに入りました。

• FIDO Alliance報告により、エンタープライズ導入率が29%に到達（2025年比+18ポイント）
• Apple/Google/Microsoftの3社同期は段階実装中だが、完全互換には制約あり。Hybrid Transportが現実解
• 日本でも金融・キャリア・行政で導入が加速。2027年にかけてSMS OTP廃止が進む見込み
• 実務上の課題はアカウント復旧フロー、共有デバイス対応、リバースプロキシ型フィッシング対策
• WebAuthn Level 3とPasskey Provider APIにより、開発者の実装選択肢が拡大
• パスキーはパスワードレスへの移行パスとして不可避なトレンドであり、2026年中のパイロット実施が推奨されます

パスキーは万能ではありません。しかし「パスワードよりも明確に優れている」ことは、2年間の実運用データで証明されました。残る課題は技術的というより、組織的な移行戦略とユーザー教育です。

参考リソース

• FIDO Alliance - State of Passkey 2026 Report - エンタープライズ導入率29%の一次データ
• W3C WebAuthn Level 3 Specification - syncable credential仕様
• Apple Developer - Passkeys - iCloud Keychainの実装ガイド
• Google Identity - Passkeys - Google Password Manager統合
• Microsoft Entra - Passkey Authentication - エンタープライズ向けパスキー導入ガイド
• JPCERT/CC - FIDO認証に関するセキュリティ考察 - 日本語での技術解説

×

PR

×

PR