「人間の承認」をどこに挟むか——AIネイティブなワークフローの止め方・戻し方
AIネイティブな業務システムを設計するとき、「どこまで自動化するか」と同じくらい重要なのが「どこで人の承認を挟むか」です。すべてを自動化しようとすると、AIの誤判断がそのまま実害につながるリスクを抱えますし、逆にすべてに承認を求めると、AIを導入した意味が薄れます。この線引きは実装の細部ではなく、要件定義の段階で業務要件として決めるべき設計判断です。
承認を挟む4つのパターン
Human-in-the-loop（人が判断の輪に入る）と呼ばれる設計には、いくつかの型があります。業務内容に応じて使い分けます。
1. 事前承認型：AIが提案を作成し、実行前に必ず人が承認する。契約書のドラフト作成や、金額の大きい支払い処理など、実行後の取り消しが難しい操作に向きます。
2. 閾値型（例外承認）：AIの判断がある基準（金額・件数・信頼度スコアなど）を下回る場合のみ自動実行し、上回る場合に人の承認を求める。日常的に発生する定型処理の大半を自動化しつつ、リスクの高いケースだけ人の目を通せます。
3. 事後レビュー型：AIが実行した結果を、後から一定割合サンプリングして人がチェックする。実行のスピードを優先しつつ、品質を継続的に監視したい場合に向きます。
4. 差し戻し型（拒否・再実行）：人がAIの提案を却下し、修正指示を与えて再実行させる。承認・却下の二択ではなく、「ここを直して」というフィードバックをAIに戻す経路を用意する設計です。
多くの業務システムでは、これらを組み合わせます。たとえば「金額が10万円未満なら自動実行（閾値型）、10万円以上は事前承認（事前承認型）、承認された案件も月次で一定割合を事後レビューする」といった構成です。
具体例：請求書処理での承認設計
請求書処理を例にすると、承認をどこに挟むかで業務要件は次のように変わります。
- AIが請求書のOCR読み取りと勘定科目の推定を行う（自動）
- 推定の信頼度が閾値以上であれば、そのまま経理システムへ登録（閾値型・自動実行）
- 信頼度が閾値未満、または金額が一定額を超える場合は、担当者の画面に差し戻し、承認待ちのキューに入る（閾値型・事前承認）
- 担当者は「承認」「勘定科目を修正して承認」「差し戻し（AIに再推定させる）」のいずれかを選べる（差し戻し型）
このとき要件定義で決めておくべきは、「信頼度スコアの閾値をいくつにするか」という数値そのものよりも、誰が・どういう基準でその閾値を決定・変更する権限を持つかです。閾値はリリース後の運用で調整されることが多いため、変更のたびにシステム改修が必要になる設計は避け、運用担当者が設定画面から調整できるようにしておくと、現場の判断で柔軟にチューニングできます。
承認UIの設計要件
承認を挟む設計にすると、必ず「誰が、どの画面で承認するか」というUI要件が発生します。ここで見落とされやすいのが次の点です。
- バッチ承認：件数が多い場合、1件ずつではなく複数件をまとめて確認・承認できる導線を用意する（すべてに個別確認を求めると、結局は人がボトルネックになる）
- 差分表示：AIの提案内容と、元データ・過去の類似案件との差分を分かりやすく提示する（承認者が「何を確認すればよいか」が一目で分かる設計にする）
- 承認待ちの滞留を可視化する：承認待ちが溜まっている状態に気づける仕組み（通知・ダッシュボード）を用意しないと、AI導入前より処理が遅くなる逆効果が起こり得る
Difyやn8nといったワークフローツールにはHuman-in-the-loop用のノード（承認待ちで処理を一時停止し、Slackなどで通知する機能）が用意されているものもあり、承認フローそのものをゼロから作らずに構築できるケースも増えています。
まとめ
AIネイティブなワークフロー設計では、「自動化するかしないか」の二択ではなく、事前承認・閾値型・事後レビュー・差し戻しという複数のパターンを業務のリスクに応じて組み合わせることが実用的です。承認の基準値を誰が調整できるか、承認する側の画面をどう設計するかまで含めて、要件定義の段階で詰めておくことが、現場で実際に回るAIネイティブなシステムの条件になります。