# AMLヒットへの対応

Source: https://help.didit.me/ja/aml-screening/resolving-aml-hits
Updated: 2026-10-12

ヒットは判定ではなく候補です。それが自社の顧客かどうか、重要かどうかを判断し、監査に耐えられる形で判断内容を記録する方法を説明します。

順番に2つの問いを立ててください。**これは自社の顧客か**（マッチスコア）、そして**重要かどうか**（リスクスコアとカテゴリー）です。ほとんどのヒットは最初の問いで不合格になります。非常に大規模なリストに対して名前が一致しているだけのケースです。いずれの結論であっても判断理由を記録してください。監査担当者が読むのはその判断の経緯です。

## ヒットは候補である

スクリーニングエンジンの役割は、リストに載っている可能性のある人物を洗い出すことです。それが本当にそうなのか、そしてどう対応するかを決めるのはあなたです。`POSSIBLE_MATCH_FOUND`という警告は、まさにその意味しか持ちません。

![Didit コンソール: AMLヒットへの対応](https://help.didit.me/screenshots/sessions-bulk-light.webp)

*ヒットは、それが属するセッションの判定を決めることで解決されます。*

## ステップ1: これは本当に自社の顧客か

ヒットに含まれる識別情報を、検証で確認済みの情報と照合します。

| 比較項目 | 有効な理由 |
|---|---|
| 生年月日 | 最も強い判別要素です。不一致であれば、たいていそれで決着します |
| 国籍と国 | 自社の顧客とまったく関わりのない国でのヒットです |
| ミドルネームや父称を含むフルネーム | 部分的な名前の一致が、誤検知の主な原因です |
| ヒット記録上の識別番号 | リストに掲載されている場合 |

よくある名前は、制裁リストやPEPリストに対して大量の低信頼度マッチを生みます。これは不具合ではなく、名前ベースのスクリーニングの性質です。キューがこれで埋まっている場合、マッチ閾値が低すぎます。[AMLスクリーニング結果の理解](https://help.didit.me/ja/aml-screening/how-aml-screening-works)をご覧ください。

> **Tip:** ここでは音訳が重要です。非ラテン文字の名前は複数の妥当なローマ字表記を持ち得るため、同一人物が文字列として一致しない綴りで現れたり、逆に異なる人物が同じ綴りに収束したりすることがあります。そうしたケースでは、生年月日と国籍をより重視してください。

## ステップ2: 重要かどうか

AML欄で**一致を確認**または**一致しない**を選びます。複数の結果をまとめて除外できます。変更は**レビュー**に記録され、認証への書き込み権限が必要です。その後、セッションの判定と理由を記録します。

- **制裁マッチ。** 最も深刻なものです。自社の制裁対応手順に従って処理してください。安易に判断してよいものではありません。
- **PEP。** PEPは犯罪者ではありません。多くの規制体系では、PEPステータスは拒否ではなく**強化された継続的顧客管理**（追加情報の取得、資金源の確認、上級者による承認など）を引き起こします。PEPを自動的に拒否するのは1つのポリシー上の選択ですが、通常は望ましくない選択です。
- **RCA。** PEPの親族や近しい関係者で、同じ理由でスクリーニングされ、通常は同様に扱われます。
- **ネガティブ報道。** タグ付けされたカテゴリーを読んでください。1回報じられた申立ては有罪判決ではなく、自社のポリシーはその違いを区別すべきです。
- **国・地政学的リスク。** 通常は判断そのものではなく、リスク評価の入力値です。

## ステップ3: 判断を記録する

コンソールでヒットを解決する際は、判断理由を説明するメモを添えてください。ここが後から重要になる部分です。監査担当者が関心を持つのは、ヒット率そのものよりも、判断が一貫した方法で行われ、証跡が残っているかどうかです。

2年後にあなたがいない状態で、他の誰かが読むことを想定してメモを書いてください。実際にそうなるからです。「生年月日が14年異なり、国籍も異なるため棄却」は有用です。「マッチではない」は有用ではありません。

すべての操作は365日間、監査ログに記録されます。[監査ログの利用](https://help.didit.me/ja/account-organization/audit-logs)をご覧ください。

## 見落としなく誤検知を減らす

ケース管理と二者審査が有効な場合、別の審査担当者による確認が必要です。利用可否はケースの設定と権限によります。

## 4アイズ承認

AML判断に2人のレビュアーを必要とするプロセスの場合、Diditは2人目が確認を行う4アイズフローに対応しています。[4アイズレビュー](https://docs.didit.me/console/case-management/four-eyes)をご覧ください。

## モニタリングはヒットを再び呼び戻す

継続的モニタリングを有効にしている場合、以前承認された顧客が後から新たなヒットを生み、**審査中**に戻ることがあります。これは不具合ではなく機能が正しく動作している証拠であり、ヒットの解決がオンボーディング時だけの単発作業ではなく、継続的に人員配置すべきプロセスであることを意味します。[継続的AMLモニタリング](https://help.didit.me/ja/aml-screening/ongoing-monitoring)をご覧ください。

## 本番前に練習する

サンドボックスには2つのAMLシナリオがあります。`decline_aml_hit`は拒否に至るヒットを生成し、`review_aml_possible_match`は、スコアの内訳を含む実際のヒットと同じスキーマで、審査中となる低信頼度のヒットを生成します。実際の顧客を待たせる前に、これらを使ってチームに解決プロセスを練習させてください。[サンドボックスでのテスト](https://help.didit.me/ja/getting-started/sandbox-and-testing)をご覧ください。