Skip to Content
Docs06. セキュリティガードレール
中級guardrailshuman-in-the-loop更新: 2026-10-04この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

ガードレール

この記事の目的

ガードレール(guardrails)を「モデルの外側でコードとして強制される制御」と正しく定義し、入力・出力・アクションの 3 層で何をどこまで固くするかを設計できるようになります。ルールベースと LLM ベースの検査の使い分け、そしてガードレール自体の品質管理(誤検知・見逃しの評価)まで扱います。

対象読者

  • Agent の安全制御を「プロンプトの注意書き」から「実装された仕組み」に引き上げたいエンジニア
  • 過剰なブロックで使いものにならない、逆に緩すぎて意味がない、の間で強度を決めかねているチーム

前提知識

本文

概要: プロンプトの禁止指示はガードレールではない

「危険な操作はしないでください」とシステムプロンプトに書くことは、挙動を改善はしますが、強制ではありません。インジェクションで上書きされえますし、モデルが単に従い損ねることもあります(プロンプトインジェクション)。

本記事でガードレールと呼ぶのは、モデルの判断の外側にあり、コードとして強制される制御です。モデルが何を出力しようと、ガードが通さなければ実行されません。この「モデルを迂回できない」性質が、プロンプト指示との本質的な違いです。

詳細: 3 層のガードレール

Agent の実行フローには、制御を差し込める場所が 3 つあります。

層位置代表的なガード
入力ガードユーザー入力・外部コンテンツがモデルに入る前スコープ外の依頼の遮断(この Agent の目的外の話題)、インジェクション・不正パターンの検知、レート制限、入力サイズ上限
出力ガードモデルの応答がユーザー・下流システムに渡る前機微情報(個人情報・認証情報)のフィルタ、有害・不適切内容の検査、形式検証(構造化出力)、外部 URL の無害化(データ漏えい対策)
アクションガードモデルのツール呼び出し要求が実行される前ツール許可リスト、引数の検証(対象・範囲・形式)、上限(金額・件数・頻度)、承認ゲート(Human-in-the-Loop 設計)、実行環境の隔離(ツール権限設計とサンドボックス)

承認ゲートが決定的に強制するのは「承認なしでは実行しない」という条件です。人の判断の正しさや、LLM の内容判定は保証しません。副作用・外部送信・非信頼入力・機微データアクセスを別々に分類します。

3 層のうちアクションガードが最重要です。入力・出力のガードは内容の判定を含むため確率的になりがちですが、アクションガードは「このツールは呼べない」「この引数は範囲外」「承認がなければ実行しない」という決定的な強制ができる場所だからです。被害はほとんどの場合アクション(副作用)から生まれます。

詳細: ルールベースと LLM ベースの使い分け

方式性質向くもの
ルールベース(コード・正規表現・許可リスト)決定的・高速・安価。判定理由が明確ツール許可リスト、引数の範囲検証、上限、形式検証、既知パターンの機微情報
LLM ベース(検査用のモデル呼び出し)柔軟・文脈を読める。ただし確率的で、それ自体が騙されうる有害性・話題逸脱・「この応答は根拠に基づいているか」など、ルールで書けない判定

原則は「ルールで書けるものはルールで書く。LLM 検査は、決定的ガードの代替ではなく追加の層」です。LLM ベースの検査器も LLM である以上、インジェクションの対象になりえます。検査器が「問題なし」と騙されても被害が出ない位置(決定的ガードの内側)に置きます。

詳細: ガードレール自体の品質管理

ガードレールは付ければ終わりではなく、それ自体が誤検知(正当な操作のブロック)と見逃し(すり抜け)を持つコンポーネントです。

  • 評価します — 正当なケースと攻撃・違反ケースの両方を含むテストセットで、誤検知率と見逃し率を測ります。LLM ベースの検査器は judge と同じ検証手順(LLM-as-a-Judge)を適用します
  • 回帰スイートに含めます — 「ガードが機能したか」は軌跡のアサーション(軌跡(trajectory)評価)としてテストできます。プロンプト・モデルの変更でガードの発火傾向も変わります
  • 発火を監視します — ガードの発火ログは、攻撃の試行・Agent の異常の早期指標です(可観測性とトレーシング)。発火率の急変はインシデントのシグナルとして扱います(インシデント対応)

設計判断: 強度はリスクに比例させる

すべてを最強にすると、誤検知と承認疲れでシステムが使われなくなります。強度の設計は次の 2 つで行います。

実務での注意点

アンチパターン

  • プロンプトの禁止指示を「ガードレール実装済み」と数える → 指示は強制ではなく、迂回・無視されうる → コードで強制される層(特にアクションガード)を主防御にする
  • LLM 検査器を決定的ガードの代わりに使う → 検査器自体が騙されうるため、単独では突破可能な壁にしかならない → 許可リスト・引数検証・承認の内側に「追加の層」として配置する
  • ガードの発火を記録・監視しない → 攻撃の試行や誤検知の多発に気づけず、改善もできない → 発火ログを監視・アラートに接続し、定期的に誤検知率を見直す
  • 全操作に一律で最強のガードを掛ける → 誤検知と承認疲れで、ユーザーが回避策を探し始める(シャドー利用) → リスクに比例した傾斜をつけ、平時は軽く・異常時に強化する

チェックリスト

  • 外部取得を伴う読み取りを送信経路として扱い、機微データの読み取りにアクセスログと量の上限がある
  • 入力・出力・アクションの 3 層それぞれに何のガードがあるか列挙できる
  • 決定的なガード(許可リスト・引数検証・上限・承認)がアクション層にある
  • LLM ベースの検査が決定的ガードの内側に配置されている(代替になっていない)
  • ガードレールの誤検知率・見逃し率をテストセットで測った
  • 「ガードが機能したか」が回帰スイートのアサーションになっている
  • ガードの発火がログ・監視・アラートに接続されている
  • ガードの強度が操作のリスクに比例している(一律でない)
  • 異常時にガードを動的に強化(承認必須化・無効化)できる

関連トピック

参考資料

TODO・未確認事項

データ漏えい対策エージェントの認証・認可