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

# ケース管理 - ケースとライフサイクル

> Didit のケース管理では、1人のユーザーまたは1社の企業に紐づく調査ケースを作成、対応、解決できます。保存済みビュー、SLA期限、一括アクションにも対応しています。

Case Managementは、Didit Consoleにおける調査の中核です。AMLのヒット、フラグが付いた認証、不審な取引はいずれも**ケース**にでき、コンプライアンスチームは開始から解決まで、完全な監査ログを記録しながら対応できます。

***

## ライフサイクル

ケースのステータスは、次の3つだけです。

| ステータス | 意味 |
| - | - |
| `Open` | 調査中 |
| `Awaiting user` | 認証済みユーザーから追加情報を収集する間、一時停止中 |
| `Resolved` | 調査が完了し、解決内容が記録済み |

ケースを解決するには、解決内容の指定が必要です。

| 解決内容 | 意味 |
| - | - |
| `False positive` | 正当な活動だった |
| `Valid threat` | 不審または不正な活動であることが確認された |

すべてのケースには**優先度**(`Low`、`Medium`、`High`、デフォルトは`Medium`)と、任意の**期日**も設定されます。期日はSLAに基づく並べ替えと期限超過フラグに使われます。

> [!NOTE]
>
> `Under review`、`On hold`、`Pending approval`、`Critical`の重大度やケース種別という分類軸はありません。ライフサイクルは意図的に固定されており、ケースの作成方法にかかわらず、すべてのケースで分析、SLA、権限が明確になるようにしています。

## ケースごとに対象は1つ

すべてのケースは、**ちょうど1人**のユーザーまたは1つの企業に紐付けられます。1つのケースで複数の対象者を混在させることはできません。また、ケースとは異なる対象者に属するセッション、企業セッション、取引を紐付けることもできず、紐付けようとすると明確なエラーが返されます。

これにより、各ケースページでは1つの対象に焦点を絞ることができます。対象者カード、リスク概要、書類、財務データはすべて、そのケースで調査している同じ人物または企業に関するものです。別のエンティティをレビューするには、別のケースを開いて(または作成して)ください。

## Fraud Checkのソースコンテキスト

Fraud Checkセッションからケースを作成すると、そのチェックID、リクエストID、レビュアーが開いていたセクションが保持されます。
ソースカードには、ケース作成時点のセッションのアナリストステータスも記録されます。
ケースの判定とソースの判定は別々に管理されます。

APIクライアントは、ケース作成時に`check_id`、`request_id`、`source_section`を含む`source_context`を指定できます。
そのリクエストを`links`に`session`エントリとして含めてください。
チェックと紐付けるセッションは、選択したアプリケーションに属し、かつ互いに紐付いている必要があります。
APIはアナリストステータスを自ら読み取り、このコンテキストで呼び出し元が指定したステータス、推奨、ソース種別のフィールドは拒否します。

## 一覧

Case Managementの上部ナビゲーションでは、**ケース**、**概要**、**割り当て**を常に利用できます。
ケースのワークスペースには、**オープン**、**ユーザー待ち**、**解決済み**、**すべて**のステータスビューがあります。
デスクトップでケースを開くと、ケースのキューが詳細の横に表示されたままになります。
モバイルでは、パンくずリストを使ってキューに戻ります。

検索は、対象者の名前またはID、タグ、ケース番号、ケースタイトル、紐付けられたセッションID、紐付けられた取引IDに一致します。そのため、セッションまたは取引のUUIDを貼り付けると、該当するケースに直接移動できます。

フィルターチップ:**ブループリント**、**作成日**、**ソース**、**担当者**、**タグ**に加え、**フィルターを追加**から**優先度**と**期限**を追加できます。

列:作成日(日付と作成者)、ケース詳細(タイトル)、ステータス、ブループリント、対象者(名前とID)、対象者タグ、担当者、優先度、期日。横スクロールと列の設定から、さらに多くの列を利用できます。

### 並べ替えとSLA

**作成日**(デフォルト)または**期日**で並べ替えます。期日で並べ替えると、期限超過のケースが先頭に表示されます。ケースがオープンまたはユーザー待ちのまま期日を過ぎると期限超過となり、赤い期限チップで表示されます。

### 保存済みビュー

**ビューを保存**で現在のフィルターと列の組み合わせを名前付きビューとして保存し、**ビューを選択**でビューを切り替え、**フィルターをクリア**でリセットします。ビューは個人ごとのもので、他のコンソールのテーブル設定と同じ方法で保持されます。

### 一括アクション

複数のケースを選択して、次の操作ができます。

* **割り当て先**で担当者を指定する。選択したすべてのケースは同じブループリントである必要があり、そうでない場合は送信前にコンソールが警告します。
* **ステータスを設定**で、ユーザー待ち、再オープン、解決(解決内容と任意のメモを指定)に変更する。各ケースは個別に評価されるため、未完了のチェックリストや必須メモの欠落によってブロックされたケースは個別に報告され、バッチの残りが失敗することはありません。

### エクスポート

一覧のメニューには2種類のCSVエクスポートがあり、[レポートページ](https://docs.didit.me/ja/console/export-pdf-csv.md)から配信されます。

* **全ケースレポート**:ケースごとに1行で、ステータス、解決内容、優先度、タグ、紐付けられた取引、最後に提出したFIU報告を含みます。
* **SLAレポート**:ケースごとの時間指標で、割り当てまでの時間、解決までの時間、期限超過、SLA達成のフラグを含みます。

## 対象者へのアクションと再試行

対象者カードでは、権限のあるレビュアーが対象者のステータス変更、タグの追加、内部メモの追加、対象者のブロックリストへの追加を行えます。
これらのアクションは、ケースの解決とは別のものです。
**対象者へのアクション**セクションには、リクエストされた各アクションが**適用済み**または**失敗**として記録され、そのレビュアーと時刻が示されます。
現在の対象者を確認したうえで、**アクションを再試行**を使用して失敗したアクションを再試行します。
適用済みのアクションは、そのリクエストを再試行しても再度実行されません。

APIクライアントは、ケースの`entity-actions/`エンドポイントへの各リクエストに一意の`client_reference`を送信してください。
接続エラー後にリクエストを再試行する場合は、同じリファレンスと入力を使用してください。
同じリファレンスで入力を変更すると`409`が返されます。
リファレンスを指定した場合は`receipt.status`を確認してください。`200`レスポンスに失敗したレシートが含まれることがあり、その場合はアクションが適用されていません。
失敗したリクエストを再試行するには、`retry: true`を指定するか、その`action-receipts/{receipt_uuid}/retry/`エンドポイントを呼び出す必要があります。
履歴エンドポイントは1ページあたり最大20件のレシートを返し、追加の結果用に`next_offset`を返します。
`client_reference`を省略している既存のAPIクライアントは、従来のレスポンス動作のまま変わりません。

## タグ

関連する調査をまとめるには、ケースのヘッダーにある **タグを追加** からケースにタグを追加します。一覧からタグでフィルターや検索を行うこともできます。タグの変更はケースのタイムラインに記録されます。

## 関連ページ

> [card] [ケースの作成](https://docs.didit.me/ja/console/case-management/creating-cases.md)
>
> ユーザー、企業、セッション、取引、自動コネクタといったすべての作成経路を説明します。

> [card] [ブループリント](https://docs.didit.me/ja/console/case-management/blueprints.md)
>
> 割り当て、エスカレーション、移管、ケースページの内容を設定します。

> [card] [チェックリスト](https://docs.didit.me/ja/console/case-management/checklist.md)
>
> 必須の調査ステップが完了するまでケースを解決できないようにします。

> [card] [4-eyesレビュー](https://docs.didit.me/ja/console/case-management/four-eyes.md)
>
> 慎重な判断が必要な解決に対して、作成者と承認者による二重承認を行います。

## 顧客へのメッセージ

**Message customer**を使うと、確認済みの連絡先に送る定型の依頼やレビュー状況の更新をプレビューできます。
配信状態、セキュアな返信、APIのワークフローについては、[顧客へのメッセージ](https://docs.didit.me/ja/console/case-management/customer-messages.md)を参照してください。

## ディスカッションとピン留めメモ

ケースのステータスの横にあるディスカッションボタンをクリックすると、調査画面を離れずにメモを確認できます。
メモのメニューから、返信やピン留めができます。
ピン留めしたメモは先頭に表示され、返信には親メモの短い抜粋が表示されます。
ピン留めの変更はケースのアクティビティに記録され、ソース側の判定は変更されません。

削除を確定すると、メモと、返信に引用されたその抜粋が完全に削除されます。
返信自体は引き続き閲覧できます。
添付ファイルは、他のメモでまだ使用されていない限り削除されます。

APIクライアントは、メモを追加する際に`client_reference`としてUUIDを指定できます。
内容を変更せずに再試行すると、通知を重複させることなく既存のメモが返されます。
同じ参照を異なる内容で再利用した場合や、削除済みのメモに対して再利用した場合は`409`が返されます。
同じケース内の削除されていないメモを参照するには`reply_to`を指定し、`is_pinned`はメモの`PATCH`エンドポイントで更新します。

## 既存の調査の確認

共通のケース作成ダイアログでは、選択したユーザー、企業、または紐付けられたソースについて既存の調査があるかを確認します。
既存のケースを開くと、そのレビューを続けられます。
クローズ済みのケースも表示されるため、開いて再オープンするかどうかを判断できます。
別の調査として作成するには、異なるインシデントとして扱う理由を入力してください。
入力した理由は新しいケースとともに保存され、その概要に表示されます。
送信時にコンソールは重複を再確認し、ダイアログを開いている間に他のレビュアーが作成したケースも対象に含めます。

API連携では、`POST .../cases/duplicates/`で重複を確認し、ケース作成時に`review_duplicates=true`を設定できます。
既存の調査が見つかった場合、`separate_incident_reason`を指定しない限り、作成リクエストは`409`を返します。
重複確認エンドポイントは1ページあたり最大20件のケースを返し、続きの結果には`next_offset`を使用します。
このオプションを指定しない既存のAPI連携では、現在の作成時の動作がそのまま維持されます。


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