「FIDO2」という言葉は広く知られるようになりましたが、FIDO2が実際には2つの規格の組み合わせであることは、あまり知られていません。一つはWebAuthn（W3Cが策定するブラウザ標準API）、もう一つが本記事で解説するCTAP2（Client to Authenticator Protocol 2）です。CTAP2は、ブラウザやOSと、セキュリティキーや生体認証デバイスといった「認証器」との間の通信を規定するプロトコルであり、FIDO2の「裏側」で実際の暗号処理と認証器操作を支えています。本記事では、CTAP2の仕組みを技術的な視点から解説します。
1. FIDO2とCTAP2の関係——なぜ2つの規格があるのか
FIDOアライアンスとW3Cが共同で策定したFIDO2は、意図的に2つのレイヤーに分割されています。
| 規格 | 策定団体 | 役割 | 通信区間 |
|---|---|---|---|
| WebAuthn | W3C | Webアプリ（Relying Party）とブラウザ間のAPI仕様 | Webサイト ⇔ ブラウザ |
| CTAP2 | FIDOアライアンス | ブラウザ／OS（クライアント）と認証器間の通信プロトコル | ブラウザ ⇔ 認証器（セキュリティキー等） |
この分離には明確な理由があります。WebAuthnはあくまで「Webアプリがブラウザに何を要求するか」を定めるAPIであり、認証器がどのようなハードウェアで、どう鍵を保管し、どう本人確認するかには関知しません。一方CTAP2は、認証器の種類（USBキー・スマートフォンの生体認証・PCのTPM等）を問わず共通のコマンド体系で操作できるようにする「認証器との対話規約」です。この分離により、ブラウザベンダーは個々の認証器メーカーの実装を意識せずWebAuthnを実装でき、認証器メーカーもブラウザの種類を問わずCTAP2準拠のデバイスを作れます。
2. CTAP2の基本的な通信フロー
CTAP2は、大きく分けて「登録（Registration）」と「認証（Authentication）」の2つのコマンドを中心に設計されています。
authenticatorMakeCredential（登録）
ユーザーが新しいサービスにパスキーを登録する際、ブラウザは認証器に対してauthenticatorMakeCredentialコマンドを送信します。認証器はこのリクエストを受け取ると、内部で公開鍵・秘密鍵のペアを生成します。秘密鍵は認証器の外に一切出ることなく、セキュアな領域（TPM・Secure Enclave・セキュリティキー内のセキュアエレメント）に保管されます。生成された公開鍵と、その鍵を識別するためのCredential IDが、ブラウザを経由してWebサイト側のサーバー（Relying Party）に送信され、以降の認証に使われます。
authenticatorGetAssertion（認証）
次回以降のログイン時には、authenticatorGetAssertionコマンドが使われます。Webサイトが送信した「チャレンジ」と呼ばれるランダムな値に対し、認証器は保管している秘密鍵で署名を行い、その署名結果（アサーション）をブラウザ経由でWebサイトに返します。Webサイトは事前に登録された公開鍵で署名を検証し、正当な秘密鍵の保持者からのアクセスであることを確認します。秘密鍵そのものはネットワーク上を一度も流れないため、通信を傍受されても認証情報は窃取できません。
ユーザー検証（User Verification）
これらのコマンド実行前には、多くの場合「ユーザー検証（User Verification）」が要求されます。これはPIN入力・指紋・顔認証など、認証器がその場に本人がいることを確認する処理です。CTAP2は、このユーザー検証が行われたかどうかを示すフラグをアサーションに含めることで、Webサイト側が「デバイスの所持」だけでなく「本人によるその場での操作」まで確認できるようにしています。
Keyper：FIDO2/CTAP2準拠のID・アクセス管理製品
Net PeaceのKeyperは、CTAP2準拠のセキュリティキーやプラットフォーム認証器を活用したパスワードレス認証基盤です。標準プロトコルに準拠しているため、特定ベンダーのハードウェアに縛られず導入できます。
3. CTAP1（U2F）との違い
CTAP2は、その前身であるCTAP1（U2F：Universal 2nd Factor）を拡張する形で設計されました。両者の違いを理解すると、FIDO2が「二要素認証の補助」から「パスワードレスの主役」へと進化した理由が見えてきます。
| 項目 | CTAP1（U2F） | CTAP2 |
|---|---|---|
| 想定用途 | パスワード＋αの「第2要素」専用 | 単独での本人認証（パスワードレス）に対応 |
| 資格情報の保管 | サーバー側で管理するKey Handle方式が主 | 認証器側に「発見可能な資格情報」を保管可能（Resident Key） |
| ユーザー検証 | タップ（所持確認）のみが基本 | PIN・生体認証によるユーザー検証に対応 |
| ユーザー識別 | ユーザー名の事前入力が必須 | 認証器側がユーザーを特定できるため、ユーザー名入力を省略可能 |
CTAP1時代の最大の制約は「認証器はユーザーが誰かを知らない」ことでした。ユーザーはまずユーザー名（場合によってはパスワードも）を入力し、その後にセキュリティキーでの二要素目の確認を行う、という流れが必須でした。CTAP2で導入された「Resident Key（発見可能な資格情報）」により、認証器自身がどのアカウントの鍵を持っているかを把握できるようになり、ユーザー名の入力すら不要な「パスキー」体験が実現しました。
4. 認証器とプラットフォームの役割分担
CTAP2における「認証器（Authenticator）」は、大きく2種類に分類されます。
ローミング認証器（Roaming Authenticator）
USBセキュリティキーのように、複数のデバイス間で持ち運んで使える認証器です。CTAP2は、USB・NFC・Bluetooth Low Energy（BLE）の3つのトランスポートを規定しており、ローミング認証器はこれらのいずれかで「クライアント（プラットフォーム）」と通信します。
プラットフォーム認証器（Platform Authenticator）
スマートフォンの指紋・顔認証センサーや、PCのWindows Hello・TPM、MacのSecure Enclave・Touch IDなど、デバイスに内蔵された認証器です。この場合CTAP2の通信は、OS内部のセキュアな通信路（プラットフォーム固有のAPI）を介して行われ、ユーザーからは意識されません。
この2分類により、企業は「全社員に外付けのセキュリティキーを配布する」方式と、「社員が既に持っているスマートフォンやPCの内蔵認証器を使う」方式のどちらか、あるいは両方を組み合わせて導入できます。
5. トランスポート方式：USB・NFC・Bluetooth
ローミング認証器がクライアントと通信する方式（トランスポート）には、それぞれ異なる特性があります。
| トランスポート | 特徴 | 主な利用シーン |
|---|---|---|
| USB HID | 物理接続。最も安定・確実。ドライバ不要で多くのOSが標準対応 | PCでの業務利用、共有端末での認証 |
| NFC | 近接タッチで通信。スマートフォンとの相性が良い | スマートフォンでのログイン、入退室と兼用のICカード型認証器 |
| Bluetooth Low Energy（BLE） | 無線接続。USBポートのないデバイスでも利用可能だがペアリングの手間がある | タブレット・USBポート非搭載端末での利用 |
| hybrid（旧caBLE） | QRコード＋BLEでスマートフォンを別デバイスの認証器として使う | PCでのログイン時にスマホのパスキーを使う「クロスデバイス認証」 |
特に「hybrid」トランスポート（クロスデバイス認証）は、企業導入において実務上の柔軟性を大きく高めます。社員が専用のセキュリティキーを持っていなくても、既に登録済みのスマートフォンをQRコード経由で「その場限りの認証器」として使い、PCへのログインを完結できるためです。
6. CTAP2.1で追加された主な機能
CTAP2は継続的に改訂されており、最新のCTAP2.1では企業導入を後押しする機能が追加されています。
- Enterprise Attestation：企業が管理するデバイス群であることを、認証器の個体識別情報も含めて厳格に検証できる仕組み。社給デバイス以外からのアクセスを技術的に制限したい場合に有効。
- Credential Management：認証器に保管された資格情報（どのサービスの鍵が何個入っているか）を一覧・削除できる標準コマンド。デバイス紛失時の棚卸しや、退職時の資格情報整理に活用できる。
- alwaysUv（常時ユーザー検証）：認証器側で「ユーザー検証を常に必須とする」設定を強制できるオプション。PINなしのタップのみでの認証を許可しない、より厳格なポリシー運用が可能になる。
- minPinLength：認証器のPINの最小文字数をRelying Party側が指定できる拡張。組織のパスワードポリシーに準じたPIN強度を要求できる。
企業導入で押さえておきたいポイント
- 導入する認証器（セキュリティキー・スマートフォン等）がCTAP2.1に対応しているかは、ベンダーの仕様書で確認する
- Credential Management機能を使えば、情シス部門は退職者のデバイスに残る資格情報の棚卸しを効率化できる
- Enterprise Attestationは、BYOD環境では使いにくいため、社給デバイスを前提とした運用で有効性が高い
よくある質問
Q1: CTAP2とWebAuthnは、どちらか片方だけ導入することはできますか？
いいえ、実務上は両方がセットで機能します。WebAuthnはブラウザとWebアプリ間のAPIであり、CTAP2はブラウザと認証器間のプロトコルです。ブラウザがWebAuthn APIの呼び出しを受けると、内部でCTAP2を使って認証器と通信します。企業やサービス提供者が意識するのは主にWebAuthn API側ですが、その裏側でCTAP2が動いていることを理解しておくと、認証器選定やトラブルシューティングの際に役立ちます。
Q2: 古いセキュリティキー（CTAP1のみ対応）はパスキーとして使えますか？
CTAP1のみに対応したセキュリティキーは、二要素認証の第2要素としては引き続き利用できますが、ユーザー名入力を省略できる「発見可能な資格情報（Resident Key）」を必要とするパスキー機能には対応していません。パスキーとしての体験を実現するには、CTAP2対応の認証器への切り替えが必要です。
Q3: CTAP2の通信内容は暗号化されていますか？
USB HIDやNFCなど物理的に近接した通信路が前提のため、通信路自体の暗号化よりも、公開鍵暗号方式による署名検証で安全性を担保する設計です。秘密鍵は認証器の外に一切出ず、通信で送受信されるのは公開鍵や署名済みデータのみであるため、通信内容を傍受されても秘密鍵が漏洩することはありません。
Q4: 自社システムでCTAP2を意識した実装が必要になる場面はありますか？
一般的なWeb・業務システムの開発では、ブラウザのWebAuthn APIを呼び出すだけでよく、CTAP2レベルの実装を意識する必要はほとんどありません。ただし、独自の認証器を開発する場合や、認証器の管理機能（Credential Management等）を活用した情シス向け運用ツールを構築する場合には、CTAP2の仕様理解が必要になります。
7. まとめ
CTAP2は、FIDO2認証の「エンジン」にあたるプロトコルです。本記事の内容を振り返ります。
- FIDO2は、W3Cが策定するWebAuthn（Webサイト⇔ブラウザ）と、FIDOアライアンスが策定するCTAP2（ブラウザ⇔認証器）の2つの規格の組み合わせ
- CTAP2は
authenticatorMakeCredential（登録）とauthenticatorGetAssertion（認証）を中心に、秘密鍵を認証器の外に出さない設計で安全性を担保する - CTAP1（U2F）との最大の違いは「発見可能な資格情報（Resident Key）」の対応で、これによりユーザー名入力不要のパスキー体験が実現した
- 認証器はローミング型（USB/NFC/BLE）とプラットフォーム型（内蔵）に大別され、企業は自社の運用に応じて選択・併用できる
- CTAP2.1のEnterprise AttestationやCredential Managementは、企業のデバイス管理・退職者対応を効率化する機能として注目に値する
プロトコルの詳細を意識せずとも、標準に準拠した認証器・製品を選ぶことで、企業はFIDO2/パスキーの恩恵をそのまま享受できます。KeyperはCTAP2/WebAuthn標準に準拠したパスワードレス認証基盤として、自社開発の独自方式に依存しない、長期的に安心できる認証基盤を提供します。