AIガードレールは、LLMを使う仕組みに付ける「はみ出し止め」だ。利用者が入れた文章、モデルが返した答え、AIエージェントが呼び出そうとするツールを途中で確かめ、決めた範囲から外れたら止めるか、直すか、記録する。OpenAIのAgents SDKの文書は、ガードレールを、利用者の入力とエージェントの出力を確かめて検証するものと説明している。
LLMは、同じ質問にも毎回少し違う答えを返す。プロンプトに「個人情報は出さない」と書いても、そう振る舞う保証はない。だから、モデルの外側に、決まった通りに動く確認の層を置く。これがガードレールの考え方だ。
この記事は、ガードレールをどこに置き、何を確かめるかを、主なクラウドとオープンソースの公式文書から整理し、社内で作るときの順番をまとめる。LLMアプリケーションの代表的なリスクの一覧はOWASPのLLMアプリケーションのリスクに、攻撃の仕組みはプロンプトインジェクションとはに書いたので、ここでは守る側の部品に絞る。
ガードレールを置く場所は5つある
ガードレールは、LLMとのやり取りのどの段階で確かめるかで分けると分かりやすい。NVIDIAのオープンソースのPythonのライブラリ、NeMo Guardrailsの文書は、レールを5つに分けている。
| 置く場所 | NeMo Guardrailsの説明 | 確かめることの例 |
|---|---|---|
| 入力 | LLMを呼ぶ前に、利用者の入力を検証し、無害にする | 指示を書き換えようとする文、個人情報、業務と関係のない依頼 |
| 検索 | 検索で取ってきた文書や断片を絞り込み、信頼できる文脈だけを渡す | 権限のない文書、文書に埋め込まれた指示 |
| 対話 | 複数回のやり取りを方向づけ、会話の流れの決まりを守らせる | 決めた手順を飛ばしていないか |
| 実行 | ツールや関数の呼び出しと、その引数と結果を確かめる | 送金額の上限、宛先、消してよいファイルか |
| 出力 | モデルの答えを評価し、決まりに外れた内容を止めるか直す | 有害な表現、個人情報、根拠のない答え |
右の列の例は私が当てはめたものだ。社内の文書を検索して答える仕組みでは、検索のガードレールが効く。文書の側に攻撃の指示が仕込まれる経路があるからだ。AIエージェントでは、実行のガードレールがいちばん大事になる。答えが少し変でも人が読めば気づけるが、ツールの呼び出しは、間違えるとそのまま外に影響が出る。
OpenAIのAgents SDKも、入力・出力・ツールの3種類のガードレールを持つ。ツールのガードレールは、関数のツールを包み、実行の前と後で呼び出しを確かめて止められる。確かめた結果が決まりに外れたら、トリップワイヤと呼ぶ合図で処理を止める作りだ。
主な製品・オープンソースで何ができるか
ガードレールは一から作らなくても、クラウドの機能やオープンソースで多くの部分をまかなえる。公式文書に書かれている機能を並べるとこうなる。
| 名前 | 提供元 | 主な機能（公式文書の記述から） |
|---|---|---|
| Amazon Bedrock Guardrails | AWS | 有害な内容のフィルタ、拒否する話題、単語のフィルタ、機微な情報のフィルタ、文脈に基づく根拠の確認、自動推論による確認 |
| Prompt Shields | Microsoft（Azure AI Content Safety） | 利用者のプロンプトによる攻撃と、文書に埋め込まれた攻撃の検出 |
| NeMo Guardrails | NVIDIA | 入力・検索・対話・実行・出力の5種類のレールをプログラムで書ける |
| Llama Guard 4 | Meta | 入力と出力の両方を分類する、120億パラメータの安全確認用のモデル。画像も扱える |
| Agents SDKのガードレール | OpenAI | 入力・出力・ツールの確認と、トリップワイヤによる停止 |
AWSのBedrock Guardrailsは、機微な情報のフィルタで個人情報を止めるか伏せ字にでき、正規表現で独自の型も足せる。文脈に基づく根拠の確認は、検索拡張生成（RAG）の答えが、取ってきた文書に基づいていないときに止めるか印をつける機能だ。モデルを呼ばずに確認だけを行うApplyGuardrailというAPIもある。
MicrosoftのPrompt Shieldsは、守れる範囲をはっきり書いている。操作しようとする試みは検出するが、内容が有害か、事実として正しいか、文書に基づいているか、方針に沿っているかは判断しない。それには別のガードレールを使うよう書かれている。日本語のような英語以外の言語については、主に英語で学習・評価されているため性能が変わりうるとしている。
私の見方では、この2点は製品を選ぶときに読み落としやすい。一つの部品で全部を守れるわけではないこと、日本語の業務では自分たちの文章で試し直す必要があることだ。
ガードレールにできないこと
ガードレールを入れても、攻撃を全部止められるわけではない。OWASPのLLMアプリケーションのリスクの2026年版は、プロンプトインジェクションについて、確実な防止策は今のところ存在しないとし、守りは途中で止めることより設計で行うものだとしている。LLMは「指示」と「データ」を構造の上で区別しないので、SQLインジェクションに対するパラメータ化クエリにあたるきれいな対策はない、という説明だ。
入力のガードレールは、攻撃の文を見分けようとする分類器にすぎない。言い回しを変えた攻撃や、見えない文字に隠した指示はすり抜けることがある。出力のガードレールも、答えを見てから判断するので、エージェントがすでに実行したツールの呼び出しは取り消せない。
だから、ガードレールは「最後の砦」ではなく「被害を減らす層の一つ」として置く。私の見方では、優先順位は次の通りだ。
- 権限を絞る。AIが読める文書、呼べるツール、書き込める先を、業務に要る分だけにする
- 取り返しのつかない操作の前に、人の確認を挟む
- その上で、入力・検索・実行・出力のガードレールを重ねる
- 止めた記録と、すり抜けた事例を集め、決まりを直し続ける
1と2は、ガードレールが外れても被害を小さくする。AIエージェントの権限の設計はAIエージェントのセキュリティにまとめた。もっともらしい誤りへの備えは、出力のガードレールだけでは足りないので、ハルシネーション対策の設計と運用もあわせて見てほしい。
社内のAIにガードレールを入れる手順
社内向けのチャットや、業務を代わりに進めるAIエージェントにガードレールを入れるとき、私は次の順番で考える。
| 順番 | やること | 決めておくこと |
|---|---|---|
| 1 | 守るものを書き出す | 出してはいけない情報、やってはいけない操作、答えてはいけない話題 |
| 2 | どこから入ってくるかを書き出す | 利用者の入力、検索する文書、メールやWebページ、ツールの結果 |
| 3 | 汎用の部分は既存の機能を使う | 有害な表現・個人情報・攻撃の検出をどの製品で行うか |
| 4 | 業務固有の決まりを書く | ツールに渡してよい値の範囲、宛先の許可リスト、金額の上限 |
| 5 | 止めたときの振る舞いを決める | 利用者への返事、担当者への通知、記録の残し方 |
| 6 | 日本語の攻撃と普段の文章で試す | 止めすぎていないか、すり抜けていないか |
| 7 | 運用で直し続ける | 誰が記録を見て、いつ決まりを更新するか |
4の業務固有の決まりは、製品を入れても手に入らない。たとえば経費の申請を手伝うエージェントなら、金額が一定を超えたら人の承認に回す、という決まりは、モデルの外側にふつうのプログラムとして書く方が確実だ。私の見方では、ガードレールのうちAIで判定する部分は少ないほどよく、決まった値で判定できるものはすべてコードで書いた方がよい。
6の試験では、止めすぎにも気をつける。ガードレールが厳しすぎると、普通の質問まで断られ、現場が使わなくなる。MicrosoftのPrompt Shieldsの文書も、誤検出が多いときは止める設定から記録だけ残す設定に変えて様子を見る方法を挙げている。どこまで止めるかは、止め損ねたときの被害の大きさで決める。
ガードレールは作って終わりではない
ガードレールの決まりは、業務が変わるたびに古くなる。新しいツールをつないだ、検索する文書の範囲を広げた、利用者の部署が増えた。そのたびに、守るものと入口を書き出し直す必要がある。
私の見方では、ガードレールで最初に決めるべきなのは製品ではなく、止めた記録を誰が見るかだ。記録を誰も見ない仕組みは、すり抜けにも止めすぎにも気づけない。現場の業務を知り、AIの仕組みの中まで直せる人がいて、はじめてガードレールは育つ。そうした役割を担う職種としてのFDEはFDEとは？Forward Deployed Engineerの意味と仕事内容に書いた。
社内のAIの使い方に、どこまでガードレールが要るかを確かめたい場合は、AI利用セキュリティ診断のページに、私たちが何を見るかをまとめている。