GoogleのAI開発環境「Antigravity」が、またモデルの組み合わせ方を少し変えた。今回は新しい単体モデル「Gemini 4 Hydrogen」の投入に加えて、CarbonとHydrogenを使い分ける「Orchestrator」という選択肢が増えた、という話だ。単に新モデルが来たというだけではなく、長い作業を途中で別のモデルに受け渡す設計が前面に出ているのが面白い。開発支援AIが、ひとつの大きな頭で全部をやる段階から、役割分担を前提に動く段階に入ったことを示しているように見える。
Google Antigravityのブログは、2026年11月12日に「Gemini 4 Hydrogen and Orchestrator」を公開した。発表の中心は2つある。ひとつは、Gemini 4 HydrogenをGoogle Antigravity内で使えるようにしたこと。もうひとつは、Orchestratorという新しいモデル選択肢を追加したことだ。Orchestratorは、Hydrogenと、長いタスク向けのより強力なモデルを組み合わせるもので、記事ではGemini 4 Carbonがその相手として説明されている。
背景として、Googleはその少し前にGemini 4 Carbonと「/swarm」を紹介している。これは、巨大で複雑なエンジニアリング作業を、複数のワークツリーと複数のエージェントで並列にさばくための仕組みだという。発表からわずか数日で、Antigravity上では数万件のswarmが起動されたと書かれている。つまり、かなり重い問題に対して、強いモデルを多人数でぶつける使い方がすでに動いていたわけだ。
ただし、日常的な機能追加やデバッグまで毎回そんな構成にすると、処理が重くなり、frontier quotaも余計に消費する。そこでGoogleは、最初のプロンプトを見て安いモデルへ振り分ける静的な「model router」ではなく、タスクの途中で必要に応じてCarbonとHydrogenが行き来する方式を採った、と説明している。記事の例では、Carbonが最初に読み取り専用の段階で依存関係を調べ、曖昧さをほどき、明確な計画を立てる。その後Hydrogenが編集、パッケージ更新、テスト実行を担当する。もしHydrogenが行き詰まれば、またCarbonに戻して状態を見直し、計画を修正して続ける。こうした双方向の切り替えで、Carbonに近い成功率を保ちながら、速度とコスト効率を上げるのがOrchestratorの狙いだ。
Googleは性能の数字も出している。Terminal-Bench 4.1では、OrchestratorはCarbonに近い成功率を出しつつ、平均で24%少ないquotaしか使わず、19%速く終えたという。さらにAntigravity SDKを使えば、HydrogenとCarbonを自前で明示的に組み合わせることもできる。記事のデモでは、オープンソースのissue triageシステムが例に挙がっていて、Hydrogenのエージェントがissueの整理、コード探索、確認質問、PRコメントに応じたUIの素早い修正を担い、Carbonが大きなリファクタ、機能追加、セキュリティチェックを担当していた。
Hydrogen自体も単体モデルとして紹介されている。Artificial Analysis Intelligence Indexでは51点で、Argonの50点を上回り、最高設定では54点に達するという。Terminal-Bench 4.1でも57%を記録し、3.8 Flashの18.2%を大きく上回ったとしている。直接選ぶ場合は、thinking depthをlow、medium、high、そして新しいxhighの4段階で調整できる。提供開始は、HydrogenがGoogle AI ProとUltraの有料加入者向けに順次展開。OrchestratorはUltra向けにOrchestrator (Carbon) と Orchestrator (Argon)、Pro向けには Orchestrator (Argon) として配布され、企業向けには Gemini for business でも使えるとしている。
この発表で興味深いのは、Googleが「最強モデルを常時回せばよい」とは考えていないことを、かなりはっきり言葉にした点だと思う。実際、開発の現場では、最初の構想出しには深い推論が欲しいが、ファイル編集やテストの反復には速さが欲しい、という場面が多い。全部を同じ強度で回すと、待ち時間もコストも膨らむ。Orchestratorは、その不均一さを前提にしている。ここはかなり筋がいい。
しかも面白いのは、単なる「安いモデルへ逃がす」設計ではないところだ。静的なrouterは、最初の見立てが外れると弱い。仕事が進むうちに難所が見えてくるのは普通なので、タスクの途中で判断を変えられないのは不利だ。記事の説明では、Carbonが読み取りと計画、Hydrogenが実作業、そして必要ならまたCarbonへ戻る。人間のチームに近い。強い設計者が方針を固め、実務担当が回し、行き詰まったら上位の視点で立て直す。ここにAIエージェントの使い方の成熟が見える。
一方で、この方式が広く効くのは、Antigravityのように最初からモデル切り替えを体験の中心に置いた環境だろうとも思う。一般の開発者は、いつどのモデルを使うかを毎回考えるのが面倒だから、Orchestratorのような抽象化には価値がある。逆に言うと、モデルの役割分担を明示しないプロダクトでは、こうした仕組みはまだ扱いにくい。Googleは、SDKでも同じ思想を押し出しているので、個人の対話だけでなく、チームや自動化パイプラインまで見据えているのだろう。
今回の発表は、Hydrogenの性能紹介に見えて、実は「単体で勝つモデル」より「組み合わせて勝つ運用」に重心がある。これは生成AIの使い方が、モデル単体の比較から、ワークフロー全体の設計へ移っていることを示していると思う。ベンチマークの点数が高いこと自体は当然大事だが、現場では速さ、失敗からの復帰、試行回数の上限が効く。Terminal-Bench 4.1で24%のquota削減と19%の高速化を出した、という数字は、そこをかなり意識したものに見える。
ただ、ここには少し注意も必要だ。Googleの説明は魅力的だが、Orchestratorのような方式は、モデル間の受け渡しがうまくいく前提で成り立つ。実際には、どの段階でCarbonに戻すか、Hydrogenにどこまで任せるか、失敗をどう検知するかで体験は大きく変わるはずだ。SDKで明示的に組む場合はなおさら、開発者側に設計力が求められる。便利そうに見える一方で、運用の責任が完全に消えるわけではない。
それでも、今回の発表はかなり重要だと思う。AIエージェントの価値は「一発で賢い答えを返すこと」だけではない、とGoogle自身が認めたからだ。長いタスクでは、途中で考え直し、役割を切り替え、実作業と再計画を往復する。その発想は、人間のソフトウェア開発にかなり近い。HydrogenとCarbonを分けたことは、その近さをプロダクトの中心に置いた、ということなのだろう。
実務の視点で見ると、Hydrogenの追加よりOrchestratorのほうが効きそうだと思う。モデル選択は自由度が増えると同時に、面倒も増える。毎回「今は速さを取るか、深さを取るか」を考えるのは、意外と負担だ。その点、Orchestratorはその判断を内部化してくれる。開発者は一つのプロンプトを書けばよく、裏でCarbonとHydrogenが回る。これは、エージェント利用の摩擦をかなり下げるはずだ。
ただし、こういう仕組みは“うまくいけば見えない”のが難しいところでもある。成功時にはただ速く賢く見えるが、失敗時にはどこで詰まったのか把握しづらい。だからこそ、Antigravity SDKのように明示的に制御できる道を同時に用意したのは妥当だと思う。自動化されたOrchestratorで日常を回し、特殊な業務や重要なパイプラインでは自分でモデルの役割を設計する。両方を残しているのは、かなり現実的だ。
Googleが今回示したのは、単なる新モデルの投入ではなく、AI開発環境の作法そのものの更新だと思う。強いモデルを一つ選ぶのではなく、強さの違うモデルを、場面に応じてつなぎ替える。その方向に、プロダクトがはっきり寄ってきた。
参考: Gemini 4 Hydrogen and Orchestrator | Google Antigravity Blog
