2026年8月以降に新規接続を始めるアプリは、新形式の protocol と data を読み取る実装にしてください。今週は、既存コードがトップレベルの vp_token だけを探していないか確認し、移行中のアプリでは新旧両方の応答を検証します。クライアントで値を解析できても、資格情報の検証が完了したとは限りません。Android公式実装ガイドでは、アカウント作成やログインの前にサーバー側で検証するよう示されています。
Androidアプリの登録やログインにCredential Managerを組み込み、応答の形式変更後にメール資格情報を読めなくなった開発者向けです。
既存連携の移行方法を検討する技術責任者や、資格情報が使えない場合のメールコードへの回退を確認するQAにも役立ちます。
最終更新：2026年10月28日。応答形式、移行時の扱い、サーバー検証の説明はAndroid Developersの実装ガイドとメール認証の概要を確認しています。実装の詳細や移行案内が更新された場合は、公開時点の公式情報を優先してください。
解析失敗は、資格情報の欠如より先に応答形式を疑います
新形式では、応答に protocol と data が含まれ、OpenID4VPの vp_token は data 内に置かれます。そのため、旧実装が応答直下から vp_token を取得しようとすると、利用可能な資格情報が返っていても、値を見つけられないことがあります。まず実際の応答構造と接続時期を確認し、読み取り位置のずれなのか、資格情報が利用できなかったのかを切り分けます。
ここで重要なのは、値が見つからないというクライアント側の結果だけで「メール資格情報がない」と決めないことです。ログに残す際は、メールアドレスやトークンの実値を除き、キーの階層とサーバーでの検証結果を分けて記録してください。テストデータに個人情報を持ち込まない方針は、テストデータの取り扱いにも沿って整理できます。
新形式の vp_token はどこから読み取りますか？
トップレベルではなく、公式例に沿って data の内容を解析し、その中の vp_token を読み取ります。構造を示すと、確認すべき階層は次のようになります。値は説明用のプレースホルダーであり、実際の形式は公式の応答例を参照してください。
{
"protocol": "...",
"data": {
"vp_token": "..."
}
}
実装では、受け取った応答を想定した型へ変換し、protocol と data の存在、data 内の vp_token の有無を個別に扱います。data の内容や型を未確認のまま固定的に変換すると、欠落・型違い・想定外のプロトコルを同じ解析エラーとして処理してしまいます。Androidの実装ガイドにある応答例と実データを照合し、アプリ内でどの階層を読むかを明示してください。
旧コードが vp_token を読めない理由は何ですか？
旧コードが応答直下のフィールドだけを調べていると、新形式では値の格納先が異なるためです。これは「資格情報が発行されなかった」とは別の問題です。Credential Managerから実際に返された応答を、機密値を伏せた状態で確認し、旧形式を前提としたパーサーの参照先を見直します。
接続の時期による判定は、次の比較で整理できます。
| 実装状況 | 確認する応答 | 対応方針 | 判定 |
|---|---|---|---|
| 2026年8月以降に新規接続 | protocol と data を含む新形式 |
新形式に沿って解析する | 推奨 |
| 既存連携の移行期間 | 実環境で返る新旧両方の形式 | 公式の移行案内に沿って互換処理を設ける | 条件付き |
| どちらの形式か未確認 | 実際の応答と接続時期 | ログの構造を調べてから分岐を決める | 先に調査 |
新規接続で旧形式だけを実装するのは避けます。既存連携では、互換処理を無期限に残す前提にせず、公式の移行説明を確認して対象範囲と削除条件を決めてください。対応バージョンや旧形式の終了時期はここで推測せず、公開時点のAndroid公式案内で確認します。
クライアントで解析した後、サーバーは何を検証しますか？
クライアントが vp_token を読み取ったことは、資格情報の真正性を証明しません。アカウント作成やログインを許可する前に、サーバー側で署名、発行者、保持者との結び付け、要求時に使った元のnonceを検証します。具体的な処理は、OpenID4VP仕様とAndroidのデジタル資格情報に関する安全性の説明に照らして設計してください。
回帰確認では、アプリが読み取ったフィールドと、サーバーが受理・拒否した理由を対応付けます。資格情報データの形式だけでなく、検証対象となるデータの意味や制約については、W3Cの可検証資格情報データモデルも参照できます。
メールコードへの回退を含めた回帰確認
資格情報が端末で利用できない場合、応答が想定外の場合、またはサーバー検証に失敗した場合に、自社アプリがどの代替手段を提示するかを確認します。メールコードへの回退を用意する場合は、メールの送信、テスト用受信先での受信、アプリ側でのコード検証を別々の確認点にします。メールが受信できたことだけでは、Digital Credentials APIの資格情報が有効だとは判断できません。
自社アプリまたは許可を得た環境で、次の順に試すと問題の位置を絞りやすくなります。
- 実際に返った応答を機密値なしで保存し、新旧どちらの構造か確認します。
- 新形式で
protocolとdataが読めることを確認し、data内のvp_tokenの参照経路を検証します。 dataやvp_tokenが欠ける応答、型が想定と異なる応答、未対応の構造を与え、アプリが安全に処理するか確認します。- 既存連携では新旧形式それぞれの処理結果を記録し、移行分岐が意図どおり動くか確かめます。
- サーバーで署名、発行者、保持者との結び付け、元のnonceを検証し、受理と拒否の結果を確認します。
- 資格情報が使えないケースからメールコードへ回退し、送信・受信・アプリ内照合の状態を個別に記録します。
受信確認では、使い捨ての受信先をテストの補助に使えます。ただし、受信できたことが示すのはメール回退経路の一部だけです。FwdQuickの一時受信先を回退メールの確認に使う場合も、資格情報の真正性やサーバー検証の成否とは切り離して扱ってください。受信先を分けてテストデータを管理する方法は、FwdQuickの案内から確認できます。