> ## 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.

# ルールAPIとMCP：KYTルールをプログラムで管理

> DiditのManagement APIとMCPツールで、KYTルールをプログラムから作成・調整・バックテスト・移行できます。エンドポイント一覧と、作成→バックテスト→有効化のワークフローを解説します。

ビジネスコンソールのルール機能はすべて、アプリケーションのAPIキーを使用する**Management API**、またはサインイン済みのコンソールユーザーとして動作するAIエージェント向けの**Didit MCP**を通じて、プログラムから利用できます。これらを使うと、コードからルールを管理したり、ルールセットをバージョン管理したり、AIアシスタントにルールの作成や移行を任せたりできます。

## どの手段をいつ使うか

| 手段 | 認証 | 最適な用途 |
| - | - | - |
| **ビジネスコンソール** | コンソールへのログイン | すべての変更の人によるレビュー、ビジュアルでのルール作成とバックテスト |
| **Management API** | `x-api-key` | バックエンドからの自動化、コードによるルールセット管理、CIで管理するルールのデプロイ |
| **Didit MCP** | Sign in with Didit (OAuth) | AIアシスタントとエージェント。DiditコンソールのCopilot、Claude、Cursor、または任意のMCPクライアント |

## エンドポイント

| エンドポイント | 用途 |
| - | - |
| [`GET /v3/transactions/rules/`](https://docs.didit.me/ja/management-api/transactions/rules-list) | フィルターとパフォーマンス順でルールを一覧表示 |
| [`POST /v3/transactions/rules/`](https://docs.didit.me/ja/management-api/transactions/rules-create) | カスタムルールを作成 |
| [`GET /v3/transactions/rules/{rule_uuid}/`](https://docs.didit.me/ja/management-api/transactions/rules-get) | 実行カウンター付きでルールを1件取得 |
| [`PATCH /v3/transactions/rules/{rule_uuid}/`](https://docs.didit.me/ja/management-api/transactions/rules-update) | カスタムルールを更新、任意のルールのモードを切り替え |
| [`DELETE /v3/transactions/rules/{rule_uuid}/`](https://docs.didit.me/ja/management-api/transactions/rules-delete) | カスタムルールを完全に削除 |
| [`POST /v3/transactions/rules/backtest/`](https://docs.didit.me/ja/management-api/transactions/rules-backtest) | 仮想的なルールを履歴に照らして評価 |
| [`GET /v3/transactions/rules/library/`](https://docs.didit.me/ja/management-api/transactions/rules-library) | 150+のプリセットライブラリをインストール状況とともに閲覧 |
| [`POST /v3/transactions/rules/install/`](https://docs.didit.me/ja/management-api/transactions/rules-install) | キー、バンドル、または両方の積集合でプリセットをインストール |
| [`DELETE /v3/transactions/rules/install/`](https://docs.didit.me/ja/management-api/transactions/rules-uninstall) | キー、バンドル、または両方の積集合でプリセットをアンインストール |

対応するMCPツールは、`didit_transaction_rule_list`、`didit_transaction_rule_get`、`didit_transaction_rule_create`、`didit_transaction_rule_update`、`didit_transaction_rule_delete`、`didit_transaction_rule_backtest`、`didit_transaction_rule_library_list`、`didit_transaction_rule_install`、`didit_transaction_rule_uninstall`です。詳しくは[MCPツールリファレンス](https://docs.didit.me/ja/integration/mcp/tools.md)を参照してください。

フィールドカタログ、19種類すべての条件演算子、ベロシティウィンドウ、グループ化された条件、6種類のアクションタイプを含む完全なスキーマは、[ルールとスコアリング](https://docs.didit.me/ja/transaction-monitoring/rules.md)ページに記載されており、APIリファレンスにも組み込まれています。

## 作成、バックテスト、有効化

新しいルールを安全に展開する手順は次のとおりです。

**1. TESTモードでルールを作成する**

```bash theme={null}
curl -X POST 'https://verification.didit.me/v3/transactions/rules/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "title": "Structuring - inbound (custom)",
    "description": "20+ inbound EUR transfers, all under 10,000 EUR, 30 days",
    "category": "finance",
    "mode": "TEST",
    "evaluation_mode": "ALL",
    "scope": {
      "transaction_types": ["finance"],
      "directions": ["INBOUND"]
    },
    "conditions": [
      {"field": "currency", "operator": "eq", "value": "EUR"},
      {"field": "amount",
       "operator": "lt", "value": 10000}
    ],
    "aggregation": [
      {
        "metric": "count", "operator": "gte", "value": 20,
        "window": "30d",
        "filters": {"direction": "INBOUND",
                    "transaction_type": "finance",
                    "currency": "EUR",
                    "subject_vendor_data": "__current__"}
      },
      {
        "metric": "max", "field": "amount",
        "operator": "lt", "value": 10000, "window": "30d",
        "filters": {"direction": "INBOUND",
                    "transaction_type": "finance",
                    "currency": "EUR",
                    "subject_vendor_data": "__current__"}
      }
    ],
    "actions": [{"type": "add_score", "value": 35}]
  }'
```

ペイロードは2つの部分に分けて読みます。`scope`と`conditions`は**評価対象の取引**を表します。ここでは、EUR建てで生の`amount`が10,000未満の、入金の金融取引です。`aggregation`のエントリーは**同一の対象に対する30日間のウィンドウ**を表します。受け取り側のEUR建て金融取引が20件以上あり、そのいずれも10,000 EUR以上ではないことです。`evaluation_mode`の値にかかわらず、両方のaggregationエントリーが成立する必要があります。この設定が適用されるのは条件だけです。

この例では生の`amount`を使い、両方の部分で`currency`をEURに固定しているため、為替換算による正規化に依存しません。サンドボックスのテストデータでバックテストするには、同一の対象について30日以内に、`amount`がそれぞれ10,000未満の入金のEUR建て金融取引を20件以上送信してください。`preferred_currency_amount`も`amount_in_default_currency`も必要ありません。サンドボックスでの取り込みではこれらの取引が保存されるだけなので、バックテストは明示的に実行してください。

`TEST`ルールは新しい取引ごとに評価され、一致したはずの取引を記録しますが、取引のスコアやステータスには一切影響しません。

> [!NOTE]
>
> **aggregationフィルターは条件ではありません。** 条件が読み取るのは常に評価対象の取引だけです。aggregationフィルターは常に過去のウィンドウを絞り込むだけで、比較は等価またはリストへの包含で行います。`lt`フィルターはないため、*10,000未満の送金だけ*を数えることはできません。
>
> `max ... lt 10000`のエントリーは、ウィンドウに上限を設けるためにサポートされている方法です。これはウィンドウ内の**すべての**取引が10,000未満であることを要求するもので、少額の取引だけを数えるよりも厳格です。20件の中に12,000の送金が1件あるだけで、ルールは発動しなくなります。件数だけで判定したい場合はこのエントリーを削除し、そのことをタイトルに明記してください。このエントリーがない場合、ルールは金額を問わず入金を数えるため、50,000の入金19件の後に少額の入金1件が続くケースも一致します。

**2. 履歴に対してバックテストする**

```bash theme={null}
curl -X POST 'https://verification.didit.me/v3/transactions/rules/backtest/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "conditions": [
      {"field": "currency", "operator": "eq", "value": "EUR"},
      {"field": "amount",
       "operator": "lt", "value": 10000}
    ],
    "aggregation": [
      {
        "metric": "count", "operator": "gte", "value": 20,
        "window": "30d",
        "filters": {"direction": "INBOUND",
                    "transaction_type": "finance",
                    "currency": "EUR",
                    "subject_vendor_data": "__current__"}
      },
      {
        "metric": "max", "field": "amount",
        "operator": "lt", "value": 10000, "window": "30d",
        "filters": {"direction": "INBOUND",
                    "transaction_type": "finance",
                    "currency": "EUR",
                    "subject_vendor_data": "__current__"}
      }
    ],
    "evaluation_mode": "ALL",
    "scope": {
      "transaction_types": ["finance"],
      "directions": ["INBOUND"]
    },
    "period_days": 90
  }'
```

```json theme={null}
{ "evaluated": 4820, "matched": 12, "affected_entities": 4, "period_days": 90 }
```

`matched`の件数が予想外であれば、ルールが何らかのアクションを実行する前に、しきい値を調整する必要があります。

> [!WARNING]
>
> これから有効化する構成と**完全一致**する構成でバックテストしてください。`conditions`、`aggregation`、`evaluation_mode`、`scope`をすべて同じにします。`conditions`、`aggregation`、`scope`を省略しても、それ自体は制約を追加しません。scopeを省略すると、保存済みのルールが対象外とする方向や取引タイプが含まれる可能性があります。`evaluation_mode`を省略するとデフォルトで`ALL`になるため、`ANY`ルールで省略すると一致件数が減ることがあります。`period_days`を省略するとデフォルトで90日になり、無制限の履歴が選択されるわけではありません。

**3. 有効化する**

```bash theme={null}
curl -X PATCH 'https://verification.didit.me/v3/transactions/rules/RULE_UUID/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{"mode": "ACTIVE"}'
```

ルールは、**本番環境**のアプリケーションのすべての新しい取引に即座に適用されます。

> [!WARNING]
>
> サンドボックスのアプリケーションではルールは一切評価されません。サンドボックスの取引は
> 保存されるだけなので、サンドボックスのアプリケーションでルールを有効化しても、確認できる
> 変化は何もありません。本番稼働前にルールを試すためにサポートされている方法はバックテストです。
> 詳しくは[サンドボックスでのトランザクションモニタリング](https://docs.didit.me/ja/integration/sandbox-testing.md#サンドボックスでのトランザクションモニタリング)を参照してください。

## 他のプロバイダーからのルール移行

ルールの作成はスキーマが完全に文書化された通常のAPI呼び出しなので、他のプロバイダーからエクスポートしたルールをAIアシスタントがDiditのルールに変換できます。

1. 現在のプロバイダーからルールを**エクスポート**します。ほとんどのツールはCSVまたはExcelにエクスポートできます。
2. Diditコンソールのアシスタント（または[Didit MCP](https://docs.didit.me/ja/integration/mcp/overview.md)を接続したClaudeなど、MCPで接続した任意のエージェント）に**ファイルをドロップ**します。スプレッドシートは自動的にテキストに変換されます。
3. アシスタントが**各行を**Diditのスキーマ（条件、ベロシティウィンドウ、アクション）に**マッピング**します。何かを作成する前にそのマッピングを表示し、Diditに対応するものがない項目を明示します。
4. 承認すると、アシスタントが**ルールをTESTモードで作成**し、自社の取引履歴に対してバックテストを行い、作成済み、失敗、マッピング不可の行を報告します。
5. **数値を確認し**、問題のないルールを**有効化**します。有効化はコンソールから、または`PATCH {"mode": "ACTIVE"}`で行えます。

次のようなプロバイダーのエクスポートは、

```csv theme={null}
Rule Name,Condition,Threshold,Window (days),Action
Structuring - Small Transfers,count of outbound transfers under amount,20 transfers under 10000 EUR,30,Flag for review
High Value Wire,single transaction amount,> 50000 USD,,Decline
```

次のようなルールになります。

```json theme={null}
{
  "title": "Structuring - Small Transfers",
  "description": "20+ outbound EUR transfers, all under 10,000 EUR, 30 days",
  "category": "finance",
  "mode": "TEST",
  "evaluation_mode": "ALL",
  "scope": {
    "transaction_types": ["finance"],
    "directions": ["OUTBOUND"]
  },
  "conditions": [
    {"field": "currency", "operator": "eq", "value": "EUR"},
    {"field": "amount", "operator": "lt", "value": 10000}
  ],
  "aggregation": [
    {
      "metric": "count", "operator": "gte", "value": 20,
      "window": "30d",
      "filters": {"direction": "OUTBOUND",
                  "transaction_type": "finance",
                  "currency": "EUR",
                  "subject_vendor_data": "__current__"}
    },
    {
      "metric": "max", "field": "amount",
      "operator": "lt", "value": 10000, "window": "30d",
      "filters": {"direction": "OUTBOUND",
                  "transaction_type": "finance",
                  "currency": "EUR",
                  "subject_vendor_data": "__current__"}
    }
  ],
  "actions": [
    {"type": "add_score", "value": 35},
    {"type": "change_status", "value": "IN_REVIEW"}
  ]
}
```

CSVの行は方向と通貨を指定しているため、ルールの両方の部分にそれらを含めます。`scope`と`conditions`は、評価対象の取引を10,000未満の出金方向のEUR送金に限定し、集計フィルターは30日間のウィンドウを同じ対象者の出金方向のEUR送金に限定します。生の`amount`は単一の通貨内でしか比較できないため、上記のように通貨を固定してください。通貨をまたぐ上限を設けるには、ウィンドウ内のすべての取引に正規化された金額が必要です。`preferred_currency_amount`に切り替えるだけでは、正規化された金額があることは保証されません。過去の取引に正規化された金額がない場合、数値の集計ではゼロとして扱われることがあります。

ウィンドウを10,000 EUR未満に保つのは`max`エントリーです。集計フィルターでは*10,000未満*を表現できないためです。この方法のトレードオフについては、上記の[作成ステップ](#作成、バックテスト、有効化)の注記を参照してください。スキーマで正確に表現できない内容は、黙って近似せず、ルールの`description`に明記してください。

> [!TIP]
>
> プロバイダーのルールをカスタムルールとして作り直す前に、[ルールライブラリ](https://docs.didit.me/ja/management-api/transactions/rules-library.md)を確認してください。Diditは一般的な類型（ストラクチャリング、ベロシティ、制裁へのエクスポージャー、デバイスの使い回し、暗号資産リスク）をカバーする150+のプリセットを提供しており、プリセットは1回の呼び出しでインストールできます。

## バリデーションエラーが意図的に詳細な理由

作成と更新のエンドポイントは、条件、集計、スコープの値を、ルールエンジンが受け付ける内容と厳密に照合して検証します。不明な演算子やメトリクス、不正な形式のウィンドウ（`"30d"`ではなく`"30days"`）、無効なスコープのdirection、リストのない`contains_any`、`score`のない`fuzzy_match`、`workflow_id`のない`AWAITING_USER`への`change_status`は、いずれも`400`を返し、インデックスと問題点を示します。一度もマッチしないルールが黙って保存されることはありません。エージェントやスクリプトはエラー本文を読み、ペイロードを修正してください。`transaction_types`、`directions`、`action_types`以外のスコープキーは保存されますが、エンジンでは無視されます。これはBusiness Consoleが従来から保存してきた方法と同じです。

## 次のステップ

> [card] [ルールとスコアリング](https://docs.didit.me/ja/transaction-monitoring/rules.md)
>
> ルールの完全なスキーマ: フィールド、演算子、ベロシティウィンドウ、アクション。

> [card] [ルール作成API](https://docs.didit.me/ja/management-api/transactions/rules-create.md)
>
> リクエストとレスポンスのスキーマを含むエンドポイントリファレンス。

> [card] [ルールライブラリ](https://docs.didit.me/ja/transaction-monitoring/rules-library.md)
>
> 150+種類のプリセットカタログとバンドル。

> [card] [MCPの概要](https://docs.didit.me/ja/integration/mcp/overview.md)
>
> AIエージェントをDiditのワークスペースに接続します。


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