7月18日、Techstrong.aiが「Google Delays Gemini 3.5 Pro as Coding Improvements Fall Short」と題した記事を公開した。複数の関係者の証言をもとにした報道によると、GoogleはコーディングAIの性能目標を達成できず、フラッグシップモデル「Gemini 3.5 Pro」のリリースを数ヶ月単位で先送りしているという。コード生成が「フロンティアモデルの信頼性テスト」になりつつある今、この動向はAIコーディングエージェントを本番環境に組み込もうとしている開発チームにとっても無視できない話だ。

コーディング性能が「フロンティアモデルの試金石」になった

Googleは、主力AIモデル「Gemini 3.5 Pro」のリリースを数ヶ月単位で延期している。原因は、コード生成能力の改善が社内の性能目標に届かなかったことだとされている。

Gemini 3.5 Proは、5月のGoogle I/O 2025で発表され、その後間もなく顧客向けにリリースされる予定だった。しかし、プロジェクトに詳しい複数の関係者の証言をもとにした報道によると、エンジニアチームはコード生成能力の強化に取り組みつつ、リリースをずらし続けている状況だ。なお、Googleが公式に延期を発表したわけではなく、あくまで関係者の証言に基づく報道である点は留意が必要だ。

Futurum GroupのVP、Mitch Ashleyは本件についてTechstrong.aiに次のように語っている。

「GoogleがGemini 3.5 Proをコーディングの目標未達で延期したことは、コーディングがフロンティアモデルの信頼性を測る決定的なテストになったことを裏付けている。ベースモデルを廃棄して再トレーニングを深めるという判断は、Googleが自社ロードマップではなく競合他社を基準に自らを採点していることを示している。」

Ashleyはさらに、フロンティアモデルの上にコーディングエージェントを構築している企業に対して実務的な警告も発している。

「ベンダーのロードマップ日程やベンチマークの主張は、自社のパイプラインで検証されるまでは暫定的なものとして扱うべきだ。単一ベンダーのコーディング動向に依存したアーキテクチャを組んでいるチームは、コントロールできない依存関係を抱えることになる。」

競合はコード生成で攻勢をかけている

GoogleがGemini 3.5 Proの出荷を見送っている間に、競合他社は動いている。元記事によると、MetaおよびOpenAIがコーディング特化の強化を施した新モデルをそれぞれ投入しているとされている。具体的なモデル名については、元記事の原文を直接確認していただきたい。

AIによるコード生成は、今や最も競争の激しいセグメントの一つだ。企業がAIコーディングエージェントを本番環境に組み込む動きが加速する中、モデルの実力差がそのまま開発生産性の差に直結しはじめている。

Google内部でも混乱

皮肉なことに、Googleは社内ではAIによるコード生成を積極的に活用している。同社によると、レビューを通過して本番環境に到達するコードのうち、約75%がAI生成だという。

一方で、いくつかの構造的な問題も浮上している。

• Google Cloud、DeepMind、Android、コンシューマープロダクトの各チームにわたる開発上の競合が、Gemini 3.5 Proの開発を複雑化している
• 計算リソースの不足と、AI生成コードの社内実験を制限していた内部規制が研究の足かせになっていた
• 研究者の一部がAnthropicやOpenAIへ流出している

Googleはこれらに対処すべく、AIコーディングインフラを「Google Antigravity」プラットフォームに統合し、DeepMind内にAIコーディング専任チームを新設している。「Google Antigravity」はGoogleが社内のAIコーディング基盤を一元管理するために整備しているプラットフォームとされているが、現時点では公式情報が限られており、元記事の記述に基づく紹介である点を付記しておく。

Googleの広報担当者は、現在Gemini 3.5 ProとFlashのアップグレードモデル等をパートナーとともにテスト中であり、米国政府とのモデルテストやAI安全フレームワークに関する議論も継続中だとしている。

エンジニアへの含意

今回の遅延が示すのは、フロンティアモデル開発における競争圧力の構造的な変化だ。かつては「発表してから改善する」サイクルが許容されていたが、コーディングエージェントが本番環境に組み込まれる段階になると、ベンチマーク上の優劣がそのまま開発組織の生産性に影響する。ベンダーが「目標未達」を理由に出荷を見送るという判断自体は品質管理として評価できる一方、依存するチームにとっては計画の見直しを迫られるリスクでもある。

Mitch Ashleyが指摘するように、単一ベンダーのロードマップに深く依存したアーキテクチャは、コントロールできない外部リスクを内包する。複数モデルへの対応や、自社環境でのベンチマーク検証を前提とした設計が、今後の標準的なプラクティスになっていく可能性がある。

※編集部の考察：AIコーディングエージェントの採用を検討している開発チームにとっては、モデルの切り替えコストを最小化するための抽象化レイヤー（LiteLLMやOpenRouterなど）を早期に設計に組み込んでおくことが、ベンダーリスクの軽減策として有効になりつつある。

詳細はGoogle Delays Gemini 3.5 Pro as Coding Improvements Fall Shortを参照していただきたい。