社内のAI基盤は「探索される側」でもある — LLM連携基盤の露出面という考え方

社内で生成AIを試すとき、多くは「ツールをサーバーに立てる」ところから始まります。ワークフロー自動化のツール、ローカルでモデルを動かす推論サーバー、検証用のAPIゲートウェイ。動かすこと自体は、以前よりずっと簡単になりました。そこで見落とされがちなのが、そのサーバーが、いま何と繋がっているのかという問いです。

AIのセキュリティというと、入力した情報の行き先やプロンプトインジェクションのような、AIそのものの振る舞いに目が向きがちです。この記事で扱うのはそちらではなく、基盤の通信経路のほうです。観測データが示していたのは、もう少し古典的な事実でした。AI関連のサーバーは、インターネットから到達できる状態にあれば、外から探索される対象にもなるということです。

何が観測されたのか：LLM関連フレームワークを狙う通信

JPCERT/CCが2026年7月16日に公開した『JPCERT/CC 四半期レポート』（対象期間 2026年4月1日～6月30日）の23ページ「2.2.2 LLM 関連フレームワークの脆弱性を狙う通信」に、次の観測が記載されています。

n8n におけるコード実行の脆弱性（CVE-2026-21858）やllama-cpp-python / SGLang におけるコード実行の脆弱性（CVE-2024-34359 / CVE-2026-5760）といった、LLM と連携するフレームワークやライブラリの脆弱性を標的とした攻撃パケットやスキャンパケットが、2026 年4 月下旬ごろから散発的に観測されています。

これはJPCERT/CCがインターネット上に設置している低対話型ハニーポット（サービスへの通信を記録するための観測用の仕掛け）で捉えられたものです。観測されたのはハニーポットへ届いたパケットであり、実在企業のサーバーが侵害されたという報告ではありません。件数の規模についても、レポート自身が「散発的」と書いています。

なお、引用中のCVE-2026-21858について、NVD（米国の脆弱性データベース）は、特定のフォーム型ワークフローを介したサーバー上のファイルへのアクセスと、構成や利用状況によっては追加の侵害につながりうる問題として説明しています。レポートの「コード実行の脆弱性」という表現とは記述の粒度が異なります。どちらの記述が実態に近いかをこの記事で判定することはしないため、出典の記述をそのまま引用したうえで、以下では個別の脆弱性の性質を論拠にはしません。

そのうえでレポートは、対策について次のように述べています。

LLM と連携する開発基盤はインターネットとの通信経路を持つことが比較的多いと考えられます。脆弱性の修正を適用するだけでなく、通信を適切に制御するなど、多層的な防御を意識した対策が重要です。

注目したいのは、脆弱性の修正と並べて「通信を適切に制御する」ことが挙げられている点です。この記事では、その「通信の制御」が何を指すのかを、社内にAI基盤を置いた場合の構図に沿って整理します。以下の整理は当サイトによるもので、レポートが提示した手順ではありません。

LLM連携基盤の露出面とは何か？

LLM連携基盤の露出面とは、社内でAIを動かすために用意したサーバーが持つ、外部と通信できる箇所の総体を指します。ここには、外部から到達できる入口（管理画面やAPI）と、外部へ出ていく出口（モデルの取得や外部AIサービスの呼び出し）の両方が含まれます。AI基盤をひとつ立てると、この入口と出口が同時に増えることがあります。業界で定まった用語ではなく、方向を分けて数えるために当サイトが使う呼び名です。

発想としては攻撃面（アタックサーフェス）とほぼ同じですが、AI基盤では入口と出口で事情が異なるため、方向を意識して分ける言い方をしています。

なぜAIを動かすと「面」が増えるのか

AI関連の基盤は、外部からモデルやパッケージを取得し、外部のAIサービスを呼び出す構成を取ることが多いためです。加えて、ワークフローを組んだりログを見たりするための管理画面が要る場合があります。その結果、外へ出ていく出口と、操作のために開ける入口が生じます。

一般的な社内向けの業務システムであれば、外向きの通信をほとんど必要としない構成も成り立ちます。AI関連の基盤には、次のような構成が見られます。

• モデルやパッケージを取ってくる構成：モデルの配布元、パッケージリポジトリ、コンテナレジストリへの通信が前提になります
• 外部のAIサービスを呼ぶ構成：社内で動かすのは前段のワークフローだけで、推論そのものは外部APIというケースがあります
• 操作のためのUIが要る構成：ワークフローを組む、動作を確認する、ログを見る。これらを画面から行うなら、管理UIが立ちます
• 検証として始まる場合：まず動かして評価する段階では、認証やアクセス範囲の設定が後回しになり、そのまま残ることがあります

JPCERT/CCが「インターネットとの通信経路を持つことが比較的多いと考えられます」と書いているのは、上の3つのような通信経路を指していると読めます。4つ目に挙げた設定の後回しは、通信経路があるかどうかとは別の話で、当サイトが並べて挙げているものです。ただし、ローカルで完結する構成や、管理UIを外部公開しない構成もあります。自社がどれに当たるかは、構成ごとに変わります。

ここで区別しておきたいのは、外向きの通信があること自体は、外から到達できることを意味しないという点です。多くの構成では、内から外への通信は通っても、外から内へは届きません。入口ができるのは、管理UIやAPIを社外からも使えるようにするために経路を開けたとき、あるいはクラウド上に立てたインスタンスの公開範囲が広いまま残っているときです。検証として始めた基盤ほど、この設定が見直されないまま残ることがあります。

なお、この話はシャドーAI（会社が把握していない未許可のAI利用）とは別の問題です。シャドーAIが「社員が外部のAIサービスを使ってしまう」問題であるのに対し、こちらは会社が正規に立てたサーバーが、想定より広く到達可能になっている問題です。前者は利用の統制、後者は構成の把握が起点になります。

露出面は入口と出口の両方にある

方向を分けると、リスクの中身と打ち手が整理しやすくなります。攻撃者の側から見れば、入口は侵入の起点になり、侵入された場合には出口が外部とのやり取りに使われることがあります。これは一般的な攻撃の筋道の整理であり、今回のレポートが観測として報告したものではありません。

方向	何が論点になるか	制御の考え方
入口（ingress）	管理UIやAPIのエンドポイントが探索され、既知の脆弱性を突かれる	そもそも誰から到達できる必要があるのかを決め、範囲を絞る
出口（egress）	侵入された場合に、外部とのやり取りへ使われうる	接続先を許可リストで絞る

当サイトの既存のコラム記事は、AIエージェントのリスクは外向き通信に重心があるという観点から、出口側の制御を中心に扱ってきました。今回の観測が思い出させるのは、その手前の入口側にも面があるという点です。

入口の制限と出口の制限は、それぞれ異なる局面を対象にします。入口は到達そのものを減らし、出口は侵入された後に外部とやり取りできる範囲を減らします。インシデント発生時の封じ込めで通信の遮断が選択肢になるのは、後者の考え方によるものです。

脆弱性の修正だけでは間に合わないことがあるのはなぜか

修正が公開されてから、それが自社の環境に適用されるまでに時間差が生じることがあるためです。その間、当該の脆弱性を持ったまま到達可能な状態が続きます。通信の制御は、この時間差の間に被害が成立することを難しくする層として置かれます。修正の適用が最優先であることは、この整理をしても変わりません。

レポートが名前を挙げた3件は、いずれも公表済みの脆弱性です。観測された通信が個々の公表を契機にしたものかどうかは、レポートにも書かれておらず、公開情報からも判断できません。ここで言えるのは、公表済みの脆弱性が探索の対象になりうるということまでです。

修正の適用が遅れる事情としては、次のようなものが考えられます。いずれもレポートに書かれているものではなく、更新が遅れる場合の例として当サイトが整理したものです。

• 導入したツールが依存するライブラリまで含めると、更新対象の把握が難しい
• 検証目的で立てたものは、運用中のシステムのような更新計画の対象に入っていないことがある
• 更新によって動作が変わる可能性があるため、適用の前に動作を確かめる工数が要る

通信の制御は、この時間差を埋める層として置かれます。修正が適用されるまでの間、到達経路を減らす・外部と通信できる範囲を絞るという別の層で被害の成立を難しくする、という位置づけです。許可した宛先を経由する持ち出しまで一律に止められるわけではありません。この記事では「多層的な防御」を、修正・到達範囲の制限・外向き通信の制限を組み合わせることとして整理しています。逆にいえば、通信制御があるから修正しなくてよい、という話にはなりません。

専任の担当者がいない状況で、まず確認できること

情シスの担当が総務や経営者との兼任である場合、網羅的な棚卸しから始めるのは現実的ではありません。最初の確認対象を絞るなら、手元で見て分かることと、構成を知っている人に聞くことを分けると進めやすくなります。これはJPCERT/CCが示した手順ではなく、当サイトの確認例です。

手元で見て分かること

1. AI関連のツールを動かしているホストを挙げる：検証用・PoC用として立てたものを含めます。「誰が、いつ、何のために立てたか」まで分かると理想的です
2. レポートが名前を挙げた製品を使っていないかを見る：n8n、llama-cpp-python、SGLang、およびこれらを内部で使う構成が該当します。使っている場合は、まず修正の適用状況を確認します。個別の脆弱性の深刻さをこの記事では判定しませんが、名前の挙がっているものを棚卸しする作業は、観測の話とは独立して最初に済ませられます
3. インターネット側から到達できるかを試す：社内のネットワークの外（スマートフォンの回線や自宅の回線など）から、そのツールの画面が開けてしまわないかを試します。画面が開く場合、少なくともその接続元からはインターネット経由で到達できる状態です。認証や接続元の制限がかかっているかも併せて確認します。ただしこの方法で分かるのは、試したURLと接続条件についてだけです。社用端末が常時VPNや社内DNSを経由している場合、社外の回線から試したつもりでも社内側の経路をたどっていることがあります
4. そのホストが外向きにどこへ繋いでいるかを書き出す：まず設計や設定から分かる範囲（モデルの配布元、パッケージリポジトリ、呼び出している外部API）を書き出します

構成を知っている人に聞くこと

導入や運用を外部の事業者に任せている場合、次の2つは手元の画面からは確かめきれません。窓口が社内の別部署であっても、聞く相手が変わるだけで内容は同じです。

• インターネットから到達できる経路があるか：画面を持たないAPI、別のポート、IPv6の経路、クラウドのロードバランサーや公開IPは、3の方法では見えません。ルーターのポート転送設定や、クラウドのファイアウォール・セキュリティグループの設定が対象になります。設定の管理者や保守事業者が社外にいる場合は、「このホストへインターネットから到達できる経路があるか」を先方へ確認します。3で画面が開かなかったことだけを根拠に、公開されていないと判断しないことが要点です
• 使っている製品と、その版：2の棚卸しは、構築を委託した基盤では手元の情報だけでは埋まりません。名前の挙がった製品を内部で使っていないか、使っている場合に修正が適用されているかを、導入元や保守事業者へ確認します

分かった後に決めること

到達可能である必要がないものは、まず経路を閉じる。検証が終わっているものは、止めるという選択肢も含めて判断します。

ここまでのうち、4で書き出した想定と実際の通信を突き合わせるには、社内からインターネットへ出ていく通信を観測できる状態が別に必要になります。これは書き出しの作業とは違い、手元の設定を見るだけでは済みません。既存の構成を変えずに観測から始める進め方は、導入の流れで説明している observe → monitor → enforce の段階導入と同じ考え方になります。

なお、社外の回線から自社のシステムへ接続を試す場合は、事前に社内の合意を得てから行ってください。

よくある質問

社内ネットワークの中に置いてあれば、この話は関係ありませんか？

インターネット側から直接到達できない構成であれば、外部からそのサービスへ直接届く経路は限定されます。ただし出口側の論点は残ります。AI基盤がモデルの取得や外部APIの呼び出しのために外向きの通信を持つ場合、その接続先が想定どおりかを確認しておく意味はあります。

外部のAIサービスをAPIで使っているだけでも関係ありますか？

観測されたのは自組織で動かすフレームワークやライブラリを狙う通信のため、外部APIを呼ぶだけの利用は直接の対象ではありません。ただし、その呼び出しを仲介するワークフロー基盤や管理UIを社内に立てている場合は、そのサーバーに脆弱性がないか、インターネットから到達できる構成になっていないかを確認する対象になります。何を社内で動かしているかで切り分けるのが実務的です。

通信を制御すると、AI基盤が動かなくなりませんか？

いきなり遮断する運用にすると、その懸念は現実になります。まず接続先を観測して記録し、必要な宛先を確認してから段階的に絞り込むことで、いきなり遮断する場合より業務への影響を抑えやすくなります。観測の結果、必要な接続先を限定できる構成であれば、許可リスト型の制御を検討できます。

まとめ

• JPCERT/CCは、LLMと連携するフレームワークの脆弱性を狙う通信を2026年4月下旬ごろから散発的に観測したと報告している
• 社内で動かすAI関連基盤では、構成によって管理UIやAPIという入口と、モデル取得や外部API呼び出しという出口が生じる
• レポートは、脆弱性の修正を適用するだけでなく通信を適切に制御することを、多層的な防御として挙げている
• 修正の適用には時間差が生じることがあるため、通信制御はその時間を埋める層として位置づけられる
• 出発点は、AI関連のホストを挙げ、レポートが名前を挙げた製品の修正状況と、到達できる範囲と繋いでいる先を確認すること

AIエージェントを含む構成でネットワーク側の防御をどう組むかは、技術ガイド: AIエージェントのセキュリティで整理しています。既存の構成を変えずに通信の観測から始める方法は、透過型ファイアウォールとはで確認できます。

出典

• JPCERT/CC『JPCERT/CC 四半期レポート』（2026年4月1日～2026年6月30日、2026年7月16日公開）本文23ページ「2.2.2 LLM 関連フレームワークの脆弱性を狙う通信」（PDFでは24ページ目） レポート本文（PDF）（四半期レポート一覧）
• NVD: CVE-2026-21858
• NVD: CVE-2026-5760
• 公開日の確認: JPCERT/CC「『JPCERT/CC 四半期レポート』公開のお知らせ」（2026年7月16日） 公開のお知らせ