こんにちは、株式会社 ChillStack リサーチ＆ソリューション部です。
今回は、安全な AI エージェント利活用のためのフレームワークを提唱した「Agent-Native Immune System: Architecture, Taxonomy, and Engineering」というペーパーについて紹介します。
※紹介するペーパーは概念提唱のみ行なっており、実験や評価を実施しているものではありませんのでご了承ください。
AI エージェントの活用における課題
昨今AI利活用は静的なチャットボットから、自律的に推論し、外部ツールを呼び出し、記憶を保持し、複数エージェントで協調する形へ移行してきています。これにより、AI が扱える業務の幅は大きく広がりましたが、同時にサイバーリスクの脅威も根本的に拡大してきています。
しかし、既存の防御メカニズム（境界防御や、学習時に AI の価値観・行動方針を調整する対策など）は、エージェントの能動的な推論ループの「外部」に留まっています。たとえば、入力を事前にフィルタリングする、API ゲートウェイで制御する、学習時に「何を優先し、何を避けるべきか」を教える、といった対策は重要ですが、エージェントが実行時に何を記憶し、どのツールを選び、他のエージェントとどうやり取りするかまでは十分に見えていません。
その結果、学習時に価値観や行動方針を調整された AI であっても、実行時にメモリポイズニング（記憶の汚染）、ツール連携の操作、あるいはマルチエージェントのプロトコル攻撃（エージェント同士のやり取りのルールを悪用する攻撃）などを受ける可能性が残されているという課題があります。
防御システム「Agent-Native Immune System」の提案
上記の課題を解決するため、本ペーパーではエージェントの認知ループ（入力を読み、考え、ツールを使い、その結果を次の判断に反映する一連の流れ）に直接組み込まれる生体模倣型・内因性防御アーキテクチャ「Agent-Native Immune System（ANIS：エージェント内因型免疫システム、以降 ANIS）」を提案しています。
学習時に AI の価値観や行動方針を調整することは、「この AI は何を優先し、何を避けるべきか」という基本ルールをあらかじめ教える対策です。一方で ANIS は、実行中に不審なメモリ参照やツール呼び出しが起きたとき、その場で確認・隔離・遮断する仕組みとして設計されています。
ここで重要なのは、ANIS は既存の価値観・行動方針の調整や境界防御を否定するものではないという点です。むしろ、価値観・行動方針の調整が「AI は何を大切にすべきか」を定義し、境界防御が「外から入ってくる既知の危険」を減らす一方で、ANIS は「実行中のエージェントが自身の状態を守り続ける」ための仕組みとして位置づけられています。
ANIS の紹介
ANIS の全体像
ANIS は、生物の免疫システムを AI エージェントの実行環境に対応づけたアーキテクチャです。生物が外部からの病原体を検知し、自己と非自己を区別し、抗体を作り、免疫記憶を残すように、AI エージェントにも実行時の防御機構を持たせようとする考え方です。
本ペーパーでは、ANIS の目的として以下の 4つが示されています。
- Secure（安全）: 外部からの攻撃や不正な操作からエージェントを守る
- Healthy（健全）: エージェントの目標、記憶、推論の一貫性を保つ
- Orderly（秩序）: 複数エージェント間のやり取りを安全に保つ
- Evolving（進化）: 新しい脅威に応じて防御機構を継続的に更新する
従来のセキュリティは「攻撃を外側で止める」発想が中心でした。ANIS では、エージェント自身の認知ループ、ツール利用、メモリ、協調プロトコルの内部に防御機能を持たせることで、実行時に発生する攻撃や異常に対応しようとしています。
6層構造の Immune Tower
ANIS の中心となるのが、6層構造の「Immune Tower」です。これは、エージェントを守る機能を下位の信頼基盤から上位の集合的な免疫まで段階的に整理したものです。
| レイヤー | 名称 | 役割 | 具体例 |
|---|---|---|---|
| L0 | Hardware Trust Root | エージェントやワクチンの真正性を確認する基盤 | TPM、TEE、セキュアブート、構成証明（実行環境が正しいことの確認） |
| L1 | Barrier Immunity | 推論に入る前に危険な入力や操作を隔離する | 入力サニタイズ、サンドボックス、API ゲートウェイ、MCP 境界プロキシ |
| L2 | Innate Cognitive Defense | 既知の異常や危険な推論パターンを素早く検知する | ルールエンジン、既知パターン検知、推論トレース監査、決定論的検証器 |
| L3 | Adaptive Tool Defense | 新しい脅威に応じて防御策を生成・適用する | 動的な防御策の生成、LoRA アダプタ、ツール選択・推論の補正 |
| L4 | Ecological Governance | 複数エージェント間の信頼関係やプロトコルを監査する | プロトコル監査、信頼チェーン検証、行動の来歴管理 |
| L5 | Collective Immunity | エージェント群全体で脅威情報や防御策を共有する | ワクチン同期、複数エージェントで共有する脅威情報、免疫ネットワーク |
この 6 層は単なる分類ではなく、防御機能の流れを示すアーキテクチャとして説明されています。
たとえば、悪意ある MCP ツールの説明文が AI エージェントのコンテキストに入り込もうとするケースを考えます。
- L1 では、ツールの提供元や説明文の検証、サンドボックス化によって危険な入力を推論前に止めます。
- L1 をすり抜けた場合、L2 では推論トレースやルールベースの検証によって、ツール選択が不自然に誘導されていないかを確認します。
- L3 では、同様の攻撃に対するワクチンを生成し、ツール選択の挙動を補正します。
- 複数エージェントで構成されるシステムでは、L4 がエージェント間のメッセージや信頼チェーンを監査します。
- L5 が検出された脅威や有効な防御策を他のエージェントにも共有します。
これにより、単体のエージェントだけではなく、エージェント群全体として防御力を高めることを狙っています。
Agent Viruses（攻撃）と Agent Vaccines（防御）
本ペーパーでは、AI エージェントに対する攻撃を「Agent Viruses」、それに対する防御策を「Agent Vaccines」として整理しています。
Agent Viruses は、攻撃対象となる面によって大きく以下の 4 つに分類されます。
- Cognitive（認知）: 目標の乗っ取りや推論の誘導を狙う攻撃
- Memory（記憶）: 長期記憶や RAG の参照情報を汚染する攻撃
- Tool（ツール）: ツール説明文、ツール選択、MCP 連携などを悪用する攻撃
- Multi-Agent（マルチエージェント）: エージェント間のプロトコル、ID、信頼チェーンを悪用する攻撃
近年の AI エージェントに対する攻撃は、単にユーザー入力に悪意ある指示を混ぜるだけではありません。記憶に攻撃用の情報を長期的に残したり、ツールの説明文を通じてモデルの判断を誘導したり、複数エージェントの相互作用を利用して誤った信念を広げたりします。そのため、入力フィルタだけでなく、記憶・ツール・プロトコルまで含めた防御が必要になります。
これに対して Agent Vaccines は、攻撃パターンに対してエージェントが取る防御策です。
ペーパーでは、Agent Vaccines の応答として
- pass: 通過
- block: 遮断
- quarantine: 隔離
- alert: 通知
といった動作が想定されています。
また、Agent Vaccines は大きく 2 種類に分けられます。
| 種類 | 概要 | 例 | 特徴 |
|---|---|---|---|
| Non-parametric Vaccine（ルール型の防御） | モデルの重みを変更せず、外側のルールや制約で防御する | プロンプトテンプレート、アクセス制御、ツール許可リスト、サンドボックスポリシー | 解釈しやすく戻しやすい一方で、コンテキスト操作や複雑な攻撃に弱い場合がある |
| Parametric Vaccine（モデル調整型の防御） | モデル内部の表現や軽量な追加重みを使って防御する | ステアリングベクトル、LoRA アダプタ、防御用埋め込み | プロンプトレベルの回避に強くなり得る一方で、検証や運用の難易度が上がる |
ここで出てくるステアリングベクトルは、モデルの出力傾向を特定の方向に少し寄せるための調整値、LoRA アダプタは大きなモデル全体を作り替えずに追加で読み込む小さな調整パーツ、と考えるとイメージしやすいです。
ここでのポイントは、「ルールを追加して終わり」ではなく、エージェントが攻撃にさらされた経験をもとに、防御策を改善していくという考え方です。特に Parametric Vaccine は、モデルの内部表現に対する軽量な介入によって、危険な推論経路やツール選択を抑制する防御として位置づけられています。
Harness Triad と継続的な免疫学習
ANIS のもう一つの重要な要素が「Harness Triad」です。ここでいう Harness は、モデルそのものではなく、モデルの周囲にあるプロンプト、ツール、メモリ、検証器、実行ポリシー、オーケストレーションなどを含む実行基盤を指します。
本ペーパーでは、Harness Triad として以下の 3 つが示されています。
- Self-harness: 実行ログ、推論トレース、メモリアクセス、ツール呼び出しを監査し、異常や弱点を見つける
- Meta-harness: 候補となる防御策を評価し、防御効果と誤検知のリスクを測る
- Auto-harness: 承認された防御策を実行基盤に反映し、検証ルールやポリシーを更新する
この 3 つは下記の閉じたループにて動作します。
- Self-harness が異常なツール呼び出しや不自然な推論パターンを検知する
- 検知された失敗パターンをもとに、防御策の候補を生成する
- Meta-harness が候補を評価し、攻撃を防げるか、正常な動作まで止めてしまわないかを確認する
- Auto-harness が承認された防御策をデプロイする
- デプロイ後の効果を Self-harness が再度監査し、次の改善につなげる
この流れは「Continual Immune Learning（CIL：継続的な免疫学習）」として説明されています。AI エージェントが攻撃を受けた後に単にログを残すだけではなく、その経験をもとに防御機構を更新していく点が特徴です。
Thymus Simulator と自己免疫リスク
免疫システムをエージェントに組み込む場合、強すぎる防御が正常な動作まで止めてしまうリスクがあります。生物の免疫にたとえると、自己を攻撃してしまう「自己免疫」のような問題です。
ANIS では、このリスクを抑えるために「Thymus Simulator」という評価環境を導入しています。Thymus は生物の胸腺を指し、ここでは「新しい防御策を本番に入れる前に試す検査場」のような役割です。候補となるワクチンを、攻撃パターンだけでなく、正常なエージェント動作の集合にも適用し、正常な動作を誤ってブロックしないかを検証します。
たとえば、あるワクチンがメモリポイズニングを高い確率で防げたとしても、通常のメモリ参照まで大量に遮断してしまう場合、業務利用では使いにくい防御策になります。そのため、防御効果だけでなく、誤検知や通常機能への影響も評価する必要があります。
ANIS の評価観点と限界
本ペーパーでは ANIS のアーキテクチャと分類体系が中心に説明されており、大規模な実験によって ANIS 全体の有効性が実証されているわけではありません。
そのため、「ANIS はすでに効果が検証済みの完成された仕組み」というより、今後の AI エージェントセキュリティを考えるための設計フレームワークとしてまずは捉えるのが良いかと思います。
一方で、ANIS を評価するための指標として、以下のような考え方が示されています。
| 指標 | 概要 | 見ているもの |
|---|---|---|
| Cognitive Consistency Score（CCS） | 推論トレースが宣言された目標と論理的に一貫しているか | 認知的な健全性 |
| Behavioral Legitimacy Index（BLI） | ツール呼び出しが認可された操作の範囲に収まっているか | 行動の正当性 |
| Ecological Order Coefficient（EOC） | エージェント群全体の健全性が安定しているか | 集合的な秩序 |
| Autoimmunity Rate（AIR） | 防御策が正常な動作を誤って止める割合 | 誤検知や過剰防御のリスク |
特に AIR は、ANIS を実務に近づけるうえで重要な指標です。セキュリティ対策は攻撃を止めるだけでなく、通常業務を止めすぎないことも求められます。AI エージェントが外部ツールを使って業務を進める場面では、過剰な遮断がそのまま業務停止につながるため、防御効果と利便性のバランスを測る必要があります。
本ペーパーでは、今後の課題として以下の点も挙げられています。
- Parametric Vaccine や Harness Triad を現実的な攻撃条件で評価する実証が必要
- Self-harness や Meta-harness による継続監視には計算コストや遅延が伴う
- 防御感度を上げるほど、正常な動作まで止める自己免疫リスクが高まる
- 現時点では主にテキストベースのエージェントを対象としており、マルチモーダルな防御は今後の課題
- ワクチン形式、監査ログ、免疫プロトコルの標準化がまだ十分ではない
このように、ANIS は非常に興味深い構想である一方、実運用にそのまま導入できる完成済みの製品や標準ではありません。
今後、評価指標やプロトコル、実装パターンが整備されていくことで、より実務に近い形で活用できる可能性があります。
AI エージェントの安全性に関する考察（論文外）
AI エージェントの安全性を考えるうえで、今後は「モデル単体を安全にする」だけでは不十分になっていくと考えられます。エージェントは、モデル、メモリ、外部ツール、権限、実行環境、他エージェントとの通信を含むシステムとして動作するためです。
ANIS が示している重要な視点は、AI エージェントを単なる API 利用者ではなく、継続的に状態を持ち、環境と相互作用し、自身の挙動を変化させる存在として扱う点です。そのようなエージェントには、外側からの入力制御だけでなく、内側で状態を監査し、異常を検知し、防御策を更新する仕組みが必要になります。
実務で AI エージェントを導入する際は、まず以下のような観点を確認することが重要です。
- ツールと権限を最小化する: エージェントに不要なファイル操作、外部送信、課金処理、管理操作の権限を与えない
- メモリとツールの来歴を確認する: 長期記憶、RAG の参照データ、MCP ツールの説明文や提供元を検証する
- 実行時の監査ログを残す: 推論トレース、ツール呼び出し、メモリ参照、エージェント間メッセージを後から追えるようにする
- 防御策の誤検知を測る: 攻撃を止めるだけでなく、通常業務を止めすぎていないかを確認する
- 複数エージェント間の信頼を検証する: エージェント ID、メッセージ署名、共有される防御情報の真正性を確認する
ANIS は、こうした観点を「免疫」という一つの枠組みで整理している点に価値があります。境界防御、価値観・行動方針の調整、実行時の監視、ツール制御、メモリ保護、マルチエージェントの信頼管理を別々に考えるのではなく、エージェントの健康状態を維持するための層構造として捉え直しています。
まとめ
今回は、「Agent-Native Immune System: Architecture, Taxonomy, and Engineering」というペーパーをもとに、AI エージェントのための内因性防御アーキテクチャである ANIS を紹介しました。
ANIS は現時点では概念的な提案の側面が強く、実運用に向けた検証や標準化には課題もあります。
ですが、AI エージェントや MCP を活用するシステムが増えていく中で、ANIS が提示する「実行時に自己を守るエージェント」という視点は、今後の AI セキュリティを考えるうえで重要なものになる可能性があります。
最後に
本記事の内容が、AI エージェントや MCP を安全に運用するための設計観点を整理する参考になれば幸いです。
ChillStack では、AI セキュリティ分野に興味がある方、または経験のある方を募集しています。この記事を読んで関心を持っていただけた方や、さらに詳しく知りたい方は、ぜひカジュアル面談でお話ししましょう。
会社概要
採用ページ
公式 Note
Discussion