AIエージェントに見積書のドラフト作成やメール返信、チケット対応などの実務を任せる企業が増えている。ただし多くの現場で最初にぶつかる壁は「モデルの精度」ではなく、「どこで人間が承認するか」という運用設計だ。承認ポイントを置きすぎれば人間がボトルネックになり、置かなさすぎれば誤送信や誤操作のリスクが跳ね上がる。本稿ではHuman-in-the-Loop（HITL）の設計原則と、実装レベルでよくある落とし穴、現場の事例を整理する。
なぜ「承認」が最大のボトルネックになるのか
複数の業界レポートが共通して指摘するのは、AIエージェント導入の失敗はモデル性能ではなく運用設計に起因するという点だ。Gartnerはエージェント導入プロジェクトが打ち切られる主因として「コスト増大」「事業価値の不明確さ」「リスク管理の不備」の3つを挙げており、いずれもモデルの出来とは別軸の話である。MIT NANDAの調査でも、企業向け生成AIシステムのうちパイロットまで到達したのは20%、本番稼働まで進んだのはわずか5%にとどまるという。
特に問題になりやすいのが承認プロセスそのものの設計だ。Workflow Builderのガイドは、エージェント型システムでは「あらかじめすべての承認ポイントを列挙できない」点が旧来の自動化と決定的に違うと指摘する。エージェントは状況に応じて自分でアクションの順序を選ぶため、固定フローの前提で設計されたチェックポイントは容易に穴が空く。
承認ポイント設計の4原則
1. 影響度で仕分ける
すべての判断を人間承認にすると、レビューが形骸化した「ラバースタンプ（機械的な承認押印）」に陥る。Cflowのレポートは、AIが判断を準備しリスクを提示したうえで、影響が大きい判断だけを人間が最終確認する設計を推奨している。定型・低リスクな作業（下書き作成、社内向け要約など)は自動化し、対外送信や金銭・契約に関わるアクションにのみ承認を絞り込む。
2. 承認はセンシティブなアクションの「直前」に置く
AIエージェント開発フレームワーク LangGraph の実装知見をまとめた記事では、「承認はアクションの数ステップ前ではなく、副作用を伴うアクションの直前に置くべき」だと強調されている。メール送信・決済・DB更新などの取り消しにくい処理の直前でのみ人間の確認を挟み、それより前の思考・計画段階は自動で進めるのが定石だ。
3. 「承認疲れ」を前提に設計する
Anthropicの分析によれば、あらゆるアクションに人間承認を要求する運用はかえって危険性を高める場合がある。承認回数が増えるほど人間は中身を精査せず機械的に承認する「アラート疲れ」に陥り、結果として全承認・全自動よりも見落としが増えるケースがあるという。実際、Anthropicの評価では Claude Code や Codex に搭載された「自動レビューモード」（提案アクションを分類器でチェックし、危険なものだけ人間に確認を求める）の方が、全件人間承認や無制限自動実行よりも有害なアクションの阻止に有効だったと報告されている。
4. 「取り消し可能性」で設計する
カナダ政府が公開しているエージェント型AI利用ガイドは、可逆性（reversibility）を設計原則の一つに掲げている。同ガイドが紹介する事例では、問い合わせ対応エージェントを「ドラフト作成のみ・最終返信や案件クローズは不可」の権限に限定し、クローズ操作を試みたら自動停止してチームに通知する仕組みを組み込んでいた。実際に問い合わせが急増した際にこの仕組みが作動し、影響を受けた案件を担当者が手動で再オープンして事なきを得たという。
実装レベルの落とし穴 ── LangGraphのinterruptを例に
承認フローを自前で実装する場合、フレームワークの挙動を誤解して事故につながるケースがある。LangGraphのドキュメントや実装者のブログから、代表的な落とし穴を3つ紹介する。
| 落とし穴 | 内容 | 対策 |
|---|---|---|
| ノードの再実行 | 承認待ちで一時停止(interrupt)したノードは、再開時に「最初から」再実行される。interrupt以前に書いたコードも再度走る。 | 副作用のあるコードをinterrupt以前に置かない。冪等な設計にする。 |
| respondとrejectの混同 | 人間の「拒否」メッセージをrespond扱いにすると、エージェントはそれを「成功したツール結果」として解釈してしまう。 | アクションを拒否する場合は必ずreject、成功結果の一部として渡す場合のみrespondを使う。 |
| リトライ時の重複実行 | メール送信や課金など副作用のある処理は、ステップがリトライされた際に重複実行されるリスクがある。 | 冪等キーの付与など、リトライ前提の設計にする。 |
承認・監視を支援するツールの例
自前実装だけでなく、承認フローや監査ログを標準機能として持つツールも増えている。導入時の比較材料として簡単に整理する。
| ツール | 特徴 |
|---|---|
| LangGraph | グラフ構造でエージェントの状態遷移を明示的に制御。interrupt機能でセンシティブなアクション直前に人間承認を挟める。エンジニア向け。 |
| StackAI | ノーコードでエージェントを構築でき、人間承認へのエスカレーションルールやSOC 2対応をあらかじめ備える。契約書レビューなど文書中心の業務向け。 |
| t0ggles | 複数のエージェントと人間の承認をタスクボードで可視化し、誰がいつ何を承認したかの監査証跡を残すことに特化。 |
実務でのチェックリスト
- 承認ポイントは「対外送信」「金銭・契約」「不可逆な変更」など高リスクな操作の直前にのみ置く
- 低リスクな定型作業（下書き・要約・社内向け情報整理）は自動化し、人間の確認対象を絞り込む
- 承認頻度が高くなりすぎていないか定期的に点検し、「ラバースタンプ化」の兆候があれば承認基準を見直す
- 停止・巻き戻しのための「一時停止ボタン」や再オープン手順をあらかじめ用意しておく
- 誰が・いつ・何を承認したかの監査ログを必ず残す
- 副作用のある処理（送信・課金・DB更新）はリトライ時の重複実行を防ぐ設計にする
承認プロセスは「安全のためのコスト」ではなく、うまく設計すれば自動化の速度を落とさずに事故を防ぐレバーになる。まずは影響の大きい業務から一つ選び、承認ポイントを最小限に絞ったパイロットから試すのが現実的な出発点だろう。
主な情報源
- Guide on the Use of Agentic Artificial Intelligence – Canada.ca
- What Is Human-in-the-Loop Automation? – Workflow Builder
- 10 AI Workflow Automation Trends Reshaping 2026 – Cflow
- LangGraph human approval: interrupt or middleware? – Soba Labs
- Interrupts – Docs by LangChain
- The AI-as-Normal-Technology view of loss of control incidents
- When Not to Deploy an AI Agent in Customer Service – FPT Software
- Human-in-the-Loop AI (HITL) – Parseur
各ツールは提供元の規約に従ってご利用ください。情報は各情報源の公開時点のものです。収集・要約はAI、公開判断は人。