ジェイルブレイク対策、構造的防御、実行時の検知と対応（AIDR）——エージェントの「守り」は、この1年で設計の選択肢が一気に増えました。入力フィルタを入れ、出力をチェックし、ツール実行に許可リストをかける。ここまでは、多くの現場ですでに手が動いています。
問題は、その後です。本番に出したガードレールは、何もしなければ静かに劣化します。誤検知で業務が止まるたびに例外が足され、ルールは肥大し、誰も全体を説明できなくなる。気づいたときには「たくさん入っているのに、肝心なところが素通り」という状態になっています。
これは、ネットワーク運用の現場で何度も見てきた光景です。ファイアウォールのACLは、導入した日がいちばんきれいで、そこから年々汚れていきます。使われていないルール、上位ルールに隠れて一度もヒットしないルール、「一時的に」と言って開けたまま何年も残る例外。ガードレールは、まったく同じ道をたどります。
本稿では、ガードレールを「入れて終わり」の機能ではなく、運用し続ける”防御資産”として扱うための規律——GuardrailOps——を整理します。誤検知率と見逃し率のトレードオフ監視、例外（許可リスト）の棚卸し、ルールの版管理とシャドー評価、そしてガードレール自体のレイテンシとコスト。目指すのは、「守りが業務を止める」と「形だけの守り」の両方を防ぐことです。
本稿の位置づけ
AgentOps連載では、PromptOps（指示資産）、ナレッジ運用（参照資産）、ツール運用（能力資産）、モデル運用と、エージェントを構成する資産を順に「運用対象」にしてきました。残っている大きな資産が、ガードレール——防御資産です。
ガードレールについては、これまでも複数の記事で扱ってきました。本稿との違いは次のとおりです。
| 既存記事 | ガードレールをどう扱ったか | 本稿との違い |
|---|---|---|
| ジェイルブレイク対策／構造的防御 | 守りをどう設計するか（多層化・権限分離・構造で防ぐ） | 本稿は、作った守りを運用し続ける話 |
| 「守る側」へのメタ攻撃 | 攻撃者がガードレールを破る手口と対策 | 本稿は攻撃がなくても、例外の追加とルールの陳腐化で自然に劣化する問題 |
| AIDR | 実行時の検知と対応 | 本稿は、検知ルールそのもののライフサイクル |
| AgentOps・PromptOps編 | 指示資産の版管理と評価 | 本稿は防御資産の版管理と評価 |
設計記事が「設計書」だとすれば、本稿は「保守手順書」です。設計がどれだけ正しくても、保守されない守りは、いずれ守りではなくなります。
なぜガードレールは”放っておくと”劣化するのか
例外は「足す理由」しかなく、「消す理由」がない
誤検知で業務が止まると、現場から「これを通してほしい」という依頼が来ます。止まっているのは売上や顧客対応なので、対応は急ぎです。担当者は許可リストに1行足し、問題は解決します。
ところが、その例外を消すきっかけは、どこにもありません。依頼した人は困っていないので何も言わない。消して何か起きたら責任を問われるので、誰も消したがらない。結果として、例外は単調増加します。ファイアウォールのACLが肥大するのと、まったく同じ力学です。
環境が変わり、ルールが古くなる
劣化の原因は例外だけではありません。ガードレールが前提にしている環境そのものが変わります。
- モデルが変わる：モデル更新で出力の言い回しが変わり、出力フィルタの正規表現がヒットしなくなる
- 業務が変わる：新しい業務フローで、正当な入力が既存ルールに引っかかり始める
- ツールが変わる：ツールの追加・引数変更で、許可リストが実態と合わなくなる
- 攻撃が変わる：新しい手口に対して、既存ルールが何も反応しない
どれも、ガードレール側には一切手を入れていないのに起きる劣化です。「何も変えていないから安全」ではなく、「何も変えていないから古くなっている」と考えるのが運用の基本姿勢です。
2つの失敗モード
劣化したガードレールは、次のどちらか（または両方）に陥ります。
| 失敗モード | 症状 | 現場で起きること |
|---|---|---|
| 守りが業務を止める | 誤検知が多い。正当な依頼がブロックされる | 利用者が離れる。「ガードレールを外せ」という圧力が強まり、雑な例外が増える |
| 形だけの守り | 見逃しが多い。ルールはあるがヒットしない | 監査上は「対策済み」なのに、実際には素通り。事故が起きて初めて気づく |
厄介なのは、前者を直そうとすると後者に寄ることです。誤検知を減らすために例外を足し、閾値を緩めると、見逃しが増える。だからこそ、2つを同時に見る運用が必要になります。
まず棚卸し——ガードレールという”防御資産”を一覧にする
運用の第一歩は、自分たちが何を持っているかを把握することです。ガードレールは、プロンプトやツールに比べてあちこちに分散して実装されがちです。入力の前段、モデル呼び出しのラッパー、ツール実行の手前、出力の後段——それぞれ別のチームが別の仕組みで入れていることも珍しくありません。
| 資産の種類 | 例 | 劣化の典型パターン | 運用で見る指標 |
|---|---|---|---|
| 入力フィルタ | プロンプトインジェクション検知、禁止トピック判定、PII検知 | 業務の変化で誤検知が増える／新手口を見逃す | ブロック率、誤検知率、見逃し率 |
| 出力フィルタ | 機密情報・PIIのマスキング、有害表現の検知、根拠のない断定の検知 | モデル更新で言い回しが変わり、パターンがヒットしなくなる | マスキング率、モデル更新前後の差分 |
| ポリシー判定 | LLMによる判定（LLM-as-a-judge）、分類器 | 判定モデルの更新で判断基準がずれる | 判定の一致率、レイテンシ、コスト |
| 許可リスト／拒否リスト | ツール・宛先ドメイン・コマンド・ファイルパスの許可リスト、例外リスト | 例外が単調増加し、期限切れ・未使用が溜まる | 件数、期限切れ件数、ヒット数ゼロの件数 |
| 実行ガード | 金額・件数の上限、承認必須アクション、レート制限 | 業務の拡大で上限が実態に合わなくなる | 上限到達回数、承認待ち時間 |
この一覧には、各ガードレールのオーナー（誰が判断するか）と配置場所（どこで動いているか）を必ず書き添えます。オーナーのいないルールは、誰にも消せないルールです。
規律1：誤検知率と見逃し率のトレードオフを監視する
2つの率は、必ずセットで見る
ガードレールの品質は、次の2つで表せます。
- 誤検知率（False Positive）：正当な入出力を、誤ってブロックした割合。業務を止めるコスト
- 見逃し率（False Negative）：ブロックすべきものを、素通りさせた割合。事故のリスク
この2つはトレードオフの関係にあります。閾値を厳しくすれば見逃しは減りますが誤検知が増え、緩めればその逆になります。どちらか片方だけを報告するダッシュボードは、判断を誤らせます。「誤検知が半分になりました」という報告は、見逃し率が同時に示されて初めて評価できます。
どうやって測るか
本番環境では、正解ラベルが自動ではつきません。そのため、2つの率は別々の手段で推定します。
| 測りたいもの | 測り方 | ポイント |
|---|---|---|
| 誤検知率 | ブロックされたログを定期的にサンプリングし、人がレビューする | 利用者からの「止められた」という申告（異議申し立て）も入力にする。申告の仕組みがないと、誤検知は”静かな離脱”として消える |
| 見逃し率 | 既知の攻撃・違反パターンを集めた評価セットを定期的に流す | レッドチーミングで見つかった手口を評価セットに追加し続ける。評価セットが古いと、見逃し率は実態より良く見える |
| 両方 | 正当な入力と違反入力を混ぜたゴールデンセットで回帰テスト | ルール変更のたびに流し、両方の率の変化を確認する |
閾値は「リスクの高さ」で変える
すべてのエージェント・すべての操作に同じ閾値をかける必要はありません。読み取りだけの社内QAと、送金や外部送信を行うエージェントとでは、許容できる見逃し率がまったく違います。リスクの高い操作ほど見逃しを嫌って閾値を厳しくし、誤検知はヒューマンレビュー（承認フロー）で吸収する。リスクの低い操作は誤検知を嫌って閾値を緩める。この使い分けを、ガードレールごとに明文化しておきます。
規律2：例外（許可リスト）を棚卸しする
例外は”負債”として扱う
例外は、守りに意図的に開けた穴です。必要な穴もありますが、開けた瞬間から返済義務のある負債として扱います。そのために、例外の登録時点で次の項目を必須にします。
- 申請者と承認者：誰が求め、誰が許可したか
- 理由と関連チケット：どの誤検知・どの業務要件に対応したものか
- 適用範囲：どのエージェント・どの利用者・どの操作に効くか（できるだけ狭く）
- 有効期限：期限のない例外は登録させない。恒久化が必要なら、期限到来時に再承認する
「とりあえず全体に許可」「期限は未定」という例外は、後から必ず誰にも説明できない穴になります。
棚卸しで探すもの——ACL監査と同じ観点
定期的な棚卸しでは、ファイアウォールのルール監査とほぼ同じ観点で例外とルールを洗い出します。
| 観点 | ファイアウォールでの姿 | ガードレールでの姿 | 対処 |
|---|---|---|---|
| 期限切れ | 「一時開放」のまま残っているルール | 有効期限を過ぎた許可リスト項目 | 自動で無効化し、必要なら再申請させる |
| 未使用 | ヒットカウントがゼロのルール | 一定期間一度もマッチしていない例外・ルール | オーナーに確認のうえ削除。ヒット数のログが前提 |
| シャドー（隠れ）ルール | 上位ルールに先にマッチされ、一度も評価されないルール | 前段のフィルタや広い許可に吸収され、実際には効いていないルール | 評価順序を可視化し、効いていないルールを洗い出す |
| 広すぎる許可 | any/any に近い許可 | ワイルドカードのドメイン許可、全ツール許可、全利用者向け例外 | 実際のマッチ実績から範囲を絞り込む |
| 重複・矛盾 | 同じ条件を別々に定義したルール | チームごとに別々に足された同じ例外、許可と拒否の衝突 | 統合し、オーナーを一本化する |
このうちシャドー（隠れ）ルールは、特に見落とされがちです。ルールは存在し、設定画面にも見えるので「対策済み」に数えられますが、実際には一度も評価されていません。「形だけの守り」の典型です。ネットワーク運用でルールのヒットカウントを見るのと同じように、ガードレールにも「どのルールが、いつ、何回効いたか」のログを残すことが、棚卸しの前提条件になります。
規律3：ルールを版管理し、シャドー評価で入れ替える
ガードレールはコードとして扱う
ガードレールのルール、閾値、許可リスト、判定用プロンプトは、すべてリポジトリで版管理します。管理画面から直接書き換える運用は、緊急時を除いて避けます。版管理しておけば、「いつ、誰が、なぜ変えたか」が追え、問題が起きたときに直前の版に戻せるからです。
見落としやすいのが、LLMを判定に使うガードレールです。判定用のプロンプトや判定モデルのバージョンも、ルールの一部です。判定モデルが更新されれば、ルールの文言を一文字も変えていなくても判断が変わります。モデル運用編で扱ったバージョンのピン留めは、ガードレール用のモデルにも適用します。
シャドー評価——本番トラフィックで”判定だけ”させる
新しいルールをいきなり本番で有効にすると、誤検知で業務を止めるリスクがあります。そこで、段階的に入れ替えます。
- オフライン評価：ゴールデンセットで誤検知率・見逃し率を確認する
- シャドーモード：本番トラフィックに対して判定だけを行い、ブロックはしない。旧ルールとの判定差分をログに残す
- 差分レビュー：「新ルールだけがブロックしたもの」「旧ルールだけがブロックしたもの」を人がレビューし、どちらが正しいかを判断する
- カナリア適用：一部の利用者・一部のエージェントで有効化し、誤検知の申告や業務指標を監視する
- 全面適用と旧ルールの廃止：旧ルールを確実に削除する（残すとシャドールールになる）
ポイントは手順2〜3の判定差分です。新旧のルールの違いが、実際のトラフィックでどう現れるかを見てから判断できるため、「入れてみたら業務が止まった」「入れ替えたら見逃しが増えていた」の両方を事前に防げます。
緊急変更の扱い
新しい攻撃手口が見つかったときなど、シャドー評価を待てない場面もあります。その場合は緊急変更として即時適用を認めますが、事後に必ず通常の手順（評価セットへの追加、差分レビュー）に乗せることをルールにします。緊急変更が事後処理されないまま積み重なるのも、例外と同じく劣化の原因です。
規律4：ガードレール自体のレイテンシとコストを監視する
ガードレールは”ホットパス”にいる
ガードレールは、すべてのリクエストの通り道に置かれます。つまり、ガードレールの遅延はそのままエージェントの遅延になり、ガードレールの障害はそのままエージェントの障害になります。入力判定、出力判定、ツール実行前の判定とLLMベースのチェックを重ねると、本体のモデル呼び出しと同じくらいの時間がかかることもあります。
監視すべきは平均値ではなく、p95／p99などの裾のレイテンシです。判定用モデルの混雑やタイムアウトは、裾に現れます。
タイムアウト時の方針を決めておく——fail-open か fail-closed か
ガードレールが応答しないとき、リクエストを通すのか（fail-open）、止めるのか（fail-closed）。これを事前に決めていない現場は少なくありません。決めていないと、実装のデフォルト任せになり、障害時に初めて「実は素通りしていた」ことが分かります。
| 操作のリスク | 推奨される方針 | 理由 |
|---|---|---|
| 高（送金、外部送信、データ削除、権限変更） | fail-closed（止める） | 止まるコストより、素通りのコストの方が大きい |
| 中（社外向けの回答生成など） | fail-closed＋代替応答、または人の確認へ回す | 業務を完全には止めずに、リスクを抑える |
| 低（社内向けの読み取り専用QAなど） | fail-open（通す）＋事後ログ監査 | 守りの障害で業務を止めない |
どちらを選んだにせよ、fail-openが発動した件数は必ず記録・アラートします。「守りが効いていなかった時間」を把握できないのは、形だけの守りと同じです。
コストを抑える——安い判定から順に
LLMを使った判定は精度が高い一方、呼び出しのたびにコストがかかります。すべてのリクエストに高価な判定をかけるのではなく、安く速い判定から順に通す段階構成にすると、コストとレイテンシを両方抑えられます。
- 第1段：ルールベース（正規表現、許可リスト）——明らかなものを即判定
- 第2段：軽量な分類器——大半のリクエストはここで判定を終える
- 第3段：LLMによる判定——判断が難しいものだけを回す
このとき、各段で「どれだけのリクエストが次の段に回ったか」を監視します。第3段に回る割合が急に増えたら、業務か攻撃のどちらかに変化が起きているサインです。
運用サイクル——いつ、何を見るか
4つの規律を、定常業務のサイクルに落とし込みます。
| 頻度 | やること | 主な担当 |
|---|---|---|
| 常時 | ブロック率・レイテンシ（p95/p99）・fail-open発動・判定コストのアラート監視 | 運用（NOC的な一次監視） |
| 日次〜週次 | ブロックログのサンプリングレビュー（誤検知の推定）、異議申し立ての処理 | ガードレールのオーナー |
| 週次〜隔週 | 評価セット・ゴールデンセットの実行（見逃し率・誤検知率の回帰確認） | セキュリティ／評価担当 |
| 月次 | 例外の棚卸し（期限切れ・未使用・広すぎる許可）、緊急変更の事後処理 | オーナー＋承認者 |
| 四半期 | ルール全体の監査（シャドールール・重複・矛盾）、閾値方針とfail-open/closed方針の見直し | セキュリティ責任者 |
| イベント時 | モデル更新・ツール追加・業務変更のたびに回帰テストとシャドー評価 | 変更の起案者 |
よくある落とし穴
- ブロック件数を「成果」として報告する：ブロック件数が多いのは、攻撃が多いからか、誤検知が多いからか分かりません。誤検知率・見逃し率とセットでなければ意味を持ちません
- 例外を管理画面で直接足す：版管理の外で足された例外は、棚卸しの対象から漏れます
- 評価セットを更新しない：古い攻撃パターンだけで測った見逃し率は、実態より良く見えます
- ガードレール用モデルのバージョンを固定していない：プロバイダ側の更新で、ある日突然判定が変わります
- fail-open/closedがデフォルト任せ：障害時に初めて方針を知ることになります
- 旧ルールを残したまま新ルールを足す：入れ替えのはずが、重複とシャドールールを増やすだけになります
GuardrailOps チェックリスト
| 領域 | チェック項目 |
|---|---|
| 棚卸し | すべてのガードレールが一覧化され、配置場所とオーナーが明記されている |
| ルールごとのヒット数（いつ・何回効いたか）がログに残っている | |
| トレードオフ監視 | 誤検知率と見逃し率をセットで報告している |
| 利用者が誤検知を申告できる仕組みがある | |
| リスクの高さに応じて閾値を使い分け、その方針が文書化されている | |
| 例外管理 | 例外に申請者・承認者・理由・範囲・有効期限が必須になっている |
| 期限切れの例外が自動で無効化される | |
| 月次で未使用・広すぎる例外を棚卸ししている | |
| 版管理と評価 | ルール・閾値・判定プロンプト・判定モデルのバージョンが版管理されている |
| 新ルールはシャドーモードで判定差分を確認してから適用している | |
| 入れ替え後に旧ルールを確実に削除している | |
| レイテンシとコスト | ガードレールのp95/p99レイテンシを監視している |
| 操作のリスクごとにfail-open/fail-closedの方針が決まっており、発動が記録される | |
| 安い判定から順に通す段階構成になっており、段ごとの通過率を監視している |
よくある質問（Q&A）
Q1. 小さなチームでも、ここまでの運用が必要ですか？
すべてを一度に揃える必要はありません。最初の一歩としては、①例外に有効期限をつける、②ルールごとのヒット数をログに残す、③fail-open/closedの方針を決めるの3つをおすすめします。どれも小さな手間で始められ、後から棚卸しや評価を始めるときの土台になります。
Q2. 誤検知率と見逃し率、どちらを優先すべきですか？
エージェントが行う操作のリスクで決まります。取り消しのきかない操作（送金、外部送信、削除など）では見逃しを優先して減らし、誤検知は人の承認フローで吸収します。読み取り中心の低リスクな用途では、誤検知を減らして業務を止めないことを優先します。重要なのは、どちらを優先したかを明文化して合意しておくことです。
Q3. 例外の申請が多すぎて、棚卸しが追いつきません。
例外が多いこと自体が、ルール側の問題を示しています。同じ種類の例外が繰り返し申請されているなら、それはルールの誤検知を例外で埋めている状態です。個別の例外を足すのではなく、ルールそのものを見直してシャドー評価にかける方が、長期的には件数が減ります。
Q4. 市販のガードレール製品を使えば、運用は不要になりますか？
製品は検知エンジンやルールの一部を提供してくれますが、自社の業務に合わせた閾値・例外・fail-open/closed方針は、自社で運用するしかありません。製品側のルール更新も、自社にとっては「ある日判定が変わる」変更です。製品のバージョンも版管理の対象に含め、更新時には回帰テストを流してください。
Q5. AIDRなどの実行時検知とは、どう役割分担すればよいですか？
AIDRは「いま起きていることを検知して対応する」仕組みで、GuardrailOpsは「その検知・防御のルール自体を健全に保つ」運用です。AIDRで見つかった見逃しは評価セットへ、AIDRで多発する誤アラートはルールの見直しへ——というように、AIDRの結果をGuardrailOpsの入力にする関係をつくると、両方が強くなります。
まとめ——守りも、運用されて初めて守りになる
ガードレールは、導入した日がいちばんきれいで、そこから劣化していきます。誤検知のたびに例外が足され、環境の変化でルールが古くなり、気づけば「業務を止める守り」か「形だけの守り」——あるいはその両方——になっています。
それを防ぐのは、特別な技術ではなく、ネットワーク運用が何十年もかけて身につけてきた地道な規律です。
- 測る：誤検知率と見逃し率を、必ずセットで監視する
- 棚卸しする：例外を負債として扱い、期限切れ・未使用・隠れルールを定期的に洗い出す
- 安全に変える：ルールを版管理し、シャドー評価で判定差分を確かめてから入れ替える
- 守り自体を守る：レイテンシ・コスト・fail-open/closedを、エージェント本体と同じ水準で監視する
指示資産、参照資産、能力資産、モデル、そして防御資産。エージェントを構成するすべての資産が「運用対象」になったとき、AgentOpsはようやく一周します。ガードレールを「入れたかどうか」ではなく、「効いているかどうか」で語れる組織を目指しましょう。
コメント