Gemini 4 CarbonとHydrogenはペアで真価を発揮します。Carbonが計画を立案し、Hydrogenが実装・構築を担います。Carbonを実行するプランナーAgentにTaskを割り当て、受け入れ基準を備えたサブタスクを作成させたら、それらをHydrogenを実行するワーカーAgentや検証Agentに委ねます。そして2回失敗したタスクはプランナーへと差し戻します。フロンティアモデルの高額な料金を支払うのは、高度な判断が不可欠なターンだけに抑えられます。
なぜGemini 4 CarbonとHydrogenを組み合わせるのか
Googleは2026年11月12日にGemini 4 Hydrogenをリリースし、「エージェント型ワークフローの常用モデル（daily driver）」と位置づけました。その2日前の11月10日には、Gemini APIの変更履歴にてGemini 4 Carbonの一般提供（GA）が案内されています。これにより今月、Googleの最強モデルと高速実行モデルを初めて同じTaskの背後で連携させることが可能になりました。
Google自身によるHydrogenの提案も、まさにこのペア運用を軸に据えています。発表記事では、Carbonがコーディネーターとして機能し、Hydrogenが「分離されたワークスペース全体で変更を同時にビルド・テストするワーカーAgentや検証Agent」を動かせると説明されています。Gemini APIガイドの表現はさらに明快です。インターフェースの設計や難解な課題の解決はCarbonに任せ、コード編集や並行サブエージェントタスク、テストの実行はHydrogenへと委任する、という構成です。
これはモデル固有の機能ではなくオーケストレーションのパターンであり、今すぐご自身のボード上に構築できます。1台のノートPC内のスクリプトではなく、ボード上でパターンを一元管理したいなら、TaskやAgent、レビューが集約されるSharklyが最適です。
GoogleのOrchestratorが何をするのか：1段落で解説
OrchestratorはGoogle Antigravity内のモデルオプションであり、1つの会話の中でプランナー（CarbonまたはArgon）とHydrogenを自動で切り替えます。Antigravityのドキュメントによると、プランナーはまず読み取り専用フェーズから着手し、再計画の明確なトリガーを含む計画書を作成した上で、実行をHydrogenに引き渡します。そしてHydrogenは何らかの障害や摩擦（friction）に直面した際に制御を差し戻します。
ドキュメントには、大いに参考となる3つの摩擦シグナルが挙げられています。
- 検証ステップが2回連続で失敗したとき。
- インターフェースの動作が計画の想定と異なるとき。
- 計画内で確定していなかった設計上の判断が必要になったとき。
Googleの報告によれば、Terminal-BenchにおいてOrchestratorはCarbon単体に迫るタスク成功率を達成しつつ、クォータ消費を24%削減し、平均19%高速に処理を完了しました。なお、ベンチマークのバージョンに関してはGoogleの2つの記事間で相違があり（発表記事では4.0、Antigravityの記事では4.1）、Googleが統一するまでは単にTerminal-Benchと言及しておくのが無難です。
Orchestratorは会話内で単一のエージェントとして振る舞い、思考レベル（thinking-level）を調整できない固定構成で動作し、Carbon版はGoogle AI Ultra限定と案内されています。一方、チーム用のボードを活用すれば、この役割分担を複数のAgentに分散させ、計画と引き継ぎのプロセスをチーム全員に可視化できます。
コストの観点：Gemini 4 HydrogenとCarbonの価格比較
以下は、2026年11月13日時点のGemini APIの料金ページに基づくトークン単価です。
| モデル | APIモデルID | 入力 / 1M | 出力 / 1M | 無料枠 |
|---|---|---|---|---|
| Gemini 4 Carbon | gemini-4-carbon |
11月30日まで$2.00、以降$4.00 | 11月30日まで$10.00、以降$20.00 | なし |
| Gemini 4 Hydrogen | gemini-4-hydrogen |
$1.50 | $7.50 | あり（レート制限付き） |
予算を組む前に日付をよく確認してください。11月30日までは、Hydrogenのトークン単価はCarbonより25%安いだけですが、12月1日以降は62.5%も安くなります（どちらの数値もGoogleの定価に基づく試算です）。
これが1回の実行にどう影響するかも試算してみました。たとえば、20万トークンを読み込み、4万トークンを出力するワーカーの1ターンを想定します（出力には思考トークンを含みます）。12月1日以降のCarbonでは、$0.80 + $0.80 = $1.60になります。一方、Hydrogenであれば、$0.30 + $0.30 = $0.60です。スプリント期間中にこれを1日30回実行すれば、その差額は決して誤差では済まなくなります。
さらに、トークン単価の比較だけでは実際の差を過小評価してしまいます。Googleによると、Carbonは「仮説の検証やエッジケースの確認のため、1ターンあたりにより多くの思考トークンを消費する」とされており、出力の課金にはこの思考トークンも含まれます。したがって、まったく同じ編集作業でも、Carbonでは単価が高くなるだけでなく、請求対象の出力トークン数自体も増える可能性が高いのです。Googleはこのペア運用のタスク別コストを公表していないため、具体的な削減見込みを見積もる際は、必ずご自身のリポジトリで測定してください。
もうひとつの大きな要素が速度です。Googleの報告によると、Hydrogenはデフォルトのhigh設定時において、Gemini 3.8 Flashよりも2.5倍高速にタスクを完了します。
エージェントチームでの作業分担：モデルと役割のマッピング
プランナー／ワーカーの分業制とは、明確に定義された役割分担です。1つのAgentが計画策定と難易度の高い判断を担当し、より低コストなAgentが実行を担い、人間が確認する前に検証Agentが成果物をチェックします。各役割には、その業務内容に見合ったコスト感と能力深度を持つモデルを割り当てます。
| 役割 | モデル | 思考レベル | 担当業務 |
|---|---|---|---|
| プランナー | gemini-4-carbon |
デフォルトmedium、難度の高いTaskはhigh |
コードベースの読み込み、受け入れ基準付きサブタスクの作成、再計画 |
| ワーカー（1〜n） | gemini-4-hydrogen |
high（デフォルト） |
コード編集、パッケージ更新、テスト実行（各エージェントがサブタスクを1件ずつ担当） |
| 検証者（Verifier） | gemini-4-hydrogen |
high、リスクの高い差分にはxhigh |
プランナーが定めた受け入れ基準に沿った検証の実行 |
| 人間 | 対象外 | 対象外 | 大規模なTaskにおける計画の承認、最終成果物の受け入れ |
この表を構成するにあたり、Googleのドキュメントに記載された2つの重要ポイントを反映しています。まず、CarbonとArgonのデフォルトはmediumで上限がhighであるのに対し、Hydrogenはデフォルトがhighでxhighにも対応しています。さらにGoogleは、xhighはレイテンシとトークン消費量を増加させ、「平易なプロンプトでは過剰な思考（overthinking）を引き起こす可能性がある」と警告しています。したがって、認証、決済、データ移行などに触れる差分を検証する場合に限定して、検証Agentにxhighを適用するのが賢明です。
プランナーは何を記述すべきか
プランナーの出力は、後続のすべてのAgentに対する契約書（コントラクト）となります。優れた計画には、独立した変更ごとのサブタスク、それぞれの対象ファイルスコープ、動作を証明するコマンド、そして差し戻しの条件が網羅されています。ワーカーがいつ作業完了と見なせるのか判断できない状態なら、その計画はまだ未完成です。
どのような場合にプランナーへ作業を差し戻すか
Googleのトリガー条件を参考に、ルールを明文化しておきましょう。チェックが2回失敗したとき、インターフェースが計画と一致しないとき、あるいは設計上の判断が必要になったときに、ワーカーはサブタスクを差し戻します。その際、ログ、ここまでの差分、そして疑問点を添えて返します。より上位のモデルで勝手に再試行させてはなりません。安価な実行層のコストメリットが、高額モデルの請求額の中に埋もれて見えなくなってしまうからです。
Sharklyでの設定手順
Sharklyにおいて、Agentとは接続されたComputer上のRuntimeを通じて動作するAIチームメイトであり、Crewとは1つのリーダーAgentによって統括されるAgentと人間のグループです。この構造は、グルーコードを一切書くことなくプランナー／ワーカーの分業モデルにそのまま当てはまります。プランナーがCrewリーダーとなり、ワーカーや検証AgentがCrewメンバーとなります。
上のパネル（Claude Codeを実行している例）のように、各Agentは独自のRuntimeとDefault modelを保持します。今回のセットアップでは、各AgentにGemini CLIなどGemini APIにアクセス可能なRuntimeを割り当て、Agentごとにモデルを設定します。プランナーにはCarbonを、それ以外のAgentにはHydrogenを指定してください。モデル一覧にまだ新しいIDが表示されていない場合は、Runtime側の設定でモデルを指定します。また、設定リファレンスにもある通り、Gemini CLIはGEMINI_MODEL環境変数を読み込むことができ、SharklyのAgentはAgentごとの環境変数設定にも対応しています。
次に、連携ルールをCrewの指示（instructions）に記述します：
CREW: carbon-plans-hydrogen-builds
Leader: planner (gemini-4-carbon)
1. Read the Task and recent comments. Explore read-only first.
2. Post a plan as a comment: one sub-task per independent change,
file scope, the check command, and the re-plan trigger.
3. If the Task touches more than 3 modules, wait for a person to
approve the plan before mentioning any worker.
4. Mention one worker per sub-task. Mention the verifier last.
Workers: worker-a, worker-b (gemini-4-hydrogen, high)
- Do one sub-task. Run its check. Report the diff and the result.
- If the check fails twice, stop. Report the log and the question
to the leader. Do not widen scope.
Verifier: verifier (gemini-4-hydrogen, high; xhigh for auth/payments)
- Re-run every check from the plan. Pass or fail each one, with output.
A person accepts the result. Nobody merges on an Agent's word.
設定後、TaskをCrewに割り当てます。Crewsのドキュメントにある通り、実行はリーダー主導で進みます。リーダーがTaskとCrewの指示を読み取り、特定の作業ごとにメンバーをメンションして依頼し、その結果が同じTaskへと集約されます。ワーカーごとに個別のワークツリーが割り当てられるよう、一時作業ディレクトリを使用してください。Crewの共有Taskディレクトリを有効にするのは、サブタスク同士が互いのローカル変更を順番に積み重ねていく必要がある場合のみに限定しましょう。
作業がブロックされても状況は見失われません。失敗やブロックが発生した実行はInboxに集約され、人間の対応を待っているAgentはサイドバーのTask Chatsに表示されます。プランナー自身でも計画を修復できない場合、図の破線矢印の先としてここに行き着くことになります。
高度なテクニック
長期間に及ぶTaskにはAPIのモデル切り替えを活用する：Googleのドキュメントによると、スキーマを変更することなく、previous_interaction_idを用いて1つのマルチターンセッション内で計画ターンをgemini-4-carbonに、実行ターンをgemini-4-hydrogenへとルーティングできます。これはOrchestratorの仕組みをご自身のコード上で再現するアプローチであり、単一のAgent実行内で非常に役立ちます。
ホップごとの出力サイズに留意する：ストリーミングを使用しない場合、1ホップあたりHydrogenは最大65,536トークンを返しますが、CarbonやArgonの非ストリーミングRESTホップでは32,768トークンにとどまります。テストスイートやマイグレーション仕様の作成など、大量のテキスト生成を伴う作業はワーカー側に任せるのが得策です。
Hydrogenでは明示的キャッシュを省く：Hydrogenは明示的なコンテキストキャッシュ（explicit caching）をサポートしていません。一方で、4,096トークン以上のプロンプトに対して暗黙的キャッシュ（implicit caching）が適用され、キャッシュされた入力トークンは95%割引されます。そのため、各ワーカーのプロンプトの先頭に共有リポジトリのコンテキストを配置するようにしてください。
プランナー／ワーカー分業制に代わる選択肢
- Hydrogen単体：Googleのドキュメントでは、パッケージの更新、重複コードの排除、スキャフォールディング、仕様が明確な関数の単体テスト作成、ドキュメント作成などに推奨されています。この場合、プランナーは不要です。
- Carbon単体：分散システムの設計、レースコンディションの調査、複数リポジトリにまたがるマイグレーションなど、すべてのステップで深い思考力が要求されるケースに適しています。
- AntigravityのOrchestrator：対象プランに含まれている場合、1人のユーザーが1つの会話内で自動引き継ぎを利用するのに適しています。
- 静的ルーター：事前にTaskを分類して特定のモデルに振り分けます。ただしGoogleは、タスクの途中で難易度が変化する長期的な実行においては、この方式が破綻しやすいと指摘しています。事前分類方式については、Gemini Decisions APIを用いたエージェントTaskのルーティングで解説しています。
実践的なユースケース
大量のIssueのトリアージ：Google自身のAntigravity SDKデモでは、トリアージやコーディングを担当するHydrogenエージェントと、リファクタリング、新機能開発、セキュリティチェックを担当するCarbonエージェントをペアリングしています。ボード上で運用する場合、受付キューにHydrogen Agentを配置し、「refactor」や「security」のラベルが付いたタスクにはCarbonリーダーを割り当てる形になります。
機能を並行サブタスクに分割：プランナーがAPIの変更をスキーマ更新、ハンドラー更新、クライアント更新へと分割し、3つのワーカーが別々のワークツリーでこれらを並行実行し、最後に検証Agentがコントラクトテストを実行します。
まとめ
Carbonが計画し、Hydrogenが構築し、人間が成果物を受け入れる。12月1日以降の価格改定によってこの分業の費用対効果はさらに高まり、摩擦トリガーによって安価な失敗が高額な再試行に膨らむのを防ぎ、ボードによってあらゆる引き継ぎがTask上でチーム全体に可視化されます。より広範なパターンについては、AIエージェントのオーケストレーションとはや、当社のCrewにおけるモデルルーティングのルールをご覧ください。
次のステップとして、まずは1台のComputerをSharklyに接続してみましょう。CarbonのプランナーAgentとHydrogenのワーカーAgentを1体ずつ作成し、上記の指示を与えたCrewに配置したら、普段なら人が半日かけて行うようなTaskを割り当ててみてください。SharklyにはFreeプランがあるため、この検証にかかるコストはGeminiのトークン費用のみです。
よくある質問（FAQ）
Gemini 4 CarbonとHydrogenの違いは何ですか？
CarbonはGoogle最強のフロンティアモデルであり、長期的な推論や難解なアーキテクチャ設計、デバッグ、セキュリティ検証のために設計されています。一方のHydrogenは、日々のコーディングやエージェント実行に向けた高速かつ高効率なGemini 4モデルです。思考レベルは、Carbonがデフォルトでmedium、上限がhighであるのに対し、Hydrogenはデフォルトでhigh、さらにxhighにも対応しています。
Gemini 4 HydrogenはCarbonよりも安価ですか？
はい、安価です。Hydrogenは入力100万トークンあたり$1.50、出力100万トークンあたり$7.50です。Carbonは2026年11月30日まで入力$2.00・出力$10.00、12月1日以降は入力$4.00・出力$20.00となります。さらに、Gemini APIにおいてHydrogenにはレート制限付きの無料枠がありますが、Carbonには無料枠がありません。
検証AgentはHydrogenではなくCarbonで動かすべきですか？
基本的にはその必要はありません。Googleは並行して動作するワーカーAgentや検証AgentとしてHydrogenを推奨しています。リスクの高い差分に対しては検証Agentの思考レベルをxhighにし、チェックが2回失敗したときに限ってTaskをCarbonのプランナーへとエスカレーションするのが適切です。
SharklyがTaskごとにモデルを自動選定してくれるのですか？
いいえ、自動選定ではありません。各AgentのRuntimeを通じてモデルを設定し、Taskのどの部分をどのAgentが担当するかはCrewの指示によって決定されます。SharklyはTask、実行プロセス、引き継ぎ、そしてレビューを一元管理する役割を担います。
