ガードレールとは、AI エージェントに許される行動を制約するために、その周囲に置かれるポリシー、統制、仕組みのことである。この語はいくつもの層で使われており、ここで扱う情報源は 1 つの定義を共有していないため、以下のどの定式化も合意されたものとして読むべきではない。
ある説明は、AI エージェントのための効果的なガードレールの実装 で示されているもので、組織的かつソフトウェアデリバリーに特化している。それによれば、ガードレールとは、AI エージェントが開発環境とどのように関わるかを統制するポリシー、統制、監視の仕組みからなる包括的なフレームワークである。そこでは、この概念は従来のセキュリティ統制を超えるものとして説明されている。すなわち、自律的なコード生成や自動化されたインフラ管理など、従来は人間による監督を必要としていた機微な操作をエージェントが担うようになるなかで、AI システムが組織のポリシーや規制要件を遵守しつつ、安全かつ効果的に動作することを保証するものである。
これは 4 つの説明のうちの 1 つ目であり、それぞれがこの語に異なる側から迫っているため、区別しておく価値がある。1 つ目は組織的なもので、企業がエージェントの行動の周囲に置くアクセス制御、承認ゲート、監査証跡を説明する。2 つ目はアプリケーションレベルのもので、開発者がエージェントの入力と出力の周囲に置く分類器やフィルターを説明する。3 つ目はフレームワークレベルかつ決定論的なもので、モデルの外側で実行されるコードにルールを置き、ツール呼び出しをそもそも実行してよいかどうかを判断する。4 つ目は、アプリケーションコードとモデルの間に挟まれるツールキットの層であり、そこではレールがアプリケーションロジックとして書かれるのではなく、設定と専用の言語で宣言される。いずれも同じ目的、つまりエージェントにできることを制約するために同じ語を使っているが、作用する層が異なり、どれも他を包含しない。次節の最後で取り上げる 5 つ目の情報源は、5 つ目の層を加えるものではない。それはアプリケーションレベルの意味を、より狭い、製品固有の形で言い直しているにすぎない。一方、他の 4 つが届かない 5 つ目の層を実際に加える説明が 1 つある。モデル提供者が自社の展開済みモデルにリアルタイムで適用する強制であり、これは後述の「提供者側での強制」で扱う。
用法
54 人の DevSecOps の実務家とリーダーへのインタビューに基づき、1 つ目の説明は AI エージェントのためのガードレールを 4 つのカテゴリに分類している。ユーザーロールとアクセス制御は、AI ツールにシステムへのアクセスを許可する前に二要素認証またはシングルサインオンを要求すること、そしてシークレット、認証情報、保護されたブランチに触れる AI の操作にロールベースのアクセス制御を適用することを求める。制限と統制は、エージェントの行動が直接行えることを制約する。手動レビューなしの本番環境への直接デプロイをブロックすること、AI が生成した変更を人間が書いた変更と同じマージリクエストのレビュープロセスに通すこと、定められたコストの閾値を超える場合に手動承認を要求すること、インフラやリソースの削除に複数人のレビューを必須とすること、そしてすべてのエージェントの行動についてロールバック可能な状態を維持することである。カスタマイズにより、組織はこれらの境界を自らの運用手順に合わせて調整できる。管理者が設定できる禁止コマンド（例：Terraform の state の消去、ドメイン名の変更）、顧客への影響に応じた人間の関与ポイント、ユーザーロールごとに調整可能な自動化レベルなどである。ログ記録、追跡、透明性は、AI が起こした変更とそれに関わった人間の承認の両方を記録する監査証跡、AI の判断に対する説明、AI が生成したコードやサードパーティのコードに対するライセンス遵守のチェック、そして本番データへのアクセスに対するコンプライアンス主導のきめ細かな統制を扱う。
エージェント構築の実践ガイド は、ガードレールを単一のアプリケーションのレベルで、しかも単一の統制ではなく多層防御として扱っている。そこでの OpenAI の立場は、1 つのガードレールだけでは十分な保護を提供できる可能性は低く、複数の専門化されたガードレールを組み合わせて使うことで、より堅牢なエージェントが生まれるというものである。その具体的な構成例では、LLM ベースのガードレール、正規表現などのルールベースの保護、モデレーション API を組み合わせ、関数呼び出しに進む前にユーザー入力を精査している。このガイドは 7 つの種類を挙げている。
- 関連性分類器 — 範囲外のクエリにフラグを立て、応答を意図された範囲内に保つ。
- 安全性分類器 — ジェイルブレイクやプロンプトインジェクションの試みを検出する。その例として、教師の役を演じてシステム指示を暗唱するよう求めるリクエストが挙げられている。
- PII フィルター — モデルの出力に個人を特定できる情報が含まれていないかを精査する。
- モデレーション — 入力に含まれるヘイトスピーチ、ハラスメント、暴力にフラグを立てる。
- ツールのセーフガード — 利用可能な各ツールを、読み取り専用か書き込み可能か、可逆性、必要なアカウント権限、金銭的影響といった要素に基づいて低・中・高のリスクで評価し、その評価を使って高リスクの呼び出しの前にチェックのため一時停止したり、人間にエスカレーションしたりする。
- ルールベースの保護 — ブロックリスト、入力長の制限、正規表現フィルターなど、既知の脅威に対する決定論的な対策。
- 出力の検証 — 応答をブランドの価値観に沿ったものに保つためのプロンプトエンジニアリングとコンテンツチェック。
同じガイドは、ガードレールを構築するための 3 段階の経験則を示している。まずデータのプライバシーとコンテンツの安全性に注力し、現実のエッジケースや失敗が現れるたびに新たなガードレールを追加し、エージェントの進化に合わせてセキュリティとユーザー体験の両方を最適化する、というものである。また、ガードレールは通常のセキュリティエンジニアリングの代わりにはならず、堅牢な認証・認可のプロトコル、厳格なアクセス制御、標準的なソフトウェアセキュリティ対策と組み合わせるべきだと強調している。OpenAI Agents SDK では、これは @input_guardrail 関数として実現されており、その tripwire_triggered 出力が実行を中断させる。ガードレールは主エージェントに先立ってではなく、主エージェントと並行して実行される。
このガイドのガードレールの扱いにおける最後のセーフガードは、フィルターですらない。ヒューマン・イン・ザ・ループ による介入を計画しておくことを重要なセーフガードとして扱い、その 2 つのトリガーとして、失敗の閾値を超えた場合と、機微である、不可逆である、あるいは重大な結果を伴う高リスクの行動を挙げている。
3 つ目の説明は、ガードレールをさらに低い位置、つまり分類器や組織的なプロセスではなくエージェントフレームワークそのものに置く。AI エージェントのガードレール：LLM が回避できないルール で説明されているこの捉え方では、システムプロンプトやツールの docstring に散文として表現されたガードレールは、モデルが呼び出しのたびに解釈し直し、判断し直す入力にすぎないため、何も確実には制約しない。この投稿の例は、ツールの docstring が求める支払いなしに予約を確定させ、成功したと報告するエージェントである。代わりにこの投稿が提案するガードレールは、実行前のインターセプターが評価する決定論的なルールであり、ツールが実行される前に呼び出しを取り消し、違反内容を結果としてモデルに返す。この意味を上記の分類器ベースの意味と区別するのは、層だけでなく判断の種類である。これらのルールは、コンテンツに関する確率的な判断ではなく、ツール呼び出しのパラメーターに対するブール述語であり、この投稿は 3 つのデモシナリオ全体で偽陽性ゼロ、偽陰性ゼロを報告している。ただしその決定性は、書き下されたものの範囲に限られる。投稿は、保護すべき操作ごとにルールを明示的に定義しなければならないと述べており、誰もルールを書いていない操作は保護されない。このパターンについては ニューロシンボリック検証 を、それが依拠する割り込みの仕組みについては エージェントフック を参照。
4 つ目の説明は、フレームワークやポリシー文書ではなくツールキットに由来するもので、その特徴的な点は、ガードレールをアプリケーションコードと LLM の間に独立した層として置くことである。NVIDIA NeMo Guardrails はこれをプログラム可能なガードレール、あるいはレールと呼び、モデルの出力を制御する特定の方法と定義している。その例は、政治について話さないこと、特定のリクエストに特定の方法で応答すること、あらかじめ定められた対話経路に従うこと、特定の言語スタイルを使うこと、構造化データを抽出することである。この説明が上記の 3 つに加えるのは、組織的な層によるのではなく、リクエスト内での位置による分類である。ユーザー入力を拒否または変更できる入力レール、モデルへのプロンプトの与え方に影響を与え、あらかじめ定められた応答に置き換えることもできる対話レール、RAG パイプラインで取得されたチャンクを拒否または変更する検索レール、ツールの入力と出力に適用される実行レール、そしてモデルが生成したものを拒否または変更できる出力レールである。レールはプロンプト内の散文として表現されるのではなく、設定フォルダー — 有効なフローを指定する YAML と、Colang で書かれた定義 — の中で宣言される。この点で、この説明は分類器ベースの 2 つ目よりも決定論的な 3 つ目に近い。ただし、設定されたフローの中には事実のセルフチェックのようなモデルベースのチェックも含めることができる。
マルチエージェントワークフローを構築するためのノードベースの製品である Agent Builder に関する OpenAI の安全性ガイダンスは、アプリケーションレベルの意味に、より狭い形で立ち返っている。そしてそれは、分類に何を加えるかよりも、その主張の範囲をいかに控えめに定めているかという点で注目に値する。そこではガードレールは、入ってくる入力をサニタイズするためにワークフローに置かれるノードであり、挙げられている 2 つの役割は、個人を特定できる情報の編集（redaction）とジェイルブレイクの試みの検出である。同じページは、それらのノードだけでは万全ではないと述べ、効果的な第一陣の防御と呼んでいる。また、上記の説明とは異なる形で境界を引いている。OpenAI 自身のガイドが人間の介入をガードレールの章のセーフガードとして扱っているのに対し、このページはツールの承認を独立した節で扱い、MCP ツールを使う場合には承認を有効にしておくよう求めている。その方法は専用の承認ノードによるもので、読み取りを含むすべての操作を人が確認する。これらの手法を組み合わせることで、プロンプトインジェクション、悪意あるツールの使用、予期しないエージェントの振る舞いのリスクが大幅に減ると述べる一方で、構造化出力と隔離はリスクを大きく減らすが完全には取り除かないこと、そしてこれらの緩和策があってもエージェントは依然として誤りを犯したり騙されたりしうることを別に述べている。このガイダンスは、OpenAI が非推奨にするとしている製品に結びついており、その提供終了は 2026 年 11 月 30 日に予定されている。
提供者側での強制
上記の説明が扱っていない層として、モデル提供者自身が、展開済みのモデルに対してリアルタイムで運用する層がある。（上記の 4 つの説明はモデルの上に構築する側の視点から書かれているが、こちらは提供者の視点から書かれている。この対比も、これを「ガードレール」のさらなる意味として扱うという判断も、このページ独自の枠組みである。以下の投稿はこの語を将来構築するかもしれないセーフガードについてのみ使っており、ここで説明する仕組みは強制措置（enforcement actions）と呼んでいる。）Claude のためのセーフガードの構築 は、Anthropic によるこの層の実装を説明している。
その検出の仕組みは一連の分類器であり、特定の種類のポリシー違反をリアルタイムで検出するよう設計された、プロンプトで調整された、あるいは特別にファインチューニングされた Claude モデルである。複数の分類器を同時に展開でき、それぞれが異なる種類の害を監視しながら、主となる会話は自然に進んでいく。エンジニアリング上の制約ははっきりと述べられている。計算のオーバーヘッドと、無害なコンテンツに対する強制の両方を抑えながら、何兆もの入力・出力トークンを処理しなければならない。
この層をフィルターと区別するのは、分類器が何を引き起こせるかである。応答のステアリングは、リクエストの処理中に、モデルがプロンプトをどう解釈しどう応答するかを調整する。投稿の例は、スパムやマルウェアを生成しようとする明らかな試みを分類器が検出したときに、システムプロンプトに指示を自動的に追加するというものである。また、限られたケースでは、提供者はモデルの応答そのものを止めることができる。単一のリクエストを超えて、違反のパターンはアカウント単位の措置につながりうるもので、それには警告や、深刻な場合にはアカウントの停止が含まれる。つまり同じ語が、入ってくるものや出ていくものを選別するだけでなく、処理中のリクエストを変更する統制をも指しているのであり、それがこれを、アプリケーションレベルの意味を移し替えたものではなく、独自の意味たらしめている。投稿はこの強制措置の列挙を網羅的な一覧ではなく「〜を含む」ものとして説明しており、Anthropic のファーストパーティ製品では、分類器と並んで、既知の児童性的虐待コンテンツに対する別個のハッシュ照合による検出があることも説明している。
投稿はまた、この実行時の層を作業の全体として扱うのではなく、ライフサイクルの中に位置づけている。ポリシーの策定、モデルの学習への影響、デプロイ前のテスト、デプロイ後の監視がその周囲を取り巻いている。テストの層がリリースされた製品を変えた一例として報告されているのがコンピュータ操作ツールで、リリース前の評価でこの機能がスパムの生成と拡散を助長しうることが判明し、リリース前に新たな検出手法、強制の仕組み、プロンプトインジェクション対策が追加された。機能そのものについては、他のベンダーによる文書に基づいて コンピュータ操作（Computer Use） で扱っている。
これらのいずれにも有効性の数値は伴っていない。投稿は分類器の適合率や再現率も、無害なトラフィックに対する偽陽性率も示していない。したがって、これが示しているのは、この層が存在することとそれが何をできるかであって、それがどれほどうまく機能するかではない。
関連用語
サンドボックス化, ヒューマン・イン・ザ・ループ, エージェント型エンジニアリング, ニューロシンボリック検証, エージェントフック, AI エージェントのための効果的なガードレールの実装, AI エージェントのガードレール：LLM が回避できないルール, エージェント構築の実践ガイド