agent-collaboration

エージェントの連携

複数の AI モデルを専門エージェントとして連携させ、それぞれの得意分野を担当させます。1 つのモデルが計画を立て、別のモデルがコーディングし、さらに別のモデルがレビューします。プランナーは常にループに加わり、各フェーズの後に再び参加して評価し、方向を修正します。

---

使用する場面

• 計画、実装、レビューを必要とする複雑なプロジェクト
• 1 つのモデルの見落としがリスクとなるタスク
• 自己レビューでは見つけられない問題を、敵対的レビューで検出したい場合
• ウェブ検索、情報の統合、検証を必要とする調査中心の作業
• 専門的な推論を必要とする数学や科学のタスク
• 計画 → 実行 → レビュー → 再計画のループが役立つあらゆるタスク
• ユーザーが複数モデルの連携を明示的に求めている場合

使用しない場面

• 1 行の修正、誤字の訂正、簡単な質問
• 1 つのモデルの得意分野だけで完結するタスク
• 徹底さよりも速さが重要な場合
• 具体的な成果物を伴わない探索的な会話

---

考え方

1 つのモデルがすべてにおいて最適とは限りません。 ベンチマークでは、モデルのファミリーごとに得意なタスクが異なることが一貫して示されています。Claude Opus は計画立案と抽象的な推論に優れています。GPT-5.4 はコード実装で先頭に立っています。Gemini 3.1 Pro は数学、科学、知識検索で優れた性能を発揮します。Grok 4 は異論を唱える視点をもたらします。これらを専門エージェントとして組み合わせることで、複雑なタスクでは単一モデルを上回る成果が得られます。

プランナーは指揮者です。 タスクを分解し、委任し、評価し、必要に応じて再計画します。他のすべてのエージェントはプランナーに結果を報告します。プランナーはファイルを編集しません。状況を把握するためにコードを読み、サブエージェントを起動しますが、その権限の源は作業そのものではなく、指示を出すことにあります。

敵対的レビューは必須です。 異なるモデルファミリーによるレビューでは、自己レビューでは見つけられない失敗パターンを検出できます。敵対的レビュー担当者の仕事は問題を見つけることであり、配慮した表現をすることではありません。

エージェントは使い捨てでも、コンテキストはそうではありません。 各エージェントはステートレスでもかまいませんが、エージェント間の引き継ぎでは、関連するすべてのコンテキストを保持する必要があります。各フェーズ間で情報が失われないようにするのは、プランナーの責任です。

---

7 つのエージェント

1. プランナー

• 役割： 複雑なタスクをサブタスクに分解し、それぞれに適切なエージェントを割り当て、成功基準を定め、結果を評価し、必要に応じて再計画します
• 主なモデル： Claude Opus 4.6（拡張思考）
• 代替モデル： Claude Opus 4.5、GPT-5.4（高度な推論）
• Opus を選ぶ理由： Arena 総合 1 位（1504 Elo）、Hard Prompts 1 位、抽象的な推論で最高の性能（ARC-AGI 2：68.8％）。拡張思考は、構造化された分解と多段階の計画立案に優れています
• ツール： ファイルの編集は行いません。プランナーはコードを読み取り、読み取り専用のシェルコマンド（git log、ls）を実行してサブエージェントを起動しますが、ファイルの書き込みや編集は行いません
• 出力： サブタスクの割り当て、依存関係、成功基準を記載した YAML 形式の構造化計画

2. コーダー

• 役割： コードの変更を実装し、テストを書き、バグを修正し、リファクタリングします。計画に忠実に従います
• 主なモデル： GPT-5.4（高度な推論）
• 代替モデル： Claude Sonnet 4.5、Claude Sonnet 4.6
• GPT-5.4 を選ぶ理由： Aider コーディングリーダーボードをリードしています（88％）。高速かつ正確で、計画を動作するコードに変換する能力に優れています
• 代替モデルとして Sonnet 4.5 を選ぶ理由： SWE-bench Verified をリードしています（82％）。実際のソフトウェアエンジニアリングタスクに強みがあります
• ツール： ファイルシステムへの完全なアクセス権（読み取り、書き込み、編集、ターミナル、パッケージマネージャー）
• 出力： 変更したファイル、テスト結果、実装の概要

3. リサーチャー

• 役割： ウェブ検索、ドキュメントの調査、API の調査、文献レビュー、競合分析、要約
• 主要モデル： Gemini 3.1 Pro
• フォールバック： Claude Opus 4.6
• Gemini 3.1 Pro を選ぶ理由： Humanity's Last Exam（45.8%）で首位、MMMLU（91.8%）でトップです。幅広い知識領域から情報を見つけ、統合する能力に優れています
• フォールバックとして Opus を選ぶ理由： BrowseComp（ウェブ調査の統合）で最高の性能を発揮します。異なる情報を結び付けることに優れています
• ツール： ウェブ検索、ウェブ取得、ファイルの読み取り。ファイルの編集は行いません。リサーチャーの役割は調査結果の報告であり、実装ではありません
• 出力： 出典を明記した調査概要、主要な調査結果、意思決定に役立つトレードオフ

4. サイエンティスト

• 役割： 数学的推論、形式的証明、統計モデリング、データ分析、アルゴリズムの検証、科学技術計算
• 主要モデル： Gemini 3 Pro
• フォールバック： GPT 5.2、Claude Opus 4.6
• Gemini 3 Pro を選ぶ理由： AIME 2025 で 100%、GPQA Diamond で 94.3% を獲得しています。段階的な数学的推論と形式的証明に優れています
• フォールバックとして GPT 5.2 を選ぶ理由： AIME 2025 で 100%、GPQA Diamond で 92.4% を獲得しています
• ツール： コード実行（計算と検証用）、結果のファイル読み取り／書き込み。通常、ウェブアクセスは不要です
• 出力： 形式的な分析、証明、方法論を示した計算結果

5. ビジュアルアナリスト

• 役割： 画像分析、UI/UX レビュー、図の解釈、スクリーンショットの分析、ビジュアルリグレッションの検出、デザインシステムへの準拠確認
• 主要モデル： Claude Opus 4.6
• フォールバック： Gemini 3.1 Pro
• Opus を選ぶ理由： ARC-AGI 2：68.8%（抽象的な視覚的推論で大きくリード）。構造化された出力を伴うマルチモーダル理解にも優れています
• フォールバックとして Gemini を選ぶ理由： MMMU-Pro で 80.5% を獲得しています。複雑な視覚コンテンツの解釈に優れています
• ツール： 画像の読み取り、スクリーンショットのキャプチャ、ファイルの読み取り。ファイルの編集は行わず、視覚的な調査結果を報告します
• 出力： 具体的な観察事項、問題点、推奨事項を含む視覚分析レポート

6. 敵対的レビュアー

• 役割： 欠陥、セキュリティ上の脆弱性、エッジケース、論理エラー、誤った前提、競合状態、パフォーマンスの問題を見つけます。あらゆる判断に異議を唱えます。正しいと証明されるまでは、コードに問題があるものと見なします
• 主要モデル： Grok 4
• フォールバック： Gemini 3.1 Pro、Claude Opus 4.6
• Grok 4 を選ぶ理由： Arena 全体で 4 位であり、率直で反対意見を述べるコミュニケーションスタイルを備えています。コーダーとは根本的に異なるモデルファミリーを使うことで、自己満足的なレビューではなく、真の敵対的視点を確保します
• 異なるモデルファミリーが重要な理由： 同じファミリーのモデルは、似た盲点を共有しています。異なるファミリーによるレビューなら、同じファミリーのレビューでは見落とす問題を発見できます
• ツール： 読み取り専用です。敵対的レビュアーは編集を行わず、深刻度順に並べた問題の一覧を作成します
• 出力： 深刻度（重大／高／中／低）、再現手順、修正案を含む問題一覧

7. ピアレビュアー

• 役割： 品質評価、アーキテクチャレビュー、スタイルの一貫性、ベストプラクティス、ドキュメントレビュー、保守性の分析
• 主要モデル： Claude Opus 4.6
• フォールバック： GPT-4o
• Opus を選ぶ理由： 構造的で徹底した分析に優れています。実用性と品質基準のバランスを取ります
• フォールバックとして GPT-4o を選ぶ理由： ピアレビューにおける肯定的バイアスが最も少ないことが示されています（Sakana AI の AI Scientist 研究による）。敵対的にならず、率直な評価を行います
• ツール： 読み取り専用です。「承認」「変更を要求」「却下」の明確な判定を含むレビューを作成します
• 出力： 判定、良い判断への評価、具体的な変更要求を含む構造化レビュー

---

動作の仕組み

これは手動ディスパッチ型のワークフローです。ディスパッチャーとなるのは、あなた（またはプライマリエージェントのセッション）です。エージェントが自律的にオーケストレーションを行うことはありません。以下のオーケストレーションループに従い、必要に応じて各エージェントを呼び出し、ハンドオフプロトコルを使ってエージェント間でコンテキストを渡します。このスキルが提供するのは、ワークフローのパターン、エージェントの定義、ハンドオフ形式です。判断はあなたが行います。

オーケストレーションループ

複雑なタスクはすべて、このループに従います。プランナーは常に開始点であり、終了点でもあります。

┌──────────────────────────────────────────────┐
│                  PLANNER                      │
│           Claude Opus 4.6 (thinking)          │
│                                               │
│  1. Analyze the full task and constraints      │
│  2. Break into concrete subtasks              │
│  3. Assign each subtask to an agent role      │
│  4. Define success criteria per subtask       │
│  5. Specify execution order and dependencies  │
│  6. Identify which subtasks can run parallel  │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│             EXECUTION PHASE                   │
│     (parallel where no dependencies)          │
│                                               │
│  ┌──────────┐ ┌───────────┐ ┌──────────┐    │
│  │  Coder   │ │Researcher │ │Scientist │    │
│  │ GPT-5.4  │ │Gemini 3.1 │ │Gemini 3  │    │
│  └────┬─────┘ └─────┬─────┘ └────┬─────┘    │
│       │             │             │           │
│       ▼             ▼             ▼           │
│  ┌────────────────────────────────────────┐  │
│  │       Results + Artifacts               │  │
│  └────────────────────────────────────────┘  │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│              REVIEW PHASE                     │
│  (both reviewers in parallel for Patterns A-D)│
│                                               │
│  ┌───────────────┐  ┌───────────────┐        │
│  │  Adversarial  │  │     Peer      │        │
│  │    Grok 4     │  │  Claude Opus  │        │
│  └───────┬───────┘  └───────┬───────┘        │
│          │                  │                 │
│          ▼                  ▼                 │
│  ┌────────────────────────────────────────┐  │
│  │     Review Verdicts + Issue Lists       │  │
│  └────────────────────────────────────────┘  │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│            PLANNER RE-ENTERS                  │
│                                               │
│  Evaluates all review feedback:               │
│                                               │
│  • All clear → Accept and complete            │
│  • Minor issues → Send back to coder          │
│  • Major issues → Replan from scratch         │
│  • Reviewers disagree → Planner adjudicates   │
│  • New information → Update plan, re-execute  │
└──────────────────────────────────────────────┘

最大反復回数

無限ループを防ぐため、次の制限を適用します。

• コーディング → レビューのサイクル： 最大3回です。3ラウンドを経てもコーダーがレビュアーを満足させられない場合、プランナーはアプローチを簡略化するか、ユーザーにエスカレーションする必要があります
• 全面的な再計画： タスクごとに最大2回です。2回の再計画後、プランナーは既知の問題を記録したうえで、現時点の成果を提示します
• 個々のエージェントのタイムアウト： 妥当な労力をかけても有用な出力が得られないエージェントがいる場合、プランナーは代替モデルに担当を割り当てるか、サブタスクを簡略化します

---

引き継ぎプロトコル

エージェント間で作業を引き継ぐ際は、構造化された形式にする必要があります。プランナーが各引き継ぎを作成し、エージェント同士が直接やり取りすることはありません。

実用上の注意： 以下の YAML 形式は目安となるテンプレートであり、厳密な契約ではありません。実際のモデルが常に完璧な YAML を出力するとは限りません。プランナーは、エージェントがどのような形式（構造化された YAML、Markdown、自由形式のテキスト）で出力しても、関連情報を抽出する必要があります。重要なのは、書式が正確であることではなく、フェーズ間で情報が正しく受け渡されることです。エージェントが YAML ではなく自由形式のテキストを返した場合、プランナーは主要なフィールド（ステータス、概要、変更したファイル、見つかった問題）を抽出し、次の引き継ぎを手動で作成します。

プランナー → 実行エージェント

handoff:
  to: coder                           # agent role
  task_id: 2
  description: "Implement OAuth2 PKCE flow"
  context: |
    The codebase uses JWT tokens stored in httpOnly cookies.
    Middleware at /api/auth/middleware.ts validates tokens on every request.
    The researcher found 3 existing auth patterns (see research summary below).
    Extend the JWT pattern — do not replace it.
  dependencies_resolved:
    - task_id: 1
      agent: researcher
      summary: "Found JWT, session, and API key auth patterns. JWT is most recent."
      key_files:
        - /api/auth/jwt.ts (lines 1-45)
        - /api/auth/middleware.ts (lines 12-30)
  constraints:
    - "Must extend existing JWT pattern, not replace it"
    - "Must be backward-compatible with existing middleware"
    - "Must include tests"
  success_criteria:
    - "OAuth2 PKCE flow works end-to-end"
    - "Existing auth tests still pass"
    - "New tests cover PKCE-specific scenarios"

実行エージェント → プランナー（結果）

result:
  from: coder
  task_id: 2
  status: complete                     # complete | partial | failed | blocked
  summary: "Implemented PKCE flow in 3 files, added 8 tests"
  artifacts:
    files_changed:
      - /api/auth/pkce.ts (new, 120 lines)
      - /api/auth/middleware.ts (modified, added PKCE validation)
      - /api/auth/__tests__/pkce.test.ts (new, 85 lines)
    test_results: "8 passed, 0 failed"
  notes: |
    Used crypto.subtle for code verifier generation (Web Crypto API).
    The middleware change is backward-compatible — existing JWT auth still works.
  concerns:
    - "Code verifier storage uses session — may need Redis for horizontal scaling"

プランナー → レビューエージェント

handoff:
  to: adversarial_reviewer
  task_id: 4
  description: "Security audit of OAuth2 PKCE implementation"
  context: |
    The coder implemented a PKCE flow. Review for security vulnerabilities,
    edge cases, and correctness. Be especially critical of:
    - Cryptographic operations (code verifier, code challenge)
    - Token storage and transmission
    - CSRF and replay attack vectors
    - Error handling in auth flows
  artifacts_to_review:
    - /api/auth/pkce.ts
    - /api/auth/middleware.ts
    - /api/auth/__tests__/pkce.test.ts
  implementation_summary: |
    Uses crypto.subtle for code verifier. Session-based storage.
    Middleware validates PKCE alongside existing JWT.

レビューエージェント → プランナー（判定）

verdict:
  from: adversarial_reviewer
  task_id: 4
  decision: request_changes            # approve | request_changes | reject
  critical_issues:
    - severity: high
      location: /api/auth/pkce.ts:45
      issue: "Code verifier stored in plaintext session — if session is compromised, PKCE is defeated"
      suggestion: "Hash the verifier before storage, compare hashes on validation"
    - severity: medium
      location: /api/auth/pkce.ts:78
      issue: "No expiration on code challenge — replay attack window is unlimited"
      suggestion: "Add 10-minute TTL on challenge, clean up expired entries"
  minor_issues:
    - severity: low
      location: /api/auth/__tests__/pkce.test.ts
      issue: "No test for expired challenge scenario"
  positive_observations:
    - "Good use of crypto.subtle over Math.random for verifier generation"
    - "Backward compatibility with existing JWT flow is well-handled"

---

ワークフローパターン

パターン A：計画 → コーディング → レビュー（デフォルト）

ほとんどの開発タスクで使われる基本的なパターンです。

Planner → Coder → [Adversarial + Peer Review] → Planner

使用する場合： 機能の追加、バグ修正、コードのリファクタリング。ほとんどのタスクはここから始まります。

プランナーの動作： 明確なサブタスクを含む単一の計画を作成します。レビュー後、承認、修正、再開のいずれかを決定します。

パターン B：調査 → 計画 → コーディング → レビュー

実装の前に理解が必要なタスクで使います。

Planner → Researcher → Planner (replan) → Coder → [Review] → Planner

使用する場合： 不慣れな API の利用、アーキテクチャ上のアプローチの選択、統合作業など、計画の前に情報が必要なあらゆるタスク。

プランナーの動作： 最初の計画は「調査フェーズのみ」です。調査が完了した後、プランナーは新たに、得られた情報に基づいた実装計画を作成します。

パターン C：詳細分析

数学、科学、または視覚的な推論が多く必要なタスク向けです。

Planner → [Scientist + Visual Analyst + Researcher] → Planner → Coder → [Review] → Planner

使用する場合： データパイプライン、ML モデル、アルゴリズムの実装、視覚的なリグレッションテストなど、形式的な正確性が求められるあらゆるタスク。

プランナーの動作： 実装計画を作成する前に、複数の専門エージェントから分析を集めます。科学者の出力が、コーダーにできることを直接制約します。

パターン D：完全なパイプライン

大規模で複雑なタスク向けの完全なワークフローです。

Planner → Researcher → Planner (replan) → [Coder + Scientist] → Visual Analyst → [Adversarial + Peer Review] → Planner

使用する場合： 主要な機能、システム設計、アーキテクチャの変更など、重要度の高いあらゆるタスク。

プランナーの動作： 複数回の再計画サイクルを実行します。実装後にビジュアルアナリストが UI を確認します。承認前に完全なレビューを行います。

パターン E：迅速な反復

完全なレビューが過剰となる、迅速な修正向けです。

Planner → Coder → Adversarial Reviewer → Planner

使用する場合： 小さなバグ修正、軽微なリファクタリング、ドキュメントの更新。同業者レビュアーは省略します。敵対的なチェックでセキュリティと正確性の問題を検出できるため、小規模な変更にはそれで十分です。

プランナーの動作： 簡易的な計画を立て、1回だけレビューを行い、迅速に完了します。

パターン F：調査のみ

実装ではなく、情報が必要な場合に使います。

Planner → [Researcher + Scientist] → Planner → Summary

使用する場合： 技術調査、実現可能性の調査、競合分析、意思決定の支援。

プランナーの動作： 調査と分析を統合し、意思決定にすぐ使える概要を作成します。コードは作成しません。

---

プランナーの出力形式

プランナーは、他のエージェントが従える構造化された計画を作成します。次の形式を使用します。

plan:
  task: "Description of the overall task"
  pattern: A                             # Which workflow pattern (A-F)
  
  subtasks:
    - id: 1
      description: "Research existing auth patterns in the codebase"
      agent: researcher
      depends_on: []
      success_criteria: "Summary of auth patterns with file locations and recommendations"
    
    - id: 2
      description: "Implement OAuth2 PKCE flow extending existing JWT auth"
      agent: coder
      depends_on: [1]
      success_criteria: "Working OAuth2 PKCE flow with tests passing, backward-compatible"
    
    - id: 3
      description: "Verify cryptographic correctness of PKCE implementation"
      agent: scientist
      depends_on: [2]
      success_criteria: "Formal verification that entropy, hashing, and timing are correct"
    
    - id: 4
      description: "Security audit — find vulnerabilities and edge cases"
      agent: adversarial_reviewer
      depends_on: [2]
      success_criteria: "Security audit with no unaddressed critical or high issues"
    
    - id: 5
      description: "Architecture and quality review"
      agent: peer_reviewer
      depends_on: [2]
      success_criteria: "Approved or specific changes requested"
  
  execution_order:
    - phase: 1
      parallel: [1]
    - phase: 2
      parallel: [2]
    - phase: 3
      parallel: [3, 4, 5]
  
  notes: |
    Subtasks 3, 4, 5 can run in parallel since they all review the same output.
    If review finds critical issues, we loop back to subtask 2 with fixes.

---

ツール別セットアップ

OpenCode（マルチプロバイダーに推奨）

OpenCode は、エージェントごとにモデルを上書きでき、75 以上の LLM プロバイダーをネイティブにサポートしています。ゲートウェイは不要です。OpenCode 自体がゲートウェイです。

API キー

プロバイダーの API キーを環境変数として設定します。利用する予定のプロバイダーのキーだけが必要です。直接利用するプロバイダーかクラウドプロバイダー（Bedrock／Azure）を選ぶか、組み合わせてください。

# --- Direct providers ---
export ANTHROPIC_API_KEY="sk-ant-..."
export OPENAI_API_KEY="sk-..."
export GOOGLE_API_KEY="..."            # or GOOGLE_GENERATIVE_AI_API_KEY
export XAI_API_KEY="..."

# --- Amazon Bedrock (alternative for Claude + other models) ---
export AWS_ACCESS_KEY_ID="..."
export AWS_SECRET_ACCESS_KEY="..."
export AWS_REGION="us-east-1"          # or us-west-2, eu-west-1, etc.

# --- Microsoft Azure OpenAI (alternative for GPT models) ---
export AZURE_API_KEY="..."
export AZURE_RESOURCE_NAME="your-resource"
export AZURE_DEPLOYMENT_NAME="your-deployment"
export AZURE_API_VERSION="2024-12-01-preview"

# --- Google Vertex AI (alternative for Gemini models) ---
export GOOGLE_CLOUD_PROJECT="your-project"
export GOOGLE_APPLICATION_CREDENTIALS="/path/to/service-account.json"
# export GOOGLE_GENAI_USE_VERTEXAI=true

プロバイダーの設定（opencode.json）

利用するプロバイダーを設定します。すべてを設定する必要はありません。インフラストラクチャに合ったものを選んでください。

{
  "provider": {
    "anthropic": {
      "api_key": "{env:ANTHROPIC_API_KEY}"
    },
    "openai": {
      "api_key": "{env:OPENAI_API_KEY}"
    },
    "google": {
      "api_key": "{env:GOOGLE_API_KEY}"
    },
    "xai": {
      "api_key": "{env:XAI_API_KEY}"
    },
    "bedrock": {
      "aws_access_key_id": "{env:AWS_ACCESS_KEY_ID}",
      "aws_secret_access_key": "{env:AWS_SECRET_ACCESS_KEY}",
      "aws_region": "{env:AWS_REGION}"
    },
    "azure": {
      "api_key": "{env:AZURE_API_KEY}",
      "resource_name": "{env:AZURE_RESOURCE_NAME}"
    },
    "vertex": {
      "project": "{env:GOOGLE_CLOUD_PROJECT}"
    }
  }
}

エージェント定義

エージェント定義は、セットアップスクリプトを使って正規テンプレートから生成されます。スキルディレクトリから実行してください。

# Project-level (recommended)
sh agents/setup.sh opencode

# Or specify a custom target directory
sh agents/setup.sh opencode ~/.config/opencode/agents

これにより、正しい OpenCode フロントマター（model: provider/id、permission: edit: deny）を含む 7 つのエージェント .md ファイルが .opencode/agents/ に生成されます。

各エージェントは異なるプロバイダー／モデルを使用します。OpenCode はモデルのプレフィックスに基づいて、適切なプロバイダーに自動的にルーティングします。

デフォルトの割り当て（直接利用するプロバイダー）：

エージェント	モデル ID	プロバイダー
Planner	anthropic/claude-opus-4-6	Anthropic
Coder	openai/gpt-5.4	OpenAI
Researcher	google/gemini-3.1-pro	Google
Scientist	google/gemini-3-pro	Google
Visual Analyst	anthropic/claude-opus-4-6	Anthropic
Adversarial Reviewer	xai/grok-4	xAI
Peer Reviewer	anthropic/claude-opus-4-6	Anthropic

Amazon Bedrock の代替案 — Bedrock 経由でルーティングするには、エージェントの .md ファイルでモデル ID を置き換えます。

エージェント	Bedrock モデル ID
Planner	bedrock/anthropic.claude-opus-4-6-v1
Coder	bedrock/anthropic.claude-sonnet-4-5-v1
Researcher	bedrock/amazon.nova-pro-v1
Scientist	bedrock/anthropic.claude-opus-4-6-v1
Visual Analyst	bedrock/anthropic.claude-opus-4-6-v1
Adversarial Reviewer	bedrock/amazon.nova-pro-v1
Peer Reviewer	bedrock/anthropic.claude-opus-4-6-v1

注：Bedrock を使うと、別途 Anthropic API キーを用意せずに Claude モデルを利用できます（AWS 経由で課金されます）。Gemini と Grok は Bedrock では利用できません。代替として Amazon Nova または Claude を使うか、Bedrock と直接利用するプロバイダーを組み合わせてください。

Microsoft Azure OpenAI の代替案 — Azure を利用する組織向け：

エージェント	Azure モデル ID
Planner	azure/claude-opus-4-6
Coder	azure/gpt-5.4
Researcher	azure/gpt-5.4
Scientist	azure/gpt-5.4
Visual Analyst	azure/claude-opus-4-6
Adversarial Reviewer	azure/gpt-4o
Peer Reviewer	azure/claude-opus-4-6

注：Azure OpenAI のモデル ID は、デプロイ名によって異なります。上記の ID は、モデル名と一致するデプロイがあることを前提としています。Azure では、Azure サブスクリプション経由の課金で GPT モデルと Claude モデル（Azure AI Foundry 経由）を利用できます。Gemini と Grok は Azure では利用できません。代替として GPT-4o または Claude を使うか、Azure と直接利用するプロバイダーを組み合わせてください。

Google Vertex AI の代替案 — GCP を利用する組織向け：

エージェント	Vertex AI モデル ID
Researcher	vertex/gemini-3.1-pro
Scientist	vertex/gemini-3-pro
Visual Analyst	vertex/gemini-3.1-pro

注：Vertex AI では、GCP 経由の課金で Gemini モデルを利用できます。Claude も Vertex AI Model Garden 経由で利用できます。

プロバイダーの組み合わせを推奨します。 1 つのクラウドに限定する必要はありません。Claude には Bedrock、GPT には Azure、Gemini と Grok には直接利用するプロバイダーを使ってください。各エージェントの .md ファイルでモデルのプレフィックスを変更するだけです。

エージェントの呼び出し

OpenCode では、エージェント名を指定してエージェントを呼び出します。オーケストレーションを行うエージェント（あなた、つまりプライマリエージェント）が、前述のワークフローパターンに従います。

@planner Break down this task: implement user authentication with OAuth2 PKCE

その後、計画に従い、指示された各エージェントを呼び出します。

@researcher Find existing auth patterns in this codebase
@coder Implement PKCE flow based on the research findings: [paste context]
@adversarial-reviewer Review this PKCE implementation for security issues: [paste context]
@peer-reviewer Review code quality and architecture: [paste context]

---

Claude Code

Claude Code は成熟したサブエージェントアーキテクチャを備えていますが、サブエージェントで利用できるモデルは Anthropic のものに限られます。プロバイダーをまたいで利用するかどうかに応じて、3 つの方法があります。

アプローチ 1：Anthropic のみ（ゲートウェイなし）

すべてのエージェントで Anthropic モデルを使用します。異なるファミリー間での敵対的レビューはできなくなりますが、シンプルになります。

エージェント	Claude Code のモデル	備考
プランナー	opus	拡張思考に対応し、ファイルは編集しません
コーダー	sonnet	高速で、コードに強いモデルです
リサーチャー	opus	情報の統合に強く、ウェブツールと併用します
サイエンティスト	opus	妥当な数学的能力を備えています
ビジュアルアナリスト	opus	Anthropic ファミリーで最も優れたマルチモーダルモデルです
敵対的レビュアー	sonnet	opus とは異なりますが、同じファミリーのため、敵対的レビューの効果は弱まります
ピアレビュアー	opus	構造化された分析を行います

制限事項： 同じモデルファミリーによる敵対的レビューの効果は低くなります。Sonnet に強力な敵対的プロンプトを与えて敵対的レビュアーとして使うことで部分的に補えますが、同じファミリーに共通する盲点は残ります。

エージェント定義ファイル： セットアップスクリプトを使って、正規テンプレートから生成します。

sh agents/setup.sh claude-code

これにより、Anthropic 固有のフロントマター（model: opus/sonnet、allowed-tools、effort）を含む 7 つのエージェント .md ファイルが .claude/agents/ に生成されます。

アプローチ 2：OpenRouter ゲートウェイを使用

MCP サーバーまたはスクリプトを使って、特定のエージェントから外部モデルを呼び出します。これにより、異なるファミリー間で真の敵対的レビューを行えます。

手順 1： OpenRouter API キーを設定します。

export OPENROUTER_API_KEY="sk-or-..."

手順 2： ゲートウェイ用のスクリプトディレクトリとスクリプトを作成します。

mkdir -p .claude/scripts
cat > .claude/scripts/call-model.sh << 'SCRIPT'
#!/bin/bash
# Usage: call-model.sh <model> <prompt-file>
# Reads prompt from a file to avoid shell argument length limits.
# If no file given, reads from stdin.
MODEL="$1"
PROMPT_FILE="$2"

if [ -z "$OPENROUTER_API_KEY" ]; then
  echo "Error: OPENROUTER_API_KEY not set" >&2
  exit 1
fi

if [ -n "$PROMPT_FILE" ] && [ -f "$PROMPT_FILE" ]; then
  PROMPT=$(cat "$PROMPT_FILE")
elif [ ! -t 0 ]; then
  PROMPT=$(cat)
else
  PROMPT="$2"
fi

RESPONSE=$(curl -s https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{
    \"model\": \"$MODEL\",
    \"messages\": [{\"role\": \"user\", \"content\": $(echo "$PROMPT" | jq -Rs .)}]
  }")

ERROR=$(echo "$RESPONSE" | jq -r '.error.message // empty')
if [ -n "$ERROR" ]; then
  echo "API Error: $ERROR" >&2
  exit 1
fi

echo "$RESPONSE" | jq -r '.choices[0].message.content'
SCRIPT
chmod +x .claude/scripts/call-model.sh

手順 3： Claude Code で、オーケストレーションを担当するエージェントがこのスクリプトを使って、異なるプロバイダーを呼び出せるようにします。

# Call Grok for adversarial review (short prompt as argument)
bash .claude/scripts/call-model.sh "xai/grok-4" "Review this code for security issues: ..."

# Call Gemini for research (long prompt via stdin)
echo "Research the best approach for implementing OAuth2 PKCE..." | \
  bash .claude/scripts/call-model.sh "google/gemini-3.1-pro"

このハイブリッド方式では、Anthropic モデルには Claude Code ネイティブのサブエージェントを使い、その他のプロバイダーにはゲートウェイスクリプトを使います。

アプローチ 3：Vercel AI Gateway を使用

OpenRouter と同じですが、Vercel のゲートウェイエンドポイントを使用します。

#!/bin/bash
# .claude/scripts/call-model.sh (Vercel AI Gateway version)
MODEL="$1"
PROMPT="$2"

curl -s https://ai-gateway.vercel.sh/v1/chat/completions \
  -H "Authorization: Bearer $AI_GATEWAY_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{
    \"model\": \"$MODEL\",
    \"messages\": [{\"role\": \"user\", \"content\": $(echo "$PROMPT" | jq -Rs .)}]
  }" | jq -r '.choices[0].message.content'

Vercel AI Gateway の利点： トークンへの上乗せ料金がなく、40 以上のプロバイダーに対応し、Vercel にデプロイされたアプリでは OIDC 認証を利用できます（キー管理は不要です）。

---

Cursor

Cursor はプログラムによるサブエージェントの起動に対応していません。モデルを順に切り替えて使用します。

1. モデル選択メニューで Claude Opus を選択 → タスクを計画します
2. GPT-5.4 に切り替え → 計画を実装します
3. Grok 4 または Gemini に切り替え → 実装をレビューします
4. Claude Opus に戻す → レビューを評価し、次の手順を決定します

Cursor ルール（.cursor/rules/）

各フェーズをガイドするルールを作成します。.cursor/rules/ に配置します。

.cursor/rules/agent-collaboration.mdc

---
description: Multi-model agent collaboration workflow
globs: ["**/*"]
---

# Agent Collaboration Workflow

When working on complex tasks, follow this workflow:

## Planning Phase (use Claude Opus)
- Break the task into subtasks with clear success criteria
- Identify dependencies between subtasks
- Assign each subtask to an execution phase

## Implementation Phase (use GPT-5.4 or Claude Sonnet)
- Follow the plan exactly
- Write tests for new functionality
- Report what changed and why

## Review Phase (switch model for fresh perspective)
- Review for security vulnerabilities, edge cases, and logical errors
- Check architecture, style, and best practices
- Provide explicit verdict: approve or request changes

## Replan Phase (use Claude Opus)
- Evaluate review feedback
- Decide: accept, revise, or restart
- If revising, specify exact changes for the coder

---

Codex CLI

Codex CLI は Agent Skills 標準に対応しており、主に OpenAI モデルを使用します。複数モデルを使うには、次のようにします。

1. 実装は Codex が担当します（ネイティブの GPT-5.4 を使用）
2. その他のモデルにはゲートウェイスクリプトを使用します（Claude Code と同じ call-model.sh 方式）

標準形式に従って、エージェントスキルを .codex/skills/ に配置します。

環境設定

# Codex uses your ChatGPT account or API key
export OPENAI_API_KEY="sk-..."

# For cross-provider calls via gateway
export OPENROUTER_API_KEY="sk-or-..."

---

Gemini CLI

Gemini CLI は Gemini のみを使う単一エージェントです。順次モードを使用します。

1. 計画と調査には Gemini 3.1 Pro を使用します（どちらにも強いモデルです）
2. コーディングにはゲートウェイスクリプトを使用します（OpenRouter 経由で GPT-5.4 を呼び出します）
3. レビューには Gemini 3.1 Pro を使用します（敵対的分析に強いモデルです）

GEMINI.md との統合

GEMINI.md にワークフローの指示を追加します。

# Agent Collaboration

For complex tasks, follow this multi-phase workflow:

1. PLAN: Break the task into subtasks with success criteria
2. RESEARCH: Search the web and documentation for relevant context
3. IMPLEMENT: Write code following the plan (call external model if needed)
4. REVIEW: Critically review the implementation for flaws
5. REPLAN: Evaluate and decide next steps

---

Aider

Aider にはプランナーとコーダーの役割に自然に対応する、組み込みのデュアルモデルワークフローがあります。

.aider.conf.yml

# Architect model = Planner (proposes the approach)
model: anthropic/claude-opus-4-6

# Editor model = Coder (implements the changes)
editor-model: openai/gpt-5.4

# Weak model = Fast tasks (commit messages, summaries)
weak-model: google/gemini-3-flash

# Enable architect mode
edit-format: architect

できること： Claude Opus がアプローチを計画し、GPT-5.4 が編集を実装します。これにより、パターン A（計画 → コード）をネイティブに実行できます。

できないこと： レビューフェーズです。レビューを行うには、別の aider セッションを実行します。

# Review session with a different model
aider --model xai/grok-4 --no-auto-commits --message "Review the recent changes for security issues and edge cases"

プロバイダーのサポート： Aider は内部で LiteLLM を使用しており、100 以上のプロバイダーに対応しています。provider/model-id 形式であれば、どれでも使用できます。

---

ゲートウェイの設定

ゲートウェイなし：プロバイダーの直接 API

ネイティブなマルチプロバイダー対応のツール（OpenCode）を使う場合や、単一のプロバイダーを使用する場合：

# --- Direct providers ---
export ANTHROPIC_API_KEY="sk-ant-..."    # Claude models
export OPENAI_API_KEY="sk-..."           # GPT models
export GOOGLE_API_KEY="..."              # Gemini models
export XAI_API_KEY="..."                 # Grok models

# --- Cloud providers (alternative or additional) ---
# Amazon Bedrock — Claude, Amazon Nova, Mistral, Llama, etc.
export AWS_ACCESS_KEY_ID="..."
export AWS_SECRET_ACCESS_KEY="..."
export AWS_REGION="us-east-1"

# Microsoft Azure OpenAI — GPT, Claude (via AI Foundry)
export AZURE_API_KEY="..."
export AZURE_RESOURCE_NAME="your-resource"
export AZURE_API_VERSION="2024-12-01-preview"

# Google Vertex AI — Gemini, Claude (via Model Garden)
export GOOGLE_CLOUD_PROJECT="your-project"
export GOOGLE_APPLICATION_CREDENTIALS="/path/to/service-account.json"

# --- Other direct providers ---
export MISTRAL_API_KEY="..."
export DEEPSEEK_API_KEY="..."
export GROQ_API_KEY="..."

最適な用途： OpenCode（ネイティブなルーティング）、Aider（LiteLLM によるルーティング）、プロバイダーの API に直接アクセスできるあらゆるツール。

プロバイダーの併用は一般的です。 Claude には bedrock/（AWS 経由で課金）、GPT には azure/（Azure 経由で課金）、Gemini には google/ または vertex/ を直接使用します。各エージェントのモデル ID のプレフィックスによって使用するプロバイダーが決まるため、ゲートウェイは不要です。

OpenRouter：統合 API

単一の API キーとエンドポイントで、すべてのプロバイダーの 100 以上のモデルを利用できます：

export OPENROUTER_API_KEY="sk-or-..."

エンドポイント： https://openrouter.ai/api/v1/chat/completions

モデル形式： provider/model-name

• anthropic/claude-opus-4-6
• openai/gpt-5.4
• google/gemini-3.1-pro
• xai/grok-4
• google/gemini-3-pro
• openai/gpt-4o

CLI ツール向けゲートウェイスクリプト：

#!/bin/bash
# gateway-openrouter.sh — call any model via OpenRouter
# Usage: gateway-openrouter.sh <model> <system_prompt> <user_prompt>

MODEL="$1"
SYSTEM="$2"
PROMPT="$3"

if [ -z "$OPENROUTER_API_KEY" ]; then
  echo "Error: OPENROUTER_API_KEY not set" >&2
  exit 1
fi

RESPONSE=$(curl -s https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -H "HTTP-Referer: https://skills.sh/pascalorg" \
  -H "X-OpenRouter-Title: Agent Collaboration" \
  -d "{
    \"model\": \"$MODEL\",
    \"messages\": [
      {\"role\": \"system\", \"content\": $(echo "$SYSTEM" | jq -Rs .)},
      {\"role\": \"user\", \"content\": $(echo "$PROMPT" | jq -Rs .)}
    ],
    \"temperature\": 0.3
  }")

echo "$RESPONSE" | jq -r '.choices[0].message.content'

最適な用途： Claude Code、Codex CLI、Gemini CLI — スクリプト経由でプロバイダーをまたいで利用する必要がある、単一のプロバイダーに固定されたツール。

Vercel AI Gateway：上乗せ料金なし

40 以上のプロバイダー、トークンの上乗せ料金なし、マネージドインフラストラクチャ：

export AI_GATEWAY_API_KEY="..."    # From Vercel Dashboard

エンドポイント： https://ai-gateway.vercel.sh/v1/chat/completions

モデル形式： OpenRouter と同じ — provider/model-name

プロバイダーの優先順位とフォールバック（Vercel AI SDK を使用する場合）：

import { gateway } from '@ai-sdk/gateway';
import { generateText } from 'ai';

const result = await generateText({
  model: gateway('anthropic/claude-opus-4-6'),
  prompt: 'Plan this task...',
  providerOptions: {
    gateway: {
      order: ['anthropic', 'bedrock'],     // Try Anthropic first, fall back to Bedrock
      caching: 'auto',                     // Automatic provider-appropriate caching
    }
  }
});

CLI ツール向けゲートウェイスクリプト（OpenRouter と同じパターンで、エンドポイントのみ異なります）：

#!/bin/bash
# gateway-vercel.sh — call any model via Vercel AI Gateway
# Usage: gateway-vercel.sh <model> <system_prompt> <user_prompt>

MODEL="$1"
SYSTEM="$2"
PROMPT="$3"

if [ -z "$AI_GATEWAY_API_KEY" ]; then
  echo "Error: AI_GATEWAY_API_KEY not set" >&2
  exit 1
fi

RESPONSE=$(curl -s https://ai-gateway.vercel.sh/v1/chat/completions \
  -H "Authorization: Bearer $AI_GATEWAY_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{
    \"model\": \"$MODEL\",
    \"messages\": [
      {\"role\": \"system\", \"content\": $(echo "$SYSTEM" | jq -Rs .)},
      {\"role\": \"user\", \"content\": $(echo "$PROMPT" | jq -Rs .)}
    ],
    \"temperature\": 0.3
  }")

echo "$RESPONSE" | jq -r '.choices[0].message.content'

最適な用途： Vercel プロジェクト、AI SDK を使用する TypeScript コードベース、トークンの上乗せ料金がないマネージドゲートウェイを求めるチーム。

---

エスカレーションルール

プランナーは、定められたチェックポイントでループに再び参加します。以下のルールは必ず守る必要があります。

プランナーが必ず再参加するタイミング

1. 各実行フェーズの後 — プランナーはレビューに進む前に、すべての結果を評価します
2. 各レビューフェーズの後 — プランナーはレビューのフィードバックをまとめ、次の手順を決定します
3. エージェントに失敗が発生したとき — 同じモデルで再試行するか、フォールバックモデルに割り当て直すか、サブタスクを簡略化するかをプランナーが決定します
4. レビュアーの意見が分かれたとき — プランナーは両方の立場を評価し、根拠を検討して最終判断を下します
5. 新しい情報が得られたとき — エージェントが計画を無効にする何かを発見した場合、プランナーは計画を立て直します
6. スコープが変わったとき — ユーザーの要件が変わった場合、プランナーはタスクを再分解します

プランナーが介入しないタイミング

1. 実行中 — エージェントは割り当てられた範囲内で独立して実行します
2. レビュー中 — レビュアーはプランナーの影響を受けずに、それぞれ独立して意見をまとめます
3. 簡単なタスクの場合 — パターン E（迅速な反復）では、プランナーの関与を最小限に抑えます

プランナーが決してしないこと

• コードを書く（それはコーダーの役目です）
• 調査を行う（それはリサーチャーの役目です）
• サイエンティストを介さずに数学的な主張をする
• 自分の計画を承認する（それはレビュアーの役目です）
• 両方のレビュアーの意見を同時に覆す（両方が否定した場合、コードには修正が必要です）

---

アンチパターン

すべてに同じモデルを使う

問題点： 敵対的レビューの利点が失われます。同じモデルでは、見落とす点も同じです。自分のコードをレビューするモデルは、自分の原稿を校正する書き手のようなもので、同じ誤りを見落とします。

対策： 最低でも、敵対的レビュアーには異なるモデルファミリーを使用します。

敵対的レビューを省略する

問題点： ピアレビューは通常、建設的な視点から行われます。改善点は見つかっても、セキュリティ上の問題や論理的な欠陥を見逃すことがあります。敵対的レビュアーは、遠慮によって見落とされる問題を見つけるために存在します。

対策： 必ず敵対的レビューを含めます。小さなタスクにはパターン E（迅速な反復）を使用します。これにも敵対的レビューが含まれます。

コーダーに自分のコードをレビューさせる

問題点： コーダーがコードを書いているときにバグに気づかなかったなら、レビュー中にも気づきません。同じコンテキスト、同じ前提、同じ誤りがあるためです。

対策： レビューには必ず別のモデル（できれば異なるモデルファミリー）を使用します。

単純なタスクを過剰にオーケストレーションする

なぜ問題なのか： 1 行の修正に 7 つのエージェントは必要ありません。単純な変更では、完全なオーケストレーションにかかるオーバーヘッドがメリットを上回ります。

対処方法： 小さなタスクにはパターン E を使用します。状況に応じて判断してください。修正内容が明白でリスクが低い場合は、そのまま実行してください。

成功基準を無視する

なぜ問題なのか： 基準がなければ、エージェントはいつ作業を終えるべきか分かりません。その結果、成果が不十分になったり、必要以上に作り込んだりします。プランナーが定める成功基準は契約です。

対処方法： プランナーはすべてのサブタスクに成功基準を定義する必要があります。エージェントは完了を報告する前に、基準に照らして作業を検証する必要があります。

プランナーにファイル編集権限を与える

なぜ問題なのか： プランナーがコードを書くと、結果を客観的に評価できなくなります。役割の分離は、このワークフローの基盤です。

対処方法： プランナーはファイルを編集しません。コードを読み、コンテキストを得るために読み取り専用コマンド（git log、ls）を実行し、実作業を行うサブエージェントを起動します。

引き継ぎ時にコンテキストが不足している

なぜ問題なのか： コーダーがリサーチャーの調査結果を知らなければ、調査をやり直したり、推測したりします。レビュアーが制約を知らなければ、意図的なトレードオフをバグとして指摘します。

対処方法： 引き継ぎプロトコルに従ってください。すべてのエージェントが必要なコンテキストを確実に得られるようにする責任は、プランナーにあります。

エージェント同士を直接議論させる

なぜ問題なのか： エージェントには共有コンテキストがありません。プランナーの仲介なしにエージェント同士が「議論」すると、堂々巡りになり、トークンを無駄にします。

対処方法： すべてのコミュニケーションはプランナーを通じて行います。プランナーが情報を統合し、判断し、指示を出します。

---

モデル一覧

2026 年 4 月時点のベンチマークに基づく、現在の推奨モデル割り当てです。新しいモデルのリリースに伴い、更新されます。

主な割り当て

役割	モデル	プロバイダー ID	ベンチマークの根拠
プランナー	Claude Opus 4.6 (thinking)	anthropic/claude-opus-4-6	Arena #1（1504 Elo）、ARC-AGI 2 68.8%
コーダー	GPT-5.4 (high)	openai/gpt-5.4	Aider リーダーボード #1（88%）、SWE-bench で高い性能
リサーチャー	Gemini 3.1 Pro	google/gemini-3.1-pro	HLE 45.8%、MMMLU 91.8%
科学者	Gemini 3 Pro	google/gemini-3-pro	AIME 2025 100%、GPQA Diamond 94.3%
ビジュアルアナリスト	Claude Opus 4.6	anthropic/claude-opus-4-6	ARC-AGI 2 68.8%、MMMU で高い性能
敵対的レビュアー	Grok 4	xai/grok-4	Arena #4、反対意見を述べるスタイル、異なるファミリー
ピアレビュアー	Claude Opus 4.6	anthropic/claude-opus-4-6	構造化された分析、肯定的バイアスが低い

フォールバックの割り当て

役割	フォールバック 1	フォールバック 2
プランナー	anthropic/claude-opus-4-5	openai/gpt-5.4
コーダー	anthropic/claude-sonnet-4-5	anthropic/claude-sonnet-4-6
リサーチャー	anthropic/claude-opus-4-6	openai/gpt-5.4
科学者	openai/gpt-5.2	anthropic/claude-opus-4-6
ビジュアルアナリスト	google/gemini-3.1-pro	openai/gpt-5.4
敵対的レビュアー	google/gemini-3.1-pro	anthropic/claude-opus-4-6
ピアレビュアー	openai/gpt-4o	google/gemini-3.1-pro

予算を重視した割り当て

マルチモデルの利点を保ちながら、コストを最適化するチーム向けです。

役割	予算重視モデル	プロバイダー ID	トレードオフ
プランナー	Claude Sonnet 4.6	anthropic/claude-sonnet-4-6	計画の細やかさがやや劣る
コーダー	GPT-4.1	openai/gpt-4.1	コーディング性能は良好で、コストは低い
リサーチャー	Gemini 3 Flash	google/gemini-3-flash	調査が速い一方、深さはやや劣る
科学者	Gemini 3 Flash	google/gemini-3-flash	数学に強い一方、形式的な厳密さはやや劣る
ビジュアルアナリスト	Gemini 3.1 Pro	google/gemini-3.1-pro	ビジュアル分析に強く、Opus より低コスト
敵対的レビュアー	Grok 4	xai/grok-4	これを維持してください。敵対的レビューは重要です
ピアレビュアー	Claude Sonnet 4.6	anthropic/claude-sonnet-4-6	レビュー性能は良好で、コストは低い

クラウドプロバイダーの割り当て

プロバイダーの直接 API ではなく、Amazon Bedrock、Microsoft Azure、Google Vertex AI 経由でルーティングする組織向けです。

Amazon Bedrock：

役割	Bedrock モデル ID	備考
プランナー	bedrock/anthropic.claude-opus-4-6-v1	AWS 請求経由の Claude
コーダー	bedrock/anthropic.claude-sonnet-4-5-v1	Claude Sonnet はコーディングに優れています
リサーチャー	bedrock/amazon.nova-pro-v1	ナレッジ関連のタスクには Nova Pro
サイエンティスト	bedrock/anthropic.claude-opus-4-6-v1	数学的な推論には Opus
ビジュアルアナリスト	bedrock/anthropic.claude-opus-4-6-v1	Opus はマルチモーダルに優れています
敵対的レビュー担当者	bedrock/amazon.nova-pro-v1	敵対的レビューの効果を高めるため、異なるモデルファミリーを使用
ピアレビュー担当者	bedrock/anthropic.claude-opus-4-6-v1	構造化分析

注：Bedrock には GPT、Gemini、Grok はありません。幅広いモデルを利用するには、Bedrock と直接プロバイダーを組み合わせてください。Claude エージェントには bedrock/、コーダーには openai/、リサーチ／科学には google/、敵対的レビューには xai/ を使用します。

Microsoft Azure OpenAI：

役割	Azure モデル ID	備考
プランナー	azure/claude-opus-4-6	Azure AI Foundry 経由の Claude
コーダー	azure/gpt-5.4	Azure OpenAI 経由の GPT
リサーチャー	azure/gpt-5.4	ナレッジ関連のタスクには GPT
サイエンティスト	azure/gpt-5.4	数学的な推論には GPT
ビジュアルアナリスト	azure/claude-opus-4-6	Foundry 経由の Claude マルチモーダル
敵対的レビュー担当者	azure/gpt-4o	敵対的レビューの効果を高めるため、異なるモデルを使用
ピアレビュー担当者	azure/claude-opus-4-6	構造化分析

注：Azure のモデル ID はデプロイ名によって異なります。上記では、モデル名に一致するデプロイを想定しています。Azure には Gemini や Grok がネイティブにはありません。Azure と直接プロバイダーを組み合わせてください。GPT／Claude エージェントには azure/、リサーチ／科学には google/、敵対的レビューには xai/ を使用します。

Google Vertex AI：

役割	Vertex AI モデル ID	備考
プランナー	vertex/claude-opus-4-6	Model Garden 経由の Claude
コーダー	vertex/gemini-3.1-pro	Gemini はコーディングに優れています
リサーチャー	vertex/gemini-3.1-pro	Gemini が本来得意とする分野
サイエンティスト	vertex/gemini-3-pro	Gemini が本来得意とする数学
ビジュアルアナリスト	vertex/gemini-3.1-pro	Gemini はマルチモーダルに優れています
敵対的レビュー担当者	vertex/claude-opus-4-6	Model Garden 経由で異なるファミリーを使用
ピアレビュー担当者	vertex/gemini-3.1-pro	構造化分析

注：Vertex AI には Gemini がネイティブにあり、Claude は Model Garden 経由で利用できます。GPT と Grok はありません。幅広いモデルを利用するには、直接プロバイダーと組み合わせてください。

エンタープライズ向けの推奨ハイブリッド構成 — モデルの多様性を最大限に高めるため、クラウドプロバイダーと 1 つまたは 2 つの直接 API を組み合わせます。

役割	エンタープライズ向けハイブリッド構成	理由
プランナー	bedrock/anthropic.claude-opus-4-6-v1	AWS 請求経由の Claude
コーダー	azure/gpt-5.4	Azure 請求経由の GPT
リサーチャー	vertex/gemini-3.1-pro	GCP 請求経由の Gemini
サイエンティスト	vertex/gemini-3-pro	GCP 請求経由の Gemini
ビジュアルアナリスト	bedrock/anthropic.claude-opus-4-6-v1	AWS 請求経由の Claude
敵対的レビュー担当者	xai/grok-4	直接利用 — Grok はクラウドでは利用できません
ピアレビュー担当者	bedrock/anthropic.claude-opus-4-6-v1	AWS 請求経由の Claude

これにより、モデルの多様性を最大限に保ちながら、既存のクラウド契約を通じて請求を行えます。xAI はまだどのクラウドのマーケットプレイスでも利用できないため、Grok のみ直接 API キーが必要です。

プロバイダー間のモデル ID 参照表

同じモデルでも、プロバイダーによって異なる ID 形式でアクセスします。エージェント定義でプロバイダーを切り替える際は、この表を使用してください。

モデル	Direct	Bedrock	Azure	Vertex AI	OpenRouter
Claude Opus 4.6	anthropic/claude-opus-4-6	bedrock/anthropic.claude-opus-4-6-v1	azure/claude-opus-4-6	vertex/claude-opus-4-6	anthropic/claude-opus-4-6
Claude Sonnet 4.5	anthropic/claude-sonnet-4-5	bedrock/anthropic.claude-sonnet-4-5-v1	azure/claude-sonnet-4-5	vertex/claude-sonnet-4-5	anthropic/claude-sonnet-4-5
Claude Sonnet 4.6	anthropic/claude-sonnet-4-6	bedrock/anthropic.claude-sonnet-4-6-v1	azure/claude-sonnet-4-6	vertex/claude-sonnet-4-6	anthropic/claude-sonnet-4-6
GPT-5.4	openai/gpt-5.4	—	azure/gpt-5.4	—	openai/gpt-5.4
GPT-5.2	openai/gpt-5.2	—	azure/gpt-5.2	—	openai/gpt-5.2
GPT-4o	openai/gpt-4o	—	azure/gpt-4o	—	openai/gpt-4o
Gemini 3.1 Pro	google/gemini-3.1-pro	—	—	vertex/gemini-3.1-pro	google/gemini-3.1-pro
Gemini 3 Pro	google/gemini-3-pro	—	—	vertex/gemini-3-pro	google/gemini-3-pro
Gemini 3 Flash	google/gemini-3-flash	—	—	vertex/gemini-3-flash	google/gemini-3-flash
Grok 4	xai/grok-4	—	—	—	xai/grok-4
Amazon Nova Pro	—	bedrock/amazon.nova-pro-v1	—	—	—

「—」は、そのプロバイダーではモデルを利用できないことを示します。必要に応じてプロバイダーを組み合わせてください。

単一プロバイダーでのフォールバック

1つのプロバイダーしか利用できない場合：

Anthropic のみ（Claude Code のデフォルト）：

役割	モデル	備考
プランナー	Opus（思考）	十分な能力
コーダー	Sonnet	高速で、コーディングが得意
リサーチャー	Opus	優れた統合能力
サイエンティスト	Opus	数学にも十分対応
ビジュアルアナリスト	Opus	優れたマルチモーダル性能
敵対的レビュー担当者	Sonnet	異なるモデルですが、同じファミリーのため、敵対的なプロンプトを追加してください
ピアレビュー担当者	Opus	構造化された分析

OpenAI のみ（Codex のデフォルト）：

役割	モデル	備考
プランナー	GPT-5.4（high）	優れた計画能力
コーダー	GPT-5.4	ネイティブな強み
リサーチャー	GPT-5.4	優れた調査能力
サイエンティスト	GPT-5.2	優れた数学能力
ビジュアルアナリスト	GPT-5.4	優れたマルチモーダル性能
敵対的レビュー担当者	GPT-4o	異なるモデルで、スタイルも異なります
ピアレビュー担当者	GPT-5.4（high）	構造化された分析

Google のみ（Gemini CLI のデフォルト）：

役割	モデル	備考
プランナー	Gemini 3.1 Pro	優れた計画能力
コーダー	Gemini 3.1 Pro	優れたコーディング能力
リサーチャー	Gemini 3.1 Pro	ネイティブな強み
サイエンティスト	Gemini 3 Pro	ネイティブな強み
ビジュアルアナリスト	Gemini 3.1 Pro	優れたマルチモーダル性能
敵対的レビュー担当者	Gemini 3 Flash	コストと視点の両面で異なるモデル
ピアレビュー担当者	Gemini 3.1 Pro	構造化された分析

---

モデルマップの更新

モデルの能力はリリースごとに変化します。上記の割り当ては、2026年4月時点のベンチマークに基づいています。

主なベンチマークソース

最新の情報を把握するには、以下を確認してください。

ソース	URL	対象	更新頻度
Chatbot Arena	arena.ai	全体的な品質、カテゴリ別ランキング	継続的
SWE-bench	swebench.com	実世界のソフトウェアエンジニアリング	提出時
Aider Leaderboard	aider.chat/docs/leaderboards/	実用的なコード編集	リリース時
Artificial Analysis	artificialanalysis.ai	知能／速度／コストの指標	毎週
LiveBench	livebench.ai	汚染耐性のある月次評価	毎月
GPQA Diamond	—	博士レベルの科学	固定
ARC-AGI 2	arcprize.org	抽象的な視覚推論	定期的
Humanity's Last Exam	—	最先端の知識	定期的

再評価するタイミング

• 大規模な新しいモデルがリリースされたとき（新しい Claude、GPT、Gemini、Grok のバージョン）
• 関連カテゴリで Arena のランキングが 50 Elo を超えて変動したとき
• SWE-bench または Aider のリーダーボードで新しい 1 位が登場したとき
• 特定のエージェントで一貫した品質の低下に気づいたとき

今後：ベンチマーク追跡スキル

ベンチマークを自動追跡するための補助スキルを計画しています。プログラムから利用できるソース（HuggingFace のデータセット、Arena Hard Auto）から最新のランキングを取得し、更新版のモデルマップを生成します。それまでは、主要なモデルがリリースされた際に上記のソースを確認してください。

役割とベンチマークの対応

各エージェントの役割で重要なベンチマークを把握するために使用してください。

エージェントの役割	主なベンチマーク	確認する項目
プランナー	Arena（Overall、Hard Prompts）、ARC-AGI 2	抽象的な推論、複雑な指示への対応
コーダー	Aider、SWE-bench Verified	実用的なコード編集、実世界のバグ修正
リサーチャー	Arena（Knowledge）、HLE、MMMLU、BrowseComp	幅広い知識、調査結果の統合
科学者	AIME、GPQA Diamond、MATH Level 5	数学的推論、科学的知識
ビジュアルアナリスト	ARC-AGI 2、MMMU-Pro	視覚的推論、マルチモーダルな理解
敵対的レビュアー	Arena（Hard Prompts）、PropensityBench	批判的思考、肯定的な偏りの少なさ
ピアレビュアー	Arena（Overall）、AI Scientist のレビュー評価	構造化された分析、誠実な評価

---

クイックリファレンス

ワークフローの選択

タスクの規模	パターン	使用するエージェント
簡単（1 行で済むもの）	オーケストレーションを省略	そのまま実行
小規模（単一ファイル）	E（迅速）	プランナー → コーダー → 敵対的レビュアー
中規模（複数ファイル）	A（デフォルト）	プランナー → コーダー → 両方のレビュアー
中規模＋未知の API	B（まず調査）	プランナー → リサーチャー → プランナー → コーダー → レビュー
大規模	D（フルパイプライン）	すべてのエージェント、複数のフェーズ
調査のみ	F（調査）	プランナー → リサーチャー＋科学者
数学／科学が中心	C（詳細分析）	プランナー → 科学者＋ビジュアルアナリスト＋リサーチャー → コーダー → レビュー

ツールの選択

使用するツール	マルチモデル	サブエージェント	最適な方法
OpenCode	ネイティブ（75 以上のプロバイダー）	対応	フルマルチモデル。ゲートウェイは不要
Claude Code	Anthropic のみ	対応	プロバイダー横断にはゲートウェイスクリプトを使用、または Anthropic のみで運用
Cursor	UI でモデルを選択	非対応	フェーズごとにモデルを順次切り替え
Codex CLI	OpenAI のみ	対応予定	プロバイダー横断にはゲートウェイスクリプトを使用
Gemini CLI	Google のみ	非対応	順次切り替え＋ゲートウェイスクリプト
Aider	任意（LiteLLM 経由）	非対応	アーキテクト／エディターのデュアルモデル＋レビューセッション

ゲートウェイの選択

シナリオ	推奨ゲートウェイ
OpenCode のユーザー	不要 — ネイティブのマルチプロバイダー対応
すべてに単一の API キーを使用	OpenRouter
Vercel プロジェクト／TypeScript	Vercel AI Gateway
セルフホスト／完全な制御	LiteLLM プロキシ
予算の追跡が重要	Vercel AI Gateway または OpenRouter（どちらもダッシュボードを提供）
エンタープライズコンプライアンス	Portkey（SOC 2、HIPAA）

---

コストの目安

マルチモデルのオーケストレーションでは最先端モデルを使用するため、無料ではありません。タスクあたりのおおよそのコストは次のとおりです（複雑さやトークン数によって変動します）。

パターン	使用モデル	推定コスト範囲
E（高速）	3 回の呼び出し（プランナー + コーダー + 敵対的レビュアー）	$0.50 – $2
A（デフォルト）	4～5 回の呼び出し（プランナー + コーダー + 2 人のレビュアー + 再計画）	$2 – $8
B（調査優先）	6～7 回の呼び出し（+ 調査担当者 + 再計画）	$3 – $10
D（フルパイプライン）	8～12 回の呼び出し（全エージェント、複数フェーズ）	$5 – $20

これらの費用は、最先端モデル（Opus、GPT-5.4、Gemini 3.1 Pro）を使用する場合のものです。予算重視の割り当て（モデルマップを参照）では、品質がある程度低下する代わりに、コストを 50～70% 削減できます。

オーバーヘッドに見合う場合： バグや要件の見落としによって、何時間もの手戻りが発生するような複雑なタスクです。セキュリティ上の脆弱性を見つけるマルチエージェントレビューに $10 かかっても、それ以上のコストを節約できます。

見合わない場合： 些細な変更です。5 分で修正を書いて検証できるなら、オーケストレーションは省略してください。

---

トラブルシューティング

エージェントが見つからない

症状： @planner またはエージェントの呼び出しで、「agent not found」などのエラーが返されます。

対処方法： エージェント定義ファイルが正しいディレクトリにあることを確認してください。

• OpenCode：.opencode/agents/planner.md（プロジェクト）または ~/.config/opencode/agents/planner.md（グローバル）
• Claude Code：.claude/agents/planner.md（プロジェクト）または ~/.claude/agents/planner.md（グローバル）

ファイルが正しくコピーされたことを確認してください：ls .opencode/agents/ または ls .claude/agents/

モデルを利用できない／API エラー

症状： エージェントの実行時に「Model not found」、「Invalid model」、または 404 エラーが発生します。

対処方法：

• プロバイダーに対してモデル ID が正しいことを確認してください。モデル ID はプロバイダーごとに異なります。クロスプロバイダーのモデル ID 参照表を確認してください
• API キーが設定されていることを確認してください：echo $ANTHROPIC_API_KEY | head -c 10（先頭 10 文字が表示されるはずです）
• Bedrock の場合：IAM ロールに、対象モデルへの bedrock:InvokeModel 権限があることを確認してください
• Azure の場合：モデル ID 内のデプロイ名が、Azure のデプロイと一致することを確認してください

エージェントが意味のない出力を生成する

症状： エージェントが役割を無視する、本来はレビューだけを行うべきなのにコードを書く、または構造化されていない出力を生成します。

対処方法：

• エージェント定義ファイルにシステムプロンプト全体（Markdown 本文）が含まれていることを確認してください。ファイルにフロントマターしかない場合、エージェントには指示がありません
• 読み取り専用エージェントの場合、permission: edit: deny（OpenCode）または制限付きの allowed-tools（Claude Code）が設定されていることを確認してください
• ゲートウェイスクリプトを使用している場合、プロンプト全体が渡されているか確認してください。シェル引数の切り詰めはよくある問題です。長いコンテキストには、標準入力またはファイルベースのプロンプトを使用してください

コンテキストウィンドウのオーバーフロー

症状： 大規模なコードベースでエージェントがエラーになる、または出力が途中で切れます。

対処方法：

• プランナーはファイル全体を貼り付けずに、引き継ぎ時にコンテキストを要約してください。ファイルの全内容ではなく、ファイルパスと関連する行範囲を含めてください
• 調査内容を引き継ぐ場合は、調査結果を 500 語以内で要約してください。コーダーに調査結果の全文は必要ありません
• レビュー内容を引き継ぐ場合は、コードベース全体ではなく、変更したファイルのみを含めてください
• 1 つのファイルが大きすぎる場合は、プランナーにタスクをファイル単位の小さなサブタスクへ分割させてください

ゲートウェイスクリプトがエラーを表示せずに失敗する

症状： ゲートウェイスクリプトが空の出力または null を返します。

対処方法：

• API キーを確認してください：echo $OPENROUTER_API_KEY | head -c 10
• エンドポイントを直接テストしてください：curl -s https://openrouter.ai/api/v1/models | jq '.data[0].id'
• jq があるか確認してください：which jq — 見つからない場合はインストールしてください（brew install jq または apt install jq）
• 詳細な curl 出力でスクリプトを実行してください：HTTP エラーを確認するため、一時的に curl -s を curl -v に置き換えてください

レビュアーが常に承認する（形式的な承認）

症状： 敵対的レビュアーがすべてを承認してしまい、目的が達成されません。

対処法：

• 敵対的レビュアーがコーダーとは異なるモデルファミリーを使用していることを確認します。同じファミリーによるレビューは承認に傾きがちです。
• 敵対的なプロンプトを強化します：「問題を少なくとも3つ見つけなければなりません。問題がゼロのまま承認した場合、あなたは役割を果たせていません」
• プロバイダーを1つだけ使用する場合（Anthropicのみ）、非常に攻撃的なプロンプトを使って敵対的レビューにSonnetを使用します。これにより、同じファミリーによる偏りをある程度補えます。