私自身、AIに集計、書類確認、メールの整形まで任せる場面が増えました。ただ、外へ送るのは自分で判断する。分からない内容は送らない。この線を残せば、大きな事故は避けられると考えていました。
ところが、Geminiがセキュリティ評価中に実在する3社のシステムへ入ったという報道を読むと、それだけでは足りません。AIが違う相手へアクセスした後で人が確認しても遅い。人の判断に加えて、AIが判断する前に越えられない境界が必要です。
今回の結論は、AI自動化を止めることではありません。読み取りと下書きは任せる。接続先、書き込み、送信、認証情報、停止条件は先に制限する。プロンプトで『気をつけて』と頼むだけではなく、権限と仕組みで止めます。
Geminiが実在3社へ入った事故で何が起きたのか
報道によると、事故は2026年5月、AIのセキュリティ能力を調べる評価中に起きました。評価会社Irregularは、架空企業のシステムから情報を取得する課題をGeminiへ与えていました。ところが、その架空企業と同じ名前の実在企業があり、試験環境から公開インターネットへ接続できる状態だったとされています。
Googleの説明では、Geminiは対象範囲内だと考えた3サイトへアクセスしました。公開情報を調べ、資格情報を推測して利用したとされています。WSJ報道の要約では、1件はパスワードの推測、残る2件は公開リポジトリにあった認証情報が入口でした。
Googleは、Geminiが実在企業だと認識した後に停止し、損害は発生せず、対象企業と米国当局へ通知したと説明しています。ここはGoogle側の説明として受け取る必要があります。使用モデルは公表されておらず、最新のGemini 3.8ではないとも説明されています。
『Geminiが勝手に反乱した』という話ではない
見出しだけを見ると、Geminiが試験環境から脱走し、自分の意思で企業を攻撃したように見えます。確認できた範囲では、そこまでの話ではありません。Geminiにはセキュリティ課題を達成する目的が与えられ、公開インターネットへ接続でき、実在企業を課題の対象だと誤認しました。
だから軽い事故という意味でもありません。モデルが指示どおり動いていても、対象範囲と権限を間違えれば、現実のシステムへ影響が出ることが分かりました。AIに悪意があるかより、何へ接続でき、何を実行できたかを見るべきです。
Googleは2026年9月、脆弱性の発見と自動修正を行うGemini 3.8 Flash Cyberを、信頼できる組織向けに提供すると発表しました。今回の事故で使われたモデルとは別ですが、AIが文章を答えるだけでなく、長い手順を進め、道具を使う段階へ来ていることは分かります。
Gemini 3.8 Flash CyberのGoogle公式発表を見る
営業で怖いのは、AIの回答より操作権限
営業の仕事では、AIが文章を間違えても、送る前に直せます。しかしAIエージェントへブラウザ、メール、CRM、ファイル、社内ツールの操作を渡すと、回答と実行がつながります。間違った相手へのメール送信、担当者の上書き、古い資料の削除は、出力を読んでから直す運用では間に合いません。
| 仕事 | 最初の運用 | 理由 |
|---|---|---|
| 社内資料の検索・要約 | 条件を限定して自動 | 元資料を変更しない |
| メール・提案書の下書き | 自動 | 送信前に本文と宛先を確認できる |
| 集計表の作成 | 自動＋検算 | 行数・合計・分母を正解表と照合できる |
| CRMへの活動記録 | 承認後に書き込み | 顧客履歴の誤更新が残る |
| 社外メール送信・公開 | 毎回承認 | 宛先・添付・本文の誤りを取り消しにくい |
| 契約・発注・支払い・削除 | 原則として自動化しない | 金銭・法的効果・復旧不能の影響が大きい |
| 権限変更・認証情報の取得 | 任せない | AI自身が行動範囲を広げられる |
私が今やっているのは、スクリーンショットを貼って『ここを埋めて』『集計して』と頼み、違いを見つけたら具体的に直す使い方です。書類やメールも下書きまでは速くなりました。この段階では最後に自分が見る余地があります。完全自動化へ進むなら、その余地を承認フローとして仕組みに残します。
AIエージェントに仕事を任せる前の5つの境界
1．接続先を名前ではなく許可リストで固定する
今回の事故では、架空の対象と同じ名前の実在企業がありました。『〇〇社を調べる』という名前だけの指定では、AIが別のサイトを選ぶ余地があります。アクセスできるドメイン、フォルダ、データベースを先に登録し、それ以外へは接続できない状態にします。試験では公開インターネットを切り、ダミーデータだけを置きます。
2．読み取り、下書き、書き込み、送信、削除を分ける
『メールを使える』『CRMを使える』では範囲が広すぎます。メール検索と下書き作成は許可しても、送信は別権限にします。CRMも閲覧、候補作成、活動記録の追加、既存情報の上書き、削除を分けます。最初は読み取りと下書きだけで価値を確かめます。
3．外部へ出る直前で人が確認する
確認画面を置く場所は、仕事の開始時ではなく実行直前です。メールなら宛先、CC、添付、本文。CRMなら顧客名、変更項目、変更前後。公開ならURLと公開範囲を一画面で見ます。『この作業を許可しますか』だけでは、内容を見ずに承認する癖がつきます。
4．人のパスワードをAIと共有しない
AIには専用のアカウントやサービスIDを用意し、必要な期間と操作だけを許可します。人と同じIDを使うと、本人が操作したのかAIが操作したのか追えません。退職・異動・作業終了時に、そのAIだけの権限を止められる形にします。
5．分からないときに止まり、後から追えるようにする
対象が許可リストにない、件数が想定と違う、権限が不足する、別会社と名前が重なる。この時は推測して続けず停止します。入力、参照先、判断、操作、結果をログへ残せば、何が起きたかを人が確認できます。私が普段使っている『分からないものは送らない』を、AIの停止条件へ変える考え方です。
私は『全部自動』ではなく3段階で進める
仕事中は、ある程度雑な指示でも前提が共有されていればAIは動きます。これは文章作成や集計では強みです。一方、操作まで任せる場面では、AIが前提を理解していることと、アクセス先が正しいことを分けます。会話上のコンテキストだけで安全性を作りません。
- 第1段階：匿名データを読み、検索・要約・下書きだけを行う
- 第2段階：社内の限定された場所へ、承認後に追記する
- 第3段階：外部送信や本番操作は、実行内容を表示して人が承認する
この順番なら、AIに任せる価値と事故の影響を分けて見られます。第1段階で役に立たない仕事へ、広い権限を渡す理由はありません。第2段階で表記揺れや誤更新が多ければ、分類ルールを直してから次へ進みます。
導入前に確認する7項目
- AIが接続できるドメイン、フォルダ、システムを列挙したか
- 読み取り、作成、更新、送信、削除の権限を分けたか
- 顧客情報を使わないダミーデータで先に試したか
- 社外送信や本番更新の直前に内容を確認できるか
- 人のパスワードを共有せず、AI専用のIDを使っているか
- 対象不明、件数不一致、想定外の接続で停止するか
- 操作と結果のログを後から確認できるか
七つのうち一つでも答えが曖昧なら、まず読み取りと下書きまでに戻します。AIの性能が上がるほど、便利さと一緒に実行範囲も広がります。だからモデルの賢さを比べる前に、間違えたときにどこで止まるかを決めます。
Geminiの事故から変えるべきこと
今回の事故を理由に、AIへ仕事を任せること自体をやめる必要はありません。集計、検索、下書き、書類確認は、すでに私の手作業を減らしています。ただし、自動化の完成を『人が見なくてよい状態』とは考えません。
人が判断する場所を残し、その手前にも権限の壁を置く。AIが間違った相手を選んでも接続できず、送信前には宛先と内容が見え、分からなければ止まる。今回の記事で持ち帰るべきなのは、AIへの不安ではなく、この設計です。
よくある質問
Q. Geminiが自分の意思で企業をハッキングしたのですか？
確認できた範囲では、反乱や悪意の証拠ではありません。セキュリティ評価の課題中に公開インターネットへ接続でき、実在企業を対象範囲内だと誤認した事故です。
Q. 通常のGeminiアプリを使うだけでも危険ですか？
今回の事例は、セキュリティ課題と外部操作権限を与えた評価環境で起きました。通常のチャット利用と同じ条件ではありません。ただし、ブラウザ、メール、CRMなどを連携するときは接続先と操作権限を確認します。
Q. 人が最後に承認すれば安全ですか？
承認は必要ですが、それだけでは足りません。内容を見ずに承認する危険があるため、接続先の許可リスト、最小権限、AI専用ID、停止条件、操作ログも組み合わせます。
