投稿者 global-ai-media 
生成AIのセキュリティ議論は「プロンプトインジェクション」や「誤情報の生成」に集中しがちですが、今まさに攻撃者が狙っているのはより原始的で致命的な「インフラの無防備な露出」です。最新の観測データが示す脅威の実態と、PoC（概念実証）や社内導入を急ぐ日本企業が陥りやすいセキュリティの死角について解説します。
LLMエンドポイントへの無差別スキャンが急増中
サイバーセキュリティ企業のGreyNoiseが公開した最新のデータによると、直近のわずか11日間で、大規模言語モデル（LLM）のインフラを標的とした80,000回以上のスキャン活動がハニーポット（攻撃観測用のおとりシステム）によって検知されました。
これは特定の企業を狙った標的型攻撃というよりも、インターネット上に無防備に公開されているLLM関連のサーバーやAPIエンドポイントを洗い出すための「自動化された探索活動」である可能性が高いと考えられます。攻撃者は、開発者がテスト用に立ち上げたサーバーや、設定不備のまま稼働している推論サーバーを探し求めています。
「モデルの脆弱性」と「インフラの脆弱性」の違い
AIセキュリティの文脈では、これまで入力プロンプトを工夫してAIから不適切な回答を引き出す「プロンプトインジェクション」や「ジェイルブレイク（脱獄）」が注目されてきました。しかし、今回検知された脅威はそれとは異なります。
ここで問題になっているのは、OllamaやvLLM、あるいは各種Vector DB（ベクトルデータベース）といった、LLMを動かすためのミドルウェアやインフラそのものです。これらは開発の利便性を重視して設計されていることが多く、デフォルト設定では認証機能が無効になっていたり、ネットワーク制限がかかっていなかったりするケースが少なくありません。
もし、社内の機密データを学習させたモデルや、RAG（検索拡張生成）用のナレッジベースが接続されたサーバーが外部からアクセス可能になっていれば、プロンプトを工夫するまでもなく、データやモデルそのものが盗み出されたり、踏み台として悪用されたりするリスクがあります。
日本企業における「PoC貧乏」とシャドーAIのリスク
日本国内でも、機密情報保持の観点からOpenAIなどのパブリックAPIを利用せず、自社環境（オンプレミスやプライベートクラウド）でオープンソースのLLMを運用しようとする動きが活発です。
ここで懸念されるのが、現場主導のDX（デジタルトランスフォーメーション）推進に伴うリスクです。エンジニアやデータサイエンティストが、PoC（概念実証）のためにクラウド上のインスタンスで一時的にLLMサーバーを立ち上げ、ファイアウォールの設定を甘くしたまま放置してしまうケースは珍しくありません。
特に日本では、IT部門の厳格な管理下を離れ、事業部門が独自にAI活用を検証するケースが増えています。こうした「シャドーAI」環境では、エンタープライズレベルのセキュリティ（認証、ログ監視、ネットワーク分離）が後回しにされがちであり、今回のGreyNoiseの報告にあるようなスキャンの格好の標的となります。
日本企業のAI活用への示唆
AIの民主化が進む中、日本企業は「AI倫理」や「著作権」といったソフト面のリスクだけでなく、古典的かつ物理的な「インフラセキュリティ」に立ち返る必要があります。実務的な対応策として、以下の3点が重要です。
1. AIインフラの資産管理と可視化
社内のどの部門が、どのクラウドやサーバーでLLMを稼働させているかをIT部門が把握する仕組みが必要です。PoC終了後に放置された「ゾンビサーバー」が攻撃の入り口になる事例は枚挙にいとまがありません。
2. デフォルト設定への過信を捨てる
多くのオープンソースLLMツールは「すぐに動くこと」を優先しており、「安全であること」は二の次です。社内ネットワーク内であっても、APIエンドポイントには必ず認証（Basic認証やAPIキー、mTLSなど）を導入し、VPNやIP制限でアクセス元を絞るという基本動作を徹底する必要があります。
3. ガバナンス・ガイドラインの具体化
「AI利活用ガイドライン」を策定している企業は増えていますが、「入力データの内容」に関する規定が中心です。今後は、「LLMをホスティングする場合のセキュリティ要件（ポート開放の禁止、認証の必須化など）」といった、インフラ運用レベルの具体的な基準を盛り込むことが、予期せぬ情報漏洩を防ぐ鍵となります。