Guardrailsとは？

一つのフィルターではない

Guardrailsは、AIの前に一度だけ置く禁止語フィルターではありません。どこで失敗すると何が起きるかに合わせて、複数の境界へ制御を置きます。

入力では、依頼が対象業務に合うか、秘密情報や攻撃的な指示を含まないかを確認します。出力では、形式、根拠、個人情報、公開可能な内容かを確認します。ツール実行では、ツール名、引数、対象、利用者の権限、副作用を実行直前に確認します。

入力を通過しても、その後に作られたツール引数が安全とは限りません。最終出力が妥当でも、途中で不要な外部操作が行われていれば遅すぎます。入力、出力、実行時を別々に守るのはこのためです。

入力・出力・実行時の3層

OpenAI Agents SDKの実装では、エージェントの入力と最終出力を検査するGuardrailsに加え、関数ツールの呼び出し前後を検査するTool Guardrailsがあります。どの境界へ適用されるかは製品やSDKで異なるため、名称だけでなく実行順序を確認します。

実行時制御はツールの直前に置く

LLMが返したツール名と引数は、提案として扱います。JSON Schemaに合っていても、記事IDが正しいか、利用者が公開権限を持つか、同じ処理を二重実行していないかまでは保証されません。

たとえば publish_article(article_id=42) が提案されたら、アプリ側でツールの許可リスト、引数、権限、現在の状態を検証します。戻しにくい公開操作なら人の承認を待ち、許可された一回だけを実行します。拒否やタイムアウトは失敗として記録し、別のツールへ勝手に置き換えません。

Human approvalとの関係

人の承認はGuardrailsの代わりではありません。自動検査は、大量の呼び出しへ同じ条件を適用するのが得意です。人は、文脈や影響が大きく機械判定だけでは決めにくい操作を確認します。

承認画面には、ツール名だけでなく、対象、主要な引数、起こる変更を表示します。承認後も、実行直前に権限と引数を再検証します。待機中に権限や対象データが変わる可能性があるためです。

設計するときの順番

1. 守る対象と、許可する操作を決める
2. 入力、出力、ツール実行のどこで検査するか決める
3. 許可、修正、停止、承認待ちの動作を決める
4. タイムアウト、回数上限、再試行、二重実行防止を決める
5. 判定理由と実行結果を監査できる形で残す
6. 正常例と失敗例を評価セットにして継続確認する

判定モデルだけに任せず、スキーマ検証、認可、許可リスト、サンドボックス、レート制限など、通常のソフトウェア制御と組み合わせます。

限界を前提にする

Guardrailsを入れても、AIエージェントが完全に安全になるわけではありません。入力の見逃し、誤判定、未知の攻撃、ツール側の不具合、設定ミスは残ります。また、厳しすぎる判定は正常な依頼まで止めます。

そのため「安全になった」と断定するのではなく、どのリスクをどの境界で減らすのかを記録します。検査を回避された場合も、最小権限、隔離、操作上限、監査ログによって影響を小さくします。

覚え方

Guardrailsは、AIを囲う一本の柵ではなく、入力、出力、実行の要所に置く複数の検問です。