AIエージェントにガードレールを付ければ、それだけで安全だと思いがちです。ところが、安全確認を本体と並列に走らせると、判定が終わる前にツールが動く場合があります。OpenAI Agents SDKの仕様から見えるのは、ガードレールの有無よりも「どこで、いつ止めるか」が重要だということです。
並列チェックは低遅延でも、先回りを許します
OpenAI Agents SDKの入力ガードレールには、2つの実行モードがあります。
- 並列実行：ガードレールとエージェントを同時に開始します。既定値で、待ち時間を抑えやすい方式です。
- ブロッキング実行：ガードレールの判定後にエージェントを開始します。不合格なら本体は動きません。
公式ドキュメントは、並列実行でトリップワイヤー（停止判定）が作動しても、キャンセルまでにトークンが消費され、ツールが実行済みになる可能性を明記しています。一方、ブロッキング実行なら、不合格時のトークン消費とツール実行を防げます。
検索や分類のような読み取り中心の処理なら、並列化の利点は大きいでしょう。しかし、メール送信、購入、データ更新、設備操作のような副作用を伴う処理では、「後から止める」は安全設計になりません。送信ボタンを押した後に内容を確認しても遅いのと同じです。
入口と出口だけでは、途中の操作を守れません
SDKでは、エージェントレベルの入力ガードレールはチェーンの最初、出力ガードレールは最終出力を作るエージェントに対して実行されます。マルチエージェント構成の途中で何度もツールを呼ぶ場合、入口と出口の確認だけでは各操作を覆えません。
そこで重要になるのがツールガードレールです。カスタム関数ツールの呼び出しごとに、実行前の入力検査と実行後の出力検査を置けます。設計上は次のように責務を分けると整理しやすくなります。
- 入口：依頼そのものを受け付けてよいか確認する
- 操作直前：対象、権限、金額、宛先などを確定する
- 操作直後：結果に秘密情報や不適切な内容がないか確認する
- 出口：利用者へ返す最終回答を検証する
ただし、SDKのツールガードレールが適用されるのは function_tool で作成した関数ツールです。公式ドキュメントによると、ホスト型ツールや組み込み実行ツール、ハンドオフ自体には同じ仕組みがそのまま適用されません。利用するツールごとに保護範囲を確認する必要があります。
PL視点では「戻せるか」で実行方式を決める
実務では、すべてをブロッキングにすると応答が遅くなり、すべてを並列にすると副作用のリスクが残ります。そこで、ツールを次の3段階に分ける方法が現実的です。
- 読み取り専用：検索、参照、分類。並列チェックを候補にする
- 取り消し可能：下書き保存、仮予約。実行ログと取消手段を必須にする
- 取り消し困難：送金、公開投稿、本番変更。事前のブロッキング検査と人の承認を置く
OpenAIの安全ベストプラクティスも、可能な限り出力を人が確認し、特に高リスク領域やコード生成では人の関与を重視するよう勧めています。ガードレールは人の承認を消す仕組みではなく、承認前に危険な候補を減らす仕組みと考えるのが安全です。
まとめ
AIエージェントの安全性は、チェック項目の多さだけでは決まりません。重要なのは、危険な操作より前に判定が完了することです。
- 並列実行は低遅延ですが、停止前にツールが動く可能性があります
- 副作用の大きい操作はブロッキング検査を優先します
- 入口と出口に加え、各ツールの実行前後にも境界を置きます
- 取り消し困難な操作には、人の承認を残します
「安全確認を入れたか」ではなく、「安全確認が終わる前に何が動けるか」。この問いが、エージェントを実験から業務へ移すときの設計レビューを一段具体的にします。