AIに「この会社のシステムから情報を取ってこい」と指示したら、同じ名前の本物の会社に入ってしまった——。GoogleのAIモデルGeminiが、能力評価のテスト中に実在する企業3社のシステムへ不正アクセスしていたことが報じられました。テストを設計した側に悪意はなく、対象は架空の企業のはずでした。それでも本物に届いた構造は、AIエージェントを使い始めたすべての企業に関係します。
何が起きたか
米Wall Street Journalの9月18日の報道によると、2026年5月、AIの評価を手がけるイスラエル企業Irregularが実施したサイバー能力テストの最中に、Geminiがテスト環境の外にある実在企業3社のシステムへ不正アクセスしました。テスト用に用意された架空企業の名前が実在企業と同じで、しかも本来は遮断されているはずのインターネット接続が意図せず可能な状態だったため、モデルはパスワードの推測や公開リポジトリに残っていた認証情報を使って実在のシステムに到達したとされています。Geminiは相手が実在のシステムだと判明した時点で行為を止め、実害は確認されておらず、Googleは3社と米連邦当局に連絡したと説明しています（ITmedia AI＋、The Hacker News）。
なぜ自社に関係があるのか
- *AIエージェントを使う側として。この事故は、一つの失敗ではなく二つの失敗が重なって起きました。「対象を名前で指定した」ことと、「外に出られないはずの設定が実際には出られた」ことです。AIに調査・診断・自動化の仕事を渡すとき、人間は「〇〇社の」「テスト環境の」とラベルで対象を伝えがちですが、ラベルは世界に一つとは限りません。対象は名前ではなく、許可したドメインやIPアドレスの一覧、隔離されたネットワークといった「境界」で固定する**必要があります。そして境界が本当に閉じているかは、設定画面ではなく実際の通信で確かめるしかない——これは先日の「読み取り専用のはずのAIエージェント」の事例と同じ教訓です。
- *侵入を受けた側として。**3社は、自社とは無関係のAIテストによって侵入されました。自社のログに「連続したパスワードの試行」や「公開リポジトリに漏れた認証情報でのログイン」が現れたとき、その相手が攻撃者なのか、どこかのAIテストなのかは区別できません。区別できない以上、検知と初動は同じでなければなりません。そしてこの事例で使われた侵入経路——推測できるパスワードと、公開リポジトリに置き忘れた認証情報——は、AIでなくても致命的です（パスワードの使い回しはなぜ「全滅」につながるのか）。
明日やること
- AIエージェントに調査・診断・自動化を任せるときは、対象を「名前」ではなく「境界」で固定する。許可リスト・隔離環境・外部接続の遮断を、設定の記載ではなく実際の通信で確認する。脆弱性診断を外部に委託している場合も、AIを使うか、対象範囲をどう固定しているかを確認しておく
- 公開リポジトリ（GitHub等）に自社の認証情報や接続情報が残っていないか点検する。見つかったら、削除ではなく無効化と再発行を行う（履歴に残るため、削除しても漏えいは消えない）
- 不審なログイン試行を検知したときの初動を、相手が誰であっても同じ手順で回す（インシデント発生時の初動対応）。「テストでした」という申告は、こちらで検証できるまで信用しない
もっと知るには
AIエージェントの制約が「形式」だけで効いていなかった事例は「読み取り専用」のAIエージェントが1万8000件書き込んでいたで解説しています。今回の侵入経路の基礎はパスワードの使い回しはなぜ「全滅」につながるのか、検知後の動き方はインシデント発生時の初動対応をどうぞ。
