Passkey B2B 元年: コンシューマーからエンタープライズへ
- 〜2024 年に Apple・Google・Microsoft が揃って推進した Passkey は当初コンシューマー向け認証手段として広まった。しかし 2025 年後半から B2B 採用が急速に進み、2026 年は「Passkey B2B 展開元年」と呼べる状況になっている。Okta・Entra ID・Google Workspace・1Password Business のいずれもが Cross-Device Passkey と同期 Passkey を両方サポートし、FIDO2 準拠のセキュリティキー（YubiKey 5C・Google Titan）と併存運用できる設計に成熟した。
B2B で Passkey が本格導入される最大の理由はフィッシング耐性だ。2024〜2025 年、日本企業を標的にした AiTM（Adversary-in-the-Middle）フィッシングキットが急増した。従来の TOTP や SMS OTP は中間者プロキシ経由で認証セッションを奪取する攻撃に脆弱で、国内大手 SaaS で数千アカウントが一夜で侵害される事件が複数発生した。Passkey（WebAuthn）はドメインバインディングによりフィッシングサイトでは署名が成立しないため、AiTM に対して構造的に耐性を持つ。「運用で気をつける」ではなく「プロトコルで担保される」点が経営判断の根拠になった。
同期 Passkey（iCloud Keychain・Google Password Manager 経由）とデバイスバインド Passkey（YubiKey 等に閉じる）のトレードオフは継続論点だ。金融・防衛系はデバイスバインドを好み、広範な社員展開には同期 Passkey が現実的だ。NIST SP 800-63B の 2025 年改訂で同期 Passkey が AAL2 として認められたことは、ポリシー策定の追い風になっている。
WebAuthn 実装の落とし穴とアカウント復旧
最初にハマるのは RP ID（Relying Party ID）の設計だ。RP ID はドメイン単位のため `corp.example.jp` と `portal.example.jp` で別の Passkey 登録が必要になる。統合したい場合は親ドメイン `example.jp` を RP ID にする必要があるが、親ドメインをマーケティングサイトと共有する組織では影響を慎重に評価しなければならない。
アカウント復旧は Passkey 運用最大の難所だ。復旧設計を怠るとバックアップ手段として弱い認証（メール OTP・SMS OTP）が温存され、セキュリティ強度は残存バックアップに引き下げられる。推奨は3層設計だ。軽度復旧（別端末からの再ログイン）は同期 Passkey で自動解決、中度復旧（全端末紛失）は管理者承認＋本人確認書類、重度復旧（ID 改竄の疑い）はオフライン本人確認必須。重度復旧を CS 経由にしないことも重要で、CS のソーシャルエンジニアリング突破が 2024 年に実際発生している。
SCIM とプロビジョニング自動化
SCIM 2.0 による自動プロビジョニングはもはや選択肢ではなく前提条件だ。IdP から各 SaaS へ SCIM 同期することで、ユーザー追加・属性更新・無効化がリアルタイムで伝播する。主要 SaaS（Salesforce・Slack・Notion・GitHub Enterprise・Atlassian）は SCIM 2.0 を標準提供し、受信側の実装品質も 2024 年比で大幅向上した。
SCIM 運用で見落とされがちなのは属性マッピング設計だ。IdP 側の部署・職位・雇用区分を SaaS 側のグループや権限ロールにマッピングする表を、HR と情シスが共同で維持できる形にする。Okta Workflows、Entra Lifecycle Workflows にはノーコード UI があり、IF 文チェーンで表現する方式が主流だ。スクリプト依存の属性変換は半年後の変更に追随できなくなる典型パターンになる。CSV 日次同期からの脱却計画は、2026 年の内部監査で提示を求められるケースが増えている。
SAML から OIDC へ: なぜ今か
SAML は B2B SSO の長年の標準だったが、2026 年時点で新規プロジェクトは OIDC が第一選択肢になっている。理由は3つ。第一にモバイル・SPA 対応で、SAML の XML リダイレクトは PKCE を用いる OIDC と比較してモバイルネイティブで煩雑だ。第二に署名・暗号化の複雑性で、SAML は XML Signature 仕様が広く、実装差異による脆弱性（XML Signature Wrapping 攻撃など）が歴史的に頻発した。第三に認証（ID Token）と API 認可（Access Token）を構造的に分離できるため、マイクロサービス環境での権限設計が明快になる。
ただし SAML 全廃は現実的でない。SAP SuccessFactors、Workday、Oracle Cloud の一部は SAML が唯一の SSO だ。移行戦略は「新規は OIDC、既存 SAML は当面維持、IdP を両対応基盤に集約」となる。移行でハマるのは「属性マッピング差異」で、長年 SAML 運用で作り込んだ Assertion 変換ロジックを OIDC claim 設計に引き継ぐ際に、グループ名衝突やロールスコープの食い違いが頻発する。移行前に「現状 SAML Assertion 全属性を列挙し、OIDC 標準 claim + カスタム claim への写像表を作る」工程を必ず挟むこと。
Adaptive MFA と step-up 認証
Adaptive MFA はリクエスト文脈に応じて認証強度を動的に調整する仕組みだ。通常は Passkey のみで通すが、未知デバイスから、深夜に、初めての国から接続された場合のみ追加認証を要求する、といった条件分岐で運用する。step-up 認証はそのサブセットで、「給与データ閲覧」「本番デプロイ」「顧客データ一括エクスポート」など高リスク操作の直前に現在のセッション認証強度を再評価し、不足なら追加認証を要求する。OIDC の acr（Authentication Context Class Reference）claim で「この操作には acr=phr（phishing-resistant）が必要」と宣言する方式が標準だ。
設計で最も難しいのは「誤検知の許容値」である。厳しすぎれば業務が止まり、緩めれば侵害が見逃される。筆者の経験則では「既知デバイス＋既知地理では Passkey のみ」「未知デバイスでは Passkey ＋ step-up」から始め、インシデント履歴と偽陽性率を月次レビューで調整する。
日本企業特有の衝突: 個人番号と共有アカウント
日本企業で Passkey・SCIM・OIDC を推進する際、海外ベンダー文書にない文化的衝突が立ち上がる。第一に「社員番号と個人番号（マイナンバー）の扱い」。個人番号は番号法により利用目的が厳格に限定され、IdP の sub claim や SCIM の externalId に個人番号を入れてはならない。しかし現場では社員番号と個人番号を紐付けた基幹システムが残り、SCIM 同期設計で個人番号を誤って外部 SaaS に流すインシデントが発生している。属性マッピング表には「外部流出禁止属性」のチェックリストが必須だ。
第二に「共有アカウント文化」との衝突だ。日本の中小〜中堅企業では `soumu@`、`keiri@` のような役職付き共有アカウントが残る。Passkey は個人の認証器に紐づくため、共有アカウントに Passkey を設定すると「誰がログインしたか」が辿れなくなる。移行戦略は、共有アカウントを機能アカウント（Service Account）と個人アカウントに分離し、業務メール受信は機能アカウント、ログインは個人アカウントで行う設計に再編することだ。監査ログの可逆性を優先すれば共有ログイン自体を全廃するしかない。第三に「会社貸与端末と BYOD の混在」で、管理対象端末のみ同期 Passkey、BYOD はハードウェアキー必須とする二層運用が現実的だ。
移行ロードマップ
- 〜18 ヶ月のロードマップを示す。第1段階（0〜3ヶ月）で IdP 基盤整備・SAML/OIDC 両対応・SCIM 受信対応 SaaS の棚卸し。第2段階（3〜6ヶ月）で Passkey パイロット展開・Adaptive MFA 初期ポリシー・SCIM 自動化の優先 SaaS 10 本。第3段階（6〜12ヶ月）で全社 Passkey 展開・TOTP/SMS OTP 段階的廃止・step-up のアプリ組み込み。第4段階（12〜18ヶ月）で SAML 新規禁止・レガシー SAML の OIDC 移行または撤退判断・共有アカウント全廃。経営層への説明は「AiTM 想定損害額」と「監査対応工数削減」の2軸が効く。IdP を中軸に HR・ZTNA・SaaS 群を統合するアイデンティティ運用基盤は、プロジェクト単位ではなく組織の恒常的ケイパビリティに格上げされつつある。