AIコーディングモデル＆エージェントツール：2026年7月の最新勢力図

AIコーディング市場を1枚のランキングで表すことは、もうできません。2026年7月、主要ラボはどこもモデルのポートフォリオとエージェントハーネスの両方を提供しています。モデルが判断を担い、ハーネスがツール、権限、並列ワーカー、永続化、実行場所を担います。

この区別は重要です。最先端モデルでも、薄くて中断に弱いターミナルループに入っていれば、長時間のマイグレーションには不向きです。少し小さいモデルでも、worktree、チェックポイント、確実なresumeを備えた成熟ハーネスの中なら、より多くの実作業を完了できることがあります。いまAIコーディングスタックを選ぶということは、この2層を同時に選ぶことです。

スナップショット日：2026年7月19日。 モデルのalias、Previewラベル、クォータ、提供状況は頻繁に変わります。本記事ではPreview／Experimentalを明示し、固定的なランキングではなく各社の現行公式ドキュメントへリンクします。

まず結論

プロバイダー	現行モデル階層	主なコーディングエージェント面	重要なステータス
Anthropic	Fable 5、Opus 5、Sonnet 5、Opus 4.8、Haiku 4.5	Claude Code：CLI、IDE、desktop/web、サブエージェント、dynamic workflow、Agent Teams	Opus 5は現行Opus、Opus 4.8は前世代。アカウントごとに可用性が異なる
OpenAI	GPT-5.6 Sol、Terra、Luna	Codex desktop、CLI、IDE、cloud、exec、SDK	面ごとに成熟度が異なる。codex execはStable、一部cloud/app-serverコマンドはExperimental
Google	Gemini 3.5 Flash、3.1 Pro Preview、3.1 Flash-Lite	Antigravity／Antigravity CLI、Gemini API Managed Agents、Jules	3.1 ProはPreview。consumer向けGemini CLIはAntigravity CLIへ移行
xAI	Grok 4.5	Grok Buildのターミナルエージェントとオープンソースハーネス	Grok BuildはEarly Betaで開始、7月15日にソース公開

万能の勝者はいません。有用な問いは、このワークロード、この故障モデル、この規模に最適な組み合わせは何かです。

Anthropic：現行モデルのポートフォリオと複数の並列化境界

Claude Code 2.1.226のmodel configurationには次の選択肢があります。/model に実際に表示されるモデルとaliasはprovider、プラン、アカウントのentitlement、rolloutによって異なります。

• Claude Fable 5（claude-fable-5）は、広く提供される中で最も高性能なモデルで、長時間エージェントと最難関の判断作業向けです。
• Claude Opus 5（claude-opus-5）は現行Opus世代で、難しいOpusクラスの作業向けです。
• Claude Opus 4.8（claude-opus-4-8）は前世代のOpusで、表示される環境では引き続き対応選択肢です。
• Claude Sonnet 5（claude-sonnet-5）は、速度と知能のバランスを重視した日常実装向けです。
• Claude Haiku 4.5（claude-haiku-4-5-20251001）は、ファンアウト、スキャン、大量の補助作業に向く最速・低コスト層です。

実務戦略は「全部Fable」ではありません。安いファンアウト、高価な判断です。HaikuやSonnetにファイル探索や機械的チェックを任せ、アーキテクチャ、敵対的検証、最終統合にFableやOpusを使います。

Claude Codeには複数の並列作業抽象があり、同じものとして扱うべきではありません。

1. 標準サブエージェントは独自contextを持ち、呼び出し元へ結果を返します。Claude Code v2.1.172以降は、サブエージェントがnested subagentをspawnでき、固定上限は5層です。メイン会話へ戻す必要があるのは最上位subagentの要約だけで、depth 5のagentにはAgent toolが渡されません。
2. Agent Teamsは、共有タスクリストとteammate間の直接メッセージを持つ独立したClaude Code instance群です。現在もデフォルト無効のExperimental機能です。token消費が増え、teammateは自動的にworktree分離されず、nested teamも作れません。
3. Dynamic workflowsは、大規模な編成をworkflow構造に移し、バックグラウンド実行と/workflowsによる観測を提供します。最近はworkflow sizeとtelemetryの制御も追加されました。詳しくはv2.1.202リリースを参照してください。
4. Background sessionとworktreeは、一度だけ結果を返す短い委譲ではなく、完全なsession寿命や分離checkoutが必要なタスクに向きます。

これは最も多彩なネイティブ編成メニューの1つですが、無限に深くできる1本のサブエージェントツリーではありません。5層の上限は固定で、それぞれ寿命と調整境界が異なります。

OpenAI：GPT-5.6と最も広いCodexの提供面

OpenAIのモデルカタログでは、GPT-5.6が3ティアに分かれます。

• GPT-5.6 Sol（gpt-5.6-sol、推奨開始aliasはgpt-5.6）は、複雑な専門推論とコーディングの旗艦です。
• GPT-5.6 Terra（gpt-5.6-terra）は、知能、レイテンシ、コストのバランス型です。
• GPT-5.6 Luna（gpt-5.6-luna）は、コスト重視の大量処理向けです。

役割分担はAnthropicに似ています。曖昧なマルチステップ作業と最終判断にはSol、日常エージェントや補助レビューにはTerra、スループットにはLunaです。ただし最終マッピングは自分のリポジトリで評価すべきです。ベンダーのbenchmarkは、あなたのbuild時間、ツール信頼性、プロジェクト規約までは測りません。

Codexの差別化は、同じ作業モデルが多くの製品面を横断することです。ChatGPT desktop、ターミナルCLI、IDE、cloudで利用できます。自動化ではcodex execがStableの非対話コマンドで、通常出力またはJSONLを返し、以前のexec sessionもresumeできます。組み込み用途ではCodex SDKがTypeScriptとPythonで継続可能なcoding threadを提供します。Python SDKは現時点でBetaです。

Codexは本当の再帰委譲にも対応しますが、安全なデフォルトは意図的に浅く設定されています。設定リファレンスではagents.max_depthのデフォルトは1です。rootは直接のchildをspawnできますが、設定を引き上げない限りchildはさらにdescendantを作れません。深いツリーは設定可能ですが無料ではありません。token、レイテンシ、ローカル資源負荷、暴走ファンアウトの危険を増幅します。agents.max_threadsのデフォルトは6で並行数を制限しますが、境界の悪い再帰計画を予測可能にはしません。

対話、scripted exec、SDK制御、深さを調整できるサブエージェントツリーを1つの環境で扱いたいならCodexが有力です。「深くネストできる」は品質スコアではなく制御面だと考えてください。

Google：Gemini 3.5 FlashとAntigravityへの移行

GoogleのGeminiモデルページは、productionステータスを明確に示しています。

• Gemini 3.5 FlashはStableで、持続的なfrontier agentic／coding作業におけるGoogleの最も知的なモデルと説明されています。
• Gemini 3.1 Flash-LiteはStableで、速度、スケール、コスト効率向けです。
• Gemini 3.1 Proは高度な推論とコーディング向けですが、まだPreviewです。Preview endpointは制限が厳しく、廃止通知期間も短い場合があります。

新しいproduction統合の多くは、まず3.5 Flashを基準に評価するのが自然です。大量分類、スキャン、単純なtool callには3.1 Flash-Liteを。3.1 Pro Previewは、自社評価で明確に勝ち、Previewのライフサイクルリスクを受け入れられる場合に限って選ぶべきです。

ツール面はモデル以上に大きく変わりました。GoogleはGemini CLIからAntigravity CLIへの移行を発表しました。6月18日以降、旧経路は無料／consumer、Google AI Pro、Google AI UltraのGemini CLIおよびGemini Code Assist IDE requestを提供しなくなりました。Standard／Enterpriseはこのconsumer cutoffの対象外です。

Antigravity CLIはskills、hooks、subagents、pluginとして再編されたextensionsなど、Gemini CLIの主要概念を引き継ぎます。一方、Googleは初期版が1対1のfeature parityではないとも明記しています。方向性はAntigravity 2.0と同じagent harnessを使う統一server-backed multi-agent platformで、非同期バックグラウンドworkflowを実行します。Google中心のagent作業には魅力的ですが、移行テストは導入作業そのものです。

Julesは別の選択肢であり、旧CLIの改名版ではありません。 Julesは現在もPublic BetaのGitHub統合cloud coding agentです。タスクごとにfresh VMを起動して非同期で作業し、範囲を絞ったrepoタスク、定期メンテナンス、CI修復、PR deliveryに向きます。「依頼して後でPRを受け取る」ならJules、ターミナルでmulti-agentを操作するならAntigravity CLIです。

xAI：Grok 4.5と公開されたGrok Buildハーネス

xAIは7月16日にGrok 4.5を公開し、coding、agentic task、knowledge work向けの最強モデルと位置づけました。xAI APIで利用でき、Grok Buildのデフォルトモデルにもなっています。

Grok Buildは、plan review、diff、AGENTS.md、skills、plugins、hooks、MCP、並列subagents、worktree統合を持つターミナルcoding agentです。-p headless modeでscriptやautomationから呼び出せ、ACPも別の統合境界になります。5月にEarly Betaとして始まったため、信頼性とインターフェース変更を評価に含める必要があります。

7月の重要な変化は透明性です。xAIは7月15日にGrok Buildのagent loopとTUIをオープンソース化しました。公開コードにはcontext assembly、tool dispatch、ターミナルUI、extension systemが含まれ、local-firstでbuildしてローカル推論に向けることもできます。オープンソースはハーネスを検査・拡張可能にしますが、hosted model、クォータ、Beta APIが不変だと保証するものではありません。

高速なterminal-first agent、検査可能なハーネス、多数のworktreeワーカーが必要ならGrok Buildは魅力的です。ただしこのスナップショットでは、Grok 4.5もオープンソース版も公開から数日です。全面移行の前に代表的なリポジトリで試してください。

Model-Aware Planning：オーケストレーションモードとして設計する

Model-aware planning は routing contract であり、provider ranking ではありません。一つの outcome を境界のある task node に分解し、node ごとに model、harness、reasoning budget、authority boundary を選びます。以下の provider 役割は現在の操作面から導く開始仮説であり、恒久的な勝者ラベルではありません。Release、tool policy、workload が変われば、自分の repository で再評価します。

1. Model を選ぶ前に task contract を書く。 Objective、acceptance criteria、必要な artifact、dependency、side effect を記録します。独立して進められる discovery と依存する implementation を分け、不可逆な remote action は通常の child task ではなく明示的な approval gate にします。
2. 検証済みの作業特性で routing する。 Claude は hierarchical decomposition、long-context synthesis、一貫した計画を保つ coordination の開始候補です。Codex は repository-centered implementation、diff/test loop、structured または headless execution の開始候補です。Grok Build は terminal-first exploration、worktree isolation、parallel agent run の開始候補です。これは試すべき役割であり、global scorecard ではありません。Evaluation evidence が支えるなら、どの provider も任意の node を担当できます。
3. Node ごとに model と reasoning effort を選ぶ。 Architecture、曖昧な debugging、security review、adversarial verification、final synthesis には高能力 model と高い effort を使います。範囲の狭い search、inventory、formatting、機械的 check には高速 modelを使い、そのmodelが対応するときだけeffortを下げます。Claude Code 2.1.226ではFable 5、Opus 5、Sonnet 5、Opus 4.8が low、medium、high、xhigh、max に対応します。Haiku 4.5はeffort対応モデルとして掲載されていないため、--effort を付けません。Model 名と effort control は provider-specific なので、実値を記録し、別 provider の設定へ推測で変換しません。
4. Delegation 前に authority を固定する。 各 node に read-only か edit 可か、許可する path/tool、sandbox と network boundary、credential や external system が scope 内かを記述します。Handoff は caller の authority を拡張できません。境界を強制するのは native permission と sandbox controls であり、「注意して」という prompt ではありません。
5. Handoff を検証可能にする。 受信 agent へ渡す bounded packet には goal、関連 file、constraint、expected output、現在の commit または diff、実行済み test、未解決 risk、completion に必要な evidence を含めます。受信側は transcript を信頼するだけでなく repository state を再確認し、vendor session ID を portable resume token として扱いません。
6. Evidence を一つの controller に戻す。 一つの orchestrator が dependency order と final verdict を所有し、concurrent change を調整し、affected tests と final diff を確認して blocker を正直に報告します。自信のある summary は completion evidence ではなく、acceptance criteria と結果 artifact が証拠です。

この mode は、task node ごとに判断力、コスト、execution boundary を変える必要がある場合に使います。明白な verification step が一つだけの小さな変更なら、scope を絞った single agent の方が明快です。

ロゴではなくワークロードで選ぶ

ワークロード	最初に試す候補	理由
アーキテクチャ、曖昧なデバッグ、敵対的検証	Fable 5またはGPT-5.6 Sol	判断ミスが高くつく場所にfrontier tierを使う
人間がレビューする日常実装	Sonnet 5、GPT-5.6 Terra、Gemini 3.5 Flash	知能、レイテンシ、スループットのバランス
大量スキャン、機械的ファンアウト	Haiku 4.5、GPT-5.6 Luna、Gemini 3.1 Flash-Lite	補助作業に最上位の判断力は不要
大規模Claude-native編成	Claude Code dynamic workflows	Workflow構造、背景実行、ネイティブ監視
desktop、CLI、IDE、cloud、組み込み自動化を1スタックで	Codex	広い提供面、Stable exec、SDK制御
Google中心の非同期multi-agent作業	Antigravity CLI	統一Google agent harnessと背景workflow
GitHubタスクをremote実行しPRで受け取る	Jules	Cloud VM、scheduled work、CI loop、非同期delivery
検査可能なハーネスでterminal-first並列作業	Grok Build	Headless、subagents、worktrees、公開agent loop

「どのモデルが一番？」より良い評価

同じ実タスクを各候補スタックで実行し、次の5点を記録します。

1. **パッチの正しさ：**問題を直し、regressionを作らなかったか。
2. **検証規律：**適切なテストを実行し、失敗を正直に報告したか。
3. **復旧性：**中断後に、やり直しや忘却なしでresumeできるか。
4. **分離性：**並列ワーカーがファイルや状態で衝突しないか。
5. **完了までの総コスト：**token単価だけでなく、再試行、人間レビュー、失敗runも含める。

短く整理されたタスクではモデル知能が支配的です。長く混沌としたタスクではハーネス設計が支配的になります。そのため2026年7月の最適解は、frontier modelで判断し、安いworkerでファンアウトし、タスクの実際の寿命に合ったprocess boundaryを使うポートフォリオになりがちです。

まとめ

Anthropicは、安価なworkerから高判断モデルまでの最も明快な階層と、多様なClaudeネイティブ調整パターンを提供しています。OpenAIはGPT-5.6に、最も広いCodexの提供面と設定可能な再帰サブエージェントを組み合わせています。GoogleはGemini 3.5 Flashという強いStable coding基準を持ちますが、consumerツール利用者はGemini CLIからAntigravityへの移行を理解する必要があります。xAIはGrok 4.5をデフォルトcoding modelにしながらGrok Buildを非常に検査しやすくしましたが、CLIはまだ若い製品です。

benchmarkの勝者だけを単独で買わないでください。選ぶべきものはモデルの役割、process boundary、復旧設計です。それが、エージェントのデモを信頼できるエンジニアリングシステムへ変えられるかを決めます。

---

公式情報：Anthropic models、Claude Code subagents、Claude Code Agent Teams、OpenAI models、Codex non-interactive mode、Gemini models、Antigravity transition、Jules FAQ、Grok 4.5、Grok Build open source。