AIエージェント用ネットワークセグメント設計入門
AIエージェントを業務導入するとき、「どのネットワークに置くか」は後回しにされがちな論点です。しかし実は、置き場所の設計がそのまま守りの強さを決めます。この記事では、AIエージェント用のネットワークセグメント設計を、基本から順に解説します。
セグメント分離の基本 — 用途別に分ける
ネットワークセグメントとは、社内ネットワークを用途や信頼レベルごとに区切った単位です。サーバ用・社員PC用・ゲストWi-Fi用を分ける、といった運用は多くの企業ですでに行われています。
分ける理由はシンプルで、区切りごとに異なるポリシーを適用でき、問題が起きたときの影響範囲を区切りの中に閉じ込められるからです。ゲストWi-Fiから社内サーバに触れない、というのはこの典型です。
AIエージェントの導入は、ここに新しい区分をひとつ増やす話だと捉えられます。「エージェント専用セグメント」です。
なぜエージェントは専有セグメントと相性がよいのか
人間が使うネットワークに強い制限をかけると業務が止まりますが、エージェントには人間と決定的に違う性質があります。健全なエージェントの接続先は、少なく、安定していることです。
普段つなぐのは、利用しているLLMの接続先と、コードリポジトリやパッケージ取得先など決まったいくつかのツールだけ。接続先が安定しているからこそ、
- 許可リストが現実的な長さで書ける
- リストにない宛先への接続、つまり逸脱そのものが異常のシグナルになる
という守り方が成立します(詳しくは AIエージェントの egress 制御入門)。そしてこの守り方は、エージェントだけを専有セグメントに集めたときに最も素直に機能します。人間の多様な通信が混ざらないため、ポリシーを純粋に「エージェント基準」で書けるからです。
専有セグメントで可能になる強い制御 — deny-base
エージェント専有のセグメントなら、egress を deny-base(デフォルト拒否)にできます。基本はすべて遮断し、許可した宛先だけを通す構えです。
| 適用先 | 現実的な構え | 理由 |
|---|---|---|
| 人間が使うセグメント | allow-base(基本は通し、危険な宛先だけ遮断) | 閲覧先が多様で許可リスト化が非現実的 |
| エージェント専有セグメント | deny-base(基本は遮断し、許可宛先だけ通す) | 接続先が少なく安定し、許可リストが書ける |
deny-base のセグメントでは、プロンプトインジェクションなどでエージェントの意図が乗っ取られても、許可リストにない宛先へはネットワークが到達させません。情報の持ち出し先や攻撃者のサーバが、たまたま許可リストに載っている可能性は低いため、被害範囲(blast radius)を強く限定できます。
人間と同居する場合の現実解
「専用セグメントを切る余裕がない」「開発者のPC上でエージェントを動かしている」という環境も現実には多いはずです。その場合に deny-base を適用すると、人間の業務閲覧まで止まってしまいます。
現実解は、強度を一段落とした制御です。
- LLM接続先の固定 — 通常の閲覧は止めず、既知のLLMサービス宛ての通信のうち「公認した接続先以外」だけを遮断する。エージェントが不正なAIサービスへ誘導される事態を絞れます
- 持ち出しに使われやすい宛先の明示遮断 — トンネルサービスや匿名アップロードサービスなど、用途が侵害時に偏る宛先を拒否リストに載せる
- 観測と記録 — 遮断しないまでも、接続先を記録に残し「初めて見る宛先」を要調査として拾う
同居環境はあくまで妥協であり、エージェントの活用が本格化する段階で専有セグメントへの移行を計画に入れることをおすすめします。なお、セグメントの境界に制御を足す際、既存のIP設計を変えずに挿入できる方式もあります(透過型ファイアウォール入門)。
セグメントだけでは十分ではない
正直に書くと、セグメント分離は万能ではありません。
- 許可した正規宛先の悪用は捕捉できません。公認サービスへ秘密を送る、といった行為はセグメントの内外を問わず通ってしまいます
- セグメントは通信の経路を絞るだけで、認証・権限の不備を肩代わりしません。エージェントに与えるAPIキーやアクセス権の最小化は別途必要です
- 遮断して終わりではなく、ログを残して見る運用があって初めて「逸脱=シグナル」が活きます
- ホスト側の対策(サンドボックス・実行制限・人間の確認)との多層防御が前提です
また、deny-base への切り替えは一気に行わず、まず観測して接続先を把握し、「もし強制したら何が止まるか」を確認してから強制する段階導入が定石です。
まとめ
- セグメント分離の本質は「区切りごとに異なるポリシー」と「影響範囲の閉じ込め」
- エージェントは接続先が少なく安定 → 専有セグメント+deny-base が素直に機能する
- 人間と同居する場合は、LLM接続先の固定・危険宛先の明示遮断・観測記録が現実解
- セグメントは強力だが単独では不十分。認証・権限・ログ・ホスト側対策と併用する
Tate(盾)は、エージェントセグメントの境界に挟むだけで deny-base の egress 制御を実現するために設計されたアプライアンスです。仕組みは AIガードレールをご覧ください。
AIエージェントの外向き通信、見えていますか。
Tate(盾)は、回線に挟むだけで導入できる L2透過型ファイアウォール・アプライアンスです。現在、先行案内・お問い合わせを受け付けています。