身元確認申込み
このドキュメントの目的
身元確認申込み機能を設定し、eKYCサービスとの連携を実装することが目標です。
学べること
✅ 身元確認申込みの基礎
- 申込みテンプレートの構造
- プロセス定義(apply, ekyc, callback等)
- 外部サービス連携の仕組み
✅ 実践的な知識
- テンプレート設定の詳細
- リクエスト/レスポンスのマッピング
- verified_claimsの登録フロー
✅ プロセス制御
- プロセス依存関係の定義とシーケンス制御
- リトライ制御による再実行ポリ シー
- process_sequence検証による実行順序の強制
所要時間
⏱️ 約30分
前提条件
- 身元確認導入ガイドを読了
- テナント作成完了
- 外部身元確認サービスのAPI仕様を把握
概要
idp-server は身元確認済みID(verified ID)を提供するにあたり、 申込み・審査・完了登録の一連の申込みを管理できます。
外部のサービスと連携も可能です。
申込み機能はテンプレート形式で柔軟に定義可能で、申込みのバリデーション・外部サービス連携・データ変換などに対応しています。
利用方法
Control Plane APIを使ってテンプレートを事前に登録する。- テンプレートに応じて身元確認APIが利用可能になる。
- ユーザーが申込み操作を実行すると、定義済みテンプレートに従って申込み処理を実行する。
- 外部サービスからコールバックも同 様に、定義済みテンプレートに従って処理を実行する。
- 身元確認が完了すると
verified_claimsをユーザーに紐づけて永続化する。 - IDトークンやUserInfoに
verified_claimsを含めることができる。
※ 外部身元確認サービスのAPI仕様に合わせて、柔軟に idp-server の各申込のプロセスの設定を設定することができます。
申込みテンプレートの設定項目
| 項目 | 内容 | 必須 |
|---|---|---|
id | テンプレートのUUID | ✅️ |
type | 申込み種別(例: investment-account-opening) | ✅️ |
common | 共通設定。外部サービス。外部サービスのコールバック用の申込ID | - |
processes | 申込みプロセス。一連の身元確認のプロセスを定義する。複数登録可能 | ✅️ |
result | verified_claims source_details のマッピング定義 | - |
attributes | 申込参照APIのレスポンスに含める属性情報。 | - |
申込みフロー例
- アプリから身元確認の申込みを 行い、idp-server経由で外部身元確認サービスに連携する
- アプリでeKYCの実施し、idp-server経由で結果を外部身元確認サービスに連携する
- 外部身元確認サービスでの審査
- idp-serverが外部身元確認サービスから審査結果を受信する
- 審査結果に応じて、ユーザーの検証済みクレームを更新する
例に対応するprocess 定義
apply:申請データの送信ekyc:eKYC実施callback-examination:審査状態の通知(コールバック)callback-result:verified_claims 登録用データの受信(コールバック)
例に対応するシーケンス
例に対応するステータス遷移
申込みステータス
身元確認申込みは、申請の受付から承認・否認に至るまで複数のステータスを経由します。 本項では、各ステータスの意味と代表的な利用タイミングについて解説します。
ステータスは、申込み処理の進行状況を表すものであり、申込み一覧画面や詳細画面での表示などでご利用してください。
以下は、申込みにおける代表的なステータス一覧とその説明です。
| ステータス名 | 説明 |
|---|---|
requested | 申請リクエストが正常に受理された直後の状態です。 |
applying | ユーザーまたは外部システムが必要な情報を入力・収集中の状態です。フォーム入力中や追加書類のアップロード待ちなどが該当します。 |
applied | 申請情報の送信が完了し、審査待ちの状態です。全ての申込み処理が終了した後に遷移します。 |
examination_processing | 申請内容に対する審査が実施されている状態です。外部eKYCサービスとの連携や人手による審査が行われている場合も含まれます。 |
approved | 審査の結果、申請が承認された状態です。ユーザーの身元確認が完了し、検証済みクレームの登録などが行われます。 |
rejected | 審査の結果、申請が却下された状態です。必要に応じて理由の提示や再申請の導線提示が推奨されます。 |
expired | 有効期限切れなどにより、申請が無効となった状態です。一定期間操作が行われなかった場合などに自動的に遷移することがあります。 |
cancelled | ユーザ ーまたは管理者によって申請が任意に中断された状態です。取り下げやキャンセル操作などが該当します。 |
unknown | 状態が特定できない不明な状態です。移行中やデータ不整合、バージョン差異等により例外的に発生する可能性があります。 |
申込APIのパスの動的設定
身元確認申込みAPIは、テンプレートのprocesses定義の基づいて、テナント単位で動的にルーティングされる仕組みになっています。
APIのパスの verification-type と process が、テンプレートの "type" フィールドと "processes" に定義されたキーにより組み立てられます。
※テナント間で設定は共有されません。ただし、別テナントに同一の設定を適用するこは可能。
アプリからの申込み用API
初回申込み
POST /{tenant-id}/v1/me/identity-verification/applications/{verification-type}/{process}
※リソースオーナーのアクセストークンが必要
後続処理
POST /{tenant-id}/v1/me/identity-verification/applications/{verification-type}/{id}/{process}
※リソースオーナーのアクセストークンが必要
申込み一覧取得
GET /{tenant-id}/v1/me/identity-verification/applications
※リソースオーナーのアクセストークンが必要
※クエリパラメータ: type, status, limit, offset
申込み削除
DELETE /{tenant-id}/v1/me/identity-verification/applications/{verification-type}/{id}
※リソースオーナーのアクセストークンが必要
検証結果取得
GET /{tenant-id}/v1/me/identity-verification/results
※リソースオーナーのアクセストークンが必要
※検証済みクレーム(verified_claims)の取得
APIエンドポイント詳細
申込み一覧取得 API
- パス:
GET /{tenant-id}/v1/me/identity-verification/applications - 認証: リソースオーナーのアクセストークン必須
- クエリパラメータ:
type(optional): 申込み種別でフィルタリングstatus(optional): 申込みステータスでフィルタリング(requested, applying, applied, examination_processing, approved, rejected, expired, cancelled)limit(optional): 取得件数制限(デフォルト: 20)offset(optional): 取得開始位置(デフォルト: 0)
申込み削除 API
- パス:
DELETE /{tenant-id}/v1/me/identity-verification/applications/{verification-type}/{id} - 認証: リソースオーナーのアクセストークン必須
- 説明: 申込みの削除または取り下げ処理。ステータスがcancelledに変更される
検証結果取得 API
- パス:
GET /{tenant-id}/v1/me/identity-verification/results - 認証: リソースオーナーのアクセストークン必須
- レスポンス: ユーザーに紐づく検証済みクレーム(verified_claims)とその詳細情報
リソースオーナー用のAPI仕様(身元確認関連の申込みAPIを含む)
審査結果コールバックAPI
審査結果コールバック
POST /{tenant-id}/internal/v1/identity-verification/callback/{verification-type}/{process}
※テンプレートのcommonへの設定および、申込み詳細(application_details)から申込みを特定できるパラメータを含める必要があります。
{
"id": "UUID",
"type": "investment-account-opening"
"common": {
"external_service": "mocky",
"callback_application_id_param": "application_id"
},
"processes": {},
"result: {}
}
審査結果コールバック
POST /{tenant-id}/internal/v1/identity-verification/callback/{verification-type}/{id}/{process}
外部ステム連携用インターナルAPI仕様(身元確認関連のコールバックAPIを含む)
process詳細
身元確認申込みAPIの内部ロジックは、7つの主要なフェーズで構成されています。
これらのフェーズにより、柔軟で拡張可能な申込み処理を実現しています。
フェーズ一覧
| フェーズ名 | 役割・目 的 | 主な設定項目 | 必須 |
|---|---|---|---|
| 1. request | リクエストの構造・形式を検証 | schema(JSON Schema) | - |
| 2. pre_hook | 実行前の事前検証・外部パラメータ取得・外部API実行 | verifications, additional_parameters | - |
| 3. execution | メイン業務処理(外部連携 or 内部処理) | type, http_request, mock, no_action など(処理タイプに応じて) | ✅ |
| 4. post_hook | 実行後の検証・外部API実行 | verifications additional_parameters | - |
| 5. transition | ステータス遷移 | approved rejected canceled | - |
| 6. store | 処理結果や申請内容の永続化 | application_details_mapping_rules | - |
| 7. response | クライアントへのレスポンス生成 | body_mapping_rules | - |
プロセス内部ロジック
詳細処理フロー
プロセス依存関係とシーケンス制御
身元確認申込みでは、複数のプロセスを順序立てて実行する必要がある場合があります。 例えば、「申込み (apply) → CRM登録 (crm-registration) → eKYC実施 (request-ekyc)」のように、前のプロセスが完了しないと次のプロセスを実行できない要件に対応できます。
主な機能
- プロセス依存関係の定義: 前提となるプロセスの完了を必須化
- リトライ制御: プロセスごとに再実行の可否を設定
- 自動検証:
process_sequence検証タイプによる実行順序の強制
dependencies フィールド
各プロセスに dependencies フィールドを追加することで、実行順序を制御できます。
設定項目:
| フィールド | 型 | 説明 | 必須 |
|---|---|---|---|
required_processes | string[] | このプロセスを実行する前に完了が必要なプロセス名のリスト | - |
allow_retry | boolean | プロセスの再実行を許可するか (true: 許可, false: 不可) | ✅ |
設定例:
{
"processes": {
"apply": {
"dependencies": {
"required_processes": [],
"allow_retry": false
}
},
"crm-registration": {
"dependencies": {
"required_processes": ["apply"],
"allow_retry": false
}
},
"request-ekyc": {
"dependencies": {
"required_processes": ["crm-registration"],
"allow_retry": true
}
}
}
}
process_sequence 検証タイプ
依存関係を強制するために、pre_hook の verifications に process_sequence タイプを追加します。
設定例:
{
"pre_hook": {
"verifications": [
{
"type": "process_sequence"
}
]
}
}
検証内容:
- 依存プロセスの完了チェック:
required_processesに指定されたプロセスがすべて正常完了しているか - リトライ制御:
allow_retry: falseのプロセスが既に実行済みの場合、再実行を拒否
エラーレスポンス:
依存関係違反または リトライ禁止違反の場合、以下のエラーが返されます:
{
"error": "pre_hook_validation_failed",
"error_messages": [
"Process 'crm-registration' requires completion of: apply"
]
}
または
{
"error": "pre_hook_validation_failed",
"error_messages": [
"Process 'apply' does not allow retry and has already been executed"
]
}
実行フロー例
シナリオ: 証券口座開設における3段階プロセス
- apply (基本情報入力) - 依存なし、リトライ不可
- crm-registration (CRM登録) -
apply完了が必須、リトライ不可 - request-ekyc (eKYC実施) -
crm-registration完了が必須、リトライ可
正常な実行順序:
1. POST /{tenant-id}/v1/me/identity-verification/applications/account-opening/apply
→ 成功 (application_id: "abc-123" を取得)
2. POST /{tenant-id}/v1/me/identity-verification/applications/account-opening/abc-123/crm-registration
→ 成功
3. POST /{tenant-id}/v1/me/identity-verification/applications/account-opening/abc-123/request-ekyc
→ 成功
4. POST /{tenant-id}/v1/me/identity-verification/applications/account-opening/abc-123/request-ekyc
→ 成功 (allow_retry: true のため再実行可能)
エラーケース:
1. POST /{tenant-id}/v1/me/identity-verification/applications/account-opening/crm-registration
→ 400 Bad Request
→ "Process 'crm-registration' requires completion of: apply"
2. apply実行後、再度 apply を実行
→ 400 Bad Request
→ "Process 'apply' does not allow retry and has already been executed"
ユースケース
| ユースケース | 設定 |
|---|---|
| 線形フロー | apply → ekyc → callback という順序を強制したい場合 |
| ワンタイム処理 | 基本情報入力は一度だけ実行させたい (allow_retry: false) |
| リトライ可能処理 | 本人確認書類の撮影失敗時に再実行を許可 (allow_retry: true) |
| 複数依存 | プロセスDが「プロセスA」「プロセスB」「プロセスC」すべての完了を必要とする |
完全な設定例
{
"id": "uuid-here",
"type": "account-opening",
"processes": {
"apply": {
"request": {
"schema": {
"type": "object",
"properties": {
"given_name": { "type": "string" },
"family_name": { "type": "string" }
},
"required": ["given_name", "family_name"]
}
},
"pre_hook": {
"verifications": [
{
"type": "process_sequence"
}
]
},
"execution": {
"type": "no_action"
},
"dependencies": {
"required_processes": [],
"allow_retry": false
},
"transition": {
"applied": {
"any_of": [[
{ "path": "$.request_body", "type": "object", "operation": "exists" }
]]
}
},
"store": {
"application_details_mapping_rules": [
{ "from": "$.request_body", "to": "*" }
]
}
},
"crm-registration": {
"request": {
"schema": {
"type": "object",
"properties": {
"crm_id": { "type": "string" }
},
"required": ["crm_id"]
}
},
"pre_hook": {
"verifications": [
{
"type": "process_sequence"
}
]
},
"execution": {
"type": "no_action"
},
"dependencies": {
"required_processes": ["apply"],
"allow_retry": false
},
"transition": {
"applied": {
"any_of": [[
{ "path": "$.request_body", "type": "object", "operation": "exists" }
]]
}
},
"store": {
"application_details_mapping_rules": [
{ "from": "$.request_body", "to": "crm_data" }
]
}
},
"request-ekyc": {
"request": {
"schema": {
"type": "object",
"properties": {
"ekyc_provider": { "type": "string" }
},
"required": ["ekyc_provider"]
}
},
"pre_hook": {
"verifications": [
{
"type": "process_sequence"
}
]
},
"execution": {
"type": "no_action"
},
"dependencies": {
"required_processes": ["crm-registration"],
"allow_retry": true
},
"transition": {
"applied": {
"any_of": [[
{ "path": "$.request_body", "type": "object", "operation": "exists" }
]]
}
},
"store": {
"application_details_mapping_rules": [
{ "from": "$.request_body", "to": "ekyc_data" }
]
}
}
}
}
注意事項
- 循環依存の禁止: プロセスA → プロセスB → プロセスA のような循環依存は設定しないでください
- 依存チェーンの検証: 依存関係が正しく設定されているか、設定後にテストしてください
- リトライポリシーの設計: ビジネス要件に応じて
allow_retryを適切に設定してください - エラーハンドリング: クライアント側で依存関係エラーを適切に処理し、ユーザーに案内してください
各フェーズの詳細設定
1. Request フェーズ
目的: リクエストの受信と基本検証
主な機能:
- リクエストスキーマ検証
- 必須パラメータチェック
- データ型・形式検証
- 認証情報確認
設定例:
{
"request": {
"schema": {
"type": "object",
"required": [
"last_name",
"first_name",
"email_address"
],
"properties": {
"last_name": {
"type": "string",
"maxLength": 255
},
"email_address": {
"type": "string",
"pattern": "^[\\w\\.-]+@[\\w\\.-]+\\.[a-zA-Z]{2,}$"
}
}
}
},
"pre_hook": {},
"execution": {},
"post_hook": {},
"transition": {},
"store": {},
"response": {}
}
処理内容:
- リクエストボディのJSONスキーマ検証
- 必須フィールドの存在確認
- データ形式の妥当性チェック
- 文字数制限などの制約確認
設定項目:
| 項目名 | 型 | 説明 |
|---|---|---|
type | string | 基本は "object"。ルートのデータ型を定義。 |
required | string[] | 必須項目名のリスト。リクエストにこの項目が存在しないとエラーになる。 |
properties | object | 各プロパティのバリデーション定義を含むオブジェクト。 |
└ <key> | object | 各プロパティに対する制約(型、長さ、パターンなど)。 |
└└type | string | "string", "integer", "boolean", "object" などを指定。 |
└└format | string | "date", "date-time" など、特定フォーマットの検証に使用。 |
└└pattern | string | 正規表現による文字列パターンチェック。例: メールアドレス。 |
└└minLength | integer | 文字列の最小文字数。 |
└└maxLength | integer | 文字列の最大文字数。 |
└└minimum | integer | 数値の最小値。 |
└└maximum | integer | 数値の最大値。 |
2. Pre Hook フェーズ
目的: メイン処理実行前の準備・検証
主な機能:
- 申込みに対するビジネスロジック検証(複数指定できる。設定順に実行する)
- ユーザークレームの検証
- 重複申込み検証
- その他のロジックも追加予定
- 追加パラメータ取得(複数指定できる。設定順に実行する)
- 外部API実行
- その他のロジックも追加予定
設定例:
{
"request": {},
"pre_hook": {
"verifications": [],
"additional_parameters": []
},
"execution": {},
"post_hook": {},
"transition": {},
"store": {},
"response": {}
}
処理内容:
- 申込みに対するビジネスロジック検証
- 追加パラメータ取得
の順で実行される。