AI・機械学習 2026.05.25

AIインフラ100万台調査で露呈した認証なし公開の実態

約17分で読めます

Intruder社が100万超の公開サービスをスキャンした調査で、Ollama・n8n・Flowiseが認証なしで大量公開されている実態が明らかに。AI導入の速度がセキュリティを危険なほど置き去りにしている現状を解説します。

AIの導入スピードが、セキュリティを危険なほど置き去りにしている

「とりあえずOllamaを立ててみた」「n8nでワークフローを自動化したら便利だった」――AIツールのセルフホスティングが急速に広がる中、こんな状況に心当たりはありませんか?

ドキュメント通りにインストールして動いたからといって、それが「安全に動いている」とは限りません。むしろ、ドキュメント通りにデプロイしたことで、無防備なまま全世界に公開されてしまっているケースが大量に存在することが、2026年5月にThe Hacker Newsが報じた調査で明らかになりました。

調査を実施したのは、攻撃面管理(Attack Surface Management)ツールを提供するセキュリティ企業・Intruder社です。その調査結果は、「AI基盤の普及」と「セキュリティ意識の乖離」という業界全体の深刻な問題を浮き彫りにするものでした。

この記事では、調査の内容を正確に紐解きながら、Web担当者や情シス担当者が今すぐ取るべき対策を具体的に解説します。


調査の規模と手法:200万ホストを「外から見た」

Intruder社の調査チームが使ったのは、**証明書透明性ログ(Certificate Transparency Logs)**という手法です。これは、TLS/SSL証明書の発行記録を公開ログから収集・追跡する仕組みで、「インターネット上に存在する公開サービスの一覧」を外部から把握するために使われます。

この手法で抽出した200万超のホストから、さらに100万以上の公開サービスを特定してスキャンを実施。特に注目したのは、Ollama、n8n、Flowise、OpenUIといったAI関連のオープンソースプロジェクトです。

証明書透明性ログとは? WebサイトがHTTPS通信に使うSSL証明書は、発行のたびに公開ログに記録されます。このログは誰でも参照可能なため、セキュリティ研究者はもちろん、攻撃者も「どんなサービスが公開されているか」を把握するために活用しています。つまり、今回の調査と同じ手法で、悪意ある第三者もターゲットを探せるということです。

この調査が実施された背景には、ClawdBotという自己ホスト型AIアシスタントが1日平均2.6件というハイペースでCVE(共通脆弱性識別子)を出し続けているという問題事案がありました。AI関連OSSの脆弱性が構造的な問題を抱えているのではないか――その仮説を検証するための大規模調査だったのです。


無料AI相談

AIで気軽にWeb相談してみませんか?

詳しく見る

発見1:「認証なしデフォルト」という業界全体の病

調査で最初に浮かび上がった構造的問題が、認証機能がデフォルトで無効になっているAI関連OSSの多さです。

これは単に「設定ミス」の話ではありません。多くのプロジェクトが、ドキュメント通りにインストール・起動した状態では認証が一切要求されない設計になっているのです。開発者が「まず動かしてみる」ことを優先するために利便性を高めた結果が、本番環境でそのまま使われるという事態を招いています。

さらに調査では、以下のような複合的な問題も確認されています:

  • rootユーザーによる実行:コンテナやサービスが管理者権限で動作しており、侵入された場合のダメージが最大化する
  • docker-composeへのハードコード認証情報docker-compose.yml にAPIキーやパスワードが平文で記述されており、ファイルが外部からアクセス可能な状態で公開
  • Dockerの誤設定:Dockerソケットの露出など、ホスト全体を乗っ取られるリスクのある設定
  • 新規の任意コード実行脆弱性:AIプラットフォーム固有の、まだパッチが当たっていないRCE(リモートコード実行)脆弱性

「ローカルで試すだけ」が本番に化ける 開発環境で動作確認したdocker-compose.ymlをそのまま本番サーバーにコピーするケースは珍しくありません。APIキーやDB接続情報がハードコードされた状態で公開サーバーに置かれると、それだけで重大なセキュリティインシデントになり得ます。


発見2:Ollama APIの「31%応答」という衝撃的な数字

Ollamaは、LLaMAやMistralといった大規模言語モデルをローカル環境で動かすためのOSSです。API経由でモデルにアクセスできる設計で、開発者の間で急速に普及しています。

Intruder社の調査チームは、モデルが接続済みかつ認証なしで公開されているOllama APIに対して、シンプルなテストとして 'Hello' というメッセージを送信しました。

その結果、5,200台超のうち31%が実際に応答を返しました。

返ってきたレスポンスの内容が、問題の深刻さをよく表しています:

"Greetings, Master. Your command is my law."

"I am here to assist you ... with your health and wellbeing issues."

"I am an AI assistant integrated with our cloud management systems."

最後のレスポンスは特に注目に値します。「クラウド管理システムに統合されたAIアシスタント」と名乗るモデルが、認証なしでインターネットに公開されていたのです。何らかのインフラ管理ツールと連携したAIが、外部から自由にアクセスできる状態にあったことを示唆しています。

さらに深刻なのが、518台はAnthropicのClaude、DeepSeek、Moonshot、Google、OpenAIなどのフロンティアモデルへのプロキシとして機能していたという事実です。これらのインスタンスは、本来有料で使用するはずのAPIを無制限で外部から利用できる「無料プロキシ」と化していました。APIコストを誰かが知らないうちに負担させられ続けているわけです。


発見3:n8n・Flowiseでビジネスロジックと認証情報が筒抜けに

n8nはノーコード/ローコードのワークフロー自動化ツール、Flowiseはビジュアルでエージェントを構築できるプラットフォームです。どちらもAIエージェントの普及とともに急速に採用が広がっています。

調査では、これらのエージェント管理プラットフォームが政府機関・マーケティング・金融セクターを含む90件以上で認証なしに公開されていることが判明しました。

露出していた情報は、単なる設定ファイルにとどまりません:

  • ワークフローの全内容:業務プロセス・自動化ロジックがそのまま閲覧・改ざん可能
  • 認証情報リスト:外部サービスへの接続に使うAPIキー、ユーザー名、パスワード
  • ローカル関数へのアクセス:ファイル書き込み機能、コードインタープリタなど、サーバー上で任意の操作が可能な機能

また、OpenUIベースのチャットボットでは、ユーザーとLLMのチャット会話履歴が完全に露出。個人情報や業務上の機密情報がやり取りされていた可能性があります。

NSFW系チャットボットの事例では、さらに直接的な問題が発覚しました。Claude APIキーが設定ファイル内に平文で保存・公開されていたのです。これは単なるプライバシー侵害にとどまらず、そのAPIキーを使って攻撃者が無制限にClaudeを利用できることを意味します。


なぜこんなことが起きるのか:速度優先の文化という根本原因

技術的な問題の背後にある本質的な要因を理解しておくことは重要です。

Intruder社の調査レポートが指摘した核心は、まさに "speed is winning, security is lagging behind"(速度が勝ち、セキュリティが取り残されている) という一言に集約されます。

AIツールの競争は凄まじい速さで進んでいます。新しいモデルが毎週のように登場し、OSSプロジェクトはユーザー獲得のためにインストールの手軽さを最優先します。「5分で動く」「docker-composeで一発起動」というアピールが開発者を引き付ける一方で、セキュリティの設定は後回しにされます。

エンタープライズソフトウェアが長年かけて培ってきた「デフォルトセキュア」という設計思想が、新興のAI系OSSではまだ根付いていません。結果として、世界中の開発者や企業が「ドキュメント通りに動かした」だけで、意図せずインターネットに脆弱なエンドポイントを公開してしまっているのです。

flowchart TD
    A[AIツールをデプロイしたい] --> B[公式ドキュメントに従って起動]
    B --> C{認証設定はデフォルトで?}
    C -->|無効| D[無認証でインターネットに公開]
    C -->|有効| E[安全に稼働]
    D --> F[APIキー露出・ワークフロー閲覧]
    D --> G[無断でモデルを利用される]
    D --> H[任意コード実行のリスク]
    F --> I[セキュリティインシデント]
    G --> I
    H --> I

よくある失敗パターンと対処法

ここでは、Intruder社の調査で明らかになった問題が実際の現場でどのように発生するかを整理し、対処法とともに解説します。

失敗パターン1:開発用設定をそのまま本番に持ち込む

ローカルで動作確認したコンテナ構成ファイルをSCPやGitで本番サーバーにそのままコピーするケースです。OLLAMA_HOST=0.0.0.0 のように全インターフェースへのバインドが残っていると、外部からアクセス可能になります。

対処法:環境変数ファイルを分離し、本番用には必ずバインドアドレスを制限する。

# docker-compose.prod.yml の例
services:
  ollama:
    image: ollama/ollama
    # 本番では localhost のみバインド
    ports:
      - "127.0.0.1:11434:11434"
    environment:
      # APIキーは .env ファイルから読み込む(ハードコード禁止)
      - OLLAMA_API_KEY=${OLLAMA_API_KEY}

失敗パターン2:APIキーをdocker-compose.ymlに直書き

# NG例:絶対にやってはいけない
environment:
  - ANTHROPIC_API_KEY=sk-ant-api03-xxxxxxxxxx
  - OPENAI_API_KEY=sk-xxxxxxxxxx

対処法:.env ファイルに分離し、.gitignore に追加する。

# .env ファイル(Gitに含めない)
ANTHROPIC_API_KEY=sk-ant-api03-xxxxxxxxxx
OPENAI_API_KEY=sk-xxxxxxxxxx
# docker-compose.yml(Gitで管理してOK)
environment:
  - ANTHROPIC_API_KEY=${ANTHROPIC_API_KEY}
  - OPENAI_API_KEY=${OPENAI_API_KEY}

失敗パターン3:n8nやFlowiseをリバースプロキシなしで直接公開

NginxやTraefikを経由せずに直接ポートを公開し、認証設定もしていないケースです。n8nはデフォルトでBasic認証が無効なため、起動しただけでワークフローが丸見えになります。

対処法:必ずリバースプロキシを前段に置き、Basic認証またはOAuth認証を設定する。

# Nginx でBasic認証を追加する例
server {
    listen 443 ssl;
    server_name n8n.example.com;

    # Basic認証
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;

    location / {
        proxy_pass http://127.0.0.1:5678;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

失敗パターン4:rootユーザーでコンテナを実行

Dockerfileやcompose設定でユーザーを指定しないと、コンテナ内のプロセスはrootとして動作します。コンテナエスケープが発生した場合、ホストOSにrootでアクセスされるリスクがあります。

対処法:Dockerfileに非rootユーザーを明示する。

# 非rootユーザーでの実行例
FROM node:20-slim

# 専用ユーザーを作成
RUN groupadd -r appuser && useradd -r -g appuser appuser

WORKDIR /app
COPY --chown=appuser:appuser . .

# 非rootに切り替え
USER appuser

CMD ["node", "server.js"]

自社で今すぐ確認すべきセキュリティチェックリスト


無料AI相談

AIで気軽にWeb相談してみませんか?

詳しく見る

このAI技術、御社の業務にも導入できます

AI導入・業務自動化

ChatGPT活用や業務自動化など、最新のAI技術を御社に合わせてご提案します

200件以上の制作実績 顧客満足度97% 初回相談無料

※ 通常1営業日以内にご返信します

まとめ:「動く」と「安全」は別物だという認識を

The Hacker Newsが2026年5月に報じたIntruder社の調査は、AI導入の波が「利便性」という名の下でセキュリティを危険なほど置き去りにしている現実を、100万台規模のスキャンデータで証明しました。

5,200台超のOllama APIのうち31%が見知らぬ相手にも応答し、90件以上のn8n・Flowiseが政府機関や金融セクターを含む組織でワークフローと認証情報を丸ごと公開していた。これは特定のベンダーや特定の組織の問題ではなく、AIツールを速く使おうとする文化全体の問題です。

"speed is winning, security is lagging behind" ――調査レポートが残したこの言葉は、AI活用を推進するすべての組織に向けた警鐘です。

「ドキュメント通りに動いている」ことと「安全に運用できている」ことは、まったく別の話です。特に自社でAIツールをセルフホストしている場合、今日この記事で挙げたチェックリストをもとに、一度設定を見直すことを強くお勧めします。

Fivenine Designでは、Laravel・Next.jsを活用したWebアプリケーション開発とともに、AIツールの安全な導入・インフラ設計についてもご相談を承っています。「自社のAI基盤が安全かどうか確認したい」「セキュアな構成でAIを導入したい」といったご要望がございましたら、お気軽にお問い合わせください。

この記事をシェア

AI技術の導入・活用をサポートします

業務に合わせたAI活用のご提案が可能です。 初回相談は無料です。

※ 1営業日以内にご返信いたします

この技術でお困りなら

無料でプロに相談できます

相談する
AIに無料相談