# 審査で止まっているセッションと、その減らし方

Source: https://help.didit.me/ja/verification-sessions/session-in-review
Updated: 2026-10-12

審査中は、自動チェックは完了したものの人が対応すべき何かが検出された状態です。自然に解決することはありません。キューを処理し、審査率を下げる方法を説明します。

**審査中は自然には解消しません。** これは、あるチェックが何かを検出し、チームの誰かが承認、拒否、または再提出の依頼をするのを待っている状態を意味します。審査率が高い場合、原因はほぼ常に不正ではなく、厳しすぎる閾値設定です。

[Video: タグ・ステータス・セッションチャット：チームでのケース審査 - Didit Academy](https://www.youtube.com/watch?v=bRkH0agxVDc)

> **Warning:** **Didit はセッションを審査しません。** 審査中のセッションは、Business Console 上であなたのチームの担当者を待っており、Didit 側では誰も確認していません。Didit 側に待ち行列はなく、所要時間の目安もありません。あなたのチームの誰かが判断するまで審査中のままです。

すべてのステータスの中で、**審査中**は最もサポートへの問い合わせを生む理由の1つです。単純な理由からです。一見、プラットフォームがまだ処理中のように見えますが、実際にはプラットフォーム側の処理は完了しており、あなたの対応を待っています。

## 審査中が実際に意味すること

自動チェックはすべて実行済みです。少なくとも1つが、自動判定ではなくレビューに回すようワークフローで設定された警告を発しました。セッションは今、あなたのキューの中で、人による解決を待っています。自動的に決定を下すタイムアウトは存在せず、システムにチェックを再実行させて自ら判定を変えさせる方法もありません。

## セッションを処理する

1. **レビューキューを開く**

   **本人確認 → ユーザーの確認 → 要審査**または**受信トレイ → 判定**を開きます。Aで承認、Dで否認、Rで再提出、J/Kで移動します。確定前にダイアログを確認してください。

2. **ステータスだけでなく警告を読む**

   セッションを開き、どのチェックがフラグを立てたか、警告の内容を確認してください。それが実際にあなたが判断すべき内容を決めます。詳細は[検証結果の読み方](https://help.didit.me/ja/verification-sessions/reading-a-verification-result)をご覧ください。

3. **判断する**

   承認、拒否、または失敗したステップのみの再提出を依頼します。ノートを追加すると、それは監査証跡の一部になります。

4. **バックエンドに知らせる**

   判断が下されると`status.updated`のwebhookが発火するため、自分で照合しなくてもシステム側が最終状態を取得します。

![Diditコンソールで検証一覧を審査中ステータスで絞り込んだ画面](https://help.didit.me/screenshots/sessions-bulk-light.webp)

*検証を審査中で絞り込み、キューを処理します。*

## 審査率が高くなる理由

可能性が高い順に、次のとおりです。

1. **顔照合の閾値が近すぎる。** レビュー帯域が広いと、通常の照明の変動だけでその中に入ってしまいます。詳細は[顔照合スコアと閾値](https://help.didit.me/ja/liveness-biometrics/face-match-thresholds)をご覧ください。
2. **AMLレビュー閾値が低いマッチスコアに設定されている。** よくある名前は、低いマッチスコアで候補ヒットを生成します。レビュー閾値を低く設定しすぎると、ほぼ全員がレビューに回されます。詳細は[AMLヒットの解決](https://help.didit.me/ja/aml-screening/resolving-aml-hits)をご覧ください。
3. **住所証明の部分一致。** 住所の書式は国によって大きく異なり、略語の違いだけで部分一致として扱われます。部分一致をレビューに回すか通過させるかは、意図的に決めてください。
4. **データベース検証の部分一致。** 原因は同じです - 信頼できる情報源に異なる表記で記録された氏名です。
5. **正当な再来ユーザーへの重複顔フラグ。** 同一の実在人物が複数回検証すると、自分自身と一致してしまいます。詳細は[重複検知](https://help.didit.me/ja/verification-sessions/duplicate-detection)をご覧ください。
6. **「念のため」すべての警告をレビューに回している。** すべてをレビューすることは、何もレビューしないことと同じです。キューが処理されなくなるためです。本当に判断が必要な警告だけを選んでください。

## ワークフローを並べ替えて、早く安価にレビューする

フローが高コストで、それでも多くのセッションが結局レビューに回ってしまう場合、安価なリスクチェックを前段に移動させると、高価なチェックが実行される前にフローが止まるようになります。フルKYCフローの前に$0.03のデバイス・IP分析を置くと、そもそも通過する見込みのないトラフィックへの支出を削減できます。

トレードオフはユーザー体験です。最初のステップで止められた人は、何も投資していない代わりに、なぜ止められたのかを知る機会もありません。自社のファネルにとってどちらが重要かを判断してください。

## 四眼レビュー

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

## 審査中ではないもの

- **「まだ処理中」ではありません。** プラットフォームの処理完了を待っている場合、該当するステータスは進行中です。
- **ソフトな拒否ではありません。** 審査中のセッションにはまだ評決が一切存在しないため、自社のシステムで「拒否」にマッピングせず、専用の保留ステータスにマッピングしてください。
- **サポートが代わりに判断できるものではありません。** 自社の顧客を承認・拒否する権限を持つのは、あなたのチームだけです。サポートは、なぜセッションにフラグが立ったのかを説明できますが、そのためには`session_id`が必要です。

## 継続モニタリングが承認済みセッションを審査中に戻すことがある

AMLモニタリングを有効にしている場合、日次の再スクリーニングでレビュー閾値を超える新しいヒットが見つかると、以前承認されたセッションが後から審査中に移ることがあります。これは想定どおりの挙動であり、後退ではありません。むしろそれこそがモニタリングの目的です。詳細は[AML継続モニタリング](https://help.didit.me/ja/aml-screening/ongoing-monitoring)をご覧ください。