開発工程別 AIコーディングエージェント使い分け完全ガイド｜Claude・Codex・Cursor・Geminiを実測ベンチマークで比較

想定読者: AIツール選定・ワークフロー最適化に取り組む中級以上のエンジニア / テックリード

はじめに：なぜ「1つのAIで全工程」は破綻するのか

こんにちは、ぽんたぬきです。

40代になってつくづく感じるのですが、「万能な道具」への幻想って、若いころよりもかえって強く信じてしまいがちですよね。AIコーディングエージェントの世界でも、全く同じことが起きています。

「ChatGPTで全部やっている」「ClaudeだけでOK」——そういった声をよく聞きますが、実際に私が試してきた経験から言うと、単一ツールで全工程を回すと、かなり手痛い目に遭います。

具体的にどんな実害が出るか、3つ挙げましょう。

① 設計フェーズのハルシネーションが下流工程まで伝播する

設計フェーズで曖昧なまま固まった「なんとなく正しそうな仕様」が、そのまま実装・テストまで流れてしまう。人間のレビューが薄いほど、この問題は深刻です。特定のモデルは「もっともらしい嘘」をつくのが非常にうまいので、設計フェーズでの出力品質チェックは絶対に手を抜けません。

② 実装と検証を同一モデルファミリーで回すと「相関エラー」が増える

これは実際に失敗した経験があります。Codexで実装してCodexでレビューさせると、同じ種類の思い込みが実装側と検証側で共有されてしまい、論理的なバグを見落とすことがありました。別ベンダーのモデルを組み合わせることで、このリスクを大きく下げられます。

③ 高性能モデルを全工程で使うとコストが膨張する

Claude Opus 4.7は1タスクあたり約$4.10かかります。これをすべての工程に適用したら、コストが爆発します。工程によっては$0.07/タスクのツールで十分なケースがほとんどです。

つまり、「工程ごとに向いているAIは変わる」という視点が、今のAI活用の本質的なテーマなんです。

この記事では、工程別の選定マトリクスから、コンテキスト引き渡しの設計、オーケストレーション実装例まで、実測データをベースに整理します。一緒に最適なマルチエージェント設計を考えていきましょう。

【結論先出し】開発工程別 AIエージェント選定マトリクス

まず結論をお見せします。細かい説明は後のセクションで。

このマトリクスを評価する軸は3つです。

• 精度軸：SWE-bench / Terminal-Bench / LiveCodeBenchなどのベンチマークスコア
• コスト軸：タスクあたりの費用（$/タスク）
• 実行環境軸：IDE統合・ターミナル・API経由のどこで使えるか

まず試すべき最小構成は Claude（設計）→ Codex（実装）→ 別ベンダー検証 → 人間レビュー です。この4ステップから始めて、徐々に自動化を進めるのが現実的なアプローチです。

Claudeが要件定義・設計で強い理由

長文コンテキスト：「全部投げてから整理する」スタイルが使える

Claude Opusの最大コンテキストは1Mトークンです。これが何を意味するかというと、既存ドキュメント・議事録・Slackのエクスポートをまとめて投入できるということ。

私が実際にやっているのは、プロジェクト開始時に以下をまるごとClaudeに渡すことです。

• ステークホルダーとの過去のやり取り
• 参照する既存システムのドキュメント
• 競合他社の仕様書（公開されているもの）
• チームが使っている用語集

コンテキスト圧縮を挟まずに一括投入することで、「あの制約は議事録の3ページ目に書いてあった」という情報を落とさずに整理できます。これが要件定義フェーズで特に効きます。

構造化出力能力：曖昧な要望を意思決定可能な形にする

Claudeは「曖昧なインプット → 構造化されたアウトプット」の変換が非常に得意です。

私がよく使うプロンプト構成は以下の4ブロックです。

【前提】このシステムが解決したい課題と利用者像
【制約】変更不可の技術的・ビジネス的制約
【出力フォーマット】Markdownテーブル + JSON Schema
【禁止事項】「〜でしょう」「〜と思われます」などの曖昧表現の使用

さらに最後に必ず 「上記の要件で見落としている観点があれば、逆質問として3つ挙げてください」 を付け加えることで、自分では気づいていない抜け漏れを拾えます。

ベンチマークで見る優位性

2026年の実測では、SWE-bench（ソフトウェアエンジニアリングタスクの自動評価ベンチマーク）でClaude Opusが82.1%、Geminiが63.8%という差があります。特に上位の複雑なタスクになるほどこの差は広がる傾向があり、要件定義や設計フェーズのような「曖昧さの高い複雑問題」でのClaudeの優位性を裏付けています。

Opus と Sonnet の使い分け基準

全工程でOpusを使う必要はありません。私の判断基準はこうです。

Opusを選ぶとき：

• 仕様の曖昧さが高く、間違えると後工程のコストが大きい
• 多ステップの連鎖推論を人間の監視なしで維持させたい
• 要件が複雑に絡み合っていて、単純化できない

Sonnetを選ぶとき：

• 定型的なドキュメント生成や繰り返しタスク
• スループットを重視してコストを下げたい
• 出力品質を人間がこまめにレビューできる

Codex系が実装で強い場面とその限界

強み①：ターミナル操作の圧倒的精度

Terminal-Bench v2.1（ターミナル操作・コマンドライン実行の精度ベンチマーク）でCodexは88.8%という業界最高スコアを記録しています。

これが実際の開発でどう効くかというと、「コードを書く」だけでなく「ビルドして、テスト実行して、失敗したログを見て修正して、また実行する」という自律ループを高精度で回せるということです。

フロントエンドならば npm run dev で起動してブラウザのスクリーンショットを確認するところまで、バックエンドなら pytest を走らせて失敗したテストケースを自動修正するところまで、Codexに任せられます。

強み②：Issue単位の自律修正と並列実行

GitHubのIssueを渡して「これを修正するPRを出して」と指示できます。しかもバックグラウンドで非同期実行できるため、複数のIssueを並列で処理させながら他の作業ができます。

タスク分割の粒度設計が重要で、「1Issueに1変更の責任」というルールで切り分けると並列実行の効果が最大化します。

強み③：既存リポジトリへの局所的変更

既存のコードベースに対して「この関数だけ修正する」「このAPIエンドポイントを追加する」という局所的な変更は、Codexが最も得意とするところです。コード全体の整合性を保ちながら、指定された範囲だけを変更する精度が高い。

限界：知っておくべき3つの弱点

限界①：リポジトリ全体の構造推論はClaude Opusに劣る

大規模リポジトリのアーキテクチャ全体を把握して「なぜこういう設計になっているか」を説明させると、Claudeのほうが精度が高いです。Codexは「指示されたこと」は得意ですが、「全体から考えること」は苦手。

限界②：クロスベンダー連携が限定的

Codexは他社ツールとのシームレスな連携に制限があります。オーケストレーション構成を組むとき、この制約を前提に設計する必要があります。

限界③：同一ファミリーでの実装＋検証は相関エラーを生む

冒頭でも触れましたが、Codexで実装してCodexでテストさせると、同じ種類の思い込みが共有されます。テスト・レビュー工程は別ベンダーを使うことを強く推奨します。

実装フェーズの出力品質チェックリスト

Codexの出力を受け取ったら、必ず以下を確認してください。

• 差分の範囲が指示を超えていないか（余計なリファクタリングが混入していないか）
• テストが通る状態か（CI上で確認）
• 既存のコーディング規約に沿っているか（linterで自動チェック）
• 変更が想定した機能だけに限定されているか

Gemini 2.5 Pro の位置づけ：大規模読解とコスト効率の担当

2Mトークンウィンドウという唯一性

Gemini 2.5 Proのコンテキストウィンドウは2Mトークンです。これはフロンティアモデルの中で現時点で最大です。

何に使うかというと、巨大リポジトリを丸ごと投入しての静的解析やアーキテクチャ把握です。「このリポジトリ全体を読んで、循環依存しているモジュールをすべて洗い出して」といった指示が、分割なしで通ります。

レガシーシステムの移行調査や、大規模なコードレビューで特に威力を発揮します。

ベンチマークの伸びと弱点

Gemini 2.5 Proの伸び方は印象的です。

• LiveCodeBench（ライブコーディングベンチマーク）：1.5 Proの16.9%から2.5 Proで74.2%へ急伸
• Aider Polyglot（多言語コーディング評価）：82.2%を達成

一方でSWE-bench Verifiedは約62%で、Claude Opusの78%には及びません。「書く・実行する」は得意になってきましたが、「設計の複雑な推論」ではまだClaudeが上です。

コスト優位とベストな使い所

コストはClaude比で約1/12。これは非常に大きな差です。

Geminiが最適な投入先：

• 大規模コードベースの読解・静的解析
• コードレビュー（量が多い場合）
• 長文ドキュメントの生成
• クロスベンダー検証役（ClaudeやCodexとは異なる視点でのチェック）

Cursor（Composer 2.5）の位置づけ：対話的開発とコスト最適化

圧倒的なコストパフォーマンス

Cursor Composer 2.5の数字を見てください。

• SWE-bench Multilingual：79.8%（Claude Opus 4.7の80.5%にほぼ同等）
• コスト：$0.07/タスク（Claude Opus 4.7の$4.10の約1/58）

この数字、初めて見たときは目を疑いました。精度はトップモデルとほぼ同等で、コストは1/58。

IDE内モデル切り替えという強み

CursorはIDE（VSCode互換）の中で複数のフロンティアモデルを柔軟に切り替えられます。Claude、GPT-4、Geminiなど、タスクに応じて最適なモデルを即座に選べる。

この「人間が介在しながら対話的に開発する」という用途においては、Cursorは非常に優秀なツールです。

限界：オーケストレーションに組み込みにくい

外部APIが非公開のため、プログラマブルなオーケストレーションには組み込みにくいという制約があります。

つまり、Cursorは人間が操作するフロントとして割り切るのが現実的な使い方です。完全自動化したいフローにはCodexやClaude APIを使い、対話的なUIとしてCursorを使うという棲み分けが機能します。

工程間コンテキスト引き渡しの設計

ここからが実装の核心部分です。マルチエージェント設計で一番壊れやすいのは「工程間のつなぎ目」です。

基本原則：Stateless Handoff Model

各エージェントは自身のコンテキストで完結して実行する。これが原則です。

次の工程へは「ターゲットエージェントの指定 + 共有コンテキスト変数」をtool callのreturnとして渡します。「前のエージェントがどんな会話をしたか」をすべて引き継ぐのではなく、必要な情報を選択して構造化して渡すというイメージです。

サブエージェントが親エージェントに返す要約は1,000〜2,000トークンが適切な粒度です。実測では、この設計で全体のトークン消費を67%削減できた事例があります。

工程別の推奨引き渡し形式

壊れやすいポイントと対策

問題①：暗黙の前提が落ちる

「これはもちろんそうだよね」という前提が、別エージェントに渡ると「もちろん」ではなくなります。

対策：制約セクションを必須フィールドとして構造化する。「制約：〇〇は変更しない」という形で明示する。

問題②：要約で情報が消える

要約はどうしても情報を圧縮するので、細部が落ちます。

対策：「捨てた情報のリスト」も一緒に返させる。「以下の情報は要約から除外しました：〇〇、〇〇」という形式で。次の工程のエージェントが必要なら元情報を参照できるようにしておく。

ハンドオフ用スキーマの実例

{
  "handoff_schema_version": "1.0",
  "from_phase": "requirements",
  "to_phase": "design",
  "summary": "ECサイトの注文管理機能の要件定義結果",
  "requirements": [
    {"id": "REQ-001", "priority": "must", "content": "注文のキャンセルは出荷前のみ可能"},
    {"id": "REQ-002", "priority": "should", "content": "在庫が0になった商品は自動的に非表示"}
  ],
  "constraints": [
    "既存の決済基盤（Stripe）は変更しない",
    "DBはPostgreSQL 15系のまま維持"
  ],
  "dropped_information": [
    "ステークホルダーAの「返品機能もほしい」という要望（スコープ外として合意済み）"
  ],
  "open_questions": [
    "在庫の復元は手動か自動か未決定"
  ]
}

このスキーマを渡せば、設計フェーズのエージェントはゼロから文脈を組み立てる必要がなく、制約とオープンな問題がはっきり見えた状態でスタートできます。

マルチエージェントワークフローのオーケストレーション実装例

実績のある6つのパターン

① オーケストレーター・ワーカー メインエージェントがタスクを分解してサブエージェントに割り振る。コスト40〜60%削減の実績あり。複雑なタスクを安価なモデルで並列実行できる。

② 順序パイプライン 開発フロー全体の標準形。要件→設計→実装→テストを順番に流す。最もシンプルで導入しやすい。

③ ファンアウト・ファンイン フロントエンドとバックエンドの実装を並列化。完了後にマージして整合性チェックを行う。

④ マルチエージェント議論 実装と検証を別ベンダーに分離。相関エラーを防ぐための構成。

⑤ 動的ハンドオフ エージェントが自律的に「この問題は専門エージェントに委譲すべき」と判断して委譲する。

⑥ 適応計画 マネージャーエージェントが実行状況に応じて計画を動的に修正する。最も高度な構成。

【実装例】Claude設計 → Codex並列実装 → Gemini検証パイプライン

実際に私が組んだシンプルなパイプライン実装のイメージです。

# orchestrator.py

import asyncio
from typing import TypedDict

class HandoffContext(TypedDict):
    phase: str
    requirements: list
    constraints: list
    artifacts: dict

async def run_pipeline(initial_requirements: str):
    
    # Step 1: Claude で設計フェーズ
    design_context = await claude_design_agent(
        input=initial_requirements,
        model="claude-opus-4-7",
        output_schema=HandoffContext
    )
    
    # Step 2: Codex で並列実装（フロント・バック同時）
    frontend_task = asyncio.create_task(
        codex_implementation_agent(
            context=design_context,
            target="frontend",
            repo_path="./src/frontend"
        )
    )
    backend_task = asyncio.create_task(
        codex_implementation_agent(
            context=design_context,
            target="backend", 
            repo_path="./src/backend"
        )
    )
    
    frontend_result, backend_result = await asyncio.gather(
        frontend_task, backend_task
    )
    
    # Step 3: Gemini でクロスベンダー検証
    verification_result = await gemini_verification_agent(
        implementation_diff=merge_diffs(frontend_result, backend_result),
        requirements=design_context["requirements"],
        model="gemini-2.5-pro"
    )
    
    return verification_result

# リトライとロールバックの設計
async def codex_implementation_agent(context, target, repo_path, max_retries=3):
    for attempt in range(max_retries):
        try:
            result = await codex_api_call(context, target, repo_path)
            if validate_output(result):
                return result
        except Exception as e:
            if attempt == max_retries - 1:
                await rollback_changes(repo_path)
                raise
    raise MaxRetriesExceeded()

ポイントは以下の3点です。

1. 失敗時のリトライ：最大3回まで自動リトライ。失敗が続いたらロールバック
2. 並列実行：asyncio.gather でフロントとバックを同時に走らせる
3. クロスベンダー検証：実装（Codex）と検証（Gemini）で異なるベンダーを使う

ROI計算：マルチエージェント化すべき工程の見極め

重要な数字があります。Princetonの研究によると、単一エージェントがベンチマークの64%のタスクで複数エージェントと同等以上のパフォーマンスを発揮します。

つまり、すべての工程をマルチエージェント化する必要はありません。

マルチエージェント化すべき工程：

• 失敗コストが高い（本番リリース直前の検証など）
• 相関エラーのリスクが高い（実装と検証の同一ファミリー問題）
• 並列化でリードタイムを短縮できる（フロントとバックの独立した実装）

マルチエージェント化しなくていい工程：

• 単純な定型タスク（ドキュメント更新、定型コード生成）
• 頻繁な人間レビューが入る工程（単一ツールで十分）
• コンテキストの継続性が重要で分割するとむしろ精度が下がる工程

「精度が+2.1%上がるためにコストを2倍払う価値があるか」——この問いに対して、工程ごとに答えを出すことが重要です。

現場導入ロードマップ

いきなり全部変えようとすると失敗します。私が推奨する4ステップです。

Step 1：既存フローの工程を棚卸しする（1週間）

今のチームの開発フローを「要件定義→設計→実装→テスト→レビュー」に分解して、それぞれで何をしているかを書き出す。「実はここでAIを使っていない」「ここが一番時間がかかっている」という発見があるはずです。

Step 2：1工程だけツールを差し替えて効果測定する（2〜3週間）

一番変えやすい工程を1つだけ選んで、推奨ツールに切り替える。まずは「設計フェーズをClaudeに」だけでもいい。数字を取ることが大事です。

測る指標：

• そのフェーズのリードタイム
• 次の工程への手戻り回数
• AIへの費用（$/工程）

Step 3：ハンドオフ形式を標準化する（1〜2週間）

工程間で渡す情報のスキーマを決める。前述のJSON形式を参考に、自分たちのフローに合わせてカスタマイズしてください。

Step 4：オーケストレーションを自動化する（1ヶ月〜）

Step 1〜3が安定してから自動化に進む。手動でうまくいっていないフローを自動化しても、うまくいかないまま速くなるだけです。

まとめ：単一ツール依存からマルチエージェント設計へ

工程別選定の要点3行サマリ

1. Claude Opusは要件定義・設計で使う。長文コンテキストと構造化推論が他の追随を許さない
2. Codexは実装・テスト・CI/CDで使う。ターミナル操作と自律ループが最強
3. Gemini 2.5 Proは大規模コードベース読解とクロスベンダー検証で使う。コスト効率も魅力

明日から試せる最小構成

難しく考えすぎないでください。明日から試せる最小構成はこれだけです。

Claude（設計フェーズのプロンプト強化）
→ Codex（実装・テスト実行）
→ Gemini（最終レビュー）
→ 人間（意思決定とリリース判断）

まずはこの3ツール連携を手動でやってみる。ハンドオフのスキーマも最初はMarkdownファイルで十分です。慣れてきたらPythonスクリプトで自動化する、という順番で進めてください。

今後の注目ポイント

モデルは毎月のように更新されます。ベンチマークの数字も半年後には変わっているでしょう。

大事なのは、特定のスコアに依存するのではなく「どのベンチマークが自分たちの工程に一番関係するか」を理解しておくことです。SWE-benchは設計・複雑タスク、Terminal-Benchはターミナル操作、LiveCodeBenchは実装精度——それぞれが測っているものを把握しておくと、新しいモデルが出たときの評価が速くなります。

40代になって一番感じるのは、「道具を増やすことより、道具を選ぶ眼を鍛えることのほうが価値がある」ということ。AIの世界はまさにそれが問われています。

同じ悩みを持つ仲間として、一緒にこのマルチエージェント設計を磨いていきましょう。何か試してみた結果があれば、ぜひコメントで教えてください。

参考リンク

• Qiita: 開発工程別AIエージェント活用
• Qiita: Claude・Codex・Gemini比較
• SWE-bench公式
• Anthropic Claude API ドキュメント
• OpenAI Codex ドキュメント
• Google Gemini API ドキュメント