結論:6月16日以降、管理者はGemini 3.5 Flashを止められなくなる。「モデル単位で無効化して統制する」前提の規程は今週中に見直しが必要だ

Google Cloudの公式リリースノートによると、Gemini Enterpriseの Gemini 3.5 Flashの機能管理トグル(feature management toggle)は2026年6月16日以降、利用できなくなる。以後、Gemini 3.5 FlashはGemini Enterpriseアプリの 全ユーザーでデフォルト有効となり、無効化できない。変更はGlobal・US・EUの各マルチリージョンに適用される。

注目すべきは、撤去期日が 当初の6月8日→6月9日→6月16日と三度変わった末に確定した 経緯だ。組織のポリシー上の理由でトグルをオフにしてきた企業も、6月16日を境にその選択肢を失う。管理者が新モデルの有効/無効を選べない「強制移行」 であり、「リスク評価が済むまで新モデルは無効化しておく」という運用を採ってきた企業ほど影響が大きい。今日6月12日時点で残りは4日。週明けを挟むため、実質の対応猶予は今週中と考えるべきだ。

押さえるべき1点:今回消えるのは機能ではなく「止める自由」だ。AI利用規程やセキュリティ審査が「モデル単位の無効化」を統制手段として前提にしているなら、その前提自体を作り替える必要がある。


何がいつ起きるか:公式リリースノートの時系列

日付(リリースノート掲載日)内容
5月26日管理者はトグルでGemini 3.5 Flashのオン/オフを制御可能と案内。あわせて「6月8日以降トグルは利用不可。6月8日からデフォルト有効・オフ不可」と予告
6月5日適用日を6月9日に変更。「Gemini 3.5 Flashは全ユーザーでデフォルト有効となり、無効化できない」(Global・US・EUマルチリージョン)
6月8日適用日を再変更。「トグルは2026年6月16日以降利用不可」(Global・US・EUマルチリージョン)
6月9日「2026年6月16日以降、Gemini 3.5 Flashの機能管理トグルは利用不可」と最終確定の告知
6月16日トグル撤去。以後デフォルト有効・無効化不可

つまり現時点(6月12日)ではまだトグルが存在し、オフにしている組織ではオフのままだ。6月16日にその状態が強制的に終わる

期日が短期間に三度動いた経緯は、実務上の落とし穴にもなっている。6月5日時点のリリースノートを読んだ担当者は「6月9日に適用済み」と認識し、5月26日時点の告知だけを見た担当者は「6月8日だったはず」と認識している可能性がある。社内で「もう変わった」「まだ先だ」という認識が混在し得る ため、対応状況の確認は最新のリリースノートを正として仕切り直すべきだ。二次記事や社内の伝聞ではなく、リリースノートの原文と管理画面の実際の表示で確認することを勧める。

なお同じリリースノートでは6月9日付で、エージェントをGoogleグループ単位で共有する機能の一般提供(GA)も告知されている。新モデルの強制有効化と共有エージェントの流通拡大が同時に進む構図であり、「いつの間にか新しいAIモデルが使え、いつの間にか誰かの作ったエージェントが部署に流通している」状態が標準になっていく。モデルの統制とエージェントの統制は別の論点だが、管理者にとっては同じ週に同時に動いた変更であり、点検はセットで行うのが効率的だ。


なぜ自社事か:「審査が終わるまで止めておく」という統制手段が使えなくなる

多くの企業のAI利用規程・セキュリティ審査は、「新しいモデル・機能はリスク評価が済むまで無効化しておき、承認後に有効化する」という ホワイトリスト型の統制 を暗黙の前提にしてきた。今回の変更はこの前提を崩す。ベンダー側のロードマップでモデルが自動的に有効化されるなら、統制の軸足は「入口で止める」から 「使われている前提で、データ・ログ・教育で統制する」 に移さざるを得ない。

統制の軸足を移すと言っても、ゼロから作り直す必要はない。見直すべきは多くの場合、①新機能・新モデルの承認手続き、②投入禁止データの定義、③違反時・事故時の対応——の3種類の条項に集約される。このうち①だけが「止める」前提で書かれていることが多く、②③は有効化後も そのまま機能する。

規程の書き換えイメージを示すと、たとえば「新しいAIモデルは情報システム部門の承認後に有効化する」という条項は、もはや実行手段を失う。これを「新モデルは有効化される前提とし、承認が完了するまでの間は機密情報・個人データの投入を禁止する。承認後に利用範囲を拡大する」という形に改めれば、トグルがなくても統制の実質を保てる。止める対象をモデルからデータと用途に移す のが書き換えの基本方針だ。

そしてこれはGoogleに限った話ではない。Microsoft 365 Copilotでもエージェント・機能の自動展開と乱立が管理側の課題になっており、SaaSベンダーがAI機能を既定で有効化していく流れは業界全体で進んでいる。今回のトグル撤去は、その流れが「管理者の選択権の撤去」まで踏み込んだ事例として、Gemini Enterprise利用企業以外にとっても自社事の予告編である。

これは部門ごとの野良AI・シャドーAIが乱立する失敗とも地続きの問題だ。承認外のツールを社員が勝手に使うのがシャドーAIだとすれば、今回は 承認プロセスを経ていないモデルがベンダー都合で社内に配られる という、いわば「公式経路のシャドーAI化」である。利用規程の作り方はシャドーAIガバナンスの実務ガイドで整理しているが、モデル単位の禁止条項は今後ますます空文化していく。

期日が三度動いた経緯も実務上は重要だ。ベンダーの強制移行スケジュールは変わり得るため、「告知された期日を規程に書き写す」のではなく「変更を検知して規程側を追従させる」運用 ——リリースノートの定期ウォッチ——が必要になる。監査の観点でも同じことが言える。ISMSや内部統制の文書に「利用を許可するAIモデル」を列挙している企業は、ベンダー側の強制有効化のたびに文書と実態が乖離していく。監査で指摘されるのは新モデルの存在ではなく、文書と実態の不一致 のほうだ。


6月16日までの確認チェックリスト

  1. 現在のトグル設定を確認する:Gemini Enterpriseの管理画面でGemini 3.5 Flashをオフにしているか。オフにしている場合、6月16日以降は強制的に有効になる前提で以降の項目を進める。オンのまま運用してきた組織は影響が小さいが、3以降の規程点検は同様に必要だ
  2. オフにしていた理由を文書で確認する:データ取り扱い・出力品質・コンプライアンスなど、無効化の理由が何だったかを特定し、トグル以外の手段で代替できるか判断する。理由が残っていない場合は、当時の判断者へのヒアリングまで遡る
  3. AI利用規程の前提条項を点検する:「未承認モデルは無効化する」型の条項があれば、「有効化を前提とした利用条件・禁止データの明示」型に書き換える
  4. ログ・監査の取得範囲を確認する:誰がどのモデルをどう使ったかを後から追える設定になっているか。ISMS・内部統制でAI利用手順を文書化している場合は、文書側の改訂も漏れなく行う
  5. 利用者への周知と共有エージェントの棚卸し:6月16日に何が変わるかを利用部門へ通知し、グループ共有されているエージェントの一覧と権限を確認する。「知らないうちに選べるモデルが増えていた」という状態を作らないことが目的だ

チェックの勘所:最優先は1と2だ。トグルをオフにしている組織には「6月16日に社内環境が変わる」ことが確定している。理由の特定を飛ばして規程だけ直すと、本来守りたかったリスク(例:特定データの投入禁止)が宙に浮く。

なお、この5項目は今回限りの対応ではなく、ベンダーがAI機能を強制有効化するたびに回す定常プロセス として整備しておく価値がある。次の強制移行は必ず来る。そのときに今回のチェック結果と判断記録が残っていれば、対応は数日から数時間に短縮できる。


よくある質問(FAQ)

Q. 6月16日に具体的に何が変わるのか? A. Gemini 3.5 Flashの機能管理トグルが利用できなくなり、Gemini Enterpriseアプリの全ユーザーでGemini 3.5 Flashがデフォルト有効・無効化不可になる。現在トグルでオフにしている組織も、以降はユーザーがチャットでこのモデルを選択できる状態になる。変更はGlobal・US・EUマルチリージョンに適用される。利用者側の操作は不要で、管理者側にも代替の無効化手段は(リリースノートで確認できる範囲では)案内されていない。

Q. AI利用規程はどう直すべきか? A. 「モデルを無効化して統制する」前提の条項を、「モデルは有効である前提で、投入してよいデータ・してはならないデータ、用途、確認手順を定める」設計に改める。あわせて、ベンダーのリリースノートを定期的に確認し規程へ反映する担当・頻度を明文化することを勧める。今回のように期日が短期間で三度変わるケースでは、規程に固定日付を書き込むより「ベンダー告知に追従する」運用ルールのほうが保守しやすい。

Q. 6月16日までに何もしなかったらどうなるか? A. システム障害が起きるわけではない。起きるのは「規程上は使えないはずのモデルが、実際には全ユーザーが選べる」という文書と実態の乖離だ。利用者がそのモデルで機密情報を扱った場合、規程側に有効な禁止・条件の定めがなければ事後対応も曖昧になる。監査・インシデント対応の両面で、放置のコストは静かに積み上がる。

Q. ほかのGoogleサービスやAI製品にも同じことが起きるのか? A. 今回確認できる一次情報はGemini EnterpriseのGemini 3.5 Flashに関する変更であり、他サービスへの一般化は推測になる。ただし、新モデルをベンダー主導で順次有効化する運用は業界全体の傾向であり、「止めて審査する」統制が通用しにくくなる方向性は他製品でも想定しておくべきだ。自社が使う各AI製品について「管理者が無効化できる範囲」を一覧化しておくと、次の同種変更への耐性が一気に上がる。


社内導入判断に落とすための確認観点

AI関連の発表は、機能名やベンダー名だけで判断すると失敗しやすい。自社で見るべきなのは、利用対象業務、入力してよいデータ、権限管理、ログ取得、費用上限、モデル変更時の再評価、成果測定の方法である。特にエージェントや外部ツール連携を伴う場合は、AIがどのシステムに接続し、どの権限で何を実行できるかを図にしてから判断する必要がある。

導入の可否は「使えるか」ではなく「統制しながら使い続けられるか」で決まる。PoCでは動いても、本番では監査・費用・障害時対応・利用部門教育が必要になる。記事内の発表を自社に適用する場合は、まず1業務に絞り、成功条件と停止条件を明文化する。

GXOへ相談する前に整理しておくと早い情報

相談前には、対象業務、現在の作業時間、利用予定データ、既存システム、禁止したい操作、想定利用者数、月額予算、社内規程の有無を整理する。AI導入はモデル選定から始めるより、業務とデータの整理から始めた方が手戻りが少ない。


90日で本番判断へ進めるロードマップ

最初の30日は、対象業務とガバナンスの整理に使う。AIで置き換えたい作業、AIに渡してよいデータ、利用者、承認者、ログの保管先、費用上限を決める。ここで曖昧なままPoCを始めると、動くものはできても本番承認で止まる。

31日目から60日目は、小さな業務でPoCを行う。評価指標は「便利だったか」ではなく、処理時間、エラー率、再作業率、問い合わせ件数、判断品質など、業務KPIに結びつくものにする。AIの回答だけでなく、人が確認・修正する工程まで含めて測る。

61日目から90日目は、本番化可否を判断する。モデル・調達経路・権限・監査・費用・障害時の手順を揃え、継続運用できる形にする。ここで本番化しない判断になった場合も、入力データや業務プロセスの課題を記録しておくと、次のAI導入の成功率が上がる。


いつGXOに相談すべきか

  • 自社のAI利用状況(公式導入分もシャドーAIも含む)を 棚卸しし、強制有効化時代の利用規程に作り替えたい(現規程がいつのベンダー仕様を前提に書かれたか分からない場合を含む)
  • 生成AIに 投入してよいデータの線引きとログ・監査の設計 を専門家とともに固めたい
  • Workspace・各種AI製品の 設定と規程の整合を第三者の目で点検 してほしい

GXOは、AIアセスメントでAI利用の棚卸しから規程・統制設計までを支援し、生成AIセキュリティで入力データ管理・ログ設計・教育を含むガバナンス実装を提供している。「止められない」前提の統制への移行は早いほど低コストだ。→ AI利用規程・ガバナンスの相談はこちら

関連記事


参考資料

本記事は2026年6月12日時点の公開情報をもとに作成。トグル撤去の期日は過去に複数回変更されており、今後も変わる可能性があるため、Google Cloudの一次情報の最新版を必ず確認すること。


「新モデルを止めて審査する」が通用しない時代の統制設計を

AI利用の棚卸し、強制有効化を前提とした利用規程への改訂、投入データの線引き、ログ・監査の設計までを支援します。ベンダーの仕様変更に規程が置いていかれていないか、第三者の目での点検から始められます。

AIガバナンスの無料相談を予約する

※ 営業電話はしません | オンライン対応可 | 規程の現状診断のみの相談も歓迎