先に要点
- Human-in-the-loop は、AIエージェントの処理途中に人間の確認や承認を挟む設計です。
- 承認を入れるべきなのは、外部送信、DB更新、本番反映、課金、権限変更、削除、取り消しにくい操作の直前です。
- すべてに承認を入れると遅くなるため、`読むだけ` と `副作用がある操作` を分けて考えるのが基本です。
AIエージェントを業務で使うとき、よく出るのが どこまで自動でやらせてよいか という問題です。
調査や要約だけなら比較的扱いやすいですが、メール送信、チケット起票、DB更新、コードのマージ、クラウド操作まで進むと話が変わります。
ここで重要になるのが、人間承認です。
OpenAI Agents SDK でも Human-in-the-loop が機能として用意されており、tool 実行前に approval が必要な場合は run を一時停止し、承認または拒否後に再開できる仕組みが説明されています。
この記事では、2026年4月21日時点の OpenAI Agents SDK の公式ドキュメントを確認しながら、AIエージェントで人間承認をどこに入れるべきか、実務の判断基準として整理します。
まず基本: 承認は「最後」ではなく「危険操作の直前」に置く
AIエージェントの承認設計で大事なのは、最後に結果を見るだけでは不十分な場面があることです。
たとえば、AIがすでにメールを送った後に人間が確認しても、送信は取り消せません。
DBを更新した後、クラウドリソースを作った後、外部APIにデータを送った後も同じです。
そのため、承認は 危険な操作の前 に置くのが基本です。
| 操作 | 承認の必要度 | 理由 |
|---|---|---|
| 検索、読み取り、要約 | 低め | 外部影響が小さい |
| 下書き作成、提案 | 中 | 人が採用前に確認できる |
| メール送信、チケット起票 | 高 | 外部や他者に影響する |
| DB更新、削除、権限変更 | 高 | 業務データや権限に影響する |
| 本番反映、課金、購入 | 非常に高い | 費用・障害・契約影響が出る |
承認を入れるべき代表的な場所
1. 外部送信の直前
メール、Slack、問い合わせ返信、顧客向け文章、SNS投稿、外部API送信などです。
AIが書いた文章が正しそうでも、宛先、表現、機密情報の混入、ブランドトーンの問題が起きることがあります。
特に顧客、取引先、公開ページへ出るものは、人間確認を挟む価値が高いです。
2. DB更新や削除の直前
読み取りは自動化しやすいですが、更新や削除は別です。
誤った条件で一括更新したり、必要なデータを削除したりすると復旧が難しくなります。
AIエージェントには、最初は読み取り権限だけを与え、更新系は承認後に限定実行する形が安全です。
3. 本番環境へ影響する操作の直前
デプロイ、設定変更、キャッシュクリア、ジョブ停止、クラウドリソース変更などです。
これらは成功しても失敗しても影響が大きいため、実行前に人間が確認する方が安全です。
4. 課金や購入が発生する操作の直前
クラウドリソース作成、有料APIの大量実行、広告出稿、SaaS契約、クレジット消費などです。
AIは目的達成のために合理的に見える操作を選ぶかもしれませんが、予算や承認権限までは自動で分かりません。
5. 権限変更の直前
ユーザー追加、管理者権限付与、APIキー発行、ロール変更などです。
権限は一度広げると事故につながりやすいため、AI判断だけで動かさない方がよいです。
6. 法務・契約・人事に関わる判断の前
契約文面、採用判断、人事評価、法的リスクがある回答は、AIが下書きや論点整理をするのは便利ですが、最終判断は人間が持つべきです。
承認を入れすぎると何が起きるか
承認は安全装置ですが、全部に入れると AIエージェントの意味が薄れます。
たとえば、検索するたびに承認、ファイルを読むたびに承認、要約するたびに承認では、作業が進みません。
この状態になると、人間がAIの作業ログを追うだけになり、かえって疲れます。
そのため、承認は リスクのある副作用 に絞るのが基本です。
承認なしで進めやすい操作
次のような操作は、比較的自動化しやすいです。
- 公開情報の検索
- 読み取り専用の社内文書検索
- ローカルファイルの参照
- 下書き作成
- 要約
- テストの実行
- 差分の説明
ただし、読み取り対象に機密情報や個人情報が含まれる場合は、入力ルールやログ管理も一緒に考える必要があります。
OpenAI Agents SDKではどう扱われているか
OpenAI Agents SDK では、Human-in-the-loop guide で tool approval の pause / resume パターンが説明されています。
承認が必要な tool 呼び出しがあると run が中断され、result.interruptions に pending item が入り、状態を保存して approve または reject した後に再開できます。
また Tools docs では、Agent.as_tool(..., needs_approval=...) も function_tool と同じ承認フローを使うと説明されています。
ここから分かるのは、人間承認は チャットの最後に一言確認する だけではなく、実行フロー上の interrupt として扱うべきだということです。
guardrailsだけでは足りない場面
ガードレール は重要です。
OpenAI Agents SDK でも input guardrails、output guardrails、tool guardrails が用意されており、条件に合わない場合に tripwire で停止できます。
ただし、ガードレールは人間判断の完全な代替ではありません。
たとえば、次のような判断はルールだけでは難しいことがあります。
- この顧客へ今この文面を送ってよいか
- この本番変更を今実行してよいか
- この費用は予算内か
- この例外対応は契約上問題ないか
こうした判断は、ガードレールで止めるだけでなく、人間承認を組み合わせる方が現実的です。
承認画面に出すべき情報
承認者が見る画面や通知には、少なくとも次を出した方がよいです。
- 実行しようとしている操作
- 対象データや対象環境
- 変更前と変更後
- AIがその操作を必要だと判断した理由
- 想定される影響
- 取り消し可否
- 実行者、承認者、日時
承認しますか？ だけでは不十分です。
承認者が判断できる材料を出さないと、承認は形だけになります。
ログに残すべき情報
あとから説明できるように、承認ログも重要です。
- どの agent が何を実行しようとしたか
- どの tool を呼ぼうとしたか
- 入力パラメータ
- 承認者
- 承認または拒否の結果
- 実行時刻
- 実行結果
特に業務システムや顧客対応では、AIがやりました では説明になりません。
人間の承認と実行ログをセットで残す方が安全です。
承認設計の実務パターン
パターン1: 読み取りは自動、書き込みは承認
最初におすすめしやすい形です。
AIは調査、要約、差分確認まで進め、更新や送信だけ人間が止めます。
パターン2: 少額・低リスクは自動、高リスクは承認
たとえば、社内チケット起票は自動、顧客メール送信は承認、本番DB更新は必ず承認、という形です。
パターン3: sandboxでは自動、本番では承認
検証環境では自動実行し、本番環境では承認を必須にします。
AIコーディングやインフラ操作では特に現実的です。
パターン4: 一定条件を超えたら承認
費用、件数、影響範囲、対象ユーザー数、権限レベルなどでしきい値を置きます。
まとめ
AIエージェントの人間承認は、外部送信、DB更新、本番反映、課金、権限変更、削除、取り消しにくい操作の直前 に置くのが基本です。
一方で、検索、読み取り、要約、下書き作成のような低リスク操作まで毎回止めると、エージェントの効率が落ちます。
大事なのは、
- 読むだけか、副作用があるか
- 取り消せるか、取り消しにくいか
- 社外、費用、本番、権限に影響するか
で判断することです。
AIエージェントの流れ全体は コード主導のオーケストレーションとは？AIエージェントの流れをコードで決める設計 や LLM主導のオーケストレーションとは？AIエージェントが流れを判断する設計を整理 とあわせて読むと、承認点をどこに置くべきか見えやすくなります。
参考リンク
- OpenAI Agents SDK: Human-in-the-loop
- OpenAI Agents SDK: Tools
- OpenAI Agents SDK: Guardrails
- OpenAI Agents SDK: Agents