100 万台 AI サービススキャンの衝撃 — Intruder レポートが暴いた ‘速度とセキュリティの非対称’

2026 年 5 月 24 日、Qiita に整理された一本の分析が、どんな新機能発表よりも重い重さで日本・韓国のエンジニアタイムラインを満たした。セキュリティ企業 Intruder が約 200 万ホストをスキャンし、そのうち 100 万台の露出 AI サービスを分析したレポートを一行で要約した見出しが「史上最悪のセキュリティ」だったからだ。何がそれほど悪かったのか、そしてそれは本当に「AI 特有の」問題なのか。

導入 — 数字の第一印象とその裏にある構造

まず Intruder レポートの骨格を数字だけで写す。200 万 + ホストがスキャンの母集団だ。そのうち 100 万台が AI サービスとして分類された — Ollama の 11434 ポート、n8n の 5678 ポート、Flowise の 3000 ポートなど、よく知られた AI ツールのポートを外部に開いているホストがそれだけある。Ollama API だけを見ると、その 100 万のうち約 5,000 台が Ollama で、そのうち 31 % — 約 1,600 インスタンス — が一切の認証なしに外部からモデル推論を呼び出せる状態だった。その 1,600 のうち 518 台は Ollama 自身でモデルをホストするのではなく、OpenAI / Google / Anthropic の有料 API をバックエンドにラップするプロキシ — つまり誰が呼んでも運営者のカードで課金される構造 — だった。政府・金融セクターで運用されている n8n または Flowise のインスタンス 90 余台が公開インターネットにそのまま露出している、という付随報告が最後に続く。

数字そのものの重みは明白だ。しかし重みの実際の意味は比較から出る。Intruder が同じ手法で同じ期間に測定した一般 Web アプリ群 (Apache / Nginx 背後の見慣れた LAMP / Node スタック) の認証欠落率は一桁台後半に留まる。AI サービス群の 31 % はそれよりも一桁大きい露出率だ。レポートの見出しが「史上最悪」と書いたのは絶対値ではなく比較値に対する診断だ。

ここで本稿が解こうとする問いが揃う。この非対称は一時的な事故か、それとも「AI ツールカテゴリに構造的に埋め込まれた欠陥」か。そしてその欠陥が構造的なら、その構造を作った力は何で、その力に対して防御側はどのような選択肢を持っているか。

本文 1 — 露出の解剖学: どこから、どう漏れているのか

Intruder レポートの最も価値ある部分は、露出のパターンをカテゴリに分けて整理した点だ。三つに分けられる。

第一のカテゴリは 「推論エンドポイントの直接露出」 だ。Ollama の 11434 ポートが代表例。Ollama の標準インストールガイドは localhost バインディングを推奨するが、Docker コンテナとして立ち上げる際に -p 11434:11434 でホストの全インターフェースにバインドされるパターンが頻発する。クラウドインスタンスでセキュリティグループが 22, 80, 443 だけ閉じていて 11434 が開いている状態は、意図したものではなく「閉じ忘れ」だ。同じパターンがテキスト埋め込みサーバー、音声モデルサーバー、マルチモーダルルーターでも繰り返される。セキュリティ欠如の最も多い原因は悪意ではなく デフォルトとガイドの距離 だ。

第二のカテゴリは 「推論プロキシの露出」 だ。レポートの 518 台 — 外部の有料 API をラップする Ollama プロキシ — が最も衝撃的な事例だ。このパターンは通常、社内ツールとして始まる。チームの誰かが「会社の OpenAI キーを直接露出せず、社内 LLM ゲートウェイを置こう」というアイデアで OpenAI 互換 API を公開する Ollama プロキシを立ち上げる。社内だけで使っていたものがクラウド上で動くようになり、クラウドのデフォルトセキュリティグループが 0.0.0.0/0 で開いていれば、そのゲートウェイは外部の誰でも自由に呼び出せる状態になる。このとき運営者は呼び出しごとの課金を支払うが、誰が呼んでいるかを知らない。Intruder レポートの一行 — 日本語訳によれば — 「課金が走るのは運営者、しかし呼び出し主は不明」がこのカテゴリの本質を要約する。

第三のカテゴリは 「ワークフロープラットフォームの露出」 だ。n8n, Flowise, Dify などのツールがここに属する。これらのツールは LLM 呼び出しをある種のビジュアルワークフローに束ねるため、露出すると単にモデル推論が漏れるだけでなく ビジネスロジックと認証クレデンシャル までもが一緒に漏れ出す。レポートの政府・金融セクター 90 余台露出事例がこのカテゴリに属する。n8n の 5678 ポートや Flowise の 3000 ポートが開いている政府機関のインスタンスから、外部攻撃者はワークフロー内に埋め込まれたデータベースパスワード、社内 API トークン、チャットボットのシステムプロンプト、過去会話の個人情報を同じ画面で見ることができる。露出のブラスト半径が単純な推論露出よりもはるかに大きい。

三つのカテゴリの共通の特徴を整理すると — 三つとも 「開発者ツールの基本 UX が外部露出シナリオを想定せずに設計されている」 という点だ。ローカルで素早く立ち上げて気軽に実験することが一次ユーザー想定で、プロダクション配備はユーザーが自らセキュリティを追加する前提だ。その前提が破られる地点に 100 万台の露出がある。

本文 2 — ‘速度とセキュリティの非対称’ がなぜ AI でより大きいのか

ここで本稿の第二の問いに入る。上記の露出パターンは、実は LAMP 時代の phpMyAdmin 露出、コンテナ時代の etcd 露出、ビッグデータ時代の Elasticsearch 露出と形状は同じだ。それなのになぜ AI ツールカテゴリでその比率が一桁大きく現れるのか。構造的原因を三つ整理する。

第一に、「デプロイの時間定数」 が違う。伝統的な Web アプリの配備は普通、数週間 ~ 数ヶ月単位のプロジェクトとなる。その期間にインフラチームがセキュリティレビュー、ネットワーク設定、IAM ポリシーを揃える。AI ツールの配備はしばしば 「半日 ~ 数日」 で終わる。誰かが GitHub README を見て docker run 一行で立ち上げ、その結果をデモで見せ、それが正式サービスとして固まる。その数日の間にセキュリティレビューが入る余地はない。Intruder レポートの事例の多くが「実験から始まって固まったもの」であることが、この時間定数の帰結だ。

第二に、「ユーザーの技術的自己診断能力の分布」 が違う。AI ツールの運用者はデータサイエンティスト、機械学習エンジニア、またはツールを学んだばかりのバックエンドエンジニアであることが多い。伝統的 Web 運用者プールに比べて、クラウドネットワークセキュリティ — セキュリティグループ、IAM、シークレット管理 — に対する深さが平均的に浅い。これは非難ではなく分布の事実だ。AI ツールが新しいユーザーカテゴリを引き寄せており、そのユーザーカテゴリのセキュリティデフォルト感覚が LAMP 運用者のそれとは異なる、というのが核心だ。

第三に、「攻撃経済学の非対称」 がある。伝統的な Web 露出はデータ盗難、サイト改ざん、ボットネット追加など比較的測定可能な被害につながる。AI ツール露出はそれに加えて 「推論コストの外部化」 という新しい攻撃モードを生む。誰かが露出した Ollama プロキシを発見すれば、自分の ChatGPT コストを回避するためにそのプロキシ経由で OpenAI API を呼び出す。運営者は知らない間に月数千ドルを負担する。攻撃者の利得は抽出されたデータの価値ではなく回避された推論コストであり、そのコストは非常に滑らかに現金化される。攻撃 ROI が明確だ、という事実そのものが新しい種類の圧力だ。

三つの構造的原因が合わさると、AI ツールの露出比率が伝統 Web のそれよりも一桁大きいのは一時的な現象ではなくカテゴリの本質、という結論が導かれる。Intruder の見出しが「史上最悪」と書いたのは誇張ではなく 「カテゴリが持つ非対称の最初の大きな測定」 だ。

ここにレポートの最後の一行 — 「もう始まっている」 — の重みが乗る。Google の Threat Intelligence Group が同じ 5 月に発表したレポートによれば、攻撃者が LLM を使ってゼロデイ探索とエクスプロイトの自動生成を実際に開始した痕跡が捉えられている。露出したインスタンスを自動で見つけ、そのインスタンスのモデルを使って次のエクスプロイトを作り、そのエクスプロイトを次の露出したインスタンスに適用する自己強化ループが、理論から実測へと移行しつつある、ということだ。100 万台の露出という巨大な表面がそのループの燃料となる。

本文 3 — 防御側の選択肢: 短期措置と構造的変化

この診断の重みの上で、防御側が即座にできることと中期的にすべきことを分ける。

即座 — 次の 24 ~ 72 時間単位 — の措置はシンプルだ。すべての AI ツールの基本ポート (11434, 5678, 3000 ほか運用中のポート) の外部露出を点検する。shodan 検索や社内資産スキャナで自社資産の露出状態を自分で先に確認することが第一歩。露出が発見されたらセキュリティグループ / ファイアウォール / リバースプロキシ認証のうち最も速い方法で塞ぐ。次の段階は — Intruder の勧告によれば — 露出インスタンスの推論ログと請求書を点検し、外部呼び出しがすでに発生していたかを確認することだ。推論コストの外部化は請求書の平時パターンとは異なる形で現れるため比較的明確に捕捉できる。

中期 — 四半期単位 — の措置はツール選択と運用パターンに入る。三つに整理する。

第一に、「AI ツールはゲートウェイの背後に置く」 という新しい標準の採択。Ollama, n8n, Flowise の直接露出を許さず、すべての呼び出しが認証・監査・リクエスト上限制御の効くゲートウェイ (例: Litellm, Portkey, 自社ビルドゲートウェイ) を経由するようにする。これはクラウド時代初期に「データベースをインターネットに直接露出させない」が標準になったのと同じ種類の衛生標準だ。

第二に、「推論コストの異常検知」 の日常化。AWS / GCP / Azure のコストアラームが新しい種類のセキュリティアラームに格上げされる。モデル呼び出し量の時間あたり / 日あたり分布が普段の平均から標準偏差 3 ~ 5 倍を超えれば自動遮断され運用者に通知される構造だ。推論コスト外部化攻撃に対する最も速いシグナルが請求書の形状変化だからだ。

第三に、「AI ツール運用者のセキュリティ資格」 の確立。データサイエンティスト / ML エンジニアがプロダクション推論インフラを運用する前に受けるべき最低限のセキュリティ教育が標準化される。セキュリティグループ、IAM、シークレット管理、推論ログ保存ポリシーの四点が核心だ。これは DevOps が運用エンジニアの標準資格となった過程と同じ種類の職務拡張だ。

三つの措置は同時に進む必要がある。ゲートウェイだけ置けばゲートウェイが露出され、コストアラームだけあればアラーム到着時点で既に大きな被害が発生しており、教育だけあればツールが追い越す。短期措置 + ゲートウェイ + コストアラーム + 運用者資格の四つが同時期に揃ってこそカテゴリの構造的非対称が緩和される。

結論 — ‘もう始まっている’ という警告をどう受け止めるか

Intruder レポートが投げかける本当のメッセージは 100 万台の露出という数字そのものではない。「AI ツールカテゴリはセキュリティデフォルトが壊れた状態のまま急速に拡大しており、その壊れたデフォルトの請求書がすでに到着しつつある」 という診断こそが本当のメッセージだ。この診断はツール製作者、運営者、その間のセキュリティコミュニティに、それぞれ異なる重みで作用する。

ツール製作者には 「開発者フレンドリーなデフォルトとプロダクション安全デフォルトの分離」 という宿題が下りる。Ollama が localhost バインディングを推奨する、という事実だけでは足りない。--bind 0.0.0.0 オプションを明示的にオンにしてのみ外部バインディングが可能になるように動作そのものが変わるべきだ。n8n と Flowise の初回ブート時の認証ウィザードが強制されるべきだ。この変化はツールの学習曲線をやや上げるが、カテゴリの信頼を回復する唯一の道だ。

運営者には — 既に上で整理した四つの措置を即座に実行する以外に — 自社が運用する AI ツールの露出リスクを自分が測定可能にする責任が加わる。「shodan で自社資産を検索してみる」は 1 時間で終わる作業だが、それを定期作業にする運用チームは非常に稀だ。

セキュリティコミュニティには — 最も重要なことだが — カテゴリ別衛生標準を作る仕事が落ちる。OWASP の Top 10 が Web カテゴリにしたことを、AI ツールカテゴリで再びしなければならない。OWASP の LLM Top 10 はすでに始まっているが、それはモデル使用の標準であってツール運用の標準ではない。Intruder が示した露出のカテゴリ化 (推論エンドポイント、推論プロキシ、ワークフロープラットフォーム) がその新しい標準の出発点となるべきだ。

最後に — 最も難しい — 一つの問いを読者に投げかけて稿を閉じる。我々が運用中の AI ツールインスタンスの露出状態を、我々は本当に知っているか。Intruder の 100 万台のうち一台が我々のものである確率は正確にどれくらいか。その答えを知らなければ、次の 24 時間以内に答えを作ることがこのレポートに対する最も誠実な応答だ。

出典: