AIブルーチーミング解説：管理策が実際に存在できる3つの層

セキュリティチームにAIガードレールがどこにあるか尋ねると、答えはたいていポリシー文書、システムプロンプト、ベンダー機能のいずれかを挙げる。だが、そのどれも統制ではない。統制とは、行為の瞬間にその行為を実行するかどうかを決めるものであり、AIエージェントの場合、決められる場所は3つしかない。モデル、その前段のゲートウェイ、そしてそれを取り巻く環境だ。ブルーチームが正直に約束できることはすべて、そのうち2番目と3番目から来る。これはレイヤーの問題であり、何をログに取るか、誰を呼ぶかを含む、他のあらゆるブルーチームの判断に先立つ。現場の証拠が重要な理由もここにある。AIインシデントアーカイブには、2024年12月から2026年10月17日までのエージェントインシデント400件が収録されており、その大半は、モデルが不適切に振る舞った話ではない。それらは、ノーと言えるレイヤーを持たないデプロイの話だ。

AIにおけるブルーチーミングとは、そうした防御層を組み込み、各層が何を検知するかを調整し、どれかが発火した日に備えて訓練済みの対応を用意しておく作業だ。地味で、スコアを生み出しもしないが、レッドチーム／ブルーチームのペアのうち、リスク数値を変えるのはこの半分だけである。

ブルーチームが受け継ぐもの、受け継がないもの

従来のブルーチーミングは、AIの導入によって静かに覆される一連の前提に依存している。ログは完全だと想定されていた。ネットワークがすべてのパケットを目にしていたからだ。資産は列挙可能だと想定されていた。誰かがそれらをプロビジョニングしなければならなかったからだ。振る舞いは決定論的だと想定されていた。プログラムは同じ入力が与えられれば同じ動作をするからだ。この三つのうち、エージェントとの接触に耐えるものは一つもない。

ブルーチームが代わりに引き継ぐのは、最も重大な意思決定が、ネットワーク層からは単一のホスト名への通常のHTTPSトラフィックとして扱われるリクエストの内部で行われるシステムである。プロンプト、取得されたコンテキスト、ツール呼び出し、補完結果——そのすべてがリクエストボディの内側にあり、誰もそのボディをキャプチャして解析していなければ、境界防御がどれほど優れていても、そのデプロイは機能的には監視されていない。したがってブルーチームの最初の任務は検出ではなく、センサーを確立することである。リクエストレベルおよびツールレベルの可視性がなければ、検出する対象は何もなく、下流のあらゆる制御は飾りにすぎない。

実際にその統制を執行できるのは誰か

センサーが一度存在すれば、問題は各コントロールをどこに置くことが許されるかになる。これを図示するのに有用な方法は、技術ではなく所有権によるものだ。なぜなら、コントロールが次のリリースを生き残れるかどうかを決めるのは所有権だからだ。

モデル層は、それを訓練した者のものです。あなたが設定するものでも、内部を見るものでもなく、ベンダーが新しいバージョンを出荷すればその振る舞いは変わります——それがいつになるかは、どの火曜日でもおかしくありません。あなたにできるのはバージョンを固定することと、バージョン変更を、再テストを要するリスク態勢の変更として扱うことです。ここで制御を主張することはできません。「モデルは有害な要求を拒否する」は、あなたが依存している特性であり、あなたが運用する仕組みではありません。

ゲートウェイ層は、すべてのプロンプトと補完が自社所有のコンポーネントを通る場所です。ここに予算とレート制限があり、許可リストとツール権限が適用され、リクエストとレスポンスのログ記録が構造上完全になり、トークンが課金される前にリクエストを書き換えたり、ブロックしたり、経路変更したりできます。ゲートウェイの制御は、モデルを変更しても付随し続ける唯一の制御でもあり、これは聞こえる以上に重要です。制御をプロンプトに置くチームは、移行する日にそれらを完全に失うからです。

環境レイヤーは、完全にあなたの支配下にある唯一の部分です。認証情報とそのスコープ、ネットワークの外向き通信、ファイルアクセス、実時間と支出に対するサンドボックスの制限。そして、侵害された実行が実際に被害を及ぼすのもここです。悪意ある行動をするよう仕向けられたエージェントの危険度は、環境がその行動にどこまで到達することを許したかに正確に比例します。そして環境こそ、「最小権限」が研究課題ではなく設定変更で済む唯一の場所なのです。

提案されたあらゆるAI制御に対する実用的なテストは、1つの問いに尽きます：この3つの層のうち、どれがそれを強制するのか？ 答えがモデル層なら、その制御は希望にすぎません。答えが「システムプロンプト」なら、それはモデル層の内部にある提案であり、そうではないと主張する文書を伴う分、希望より悪いものです。

検出: エージェントが実際に出力する内容

エージェント向けの検出は、人向けの検出とは異なるシグナルセットで動作する。相関させるべきログイン異常は存在しない。代わりにあるのは、異常に豊かな構造を持つリクエストストリームであり、アラートを出す価値のある4つのシグナルファミリーである。

• ツール呼び出しの量と形状。あるタスク内で突然ファイル読み取りツールを40回呼び出したり、ツールの呼び出し順序が3ステップから30ステップに変わったりするエージェントは、注目に値します。悪意があるからではなく、分布が変化したからです。

• 境界におけるコンテンツの来歴。プロンプト内のテキストのうち、どれがユーザー由来で、どれが検索由来で、どれがツール結果由来で、どれがメモリ由来なのか。プロンプトインジェクション検出のほとんどは「データのみを運ぶべきチャネルに指示文が現れた」に帰着するが、ゲートウェイが入力時に来歴をラベル付けしない限り、それを計算することはできない。

• 外向き通信とスコープ境界のエッジ。許可リスト外の宛先へのリクエスト、スコープ外のパスの読み取り、想定されたサービス外での認証情報の使用試行。これらは精度の高いシグナルであり、環境がすでに何が許可されていたかを把握しているため、低コストでもあります。

• 代理指標としての支出とレイテンシ。暴走ループも侵害も、どちらもコスト曲線の傾きが変化する形で現れる。予算アラートはスタック内で最も地味な検知手法であり、最も早くコストを回収できるものの一つでもある。

そのリストから意図的に外しているのは、ある補完（completion）が有害かどうかを判定するよう求められた分類器だ。それはチームが真っ先に手を伸ばす検知のアイデアであり、最も早く陳腐化するものでもある。モデルとともにドリフトし、誤検知率のせいでアナリストがそれを無視するよう訓練されてしまい、ランブックに書けるものを何も与えてくれない。

Contain：まずい実行を止める3つのつまみ

エージェントの封じ込めは見た目より単純です。なぜなら、ほぼすべてをカバーする3つの調整項目があるからです。 予算は1回の実行で使える金額の上限を定め、金銭的損害とループの影響範囲の両方を制限します。 スコープは1回の実行が触れられる対象、つまりそのタスクで有効なツール、パス、テナントの上限を定めます。 サンドボックスは実行できる時間と、実行中に到達できる範囲の上限を定めます。これら3つはすべてゲートウェイまたは環境の設定であり、言い換えれば強制適用可能です。

重要な設計原則は、エージェント単位のスコープではなくタスク単位のスコープだ。常設の権限セットを持つエージェントは、誰かが監査するまで権限が積み上がり続けるエージェントである。一方、タスクの期間だけタスクスコープの資格情報を受け取るエージェントは、自ら失効する境界を持つ。後者は構築に手間がかかるが、防御のコストはずっと低い。

ゲートウェイがその名にふさわしいものになるのも、まさにここだ。あらゆるモデル呼び出しの手前に存在するコントロール——ツールやMCPの呼び出しは実行前に評価され、コンテンツポリシーと個人データのマスキングはリクエストが課金される前に適用される——は、その背後にあるモデルが前四半期に使っていたものだろうと先週出荷されたものだろうと、同じコントロールである。その継続性こそが実際の製品だ。より優れたフィルターではなく、モデルが変わっても動かない、フィルターが存在する場所なのだ。

復旧: リプレイ、パッチ、再テスト

AIインシデントの復旧には、ネットワークインシデントの復旧に対する利点が一つあります。それは、実行の全体が通常記録されていることです。プロンプト、コンテキスト、ツール呼び出し、補完、タイミング——ゲートウェイがそれらを記録していれば、そのインシデントはリプレイでき、これはほとんどのフォレンジックが得られる出発点よりも強力なものです。

リプレイには順に三つの目的がある。実際に何が起きたのかを、複数人が要約した後に記録が示唆する内容ではなく、確定すること。発動すべきだった制御を特定すること。これは症状を直すことと境界を直すことの違いだ。そして回帰ケースを生み出すこと。今はブロックされるべき記録済みの入力であり、新しい設定に対して実行して、実際にブロックされることを証明する。

パッチ適用の段階は、ブルーチームが最もよく狙いを誤るところです。検出事項がモデルの挙動だった場合、利用可能な緩和策はすべてモデルの外側にあります — スコープの縮小、ゲートウェイでのフィルター、環境から権限を削除することです。検出事項がシステムの挙動だった場合、修正は設定側にあり、回帰テストは低コストです。いずれにせよ、再テストは任意ではありません。修正もモデルのバージョンも動くためであり、先月のビルドに対して検証されたコントロールは、先月についての主張にすぎません。

それが発火する日をリハーサルする

プレッシャーの中で一度も読まれたことのないランブックは、能力ではなく文書にすぎない。元が取れるリハーサルは、狭く具体的だ。あり得るエージェント事故を一つ選び、端から端まで追跡し、各ステップにかかる時間を計る。誰が気づくのか。人間が正しいログ行を見るまでにどれだけかかるのか。誰が実行を止められるのか――名前を挙げた一人か、それとも委員会か。誰が認証情報を取り消せるのか、そして取り消しが反映されるまでどれだけかかるのか。社外の誰かに通知するかどうかを誰が決めるのか。

このうち2つの質問は、チームを確実に引っかける。「誰が実行を止められるか」は、停止に寝ている誰かの対応が必要になると失敗するので、答えは人ではなく仕組みである必要がある — 当直エンジニアが単独で引ける予算上限やキルスイッチのようなものだ。「失効にはどれくらいかかるか」は、資格情報が図に含まれていないコンポーネントにキャッシュされていることが多いため失敗する。

アーカイブを読むことは、利用できる最も安価なリハーサル形態です。なぜなら、自分でゼロから考案するのではなく、他者のインシデント構造を引き継げるからです。あなたのデプロイに似たエントリをいくつか取り上げ、それぞれについて上記の3つの質問をしてください。それらに答えられないエントリは、あなたのランブックのギャップであり、インシデントの後ではなく前に見つけたものです。

明確に述べる価値のある非対称性

レッドチーミングとブルーチーミングは対称的な活動ではなく、同じように予算配分すべきではない。レッドチームの実行はスケジュールによって区切られ、対象が変化するにつれて価値が薄れていく一連の所見を生み出す。ブルーチームの管理策は持続し、複利的に積み上がり、悪質な入力と有害な結果の間に実際に立ちはだかる唯一のものである。一方の取り組みは境界を見つけられるが、その境界を保持できるのはもう一方だけである。

そのため、ブルーチームの誠実な基準は地味で検証可能なものになる。主張する統制ごとに、それを強制するレイヤー、発動したことを証明するログ行、発動しなかったときに知らせるアラート、そしてその実行を停止できる担当者を挙げられるべきだ。四つの文だ。そのうち一つでも欠けていれば、その統制はポリシー文書であり、ポリシー文書はリクエストボディを読まない。