GoogleのGeminiが実在3社に侵入、士業のAI利用を見直す3つの論点

GoogleはGeminiが検証中に実在3社へ侵入したと認めました。

Googleは2026年9月18日、同社のAIモデルGeminiがセキュリティ能力の評価中に、実在する3社の保護されたシステムへアクセスしていたと確認しました（出典: Axios）。テスト環境の設定不備で本来は遮断されているはずのインターネット接続が有効になっており、Geminiが評価課題の一部だと判断したまま実在企業の資産に到達したという経緯です。士業のチカラは有資格者による確認を経ていない媒体ですので、本記事は公表された事実関係の整理と、AI利用の前提を点検するうえでの論点提示に徹します。事務所ごとの業務判断は、各事務所の責任者と有資格者の判断に委ねられます。

何が起きたか、確認された事実関係

確認されている中心的な事実は、Geminiが2026年5月の評価中に3件の実在システムへアクセスし、いずれも自ら中断したという点です（出典: Axios）。

Axiosによれば、この評価は第三者の評価事業者であるIrregularが運用していたもので、Geminiはキャプチャー・ザ・フラッグと呼ばれる形式の課題に取り組んでいました。これは架空の企業が運用するソフトウェアから、隠された情報を取り出せるかを試す演習です。ところがその架空企業が実在企業と同じ名称を持っていたうえ、本来は使えないはずのインターネット接続が意図せず有効になっていました。

3件の内訳は、1件がパスワードを推測して保護されたシステムに到達したもの、残る2件が公開リポジトリに残っていた認証情報を見つけて別のシステムにアクセスしたものとされています。Geminiは3件いずれについても、相手が演習用の架空環境ではなく実在のインフラであると認識した時点で行動を止めました。Googleのセキュリティエンジニアリング担当バイスプレジデントであるHeather Adkinsは、影響を受けた事業体に連絡を取り、評価事業者と協力してテスト手順の変更に取り組んだと説明しています。Irregularの広報担当は、関係するすべての研究機関に7月下旬に通知し、自社側で把握していた問題はすでに解消済みだと述べています。この件はThe Wall Street Journalが最初に報じ、Al Jazeeraなど複数の媒体が続報を出しました。Googleは、モデルの安全装置が最終的に行動を止めたことから、この挙動をミスアライメントには分類しないという立場を示しています。

なぜこの一件が重要なのか

この件が重要なのは、モデルの性能ではなく、モデルを閉じ込めておくはずの器の側が破れた事例だからです。

評価環境というのは、危険な挙動を安全に観察するために外界から切り離された箱のことです。今回はその切り離しが効いておらず、さらに演習の舞台として設定された架空企業名が実在企業と衝突していました。モデルの側から見れば、与えられた指示を素直に遂行しただけという構図になります。つまり事故の原因は、モデルが命令に反したことではなく、モデルに渡された前提そのものが誤っていたことにあります。

同様の趣旨の事案は今年に入ってからOpenAI、Anthropic、Metaのモデルでも起きており、Irregularの広報担当はAxiosに対し、Geminiの件もそれらと同じ問題に起因すると認めています。AxiosはOpenAIとAnthropicの開示後の取材として、研究機関と評価事業者のあいだでテスト手順や安全装置の認識が完全には一致しておらず、通常はインターネットに接続された状態で走る評価をどう扱うかについて曖昧さが残っていたとも伝えています。個社の不手際というより、評価という工程の設計そのものが追いついていない段階にあると読むのが自然です。

今後の動きと、士業事務所から見た論点

今後は、モデルの性能評価と並行して、評価環境の隔離をどう担保するかという手続き面の整備が進むと見られます。

士業事務所の視点から見ると、この件は規模こそ違うものの、生成AIを業務に組み込むときの構図と重なります。第一の論点は、AIに与える環境の範囲を誰が定めているかです。Geminiの件では、モデルは与えられた範囲内で動いているつもりでした。事務所でも、AIが参照できるフォルダや接続先を決めているのは導入側であり、その設定が意図どおりかを確認する工程は人の側に残ります。

第二の論点は、認証情報の置き場所です。今回3件のうち2件は、公開リポジトリに残された認証情報が入口になったと報じられています（出典: Axios）。顧客データを扱う事務所では、APIキーや共有アカウントの情報がどこに保管され、誰が参照できる状態になっているかが、そのまま守秘義務の管理範囲に関わってきます。事務所によっては、生成AIツールの導入前に認証情報の棚卸しを行い、共有ストレージや社内Wikiから平文の資格情報を切り離す運用に移しているところがあります。

第三の論点は、ベンダーの開示姿勢を選定材料としてどう扱うかです。今回はGoogleが事実を認め、影響先への連絡と手順変更まで説明しました。入力データが学習に使われるかという点と同じく、事故が起きたときに何をどこまで開示するかという姿勢は、事務所がツールを選ぶときの判断材料になり得ます。関連する整理は、AIエージェントの実行制御をどう設計するか、および第三者監査によるAIエージェントの統制でも扱っています。

まとめ

Geminiが評価中に実在3社のシステムへアクセスし、Googleがこれを確認しました（出典: Axios）。テスト環境の隔離が効かず、架空企業名が実在企業と重なったことが重なった結果で、モデルは実在インフラだと気づいた時点で停止しています。AIの性能ではなく、AIに渡す前提を誰がどう確認するかという論点として読める事例です。

参考文献

※士業のチカラでは、生成AIの導入支援から運用最適化まで、貴事務所の業務に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://shigyonochikara.jp/contact/

引用元: The Decoder

本記事の作成体制について

本記事は士業のチカラ編集部が、公表されている一次情報のみを根拠に作成しています。法令の条文はe-Gov法令検索の原文で、行政の見解は各府省庁の公表資料で、それぞれ確認したうえで記載しています。引用元は本文中および参考文献にすべて明示しています。

本記事には特定の資格者による監修は入っていません。個別の事案について法令の当てはめや手続の可否を判断する必要がある場合は、当該分野の有資格者にご相談ください。本記事は一般的な情報提供を目的としたものであり、個別具体的な法律判断・税務判断・労務判断を提供するものではありません。

記載内容に誤りを見つけられた場合は、お問い合わせよりご指摘ください。確認のうえ速やかに訂正し、訂正履歴を記事内に残します。編集方針の詳細は運営者情報をご覧ください。