プロンプトとスコープ
会社は書類による本人確認フローの一部を、ブラウザを介した Digital Credentials API に置き換えたいと考えています。導入の可否、提示から始めるか発行から始めるか、そして互換性とプライバシーのリスクをどのように管理するかをどう判断しますか？
面接官が評価するポイント
- ドラフト標準を完成されたネットワークとして扱うのではなく、API の機能、クレデンシャルエコシステム、ビジネス成果を切り分けて捉えられているか。
- 提示（Presentation）と発行（Issuance）のジャーニー、およびそれぞれの異なるパートナーやリスクを区別できているか。
- カバレッジ、完了率、手動審査コスト、不正損失、リカバリパスを定量化できているか。
- データ最小化、同意、代替手段、停止条件を意思決定に組み込めているか。
状況を明確にするための質問
- 目的はログイン、年齢確認、口座開設、それとも新しいクレデンシャルの発行ですか？
- ターゲットユーザーはどのウォレット、クレデンシャルフォーマット、デバイスを所有しており、カバレッジはどのように測定されますか？
- どのフィールドが必須で、どれを選択的開示や手動審査で代替できますか？
- 検証が失敗した場合、ウォレットが利用できない場合、あるいはクレデンシャルが期限切れや失効している場合、ユーザーはどのように手続きを継続できますか？
30秒の回答フレームワーク
すべての本人確認フローを置き換えるのではなく、高価値かつ損失リスクの低い提示ジャーニーを対象にした小規模なパイロットから開始します。API、手動、現行のパスを完了率、所要時間、コスト、不正発生率で比較しつつ、ウォレットとクレデンシャルのカバレッジを測定します。データの最小化、明示的な同意、相互運用性、およびフォールバックパスをローンチ条件（ゲート）とします。カバレッジ、プライバシー、運用の指標をクリアした後にのみ、発行やより広範な市場への展開を評価します。
ステップごとの詳細解説
1. プロダクトの境界を定義する
2026年6月1日付の W3C Working Draft は、デジタルクレデンシャルの提示および発行に関するユーザーエージェントの調停について規定しています。これはブラウザとクレデンシャルエコシステム間の調整レイヤーを定義するものであり、単一の汎用文書フォーマットやウォレットネットワーク、法的な本人確認の結論を提供するものではありません。プロダクトディスカバリーでは、「ブラウザがフローを開始できること」と「ビジネスがその結果を信頼できること」を切り離して検証する必要があります。
2. 提示と発行を分離する
提示はユーザーがすでに所持しているクレデンシャルを要求するものであり、そのリスクはウォレットの可用性、ユーザーの選択、開示されるフィールド、および検証に集中します。発行はさらに発行者の適格性、クレデンシャルフォーマット、キーバインディング、ライフサイクル、失効管理が必要となり、パートナーシップやコンプライアンスの業務が増加します。発行ネットワークの構築を同時に進めるのではなく、既存のクレデンシャルを活用する単一のシナリオから開始します。
3. 測定可能な意思決定ゲートを設定する
対照群を設定し、エンドツーエンドの完了率、P50/P95所要時間、検証あたりのコスト、手動対応への引き継ぎ、不正による否認、サポート件数を比較します。平均値によって格差が隠れないよう、デバイス、ウォレット、ブラウザ、ユーザーコホート別にセグメント化します。API の失敗、ユーザーによるキャンセル、期限切れ、失効を個別にカウントします。技術的な成功はビジネスの成功を意味しません。
4. プライバシー、信頼、フォールバックを設計する
目的に必要なフィールドのみを要求し、同意および目的通知の記録を保持し、ログ内のクレデンシャルデータを制限します。検証者はクライアントの出力を信頼するのではなく、発行者の信頼性、署名、有効性、失効状況を検証します。非対応デバイス、ウォレットによる拒否、ネットワーク障害が発生した場合は、既存の手動または書類ベースのパスを利用します。プライバシーインシデント、苦情、完了率に対する停止しきい値を設定し、重要なラインを超えた場合はパイロットを一時停止します。
高品質な回答サンプル
ブラウザが API を公開しているという理由だけで本人確認を置き換えることはしません。既存のクレデンシャルが利用でき、失敗時のコストが限定的な提示ジャーニーを選択し、ウォレットとブラウザのカバレッジを測定した上で、完了率、所要時間、コスト、手動引き継ぎ、不正について対照比較を実施します。提示と発行は別々の意思決定であり、発行には発行者の適格性、フォーマットの相互運用性、失効ライフサイクルの対応が追加されます。プロダクト側では必要なフィールドのみを要求して同意を記録し、サーバー側で発行者、署名、有効性、失効を検証します。非対応、キャンセル、期限切れのフローは既存のパスに戻します。カバレッジ、プライバシー、苦情の停止ラインをクリアした後に、市場の拡大や発行の検討を行います。
よくある間違い
- Working Draft を、すべての地域、ブラウザ、ウォレットでサポートされている汎用ネットワークであるかのように扱うこと。
- 提示と発行を混同し、発行者、フォーマット、失効に関するパートナーシップの負担を過小評価すること。
- 完了率、手動引き継ぎ、不正結果を見ずに、API コールの成功のみを測定すること。
- 生のクレデンシャルをログに記録したり、目的に無関係な個人情報フィールドを要求したりすること。
- 非 API のフォールバックを用意せず、非対応デバイスで口座開設ができなくなること。
- 対照群、市場セグメント、明確な停止ラインを設けずにパイロットを実施すること。
フォローアップの質問と回答
なぜ提示から始めるのですか？
既存のクレデンシャルとウォレットに依存するため、発行ネットワークの構築よりもスコープが小さくて済みます。個別の発行プロジェクトに着手する前に、ユーザー価値、カバレッジ、検証品質を検証できます。
カバレッジが十分であるとどのように判断しますか？
対象のデバイス、ブラウザ、ウォレット、ユーザーコホートをセグメント化し、単一の互換性テーブルではなく実際のファネルデータから最低完了率を定義します。カバレッジの低いユーザーに対しても、同等の代替手段を確保する必要があります。
どのような場合にパイロットを停止すべきですか？
完了率、プライバシーインシデント、苦情、不正損失、手動コストに対するしきい値をあらかじめ定義しておきます。重要な指標がラインを超えた場合は、トラフィックの追加を停止し、監査証跡を保持した上で、修正するか中止するかを判断します。