Chrome Developers が Modernize authentication with passkeys, digital credentials, and more（2026-05-21）で、Web の Digital Credentials API の進展を解説しました。要点は、ユーザーのスマホのデジタルウォレットに入った身分証（モバイル運転免許証 mDL / ISO 18013-5、各種デジタル ID）から、必要な属性だけをブラウザ経由で安全に受け取れることです。たとえば「18歳以上である」という事実だけを受け取り、生年月日や氏名そのものは渡さない——これが選択的開示（selective disclosure）／データ最小化です。実装は navigator.credentials.get() にデジタルクレデンシャルのリクエストを渡す形になります。ここで重要なのは、これはパスキー（パスワードレス認証＝ログイン）とは別物だという点です。パスキーが「あなたが誰としてログインするか」を扱う認証であるのに対し、Digital Credentials は「あなたが○○という属性を満たすか」を示す属性の提示・本人確認です。両者を混同したまま設計すると要件を取り違えます。
受託システム開発の現場では、年齢確認・本人確認（KYC）を 「身分証画像をアップロードさせて目視」「脆弱な自前フォームで生年月日を入力」 で済ませ、結果として過剰な個人情報を保持してリスクを抱える事故が繰り返されてきました。受託で Web 制作・システム開発を支える立場では、これは 「必要な属性だけを受け取り、保持しない。安全・低摩擦・法対応した本人確認を設計して引き渡せるか」 という設計課題だと捉えています。ログイン認証側は パスキーでパスワードレス認証へ移行（GH Media） で、セッション・トークンの取り扱いは Web認証・セッション管理のセキュリティ監査（GH Media） で扱いました。本記事では属性提示の側を、「デジタル本人確認・年齢確認 実装支援」という受託パッケージとして整理します。なお本人確認・年齢確認は業種ごとに法令要件が異なるため、実装前の法務確認が前提であることを最初に添えておきます。
なぜ「いま」本人確認を作り直すのか
| 観点 | 書類アップロード / 自前フォーム（従来） | Digital Credentials API（2026） |
|---|---|---|
| 安全性 | 偽造画像・なりすましに弱い | ウォレット署名で検証可能 |
| 摩擦 | 撮影・アップロード・待ち時間 | タップで属性提示、低摩擦 |
| 取得データ | 身分証まるごと取得しがち | 必要な属性だけ（例: 18歳以上） |
| 保持データ | 過剰に保持し漏洩リスク化 | 保持しない設計が可能 |
| 法対応 | 保持＝管理責任が重い | データ最小化で責任を圧縮 |
| 成果 | 個人情報を抱え込む | 必要最小限で確認が完結 |
つまり 「本人確認できる」ことと「個人情報を抱えずに本人確認できる」ことは別物であり、受託でも 「必要な属性だけを受け取り、保持せず、対応端末がない利用者にもフォールバック導線を用意した状態で引き渡す」 ことが品質の前提になりました。これにより 「過剰な個人情報を持たない本人確認」を成果物として保証できます。
Digital Credentials API でできること
① 選択的開示（必要な属性だけ＝データ最小化）
最大の価値は 「氏名・生年月日・住所をまるごと渡さず、判定に必要な属性だけを提示できる」 ことです。年齢確認なら「18歳以上か」という真偽値に近い形で受け取れるため、過剰な個人情報を取得・保持しなくて済みます。受託では 「この機能に本当に必要な属性は何か」を要件段階で削り込み、取得範囲を最小化します。
② mDL / デジタルウォレットからの提示フロー
ユーザーのスマホには mDL（モバイル運転免許証 / ISO 18013-5）や各種デジタル ID がウォレットとして入りつつあります。サイト側が要求した属性に対し、ユーザーが自分の意思で提示を承認し、ウォレットが署名付きで応答します。サーバはその署名を検証して真正性を確認します。
③ 年齢確認 / KYC への適用
最小の呼び出しは次のような形になります。navigator.credentials.get() にデジタルクレデンシャルのリクエストを渡し、返ってきた応答をサーバ側で検証します。
// ブラウザ側: 必要な属性だけを要求する（例: 18歳以上であること）
const credential = await navigator.credentials.get({
digital: {
requests: [{
protocol: 'openid4vp',
data: {
// 「18歳以上か」という属性のみを要求（生年月日そのものは要求しない）
// 実フィールド名・プロトコルはウォレット/規格に合わせて定義する
},
}],
},
});
// 受け取った応答はそのまま信用せず、サーバ側で署名・有効性を検証する
await fetch('/api/verify-credential', {
method: 'POST',
body: JSON.stringify({ response: credential.data }),
});応答をフロントだけで信用しないことが肝です。検証はサーバ側で行い、結果（「確認済み」というフラグ）だけを保持し、属性そのものは保持しない設計にします。Web セキュリティの土台は Webセキュリティの基礎（GH Media） も併読してください。
受託で提供する「デジタル本人確認・年齢確認 実装支援」5 フェーズ
フェーズ 1: 要件・法務確認（1 週間）
- 確認の目的（年齢確認 / KYC / 資格確認）の明確化
- 本当に必要な属性の絞り込み（取得範囲の最小化）
- 業種別の法令・ガイドライン確認（要法務レビュー）
- 対応端末がない利用者向けフォールバック方針の決定
フェーズ 2: 設計（1 週間）
- 提示フローと属性スキーマの設計
- 保持する／しないデータの線引き（データ最小化の設計）
- サーバ側検証ロジック・署名検証の設計
- フォールバック導線（書類提出等）の設計
フェーズ 3: 実装（1〜3 週間）
navigator.credentials.get()を用いた提示フローの実装- サーバ側での署名・有効性検証の実装
- 確認結果フラグのみを保存するデータモデル実装
- フォールバック導線の実装
フェーズ 4: セキュリティ検証（1 週間）
- 改ざん・リプレイ・なりすましの観点でのテスト
- 過剰なデータを保持していないかの監査
- 監査ログ・同意取得の確認
- 端末・ウォレット別の互換性確認
フェーズ 5: 運用引き渡し（1 週間＋継続）
- 運用手順書・データ保持方針の引き渡し
- 法令改定・規格更新の監視体制
- 障害時・非対応端末時の運用フロー整備
受託向け実装・セキュリティ標準セット
| 観点 | 推奨 | 避ける |
|---|---|---|
| 取得属性 | 判定に必要な属性だけ要求 | 身分証をまるごと取得 |
| データ保持 | 確認済みフラグのみ保持 | 属性・画像を長期保存 |
| 検証 | サーバ側で署名・有効性検証 | フロントの応答を鵜呑み |
| 同意 | 提示前に目的を明示 | 黙示的に属性収集 |
| フォールバック | 非対応端末に代替導線 | 対応端末のみ前提 |
| 監査ログ | 確認結果のみ記録 | 属性そのものをログに残す |
どの案件に必要か / 不要か
| 必要な案件 | 優先度が低い案件 |
|---|---|
| EC（年齢制限商品を含む） | 年齢・本人確認が不要な情報サイト |
| 酒類・たばこ等の販売 | 完全公開のメディア |
| 年齢制限コンテンツ | 会員制でない閲覧専用サイト |
| 金融・決済・口座開設（KYC） | 社内向けの限定ツール |
| 会員制・資格者限定サービス | プロトタイプ・PoC 段階 |
受託契約に書く 6 つの条項
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 取得属性の範囲 | 要求する属性の限定 | 最小化されているか |
| 保持 / 非保持 | 保存するデータの定義 | 属性を持たない設計か |
| 法令準拠 | 準拠する法令・指針 | 法務レビューの主体 |
| フォールバック | 非対応時の代替手段 | 利用者の取りこぼし |
| 責任分界 | 検証・運用の責任範囲 | 事故時の責任主体 |
| ログ / 監査 | 記録範囲と保管 | 属性を記録しない方針 |
価格モデル — デジタル本人確認パッケージ
| プラン | 金額 | 対象 | 内容 |
|---|---|---|---|
| 本人確認診断 | 30 万円〜 | 1 サービス | 要件整理 + 取得属性の最小化提案 |
| 標準実装 | 120 万円〜 | 中規模 | 年齢確認 / 単一属性の提示 + 検証実装 |
| 本格対応 | 240 万円〜 | 大規模 | + KYC / 複数属性 + 監査 + フォールバック整備 |
| Lite 保守 | 5 万円〜 / 月 | 小規模 | 規格・法令動向の監視 + 軽微修正 |
| Standard 保守 | 15 万円〜 / 月 | 中規模 | + 互換性検証 + 改定影響評価 |
顧客側 ROI 試算（本人確認を伴うサービス想定）
| 項目 | 自前フォーム / 書類目視 | Digital Credentials で構築 | 差分 |
|---|---|---|---|
| 確認コスト | 目視・問い合わせ対応が発生 | 自動検証で省力化 | 運用工数の削減 |
| 離脱 | 撮影・待ち時間で離脱 | タップで完結し離脱低減 | 完了率の向上 |
| 情報漏洩リスク | 身分証を保持し続ける | 属性を保持しない | 漏洩時の被害圧縮 |
| コンプラ | 保持データの管理責任が重い | データ最小化で軽量化 | 監査・対応コスト減 |
| 年間効果 | — | — | 離脱低減 + 漏洩リスクの圧縮 |
本人確認診断（30 万円〜）だけでも、「いま取得している個人情報のうち、本当に必要なのはどれか」を可視化できること自体に価値があります。抱え込んだ個人情報は、漏洩したときにまとめて代償を請求してきます。
ハマりやすい 5 つの落とし穴
落とし穴 1: 属性を取り過ぎる
「念のため」で身分証をまるごと受け取ると、保持責任を自ら背負い込みます。判定に必要な属性だけを要求します。
落とし穴 2: 属性データを保持してしまう
確認後も属性を残すと漏洩リスクになります。確認済みフラグだけを保持し、属性は捨てます。
落とし穴 3: フォールバック導線がない
デジタル ID を持たない利用者を取りこぼします。書類提出などの代替導線を必ず用意します。
落とし穴 4: 対応端末・ウォレットを前提にする
普及途上のため、未対応環境が一定数あります。非対応を前提に分岐設計します。
落とし穴 5: 法令確認を後回しにする
業種により要件が異なり、後から作り直しになります。実装前に法務確認を済ませます。
90 日アクションプラン
| 週 | アクション |
|---|---|
| Week 1 | 確認目的の整理 + 取得属性の最小化 + 法務確認 |
| Week 2 | 提示フロー・保持方針の設計 + フォールバック設計 |
| Week 3〜5 | 提示・サーバ検証・結果フラグ保存の実装 |
| Week 6 | セキュリティ検証 + 過剰保持の監査 |
| Week 7〜13 | 運用引き渡し + 規格・法令動向のウォッチ |
まとめ — 「身分証を抱え込む」から「必要な属性だけ受け取って引き渡す」へ
Digital Credentials API によって、年齢確認・本人確認は 「書類をアップロードさせて抱え込む」時代から、「必要な属性だけを選択的に受け取り、保持しない」時代 へ移ります。受託で Web 制作・システム開発を支える立場では、取得属性を最小化し、サーバで検証し、結果だけを保持し、非対応端末にフォールバックを用意して引き渡す 「デジタル本人確認・年齢確認 実装支援」が、過剰な個人情報を持たない本人確認を成果物として届ける主力サービスです。ログイン認証側もあわせて見直すなら パスキーでパスワードレス認証へ移行（GH Media） を併読してください。
弊社では本人確認診断 / 標準実装 / 本格対応 / Lite / Standard の各段階で本パッケージを提供しています。「年齢確認をもっと安全・低摩擦にしたい」「KYC で過剰な個人情報を持ちたくない」「Digital Credentials を使えるか相談したい」というご相談は お問い合わせフォーム からお気軽にどうぞ。なお本人確認・年齢確認は法令要件を伴うため、実装前の法務確認をあわせてご検討ください。
