Gemini 4 Argonは2026年10月13日に一般提供（GA）が開始され、Googleの出力上限は従来の64Kトークンから約1M（100万）トークンへと引き上げられました。これにより、モデルは「単一の実行経路（trajectory）で数十万トークンを生成」できるようになります。その仕組みや具体的な利用手順については、Googleの開発者向けガイドで解説されています。なお、通常のプロンプト要求はデフォルトで引き続き65,536出力トークンで停止します。Interactions APIにおいてbackground: trueを指定し、max_output_tokensをより大きな値に設定することで、サーバーは入力トークン数を差し引いた最大1,048,576トークンの上限に達するまで、最大64Kトークン単位のホップを繰り返して生成を継続します。Googleは、難易度の高いプロンプトでは処理完了までに数分かかる場合があると注意を促しています。
公開告知の公式投稿において、二度読みする価値があるのは上限値の数字そのものではありません。真に見るべきは、Googleがその膨大な出力枠を使って何を行ったかです。Googleは、re2やlibgav1といったコアライブラリにおける数万行規模からFuchsia Zirconカーネルの80万行超に至るコードベースのC/C++からRustへの移行に、社内でArgonを活用したと述べています。さらに、それらのリライト成果物は「本番環境へ展開する前に、厳格な自動および手動による監査、エミュレーションテスト、レビューを受けている」と説明されています。モデルを訓練した当の研究ラボですら、本番リリース前には入念なレビューを実施しているのです。エージェントが従来の16倍もの上限で成果物を返せるようになったチームにとって、モデルそのものよりも先に用意すべきはレビュー計画です。
要約（TL;DR）
100万トークンの出力上限により、開発のボトルネックは「コードの生成」から「コードの受け入れ（承認）」へと移行します。1回の実行でこれほど膨大な成果物が返せるようになった今、作業は人間が一度の作業で確認できる単位のTask（タスク）へと分割しなければなりません。各タスクには明文化された完了条件（Definition of Done）とタイムアウトを設定し、すべてのタスクに検証エビデンスの添付を義務付け、事前にレビュー処理能力の試算を行いましょう。エージェントが調査・実装・テスト・報告を担当し、人間が方向性の決定・権限付与・結果の受け入れ判断を担います。
1回の実行でこれほどの出力が可能になると何が変わるのか
レビュー処理能力とは、チームが1日に精読し、判断を下し、受け入れることができる「エージェントの完了済み成果物」の件数を指します。これを決めるのは人間側の制約であり、モデルの性能ではありません。出力上限の引き上げは、一度に届く成果物の量を増大させるだけにすぎないのです。
かつての出力上限は、意図せずしてスコープ制御の役割を果たしていました。レスポンスの長さに限界があったため、作業は適度な区切りごとに分割され、その合間に必ず確認ポイントが挟まれていたからです。しかし、Googleが今回の新上限を設けた理由はこれとは対照的であり、「難解な課題を一挙に解決する（solve tough problems in one go）」ためのヘッドルーム（余力）を確保することにあります。しかしレビュー担当者から見れば、「一挙に」とは成果物が一度に出力され、承認判断も一回限りで、途中で「方向性が間違っている」と軌道修正をかけられるチェックポイントが失われることを意味します。
また、この上限枠は全体で共有されるものです。Argonの1,048,576トークンのウィンドウには、入力、思考（Thinking）、出力のすべてが含まれます。そのため、30万トークンのコードを読み込む実行の場合、思考と出力に使える残りは約74.8万トークンとなります。それでもなお、人間が1回の作業で1行ずつ精読できる量を遥かに超えています。
さらに品質の面も無視できません。発表時、Bloombergは匿名のGoogle社員の発言として、ベンチマーク結果と比較して一部のコーディングやフロントエンド開発作業においてArgonが期待外れであると報じました（Googleはこの報道を不正確であると反論しています）。Google自身の公開した比較表でも、エージェント型コーディングの評価項目4つのうち2つでArgonが劣後しています（詳細は当社の比較記事で解説しています）。ベンチマークは特定のテストセットに対する主張にすぎません。手元に届くdiffは自分たちのコードベースに対する変更提案であり、どのモデルが生成したものであれ、受け入れ可否は提示されたエビデンスに基づいて判断されます。
トークン予算ではなく、Taskのスコープを設計する
制御すべき単位はトークン数ではなくTaskです。モデルの出力上限に任せて作業規模を決めてしまうと、モデルが生成可能な最大サイズの成果物がそのまま返ってきます。しかし、人間側で適切なスコープを規定すれば、人間が無理なくレビューして受け入れられる成果物が得られます。Google公式のガイダンスも同じ見解を示しています。標準的なタスクではデフォルトの65,536トークンを維持し、複雑な推論やコーディングを行う場合でも、最大値まで引き上げるのではなく131,072トークンや262,144トークンのバックグラウンドモードを活用することが推奨されています。
Googleの事例自体も、作業をライブラリやカーネル単位で分割しています。移植プロジェクトも同様に分割すべきです。すなわち、レビュー担当者が一度の作業で確認を完了できるモジュールごとに1つのTaskを割り当てます。Sharklyでは、親Taskの下にモジュールごとのサブタスクを配置し、先行して完了すべきモジュールに対して「blocks / is blocked by（ブロックする／される）」の依存リンクを設定します。目的、スコープ、完了条件（受け入れ基準）はTaskの説明欄に記載し、エージェントとレビュー担当者の双方が同じ基準を共有します。
SH-412 Port the tokenizer module to Rust
Parent: SH-400 Port the parser library to Rust
Blocked by: SH-411 Port the shared buffer types
Done when:
- the Rust module replaces src/tokenizer/ and nothing outside it changes
- the existing test suite passes against the Rust build without edits
- a differential run over the fixture corpus produces identical output
- the report lists every unsafe block and the reason for it
Out of scope: public API changes, performance work
これを支えるのが、エージェントに関する2つの設定です。タスクごとのタイムアウト（per-Task timeout）は、モデルの最大スペックではなくタスクの実態に合わせて設定します。1つのモジュールに対する現実的な最長実行時間を上回りつつ、コスト面で後悔するような過剰な長時間実行は防げるラインに設定します。もう1つの最大同時実行数（Max concurrency / 割り当てタスク数）は、同時に進行するモジュール数を制限します。40個のサブタスクを一斉に実行すれば、同一のレビュー担当者のもとに40件の成果物が同時に滞留してしまうからです。
判断の指針はシンプルです。コンパイラや網羅的なテストスイートによって成果物全体を完全に自動検証できる場合（機械的なリネーム処理など）は、1回の実行に作業全体を任せます。一方、人間による判断が一部でも必要な場合（プログラミング言語の移行作業の大半がこれに該当します）は、タスクを分割します。業務時間を超えて長時間稼働するエージェントの実行には、同じ前提条件が必要です。明確な停止条件、待機状態、そして翌朝結果を確認する責任者の存在です。
Taskにエビデンスを集約する
エビデンスを伴わない大規模な成果物の確認は、レビューとは呼べません。それは人間が時間をかけて手作業で再実行しているにすぎないのです。
libgav1の事例は、優れたエビデンスのあり方を的確に示しています。Googleによると、Argonは既存のRust移植版における32K行のSIMDコードを置き換え、その結果「元のRust移植版と完全に同一の映像出力を維持したまま、2.7倍の高速化を達成した」といいます。32K行ものコードをレビュー可能にしたのは、まさにこの文章の後半部分です。新旧両方のコードに同一の入力を与え、出力が完全に一致したという事実です。これが「差分テスト（differential testing）」であり、これによってレビュー担当者は機械的比較ではカバーできない領域――unsafeコードの妥当性、エラーハンドリングの経路、実環境のワークロードでも高速化が維持されるかどうかの検証――に集中できるようになります。
すべての実行結果において、Taskには次の4つの情報が返されるべきです。
| Taskに添付すべきエビデンス | レビュー担当者のどのような疑問に答えるか |
|---|---|
| 変更内容の要約 | 何が、どこで、なぜ変更されたか？ |
| テスト、型チェック、ビルドの出力結果 | 既存の信頼されたチェックを今も通過しているか？ |
| 検証内容とその手法 | どのような入力に対して動作の同一性が保たれているか？ |
| 既知の制限事項 | 人間が直接目で確認すべき点は何か？ |
これこそがSharklyのワークフローが提示する構成です。エージェントが型チェック、テスト、ビルドを実行したうえで、変更内容の要約、検証結果、既知の制限事項をタスクに添付します。そして人間が受け入れ、変更要求、またはマージやリリースの判断を行います。エージェントの最終レスポンスはTaskに保存され、実行ログは「Executions」タブに記録されるため、エビデンスはターミナル上ではなくTask上に集約されます。タスクレベルのエビデンスを活用したレビュー手法では確認すべき順序を解説しており、ハンドオフ用テンプレートによって報告の定型フォーマットが提供されます。
テストなどのチェックを通過したことは「受け入れ（承認）」を意味しませんし、プルリクエストのマージも同様です。Sharklyでは、リンクされたプルリクエストをマージしてもTaskのステータスは自動変更されません。自動チェックは検証可能な範囲を検証するだけであり、その限界については「AIコードレビューエージェントが検証できること・できないこと」で述べています。その変更がTaskの要求を真に満たしているかどうかを最終判断するのは人間です。
実行前にレビュー処理能力の試算を行う
レビュー業務はキュー（待ち行列）の構造を持っています。成果物が届き、人間がそれを処理して解消します。届くペースが解消ペースを上回れば、キューは際限なく膨らみます。出力上限の引き上げが変えるのは、成果物が届く側のペースだけです。架空のプロジェクトを想定した具体的な試算例を見てみましょう。
| 想定条件（仮定の数値） | 値 |
|---|---|
| 移行対象のモジュール数 | 40 |
| モジュールあたりのレビュー時間（diffのみの場合） | 2時間 |
| モジュールあたりのレビュー時間（差分テストのエビデンスと変更要約がある場合） | 30分 |
| レビュー担当者1人が1日に丁寧なレビューへ充てられる時間 | 3時間 |
diffだけを頼りにレビューする場合、移行作業にはレビュー工数として80時間、約27営業日を要します。一方、すべてのTaskにエビデンスが添付されていれば、所要時間は20時間、約7日間に短縮されます。1回の大規模な実行であろうと40回の細かな実行であろうと、レビュー担当者側の総負荷の大きさそのものは変わりません。
大きく変わるのは意思決定のあり方です。40個のTaskに分割されていれば、自分で制御できるペースで成果物が届き、タスクごとに個別の判定を下せます。しかし40モジュール全体を1回の実行で出力してしまうと判定も一括になり、31番目のモジュールに問題があるだけで残り39個のモジュールまで巻き添えを食らってしまいます。サブタスクに分割されていれば、問題のあったタスクにコメントを付けて追加の再実行を走らせつつ、問題のない残りのタスクはそのまま次の工程へ進めることができます。
続いてコストの試算です。上限いっぱいの実行を行うと約100万トークンの出力となり、11月30日までの料金レート（100万トークンあたり10ドル）で約10ドル、12月1日以降は約20ドルかかります。Tier 1プロジェクトにおけるGoogleの利用額制限は直近10分間のローリングウィンドウあたり10ドルのため、上限いっぱいの実行を1回行うだけで、現行レートでも制限枠をまるまる消費し、12月1日以降はその制限の2倍に達してしまいます。これほど長時間の実行を許可するエージェントでは、最大同時実行数（Max concurrency）を低く抑えておく必要があります。
キューが滞留してから慌てるのではなく、最初の大規模な実行を行う前にチーム独自の数値で計算しておきましょう。レビュー処理能力の計算手法ではチーム全体での同様の試算手順を解説しており、人間のレビューがボトルネックになる理由では、キューを可視化するためのステータス設計やレビューゲートについて取り上げています。
100万トークン規模の実行に踏み切る前のチェックリスト
- [ ] 作業がレビュー担当者が一度の作業で完了できるTaskに分割されており、サブタスクや「ブロック関係（blocked by）」の依存リンクが設定されている。
- [ ] 各Taskの説明文に、完了条件（Doneの定義）とスコープ外の項目が明記されている。
- [ ] タスクごとのタイムアウトが、モデルの出力上限ではなくTaskの実態（長時間のバックグラウンドリクエストには数分かかる点を含む）に合わせて設定されている。
- [ ] 最大出力の実行を行っても、利用しているAPI Tierの利用額制限（spend limit）内に収まっている。
- [ ] 割り当てタスクに対するエージェントの最大同時実行数が、コンピュート環境が並列実行できる数ではなく、レビュー担当者が処理できる件数に合わせて設定されている。
- [ ] すべての実行結果として、変更内容の要約、チェックの出力結果、検証内容、既知の制限事項が返されるようになっている。
- [ ] 既存の動作を維持すべき作業において、旧コードに対する差分テストの検証結果が含まれている。
- [ ] 各Taskに担当レビュアーが指名されており、承認はレビュアーによるステータス変更によって行われ、マージの副産物として自動処理されないようになっている。
これらはArgonに限った話ではありません。有料のGemini APIキーがあれば誰でもArgonを呼び出せます。Googleが示したプロセスこそが標準テンプレートです。「大規模な出力」の後に「監査、エミュレーションテスト、レビュー」を行い、その後に初めて「本番展開」へと進むのです。どのAI研究機関が次に出力サイズを跳ね上げたとしても、計画を管理する場所はモデルの中ではなくTaskの上です。Sharklyは特定のモデルに依存しません。Agentsのドキュメントにある通り、エージェントは各ランタイムのデフォルトモデルに従い、カスタム引数やツールの設定から柔軟に変更できます。より高性能なモデルが使用中のランタイムに導入された際も、モデルの設定値を変更するだけで、Task、エビデンス、レビューゲートの仕組みはそのまま維持されます。リクエストからリリースに至るまで、コンテキスト、進捗、ブロッカー、成果物、そして人間によるレビューが一貫して可視化され続けます。
すでに複数のエージェントを運用しているなら、Sharklyを使えばそれらのタスクと成果物を1か所で統合管理できます。
