はじめに
連携 / SDK
ユーザー認証
法人確認
トランザクションモニタリング
変更履歴どの手段をいつ使うか
エンドポイント
対応する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ツールリファレンスを参照してください。
フィールドカタログ、19種類すべての条件演算子、ベロシティウィンドウ、グループ化された条件、6種類のアクションタイプを含む完全なスキーマは、ルールとスコアリングページに記載されており、APIリファレンスにも組み込まれています。
作成、バックテスト、有効化
新しいルールを安全に展開する手順は次のとおりです。1
TESTモードでルールを作成する
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ルールは新しい取引ごとに評価され、一致したはずの取引を記録しますが、取引のスコアやステータスには一切影響しません。aggregationフィルターは条件ではありません。 条件が読み取るのは常に評価対象の取引だけです。aggregationフィルターは常に過去のウィンドウを絞り込むだけで、比較は等価またはリストへの包含で行います。
ltフィルターはないため、10,000未満の送金だけを数えることはできません。max ... lt 10000のエントリーは、ウィンドウに上限を設けるためにサポートされている方法です。これはウィンドウ内のすべての取引が10,000未満であることを要求するもので、少額の取引だけを数えるよりも厳格です。20件の中に12,000の送金が1件あるだけで、ルールは発動しなくなります。件数だけで判定したい場合はこのエントリーを削除し、そのことをタイトルに明記してください。このエントリーがない場合、ルールは金額を問わず入金を数えるため、50,000の入金19件の後に少額の入金1件が続くケースも一致します。2
履歴に対してバックテストする
matchedの件数が予想外であれば、ルールが何らかのアクションを実行する前に、しきい値を調整する必要があります。3
有効化する
他のプロバイダーからのルール移行
ルールの作成はスキーマが完全に文書化された通常のAPI呼び出しなので、他のプロバイダーからエクスポートしたルールをAIアシスタントがDiditのルールに変換できます。- 現在のプロバイダーからルールをエクスポートします。ほとんどのツールはCSVまたはExcelにエクスポートできます。
- Diditコンソールのアシスタント（またはDidit MCPを接続したClaudeなど、MCPで接続した任意のエージェント）にファイルをドロップします。スプレッドシートは自動的にテキストに変換されます。
- アシスタントが各行をDiditのスキーマ（条件、ベロシティウィンドウ、アクション）にマッピングします。何かを作成する前にそのマッピングを表示し、Diditに対応するものがない項目を明示します。
- 承認すると、アシスタントがルールをTESTモードで作成し、自社の取引履歴に対してバックテストを行い、作成済み、失敗、マッピング不可の行を報告します。
- 数値を確認し、問題のないルールを有効化します。有効化はコンソールから、または
PATCH {"mode": "ACTIVE"}で行えます。
scopeとconditionsは、評価対象の取引を10,000未満の出金方向のEUR送金に限定し、集計フィルターは30日間のウィンドウを同じ対象者の出金方向のEUR送金に限定します。生のamountは単一の通貨内でしか比較できないため、上記のように通貨を固定してください。通貨をまたぐ上限を設けるには、ウィンドウ内のすべての取引に正規化された金額が必要です。preferred_currency_amountに切り替えるだけでは、正規化された金額があることは保証されません。過去の取引に正規化された金額がない場合、数値の集計ではゼロとして扱われることがあります。
ウィンドウを10,000 EUR未満に保つのはmaxエントリーです。集計フィルターでは10,000未満を表現できないためです。この方法のトレードオフについては、上記の作成ステップの注記を参照してください。スキーマで正確に表現できない内容は、黙って近似せず、ルールのdescriptionに明記してください。
バリデーションエラーが意図的に詳細な理由
作成と更新のエンドポイントは、条件、集計、スコープの値を、ルールエンジンが受け付ける内容と厳密に照合して検証します。不明な演算子やメトリクス、不正な形式のウィンドウ（"30d"ではなく"30days"）、無効なスコープのdirection、リストのないcontains_any、scoreのないfuzzy_match、workflow_idのないAWAITING_USERへのchange_statusは、いずれも400を返し、インデックスと問題点を示します。一度もマッチしないルールが黙って保存されることはありません。エージェントやスクリプトはエラー本文を読み、ペイロードを修正してください。transaction_types、directions、action_types以外のスコープキーは保存されますが、エンジンでは無視されます。これはBusiness Consoleが従来から保存してきた方法と同じです。
次のステップ
ルールとスコアリング
ルールの完全なスキーマ: フィールド、演算子、ベロシティウィンドウ、アクション。
ルール作成API
リクエストとレスポンスのスキーマを含むエンドポイントリファレンス。
ルールライブラリ
150+種類のプリセットカタログとバンドル。
MCPの概要
AIエージェントをDiditのワークスペースに接続します。