ネットワーク分離設計をAIで自動化｜研究解説

「この基幹システムはインターネットから直接触らせない」「決済系は別ゾーンに置く」——こうした日本語の要件から、ゾーン構成・境界機器・通信経路・ACLまでを一気に自動生成する研究が公開されました。arXivで公開された研究「TopoIntent」（arXiv:2608.13389、2026年8月13日公開）です。生成したトポロジをCIS Controls v8.1.2に照らして自動チェックし、足りない部分を補修したうえで、Mininet上で実際に疎通・遮断テストができる形まで出力します。

ただしこれは査読前のプレプリントであり、評価も研究チームが自作した小規模なデータセット上のものです。「もう設計は自動化できる」と読むと危険です。本記事では、何が新しく、情シスの実務でどこまで使えるのかを率直に整理します。

この記事でわかること

  • TopoIntentが何を自動化しようとしているのか（1文要約）
  • 3段階の仕組み（テンプレート検索 → 融合 → コンプライアンス検証）
  • 報告された数値（0.78→1.00、0.78→0.88）の正しい読み方
  • 情シスが今日から流用できる考え方と、期待しすぎてはいけない点

どんな研究か（1文でいうと）

TopoIntentとは、自然言語で書かれたあいまいなセキュリティ要件を、実行可能でコンプライアンス検証済みのネットワークセキュリティ構成（ゾーン・境界機器・ゾーン間経路・アクセス制御ポリシー）に「コンパイル」するシステムです。

論文が問題視しているのは、既存のNetOps自動化ツールの守備範囲です。Ansible等の構成管理やIaCは強力ですが、それらは「設計が確定した後」から動くものです。「業務意図・規制要件・リスク前提を、どうゾーン分割と通信ポリシーに落とすか」という一番頭を使う工程は、依然として人間の設計者の頭の中にあります。TopoIntentはその手前、つまり要件からトポロジを起こす工程を埋めにいっています。

なぜ「設計の自動化」が難しいのか

要件は、たいてい書ききられていません。「個人情報を扱う系は分離する」とは言われても、DMZを置くのか、管理セグメントをどう切るのか、ログはどこに集約するのかまでは書かれていない。設計者は業界の定石（リファレンスアーキテクチャ）で不足を埋めています。

そのままLLMに投げると、もっともらしいが構造が破綻した図が出てきます。ゾーンだけ増えて境界機器がない、経路が定義されていない、といった具合です。TopoIntentはここにスキーマ契約（schema contract）という制約をかけ、出力の形を固定したうえで生成させる方針を取っています。

TopoIntentの仕組み：3段階

段階 やっていること 狙い
1. テンプレート検索 整備済みテンプレートライブラリから、密ベクトル検索でリファレンスアーキテクチャを取得 「定石」を外部知識として持ち込み、ゼロから作らせない
2. 段階的融合（staged fusion） 要件とテンプレートを突き合わせ、書かれていない部分をテンプレート側で補完（security completion） 要件のあいまいさを埋める
3. コンプライアンス検証と補修 CIS Controls v8.1.2のうちトポロジ層で見えるセーフガードに照らして検査。不足はスキーマを壊さない「追加のみ」の編集で補修。解決できないものは人手レビュー対象としてマーク 抜けを機械的に潰し、判断が要るものは人に返す

最終成果物は、Mininet（ネットワークをPC上で仮想的に構築できるエミュレータ。研究・検証でよく使われます）のスクリプトと、カーネルレベルのiptables ACLとして出力されます。つまり図で終わらず、実際に「通るはずの通信が通るか」「止めるはずの通信が止まるか」をテストできる形まで落ちる。ここが地味ですが実務的に重要な点です。

報告された数値と、その読み方

この課題には公開ベンチマークが存在しないため、研究チームはリファレンス構成図から評価セットを自作しています。

項目 内容
検索用セット 22テンプレート／5シナリオにわたる44件の合成インテント
ホールドアウトセット 7テンプレート／14インテント（金融・政府シナリオ。検索対象から除外）
CIS充足度 追加補修により 0.78 → 1.00（平均1.5ラウンド未満）
ACL適用後のポリシー通過率 フィードバック1ラウンドで 0.78 → 0.88

「CIS充足度1.00」は満点ではない

論文の表現は正確で、「トポロジ層で見えるセーフガード」に対する充足度です。CIS Controlsには構成管理の運用プロセス、ログの保全期間、変更管理といった図からは判定しようがない項目が多数あります。1.00は「機械的に見える範囲は埋め切った」であって、「CIS準拠になった」ではありません。ここを取り違えると、監査で痛い目を見ます。

0.88という数字は、そのままでは本番に出せない

ACL適用後のポリシー通過率0.88は、裏を返せば12%は意図どおりに通っていない／止まっていないということです。ファイアウォールのルールで12%外れていたら、現場では差し戻し案件です。この研究の位置づけはあくまで「人手レビュー前提のたたき台生成」であり、論文自身も未解決ケースを人手に回す設計になっています。

評価規模は14インテント

ホールドアウトは14件、しかも合成データです。実在企業の込み入った要件（既存資産のしがらみ、部門ごとの例外運用、統廃合で残った旧セグメント）は含まれていません。査読前の研究であり、結果は今後変わりうる点も改めて強調しておきます。

現場目線：ここは刺さる、ここは期待しすぎない

正直なところ、多くの組織で本当に困っているのは「設計図が描けないこと」ではありません。「なぜこのセグメントがこう切られているのか、誰も説明できないこと」です。担当者が異動し、当時のExcelの構成図だけが残り、分離の意図が失われる。新しいシステムを載せるたびに、恐る恐る穴を開けていく——この状況は珍しくないはずです。

その意味で、この研究の面白さは自動生成そのものより「要件 → 構成 → テスト」を機械が追跡できる形につないだことにあります。要件を書き換えたら構成とACLが再生成され、疎通テストで差分が出る。設計意図がドキュメントではなくテスト可能な形で残るなら、引き継ぎ問題にはかなり効きます。

一方で、期待しすぎない方がよい点も3つあります。

  • 出力品質はテンプレートライブラリの品質で決まります。自社の設計思想を反映したテンプレートを持たない組織が、外から来たテンプレートをそのまま採用すると、「定石どおりだが自社の業務に合わない構成」が量産されます。
  • Mininetは実機ではありません。エミュレータ上で通っても、実機のステートフル挙動、NAT、機器ごとのACL評価順序、暗黙のdenyの扱いといった差異は再現されません。検証環境での確認は必須です。
  • 「分離した」ことと「守られている」ことは別です。境界機器そのものが侵入経路になる事例は現実に多発しています（参考: ORB化とは 境界機器が攻撃の中継拠点にされる脅威）。きれいなゾーン図があっても、そのゾーンを守る機器のパッチが当たっていなければ意味がありません。

情シスは何をすべきか

この論文をきっかけに設計ツールを探し始める必要はありません。むしろ、今の自社構成が「要件から説明できる状態か」を点検するほうが先です。

枠組みとしては、まず公的な指針に当たるのが近道です。ネットワーク分離や境界防御の考え方は、以下が実務に落としやすくまとまっています。

あわせて、フレームワークの共通言語を持っておくと経営層への説明が楽になります（NISTサイバーセキュリティフレームワークとは？6機能を解説／ISMSとは？ISO/IEC 27001認証の基礎を解説）。そして、机上で分離できているつもりでも実際に横移動できてしまうケースは多いため、定期的な実地確認も欠かせません（ペネトレーションテストとは？脆弱性診断との違いを解説）。

最後に、地道な話ですが、分離設計はユーザ部門の理解なしには維持できません。「業務が回らないから」と例外を積み増した結果、分離が形骸化するのはよくある展開です。啓発資料（IPA「対策のしおり」）を使って、なぜ不便を受け入れてもらうのかを説明し続ける作業が、結局は一番効きます。

まとめ

  • TopoIntentは、自然言語のセキュリティ要件からゾーン構成・ACLまでを生成し、CIS Controls v8.1.2で検証してMininet+iptablesとして実行可能な形に出力する研究です（arXiv、査読前プレプリント）。
  • 報告値の読み方に注意。CIS充足度1.00は「トポロジ図から見える範囲」に限った話であり、ACL通過率0.88は12%が意図どおりでないという意味です。人手レビュー前提のたたき台生成と捉えるのが妥当です。
  • 実務で今できるのは、自社構成を「要件から説明できる状態」にしておくこと。IPAの各ガイドラインとCIS Controls 12/13を出発点に、机上演習と実地確認で分離の妥当性を定期的に確かめてください。

出典

タイトルとURLをコピーしました