AIに遮断を任せてよいか — 防御操作の「危険度」を5つの軸で測る
検知ツールやAIエージェントが「この端末の外向き通信を止めますか」と提案してくる場面が増えています。止めれば被害の広がりを抑えられるかもしれません。しかし、その通信が実は受発注システムの定期連携だったら、止めた瞬間に業務が止まります。経営から見れば、攻撃で止まったのか防御で止まったのかは、ほとんど区別がつきません。
AIに防御の操作をどこまで任せてよいか。英国のNCSC（National Cyber Security Centre、国家サイバーセキュリティセンター）でアーキテクチャ担当CTOを務めるDave Chismon氏が、2026年9月21日のブログでこの問いを整理しました。本記事はその内容を紹介し、出口（egress）制御の運用に当てはめて考えます。
防御操作の危険度とは何か？
防御操作の危険度とは、遮断や設定変更といった防御側の操作が、誤ったときに組織へどれだけの害を与えうるかを見積もった度合いです。NCSCのブログは、これを操作の強さ、影響の範囲、対象の重要度、実行前にどこまで確かめられるか、どれだけ戻しやすいか、という5つの軸で評価する枠組みを提案しています。各軸を0〜4の段階で見て、低い操作から自動化していくという考え方です。「防御操作の危険度」は、この枠組みを指すために本記事で使う呼び方で、NCSCが定めた公式の用語や基準ではありません。
なぜ防御側は、攻撃側と同じようにAIを使えないのか？
ブログは、Halvar Flake氏の格言「攻撃の問題はすべて技術の問題であり、防御の問題はすべて政治の問題である」から話を始めます。攻撃者の悩みは「この脆弱性を突く手段はあるか」「どう検知を避けるか」といった技術的なものです。成功したかどうかも、対象のプログラムが落ちる、マルウェアが外へ通信を返してくる、というようにはっきり判定できます。AIは、成否がはっきり測れる技術課題を得意とします。
一方の防御側は、多くの時間を組織の課題に費やしています。ブログは例として次のような問いを挙げています。
- 保守切れのシステムを置き換える予算を取れるか
- ファイアウォールルールを追加する変更申請をどう通すか
- そのルールが、その通信に頼っている業務を壊さないと、どこまで確信できるか
防御は組織の本業ではなく、事業を続けるためのコストの一つです。だから防御の操作は、それが本業を害さないかを常に問われます。ブログは、取締役によっては「攻撃でITが止まること」と「防御チームの不適切な操作でITが止まること」にほとんど違いを感じないかもしれない、と書いています。AIに防御を自動で任せると、誰がその操作に責任を持つのかという組織の問題になります。筆者は「防御側は、攻撃側と同じようにAIを働かせることはできない」と結論づけています。
危険度を測る5つの軸
ブログは、脆弱性診断やSOC（セキュリティ監視の拠点）の運用に共通する原則として、次の3つを挙げています。
- 検知は技術が担い、対処は人が行う
- 技術による検知そのものが組織を害してはならない
- 技術による対処は、厳しく管理され範囲が絞られている（例: 明確な悪性の兆候に対して、1つのアカウントや1台のコンピュータに限定する）
この原則を分解して示されたのが、次の5つの軸です。どの軸も0が最も危険度が低く、4が最も高い段階です。
操作の強さ（Potency）: 自動化の処理が現状を観測するだけか、システムや権限、設定、実行時のふるまいを変えられるか。
- 0: AIがデータを示し、人に説明可能な助言を出す
- 2: 読み取り権限でAPIやWeb検索から自律的にデータを集める（情報が外へ出る危険が生じる）
- 3: APIを通じてデータやシステムの状態を変える（コードを実行するより歯止めをかけやすい）
- 4: コードを実行する、またはシステムや実行環境を直接変える
範囲（Scope）: 影響が及ぶ環境がどれだけ限定されているか。0は単一のシステム、1は把握済みのシステム群、2は範囲が分からない場合、4は全社・全台・共有基盤です。
重要度（Criticality）: 影響範囲が事業にとってどれだけ重要か。0は重要でないと分かっているもの、3は重要なサービスを支えているかどうか分からないもの、4は重要と分かっているシステムやサービスです。
事前の確かめやすさ（Rollout confidence）: 実行する前に、範囲と影響をどれだけ証明できるか。0は監査モード（実際には止めずに記録だけする状態）、きちんとした複製環境、または過去・直近のログによる強い裏付けがある場合です。4はフェイルオーバーがなく、テストもほとんどなく、確認が弱いか経験談に頼っている場合です。
戻しやすさ（Recoverability）: 自動化が誤っていたとき、害をどれだけきれいに素早く戻せるか。0は状態を変えないので戻す必要がない場合、1はAPIでの取り消しや権限の巻き戻しのような簡単な取り消し、4は手作業での復旧や元に戻せない場合、または多くのチームやシステムに復旧が依存する場合です。
ブログは、まず取り組みやすいのは操作の強さが低い作業、つまり「システムに直接作用する」のではなく「人に助言する」作業だとしています。AIは要約が得意で、大量の報告や脅威情報から要点を探し出す用途では、すでに防御側の役に立っています。
出口制御の運用に当てはめるとどうなるか？
ここからは本記事による当てはめです。ブログ自体は出口制御を例に挙げていません。
外向き通信の制御に関わる操作を5つの軸で見ると、同じ「止める」でも危険度に大きな幅があることが分かります。
- 遮断せず、止めたはずの通信を記録するだけ（would-blockログ）: 状態を変えないので、戻しやすさは0です。記録がそのまま、事前の確かめやすさの材料にもなります。
- 1台の端末から、1つの宛先への通信だけを止める: 範囲は単一システムで、ルール1行を消せば元に戻ります。ただし、その宛先が業務に使われていないかを確かめられていなければ、重要度は「分からない」段階に上がります。
- 全社の許可リストを入れ替える: 範囲は全社に及び、どの業務通信が影響を受けるかも事前には読み切れません。自動化に任せる候補としては最も遠い操作です。
つまり、AIに任せられる範囲を広げたいなら、操作そのものを弱くするか、範囲を絞るか、事前に確かめられる材料を増やすか、戻しやすくする必要があります。検知と遮断の役割の違いは「検知」と「遮断」の違いで、インシデント時に通信を止める判断は封じ込めの判断と事前準備で整理しています。
「危険度が低い」ことをどう示すか？
ブログは、研究や製品、効果の実証が特に必要な領域として、「危険度が低い」とされた操作が本当に低いことを決定的に示す方法を挙げています。筆者が例に出した問いの一つは、AIが通信ログを分析し、端末がつながりうる経路をすべて把握していると決定的に示せるか、というものです。システムやそのバイナリが、どの宛先へ通信しうるかを正確に示せるか、という問いも挙げています。
出口制御の現場に引き寄せると、ここで効いてくるのは日々の観測ログです。ある端末やサーバーが普段どこへ通信しているかが記録されていれば、ある宛先を止めたときに何が影響を受けるかを、実行前に確かめやすくなります。5つの軸でいえば、事前の確かめやすさを0に近づける材料になります。
ブログは同時に、自律的な防御がやって来て守ってくれるのを待つだけではいられず、従来の方法での改善も続ける必要がある、と念を押しています。
よくある質問
AIに遮断を任せるのは危険だということですか？
一律に危険だとは述べられていません。NCSCのブログが示しているのは、操作ごとに危険度が違い、それを見積もってから自動化する範囲を決めるという考え方です。人に助言するだけの作業や、状態を変えずに戻す必要のない作業は、自動化を始めやすいとされています。
5つの軸はNCSCの公式な基準ですか？
公式な基準やガイダンスではありません。NCSCのアーキテクチャ担当CTOが、2026年9月21日のブログで「提案できる枠組み」として示したものです。自社で使う場合は、考え方の整理として参考にし、段階の区切りや判定は自社の業務に合わせて決める必要があります。
まず何から自動化すればよいですか？
ブログは、操作の強さが低い作業、つまりシステムに直接作用せず人に助言する作業を、まず取り組みやすい領域としています。出口制御でいえば、遮断せずに記録だけを取り、止めた場合の影響を人が確かめる運用がこれに近い位置にあります。強い操作へ進むのは、範囲を絞り、ログで影響を確かめ、すぐ戻せる状態を整えてからです。
まとめ
- 防御の操作は業務を止める危険と責任の所在を伴うため、防御側は攻撃側と同じようにはAIを使えない
- 英国NCSCのブログは、防御操作の危険度を5つの軸（操作の強さ・範囲・重要度・事前の確かめやすさ・戻しやすさ）で見積もる枠組みを提案している
- 自動化は「人に助言する」弱い操作から始め、強い操作は範囲を絞り、事前にログで確かめ、戻せる形を整えてから任せる
- 出口制御では、遮断せずに記録する観測ログが、事前の確かめやすさを支える材料になる
- 「防御操作の危険度」は、この枠組みを指すために本記事で使う呼び方である
フォースネットのForceUTMは、既存のネットワーク構成を変えずに回線へ追加し、外向き通信の観測と宛先の制御を行う透過型UTMです（Tate（盾）の出口制御を統合しました）。ログはポータルから書き出して、お客様が契約しているAIで分析できます。何をどこで守るかの設計は、セキュリティFDEが一緒に進めます。
出典
- 英国NCSC（National Cyber Security Centre）ブログ「One does not simply defend agentically」Dave Chismon（CTO for Architecture）2026年9月21日公開 本文