ルール記述ガイド

本ガイドは、Merlon の CDD（顧客デューデリジェンス）リスクウェイト、国リスクテーブル、トランザクションモニタリング（TM）シナリオを定義するコンプライアンス担当者・ルール作成者向けである。設定としてのプロダクト（Configuration as the Product）の設計原則の下、これらのルールはアプリケーションコードではなくバージョン管理された JSON/YAML 設定として表現される。これにより、ソフトウェアのリリースを経ることなく、自組織のルールガバナンスプロセスを通じて作成・レビュー・承認できる。

ルールの所在

ルールの内容はリポジトリ内の content/ 配下に存在する。

content/schema/ — 各ルール種別を検証する JSON Schema。
content/_sample/ — フォーマットを示す Apache-2.0 ライセンスのサンプルルール。これらは本番運用に対応した管理策ではなく、サンプルディレクトリの README.md および各サンプルファイルがこの点を明示している（該当する場合は is_sample: true）。

Rust Engine は CDD ウェイト、国リスクテーブル、TM シナリオを運用者が提供するファイルから直接読み込む。例えば MERLON_CDD_WEIGHTS_PATH や MERLON_TM_SCENARIOS_PATH（設定リファレンス参照）である。これらのファイルはデータベースに基づくルール監査証跡の外にあるため、ADR-0012（Engine Configuration File Trust Boundary）に記載の通り、そのソース管理、変更承認、アクセス制御、バックアップは自組織の責任となる。Engine は起動時及び ConfigService RPC を通じて、読み込んだ設定の決定論的ダイジェストを出力するため、事後にデプロイ済みのルールセットを検証できる。これは監査を支援するものであり、ファイルレベルのアクセス制御を代替するものではない。

CDD ウェイト定義

CDD ウェイト定義は、重み付けされたリスク要因（「軸」）を顧客に割り当て、組み合わされたスコアからリスクティアを導出する。スキーマは content/schema/cdd_weight_v1.json（リファレンス）。最小限の実例は content/_sample/cdd_basic_weights.yaml。

schema_version: cdd_weight_v1
id: cdd_basic_weights
name: Basic CDD Risk Weights
version: 1
is_sample: true

axes:
  customer_attributes:
    weight: 0.25
    factors:
      - name: customer_type
        scores:
          individual: 1
          corporate_domestic: 2
          corporate_foreign: 4
      - name: account_age_months
        ranges:
          - max: 3
            score: 4
          - max: 12
            score: 2
          - min: 12
            score: 1

  geography:
    weight: 0.30
    factors:
      - name: country_risk
        scores:
          low: 1
          medium: 3
          high: 5

tier_thresholds:
  low:
    max_score: 2.0
  medium:
    min_score: 2.0
    max_score: 3.5
  high:
    min_score: 3.5

スキーマ上の必須フィールド: schema_version（リテラル cdd_weight_v1 である必要がある）、id（小文字、^[a-z][a-z0-9_]*$）、name、version（正の整数）、axes、及び tier_thresholds（low、medium、high を定義する必要がある）。axes 配下の各エントリには weight（0〜1）と factors 配列が必須。factor は値を直接スコアリングする（観測値をキーとする scores）か、数値範囲をスコアリングする（min/max の境界と score を持つ ranges）ことができる。

factor はインラインの scores マップの代わりに、source を country_risk_table に設定することで国リスクテーブルへスコアリングを委譲することもできる（engine/crates/merlon-engine/src/scoring/country_risk.rs 参照）。国別のリスクロジックを、すべての CDD ウェイト定義に重複させるのではなく一箇所で保守すべき場合にこれを利用する。

サンプルを本番用ルールに置き換えた場合は、content/README.md の指針に従い is_sample: false を設定する（または省略する）。

国リスクテーブル

国リスクテーブルは、明示的に列挙されていない国向けのデフォルト値とともに、ISO 国コードごとに数値のリスクスコア（1〜5）を割り当てる。スキーマは content/schema/country_risk_v1.json（リファレンス）。例は content/_sample/country_risk_sample.yaml より。

schema_version: "1.0"
content_type: country_risk_table
name: Sample Country Risk Table
effective_date: 2026-07-01
default_score: 3
countries:
  JP: { score: 1 }
  US: { score: 1 }
  KP: { score: 5, reason: "FATF blacklist / foreign exchange sanctions" }
  IR: { score: 5, reason: "FATF blacklist" }
  MM: { score: 4, reason: "FATF grey list" }

必須フィールド: schema_version、content_type（リテラル定数 country_risk_table）、effective_date（日付）、default_score（1〜5）、及び countries。各国キーは ^[A-Z]{2}$（ISO 3166-1 alpha-2 コード）に一致する必要があり、そのエントリには score が必須。reason は任意だが、監査可能性優先（Auditability First）原則に沿い、ある法域がなぜそのようにスコアリングされたかの追跡可能性のために推奨される。

TM シナリオ

TM（トランザクションモニタリング）シナリオは検知ルール（例えば集計ベースのストラクチャリングチェック）と、それが生成するアラートの重大度を定義する。新規シナリオは v2 スキーマである content/schema/tm_scenario_v2.json（リファレンス）に対して作成すること。例は content/_sample/tm_scenarios/structuring_basic.yaml を基にしたもの。

schema_version: "2.0"
scenario_id: tm_structuring_basic
name: "Structuring Detection (Basic)"
description: "Detects transaction splitting intended to evade reporting thresholds"
type: aggregation
conditions:
  transaction_type:
    - deposit
    - transfer_in
  aggregation:
    field: amount
    function: sum
    period: 24h
    group_by: customer_id
  threshold:
    by_customer_type:
      individual:
        by_risk_tier:
          LOW: 2000000
          MEDIUM: 1000000
          HIGH: 500000
      corporate_domestic:
        by_risk_tier:
          LOW: 2000000
          MEDIUM: 1000000
          HIGH: 500000
  additional:
    min_transaction_count: 3
evaluation_mode: both
severity: HIGH
tags:
  - structuring

必須フィールド: schema_version、scenario_id、name、type（現時点では aggregation のみ定義済み）、conditions、及び severity。conditions の下で、threshold.by_customer_type はシナリオごとに顧客種別ごとの異なるしきい値を設定でき、各顧客種別内では by_risk_tier.{LOW,MEDIUM,HIGH} が顧客の CDD リスクティアごとにしきい値を設定する。これは Score-Driven Architecture 原則の具体的な仕組みであり、顧客の CDD スコアがどの TM しきい値が適用されるかを決定する。evaluation_mode はシナリオがバッチジョブ・インライン・両方のいずれで実行されるかを制御し、省略された場合 v2 シナリオはデフォルトで batch となる。

v1 コンテンツとデュアルサポート

既存の tm_scenario_v1 コンテンツは強制移行の対象ではない。ADR-0006（tm_scenario_v2 Schema and v1 Dual Support）に基づき、Engine は v2 のロールアウトから少なくとも12ヶ月間 v1 コンテンツをデュアルサポートし、v1 のフラットな risk_tier_adjustments を、評価結果のセマンティクスを変えることなく、読み込み時に同等の「すべての顧客種別で同一しきい値」という v2 形式に内部変換する。content/schema/tm_scenario_v1.json（リファレンス）はこの互換性期間中は引き続き利用可能である。新規シナリオは v1 ではなく v2 に対して直接作成すべきである。

ルールファイルの検証

デプロイ前に、すべてのルールファイルをそのスキーマに対して検証すること。これは組織的な承認ステップに先立ち、レビューまたは CI プロセスの一部として実行すべき機械的なチェックである。ルールスキーマ配下のスキーマリファレンスページは、cdd_weight_v1、country_risk_v1、tm_scenario_v1、tm_scenario_v2 のすべてのフィールドと制約を文書化しており、content/schema/ 内の JSON Schema ファイルから直接生成されるため、Engine が実際に強制する内容と同期し続ける。

スコア駆動のロールアウト

CDD スコアはシステムの中心軸であるため（アーキテクチャ及び ADR-0004、Score-Driven Architecture 参照）、CDD ウェイト定義の変更は、顧客がどのリスクティアに分類されるかを変化させ、それが今度はどの TM しきい値が適用されるか、ケースの優先度、スクリーニング頻度を変化させる。CDD ウェイトの変更は、その影響が単一の検知ルールに限定されず間接的かつシステム全体に及ぶため、TM シナリオの変更と同等かそれ以上の注意を払って扱うこと。

docs/configuration.md の運用しきい値に関する指針はここにも同様に適用される。content/_sample/ のサンプルルールは一例であり、本番のデフォルト値ではない。しきい値は自組織の文書化されたリスクアセスメントから選定し、デプロイ前に変更をテストし、変更を自組織のルールガバナンスプロセスに通すこと。フェイルアラート（Fail-Alert）原則の下、新規または変更されたルールに関する不確実性は、アラートの抑制ではなく追加のレビューへ向けて解消すること。例えば、しきい値の選択が曖昧な場合、より狭い網（アラート数は少ないが見逃しの可能性が高い）よりも、より広い網（レビューして棄却される一致が多くなる）を選好する。

ルールの所在​

CDD ウェイト定義​

国リスクテーブル​

TM シナリオ​

v1 コンテンツとデュアルサポート​

ルールファイルの検証​

スコア駆動のロールアウト​