Google Geminiが実在3社をハッキング、何が起きたのか？
Googleの生成AI「Gemini」が、サイバーセキュリティ能力を評価するテスト中に、実在する3社のシステムへ権限なくアクセスしていたことが明らかになりました。
事案が発生したのは2026年5月です。
AIセキュリティ企業Irregularが、Geminiに架空企業を対象とした「Capture the Flag」と呼ばれるセキュリティ演習を実施していました。
本来、Geminiがアクセスするのはテスト用の環境だけの予定でした。
しかし、テスト環境から意図せず実際のインターネットへアクセスできる状態になっていたことで、Geminiが現実の企業システムへ到達しました。
Googleなどの説明によると、1件ではGeminiがパスワードを推測して保護されたシステムへアクセス。
別の2件では、インターネット上の公開リポジトリから認証情報を発見し、それを使用して実在企業のシステムへアクセスしました。
ただしGoogleによれば、Geminiはいずれも「これは演習用ではなく実在企業のシステムだ」と認識した段階で、自ら侵入を停止したとしています。
対象となった3社の名称は公表されていません。Googleは被害は発生していないと説明し、対象企業および米国の関係当局へ通知しています。
なぜGoogle Geminiは実在3社をハッキングしてしまったのか？
今回のポイントは、「Geminiが突然、人間に反抗して攻撃を始めた」という話ではありません。
Geminiには、架空企業への侵入テストを成功させるという明確な目的が与えられていました。
ところが、テスト環境から現実のインターネットへアクセスできたうえ、架空企業と同じ名称を持つ実在企業などへ到達できる状況が生まれました。
つまり企業DX担当者が注目すべきなのは、
「AIが悪意を持ったか」ではなく、「AIに与えた目的・権限・ネットワーク環境の組み合わせによって、想定外の実行が現実世界で起きた」
という点です。
AIエージェントが高性能になるほど、単に文章を生成するだけでなく、Web検索、ファイル操作、API利用、システム操作などを自律的に進められるようになります。
そのため、AI自身の性能だけではなく、どこまでアクセスできる環境を与えるのかが極めて重要になります。
Google Geminiの「ハッキング」と「クラッキング」は何が違う？
今回、多くの報道では「Geminiが3社をハッキングした」と表現されています。
日本では、「ハッキング」はコンピューター技術を高度に活用する行為全般、「クラッキング」は悪意を持って不正侵入する行為、と説明されることがあります。
ただし、現在のサイバーセキュリティ実務や海外報道では、両者がそこまで厳密に使い分けられているわけではありません。
米国NISTも「Hacker」について、情報システムへの権限のないアクセスを試みる、または実際にアクセスする利用者という定義を示す一方、セキュリティ改善を目的とする「White Hat Hacker」という表現も使用しています。
したがって、「ハッキング＝必ず犯罪」「クラッキングだけが不正アクセス」という単純な区分ではありません。
今回の記事では、Googleや主要海外メディアの表現に合わせて「ハッキング」としています。
参考： NIST「Hacker」
Google Geminiの3社ハッキングからDX担当者が学ぶべき4つの対策
1．AIエージェントのインターネット接続を必要最小限にする
今回、最も重要なポイントの一つがネットワークです。
テスト環境からインターネットへ接続できなければ、Geminiが実在企業へ到達する可能性は大幅に低下していました。
企業でAIエージェントを導入する場合も、
- アクセス可能なドメイン
- 利用可能なAPI
- 社内ネットワーク
- 本番環境
を必要最小限に限定することが重要です。
2．AIに与える権限と「Blast Radius」を小さくする
AIエージェントへ強力な権限を与えれば、それだけできることは増えます。
しかし、想定外の動作が発生した場合の被害範囲も大きくなります。
「AIが間違えない」ことを前提にするのではなく、「AIが間違えてもここまでしかできない」環境を設計することが重要です。
3．GitHubなど公開リポジトリへ認証情報を残さない
今回の2件では、Geminiが公開リポジトリから認証情報を発見したと報じられています。
これはAIだけの問題ではありません。
APIキー、パスワード、クラウド認証情報などをGitHub等へ誤って公開すれば、人間の攻撃者や自動化されたツールからも発見される可能性があります。
企業では、Secret Scanningや秘密情報管理サービスを活用し、認証情報をソースコードへ直接記載しないことが基本になります。
4．AIの重要操作には人間の承認ポイントを残す
AIエージェントが高度化しても、すべてを完全自動化する必要はありません。
たとえば、
- 外部システムへのログイン
- ファイルの大量取得
- データ削除
- 外部送信
- 本番環境への変更
など、影響の大きい操作では人間による承認を残す方法があります。
AIエージェントの価値は「完全無人化」だけではありません。危険な操作だけ人間が止められる設計も重要です。
Google Geminiの3社ハッキングで一般利用者や企業は対象なのか？
現時点で、一般のGemini利用者やGoogle Workspace利用企業の情報が広範囲に流出したという発表はありません。
今回対象となったのは、セキュリティテスト中にGeminiがアクセスした実在3社です。
3社の名称は公表されておらず、Googleによれば対象企業には直接通知されています。
そのため通常のGemini利用者が「自分も被害対象なのではないか」と考える種類の情報漏えい事故とは性質が異なります。
Google Geminiの3社ハッキングで補償はあるのか？
2026年9月19日時点で、今回の事案に関連して一般利用者向けの補償制度や返金などは発表されていません。
Googleは3社に実害は生じなかったと説明しています。
したがって現時点では、一般のGemini利用者に対して補償が必要となる種類の事案とは確認されていません。
まとめ｜Geminiのハッキング事例が示すAIエージェント時代の新しいリスク
今回の事案で、Geminiが自ら実在企業だと認識して侵入を停止したことは、安全機構が一定程度機能した例と見ることもできます。
一方で企業DXの視点では、それだけで安心すべきではありません。
今回明らかになったのは、
高性能なAIエージェントに目的と実行権限を与えた場合、人間が具体的な攻撃手順を一つひとつ指示しなくても、AI自身が方法を探し、現実のシステムへ到達できる段階に近づいている
ということです。
企業でAIエージェントを導入する際には、
- 何をさせるのか
- 何へアクセスできるのか
- どこへ通信できるのか
- どの認証情報を利用できるのか
- どの操作で人間の承認を必要とするのか
まで設計する必要があります。
AIエージェント時代のセキュリティでは、「AIを賢くすること」と同じくらい、「AIをどこまでしか動けないようにするか」が重要になるでしょう。