この記事を読むと
- OpenAI Agents SDKで承認が必要な場面がわかる
- Human-in-the-loopの実装イメージを整理できる
- 送信・更新・削除のような危険操作の分け方がわかる
OpenAI Agents SDKはアプリ側が実行を管理する時に使う
OpenAIのAgents SDKガイドでは、アプリケーション側がオーケストレーション、ツール実行、承認、状態を管理する場合にAgents SDKを使うと整理されています（OpenAI API Docs「Agents SDK」）。単発のAPI呼び出しでは足りない時の選択肢です。
承認フローが必要になるのは、AIが外部システムへ副作用を持つ操作を行う時です。メール送信、支払い、DB更新、ファイル削除、権限変更は、最初から人間承認を設計に入れてください。
- 読み取りだけ：自動実行しやすい
- 下書き作成：ログ付きで自動化しやすい
- 送信・更新・削除：承認対象
Human-in-the-loopは中断、判断、再開で考える
OpenAI Agents SDKのHuman-in-the-loopガイドは、承認が必要なツール呼び出しで実行を一時停止し、承認または拒否後に同じRunStateから再開する流れを説明しています（OpenAI Agents SDK「Human-in-the-loop」）。
実装では、承認待ちの状態をDBに保存し、Slackや管理画面で人間が判断し、再開時に誰が承認したかをログに残します。ここを省くと、後から事故原因を追えません。
- interruptionsを承認キューに入れる
- 承認者、理由、時刻を保存
- 拒否時の代替手順を用意
承認対象ツールは3段階に分ける
すべてのツールを承認対象にすると、担当者が疲れて見落とします。逆にすべて自動にすると、AIの誤判断がそのまま業務事故になります。実務では、読み取り、下書き、実行の3段階に分けるのが扱いやすいです。
OpenAIの実務ガイドでも、ツール設計やガードレール、評価を前提にエージェントを設計することが重視されています（OpenAI「A practical guide to building agents」）。承認は単なるUIではなく、ガードレールの一部です。
| 段階 | 例 | 承認 |
|---|---|---|
| 読み取り | 検索、一覧取得 | 不要または低 |
| 下書き | メール文、更新案 | 条件付き |
| 実行 | 送信、削除、支払い | 必須 |
実装前に決めるチェックリスト
承認フローは後付けしにくい機能です。プロトタイプ段階で、どのツールを止めるか、承認者は誰か、承認期限を過ぎたらどうするかを決めておきます。
権限とIDの設計はAIエージェント権限管理とNHI/APIキー棚卸し、ツール接続の境界はMCPとは？AIエージェントで何が変わるのかと合わせて読むと、本番に近い設計になります。
- 承認者が不在の時の扱い
- 承認内容をユーザーに見せる粒度
- 再開後に使える状態情報
- 監査ログの保存期間
よくある質問
OpenAI Agents SDKの承認フローは必須ですか？
読み取りだけなら必須ではありません。ただし、メール送信、DB更新、支払い、権限変更のような副作用があるツールでは最初から入れるべきです。
承認画面はSlackでもよいですか？
小規模検証ならSlackでも構いません。本番では承認者、理由、対象データ、再開結果を保存できる管理画面やログ基盤が望ましいです。
承認が多すぎる場合はどうしますか？
ツールを読み取り、下書き、実行に分け、実行だけを原則承認にします。低リスク処理まで止めると承認疲れが起きます。
出典・一次情報
- OpenAI API Docs「Agents SDK」
- OpenAI Agents SDK「Human-in-the-loop」
- OpenAI「A practical guide to building agents」
最終確認日：2026年6月20日。公式ドキュメントや仕様は変更される場合があるため、導入前に各サービスの最新情報を確認してください。
