Gemini 4 Argon（ジェミニ4 アルゴン）の使い方考える強さは3段階で試して一番低い段階、temperatureは無視、出力の上限は3万2768以上、Googleが/goalで11時間走らせた頼み方

2026年10月14日朝・日本時間時点の情報です。Googleは、10月14日に一般公開した Gemini 4 Argon（ジェミニ4 アルゴン） をうまく使うための推奨を、Gemini APIとGoogle Cloudの開発者向けドキュメントに載せている。Google Developers Blogには、Googleの社員がArgonに20万行を超えるPythonのコードを一晩で速くさせた時のプロンプトの原文も出た。この記事では、それらをAI時短ラボが突き合わせて、考える強さの選び方、無視される設定、出力の上限、長い出力、プロンプトの書き方、Googleの頼み方の順に整理した。同じ内容を動画でも解説している。

3行まとめ

1. 考える強さ（thinking_level）はlow・medium・highの3段階で既定はmedium。Googleは「3段階で試して、品質に届く一番低い段階を選ぶ」よう勧めている。考えた分も出力として課金される。
2. temperature・top_p・top_kは無視され、thinking_budget・MINIMALなど5つの設定はエラーになる。出力の上限（max_output_tokens）は考える分を含むので3万2768以上にし、減らしたい時は考える強さを下げる。
3. Googleは、1段落のゴール＋チームの決まり（.agents/skills）＋Antigravityの/goal＋「前後の数字つきのプルリクエストを1本」の2文で、Argonを11時間無人で走らせた。ADKの長い会話の下準備は約40%短くなった。

材料はどこから──Gemini 4向けの節は、設定の話だけ

中心になるのは、Gemini APIのドキュメントにある「What's new in Gemini 4 Argon」というページだ。そこから「Long decode（長い出力）」と「Thinking（考える強さ）」のページにつながっている。Google Cloud側には「Developer's guide to Gemini 4 Argon」があり、エラーになる設定や会話の決まりはこちらのほうが細かい。

プロンプトの書き方については、10月14日朝に取得したGemini APIの「Prompting strategies」のページでは、書き方の節の見出しは「Gemini 3」のままだった。このページの書き方の中身でGemini 4の名前が出るのは、temperatureなどの設定が無視されるという注意書きだけだ。なので、書き方はGemini 3向けの節を使うことになる。

ドキュメントの多くはAPIで使う開発者向けだが、考える強さの選び方はAntigravityで使う人にも関係する。AI時短ラボのGoogle AI Ultraの環境では、AntigravityでArgonの考える強さをLow・Medium・Highの3つから選べた。

考える強さ（thinking_level）──3段階で試して、品質に届く一番低い段階を選ぶ

What's new in Gemini 4 Argonの表をまとめるとこうなる。

Google Cloudのガイドはもう少し具体的で、highは何ファイルにもまたがるソフトウェア開発・証明・設計・脆弱性探し、mediumは普段のコード・道具を使う仕事・資料への質問・動画の理解、lowは分類・要約・メタデータの抜き出し、と書いている。

迷ったら全部highにすればよさそうに見えるが、公式の勧めは逆だ。

Run your evaluations at all three levels, then pick the lowest level that meets your quality bar.

（3つの段階すべてで評価を回して、品質の基準を満たす一番低い段階を選んでください。）

料金の面でも理由がある。What's newの料金欄では、出力の料金に考えた分のトークンが含まれる（"Output tokens, including thinking tokens"）。強さを上げれば、そのぶん払う。

Argonで無視される設定と、エラーになる設定

ここからはAPIで使う人向けの話だ。

• 無視される: temperature・top_p・top_k。Gemini APIの「Prompting strategies」によると、Gemini 4とGemini 3.6以降は入れた値を無視して、使わなくなる予定だという警告のヘッダーを返す。将来のリリースではエラーになると書かれている。答えの調整は、考える強さと構造化出力（response_schema）で行うようGoogle Cloudのページが案内している。
• エラーになる: thinking_budgetとMINIMALはHTTP 400エラー。Google Cloudの移行の表では、Gemini 3.1 Proは thinking_budget を近い段階に読み替えていたが（"Mapped to a thinking level"）、Argonでは読み替えずにエラーを返す。frequency_penalty・presence_penalty・candidate_countもエラーになるので、リクエストから消す。
• 手動のキャッシュは使えない: そのかわり、前と同じ書き出しは自動でキャッシュされ、キャッシュから読んだ入力は95%引きになる。毎回同じ長い資料（コードや文書）は、プロンプトの先頭に置くと得になる。
• 会話の決まり: Google Cloudのガイドによると、AIの返事の書き出しをこちらで先に書いておく使い方（プリフィル）はできず、会話の履歴をAIの発言で終わらせることもできない。

出力の上限は3万2768以上──減らしたい時は上限でなく考える強さを下げる

max_output_tokensは、考えた分と答えの分を合わせた上限だ。What's newはこう書いている。

Gemini 4 Argon can spend more of the limit on thinking than earlier models.

（Gemini 4 Argonは、前のモデルより上限の多くを考えることに使うことがあります。）

そのため、今の上限が3万2千より低いアプリは3万2768以上に上げるよう勧めている。Long decodeのページは、8192のような低い値だと考えている途中で止まると書く。上限を下げても考え方は短くならない。

Lowering it doesn't make the model think more concisely, and instead cuts the response off sooner.

（上限を下げても、モデルが短く考えるようにはなりません。返事が早く途切れるだけです。）

トークンを減らしたい時は、考える強さを下げる。

6万5536トークンを超える長い出力の出し方と、使わない方がいい場面

1回で出せるのは、考えた分と合わせて65,536トークンまで。それを超える時は、続きを何回かに分けてつなぎ、入力の分を引いた100万トークンまで伸ばせる。Gemini APIでは、backgroundをオンにして上限を65,536より大きくすると、つなぎはサーバーが自動でやる。backgroundをオンにしても上限を決めていないと、64Kトークンで止まる。

Long decodeのページの目安はこうだ。

What's newのページは「Complex reasoning and coding」を131,072か262,144としていて、コーディングの目安がLong decodeのページと一段ずれている。この記事の表はLong decodeのページに合わせた。

逆に、この長い出力を使わない方がいい場面も書かれている。チャット・質問への答え・要約・分類・抜き出しは3万2千トークンよりずっと手前で終わる。道具を細かく何度も呼ぶエージェントは、1回ごとの出力が大きいと分け合う100万の枠がすぐ埋まる。すぐ返事がほしい用途は、長い出力が数分かかることがあるので向かない。待つ時間の上限は15分以上にするか、backgroundで動かすよう書かれている。

文字数の指定にも注意がいる。Long decodeの表では「70万語の本を書いて」のような依頼に、こう添えている。

The model doesn't follow length targets.

（モデルは長さの目標に従いません。）

だから頼む時は、何文字で、ではなく、何をどんな構成で書くかを伝えるほうが確かだ（ここはAI時短ラボの読み）。途中で切れた時も、「続けて」と送ったり途中までの答えを会話に足したりはせず、続き用のトークン（continuation_token）を付けて最初と同じ依頼を送り直す、とGoogle Cloudのガイドにある。公式のSDKはこれを自動でやる。

プロンプトの書き方──公式ページのGemini 3向けの節

前の節のとおり、Argon専用の節ではなくGemini 3向けの節の内容だ。

1. 狙いをはっきり短く書く。相手を説得するような余計な言葉は入れない
2. XMLのタグ（<context> や <task>）か、Markdownの見出しで、指示・資料・質問を区切る。1つのプロンプトの中ではどちらかに統一する
3. 大事な制約・役割・答えの形は、システム指示かプロンプトの一番最初に置く
4. 長い資料は先に全部渡し、質問は一番最後に置く。間に「Based on the information above...（上の情報をもとに）」のような一言を入れてつなぐ
5. 何も言わないと、直接的で無駄のない答えを返す。詳しく、会話っぽく答えてほしい時はそう書く
6. モデルが自分で考えるので、答えの中に計画や手順を書かせる必要は基本的にない。難しい問題なら「Think very hard before answering」のような簡単な一言で良くなることがあり、そのぶん考えるトークンは増える

4つ目の並べ方は、自動キャッシュのために長い資料を先頭に置く話と同じ向きになる。

Googleの社員がArgonを一晩11時間走らせた時の頼み方

Google Developers Blog（10月13日）は、GoogleがオープンソースのADK（エージェントを作るための道具）を、Argonに速くさせた記録を出している。約20万5千行・約800ファイル・約1万7千個のテストがあるPythonのコードだ。

1回目は、リポジトリの決まりを何も渡さず、1段落の指示だけで頼んだ。

Make ADK add no noticeable overhead to any agent: at startup, in long sessions, in multi-agent and workflow setups. Keep what the model receives and the public API unchanged, and back each change with a test that would catch a regression.

（どんなエージェントでも、起動時・長いセッション・複数エージェントやワークフローの構成で、ADKのせいで目立つ遅れが出ないようにして。モデルが受け取る中身と公開しているAPIは変えず、変更ごとに、壊れたら気づけるテストを付けて。）

記事によると、Argonは7分で速さを測るプログラムを書き、ADKのコードを最初に直したのは70分後だった。約2時間で本当に遅い所を見つけ、その一部は最終的に取り込まれた。一方で、チームの決まりを知らないまま認証の設定の公開しているJSONの形を変え、テストは近くの216個しか回さず、変更の説明に数字を書かなかった。

2回目は、2つを足した。 1つ目は、チームの決まりを .agents/skills に置いたこと。入口のSKILL.mdは短い目次だけにして、細かい中身は別のファイルに分け、必要な時だけ読ませた。毎回の文脈を埋めないためだ。2つ目は、Antigravityの /goal。記事は、会話が長くなって要約されてもゴールを持ち続け、終わるまで走らせる機能として使っている。そのうえで、完成の形を2文で足した。

Open one pull request against main that the ADK maintainers would approve, with before and after numbers in its description. Don't merge it.

（ADKのメンテナが承認するプルリクエストを、前後の数字を説明に入れて main に1本出して。マージはしないで。）

Argonは夜9時11分から朝8時19分まで、11時間無人で走った。始める前に決まりのファイルを12個読み、何も直す前に今の速さを測った。テストは全部の16,892個を回し、終わる3分前にも自分の変更を見直して自分で入れたバグを見つけ、自分で止まった。

朝に出てきた提案は32ファイルにまたがる6つで、取り込まれたのは2つ。捨てた4つは、別のセッションの古いデータを返しかねない仕組み、ライブラリの内部に頼る書き方、読みにくくなるだけの書き換え、試験用の再生でしか速くならない仕組みだった。記事はこの分担を「the agent explores, the maintainer subtracts（エージェントが探り、メンテナが削る）」と書いている。取り込んだ2つで、長い会話の下準備は約40%短くなり、ADKの読み込みは21%速くなった。この数字は、Argonに一度も見せていない別の測り方で確かめたものだという。

まとめると、Googleの頼み方は4つだ。

1. ゴールと、変えてはいけない物を1段落で書く
2. チームの決まりを、目次つきの手引き（.agents/skills）で渡す
3. /goalで、終わるまで走らせる
4. 出してほしい物の形（前後の数字つきのプルリクエストを1本・マージしない）を決める

/goalについて、Antigravityの公式ドキュメントは「Instructs the agent to work continuously until the specified objective is fully achieved.（指定した目標を完全に達成するまで、エージェントに作業を続けさせる）」と説明し、途中で1手ずつの確認を挟まないと書いている。先に計画を作らせたい時は /plan がある。Googleの発表記事は、Argonを行き詰まった時に勝手な近道をしないよう鍛え、取り返しのつかない操作の前には人の確認を待つようにした、とも書いている。

資料を突き合わせて気づいたこと

この動画と記事を作るために、Gemini APIとGoogle Cloudの2つのドキュメントを並べて読んだ。

• 自動キャッシュが働く最小の長さは、Gemini APIのページが4,096トークン、Google Cloudのガイドが6,144トークンで、ページによって値が違う。使うサービスのページの値を見るのが確かだ
• 長いコーディングの出力の上限の目安も、What's newとLong decodeのページで一段ずれている（上の表の下に書いた）
• プロンプトの書き方の節は、10月14日朝の時点ではGemini 3向けの見出しのままだった

ドキュメントが出たばかりなので、こうしたずれは今後そろう可能性がある。そろったらこの記事を直す。

このまとめで確かめていないこと

• この記事は公式の推奨の紹介で、AI時短ラボが3段階の考える強さを同じ課題で比べたわけではない。比べる検証は、動画で別に出す予定だ
• ADKの事例の数字（11時間・16,892個・約40%・21%など）は、Google Developers Blogに書かれた値で、こちらで再現はしていない
• 料金は Gemini API の標準の料金（2026年10月14日時点）。

Argonの検証や、ほかのAIとの比較もこのあと動画で出していく。やってほしい検証があれば、動画のコメント欄で教えてほしい。