eKYC手動審査の運用設計。キュー・基準・SLO

eKYCを導入すると本人確認が「全自動」になる、と考えて計画を立てると、運用開始後に必ずつまずきます。実際には一定割合の申請が機械判定で確定できず、人の目による手動審査に回ります。そしてこの手動審査こそが、eKYC運用コストの本体であり、ユーザーの完了待ち時間を左右するボトルネックです。本記事は、eKYCシステムの導入・内製を検討している事業会社の開発責任者・コンプライアンス担当者に向けて、手動審査体制をキュー・判定基準・権限・SLOの4つの観点から設計する方法を解説します。ベンダーに審査運用ごと委託する場合でも、ここで挙げる観点は発注側が確認すべき項目そのものです。法令確認日: 2026年8月23日。

この記事の要点

• 手動審査は自動判定の「こぼれ」ではなく、閾値設計と一体で意図的に用意する中間帯の受け皿です。その設計品質が運用コストと審査完了時間を決めます
• キューは発生源別に分割し、自動割当て・応答期限・エスカレーションで滞留を仕組みとして防ぎます
• 審査品質は担当者の熟練に頼らず、判定基準書・較正訓練・覆り率の計測という仕組みで作ります。高リスク案件は二重承認をシステムで強制します
• 審査担当は券面画像・顔画像という最も機微なデータを扱う職務です。最小権限と閲覧証跡をシステム側で強制して初めて内部不正リスクに説明がつきます
• 手動審査率・p95審査時間・覆り率・コスト/件を定点観測し、閾値設計へフィードバックし続けることが運用の核心です

なぜ手動審査が発生するのか——中間帯という設計思想

顔照合や書類真贋判定のスコアは連続値です。どこかに「これ以上なら自動承認」「これ以下なら自動否認」という線を引く必要があり、その2本の線の間に挟まれた領域が中間帯、すなわち手動審査の対象です。中間帯を狭くすれば人件費は下がりますが、誤承認（なりすましの通過）や誤否認（正当なユーザーの離脱）が増えます。逆に広くすれば判定は堅くなりますが、審査要員と待ち時間が膨らみます。

つまり手動審査の量は偶然決まるものではなく、閾値をどこに置くかという経営判断の従属変数です。この閾値の決め方自体は顔照合の閾値設計で詳しく扱っています。また、審査中という状態をシステム上どう表現するか（状態機械上の manual_review の位置づけ）は壊れないeKYC APIの設計が担当します。本記事はその間、つまり「中間帯に落ちた案件を、誰が・どの順で・どんな基準で捌くか」の設計です。

審査キューに流れ込む5種類の案件

設計の第一歩は入口の分類です。手動審査キューに入る案件は発生源によって審査の性質がまったく異なります。

発生源	典型例	審査で確認すること	1件あたりの目安感
顔照合の中間帯	スコアが自動承認と自動否認の間	同一人物かの目視判断	秒単位で判断可能
書類の判定保留	真贋スコアが曖昧、旧様式、経年劣化	書類の有効性・改ざん痕	数分程度
属性の不一致	申込情報と書類・IC情報の食い違い	単純な誤入力か、なりすまし兆候か	数分〜十数分
リスクルールのヒット	高額取引、短期間の複数申込、ハイリスク属性	取引の合理性・追加確認の要否	数十分の調査になりうる
ユーザー申告・例外	IC読み取り不能の後処理、氏名変更直後	代替確認手段への振り分け	ケースバイケース

この分類が実務上重要なのは、キューを1本にまとめると「3秒で判断できる顔照合の目視」と「30分かかるリスク調査」が同じ列に並び、待ち時間の予測が不可能になるからです。発生源ごとにキューを分け、必要スキルと目標処理時間を個別に設定することが、後述するSLO運用の前提になります。なお、そもそも中間帯や判定保留に落ちる申請を減らす撮影・読み取り側の工夫はeKYCの失敗パターンで整理しています。

キュー設計——滞留を根性ではなく仕組みで防ぐ

キュー運用で起きる問題は、ほぼすべて設計段階で潰せます。押さえるべきは5点です。

• 優先度制御: 単純なFIFO（先入れ先出し）は、口座開設の離脱リスクが高い案件や契約日が迫った案件を後回しにしてしまいます。申込からの経過時間と取引側の期限を組み合わせた優先度付けが必要です
• 自動割当て: 担当者が案件を自分で選べる方式は「楽な案件のつまみ食い」を招き、難しい案件だけが残留します。自動割当てに、書類系・リスク系といったスキルタグを組み合わせるのが基本形です
• 応答期限とエスカレーション: 案件ごとに応答期限を持たせ、超過したら上位者へ自動エスカレーションします。「気づいたら3日放置されていた」を人の注意力ではなく仕組みで防ぎます
• 差し戻しの状態分離: 「再撮影を依頼してユーザーの対応を待っている」時間は、審査側の作業時間ではありません。ユーザー待ち状態を審査中と別の状態として管理し、審査時間の計測に混ぜないことが、後のSLO計測の正確さを決めます
• 状態の一元管理: 審査ツール上のステータスと、確認セッションの状態機械（manual_review）を同期させます。審査ツールでは完了しているのにAPIの応答では審査中のまま、というずれは障害調査とユーザー問い合わせ対応の両方を混乱させます

審査品質——「誰が見ても同じ結論」を仕組みで作る

目標は、同じ案件を誰が審査しても同じ結論に到達する状態です。ベテランの勘に依存した審査は、その人の退職と同時に品質が崩れます。属人化を防ぐ道具は3つです。

1. 判定基準書: 「承認してよい条件」「否認すべき条件」「追加確認に回す条件」を、実例画像（架空・合成のサンプル）付きで文書化します。「明らかに怪しい場合」のような曖昧語を残すと、その解釈が担当者ごとに割れます
2. 較正（キャリブレーション）訓練: 同一案件を複数人が独立に審査し、結論を突き合わせる訓練を定期的に実施します。判断のブレが可視化され、基準書のどこが曖昧かも分かります
3. 覆り率の計測: 手動審査の結論が後から覆った率（承認後に不正が判明、否認後に正当と判明）と、担当者間の判定分布の偏りを継続的に計測します。特定のスコア帯で覆り率が高いなら、それは基準書か閾値の置き場所が悪いというシグナルです

さらに、高額取引・リスクルール複数ヒット・否認からの再申請といった高リスク案件は、一人の判断で確定させず二重承認とします。重要なのは、これを運用ルール（マニュアル上のお願い）ではなく、一般審査員・上級審査員・管理者という承認権限の段階をシステムのロールとして実装し、システムが強制する形にすることです。運用ルールは繁忙期に破られますが、システムの制約は破れません。

権限統制と覗き見対策——審査は最も機微な職務

見落とされがちですが、審査担当者は券面画像・顔画像・住所氏名といった、そのサービスで最も機微な個人データを日常的に閲覧する職務です。ここの統制を欠いたまま内部不正が起きると、企業として説明のしようがありません。

• 最小権限: 担当に割り当てられた案件のデータだけが見える設計にします。検索機能で任意ユーザーの画像を開ける状態は、それ自体がリスクです
• 閲覧証跡: 誰が・どの案件の・どのデータを・いつ表示したかを記録します。操作ログだけでなく閲覧ログまで残す設計はeKYCの証跡設計で詳述しています
• 画面側の抑止: 審査画面でのダウンロード・コピーの制限、閲覧者を特定できる透かし表示、離席時の自動ロックを実装します
• BPO委託時の担保: 審査業務を外部委託する場合、上記の統制が委託先環境でも同じ強度で効くこと——専用環境の分離、ログの提供、監査権——を契約で担保します。委託先に確認すべき観点の構造はeKYCサービスの選び方・20項目の運用・データ項目と共通です

なお、確認記録や画像の保存期間・保存範囲そのものの設計はKYC記録の保存要件を参照してください。

SLOと計測——閾値へフィードバックし続ける

手動審査体制の健全性は、次の指標で定点観測します。計測しないものは改善できません。

指標	見方	悪化時に疑うこと
手動審査率	全申請のうち手動に回る割合	閾値の置き場所、照合モデルや撮影品質の劣化
p95審査時間	平均ではなくp95で見る	キューの詰まり。詰まりは平均値には現れない
覆り率・差し戻し率	担当者別・発生源別に分解	基準書の曖昧さ、較正不足、閾値の不整合
審査コスト/件	人件費÷処理件数	閾値変更の経営判断材料に直結
時間外の滞留	夜間申込の翌朝残量	完了予告文言（「1営業日以内」等）との不整合

計測の出口は閾値へのフィードバックです。たとえば「中間帯のうちスコア上位◯%はほぼ全件が目視で承認されている」というデータが取れたら、その帯は自動承認側に寄せられます。手動審査は一度作ったら終わりの固定費ではなく、閾値と一体で継続的にチューニングする変動要素として扱う——これが本記事で最も伝えたい設計思想です。

発注者向け——審査運用をベンダーに任せる場合の確認リスト

eKYCベンダーのマネージド審査（審査代行込みプラン）を使う場合でも、事業者としての説明責任は発注側に残ります。契約前に次の点を確認してください。

• 手動審査率とp95審査時間の実績値・目標値が提示されるか
• 審査の判定基準書を開示（または共同レビュー）できるか
• 高リスク案件の二重承認と、自社側へのエスカレーション経路があるか
• 審査担当者の閲覧証跡が取得され、自社に提供されるか
• 再委託の有無と、再委託先への統制の伝播が契約に明記されているか
• 営業時間外の申込がいつ処理されるか、ユーザーへの完了予告文言と整合しているか
• 閾値変更（手動審査量の増減）を協議できる窓口・プロセスがあるか

まとめ

• 手動審査は自動判定の残余ではなく、閾値設計とセットで意図的に用意する中間帯の受け皿です。その設計がeKYCの運用コストと完了時間を決めます
• キューは発生源別（顔照合・書類・属性不一致・リスクルール・例外）に分割し、自動割当て・応答期限・エスカレーションで滞留を仕組みとして防ぎます
• 審査品質は判定基準書・較正訓練・覆り率計測で作り、高リスク案件の二重承認はシステムのロールとして強制します
• 審査担当の権限は最小化し、閲覧証跡まで記録します。BPO委託時も同じ統制を契約で担保します
• 手動審査率・p95審査時間・覆り率・コスト/件を定点観測し、閾値設計へフィードバックし続けます
• 審査運用を外部に委ねる場合も、上記の観点は発注側の確認項目としてそのまま使えます

よくある質問

Q. eKYCの手動審査はなぜ必要なのですか？完全自動化はできませんか？

顔照合や書類真贋判定のスコアは連続値のため、自動承認と自動否認の間に必ず判定の曖昧な中間帯が生じます。中間帯をゼロにする（＝完全自動化する）ことは、誤承認か誤否認のどちらかを大幅に増やすことと引き換えになります。実務では中間帯を意図的に設け、人の目視で確定させる設計が標準です。手動審査の量は閾値の置き方で制御する経営判断の対象です。

Q. eKYCの手動審査率はどのくらいが普通ですか？

サービスの閾値設定・利用者層・書類の種類によって大きく変わるため、一律の正解値はありません。重要なのは絶対値よりも推移で、手動審査率が上がり続ける場合は照合モデルや撮影品質の劣化シグナルとして原因を調査します。自社の覆り率データと突き合わせて、閾値を動かして最適点を探し続ける運用が本質です。

Q. 手動審査の品質はどうやって担保しますか？

3つの仕組みで担保します。第一に、承認・否認・追加確認の条件をサンプル画像付きで文書化した判定基準書。第二に、同一案件を複数人が独立審査して結論を突き合わせる較正訓練。第三に、審査結論が後から覆った率（覆り率）の継続計測です。加えて高リスク案件は二重承認とし、承認権限の段階をシステムのロールとして強制します。

Q. 手動審査のSLOにはどんな指標を設定すべきですか？

手動審査率、p95審査時間（平均ではなく95パーセンタイル）、覆り率・差し戻し率、審査コスト/件、時間外申込の滞留量の5つが基本です。特に審査時間は、ユーザーの再撮影待ち時間を分離して計測しないと実態を見誤ります。計測結果は閾値設計へフィードバックし、手動審査量そのものを調整し続けます。

Q. 審査業務をBPOに委託しても大丈夫ですか？

委託自体は一般的ですが、審査担当者は券面画像・顔画像という最も機微なデータを閲覧するため、自社と同等の統制が委託先で効くことを契約で担保する必要があります。具体的には専用環境の分離、最小権限、閲覧証跡ログの提供、監査権、再委託の制限です。判定基準書の共有と覆り率の共同モニタリングまでできる委託先が望ましいです。

Q. 手動審査の担当者による情報の覗き見はどう防ぎますか？

運用ルールではなくシステムで防ぎます。担当案件のデータしか見えない最小権限、誰がどのデータをいつ表示したかの閲覧証跡、審査画面でのダウンロード・コピー制限と透かし表示、離席時の自動ロックが基本セットです。「検索すれば任意のユーザーの画像を開ける」状態を作らないことが最重要です。

主な参考資料: 金融庁 マネー・ローンダリング及びテロ資金供与対策に関するガイドライン、警察庁 2026年3月公表の改正Q&A（PDF）、個人情報保護委員会 ガイドラインQ&A

TodoONada株式会社は、マイナンバーカード認証（JPKI・eKYC）を組み込んだWebサービス・スマホアプリの受託開発を行っています。方式選定から開発・運用までのワンストップ支援に加えて、本記事で扱った審査ツールの構築、キュー・SLO設計、犯収法など業種ごとの本人確認要件の整理も支援範囲です。デジタル庁「デジタル認証アプリ」の利用申請・審査対応の伴走支援も承っています。料金の目安は認証機能組込みプラン150万円〜、認証込みアプリ開発プラン400万円〜です。詳しくはマイナンバーシステム導入支援、ご相談はお問い合わせからどうぞ。

---

この記事に関連するサービス

TodoONada株式会社では、マイナンバーカード認証を組み込んだシステム開発を行っています。

• マイナンバーシステム導入支援 — JPKI・eKYC対応の本人確認をワンストップで

導入・開発のご相談はお問い合わせからお気軽にどうぞ。検討段階のご相談も歓迎です。