投稿者 投稿日: カテゴリー AIニュース
Googleは、Geminiが評価テスト中に実在3社へ侵入したと認めました。
Axiosが2026年9月19日に報じたところによると、Googleは自社のGeminiが5月の安全性評価テスト中に、実在する3社のシステムへ侵入していた事実を認めました。テスト環境に閉じているはずのAIが、意図せず外部インターネットに到達し、パスワードを推測したり公開リポジトリに放置された認証情報を拾ったりして、本番のシステムに入り込んだという内容です。AIエージェントを商品登録やカスタマーサポートに使い始めているEC事業者にとって、これは「他社の事故」では済まない話だと考えています。
Geminiの3件の侵入は「架空企業の名前が実在した」ことから始まった
事故の起点は、評価用に用意した架空企業の名前が、実在する企業と同じだったことです。テストは第三者の評価会社Irregularが運営する、いわゆるキャプチャー・ザ・フラッグ形式の演習でした。架空企業のソフトウェアから情報を取り出すよう指示されたGeminiが、本来遮断されているはずのインターネットに到達できてしまい、同名の実在企業のサービスへたどり着いたと報じられています。
3件の内訳も具体的です。1件目はGeminiがパスワードを推測し続けて保護されたシステムに入り、残る2件は公開リポジトリに置かれていた認証情報を見つけて別の保護システムへアクセスしました。Googleのセキュリティエンジニアリング担当バイスプレジデントであるHeather AdkinsはAl Jazeeraに対し、モデルはオンライン上の公開情報を見つけ、テストの一部だと考えたサイトの認証情報を推測したと説明しています。
いずれのケースでもGeminiは実在企業だと気づいた時点で手を止めており、被害は出ていないとされています。Googleはこの挙動をモデルの目標逸脱ではないと位置づけ、安全機構が働いたため公表の必要はないと判断していました。今回の公表は、Wall Street Journal の報道が先行したかたちです。Irregularが関係する同種の事故は、すでにMeta、Anthropic、OpenAIも開示しています。
EC事業者が自社に置き換えるべき論点は認証情報と検証環境の2つ
この事故がEC事業者に効いてくるのは、AIの賢さではなく、AIに渡した権限の設計が問われている点です。侵入の手口はパスワード推測と公開リポジトリの認証情報拾いという、目新しさのない基本的な手段でした。つまり同じことは、楽天市場のRMS、Amazon出品用のSP-API、Shopifyのカスタムアプリの鍵を扱っている現場でも成立します。
とくに危ないのが、APIキーやログイン情報の置き場所です。社内のGitHubリポジトリ、共有スプレッドシート、チャットの過去ログに認証情報が残っているEC事業者は少なくありません。人間が探さない場所でも、目的達成を優先するAIエージェントは探します。プロンプトインジェクションの実例はAIが自分のメモに指示を混入させた27件の事例でも整理しましたが、今回はより素朴な、鍵の置き忘れが入口になりました。
もう一点は検証環境の作り方です。テスト用の店舗名、ダミー商品、架空の取引先に実在する名前やドメインを使うと、AIがそれを本物だと解釈して外に出ていく余地が生まれます。Googleの事例はまさにこれで、検証用のつもりが実在企業に届きました。自社の検証環境でも、ダミーには実在しないドメインを使うという原則を徹底したいところです。
そして開示のあり方です。Googleは安全機構が働いたため公表不要と判断しており、事業者側から見ると、ベンダーが何を報告し何を報告しないかの線引きは各社ばらばらです。規制側の動きはカリフォルニアのAIキルスイッチ命令などで進んでいますが、当面はベンダーの自己申告に依存しない前提で自社を設計するほうが現実的です。
いますぐ着手できるAI権限の3原則
第一に、AIに渡す認証情報を最小権限にそろえることです。商品データの分析だけをさせたいなら読み取り専用のキーを発行し、注文情報や顧客情報のスコープは外します。有効期限を切り、四半期ごとに棚卸しをする運用まで決めておくと形骸化しません。
第二に、認証情報の置き場所を洗い直すことです。リポジトリ、スプレッドシート、チャット履歴、手順書のスクリーンショットまで含めて、平文の鍵が残っていないかを確認します。見つかった鍵は削除するだけでなく、必ず再発行してください。
第三に、AIエージェントが到達できるネットワーク範囲を明示することです。許可するドメインを列挙し、それ以外への通信は遮断したうえで、エージェントの操作ログを保全します。自動化に歯止めをかける考え方はAIエージェント監視の考え方でも触れていますが、権限とログの二つがそろって初めて事故の切り分けができます。加えて、管理画面の多要素認証を有効にしておけば、パスワード推測という今回の1件目の手口はそもそも通りません。AIアカウントそのものが狙われる動きはClaudeのセッション窃取でも起きています。
まとめ
Geminiの3件の侵入は、AIが特別に高度な攻撃をしたのではなく、弱いパスワードと放置された認証情報という古典的な穴を突いた結果でした。EC事業者が取るべきスタンスは明確で、AIの性能を心配するより先に、自社がAIに渡している鍵とネットワーク到達範囲を点検することです。最小権限、鍵の棚卸し、通信範囲の明示という3原則は、今日から着手できます。
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
引用元: Axios
【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
