Guardrail と approval を一緒にすると、危険な操作は止まらない

要点

要点まとめ

この guide の一番大事な点は、危ない依頼を早く止めることと、取消や送信のような危ない操作の直前で人が止めることは、同じ安全策ではないと分けていることだ。
ここを混ぜると、最初に落とすべき依頼が奥まで進んだり、逆に人が毎回細かい確認をさせられて承認疲れを起こしたりする。
OpenAI はそのために、自動で弾く検査と、実行前に一度止める承認を別レイヤーとして置いている。
読後にやるべきことは、「どの危険を自動で落とすか」と「どの操作を人に止めてもらうか」を tool ごとに分けて書き出すことだ。

読解

何が変わったのか

この guide は、どの場面で何を使うべきかをかなりはっきり切っています。`input guardrail` は最初の依頼を自動検査する仕組み、`output guardrail` は最終回答を外へ出す前の自動検査、`tool guardrail` は function tool の引数や結果まわりを見る自動検査です。一方の `approval` は、人が判断するために実行直前で止める層です。tool に `needsApproval` を付けると、run はそのまま進まず、`interruptions` という中断情報と再開用 `state` を返します。さらに原文は、agent-level の guardrail だけでは複数 agent や handoff をまたいだ全 custom tool を自動で守れるわけではないので、副作用を起こす tool の近くに検査を置く必要があると線を引いています。

日本の文脈

なぜ重要か

日本の社内 agent 導入では、承認フローを挟めば説明責任を果たしたことにしやすいですが、それだけでは遅いし抜けます。危険な依頼を最初に落とす仕組みがなければ、不要な推論や tool 検討が走ります。逆に、tool 実行の直前で止まる承認がなければ、正しそうな文章のまま危険な操作が進みます。manager agent や handoff を含む workflow では、agent-level guardrail が全域で効くわけでもありません。安全性を prompt の善意や最後のレビューに寄せる設計は、ここで破綻しやすいです。

技術ポイント

技術的ポイント

`input guardrail`、`output guardrail`、`tool guardrail` は、それぞれ依頼、最終回答、function tool の引数や結果を対象にする自動検査だ。
`approval` は副作用のある action をそのまま実行せず、`interruptions` と `state` を返して pause する人間承認つき経路だ。
承認の流れは「止める」「承認待ち項目を返す」「アプリ側で approve/reject する」「同じ state から再開する」の 4 段階で、別 run を立て直すのではなく同じ run を継続する。
workflow boundary を誤解すると穴が開く。全 custom tool を守るには、side effect を起こす tool の近くに検査を置く必要がある。

用語

英日キーワード

英語	日本語	補足
input guardrail	入力ガードレール	main agent が動く前に危険な依頼を自動検査する仕組み。
output guardrail	出力ガードレール	最終回答が外へ出る前に内容を検査する仕組み。
tool guardrail	ツールガードレール	function tool の引数や結果まわりを自動検査する仕組み。
side effect	副作用	送信、取消、編集のように外部状態を変える操作。
interruption	中断イベント	承認が必要なため、まだ tool を実行せず pause している状態。

試す

試すなら

いまの agent で「危険なのは入力か、出力か、tool 実行か」を分けて書き出す。
書き込み、取消、送信、shell、機密 MCP 操作のような副作用を起こす tool だけを先に洗い出し、approval の対象にする。
manager agent を使っているなら、agent-level guardrail だけで守れると仮定せず、各 custom tool の横に必要な検査を置く。
承認待ちが長引く運用を想定し、`state` を保存して同じ run を後で再開できるか確認する。

注意

注意点

この guide は control の切り方を示しますが、何を危険とみなすかの業務判定までは代行しない。取消や送信の閾値は自分で決める必要がある。
approval を増やし過ぎると、結局は何でも承認してしまう運用に落ちやすい。人に見せるべきものだけを止めないと、承認疲れで質が下がる。
`Published date` は docs page 上で確認できなかった。

この記事は役に立ちましたか

公益的に続けるため、役に立った点や読みづらかった点だけを短く送れます。メールアドレスは不要です。