Gemini 3.5 Flash Stable化、API運用の論点

Google AI for Developers の Gemini API モデル一覧が 2026年6月1日 UTC に更新され、Gemini 3.5 Flash が gemini-3.5-flash という Stable モデルとして示された。Google DeepMind 側のモデルページでも、Gemini 3.5 Flash はエージェントとコーディング向けの高性能 Flash モデルとして説明され、Gemini App、Gemini API、Gemini Enterprise、Google AI Studio、Google Antigravity などで使えるとされている。

これは「新しいモデル名が増えた」だけではない。日本の開発チームにとっては、Gemini API Managed Agents の基盤モデルをどう評価するか、Gemini API Docs MCP と Agent Skills で渡す公式文脈をどう組み合わせるか、さらに Gemini API File Search のようなRAG部品とどのモデルを組ませるかを見直すきっかけになる。

事実: StableのモデルIDとして示された

Google AI for Developers の Models ページでは、Gemini 3.5 Flash が Gemini 3 系列のモデルとして掲載され、説明には「agentic and coding tasks」に対する持続的な frontier performance が強調されている。ステータスは Stable で、モデル名の例として gemini-3.5-flash が示される。Stable は、Google の同ページでは「特定の安定モデルを指す」運用に近く、通常は production app では specific stable model を使うべきだと説明されている。

一方、Google DeepMind の Gemini 3.5 Flash ページでは、モデル情報として 1M input tokens、64k output tokens、knowledge cutoff は January 2025、tool use は function calling、structured output、Search as a tool、code execution に対応すると示されている。入力は text、image、video、audio、PDF、出力は text とされる。ここまでは一次情報として確認できる事実だ。

重要なのは、プレビューの派手さではなく、API側で Stable として扱われることだ。これにより、検証環境で試したモデルを本番候補として扱いやすくなる。もちろん Stable だから障害が起きない、品質が変わらない、すべての地域や契約で同条件になる、という意味ではない。しかし、プレビュー名や experimental alias を前提にした一時的な検証より、社内のモデル台帳、監査資料、運用手順に落とし込みやすい。

分析: エージェント基盤の中心に置かれ始めた

ここからは分析だ。Gemini 3.5 Flash の意味は、単体のチャット性能よりも、Google が Gemini API をエージェント基盤へ寄せる流れの中で見るほうが分かりやすい。

Google はすでに、Managed Agents で隔離 Linux 環境、ツール実行、ファイル状態、Web ブラウジング、後続呼び出しでの再開を API 側へ寄せる方針を示している。その中核として Antigravity agent があり、既存記事でも整理した通り Gemini 3.5 Flash 上に構築されたエージェントハーネスと説明されていた。今回のモデル一覧更新は、その前提になるモデルを API 運用の棚に明確に置く動きと読める。

この流れは Gemini API Flex/Priority ともつながる。エージェントは一問一答より長く走り、検索、コード実行、ファイル処理、再試行を重ねる。そこで必要になるのは、最高性能モデルを一律に使うことではなく、モデル、実行環境、推論ティア、文脈取得を用途ごとに分ける設計だ。Gemini 3.5 Flash は、その中で「高速に反復する agentic coding / tool use レーン」の候補になる。

日本企業が見るべきポイント

日本企業でまず見るべきなのは、性能表の順位ではなく、安定運用の条件だ。Google DeepMind は Terminal-Bench、SWE-Bench Pro、MCP Atlas、OSWorld-Verified、Finance Agent v2、MMMU-Pro、MRCR v2 などのベンチマークを出している。Gemini 3.5 Flash は複数の agentic / coding / multimodal 指標で強さを示すが、ベンチマークは導入判断の入口であって、社内の本番判断そのものではない。

日本の開発組織では、仕様書、障害報告、レビューコメント、設計メモ、稟議資料が日本語で流れる。そこで大事なのは、英語ベンチマークで高いことに加えて、日本語の要件を読み違えないか、既存コードの命名やコメントを壊さないか、曖昧な業務条件を勝手に補完しないかだ。Gemini 3.5 Flash を評価するなら、社内の実データをそのまま渡す前に、匿名化した日本語チケット、古い設計資料、テスト失敗ログを使った評価セットを作るほうがよい。

次に、モデルIDの固定だ。gemini-3.5-flash のような Stable ID を使うのか、latest alias を使うのかで、検証と運用の責任が変わる。latest は新機能を追いやすいが、モデルの中身が変わる前提になる。Stable ID は変更管理しやすいが、古くなったときに移行計画が必要になる。監査や顧客説明が重い業界では、少なくとも本番経路は Stable ID を明示し、変更時にレビューできる仕組みを持つべきだ。

1M入力と64k出力をどう扱うか

Gemini 3.5 Flash の 1M input tokens と 64k output tokens は魅力的だが、長いコンテキストはそのまま品質保証にはならない。長い入力を渡せることと、重要な箇所を安定して使えることは別だ。

たとえば、巨大なリポジトリ、長い監査資料、顧客問い合わせ履歴、設計ドキュメントを丸ごと渡せるようになると、アプリ側は楽に見える。しかし、どのファイルが根拠になったのか、古い仕様と新しい仕様が混ざったときにどちらを優先したのか、検索結果と長文入力が矛盾したときにどう判断したのかを追えないと、業務利用では困る。

その意味で、長いコンテキストは File Search や Docs MCP と組み合わせて、根拠の出し方を設計する必要がある。すべてを一度に渡すより、検索で候補を絞り、必要なドキュメントだけを入れ、出力に根拠を残すほうがレビューしやすい。モデルの入力上限が大きくなるほど、むしろ文脈管理の設計が重要になる。

初期導入の現実的な進め方

最初の検証では、Gemini 3.5 Flash を標準モデルの全面置き換えにしないほうがよい。まずは用途を絞る。候補は、複数ファイルにまたがるバグ調査、UI試作の反復、長い仕様書からのテスト観点生成、社内ドキュメントを使う調査エージェント、ログとチケットを横断する障害分析あたりだ。

評価では、成功率だけでなく、再試行回数、レビュー指摘数、出典の正確さ、ツール呼び出しの失敗率、コスト、待ち時間を同時に見る。特にエージェント用途では、最終回答が正しくても、途中で危ないコマンドを提案したり、不要な外部アクセスを試したり、権限外のファイルを読もうとしたりするなら、本番にはまだ早い。

また、利用者向けの説明も必要だ。Gemini 3.5 Flash は速いから何でも任せる、ではなく、どのタスクで使うか、どのデータを渡してよいか、どの結果に人間レビューが必要かを明文化する。社内AI利用規程、開発標準、セキュリティチェックリストのどこにこのモデルを置くかを先に決めたい。

まとめ

Gemini 3.5 Flash が Gemini API のモデル一覧で Stable として示されたことは、Google のエージェント基盤戦略にとって小さくない。Managed Agents、Docs MCP、File Search、Flex/Priority といった部品がそろう中で、APIから呼べる高速な agentic coding モデルの位置づけがはっきりしてきたからだ。

日本の開発チームにとっての初動は、モデル性能表をそのまま信じることではない。Stable IDを本番モデル台帳に入れられるか、日本語要件で安定するか、長いコンテキストの根拠管理ができるか、ツール実行の権限境界を説明できるかを検証することだ。Gemini 3.5 Flash は強い候補だが、価値が出るのは、モデル単体ではなく運用設計まで含めて評価したときである。

出典

• Models | Gemini API | Google AI for Developers - Google AI for Developers, last updated 2026-06-01 UTC
• Gemini 3.5 Flash - Google DeepMind
• Gemini 3.5 - Google DeepMind
• Gemini 3.5 Flash - Evaluations Approach, Methodology & Results - Google DeepMind