> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Didit MCPの使用例：プロンプトとエージェントとの会話

> Didit MCPのプロンプトとエージェント会話の例。KYCワークフローとセッション作成、KYBの法人登記検索、レビューキュー、ルールのバックテスト、Webhook設定を紹介します。

Didit MCPが得意とする使い方を、いくつかのパターンで紹介します。普段の言葉で指示すれば、使うツールはエージェントが選びます。以下で挙げるツールはすべて[ツールリファレンス](https://docs.didit.me/ja/integration/mcp/tools.md)に掲載されています。

***

## クイックプロンプト

**運用・モニタリング（アプリ横断）**

* *「すべてのアプリを対象に、レビュー中のセッションを直近5件表示してください。」* → `didit_session_search`（`status: "In Review"`、`limit: 5`を指定）
* *「過去15日間に電話番号検証を試したものの離脱した人は何人ですか？」* → `didit_analytics`（`last_n_days: 15`を指定。1回の呼び出しで機能ファネルを読み取ります）
* *「vendor\_dataが`user_8842`の顧客を探して、どのアプリでどのステータスか教えてください。」* → `didit_vendor_user_search`
* *「クレジット残高と今月のコンバージョン率を教えてください。」* → `didit_org_get_balance` + `didit_analytics`

**設定**

* *「IDスキャンとライブネス検知を含むKYCワークフローを作成して、認証リンクを発行してください。」* → `didit_workflow_create` → `didit_session_create`
* *「パスポートのみを受け付ける本人確認ワークフローを作成し、その後にセルフィーによるライブネス検知を追加してください。」* → `didit_workflow_create`。`documents_allowed: ["PASSPORT"]`と指定するだけで、MCPがすべての国についてパスポートのみの設定に展開します（[高度な設定 → 機能設定](https://docs.didit.me/ja/integration/mcp/advanced.md#機能設定と許可リスト)を参照）。
* *「新しいワークフロー：パスポートをスキャンし、本人確認が却下されたらセッションを却下する。申告された職業が『Software Engineer』に近い（60%以上）場合はライブネスチェックを実行し、それ以外の場合はスペイン語で住所証明を求める。その後、自動判定する。」* → `didit_workflow_get_field_definitions` → `didit_workflow_validate_graph` → `didit_workflow_set_graph`
* *「ワークフロー`26d33c04…`で、本人確認の後に、本人確認が却下された場合はセッションを却下し、職業が『Software Engineer』と80%以上類似している場合はDocument-AIによる資金証明のステップを追加して、その後は続行してください。」* → `didit_workflow_search` → `didit_workflow_get_graph` → `didit_workflow_edit_graph`（小さな操作単位で編集し、レビュー可能な下書きとして保存）
* *「書類スキャンの代わりにBankIDやMitIDでのログインを提供できる国はどこですか？」* → `didit_workflow_get_id_verification_methods_catalog`
* *「`https://myapp.com/webhooks/didit`でステータス更新を受け取るWebhookの送信先を登録してください。」* → `didit_webhook_create`

**コンプライアンス**

* *「このウォレットをAMLスクリーニングにかけ、ヒットしたらブロックリストに追加してください。」* → `didit_transaction_screen_wallet` → `didit_blocklist_add`
* *「セッション`…`のケースを作成し、私に割り当ててください。」* → `didit_case_create` → `didit_case_manage`
* *「Acme Ltdは英国で登記された企業ですか？株主は誰ですか？」* → `didit_verify_kyb_search` → `didit_verify_kyb_select`

***

## 1. 本人確認を立ち上げる

> **あなた：** 「IDスキャンとライブネス検知を使って、自分のアプリにDiditの本人確認を設定し、試せるリンクをください。」
>
> **エージェント：** まずワークフローを作成します。*（`didit_workflow_create`を`workflow_label: "Standard KYC"`、`features: [{ "feature": "OCR" }, { "feature": "LIVENESS" }]`で呼び出し）* **「Standard KYC」**を公開しました。`workflow_id = 6f2c…`です。次に、試すためのセッションを作成します。*（`didit_session_create`を`workflow_id: "6f2c…"`、`vendor_data: "test-user-1"`で呼び出し）* リンクはこちらです：`https://verify.didit.me/session/…`。スマートフォンで開いてフローを実行してください。本番環境では、バックエンドがREST APIでセッションを作成します：
>
> ```bash theme={null}
> curl -X POST https://verification.didit.me/v3/session/ \
>   -H "x-api-key: $DIDIT_API_KEY" \
>   -H "Content-Type: application/json" \
>   -d '{ "workflow_id": "6f2c...", "vendor_data": "internal-user-id", "callback": "https://myapp.com/done" }'
> ```
>
> この`x-api-key`は、バックエンドで使うアプリケーションの**REST APIキー**です。このMCPへのサインイン方法（*Log in with Didit*を使用）とは別のものです。Webhookの送信先も登録しましょうか？
>
> **あなた：** 「はい。エンドポイントは`https://myapp.com/webhooks/didit`です。」
>
> **エージェント：** *（`didit_webhook_create`を`label: "Production"`、`url: "https://myapp.com/webhooks/didit"`、`webhook_version: "v3"`、`subscribed_events: ["status.updated"]`で呼び出し）* 完了しました。私が受け取るレスポンスでは署名シークレットが伏せられているため、コンソールの**Webhook**からコピーし、`DIDIT_WEBHOOK_SECRET`として保存してください。各配信を信頼する前に、`X-Signature-V2`ヘッダーを検証してください。

***

## 2. KYB:法人登記で企業を確認する

> **あなた：** 「Acme Trading Ltdは実在する英国企業ですか？登記番号は12345678です。」
>
> **エージェント：** *（`didit_verify_kyb_search`を`country_code: "GB"`、`name: "Acme Trading Ltd"`、`registration_number: "12345678"`で呼び出し）* 候補が1件見つかりました：**ACME TRADING LTD**、2019年設立、ステータスは*active*、登記上の事務所はマンチェスターです。役員と株主を含む完全な記録を取得しますか？
>
> **あなた：** 「はい。実質的支配者が誰かも教えてください。」
>
> **エージェント：** *（候補の`kyb_response_id`を指定して`didit_verify_kyb_select`を呼び出し）* 完全な記録を取得しました。取締役が2名、株式および議決権の75%+を保有する重要な支配権を有する者が1名です。記録には提出書類の履歴と登記住所が含まれます。これは課金対象の法人登記照会でした（クレジットを消費する呼び出しが2回）。すべての企業顧客に対してこれを自動的に実行したい場合は、`didit_workflow_create`でKYBワークフローに`KYB_REGISTRY`を追加できます。英国の登記所が販売しているデータのレベルは、`didit_workflow_get_kyb_registry_catalog`で確認できます。

***

## 3. レビューキューを処理する

> **あなた:** 「レビュー待ちのものは何がありますか。それぞれ何が問題ですか。」
>
> **エージェント:** *(`status: "In Review"`、`limit: 10`を指定して`didit_session_search`を呼び出し)* 2つのアプリにまたがる4件のセッションがレビュー中です。それぞれの判定を確認します。*(各`session_id`に対して`didit_session_get_decision`を呼び出し)*
>
> | セッション | アプリ | 停止した理由 |
> | - | - | - |
> | `a1f3…` | Onboarding | 顔照合の一致スコア71(しきい値80)、ライブネス検知は合格 |
> | `b7c2…` | Onboarding | 書類の有効期限が2か月前に切れている |
> | `c904…` | Marketplace | AML: PEPヒット1件、氏名一致率92%、生年月日が異なる |
> | `d215…` | Marketplace | 住所証明が90日より古い |
>
> **あなた:** 「`a1f3`を承認してください。セルフィーを確認したところ同一人物です。`b7c2`は書類の期限切れなので却下してください。」
>
> **エージェント:** *(`session_id: "a1f3…"`、`new_status: "Approved"`を指定して`didit_session_update_status`を呼び出し、続いて`session_id: "b7c2…"`、`new_status: "Declined"`、`comment: "Expired document"`を指定して呼び出し)* 両方とも更新しました。*(`a1f3…`に対して「Manual selfie review: same person」というメモを付けて`didit_session_add_review`を呼び出し)* スコアを覆した理由が監査ログに残るよう、レビューメモを追加しました。AMLと住所証明の2件はまだ未対応です。ご指示いただければ、`didit_case_create`でPEPヒットのケースを作成します。

***

## 4. 取引ルールを本番適用前にバックテストする

> **あなた:** 「1時間以内に\$1,000を超える送金を3回を超えて行った人をフラグ付けしたいです。どのくらいノイズが出ますか。」
>
> **エージェント:** *(`amount > 1000`に対する`conditions`、1時間のウィンドウでの件数3以上という`aggregation`、`period_days: 90`を指定して`didit_transaction_rule_backtest`を呼び出し)* 過去90日間では、このルールは6人の対象者による14件の取引で発火していたはずです。そのうち2人の対象者はすでにフラグ付けされています。アクションを一切実行せずに一致のみを記録する`TEST`モードで作成しましょうか。
>
> **あなた:** 「はい、TESTモードでお願いします。」
>
> **エージェント:** *(`title: "Velocity: 3+ transfers over $1,000 per hour"`、`category: "aml_ctf"`、`mode: "TEST"`、同じ`conditions`と`aggregation`、対象者をフラグ付けする`actions`リストを指定して`didit_transaction_rule_create`を呼び出し)* 作成しました。数日後に`didit_transaction_rule_get`で状況を確認してください。問題なければ、`didit_transaction_rule_update`で`mode`を`ACTIVE`に切り替えます。プリセットをインストールしたい場合は、`didit_transaction_rule_library_list`にDiditのベロシティルールのプリセットも用意されています。

***

## セッション結果は非同期です

`didit_session_create`は`session_id`、`session_token`、ホスト型の`url`を返しますが、この時点ではまだ認証は行われていません。ユーザーが`url`を開いてフローを完了します。最終的な判定は次のいずれかで届きます。

1. `status.updated` **Webhook**（推奨）
2. `didit_session_get_decision`(フォールバックとしてのポーリング)

どちらも同じ形式で、**常に複数形の配列**となり、各エントリに`node_id`が含まれます。

```json theme={null}
{
  "session_id": "uuid",
  "status": "Approved",
  "session_kind": "user",
  "id_verifications":  [ { "node_id": "first_id", "status": "Approved", "first_name": "Jane" } ],
  "liveness_checks":   [ { "node_id": "first_liveness", "status": "Approved", "score": 95.4 } ],
  "face_matches":      [ { "node_id": "first_face_match", "status": "Approved", "score": 96.1 } ],
  "aml_screenings":    [ { "node_id": "first_aml", "status": "Approved", "total_hits": 0, "hits": [] } ],
  "reviews": []
}
```

単数形のV2キー(`id_verification`、`liveness`)は決して読み取らないでください。これらはWebhookの送信先が`webhook_version: "V2"`に明示的に固定されている場合にのみ送信されます。機能ごとのフィールドリファレンスは[データモデル](https://docs.didit.me/ja/reference/data-models.md)を、署名検証と再試行のルールは[詳細設定 → Webhook](https://docs.didit.me/ja/integration/mcp/advanced.md#webhookの処理)を参照してください。

***

## ワンプロンプト連携と組み合わせる

MCPはDiditを*運用する*のに最適です。エージェントに完全な連携(バックエンドのルート、フロントエンドSDK、Webhookハンドラー、DBスキーマ)を*作成*させるには、[連携プロンプト](https://docs.didit.me/ja/integration/integration-prompt.md)を渡してください。7つのステップを順に進め、MCPツールを呼び出してワークフロー、セッション、Webhookをその場で作成します。

***

> [card] [ツールリファレンス](https://docs.didit.me/ja/integration/mcp/tools.md)
>
> エージェントが呼び出せるすべてのツール。

> [card] [高度な機能とトラブルシューティング](https://docs.didit.me/ja/integration/mcp/advanced.md)
>
> 役割、アプリ間の動作、Webhook、セルフホスティング。


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.