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

# 継続的なAMLモニタリング - 毎日の再スクリーニング

> Diditは、確認済みユーザーのAMLを毎日自動で再スクリーニングし、新たな制裁リストのヒットやステータス変更をWebhookで通知します。継続的なコンプライアンスは年$0.07からです。

継続的モニタリングは、完全なAMLプログラムに欠かせない要素です。顧客デューデリジェンスを常に最新の状態に保ち、最初のオンボーディング後に生じるリスクの可能性を特定するのに役立ちます。この機能は、AMLチェックを実施したすべてのセッションに自動で含まれ、追加の連携作業は必要ありません。

![毎日の再スクリーニングとWebhookアラートを備えた、Diditの継続的AMLモニタリングのダッシュボード](https://mintcdn.com/didit-0f962782/z6T2GHM4Zh-iSj-K/images/aml-continuous-monitoring.png?fit=max\&auto=format\&n=z6T2GHM4Zh-iSj-K\&q=85\&s=8cf8c4ecef0f78953423a598defd2b2b)

### 仕組み

Diditの継続的モニタリングシステムは、確認済みのユーザーをさまざまなウォッチリスト、制裁リスト、ネガティブメディアの情報源に対して継続的にチェックします。処理の流れは次のとおりです。

1. **毎日の自動チェック**:
   * システムは、過去に承認されたすべてのセッションに対して、毎日自動チェックを実行します
   * 各チェックでは、ウォッチリストと制裁リストの包括的なデータベースに対して、ユーザーを再スクリーニングします
   * 新たに見つかった内容を、設定済みのAMLしきい値と比較します

2. **しきい値に基づく更新**:
   * 設定したレビューしきい値を超える新たなヒットが見つかった場合、セッションのステータスは「審査中」に変わります
   * 拒否しきい値を超える新たなヒットが見つかった場合、セッションのステータスは自動的に「拒否」に変わります
   * これらのしきい値は、[ワークフロー](https://docs.didit.me/console/workflows.md)で設定したものと同じです

3. **リアルタイムの通知**:
   * ステータスが変更されると、アプリケーションにWebhook通知が届きます
   * Webhookのペイロードには、更新後のステータスと、新たなAMLヒットの詳細情報が含まれます
   * これらの通知は、標準の[Webhookシステム](https://docs.didit.me/integration/webhooks.md)と同じ形式です

4. **ビジネスコンソールの更新**:
   * すべての変更は、ビジネスコンソールに即座に反映されます
   * コンプライアンスチームは、新たなAMLヒットを調べ、詳細な結果を確認し、適切な対応を取れます
   * コンソールには、すべてのモニタリング活動とステータス変更の完全な監査証跡が保持されます

### ユーザーと法人のモニタリングを有効にする

コンソールから、ユーザーや法人全体について継続的モニタリングをオン/オフできます。インポートされたユーザーなど、AMLチェックを一度も受けていないユーザーも対象です。

1. ビジネスコンソールで**ユーザー**(または**企業**)を開き、モニタリングしたいプロファイルを選択して、**AML継続的監視**をクリックします。
2. 何かが実行される前に、ダイアログに費用の見積もりが表示されます。選択したプロファイルの数、新たなAMLスクリーニングが必要な数、1回限りのスクリーニング費用、年間のモニタリング費用です。
3. **監視を有効にする**をクリックします。少数の選択はすぐに完了し、大量の選択はバックグラウンドで実行され、ダイアログに進捗がライブ表示されます。
4. 実行が終わると、ダイアログにプロファイルごとの結果が内訳として表示されます。有効化、スクリーニングして有効化、すでに有効、またはスキップ(理由付き。たとえば、スクリーニングに必要な氏名、生年月日、国が揃っていないプロファイル)です。

知っておくと役立つ点がいくつかあります。

* **AMLスクリーニングのないプロファイルは、先にスクリーニングされます。** Diditはそれらに対して新たなAML認証を作成し(プロファイルの**認証**タブに表示されます)、通常のAMLスクリーニングとして課金します。その後、そのスクリーニングでモニタリングが有効になります。
* **プロファイルごとに、モニタリング対象のスクリーニングは1つ。** 有効にすると、ユーザーまたは法人ごとにモニタリング対象のAMLスクリーニングがちょうど1つに保たれるため、複数回認証した人でも、モニタリングも課金も1回だけです。無効にすると、そのプロファイルのすべてのスクリーニングでモニタリングがオフになります。
* **一覧でモニタリングの状況がひと目でわかります。** **ユーザー**と**企業**の両方の一覧に**継続的な監視**列があり、カーソルを合わせると次回の年次請求日が表示されます。
* **すべて選択はフィルターに対応します。** すべての行を選択した場合、操作は読み込み済みのページだけでなく、現在のフィルター結果に適用されます。

### APIでモニタリングを有効にする

同じ操作を、APIキーを使ってバックエンドからも実行できるため、モニタリングを変更するためにプロファイルを再スクリーニングしたり、コンソールを開いたりする必要はありません。

* ユーザー向け: [`POST /v3/users/aml-monitoring/`](https://docs.didit.me/management-api/aml-monitoring/toggle-users)
* 法人向け: [`POST /v3/businesses/aml-monitoring/`](https://docs.didit.me/management-api/aml-monitoring/toggle-businesses)
* ジョブをポーリングする: [`GET /v3/aml-monitoring/jobs/{job_id}/`](https://docs.didit.me/management-api/aml-monitoring/get-job)

どちらの切り替えエンドポイントも、お客様独自の識別子のリスト(`vendor_data_list`)、Diditのid(`didit_internal_id_list`)、またはその両方を、1回の呼び出しで最大1000件まで受け付け、コンソールのルールにそのまま従います。プロファイルごとにモニタリング対象のスクリーニングは1つ、スクリーニングのないプロファイルは先にスクリーニングされ、無効にするとそのプロファイルのすべてのスクリーニングでモニタリングがオフになります。

```bash theme={null}
# 1. Preview the cost. Nothing is written.
curl -X POST https://verification.didit.me/v3/users/aml-monitoring/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"is_enabled": true, "estimate_only": true, "vendor_data_list": ["user-123", "user-456"]}'

# 2. Enable monitoring. 20 profiles or fewer complete inline (200);
#    larger selections return 202 and a job_id to poll.
curl -X POST https://verification.didit.me/v3/users/aml-monitoring/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"is_enabled": true, "vendor_data_list": ["user-123", "user-456"]}'
```

レスポンスには、コンソールのダイアログと同じ内訳に加えて、プロファイルごとに1件の`results`エントリとその結果が含まれます。結果は`enabled`、`screened_and_enabled`、`already_enabled`、`disabled`、または`skipped_no_identity_data`のようなスキップ理由です。どれにも一致しなかった識別子は`unmatched`に返されます。モニタリングの切り替え自体はWebhookを発行しません。モニタリングがオンになると、再スクリーニングで通常の`status.updated`と`data.updated`イベントが発火します。

### モニタリングが実行されたことを証明する

上記のアラート、アクティビティのエントリ、Webhookはすべて、**変更**があったときに発火します。1年間毎日スクリーニングされ、新たなヒットがなかった対象者には、そのどれも生成されません。そのため、「変化なし」と「何も実行されていない」が区別できず、これでは監査に耐える回答にはなりません。実行そのものを記録する画面が3つあります。

**1. AMLレポート上の最終スクリーニング日。** `last_ongoing_screening_at`は、変更の有無にかかわらず、実行が完了するたびに更新されます。`/v2/`と`/v3/`のセッション判定、およびスタンドアロンのAMLレポートで確認できます。併せて表示される`last_ongoing_screening_datasets_updated_at`は、その実行時にプロバイダーが報告した、直近のAMLデータセットの更新日です。どちらも推定されることはありません。`null`は、それぞれ「一度も再スクリーニングされていない」「データセットの日付が報告されていない」を意味し、「不明だからそれらしい日付を入れた」という意味ではありません。`next_ongoing_monitoring_bill_date`をスクリーニング日として読まないでください。これは請求日です。

**2. 対象者ごとのスクリーニング履歴。** `GET /v1/session/{session_id}/aml-screening-history/`は、そのセッションのAMLチェックについて、完了したすべての実行を新しい順に返します。結果が`NO_CHANGE`だった実行も含まれます。グラフワークフローにAMLノードが複数ある場合は、`?node_id=`を追加します。

```bash theme={null}
curl https://verification.didit.me/v1/session/SESSION_ID/aml-screening-history/ \
  -H "x-api-key: YOUR_API_KEY"
```

```json theme={null}
{
  "count": 2,
  "results": [
    {
      "uuid": "0d1c...",
      "completed_at": "2026-09-12T04:03:11Z",
      "started_at": "2026-09-12T04:00:02Z",
      "outcome": "NO_CHANGE",
      "trigger": "ONGOING_MONITORING",
      "status": "Approved",
      "score": 0,
      "total_hits": 0,
      "dataset_freshness": null
    }
  ]
}
```

| フィールド | 意味 |
| - | - |
| `outcome` | `NO_CHANGE` — 実行が完了し、結果は変わらなかった。`CHANGED` — 実行が完了し、スコア、ステータス、またはヒットが変わった。`FAILED` — プロバイダーがこの対象者について利用できる回答を返さなかったため、何もスクリーニングされず、何も変更されなかった。カバレッジの欠落は、隠されずに記録されます。 |
| `completed_at` / `started_at` | この対象者のスクリーニングが完了した時刻と、それが属していたバッチが開始された時刻。 |
| `status` / `score` / `total_hits` | 実行後にチェックが置かれた状態。 |
| `dataset_freshness` | その実行時に、プロバイダーのリストがどれだけ最新だったか。データセットの日付が得られなかった場合は`null`。 |

**3. エクスポート可能な証拠。** `GET /v1/session/{session_id}/aml-screening-history/export/`は、同じ履歴をCSVファイルとしてストリーミングします。完了したスクリーニングごとに1行で、プロバイダーが報告した場合はソースファミリーごとのデータセット更新日が入り、報告されなかった場合は空のセルになります。このファイルは、コンプライアンスチームが監査人に提出するものです。ビジネスコンソールでは、AMLの結果の隣に同じ一覧と同じエクスポートが用意されているため、レビュー担当者はAPIにアクセスしなくても作成できます。

> [!NOTE]
>
> **提供範囲の制限を明示します。** 履歴は、この機能が提供開始された時点以降のものが記録されます。それ以前のスクリーニングは再構築されず、単に存在しません。実行履歴は、設定された保持期間(デフォルトでは2年間)保管されます。データセットの鮮度は、お使いの環境でプロバイダーがデータセットの日付を公開しているかどうかに依存します。公開されていない場合、すべてのデータセットのフィールドは`null`になり、`GET /v1/aml/dataset-freshness/`は`availability: "not_configured"`を報告します。存在しない日付が代わりの値で置き換えられることはありません。

### 継続的モニタリングのメリット

1. **継続的なコンプライアンス**: 追加の設定なしで、AML/KYC規制への継続的な準拠を確保します。
2. **リスクの軽減**: 自動モニタリングにより、新たに生じるリスクをすばやく特定し、対処できます。
3. **業務効率**: 手間のかかる手動の再スクリーニングを、追加の連携作業なしで自動化します。
4. **強化されたデューデリジェンス**: 顧客プロファイルを自動で最新の状態に保ちます。
5. **規制当局への対応**: 継続的なコンプライアンスの取り組みを、規制当局に簡単に示せます。
6. **ゼロタッチ連携**: 追加の開発作業なしで、継続的モニタリングを利用できます。


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