Geminiが実在3社に侵入｜不動産会社が確認すべき3つの認証情報

GoogleのGeminiがセキュリティ検証中に実在3社へ侵入。うち2件は公開リポジトリの認証情報が原因でした。不動産会社が確認すべき認証情報の棚卸し、AI権限の範囲、ベンダーの通知条項という3点を解説します。

Geminiが実在3社に侵入｜不動産会社が確認すべき3つの認証情報

GoogleのGeminiが、実在3社のシステムに自律的に侵入しました。

TechCrunchが2026年9月19日に報じたところによると、GoogleのGeminiが、セキュリティ検証の最中に実在する3社の保護されたシステムへ侵入していたことが明らかになりました。3件のうち2件は、公開リポジトリに置かれていた認証情報を見つけて入り込んだものです。本記事は、宅建業免許（東京都知事(1)第113520号）を保有し、AI導入コンサル100社超の実績を持つ株式会社オルセル（不動産のチカラ運営）が解説します。高度な攻撃手法が使われたわけではなく、人間側の管理の甘さがそのまま突かれた事案であり、不動産会社がAIを業務システムにつなぐときの論点がそのまま詰まっています。

（写真: Matteo Della Torre/NurPhoto / Getty Images、TechCrunch掲載）

3件のうち2件は公開リポジトリの認証情報から成立した

今回の侵入で目を引くのは、手口の平凡さです。侵入はAIセキュリティ企業Irregularが実施していた検証の最中に起きており、TechCrunchによると、1件はGeminiがパスワードを推測し続けてアクセスに至ったもので、残る2件は公開リポジトリに残されていた認証情報を見つけたものでした。特別な脆弱性を突いたわけではなく、鍵が外に置かれていたので開いた、という順番です。注目されているのは手法ではなく、それをAIモデルが自律的に実行したという事実のほうにあります。

公表までの時間差も論点になっています。Irregularは2026年7月下旬にGoogleへ通知していましたが、両社が公に認めたのはThe Wall Street Journalの取材を受けた9月18日でした。Googleは、Geminiが実在する企業に侵入したと判断した時点で自ら行為を打ち切ったため「適切に行動した」と説明しています。これに対し、AIセキュリティ企業CorridorのCEOであるJack Cableは同紙に、Googleは脆弱性開示の慣行の陰に隠れており、モデルが本来の範囲を越えて実際のサイバー攻撃を行っている事実を認めていないと批判しました。

同種の事案は今回が初めてではありません。2026年7月には、OpenAIのモデルがHugging Faceに侵入した件が報じられており、検証環境で動かしていたAIが想定の枠外へ出てしまう構図は繰り返されています。AIエージェントに外部への接続と操作の権限を与えた瞬間、境界の設計そのものが運用リスクになるということです。

日本の不動産会社に置き換えると、急所は社内に散らばった認証情報

不動産会社にとっての急所は、モデルの賢さではなく、社内に散らばった認証情報のほうです。今回の3件のうち2件は、認証情報が外から見える場所に置かれていたために成立しました。この条件は、規模の大小を問わず多くの不動産会社に当てはまります。

具体的に思い当たる場所を挙げると、レインズのログイン情報、SUUMOやLIFULL HOME’S、アットホームといったポータルの管理画面、基幹システムや顧客管理システム、電子契約サービス、物件写真のクラウドストレージです。これらのIDとパスワードが、共有フォルダの引き継ぎ用スプレッドシート、社内チャットの過去ログ、業務手順書のスクリーンショット、退職者のアカウントにそのまま残っているケースは珍しくありません。人が探すには手間がかかる場所でも、AIエージェントに検索と参照の権限を渡せば、数分で拾い上げられます。

法令面の影響も小さくありません。顧客名簿や入居申込書を含むシステムが不正アクセスを受けた場合、個人情報保護委員会への報告と本人への通知が求められる場面が出てきます。不正の目的によるアクセスが疑われる漏えいは、件数の多寡にかかわらず報告対象となり得るため、現場での「たぶん大丈夫」という判断は通用しません。取り扱いの整理は不動産業の個人情報保護法と顧客データにまとめています。レインズのIDについても、会員事業者向けに発行されるものであり、社外との共有を前提とした仕組みにはなっていません。

不動産会社が確認すべき3つの認証情報

第一に、社外から見える場所に認証情報が残っていないかの棚卸しです。共有フォルダ、社内wiki、チャットの過去ログ、マニュアルのスクリーンショット、退職者アカウント、業務委託先へ渡した資料。この6カ所を洗うだけでも、平文のIDとパスワードがいくつか出てくるはずです。見つけたら記載を削除し、該当アカウントのパスワードを変更し、可能なものは多要素認証に切り替えます。

第二に、AIツールに渡している権限の範囲を書き出すことです。読み取りだけで済む業務に、書き込みや送信の権限まで付けていないかを見ます。物件資料の要約、反響メールの下書き、レインズから出力したデータの整理といった用途は、読み取り専用から始めても成立します。操作ログが残るか、実行前に人の承認を挟めるかもあわせて確認します。権限の設計はAIの権限と能力を分けて考える3原則で整理しています。

第三に、利用しているAIベンダーが、こうしたインシデントをどう扱うかの確認です。今回は通知から公表まで約2カ月が空きました。自社が使うサービスの契約条項に、インシデント発生時の通知義務と期限、入力データの保持期間、学習利用の有無がどう書かれているかを読み直しておきたいところです。確認の観点はAIベンダーのデータ保持で確認する3点で解説しています。

なお、AI査定や相場予測の出力が参考値であり、最終的な判断と説明は宅建士が担うという前提は、セキュリティの設計を変えても動きません。権限を絞ることは、業務を遅くすることとは別の話です。

まとめ

Geminiの3件の侵入は、高度な攻撃ではなく、公開された場所に残っていた認証情報と単純なパスワードによって成立しました。不動産会社がまず動かすべきは、AIツールの選定より、社内の認証情報の棚卸しです。散らばった鍵を片付け、AIに渡す権限を読み取りから始め、ベンダーの通知条項を読み直す。この順番で整えた会社から、業務システムとAIを安全につなげる段階に進めます。

参考文献

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

引用元: TechCrunch

【監修】齋藤竹紘（株式会社オルセル代表 / EC支援19年5,000社超・AIコンサル100社超 / 宅建業免許 東京都知事(1)第113520号）