ブログ・ 2026年7月28日

ID検証API：統合と評価のガイド (JA)

開発者向けのID検証APIガイド：ワークフローアーキテクチャ、ステータス、Webhook、証拠、セキュリティ、テスト、調達基準、および統合における一般的な誤りについて解説します。.

By Didit2026年7月28日更新日 2026年7月28日

ID検証APIを使用すると、アプリケーションは本人確認の証拠を収集または提出し、申請された人物に関する構造化された結果を受け取ることができます。ワークフローに応じて、ID文書の検証、属性の抽出、ライブの申請者と参照画像の比較、生体検知、データの裏付け、または複数のチェックを1つのセッションに統合することができます。

APIの応答は証拠であり、完全なビジネス上の決定ではありません。本番環境での統合では、信頼できるキャプチャ、顧客の状態の所有権、ステータス遷移、再試行、レビュー、プライバシー、記録保持、および技術的な結果を承認、再試行、ステップアップ、レビュー、または拒否に変換するポリシーも定義する必要があります。

主要なポイント

ID検証APIは1つのエンドポイント以上です。実際の契約には、キャプチャ、非同期状態、証拠、イベント、照合、レビュー、および削除が含まれます。
バックエンドが決定を所有します。クライアントのリダイレクトや視覚的な成功画面は権威あるものではありません。最終的な状態はサーバー側で確認されるべきです。
結果にはスコープと理由が必要です。文書の真正性、所有者との関連付け、生体検知、品質、および文脈上のリスクは、説明のないブール値にまとめてしまうのではなく、分離可能であるべきです。
信頼性は失敗パスに現れます。べき等性、Webhook検証、イベントリプレイ、タイムアウト、再試行、バージョン管理、およびサンドボックスの同等性は、成功パスと同様に重要です。
評価は本番環境に近い対象者を使用する必要があります。カバレッジ、不正耐性、完了率、誤った結果、レビュー負荷、およびプライバシーは、文書、デバイス、地域、および関連するユーザーセグメントごとに測定されるべきです。

ID検証APIは何をするのか？

ID検証APIは、本人確認機能への機械可読なインターフェースを提供します。一般的な統合では、検証試行を作成し、安全なキャプチャ体験を通じて申請者を誘導し、進行状況または完了イベントを受け取り、最終的な証拠を取得し、依拠する組織のポリシーを適用します。

NIST SP 800-63A-4の本人確認モデルは、3つの重要な機能を区別しています。

解決（Resolution）：関連する集団内で申請された人物を区別する。
検証（Validation）：本人確認の証拠と属性が真正、正確、かつ許容可能であるかを判断する。
確認（Verification）：申請者がその証拠に関連付けられた対象であることを確立する。

APIは、これらの1つ、2つ、またはすべてを実行する場合があります。製品名はスコープを保証しないため、要件では各結果から期待される正確な結論を明記する必要があります。

ID検証API、文書API、KYC API、OCRの比較

インターフェース	主な目的	有用な出力	それ自体では証明できないこと
OCR API	ドキュメントのピクセルをテキストまたはフィールドに変換	抽出された名前、日付、番号、住所	真正性、所有権、または顧客リスク
文書検証API	文書とそのキャプチャされた証拠を検証	真正性チェック、有効期限、フィールドの一貫性、改ざん指標	現在の申請者がそれを所有していること
顔照合API	提出された顔と参照画像を比較	しきい値での類似性または照合の決定	生体検知、文書の真正性、または法的身元
生体検知API	生体認証キャプチャ時のライブプレゼンスを推定	真正、攻撃、再試行、またはスコアの証拠	人物の身元
ID検証API	証拠の検証と申請者の関連付けを組み合わせる	証拠レベルの結果とワークフローの成果	完全なKYCまたはビジネス適格性
KYC API	より広範な顧客デューデリジェンスフローをサポート	ID、スクリーニング、リスク、ワークフロー、および記録	組織ポリシーなしでの自動コンプライアンス

この区別は、アーキテクチャ上の誤りを防ぎます。たとえば、アップロードフォームにOCRを追加するとデータ入力は速くなりますが、ドキュメントの認証は行いません。顔照合を追加すると2つの画像が接続されますが、どちらの画像が信頼できるライブキャプチャを通じて取得されたかを確立することはできません。

これらのインターフェースを取り巻くより広範なポリシー、スクリーニング、リスク、および継続的なレビューのコンテキストについては、KYCライフサイクルガイドをご覧ください。この記事では、開発者の信頼境界、すなわちキャプチャ、APIの状態、証拠、イベント、照合、およびバックエンドの決定に焦点を当てます。

一般的な統合モデル

ホスト型検証セッション

アプリケーションのバックエンドはセッションを作成し、短命のURLまたはトークンを受け取ります。ユーザーはプロバイダーがホストするジャーニーでキャプチャを完了し、その後アプリケーションに戻ります。このモデルは、サーバー側の制御を維持しながら、フロントエンドとデバイスの複雑さを軽減することができます。

主な問題点には、ブランディング、ドメインの引き渡し、アクセシビリティ、ローカライゼーション、モバイルブラウザのサポート、セッションの有効期限、戻り動作、およびユーザーがデバイスを切り替えたときにアプリケーションがどのように再開するかなどがあります。

組み込みWebまたはモバイルSDK

SDKは、アプリケーション内でキャプチャ体験を実行します。これにより、より厳密なインターフェース制御とデバイス機能へのアクセスが可能になりますが、統合の品質がセキュリティに影響を与えます。バージョンサポート、アプリケーションの整合性、カメラの権限、仮想カメラの処理、更新ポリシー、およびテレメトリがレビューの一部となります。

スタンドアロンのサーバー間チェック

顧客システムは、構造化されたデータまたはメディアをエンドポイントに直接送信します。これは、すでに信頼されているキャプチャ、バッチ操作、または個々のモジュールに役立ちます。また、キャプチャの整合性、同意、品質、ペイロードのセキュリティ、およびリプレイ防止の責任がインテグレーターに移ります。

オーケストレーションされたワークフロー

1つのセッションは、文書検証、データベースチェック、生体検知、顔照合、スクリーニング、デバイス信号、および手動レビューに分岐できます。APIはワークフローとポリシーバージョンを公開し、後で同じステータスを解釈できるようにする必要があります。

安全な統合シーケンス

1. バックエンドから試行を作成する

信頼されたバックエンドは内部の顧客参照を生成し、必要なワークフロー、ロケール、およびポリシーコンテキストでプロバイダーを呼び出します。ブラウザまたはモバイルコードで永続的なAPI資格情報を公開しないでください。

作成操作にはべき等性戦略を使用してください。クライアントのタイムアウトによって、2回目の課金可能な試行が作成されたり、結果が元の顧客から切り離されたりしないようにします。

2. 短命のキャプチャ引き渡しを発行する

フロントエンドには、その試行に必要なスコープ付きトークンまたはURLのみを与えます。それを予期されるアプリケーション、顧客参照、ワークフロー、および有効期限にバインドします。URL、分析イベント、またはクライアントログに不要な個人データを配置することは避けてください。

3. 証拠をキャプチャして検証する

サポートされている証拠と品質要件を通じてユーザーを誘導します。回復可能な品質の問題と疑わしい攻撃を区別します。「もっと近づいてください」、「文書の有効期限切れ」、「キャプチャの整合性失敗」を1つの一般的なエラーにしないでください。

4. 認証されたイベントを受信する

検証されるまでWebhookを信頼できない入力として扱います。イベント署名またはメッセージ認証、タイムスタンプまたは鮮度制御、予期される宛先、コンテンツタイプ、およびイベント識別子を検証します。RFC 9421はHTTPメッセージ署名の一般的なメカニズムを定義していますが、プロバイダーは異なる文書化された署名スキームを使用する場合があります。

イベント識別子を保存し、べき等に処理します。配信システムは再試行します。重複イベントは正常です。到着順序を仮定せず、古いイベントが顧客を終端状態から後退させないようにしてください。

5. 正規の結果を取得する

完了イベントの後、プロバイダーAPIから最終的な試行を取得します。この照合ステップは、単一のWebhookの内容への依存を減らし、見逃されたまたは遅延した配信から回復します。

6. 組織ポリシーを適用する

構造化された証拠を組織自身の決定状態にマッピングします。プロバイダーは結果を推奨する場合がありますが、依拠する組織は製品、顧客履歴、法的根拠、リスク許容度、および利用可能な回復パスを知っています。

7. 移行を記録する

内部の顧客参照、プロバイダーの試行識別子、ワークフローとバージョン、関連する証拠または参照、理由コード、イベント履歴、ポリシーバージョン、レビュー担当者のアクション、および最終的な根拠を永続化します。永続的な参照で十分な場合は、機密データのコピーを最小限に抑えます。

APIが公開すべき状態モデル

ブール値のverifiedフィールドは、実際の顧客の旅には小さすぎます。有用な状態には、次のようなものがあります。

状態	意味	典型的なアプリケーションアクション
作成済み	試行は存在するが、キャプチャは開始されていない	安全な引き渡しを提示または再送する
進行中	ユーザーまたは非同期チェックがアクティブ	待機する。最終的なアクセスを許可しない
入力待ち	さらなる証拠またはユーザーアクションが必要	正確な回復ガイダンスを表示する
再試行可能	キャプチャまたは品質が回復可能に失敗した	制限された新しい試行を開始する
レビュー中	訓練されたレビュー担当者がケースを担当	アクセスを保留し、予想される次のステップを公開する
承認済み	必要な証拠が構成されたワークフローを満たした	組織ポリシーと状態遷移を適用する
拒否済み	証拠が定義された制御に失敗した	異議申し立て、制限、または代替パスを適用する
期限切れまたは放棄済み	決定なしで試行が終了した	制御された再開を許可する
技術エラー	システムが証拠を生成できなかった	不正として扱わずに再試行または調整する

すべての終端ステータスには構造化された理由が必要です。安定した機械コードはポリシーと分析を可能にし、ローカライズされた人間向けメッセージはユーザーとレビュー担当者を助けます。RFC 9457は、インターフェースレベルでの機械可読なHTTP問題詳細の標準フォーマットを提供します。

結果に含めるべき証拠とは？

文書レベルの証拠

方法に関連する証拠タイプ、発行国、文書クラス、有効期限、フィールドの一貫性、品質、および検証指標を含めます。結果が光学検査、チップデータ、発行者またはデータベースの裏付け、または他のソースから得られたものかを明確にします。

申請者との関連性を示す証拠

顔比較、生体検知、キャプチャの整合性、およびID属性の関連付けを分離します。不要な生体認証情報をすべての消費者に公開することなく、後で解釈するために使用された参照と決定しきい値またはバージョンを記録します。

リスクおよび運用上の証拠

デバイス、IP、速度、繰り返しの試行、またはワークフローの信号は、ステップアップとレビューを導くことができます。これらはID属性を静かに変更すべきではありません。各理由がどのサブシステムによって生成されたかを保持します。

来歴とバージョン

モデル、文書テンプレート、ウォッチリスト、またはポリシーの変更によって結果が変わる場合があります。プロバイダーバージョン、ワークフローバージョン、決定時刻、ソース参照、および人間がケースをレビューしたかどうかを保存します。

APIセキュリティ要件

ID APIは貴重な個人データと生体認証データを処理し、攻撃者が自動化できるビジネスフローを公開します。OWASP API Security Top 10は、ここで直接関連するリスクを強調しています。それは、壊れたオブジェクト認証、壊れた認証、過剰なプロパティ公開、無制限のリソース消費、機密フローの自動化、貧弱なAPIインベントリ、およびサードパーティAPIへの安全でない信頼です。

認証と認可

テスト用と本番用で別々の資格情報とアプリケーションを使用します。最小特権の原則、ローテーション、取り消し、環境分離、およびオブジェクトレベルの認可を適用します。認証された組織が識別子を変更することで別の組織の試行を取得できないようにします。

アップロードとリソースの制御

メディアタイプ、サイズ、寸法、構造、および予期されるソースを検証します。タイムアウト、同時実行制限、レート制御、および試行制限を設定します。検証呼び出しは計算を消費し、チェックごとのコストがかかるため、無制限のエンドポイントはサービス拒否とコストの両方のリスクを伴います。

データ公開

消費者が本当に必要とするフィールドのみを返します。サポート、アナリスト、開発者、管理者がデフォルトですべてのID証拠を受け取らないように、運用上の役割を分離します。ログと監視ツールから機密性の高いペイロードを編集します。

Webhookとリプレイ制御

イベントを認証し、署名検証に必要な生の本文を保持し、古いまたは不正な配信を拒否し、イベント識別子の重複を排除し、正規の状態を取得します。進行中の配信を中断することなくWebhookシークレットをローテーションします。

インベントリとバージョン管理

すべてのアクティブなエンドポイント、バージョン、ホスト、資格情報、コールバック、SDK、および廃止日を文書化します。本番データを持つシャドウテストエンドポイントや、古くてメンテナンスされていないSDKは、レビューされたパスを損なう可能性があります。

ID検証APIのテスト方法

契約と状態テスト

文書化されたすべての状態、理由、再試行、タイムアウト、および終端遷移を実行します。ページネーション、フィルタリング、エラーボディ、後方互換性、および不明なフィールドの動作を確認します。重複したWebhookや順序が入れ替わったWebhookをシミュレートします。

証拠テスト

予期される対象者における文書タイプ、国、スクリプト、有効期限条件、デバイス、カメラ、およびネットワーク全体で、許可され代表的なサンプルを使用します。サポートされていない、読み取れない、不一致、操作された、および真正な証拠を個別に追跡します。

不正テスト

リプレイ、印刷された証拠、改ざんされた文書、仮想カメラ、エミュレーター、注入されたメディア、繰り返されたID、および自動化された試行のための許可された攻撃セットを構築します。NISTのリモート本人確認要件は、キャプチャセンサーの信頼性、偽造メディア分析、保護されたチャネル、および生体認証比較を区別しています。なぜなら、単一のメカニズムでは完全なパスをカバーできないからです。

運用テスト

完了率、再試行回数、放棄率、手動レビュー率、解決までの時間、サポートへの連絡、Webhookの遅延、照合、および可用性を測定します。結果を文書、デバイス、ネットワーク、言語、および関連する顧客グループごとに分類します。

決定品質テスト

プロバイダーを1つの「精度」数値で比較しないでください。意図したしきい値での誤承認と誤拒否、攻撃固有の結果、サンプル数、信頼度、応答なしのケース、および下流で確認された結果をレビューします。

プライバシーと削除テスト

保持設定、エクスポート、削除、アクセスログ、地域処理、サブプロセッサ制御、およびオープンレビュー中または法的に義務付けられた保持中に削除要求が届いた場合の動作を確認します。

プロバイダーの評価方法

スコープと保証

どの本人確認機能が含まれていますか？どの保証モデルと独立したテストが適用されますか？どのコンポーネントとバージョンがテストされましたか？プロバイダーは、パスが何を意味し、何を意味しないのかを説明できますか？

カバレッジ

合計数だけでなく、国と文書のマトリックスを求めます。古いデバイス、複数のスクリプト、低品質のカメラ、および一般的ではないが正当な文書を含む、顧客が提示する証拠をテストします。

開発者体験

APIの一貫性、OpenAPIの品質、SDKのメンテナンス、例、サンドボックスシナリオ、Webhookツール、変更履歴の規律、移行ポリシー、ステータスページ、およびサポートエスカレーションをレビューします。5行の成功パスのサンプルは、本番環境の統合ガイドではありません。

運用と説明可能性

レビューキュー、証拠ビュー、役割の権限、監査ログ、理由コード、異議申し立て、およびエクスポートを検査します。人間が技術的な失敗、品質の再試行、可能性のある攻撃、およびIDの不一致を区別できることを確認します。

商業と移植性

成功ベースか試行ベースの課金、レビュー料金、最低料金、制限、ストレージ、地域オプション、および終了条件を理解します。内部の顧客参照とポリシー境界を移植可能に保ち、プロバイダーの変更がアカウント状態の書き換えを必要としないようにします。

一般的な統合の誤り

戻りURLからのアクセス許可

ユーザーはブラウザのパスを制御します。成功リダイレクトはインターフェースの状態であり、証明ではありません。信頼できるバックエンドから最終状態を確認します。

すべての失敗を不正として扱う

権限拒否、タイムアウト、サポートされていない証拠、ぼかし、および疑わしい操作は異なります。これらを混同すると、誤った拒否と使用できない分析が生まれます。

Webhookを正確に1回処理する

ネットワークは正確に1回の配信を約束できません。重複排除、単調な遷移、および正規の取得を備えた少なくとも1回のイベント配信を設計します。

完全なペイロードのログ記録

便利なデバッグログは、文書や生体認証データを、より広範なアクセスとより長い保持期間を持つシステムにコピーする可能性があります。識別子、構造化された理由、および制御された証拠アクセスを使用します。

サンドボックスの成功ケースのみをテストする

本番環境での失敗は、再試行、古いデバイス、エッジドキュメント、イベント遅延、バージョン変更、およびレビューで発生します。失敗シナリオを受け入れテストスイートの一部にします。

ポリシー決定のアウトソーシング

ベンダーの結果は、すべての管轄区域、顧客タイプ、製品リスク、またはビジネス制限を知ることはできません。組織の決定ロジックと説明責任を保持します。

実装チェックリスト

本番稼働前に、以下を確認してください。

API資格情報がサーバー側に残り、環境と役割によってスコープが設定されていること。
作成呼び出しがべき等であり、安定した内部顧客参照にマッピングされていること。
キャプチャトークンが短命であり、予期される試行にバインドされていること。
すべての状態と理由に明示的な顧客およびバックエンドのアクションがあること。
Webhookの署名、鮮度、重複、および順序がテストされていること。
正規の取得が、見逃されたまたは遅延したイベントを調整すること。
証拠レベルの出力が、最終的な顧客決定とは別に保たれること。
レート、アップロード、同時実行、および試行制御が自動化された悪用に対処できること。
文書、デバイス、不正、プライバシー、アクセシビリティ、およびレビューテストが本番環境に近いサンプルを使用していること。
保持、削除、インシデント対応、バージョン管理、および移行に担当者がいること。

DiditのID検証の利用

Diditは、構成可能なモジュールとしてID検証を提供し、チームが生体検知、デバイスとIP分析、およびワークフローオーケストレーターを通じた条件付きパスを追加できるようにします。公開されているスタンドアロンID検証の価格は0.15ドルですが、公開されている0.33ドルのKYCバンドルは、ID検証、パッシブ生体検知、顔照合、およびIP分析を組み合わせたものです。

料金ページには現在のモジュール料金が記載されており、無料枠は月間500回の無料検証です。これらの製品結果は、バックエンドが所有するポリシーと顧客の状態を置き換えるのではなく、それらをフィードするべきです。

よくある質問

ID検証APIとは何ですか？

本人確認の証拠を収集または提出し、証拠の有効性および申請者が主張する身元への関連性に関する構造化された結果を受け取るためのプログラムインターフェースです。

ID検証APIはKYC APIと同じですか？

必ずしもそうではありません。ID検証は本人確認の証拠と所有者との関連付けに焦点を当てています。KYC APIには、スクリーニング、顧客リスク、ワークフロー、レビュー、記録、および継続的な更新も含まれる場合があります。

本人確認はフロントエンドで実行すべきですか？

キャプチャインターフェースはフロントエンドで実行される場合がありますが、永続的な資格情報、セッション作成、最終結果の取得、ポリシー決定、および顧客状態の変更は信頼できるバックエンドに属します。

なぜWebhookが必要なのですか？

多くのチェックとレビューは非同期です。Webhookはアプリケーションに変化を通知し、取得エンドポイントは調整のための正規の状態を提供します。

重複したWebhookはどのように処理すべきですか？

各イベントを検証し、その識別子を保存し、べき等に処理し、古い状態が新しい終端状態を上書きするのを防ぎ、必要に応じて正規の試行を取得します。

サンドボックスには何を含めるべきですか？

本番環境の契約を再現し、成功、再試行、拒否、レビュー、有効期限、技術エラー、重複イベント、遅延イベント、および関連する理由コードに対する確定的ケースを提供するべきです。

APIは企業をコンプライアンスに準拠させることができますか？

いいえ。APIは証拠とワークフローの結果を提供できます。組織は、法的分析、ポリシー、顧客決定、例外、記録、プライバシー、および継続的な制御に対して責任を負います。

主要な参考文献

堅牢なID検証統合は、試行の作成者、証拠のキャプチャ方法、正規の結果、イベントの認証方法、各理由の意味、および最終的な顧客決定を所有するシステムなど、すべての信頼境界を明確にします。