Gemini 4 Hydrogen解説：日常のコーディングとエージェント業務での選び方

Gemini 4 Hydrogenは、日常的なコーディングやエージェント業務でまず評価したいモデルです。より深い推論が必要な仕事には、CarbonやArgonを使い分けます。2026年11月12日に公開されたHydrogenは、Gemini 4の中で実行の速さを重視した選択肢です。定型的な修正のたびに、最先端の推論モデルを使う必要はありません。

Gemini 4 Hydrogenで何が変わるのか

実行用のモデルを独立して選べるようになります。 エージェントとは、リポジトリ内のファイルの読み取り、コードの変更、テストの実行といった操作をモデルに行わせるソフトウェアです。Googleは、こうしたワークフローを素早く実行するモデルとしてHydrogenを位置づけています。一方、Gemini 4 CarbonとGemini 4 Argonは、長時間にわたる難しいタスクでの深い推論を担います。

個人開発者なら、バグの場所を特定し、範囲を絞って修正し、チェックを実行して変更内容を説明する、という日々の作業で評価できます。創業者にとっての判断材料は、未解決の設計判断には深い推論を残しつつ、日常的な開発を待ち時間とレビューの負担を抑えて終えられるかどうかです。

Googleの発表記事では、リポジトリでのコーディング、デバッグ、エージェントによる実行を主な用途に挙げています。開発者向け記事では、対話型のWeb開発や、複数の種類のメディアを扱う作業にも触れています。これらはGoogleによる性能の説明であり、本記事ではモデルの実機テストを行っていません。

2026年11月14日に確認： 本記事のために、発表記事、開発者向け記事、モデルカード、APIドキュメントを確認しました。以下の導入基準は、それらの情報に基づく編集部の提案です。

Gemini 4の各モデルは、どんな仕事に向いているのか

作業内容が明確ならHydrogenから始め、調査を深める必要が出たら上位の推論モデルに切り替えます。 Googleの現在のモデル選択ガイドでは、Carbonを最も強力なフロンティアモデルとし、Argonは高度で長期的なタスクの多くをCarbonより少ないトークンで処理すると説明しています。ここでいう長期的なタスクとは、推論、操作、修正を繰り返しても、一貫性を保つ必要がある仕事です。

これは用途ごとの選択であり、あらゆる仕事に通用する順位ではありません。難しいバグも、最初は普通の修正に見え、途中でアーキテクチャ上の問題が明らかになることがあります。見極めたいのは、エージェントが何を変更すべきか理解しているのか、それとも正しい変更が何かをまだ探っているのか、という境目です。

中堅企業のCTOは、現在の合格基準を維持してください。同じテストとレビュー基準を満たす修正を、より少ない総工数で出せるなら、Hydrogenの担当範囲を広げる根拠になります。Argonがすでに完遂できている難しい仕事では、引き続き比較の基準にできます。未検証の仮説やエッジケースが障害なら、Carbonへの切り替えを検討します。

Carbonの解説記事では、初期リリースと推論重視の特性を扱っています。ただし、公開当時の利用条件に関する評価は、Hydrogenの展開前のものです。Argonの解説記事では、長時間の仕事での選び方を扱っています。今回のリリースの利用経路は、次の節を参照してください。

Hydrogenはどこで使えるのか

HydrogenはGoogleの個人向け、開発者向け、企業向け製品に展開されていますが、利用条件はそれぞれ異なります。 Googleの発表では、次の経路が挙げられています。

• Geminiアプリ： 発表されたモデル展開にHydrogenが含まれます。ただし、注記が重要です。無料ユーザーは、プロンプトに適していると判断された場合に、自動モデル選択を通じて利用できます。無料で使えることは、いつでもHydrogenを指定できることを意味しません。
• Google AI StudioとGemini API： GoogleのAPIガイドには、無料枠と有料枠の両方が明記されています。無料API枠にはレート制限があります。
• Gemini for business： Googleは、APIまたはモデルのドロップダウンからの利用を案内しています。納期を設定する前に、組織のアカウントで予定している経路が使えるか確認してください。
• Google Search： Googleは、世界中のすべてのユーザーに向けた展開を発表しています。検索での利用は、モデルによる回答を受け取るためのものであり、自分のアプリ向けのAPI利用権ではありません。
• Google Antigravity： 有料のGoogle AI ProおよびUltra契約者向けにHydrogenが展開されています。Orchestratorには、後述する追加のプラン別条件があります。

API料金、2026年11月14日確認： GoogleのHydrogen APIガイドによると、通常の有料利用は入力100万トークンあたり$1.50、思考を含む出力100万トークンあたり$7.50です。コンテキストウィンドウの長さによらず同一料金で、グラウンディング料金は別途かかります。

アシスタントを試す業務担当者なら、アプリの自動選択で十分かもしれません。同じ仕事を繰り返し評価する開発者は、モデルを指定し、設定を記録できる経路を使ってください。Geminiの無料利用ガイドでは、アプリと開発者向けサービスの利用条件の違いを詳しく説明しています。

思考レベルはhighから始め、用途に合わせて調整する

Hydrogenにはlow、medium、high、xhighがあり、初期設定はhighです。 思考レベルは、モデルが推論にどれだけの労力をかけるかを制御します。知識の異なる別モデルというより、操作に移る前に問題を検討する時間の配分と考えるとわかりやすいでしょう。

Googleは、複雑なコーディングやエージェント業務の多くにhighを推奨しています。対話型コーディング、UIの試作、遅延を抑えたいツール呼び出しにはmedium、応答時間とトークン使用量が特に重要な仕事にはlowを挙げています。xhighは、highでは対応しきれない、難しく複数の手順を要する問題のために残しておきます。

ページレイアウトを調整する開発者なら、mediumで合格基準を保ちながら、修正の往復を速められるかを確認します。難しい文書一式を突き合わせる業務担当者なら、highから始め、回答が適切な根拠を引用しているかを調べます。推論の労力を増やす価値があるのは、合格する成果が改善するときだけです。

モデルを比較するときは、思考レベルを明示的に設定してください。 CarbonとArgonの初期設定はmedium、Hydrogenはhighです。初期設定のまま比較すると、モデルと同時に推論設定まで変わってしまいます。Googleはまた、xhighでは遅延とトークン使用量が増え、単純なプロンプトでも考えすぎる場合があると注意しています。

把握しておきたいコンテキストと出力の上限

Hydrogenの1,048,576トークンのウィンドウは、入力と出力で共有されます。 トークンとは、モデルが読み取る内容や生成する内容を表す単位です。出力には思考、関数呼び出し、最終回答が含まれるため、入力を大きくすると、その後の処理に使える余裕が減ります。

Google Cloudのモデル仕様では、ストリーミングの有無にかかわらず、フォアグラウンドの1区間あたりの出力上限を65,536トークンとしています。長い応答を継続するGoogleの仕組みであるLong decodeを使うと、共有ウィンドウから入力トークンを引いた範囲まで出力を延長できます。入力100万トークンに加えて、さらに出力100万トークンを使えるわけではありません。

リポジトリの移行で全ファイルを読み込むと、必要な推論や変更の生成に使う余地を圧迫しかねません。関係するコードと制約を渡し、応答用の空きを残してください。文書ワークフローでも、大量に読み込めるからといって、すべての表や例外を正しく解釈できるとは限りません。

APIガイドによると、この経路で長い応答を得るには、バックグラウンド実行と、より大きなmax_output_tokensの設定の両方が必要です。background=trueを設定するだけでは、初期設定の停止位置が維持されます。通常の対話型タスクで巨大な応答が役立つことは多くありません。有用な成果物を作るうえで、その容量が本当に必要なときにLong decodeを使ってください。

Flashからの移行ではリクエスト設定を点検する

Gemini 3.8 Flashからの更新は、モデル名の変更だけでは完了しません。 Googleの移行チェックリストでは、次の設定に注意するよう求めています。

• 従来の思考予算の指定を、対応する思考レベルに置き換えます。MINIMALとthinking_budgetは拒否されます。
• temperature、top_p、top_kの独自設定に依存しないようにします。Hydrogenは、許容範囲内のカスタムサンプリング値を無視します。
• 明示的なコンテキストキャッシュのリクエストを削除します。Hydrogenは暗黙的なキャッシュを使います。
• 場当たり的に生のテキストでツール呼び出しを出させるのではなく、ネイティブの関数呼び出しでツールを宣言するか、JSONには構造化出力のスキーマを使います。
• Googleのガイドに従い、ツールを介したターンの間で、会話の状態とthought signaturesを保持します。thought signaturesは、モデルが付与する推論状態の情報です。

CTOは、性能比較より先にこの点検を行うべきです。そうしなければ、連携の不具合をモデルの性能不足と見誤ったり、黙って無視される設定が比較を無効にしたりするおそれがあります。Cloudの仕様では、Gemini Live APIは非対応とも記載されています。既存のライブセッション連携には、別途互換性の判断が必要です。

AntigravityのOrchestratorで何が変わるのか

Google Antigravityでは、同じセッション内で計画用と実行用のモデルを切り替えられます。 Orchestratorは、最初のプロンプトだけで仕事全体の担当モデルを決めるのではなく、タスクの進み方に応じて対応します。

Googleの例では、Carbonが依存関係を調べて計画を立て、Hydrogenが修正とテストを実行します。実行中に推論の見直しが必要な問題に直面すると、Carbonに仕事を戻します。この戻り経路こそが重要です。前提が崩れた後も、作業用モデルが同じ計画を無理に押し通す必要がなくなります。

Antigravityの展開に関する記事では、Google AI Ultra契約者向けにOrchestrator (Carbon)とOrchestrator (Argon)、有料のGoogle AI Pro契約者向けに**Orchestrator (Argon)**を案内しています。企業はGemini for businessを通じて両方を利用できます。Hydrogenが使えるだけで、すべてのOrchestrator構成を利用できるわけではありません。

創業者なら、明らかな修正から設計上の検討へと頻繁に発展する機能開発で、Orchestratorを評価できます。エージェントを監督する上級の業務担当者は、引き継ぎ時にタスクの範囲、完了したチェック、未解決の疑問が保持されることを求めてください。モデルの自動選択は、その変更を安全にマージできるかどうかを判断してくれるものではありません。

期待しすぎないために：速いモデルにもレビューは必要

実行を重視したHydrogenでも、あらゆるタスクを確認なしに任せられるわけではありません。 GoogleのDeepMindモデルカードでは、HydrogenはCarbonをもとに調整されたと説明しています。一方で、ハルシネーション、ときおり生じる遅延やタイムアウト、高い思考レベルでのトークン使用量の増加も挙げています。

同カードでは、特にマルチモーダルのプロンプトで、Gemini 3.8 Flashより不当な拒否が多いことも報告しています。文書や画像を処理する業務担当者にとっては、難しいケースだけでなく、通常の正当な依頼も評価に含める具体的な理由になります。仕事を拒否するエージェントと、誤った回答を出すエージェントでは失敗の種類が異なりますが、どちらも完了に影響します。

共有コンテキストの上限も、計画上の制約として維持する必要があります。長い出力は容量を示すものであり、正確さの証明ではありません。生成量を評価するのではなく、確認の経緯を追える、レビュー可能な成果物を求めてください。

公開、本番環境の変更、顧客への連絡など、影響の大きい場面では承認を残してください。モデルの更新によって、その範囲内での仕事が改善しても、最終判断を担う人まで変える必要はありません。

よくある質問

Gemini 4 Hydrogenは無料で使えますか？

はい。ただし条件があります。Geminiアプリの無料ユーザーは、プロンプトに適している場合、自動モデル選択を通じてHydrogenを利用できます。Googleは、AI StudioとGemini APIにもレート制限付きの無料枠を設けています。AntigravityでのHydrogen展開は、有料のGoogle AI ProおよびUltra契約者が対象です。

Gemini 4 HydrogenはCarbonより優れていますか？

日常的な実行業務では、まずHydrogenを評価するとよいでしょう。Googleは引き続き、難しい推論、仮説検証、エッジケースに対応する最も強力なフロンティアモデルとしてCarbonを位置づけています。合格する成果、所要時間、レビューの負担を基準に選んでください。Hydrogenの公開によって、あらゆる用途でCarbonを上回ると示されたわけではありません。

Gemini 4 HydrogenはFlashの後継ですか？

Googleは、Gemini 3.8 Flashおよびそれ以前のモデルからの更新先としてHydrogenを推奨しています。ただし、この推奨は、すべてのFlashエンドポイントが停止したことを意味しません。Googleのガイドでは、大量の分類処理、ルーティング、非常に低い遅延が求められる用途には、別途Flash-Liteを選択肢として残しています。Flashファミリー全体をHydrogenと同じように扱うことはできません。

次に取り組むこと：範囲を絞ったワークフローで評価する

ワークフロー全体を移す前に、代表的なタスクを評価にかけてください。 個人開発者なら、慣れたリグレッション修正が使えます。CTOなら、定期的な保守作業の評価担当者を決められます。上級の業務担当者なら、正解がわかっていて確認可能な文書一式を使えます。

1. 1

   比較基準と合格判定をそろえる

   現在のモデルとHydrogenで、同じタスク、入力、利用を認めるツール、期待する結果を保存します。コードでは、関連するテストとレビュー可能なパッチを求めます。文書では、結論を支える根拠を求めます。

2. 2

   連携を点検し、思考レベルを明示する

   リクエスト設定、コンテキストの余裕、ツール宣言を点検します。複雑な仕事はhighから始め、待ち時間が重要な場面ではmediumを評価します。使用量に加えて、呼び出しの失敗、不完全な回答、レビュアーによる修正も記録してください。

3. 3

   合格する成果が改善した仕事だけに広げる

   より少ない総工数で、十分な品質で終えられる仕事にHydrogenを採用します。推論の負荷が高い未解決の仕事にはCarbonやArgonを残し、同じタスクで計画と実行の両方が繰り返し必要になるならOrchestratorを評価します。成果が合格に達しているか、まだ測れない場合は導入を待ってください。

モデル選択やワークフローの実践的な判断については、ニュースレターをご購読ください。