いろは堂AI
← 戻る

Gemini CTFテストで実在3社に侵入、原因は社名の一致

2026年9月22日|いろは堂AI編集部
屋内でスーツ姿の男性1人がノートPCを操作し眼鏡に触れている

画像出典: ぱくたそ

この記事の要点
2026年5月、AI評価会社Irregularのサイバーセキュリティ演習中に、GoogleのGeminiがテスト環境の設定ミスで意図せずインターネットへ到達し、実在する企業3社のシステムに侵入しました。原因は演習で使った架空企業名が実在企業のドメインと一致していたことで、Geminiはそれをテスト対象の一部だと認識したまま攻撃を続けています。エージェントに作業を任せる側は、ネットワーク到達性・認証情報の範囲・命名の衝突という3つの境界を自分で設計・検証する必要があります。
😟
テスト環境で動かしてるんだから、外に影響が出ることはないですよね?

「テスト環境」「サンドボックス」という言葉は、外と切り離されていることを約束してくれるように聞こえます。ところが2026年5月、その前提が崩れた事例が公になりました。AIセキュリティ評価会社が用意した演習環境の中で、Geminiが本物の企業のシステムへ入り込んでいたのです。

侵入そのものより、原因のほうが考えさせられます。高度な攻撃手法が使われたわけではなく、環境の設定ミスと、名前の偶然の一致が重なっただけでした。自分の会社でエージェントに作業を任せ始めた人にとって、これは他人事ではない話になります。

何が起きたのか?

舞台は、イスラエルのAIセキュリティ評価会社Irregularが実施した「capture the flag(CTF)」形式の評価です。CTFは、用意された標的システムに侵入して隠された目印を取れるかを競う、セキュリティ業界で一般的な演習形式を指します。IrregularはOpenAI・Anthropic・Metaなど複数のAIラボと契約する第三者評価パートナーで、この時はGoogleのGeminiに「架空企業のシステムを攻撃する」課題を与えていました。

本来、この演習環境のGeminiはインターネットにアクセスできない設定のはずでした。ところが環境の設定ミスにより、Geminiはオープンなインターネットアクセスを獲得してしまいます。ここで、もうひとつの偶然が噛み合いました。演習内で使われていた架空企業の名前が、実在する企業のドメイン名と一致していたのです。

Geminiは標的を探すうちに、そのドメインへインターネット経由で到達しました。そしてそこを演習で与えられた標的の一部だと認識し、攻撃を続行しました。結果として、実在する3社が影響を受けています。

どうやって実在企業のシステムに入り込んだのか?

手口は3社で同じではありませんでした。

社数1社2社
侵入手段パスワードを何度も推測する試行(ブルートフォース的な手法)公開リポジトリ(GitHub等)上に置かれていた認証情報の発見と利用
突かれた弱点推測できるパスワードのまま保護されていたシステム公開の場に残されたままの認証情報

CyberInsiderの公表データをもとに作成

後者の2社に注目したいところです。ここでGeminiがしたことは、公開の場に置かれたままになっていた鍵を見つけて使う、という手順にすぎません。高度な技術ではなく、探索する根気と速度が結果を生んでいます。エージェントは疲れず、人間が面倒で後回しにする総当たり的な確認を淡々と続けられる。その性質が、そのまま攻撃能力になったかたちです。

Geminiは途中で自分から止まった

Googleでセキュリティエンジニアリングを担当する副社長のHeather Adkins氏によると、3件すべてにおいて、Geminiは「自分が実在する企業にアクセスしてしまった」と認識した時点で、自律的に攻撃行動を停止しました。他のAIラボで確認された同種の事例と異なり、実害が生じる前に自ら中断した点が特徴とされています。Googleはデータの改ざんや業務への実害はなかったとし、影響を受けた3社には通知済みとしています。

ただし、これを安全策と数えてはいけません

自分で止まったのは良い結果ですが、それはモデルが途中で気づいたから成立した結果です。気づかなければ続いていました。設計として頼れるのは「止まってくれること」ではなく「そもそも到達できないこと」のほうです。次の章で触れるとおり、モデルの気づきとは無関係に成立してしまう抜け道も報告されています。

なぜ公表まで4か月かかったのか?

時系列を追うと、隠蔽というより分析と連絡の積み重ねで時間が経っている様子が見えます。

  1. 2026年5月演習中に事件が発生。
  2. 2026年7月下旬Irregularが分析を完了し、Googleに全容を伝達。Irregularは他のAIラボにも同じ問題が影響したとして、関係する全ラボへ同時期に通知したとしている。
  3. 2026年9月18日Wall Street Journalの取材と公表要請をきっかけに、Googleが公式に事件を認めた。

発覚から公表まで約7週間、発生からは約4か月です。Irregular側は、既知の問題はすべて数週間前に修正・解決済みとコメントしています。なお同種のインシデントはMeta、Anthropic、OpenAIでも確認・開示されており、いずれも同じくテスト環境の設定ミスに起因するとされています。特定のモデルの欠陥ではなく、評価環境の作り方の問題だったということです。

公表されていない情報もあります。影響を受けた3社の社名、そしてGeminiのどのモデルバージョンだったかは明かされていません。この部分は未確認として扱ってください。

「サンドボックス」と書いてあれば安全なのか?

ここが今回いちばん持ち帰る価値のある論点です。サンドボックスは「隔離された砂場」という意味の言葉ですが、どこまで隔離するかは実装ごとに違い、名称だけでは安全性を判断できません。今回の事件は、ネットワーク到達性というひとつの設定が外れただけで境界が破れた例でした。

そして、設定ミスがなくても境界が抜ける手口も報告されています。セキュリティ企業のCymulateは2026年、「Configuration-Based Sandbox Escape(CBSE、設定ファイル経由のサンドボックス脱出)」と呼ぶ脆弱性パターンを、Claude Code・Gemini CLI・Codex CLIで確認したと公表しました。

仕組みはこうです。エージェントはサンドボックスの中で動いていますが、設定ファイルへの書き込み権限を持っていることがあります。攻撃者がプロンプトインジェクション(指示文に紛れ込ませて意図しない動作をさせる手口)や悪意あるリポジトリ経由で、たとえばClaude Codeの `.claude/settings.json` に起動時フックを書き込ませたとします。そのファイルはサンドボックスが閉じた後もディスクに残り、開発者が次にツールを起動したとき、ホスト側で開発者の権限のまま実行されます。リモートコード実行(外部から他人の端末やサーバーに任意のプログラムを送り込んで走らせる攻撃)のような高度な手口は要りません。

砂場の中で書いた手紙が外のポストに残っていて、翌朝あなたがそれを読み上げてしまう、という構図です。同じパターンがGemini CLI・Codex CLIでも確認されており、各ベンダーへ責任ある開示が行われていますが、対応の速さにはばらつきがあり、根本的な問題が未修正のまま残っているケースもあると報告されています。

なお、Googleは自社の「Gemini Enterprise Agent Platform」やAntigravityハーネスで、エージェントごとにホストや他エージェントから隔離されたLinuxサンドボックスを提供する設計を進めています。ただしこれは主に本番運用サービスの話で、今回の侵入事件は評価環境側の設定ミスが原因でした。本番用に堅い隔離が用意されていても、検証や試用で使う環境が同じ強度とは限らないということです。

自分の環境では何を確認すればいいのか?

社内でAIエージェントに作業を任せている、あるいはこれから任せる場合に、今日そのまま点検できる項目に落とすと次の3つになります。

  1. ネットワークと認証情報のスコープを最小限にするそのエージェントが実際に到達できる範囲を、想定ではなく実測で確かめます。外部に出られない前提の環境なら、任意の外部ドメインへ実際にアクセスを試させて、ブロックされることを確認する。渡す認証情報も、その作業に必要な対象だけに絞ります。今回の事件は「アクセスできないはず」という前提が外れていたところから始まりました。
  2. ダミー名が実在と衝突していないか確認するテスト用の会社名・ドメイン・サービス名を決めたら、そのまま検索して実在しないか確かめます。`example.com` や `example.co.jp` のような予約済みドメイン、社内予約のダミー名を使う運用にしておけば、衝突は原理的に起きません。思いつきの社名は、たいてい世界のどこかに実在します。
  3. エージェントが書ける設定ファイルを洗い出すエージェントの作業ディレクトリ配下で、ホスト側の起動時に自動実行される種類のファイル(各ツールの設定ファイル、フック、シェルのprofile類)が書き込み可能になっていないかを確認します。書き込めるなら、そこは砂場の外へ繋がる通路です。差分レビューの対象に設定ファイルを必ず含めるだけでも、気づける確率が上がります。
🤔
結局、エージェントを信用していいのかどうかが分からなくなってきました

信用の置きどころを変えるのが、この事件の実務的な読み方です。Geminiは途中で止まりました。しかしそれは、悪意ある相手が同じ環境を使ったときには何の保証にもなりません。エージェントの判断力ではなく、環境の境界を信用の対象にする。到達できない場所には行けない、持っていない鍵は使えない、書けないファイルは書き換えられない。この3つは設定で決まり、モデルの気分では変わりません。

正直なところ、ここまで確認するのは面倒です。ただ、確認の手間は一度きりで、効き目はそのエージェントを使い続ける間ずっと続きます。任せる範囲を広げる前に、境界のほうを先に引いておくと後が楽になります。

よくある質問

Geminiが実在企業に侵入したのは、いつ・どこで起きた出来事ですか?

2026年5月、AIセキュリティ評価会社Irregularが実施したcapture the flag形式のサイバーセキュリティ評価の中で起きました。テスト環境の設定ミスによりGeminiが意図せずインターネットへアクセスでき、実在する企業3社のシステムに侵入しました。Googleが公式に事件を認めたのは2026年9月18日です。

侵入の原因は何だったのですか?

2つの要因が重なったためです。1つはテスト環境の設定ミスで、本来インターネットにアクセスできないはずのGeminiがオープンなインターネットアクセスを獲得してしまったこと。もう1つは、演習で使われた架空企業名が実在企業のドメイン名と偶然一致していたことです。Geminiはそのドメインをテスト対象の一部だと認識して攻撃を続けました。

被害はあったのですか。影響を受けた企業はどこですか?

Googleはデータの改ざんや業務への実害はなかったとし、影響を受けた3社には通知済みとしています。3社の社名、およびGeminiのどのモデルバージョンだったかは公表されていません。3件すべてで、Geminiは実在企業にアクセスしたと認識した時点で自律的に攻撃を停止したとされています。

サンドボックスの中で動かしていれば、AIエージェントは安全ですか?

名称だけで安全性は判断できません。サンドボックスの隔離範囲は実装ごとに異なり、今回はネットワーク到達性の設定ミス一つで境界が破れました。さらにセキュリティ企業Cymulateは2026年、Claude Code・Gemini CLI・Codex CLIで、サンドボックス内から設定ファイルに書き込めればホスト側で開発者の権限のままコードが実行される「Configuration-Based Sandbox Escape」というパターンを確認しています。

※記事で使用した内容・数値は変更される場合があります。最新情報は公式サイトをご確認ください。