Google Search が Gemini 3.5 Flash-Lite に切り替わった日 ── 350 tokens/秒の agentic search と、静かに始まった Gemini 4

2026年7月21日、Googleが検索の裏側を静かに入れ替えた。Gemini 3.6 Flash・Gemini 3.5 Flash-Lite・Gemini 3.5 Flash Cyberという3つの新モデルが同時に発表され、そのうちの1つ、Gemini 3.5 Flash-Liteが「Google Searchへのロールアウトが始まった」と公式ブログに明記された。前回の記事「検索が『タスク実行』になった日 ── AI Mode Connected Apps 拡大」で、当サイトは「守る→見分ける→任せる」という3段階の進化を追った。あの記事で見た「任せる」は、Instacart・Canva・YouTube MusicといったアプリをAIが操作する、いわば「アプリ側」の任せるだった。今回起きたのは、その裏で検索エンジン自身の処理速度を担うモデルが交代する、いわば「インフラ側」の任せるだ。同じ「任せる」という言葉が、わずか5日の間に2つの異なる層で進行している。しかも同じ発表の中に、もう一つ見過ごせない一文が紛れていた。「Gemini 4に向けた、これまでで最も野心的な事前学習の実行を開始した」という、まだ何も発表されていない次のモデルへの言及だ。本稿は、この2026年7月21日の発表を、確定した事実と推測を厳密に切り分けながら読み解く。見出しだけを追うと3つのモデルと1つの次世代予告が一緒くたに語られがちだが、それぞれの確度と段階はまったく異なる。その違いを丁寧にほどいていきたい。

Google が 2026年7月21日に同時発表した3モデルの全貌

まず整理しておきたいのは、この日Googleが発表したのは1つのモデルではなく、性格の異なる3つのモデルだということだ。名前が似ているため混同しやすいが、それぞれの役割はまったく違う。

修辞境界①: 3モデルを混同しない

ニュースの見出しだけを追うと「Gemini 3.6 Flashが検索に来た」と誤読しがちだが、正確には次の3体制だ。

Google公式ブログは、この3モデルの発表を次のように位置づけている。

"we have started our most ambitious pre-training run yet, for Gemini 4, and are excited by the progress"
（日本語訳: 私たちは、Gemini 4に向けたこれまでで最も野心的な事前学習を開始しており、その進捗に手ごたえを感じている）
Google公式ブログ「Gemini 3.6 Flash, 3.5 Flash-Lite, and 3.5 Flash Cyber」（2026-07-21）

この一文は記事全体の締めくくり近くに置かれており、3モデルの発表と同じ記事内で、次世代モデルの訓練開始が同時に語られている。この構造自体が、Googleが「今」と「次」を同時に見せる発表スタイルを取っていることを示している。

3.6 Flash はコスト効率の刷新版

3.6 Flashの価格は入力100万トークンあたり1.50ドル、出力100万トークンあたり7.50ドルで、前世代の3.5 Flashと比較して出力トークンのコストが17%削減された。ベンチマークによっては出力トークン数自体が最大65%削減されるケースもあるという。これは「同じ答えをより短いトークンで返せるようになった」という意味で、単純な値下げではなくモデルの効率そのものが上がったことを示している。

この「同じ答えをより短く返す」という性質は、開発者にとってはAPIコストの削減として現れるが、検索エンジンのような大規模かつ常時稼働するシステムにとっては、より大きな意味を持つ。1回あたりのクエリ処理コストが下がれば、同じ予算でより多くのクエリを、あるいはより複雑な処理を伴うクエリを捌けるようになる。3モデルの発表を「値下げのニュース」として片付けず、「検索エンジンが処理できる仕事の総量が変わるニュース」として読む視点を持っておきたい。

3つのモデルが同じ発表に並んだ理由

汎用フラッグシップの3.6 Flash、検索エージェント処理特化の3.5 Flash-Lite、セキュリティ特化の3.5 Flash Cyberという性格の異なる3モデルが同じ発表に並んだのは偶然ではないだろう。Googleのモデルラインナップが「汎用モデルを1つ作って全部に使う」時代から、「用途ごとに最適化したモデルを使い分ける」時代に移行しつつあることの表れだと読める。検索という巨大なユースケースに対して専用のモデル（3.5 Flash-Lite）が割り当てられたこと自体が、検索がGoogleにとってどれほど戦略的な処理領域であるかを物語っている。

Gemini 3.5 Flash-Lite の実測データが示す「速さ」の意味

今回の発表で最も注目すべきは、検索そのものに投入される3.5 Flash-Liteの性能プロファイルだ。

350 output tokens/秒という数字

3.5 Flash-Liteの出力速度は毎秒350トークンとされている。価格は入力100万トークンあたり0.3ドル、出力100万トークンあたり2.5ドルと、3.6 Flashよりもさらに低コストに設計されている。この「安くて速い」という組み合わせが、なぜ検索エンジンにとって重要なのか。

検索結果、特にAI OverviewsやAI Modeのような生成型の応答は、ユーザーが検索ボタンを押してから答えが表示されるまでの体感速度が使い勝手を左右する。エージェント的な処理――検索クエリを分解し、複数の情報源を参照し、回答を組み立てる――を行うほど、モデルの応答速度がボトルネックになりやすい。350 tokens/秒という速度は、この「検索の裏側で何段階もの処理をこなしながら、ユーザーを待たせない」という要求に応えるための数字だと読める。

instruction following と意図把握の向上

速度だけでなく、指示追従性（instruction following）とユーザー意図の把握精度も向上しているとされる。検索エージェントが「何を聞かれているか」を正確に理解できなければ、いくら速くても的外れな処理になる。速度と精度の両方が底上げされたことで、より複雑なタスク実行型の検索処理を任せられるモデルになった、というのが今回のポジショニングだ。

「安くて速い」がエージェント処理に向く理由

従来、AIモデルの性能競争は「どれだけ賢いか」という一点に偏りがちだった。しかし検索のようにリアルタイム性が求められる場面では、賢さと同じくらい「安定して速く動くか」が重要になる。エージェント処理は、1つのクエリに対して単発の回答を返すのではなく、複数の情報源を横断的に参照し、必要に応じて追加のクエリを発行し、それらを統合して初めて回答が完成する、という多段階の処理になりやすい。この多段階処理を成立させるには、各段階のコストと遅延が小さくなければ、全体としての体感速度が破綻してしまう。3.5 Flash-Liteの「安くて速い」という特性は、まさにこの多段階処理を実用レベルで成立させるための設計思想だと考えられる。

なぜ Google Search に展開されるのか ── 確定事実と推測の境界線

ここで、本稿がもっとも慎重に扱いたい一点がある。「Gemini 3.5 Flash-LiteがGoogle Searchに展開される」という事実と、「それがAI OverviewsやAI Modeにも使われる」という話は、情報の確度がまったく異なる。

修辞境界②: 確定表現と推測表現を分ける（最重要）

Google公式ブログが明記しているのは、次の一文だけだ。

"3.5 Flash-Lite is also rolling out in Google Search"
（日本語訳: 3.5 Flash-Liteは、Google Searchでもロールアウトが始まっている）
Google公式ブログ「Gemini 3.6 Flash, 3.5 Flash-Lite, and 3.5 Flash Cyber」（2026-07-21）

この一文が確定情報のすべてだ。「Google Searchへのロールアウトが始まっている」という事実は公式ブログの言葉としてそのまま採用できる。しかし、これがGoogle Search全体のどの機能に使われるのか――従来の検索結果ページなのか、AI Overviewsなのか、AI Modeなのか――について、公式ブログは具体的な機能名を挙げていない。この短い一文の裏にどれだけの実装範囲が隠れているかは、現時点では外部から正確に測る術がない。

この点について、業界メディアの一部は踏み込んだ推測を書いている。Search Engine Landの報道では、AI OverviewsやAI Modeでの利用について「使われるかもしれない」という趣旨の推測的な表現（"might be used"）が用いられている。これは著者の合理的な予想であって、Google公式の確約ではない。

Search Engine Land「3.5 Flash-Lite rolling out in Google Search」は、Google公式の「Google Searchへのロールアウト」という一文を受けて、それがAI OverviewsやAI Modeのような生成型検索機能に活用される可能性を論じている。だが、その活用範囲の具体像は現時点では明示されていない。

本稿では、この区別を維持したまま先に進む。確定しているのは「3.5 Flash-LiteがGoogle Search全体に展開されつつある」という事実であり、「AI Overviews専用」「AI Mode専用」といった特定の機能への紐づけは、あくまで業界メディアの推測の域に留まる。前回の記事で扱ったAI Mode Connected Appsの拡大とは、レイヤーが異なる話であることも明確にしておきたい。archives/112は「AIがどのアプリを操作するか」という機能拡張の話であり、本稿は「検索処理の裏側でどのモデルが動くか」というインフラの入れ替えの話だ。

「任せる」の二層構造 ── アプリ側と インフラ側

ここで、当サイトが2026年7月に追い続けてきた連載軸を一歩進めたい。Preferred Sourcesから始まった「守る」の議論、Cloudflare Precursor GAで見た「見分ける」の議論、そしてAI Mode Connected Appsで見た「任せる」の議論。今回の発表は、その「任せる」がさらに二層に分かれていることを教えてくれる。

「任せる = アプリ側」（archives/112）

Instacart・Canva・YouTube Musicといったアプリが、AIモードから直接操作可能になる。これはユーザーの目に見える「機能」の話だ。ユーザーが「検索してタスクを頼む」という体験の入口が広がる。

「任せる = インフラ側」（本稿・archives/113）

その裏側で、検索処理そのものを担うモデルが、より速く安価なエージェント処理向けモデルに切り替わる。これはユーザーの目には直接見えない「基盤」の話だ。アプリ側で「何を頼めるか」が広がるほど、インフラ側で「どれだけ速く正確に処理できるか」の重要性が増す。両者は独立した発表でありながら、構造的には対になっている。

3段階進化の完成形

ここまでの連載を整理すると、次のような系譜になる。

• 守る: Preferred Sources 3原則（誰に見せるかを制御する）
• 見分ける: Cloudflare Precursor GA（人間かボットかを継続的に検証する）
• 任せる（アプリ側）: AI Mode Connected Apps（AIがアプリを操作する）
• 任せる（インフラ側）: Gemini 3.5 Flash-Lite（本稿。AIの処理速度そのものが検索の裏側で交代する）

「守る」「見分ける」「任せる」という3段階の進化が、たった1週間程度の間に、別々のベンダー・別々のレイヤーで同時多発的に進んでいる。これは偶然の一致というより、業界全体がAIエージェントを前提にしたインフラへ移行しつつある局面にあることの証拠だと考えている。

興味深いのは、この二層構造が今後さらに細分化していく可能性があることだ。今回はアプリ操作の層とモデル処理速度の層という2つが同時に動いたが、今後は認証・課金・ログ記録といった、さらに別のレイヤーでも同様の「任せる」の実装が進むかもしれない。当サイトはこの多層化の進行を、レイヤーごとに区別して追跡していく方針だ。すべてを「AIが賢くなった」の一言でまとめてしまうと、どの層でどんな変化が起きているのかが見えなくなる。層を分けて記録することが、半年後・1年後に振り返ったときの資料としての価値を高めると考えている。

Gemini 3.5 Flash Cyber ── CodeMender の政府限定パイロット

3体制のうち、もう1つ触れておきたいのが3.5 Flash Cyberだ。これは検索とは関係のない、セキュリティ専用モデルとして位置づけられている。

脆弱性を「自律的に」検出・検証・修正する

Google公式の説明によれば、3.5 Flash CyberはCodeMenderという枠組みの中で、コードベースの脆弱性を検出し、その脆弱性が実際に悪用可能かを検証し、パッチを生成する一連の作業を行う。単に「怪しいコードを指摘する」だけでなく、自律的に攻撃を試みて脆弱性の実在性を確かめる（autonomously attacks）機能まで含まれているとされる。

限定パイロット段階であることの明示

この機能は現時点で一般公開されていない。政府機関と一部の信頼できるパートナーに限定したパイロット提供の段階にある。当サイトでは以前「AIエージェントのコードに脆弱性が見つかった日 ── 発見と修正の記録」という記事で、AI生成コードのセキュリティ品質の課題を扱った。3.5 Flash Cyberは、その課題に対するGoogle側の一つの回答と言えるが、まだ限定パイロットの段階であり、一般のWEBディレクターが今すぐ使えるものではない。この点は今後の展開を見ながら別記事で深追いしたい。

ここでも同じ修辞の規律を適用しておきたい。「AIが自律的に脆弱性を検出・検証・パッチする」という説明は、機能としての設計思想を語ったものであり、それが一般提供された際にどれほどの精度で機能するかは、まだ実運用の検証を経ていない。限定パイロットという段階そのものが、Google自身がまだこの機能の安全性・信頼性を慎重に見極めている最中であることを示している。archives/95で扱った「AI生成コードの品質は構文の正確さとセキュリティの正確さで別々に評価すべき」という論点は、CodeMenderのような自動修正ツールにもそのまま当てはまる。修正パッチが構文的に正しくても、セキュリティ上正しいとは限らない。

静かに始まった Gemini 4 の訓練

今回の発表の中で、実はもっとも大きなインパクトを持つかもしれないのが、次の一文だ。

修辞境界③: 「訓練を開始した」段階であることの明示（最重要）

Google公式ブログは記事の末尾近くで、次のように述べている。

"we have started our most ambitious pre-training run yet, for Gemini 4, and are excited by the progress"
（日本語訳: 私たちは、Gemini 4に向けたこれまでで最も野心的な事前学習を開始しており、その進捗に手ごたえを感じている）
Google公式ブログ「Gemini 3.6 Flash, 3.5 Flash-Lite, and 3.5 Flash Cyber」（2026-07-21）

これは「Gemini 4を発表した」でも「Gemini 4をリリースした」でもなく、「Gemini 4に向けた事前学習の実行を開始した」という段階の話だ。事前学習（pre-training）はモデル開発の最初期の工程であり、そこから評価・調整・安全性検証などの工程を経て、実際にリリースされるまでには通常相応の時間がかかる。今の時点で「Gemini 4がいつ出るか」を断定することはできない。

業界メディアの受け止め方

9to5Google「Gemini 3.6 Flash launch」やAnalytics Insight「Google unveils Gemini 3.6 Flash, 3.5 Flash-Lite; next-gen Gemini 4 enters training」は、いずれもこの「Gemini 4 enters training」という表現を見出しレベルで扱っている。3モデルの実用的な発表という「今」の話と、Gemini 4という「次」の話を、同じ記事の中で並べて報じているという点で、各メディアの扱いは一致している。

self-proof-loop 型の予言 ── 数ヶ月以内の追跡を宣言する

当サイトは「検索は『クリックする場所』から『エージェントが代わりに動く場所』になった」という記事で、WebMCP・UCP・Agentic Commerceという概念を扱い、それがわずか1日後にAI Mode Connected Appsとして現実化するのを前回の記事で確認した。今回のGemini 4の訓練開始という情報も、同じ姿勢で扱いたい。「訓練を始めた」という発表から、実際の一般提供までには数ヶ月単位の時間がかかる可能性が高い。当サイトはこの動きを定点観測し、Gemini 4が正式に発表された段階で、本稿に追記する形で答え合わせを行う予定だ。予言の的中を演出するのではなく、事実がどう推移したかを正直に記録するのが目的だ。

WEBディレクターは今週何をすべきか

今回の発表を受けて、WEBディレクターが実務的に取るべきアクションを整理する。

1. 3モデルの区別を業務資料に反映する

クライアントやチーム内で「Geminiが検索に来た」という粗い理解のまま話が進むと、後で「AI Overviewsに使われているのか」「AI Modeなのか」という確認が二度手間になる。3.6 Flash・3.5 Flash-Lite・3.5 Flash Cyberの役割の違いを、簡潔な一枚資料にまとめておくと良い。

2. Google Search全体の応答速度・傾向の変化を観測する

3.5 Flash-Liteのロールアウトが進むにつれて、検索結果の応答速度や、AI生成部分の文体・構成に変化が現れる可能性がある。Search Consoleの表示回数・クリック率の推移を、通常の週次確認に加えて、今後1〜2ヶ月は少し注意深く見ておく価値がある。

3. Fan-Out対策に「速度」という観点を加える

これまでFan-Out型の評価（複数の観点からコンテンツをどれだけ網羅的にカバーしているか）は、主にカバレッジの広さで語られてきた。エージェント処理を担うモデルが高速化されるということは、検索エンジン側がより多くの情報源を短時間で処理・比較検討できるようになるということでもある。コンテンツの網羅性がこれまで以上に評価されやすくなる可能性を、頭の片隅に置いておきたい。

4. 継続的な定点観測を習慣にする

Gemini 4の訓練開始という情報は、今すぐ何かを変える必要のある話ではない。しかし「次に何が来るか」を早期に把握しておくことは、半年後・1年後の対応スピードに直結する。「宣言と実装のギャップは物証で塞ぐ日」で扱った自己実証の姿勢と同様に、宣言だけでなく実際の展開状況を継続的に追跡する習慣が重要だ。

5. 「速さ」を評価基準の一つとして意識する

これまでWEBディレクターがコンテンツを設計するとき、意識してきたのは主に「網羅性」「専門性」「更新頻度」といった質的な観点だった。今回の発表が示唆するのは、検索エンジン側の処理速度が上がることで、より多くの情報源を短時間で比較検討できるようになるという変化だ。これは直接コンテンツの書き方を変える話ではないが、「検索エンジンがより多くの候補を素早く見比べられる時代になる」という前提の変化として、頭の片隅に置いておく価値がある。競合との差別化ポイントが、これまで以上に細部の正確さや一次情報への忠実さで問われる可能性がある。

6. クライアント・チームへの説明資料を更新する

「Gemini 4が来る」という見出しだけが独り歩きすると、クライアントから「うちのサイトも今すぐ対応しないと」という過剰な問い合わせが増えることがある。WEBディレクターとしては、今回の発表が「訓練開始」という段階にあり、実際のリリースまでには時間がかかる可能性が高いことを、落ち着いたトーンで説明できる資料を用意しておくと良い。焦らせるための情報発信ではなく、正確な段階を伝えるための情報発信を心がけたい。

当サイトの self-proof 状況（正直な自己開示）

ここで、当サイト自身の対応状況を正直に開示する。

「実施済み」と「進行中」を無理に一緒くたにせず、当サイトがまだ持っていないデータは正直に「持っていない」と書く。これは「物証で塞ぐ日」から続く、当サイトの編集姿勢の一部だ。

特にFan-Out速度観点については、現時点で計測手段そのものが確立していない。既存のFan-Outスコア測定は「どの観点がカバーされているか」という網羅性を評価する仕組みであり、「どれだけ速く処理されたか」という時間軸の評価軸は含まれていない。この観点を追加するかどうかは、3.5 Flash-Liteの展開が実際に検索結果へ与える影響が見えてきた段階で、改めて検討したい。今の段階で無理に速度計測の仕組みを作り込むよりも、まずは実際の展開状況を観測することを優先する判断だ。

3段階進化連載の系譜（self-proof-loop の接続点）

本稿は、当サイトが2026年7月に積み重ねてきたself-proof-loop連載の11本目の接続点にあたる。系譜を改めて整理しておく。

• archives/98: 「1,238記事の8割が土俵に上がっていない」── 自己実証の起点
• archives/99〜archives/100: llms.txt設置・本番DB書き換え体制の答え合わせ
• archives/104〜archives/105: 誇張報道の検証・宿題の答え合わせ
• archives/108: 再クロール待ち行列の実測・「待つ」を能動的にする
• archives/109: Search Console Platform Properties
• archives/110: 「宣言と実装のギャップは物証で塞ぐ日」
• archives/111: Cloudflare Precursorが「見分ける」へGA化
• archives/112: AI Mode Connected Apps拡大 ── 「任せる」の始まり
• archives/113（本稿）: Gemini 3.5 Flash-Lite ── 「任せる」のインフラ側と、静かに始まったGemini 4

1つの記事が単発で完結するのではなく、前の記事の宣言が次の記事で検証され、また新しい宣言が生まれる。この繰り返しが、当サイトのself-proof-loopの実体だ。

まとめ ── 速さが新しい戦場になる

2026年7月21日の発表は、一見すると「新しいモデルが3つ出た」というありふれたニュースに見える。しかし丁寧に読み解くと、そこには2つの重要な示唆がある。

1つは、検索エンジンの「任せる」という進化が、ユーザーに見えるアプリ操作の層だけでなく、ユーザーに見えないインフラの処理速度の層でも同時に進んでいるということ。350 tokens/秒という数字は単なるスペック競争ではなく、エージェント的な検索処理を実用的な速度で回すための、静かだが本質的な変化だ。

もう1つは、Googleが「今」の発表の中に、「次」の予告――Gemini 4の訓練開始――を紛れ込ませているということ。これは断定的な未来予測ではなく、あくまで訓練開始という一段階の事実であり、本稿ではその段階の違いを崩さずに記録した。

当サイトはこの2つの動きを、これからも定点観測していく。速さが新しい戦場になる時代に、WEBディレクターが持つべきなのは焦りではなく、確定した事実と推測を分けて読む冷静さだと考えている。

本稿を執筆している時点で、3.5 Flash-LiteのGoogle Searchへの展開はまだ始まったばかりの段階だ。今後数週間から数ヶ月をかけて、その影響範囲が徐々に明らかになっていくはずだ。当サイトは、その推移をSearch Consoleの実測データとともに追跡し、変化があれば正直に、変化がなければ「変化がなかった」ことも含めて記録していく。派手な予言よりも、地道な観測の積み重ねが、結局は読者にとって最も信頼できる情報になると考えているからだ。継続の質を、また明日も少しずつ更新していく。

関連 archives

• archives/85: 守る側の設計思想 ── Preferred Sourcesから学んだAIを起こす作法
• archives/86: Cloudflareのデフォルト「AI bots ブロック」があなたのGEOを殺している
• archives/87: 受け取られ方を設計する ── Preferred Sources 3原則の実装ガイド
• archives/95: AIエージェントのコードに脆弱性が見つかった日 ── 発見と修正の記録
• archives/98: 1,238記事の8割が土俵に上がっていない
• archives/103: 検索は「クリックする場所」から「エージェントが代わりに動く場所」になった
• archives/108: 再クロール待ち行列547件、当サイトの2週間
• archives/109: SNS投稿もGoogle検索に測れる日 ── Search Console「Platform Properties」
• archives/110: 宣言と実装のギャップは物証で塞ぐ日
• archives/111: Cloudflare Precursorが GA になった日
• archives/112: 検索が「タスク実行」になった日 ── AI Mode Connected Apps 拡大

一次情報出典

• Google公式ブログ「Gemini 3.6 Flash, 3.5 Flash-Lite, and 3.5 Flash Cyber」（Google, 2026-07-21）
• Search Engine Land「3.5 Flash-Lite rolling out in Google Search」（2026-07-21）
• 9to5Google「Gemini 3.6 Flash launch」（2026-07-21）
• Analytics Insight「Google unveils Gemini 3.6 Flash, 3.5 Flash-Lite; next-gen Gemini 4 enters training」（2026-07-21）
• Search Engine Roundtable「Google Search 3.5 Flash-Lite」（2026-07-21）
• BigGo Finance（2026-07-21 配信）