Gemini 4 Argon、GPT-6 Astra、Claude Opus 5.5：3大フロンティアモデル、それぞれ異なる3つの勝者

GoogleによるGemini 4 Argonの発表記事には19項目のベンチマーク結果が掲載されており、筆者の集計によればArgonは13項目で単独首位、1項目で同率首位を獲得しています。しかし、敗れた5項目も決して見過ごせるものではありません。GPT-6 AstraがFrontierSWE v2、Terminal-Bench Science、OSWorld-2.0を制し、Claude Opus 5.5がTerminal-bench 4.0とPostTrainBenchを制しています。これらはTerminal-Benchの2項目、エージェントコーディングの1項目、機械学習エンジニアリングの1項目、そしてコンピュータ操作（Computer Use）の2項目のうちの1項目であり、まさにコーディングチームが日々の開発実行で多くのリソースを投じる領域です。そして、この比較はもはや机上の空論ではありません。2026年10月13日より、Argonは有料のGemini APIにてgemini-4-argonとして一般提供されています。

そのため、「どのモデルが最強か？」という問いの答えは、どのベンチマーク項目を見るかによって3通りに分かれます。複数のコーディングエージェントを運用するチームにとって、これは決して些細な問題ではありません。チーム内のすべてのエージェントを同一のランタイムで動かしていると、そのモデル開発元の弱点も強みと一緒に抱え込むことになり、新モデルがリリースされるたびに乗り換えの議論が再燃します。どのエージェントに何を任せるか、何が完了し、何にレビューが必要か——そうした判断が、今週誰がベンチマーク首位に立ったかに左右されるべきではありません。

要約（TL;DR）

自らが作成したベンチマーク表においてさえ、すべての項目を独占できるフロンティアラボは存在しません。新モデルのリリースは全面移行の合図ではなく、ルーティングを見直す判断材料として捉えるべきです。複数のランタイムを連携可能な状態に保ち、ルーティングルールを明文化し（デフォルトの設定、別のエージェントにタスクを振り分ける条件、レビュー担当者の指定）、自社のコードベースから選んだ3つのタスクで検証してください。AstraはCodex経由、Opus 5.5はClaude Code経由、Geminiモデルは有料キーを設定したGemini CLI経由で動作します。GoogleはGemini CLIがArgonに対応しているとは明言していないため、実際のタスクに投入する前にgemini-4-argonのスモークテストを実施してください。

タスク種別に見るGoogleのベンチマーク結果

コーディングエージェントにとって重要な項目を、Google自身のカテゴリ別にまとめました。

エージェントコーディングのカテゴリだけでも4つの項目があり、首位は3つのモデルに分かれています。Argonが圧勝しているのはナレッジワーク、ロングコンテキスト、マルチモーダルの各項目ですが、最終成果物がコードのdiff（差分）である開発チームにとっては、これらは比較的重要度が低い領域です。

ただし、この結果はある程度割り引いて見る必要があります。これはあくまでGoogleが作成した表だからです。Google自身がArgonの評価を独自に実行した項目も複数あり、競合モデルの数値は主に各社の自己申告値や公開リーダーボードからの引用で、テスト用ハーネス（評価環境）も揃っていません。評価方法論のドキュメントには、各セルのデータソースが明記されています。また、リリース以降に発表されたサードパーティによる検証結果もまちまちです。Scale AIの「Humanity’s Sixth Sense」ではArgonが55.4%を獲得してGPT-6 Astra（53.6%）を抑えてトップに立ち、CursorはCursorBenchにおいてOpus 5.5と同等と評価しており、Artificial Analysisの10月15日時点のランキングではArgon (High)は掲載216モデル中8位となっています。

価格面を見ても決定打にはなりません。Argonの利用料金は、2026年11月30日までは入力100万トークンあたり2ドル、出力100万トークンあたり10ドルですが、12月1日以降はそれぞれ4ドルと20ドルに改定されます。改定後の料金はOpus 5.5とまったく同一です。一方、Astraの定価は入力10ドル、出力50ドルとなっています。

万能なモデルが存在しない以上、1社にすべてを委ねるべきではない

これは筆者らの主張というよりも、ベンダー各社が提示したデータそのものが物語っている事実です。Googleが自社モデルをアピールするために作成した表でさえ、5つの項目を競合2社に明け渡しているのですから、コーディングエージェントにおいて「万能のベストモデル」など存在しないことは明らかです。存在するのは、特定の評価環境において、今期、特定の種類のタスクに最も適したモデルに過ぎません。

この認識があれば、新モデル発表日の立ち回りも変わってきます。多くの現場では、デフォルトのランタイムを切り替え、設定を書き換え、チーム全体の慣習を刷新するという全面移行に飛びつきがちです。しかし、より低コストなアプローチは、新モデルが得意とするタスク領域の新たな選択肢として追加し、それ以外の運用には手を触れないことです。筆者らはこれまで、「どのコーディングエージェントが優れているか」よりも「ワークフローをどう管理するか」のほうが重要であると論じてきましたが、3つのモデルがそれぞれ強みを持つこのベンチマーク表は、その主張を数字で裏付けています。

判断基準は極めてシンプルです。

• 単一のデフォルトランタイムを維持すべきケース： タスクの大部分が同質で、1人のレビュアーがすべてを確認している場合。ランタイムを2つに増やすと、保守すべき設定が増え、請求先が分かれ、障害モードも倍増します。
• 2〜3つのランタイムを併用すべきケース： タスクが「シェル操作中心の作業」「UI検証」「大規模なコードベースの読み込み」に分かれている場合。ベンチマークの得意分野がまさにこの分類に沿って分かれているためです。

ルーティングルールを明文化する

1人のエンジニアの頭の中にあるルーティングルールは、単なる「個人の癖」に過ぎず、新入社員の加入や新モデルの登場によって簡単に崩れ去ってしまいます。チーム全員がいつでも確認できる場所に明文化しましょう。

Routing rule v1 (re-test after every frontier launch)

Default
  The Agent on your current default Runtime, until your own
  comparison says otherwise.

Send the Task to the Claude Code Agent (Opus 5.5 set in Claude Code) when
  - most of the work happens in a terminal: builds, CI repair, setup  [Terminal-bench 4.0]
  - it is training or evaluation plumbing for a model pipeline        [PostTrainBench]

Send the Task to the Codex Agent (GPT-6 Astra set in Codex) when
  - the change has to be verified by driving a desktop or browser UI  [OSWorld-2.0]
  - it is scientific or data work done mostly in a terminal           [Terminal-Bench Science]

Send the Task to the Gemini CLI Agent (gemini-4-argon) when
  - it needs a very large codebase or log read in one pass            [GraphWalks]
  - note: the 1M window is shared by input, thinking and output, and
    Gemini CLI support is unverified. Smoke-test before this line routes work.

Escalate
  If a run fails its acceptance checks twice, reassign the Task to the next
  Agent in this rule. The failed runs stay on the Task as evidence.

Review
  An Agent on a different Runtime from the author reads the diff and the
  evidence. A person accepts the result.

各条件には、その根拠となったベンチマーク項目と、日常の開発で見極めやすいタスクの特徴が明記されています。ここで最も重要なのはレビューの項目です。自身が作成していないdiffを別のモデルにチェックさせるのは、低コストで有益なセカンドオピニオンを得る有効な手段であり、最終的な承認の責任は人間が持ちます。

このルールをどこに記載するかは、ルーティングを誰が担当するかによって決まります。人間が担当者を指定する場合は、ワークスペースの運用規約に記載します。クルーリーダーが自動でルーティングする場合は、クルーへの指示プロンプトに組み込みます。どちらの方法をとる場合でも、実行結果は同一のタスクに集約されるため、比較履歴を一元管理できます。タスクの特徴とモデルの役割分担についての詳細は、どのコーディングタスクにどのモデルを使うべきかでさらに掘り下げて解説しています。

本運用前に自社のコードベースでルールを検証する

ベンチマークのスコアは、どのタスク種別にどのモデルを候補とするかの目安に過ぎません。最終的にどれをデフォルトにするかを決定づけるのは、実際の自社リポジトリです。ベンチマークではなく自社のコードベースでコーディングエージェントを比較する方法で紹介している手法は、この表と非常に相性が良いと言えます。表を見れば、検証用に選ぶべき3つのタスクが自ずと明らかになるからです。

1. 壊れたCIジョブの修正など、ターミナル操作が中心となるタスク
2. UIを通じて変更の成否を検証する必要があるタスク
3. リポジトリの大部分をコンテキストとして読み込む必要がある調査・質問タスク

各エージェントに対して同一のタスク説明と合格基準を与え、「一時ディレクトリの作成（Create temporary directory）」モードで実行して、実行ごとに独立したワークツリーを割り当てます。そして、エージェント自身の主張ではなく、タスクに実際に返ってきた成果物を評価します。具体的には、生成されたdiff、実行されたチェックとその結果、エージェントからの質問内容、そして人間が承認を完了するまでにかかった時間を測定します。

Gemini CLI上でgemini-4-argonを指定した1行のスモークプロンプトが通れば、Argonもすぐにこの比較検証に参加させることができます。他の設定を変更する前に、まずは同じ3つのタスクをArgonで試してください。なお、完了タスクあたりのコストという観点からの比較判断については、Opus 5.5とGPT-6 Solのデフォルトランタイム比較で詳しく解説しています。

各モデルの実行環境（2026年10月15日時点）

Geminiの項目には1つ落とし穴があります。Googleの移行告知によると、2026年6月18日以降、Gemini CLIではGoogle AI Pro、Ultra、および個人向け無料Code Assistアカウントが利用できなくなりました。ProやUltraの契約があればGeminiアプリ上でArgonを利用できますが、サブスクリプションとAPIキーは別物であり、ArgonのAPIには無料枠が存在しません。

Sharkly自体がモデルを独自に選定することはありません。エージェントの公式ドキュメントにも、「エージェントはランタイムのデフォルトモデルに従います。特定のモデル名を保証または表示することはありません」と明記されています。モデルの指定は、エージェントやランタイムのカスタム引数で行うか、Computer上のツール側の設定で行います。したがって、ルーティングルールにおける「Codexエージェント」とは、Astraを使用するように設定されたCodexランタイム上のエージェントを意味します。

それぞれのセットアップ手順については、SharklyでのGPT-6 Astraの利用、SharklyでのClaude Opus 5.5の利用、そしてGemini CLIの設定およびArgonへの切り替えについてはコーディングエージェント向けGemini 4 Argonガイドを参照してください。

ベンチマーク表は移り変わっても、開発基盤は揺るがすべきではない

次の新モデルが登場すれば、この表は再び塗り替えられるでしょう。しかし、モデルの周辺にある仕組み——ルーティングルール、タスク、実行ごとに得られるエビデンス、そして結果を承認する人間の役割——は、揺るがずに維持されるべきです。エージェントは調査し、実行し、テストし、報告します。そして人間は、方向性を定め、権限を付与し、最終的な結果を承認します。

特定の単一エコシステムに囲い込まれることなく、複数のコーディングエージェントを使い分け続けたいと考えるなら、それこそがSharklyが解決するために設計された課題です。