Gemini 4 Argonで1M出力｜background実行の書き方

Gemini 4 Argon は、1回の応答を最大100万トークンまで伸ばせます。入力・思考・出力が 1,048,576 トークンの1つの窓を共有する統一1Mコンテキストになり、long decode によって1回の応答が64Kを超えて 1,048,576 − 入力トークンのところまで伸びます。ただし何もしなければ64Kで止まります。伸ばすのに必要なのは background: true と max_output_tokens を 65,536 より大きくすることの2つで、どちらか片方だけでは効きません。

この記事は、その2つを入れてから「分割されて返ってくる本文をどう結合するか」までを順番に並べた手順書です。Gemini 4 Argon は 2026年10月13日に GA（一般提供）になったばかりで、Gemini API と Google AI Studio から使えます。提供条件そのものはGemini 4 Argon の提供開始と使える条件をまとめた記事に分けてありますので、「そもそも自分の環境で使えるのか」から確かめたい場合はそちらを先にご覧ください。

なぜ 64K で止まるのか：2つセットで初めて効く

公式ドキュメントの注記は明快です。background: true を付けても、max_output_tokens を指定しなければサーバは 64K で止まります。逆に max_output_tokens を大きくしただけで background を付けなければ、長い応答は生成されません。この2つは片方だけでは意味を持たない組み合わせだと理解しておくのが、最初のつまずきを避ける一番の近道です。

仕組みの側から見ると、サーバは 最大64Kずつの「hop」に分けて生成を継続します。background 実行は、その継続をサーバ側で面倒を見てもらうためのスイッチです。そして hop ごとに結果のステップが増えていくため、受け取り方も従来と変わります。この点が手順6で出てくる「結合」の話につながります。

なお Argon は 統一1Mコンテキストです。入力と思考と出力が別々の枠を持つのではなく、1つの窓を分け合います。したがって長い資料を入力に入れるほど、出力に回せる残りは減ります。1Mまるごとを出力に使えるわけではない、というのが実務上の出発点です。

1回の応答で64Kを超えるための6ステップ

順番に並べると次のとおりです。手順3と手順6を飛ばすと、だいたいここで詰まります。

1. モデルIDを gemini-4-argon にする。long decode は Argon の機能です。
2. background: true を付ける。サーバ側で hop をまたいで生成を継続させるためのスイッチです。
3. max_output_tokens を 65,536 より大きくする。公式が出発点として挙げているのは 131,072 と 262,144 の2つで、上限は 1,048,576 − 入力トークンです。
4. thinking_level を決める。low / medium（既定）/ high の3段で、long decode は high と相性がよいと公式が明記しています。
5. ステータスをポーリングする。in_progress または queued の間は待ち、変わったら次へ進みます。
6. 完了後、interaction.steps のうち type が model_output のステップを全部集め、その中の type が text のコンテンツを結合する。hop ごとに model_output ステップが増えるので、1つだけ読むと本文の一部しか取れません。

手順6は、短い応答しか扱ってこなかったコードから移ってくると一番見落としやすいところです。「出力が途中で終わっている」ように見えて、実は2本目以降の model_output ステップを読んでいないだけというケースがあります。切り分けの観点は64Kで切れる・途中で終わるときの切り分け手順にまとめています。

コード例：Python と REST

Python（Interactions API）

作成・ポーリング・結合の3つをそのまま並べます。generation_config の中に max_output_tokens と thinking_level を入れるのがポイントです。

• import time
• interaction = client.interactions.create(
• 　　model="gemini-4-argon",
• 　　input=...,
• 　　background=True,
• 　　generation_config={"max_output_tokens": 262144, "thinking_level": "high"},
• )
• while interaction.status in ("in_progress", "queued"):
• 　　time.sleep(5)
• 　　interaction = client.interactions.get(id=interaction.id)
• text = "".join(
• 　　content.text
• 　　for step in interaction.steps if step.type == "model_output"
• 　　for content in step.content if content.type == "text"
• )

最後の1行が手順6にあたります。step.type == "model_output" で絞り、content.type == "text" をすべて連結するという形にしておけば、hop が1回でも10回でも同じコードで通ります。interaction.steps[0] だけを読む書き方にしないことが、ここでの唯一の注意点です。

REST

エンドポイントとヘッダは次のとおりです。

• POST https://generativelanguage.googleapis.com/v1beta/interactions
• ヘッダ: x-goog-api-key: (APIキー)
• ヘッダ: Content-Type: application/json
• {
• 　"model": "gemini-4-argon",
• 　"input": "...",
• 　"background": true,
• 　"generation_config": { "max_output_tokens": 262144, "thinking_level": "high" }
• }

多ターンでやりとりを続ける場合は、previous_interaction_id を渡してサーバ側に状態を持たせる形になります。会話履歴を毎回クライアントから積み直す設計から移るときは、ここも書き換えの対象です。

あわせてクライアントのタイムアウトを延ばしてください。公式の移行チェックリストでは、難しいプロンプトは数分かかるため HTTP タイムアウトを最低15分にするよう案内されています。long decode を使うなら、この設定変更は事実上必須です。

また Argon への移行時には、temperature / top_p / top_k を外す（渡しても無視されます）、明示キャッシュ（cachedContents / caches.create）の呼び出しを削除する（Argon では非対応で、暗黙キャッシュが 4,096 トークン以上のプロンプトで既定で有効になり、ヒット時に入力トークンが95%割引になります）という2点もセットで確認しておくと、原因切り分けが楽になります。

max_output_tokens の決め方

公式が示す3つの分類

公式は用途を3つに分けています。そのまま表にします。

2段目が、既存アプリから移ってくる場合に効く項目です。Argon は上限のうち思考に使う割合が従来より大きいため、32K 未満を明示設定したままだと思考で枠を使い切って答えが尻切れになることがあります。「モデルIDだけ差し替えたら答えが短くなった」ときは、まずここを疑ってください。

低すぎても高すぎても困る

そして押さえておきたいのが、max_output_tokens は思考と出力の合計に対する固い上限だということです。両側にリスクがあります。

つまり「とりあえず上限いっぱい」も「安全側に小さく」も、どちらも正解ではありません。実際のプロンプトで何トークン使うかを測ってから決めるのが結局は近道です。入力側を削ってその分を出力に回す工夫は動画や長い資料でトークンを減らす工夫にまとめています。

thinking_level の3段

公式は「3段すべてで評価を回し、品質基準を満たす最も低い段を選ぶ」よう助言しています。long decode で high を使うと出力トークンが伸び、出力価格は後述のとおり思考トークンを含むため、段を1つ下げられるかどうかが費用にそのまま跳ね返ります。最初から high に固定せず、medium で足りるかを測ってみてください。

Mihata でも、お客様の業務にあわせて「どの段で足りるか」をあらかじめ測ってから組むようにしています。長文生成を自社の業務に組み込む段階で迷ったときは、こうした検証ごと引き受ける形も取れます。

費用の注意：出力価格は思考トークンを含む

Gemini 4 Argon の出力価格は、公式表記で "Output price (including thinking tokens)"、つまり思考トークンを含んだ値段です。Standard 段で 1Mトークンあたり $10.00（2026年11月30日まで）、12月1日から $20.00 です。

出力トークン別の概算

long decode は、この価格を1回の応答で一気に押し上げます。概算を出してみます。

50万トークン出す応答は、11月中なら1回 $5.00、12月以降は1回 $10.00 です。1回の応答だけでこの額なので、バッチ処理に組み込むなら件数を掛けた額で見積もる必要があります。12月1日に Standard も Batch も Flex も Priority も、きれいに2倍になりますので、単価の段差を含めた整理はGemini 4 Argon の出力単価と12月の倍額にまとめました。

費用を抑える3つの手当て

費用を抑える手当てとしては、thinking_level を1段下げられないか試す、max_output_tokens を実測値に合わせて絞る、Batch や Flex の段を使う（出力が $5.00・12月から $10.00）という3つが現実的です。Free Tier では Argon は全項目が利用不可なので、無料枠での試し打ちという選択肢はありません。

long decode を使わないほうがいい場面

便利な機能ですが、合わない場面がはっきりしています。

• 同期的に待つ設計のアプリ。HTTP タイムアウトを最低15分確保できない構成では、そもそも完走しません。リクエスト・レスポンスを秒単位で返す前提の API サーバに直結させるのは無理があります。
• 短い応答で足りるタスク。要約・分類・抽出のように数千トークンで終わる処理に background を付けても、ポーリングの手間が増えるだけです。
• 費用の上限を厳しく決めたい処理。max_output_tokens を大きく取ると、難しいプロンプトで枠を使い切ったときの最大費用も大きくなります。1件あたりの上限額を守りたい処理では、枠を絞るほうが設計として素直です。

逆に向いているのは、1本の長い成果物をまとめて生成したいケースです。長い仕様書、コードベース全体に渡る変更、長編の調査レポートなど、途中で切れると価値が落ちるものに効きます。

補足：細かい再試行を自分で握りたい場合

公式には、細かい再試行やバックオフの制御が必要な場合、あるいはインタラクションを保存したくない場合の選択肢として、GenerateContent API 側のクライアント側継続が案内されています。Interactions API 側にも同等の仕組みが "coming soon" とされていますが、時期は示されていませんので、現時点で確定した仕様として設計に織り込むのは避けたほうが無難です。

Interactions API の background 実行は、継続をサーバに任せられる代わりに、再試行の粒度を細かく握れないという性質を持ちます。どちらを選ぶかは「失敗時に自分で何をしたいか」で決まります。

まとめ：この順で確認する

この7行のうちどれか1つでも抜けていると、症状としては同じ「64Kで止まる」「途中で終わる」に見えます。上から順に潰していくのが確実です。

長文生成を実際の業務に載せるときは、設定の正しさよりも「どこまで自動で回し、どこから人が見るか」の線引きのほうが悩みどころになりがちです。Mihata ではそのあたりの設計からご相談を承っていますので、手元で詰まっているところがあればお気軽にお声がけください。