Codex、Claude Code、Gemini CLIなどのコーディングエージェントを複数使う場合、Agentを何体動かすかだけでは運用構成は決まらない。

親Agentが子Agentへ仕事を割り当てる構成もあれば、外部のプログラムが複数の独立Sessionを管理する構成もある。ContextやWorkspaceの共有範囲、Taskの分割方法、並列実行後の統合、Roleごとのモデル配分でも性質が変わる。

2026年10月時点では、個別製品の機能は変化が続いている一方で、マルチエージェント運用を考えるための設計項目はかなり具体化している。

この記事では、AIコーディングにおけるマルチエージェント運用に絞り、現在の研究や実装で繰り返し現れている構成を実務で選択する単位まで分解する。

Agent、Session、Role、Workspaceを分けて考える

この記事では、Agent、Session、Role、Context、Workspace、Stateを次のように区別する。

用語この記事での扱い
Agent判断し、Toolを使いながら作業する主体
SessionAgentがContextを保持して実行される単位
RolePlanner、Coder、Reviewerなど、その実行で担当する責務
ContextAgentが判断材料として参照できる情報
WorkspaceAgentが実際に読み書きするファイル領域
Stateタスクの進行状況や実行履歴など、継続運用のために保持する状態

同じモデルを使っていても、独立したSessionを3つ起動すれば、それぞれ別Contextで動かせる。1つの親Sessionからsubagentを起動し、親子でContextやWorkspaceを共有する構成もある。

Planner、Coder、Reviewerは、1つのAgentがRoleを切り替えて順番に担当する構成と、Roleごとに別Agentを割り当てる構成のどちらも取れる。

1 Agent / 1 Session

Planning
  ↓
Coding
  ↓
Review
3 Agents / 3 Sessions

Planner Session
      ↓
Coder Session
      ↓
Reviewer Session

マルチエージェント運用で分けたい設計要素

複数Agentを運用するときは、少なくとも次の要素を個別に決められる。

設計要素主な選択肢
ControlCentralized / Hierarchical / Decentralized
ControllerAgentic / Deterministic
ExecutionSequential / Parallel
Task decompositionFeature / Task / File / Responsibility
SessionShared / Separate
ContextShared / Partial / Isolated
WorkspaceShared / Isolated
StateSession内 / External
CommunicationParent-child / Peer-to-peer / Shared state / Artifact-mediated
RoleGeneral / Specialized
Model allocationFixed / Role-based / Dynamic routing
VerificationTest・CI / LLM Judge / Specialized Verifier

これらは独立して組み合わせられる。

たとえば、中央制御でSessionは分離、Contextも分離、WorkspaceはGit worktreeで分け、状態だけGitHub Issueに保存する構成がある。1つの親Agentが同じSession内で複数の子Agentを起動し、同じWorkspaceを触らせる構成もある。

2025年にACM Transactions on Software Engineering and Methodologyで公開されたレビューでは、Software EngineeringにおけるLLM Multi-Agent Systemの研究71件が整理されている。対象はコード生成だけでなく、要件、テスト、保守、end-to-end開発まで広がっている。

https://doi.org/10.1145/3712003

doi.org

代表的な構成パターン

Supervisor / Worker

親Agentがタスクを読み、必要な作業へ分解し、子Agentへ割り当てる。

               ┌─ Worker A
Supervisor ────├─ Worker B
               └─ Worker C

調査範囲や作業量が実行前に決まらないタスクでは、Supervisorが実行中にWorkerを追加したり、タスクを再分割したりできる。

Supervisor自身もLLMなので、依頼内容を見ながら追加の調査AgentやReviewerを起動できる。タスク分解や完了判定もSupervisorの判断に依存するため、Supervisorの理解がずれると、その前提で複数Workerが動く。

Deterministic Orchestrator / Worker

通常のプログラムがタスク状態とAgent Sessionを管理する。

Issue / Queue
     ↓
Orchestrator
  ├─ Worker A
  ├─ Worker B
  └─ Worker C

Issue、Queue、ラベル、DBなどに状態を保存し、特定条件を満たしたタスクだけAgentへ渡す。retry、timeout、同時実行数、監査ログもOrchestrator側で一元管理できる。

タスク内容に応じた判断だけLLMへ委譲し、状態遷移や再実行条件はコードで固定する構成も取れる。

Pipeline

Roleごとに工程を分け、前工程の成果物を次へ渡す。

Planner
   ↓
Coder
   ↓
Reviewer

工程ごとにPrompt、Model、Tool、権限を分けられる。Plannerは設計書だけを作り、CoderだけがWorkspaceを書き換え、Reviewerは読み取り専用にする、といった分離もできる。

Reviewer / Rework loop

実装とレビューを別Agentに分け、指摘がある場合は実装側へ戻す。

Coder
  ↓
Reviewer
  ├─ pass -> next stage
  └─ finding -> Coder

Reviewerを実装Agentとは別Contextで動かせば、実装時の前提をそのまま引き継がずに確認できる。review findingを外部Stateへ残せば、Sessionを再起動しても同じ指摘を引き継げる。

Fan-out / Fan-in

同じ問題に対して複数Agentを動かし、複数の候補や調査結果を作った後に統合する。

            ┌─ Agent A ─┐
Task ───────├─ Agent B ─┼─ Judge / Verifier / Integration
            └─ Agent C ─┘

複数の実装候補を比較する場合や、独立した観点から調査する場合に使える。

Fan-outの後は、どの結果を採用するか、複数結果を統合するか、統合後に何を再検証するかをFan-in側で決める。

Parallel workers

独立したタスクを別Agentへ割り当て、並列に進める。

Task A -> Agent A -> branch A
Task B -> Agent B -> branch B
Task C -> Agent C -> branch C

別モジュールの修正、独立したIssue、実装とドキュメント作成など、依存関係が少ない仕事は並列化できる。

Workspaceまで分離すると実行中の競合は減るが、最後の統合工程は別に必要になる。

タスク特性から構成を選ぶ

タスクの性質合わせやすい構成
実行中に仕事を分解したいSupervisor / Worker
多数のIssueを継続処理したいDeterministic Orchestrator
Planning、Coding、Reviewを明確に分けたいPipeline
実装と独立レビューを反復したいReviewer / Rework loop
複数案を比較したいFan-out / Fan-in
独立タスクを高速に処理したいParallel workers
Contextを意図的に分離したいSeparate Session + Artifact
長時間運用したいExternal State + Isolated Session

実際の構成では、これらを組み合わせる。

External Orchestrator
        ↓
      Issue
        ↓
    Supervisor
    ├─ Worker A
    └─ Worker B
        ↓
     Reviewer
        ↓
        PR

外部OrchestratorがIssueを選び、各Issueの中ではSupervisorが複数subagentを使い、最後に独立Reviewerへ渡す、といった構成も成立する。

ControlはCentralized、Hierarchical、Decentralizedに分ける

Centralized

中央に1つのControllerを置き、そこから各Agentへ仕事を割り当てる。

          ┌─ Agent A
          │
Controller├─ Agent B
          │
          └─ Agent C

retry、timeout、優先順位、依存関係、同時実行数などを中央で管理できる。複数Agentによる同じ仕事の重複実行も制御しやすい。

中央Controllerが停止すると全体が止まるため、Controllerの可用性がシステム全体へ影響する。

Hierarchical

Controller自体を階層化する。

                 Manager
               /         \
        Sub Manager A   Sub Manager B
          /     \           /    \
       Agent   Agent      Agent  Agent

Project、Feature、Task、Implementationのように、階層ごとにタスクを分割できる。

Project
  ↓
Feature
  ↓
Task
  ↓
Implementation

上位Agentに広い目的を渡し、下位Agentほど具体的な作業を担当させられる。上位の判断が誤ると、その判断を前提に下位Agentが動くため、階層が深いほど途中の判断と引き継ぎ情報も増える。

Decentralized

中央Controllerを置かず、Agent同士が直接連携する。

Agent A ←→ Agent B
   ↕          ↕
Agent C ←→ Agent D

探索や相互レビューでは、中央Controllerを経由せずAgent同士で協調できる。コード編集を伴う実装では、最終決定者、ファイルOwnership、競合した判断の統合方法まで決める必要がある。

CentralizedでもControllerの実装で性質が変わる

Agentic Controller

親Agent自身がタスクを読み、分解し、子Agentを起動する。

             ┌─ Child Agent A
Parent Agent ├─ Child Agent B
             └─ Child Agent C

タスク内容に応じて、その場で分解方法や担当を変えられる。仕事の割り当てや完了判定にもLLMの判断が入る。

Deterministic Controller

通常のプログラムがAgentを起動し、状態遷移を管理する。

GitHub Issue / Queue
        ↓
   Orchestrator
   ├─ Session A
   ├─ Session B
   └─ Session C
ready
  ↓
running
  ↓
validation
  ├─ fail -> retry
  ├─ ambiguous -> needs-human
  └─ pass -> review

実行条件、retry回数、timeout、同時実行数、状態遷移をコードで管理できる。タスクの意味を読んで工程自体を組み替える処理は、必要な箇所だけAgentへ委譲する。

Task decompositionは並列化より先に決める

複数Agentを並列に動かせるかは、タスクの切り方と依存関係で決まる。

Feature
├─ Task A -> Agent A
├─ Task B -> Agent B
└─ Task C -> Agent C

A、B、Cが独立していれば、そのまま並列に処理できる。

依存関係がある場合は実行順序が必要になる。

A ─────→ C
 \
  └────→ B ─────→ D

この場合、CはAの完了を待ち、DはBの完了を待つ。

タスクを分ける単位としては、Feature、Issue、Module、File、Responsibilityなどがある。ファイル単位で分ければ競合は減りやすいが、実装上の責務と一致しない場合もある。

実務では次の3点を明示する。

  • Granularity: どの大きさでタスクを切るか
  • Dependency: どのタスクが何を待つか
  • Ownership: どのAgentがどの成果物を変更してよいか

独立性が高いタスクはParallel worker、依存関係が密なタスクはPipelineやSequentialな実行に向く。

SequentialとParallelを分ける

Sequential

Agent A
  ↓
Agent B
  ↓
Agent C

前工程の成果物を次のAgentが受け取る。調査、実装、レビューを別Agentに分ける場合は、前工程の完了後に次のAgentを起動する。

Parallel

          ┌─ Agent A ─┐
Task ─────├─ Agent B ─┼─ Integration
          └─ Agent C ─┘

独立して処理できる仕事は並列化できる。別々のモジュールの修正、実装とドキュメントの作成、複数候補の生成などがある。

ファイル編集を並列化する場合は、タスク分割とWorkspace分離が重要になる。同じworking treeで複数Agentが同じファイルを編集すると、ファイル競合の管理が必要になる。

ParallelではFan-inとIntegrationまで設計する

Agent A -> worktree A -> branch A ─┐
Agent B -> worktree B -> branch B ─┼-> Integration -> Validation -> PR
Agent C -> worktree C -> branch C ─┘

Integrationでは次の点を確認する。

  • 複数Agentが同じAPIを別の前提で変更していないか
  • 依存関係が矛盾していないか
  • 個別テストでは通っても統合後に壊れないか
  • 競合時にどのAgentへ修正を戻すか
  • Integration自体をAgentに任せるか、Orchestratorで固定するか

Fan-outして作業を分けるほど、Fan-in側の責務も増える。

複数候補から1つを選ぶ場合も、JudgeやVerifierで候補を選んだ後に、選ばれた成果物を通常のCIやIntegration testへ通す。

Session、Context、Workspaceは別々に決める

Session

Agentの実行単位。

同じ親Session内でsubagentを起動する構成もあれば、完全に独立したAgent processを複数起動する構成もある。

Context

Agentが判断材料として参照できる情報。

Sessionが別でも、Issue、設計書、前工程のsummaryなどを渡せば一部Contextを共有できる。

Session A ─┐
Session B ─┼─ Shared Issue / Spec / Artifact
Session C ─┘

同じSession内のsubagentでも、実装によっては子Agentへ渡すContextを絞れる。

Workspace

Agentが実際に変更するファイル群。

Session A -> worktree A
Session B -> worktree B
Session C -> worktree C

Workspaceを分ければ、並列実行中の変更を分離できる。

Sessionを分けても同じworking treeを触らせることはできるため、Session分離とWorkspace分離は同じ意味ではない。

SessionContextWorkspace特徴
SharedSharedShared引き継ぎが簡単で、小さいタスク向け
SeparatePartialSharedAgentは独立するがファイル競合に注意
SeparatePartialIsolated実行中の変更と障害を分離できる
SeparateIsolatedIsolated独立評価や複数候補生成に向く

長時間運用では状態をSessionの外へ出す

複数Sessionを継続的に起動する場合、タスク状態をSessionの外へ保存する。

Issue / Task DB
     ↓
Orchestrator
     ↓
Agent Session
     ↓
PR / Test Result / Artifact
     ↓
Issue / Task DB

GitHub Issue、Jira、データベース、Queueなど実装先は変えられる。

次に何を実行するかは、Sessionの会話履歴だけに依存させず、外部Stateから判断できるようにする。

Failure、Retry、Recoveryも外部Stateで管理する

Agent start
   ↓
timeout
   ↓
retry
   ↓
failed
   ↓
stronger model
   ↓
needs-human

失敗には、exit code以外の状態もある。

  • Agent processが途中で終了した
  • Agentは終了したが成果物が作られていない
  • 同じTaskが二重に実行された
  • 親Agentが終了して子Agentだけ残った
  • timeout後に古いAgentが結果を返してきた
  • Workspaceだけ残り、実行状態が失われた
  • reviewerのfindingに対するreworkが途中で止まった

TaskとRunを分けると、同じTaskに対する複数回の実行をRun IDで区別できる。

Task
  id
  status
  owner

Run
  run_id
  attempt
  agent
  started_at
  timeout
  result

retry回数、timeout、backoff、強いモデルへのescalation、人間へのescalationも外部Stateで管理できる。

Communication patternを分ける

Parent-child

親Agentを経由して情報を渡す。

Worker A -> Parent -> Worker B

Supervisor型で使われる。情報は親へ集約されるため、親のContextも大きくなる。

Peer-to-peer

Agent同士が直接やり取りする。

Agent A <-> Agent B

中央を経由せず協調できるが、通信経路と責任分界が増える。

Shared state / Blackboard

Agentが共通のStateを読み書きする。

Agent A ─┐
Agent B ─┼-> Shared State
Agent C ─┘

Issue、DB、Queue、共有メモリなどを通して状態を共有する。各Agentが互いのSessionを直接知らなくても連携できる。

Artifact-mediated

明示的な成果物を次のAgentへ渡す。

Agent A
  ↓
plan.md / Issue comment / commit / test result
  ↓
Agent B

Agent Bは、Agent Aの会話履歴全体ではなく、必要なArtifactを参照できる。

前工程で何を調べ、何を決め、何が未解決なのかをArtifactとして残せば、Sessionを独立させたまま引き継げる。

RoleごとにAgentとモデルを割り当てる

複数Roleは1つのAgentにも、Roleごとの別Sessionにも割り当てられる。

Planning
  ↓
Coding
  ↓
Review

RoleごとにAgentを分ける場合は、Prompt、Tool、権限、Model、Contextも個別に設定できる。

reviewerを実装Agentとは別Contextで動かせば、実装時の前提をそのまま引き継がずに確認できる。

モデル配分は大きく3パターンに分けられる。

同じモデルを固定する

Supervisor -> Frontier Model
Worker     -> Frontier Model
Reviewer   -> Frontier Model

構成が単純で、モデル選択のroutingが不要になる。安価なモデルでretryを繰り返すより、高性能モデルを最初から使った方が総コストを抑えられるケースもあるため、token単価だけでは比較できない。

model cost
+ retry
+ test / CI
+ reviewer
+ human intervention

Roleごとにモデルを固定する

Supervisor     -> Strong Model
Coder          -> Mid-tier Model
Searcher       -> Fast / Cheap Model
Reviewer       -> Strong Model
Verifier       -> Specialized / Cheap Model

Repository検索や定型的な分類を安価なモデルへ寄せ、設計判断や最終レビューに高性能モデルを割り当てられる。

Dynamic Routing

タスクの難易度や途中状態を見て、実行するモデルを変える。

Task
  ↓
Router
  ├─ easy   -> Cheap Model
  ├─ normal -> Mid-tier Model
  └─ hard   -> Strong Model

2026年6月のAgent-as-a-Routerでは、coding taskを対象に、Orchestrator、Verifier、Memoryを使って実行結果を蓄積しながらモデルroutingを改善するACRouterが提案されている。

Agent-as-a-Router: Agentic Model Routing for Coding Tasks

Real-world users typically have access to multiple Large Language Models (LLMs) from different providers, and these LLMs often excel at distinct domains, yet none dominate all. Consequently, routing each task to the most suitable model becomes critical for both performance and cost. Existing routers treat this as a static, one-off classification problem. However, we identify the performance bottleneck for these routers as information deficit: simply augmenting a vanilla LLM router with performance statistics at the task-dimension level yields a 15.3% relative gain, surpassing a heuristic router built on the same dimension-level priors. Motivated by this finding, we propose Agent-as-a-Router, a framework that formalizes routing as a C-A-F loop (Context->Action->Feedback->Context). It closes the information gap by accumulating execution-grounded experience during deployment. We instantiate this framework as ACRouter, composed of an Orchestrator, a Verifier, a Memory module, and introduce CodeRouterBench, an evaluation environment comprising ~10K task instances with verified scores from 8 frontier LLMs, enabling regret-based router comparison on streaming tasks. Experiments show that ACRouter achieves the lowest cumulative regret on in-distribution tasks and generalizes to out-of-distribution agentic-programming tasks, demonstrating that our routing framework actively closes the information gap. Codes and benchmarks are released at https://github.com/LanceZPF/agent-as-a-router.

https://arxiv.org/abs/2606.22902

arXiv.org · arxiv.org

9月にはmulti-stepなAgent workflowの各stepで異なるモデルtierへ振り分けるAgentRouterも提案されている。planning、coding、formattingなど、同じtrajectory内でも必要なモデル能力が異なることを前提にしている。

AgentRouter: Heterogeneous Model Routing for Cost-Optimal Multi-Step Agentic Workflows

Enterprise agentic systems that route every trajectory step to a frontier model waste 60-80% of their inference budget on subtasks that smaller models handle equally well. Existing routing solutions optimize single-turn query assignment but ignore a property unique to agentic workflows: subtask complexity varies widely within a single trajectory. A planning step may require frontier-class reasoning while a subsequent formatting step needs only a 7B model. We formalize step-level model routing as a sequential assignment problem over agent trajectories and propose AgentRouter, a lightweight classifier (12M parameters, <5ms overhead per step on an A100 GPU) that maps each trajectory step to one of four model tiers using five features extractable at routing time. Trained on 50,000 annotated agent trajectory steps spanning planning, coding, research, and data analysis tasks, AgentRouter achieves 72% cost reduction relative to frontier-only baselines, retaining 97.3% of frontier-only quality (less than 3% degradation in end-to-end task completion); per-step routing accuracy reaches 91% on minimal-complexity steps and 85% on efficient-tier steps, with 76-82% on the harder mid-range and frontier tiers. On the same benchmarks, RouteLLM and FrugalGPT (applied per-step) achieve only 31% and 44% cost reduction respectively, because their single-turn training signal misses trajectory-level quality dependencies.

https://arxiv.org/abs/2609.22951

arXiv.org · arxiv.org

マルチエージェント構成では、Supervisor、Coder、ReviewerなどAgentやRoleの境界がそのままモデル切り替え点になる。

Fan-out / Fan-inではVerifierやScorerを使える

複数Agentが候補を生成する構成では、生成Agentとは別にJudge、Critic、Verifier、Scorerを置ける。

Agent A -> Patch A ─┐
Agent B -> Patch B ─┼-> Verifier -> Candidate
Agent C -> Patch C ─┘

Scorerは数値だけを返す構成にもできる。

Agent output
    ↓
  Scorer
    ↓
0.92

Scorerの値は、次の処理を決めるrouting signalとして利用できる。

score >= 0.9
  -> next stage

0.6 <= score < 0.9
  -> strong reviewer

score < 0.6
  -> retry / rework

この閾値はroutingの例であり、一般的な基準ではない。Verifierごとにscoreの意味や分布が異なるため、実際の閾値は対象タスクでの評価結果を見て決める必要がある。

2026年10月9日に公開されたSWE-Critixは、coding agentのtaskとexecution trajectoryを入力し、completion labelと判断理由を返すVerifierを学習している。論文では、base modelの分類精度57%から、SFT後66%、RL後78%まで改善したと報告している。

SWE-Critix: Post-Training Generalist Verifiers for Assessing Coding-Agent Trajectories

Coding agents are increasingly deployed for end-to-end software engineering tasks, where a readily available oracle evaluator that defines the success criteria is often absent. This motivates verifications for coding agents that can reliably judge and explain their behavior. However, verification is non-trivial as coding agents are increasingly capable of solving long-horizon software engineering tasks. Their execution trajectories can be extremely long, containing hundreds of iterative interactions with code repositories and external tools. Existing verifiers either rely on general-purpose LLMs without specialized training or train dedicated critics that predominantly focus on producing scalar rewards, highlighting the relatively limited exploration of training-based generalist verification. We introduce SWE-Critix, a post-training pipeline for training generalist verifiers of coding-agent trajectories. Given a task and its execution trajectory, the learned verifier predicts the completion label and generates a natural-language analysis that explains its judgment. Our pipeline combines supervised fine-tuning (SFT) with reinforcement learning (RL) and trains a series of 30B models on trajectories from CodeForge-Preview. On a held-out test set, SWE-Critix improves classification accuracy from 57% for the base Qwen3-30B-A3B reasoning model to 66% after SFT and 78% after RL. We release our models, datasets, and training code to facilitate further research.

https://arxiv.org/abs/2610.13356

arXiv.org · arxiv.org

Verifierで候補を絞った後も、採用した成果物はtest、lint、typecheck、buildなどの決定的な検証へ通す。

Candidate
   ↓
Test / Lint / Typecheck / Build
   ↓
Review Agent
   ↓
PR / Human Review

曖昧な結果、繰り返し失敗、高リスクな変更は、上位モデルや人間へescalationする条件として外部Stateに持たせられる。

自作Orchestratorを当てはめるとこうなる

自分が現在使っている自作Agentオーケストレーターをこの分類に当てはめると、概ね次のようになる。

GitHub Issue
  ↓
Label / Task State
  ↓
Deterministic Orchestrator
  ↓
Independent Agent Session
  ↓
Validation / Review
  ↓
Pull Request

設計軸として書くと次の通り。

Control:       Centralized
Controller:    Deterministic
Session:       Separate
State:         External
Communication: Artifact-mediated
Human:         Review / Escalation

IssueをJiraや独自DBに変えても、CodexをClaude CodeやGemini CLIに変えても、Control、Session、State、Workspaceといった設計上の論点は残る。

マルチエージェント運用で最後に決める項目

複数のコーディングエージェントを運用する場合、Agent数だけで構成は決まらない。

  • 誰がタスクを分割して割り当てるか
  • どの単位でTaskを分け、依存関係とOwnershipをどう持つか
  • Agent Sessionをどこで分けるか
  • Contextをどこまで共有するか
  • Workspaceを共有するか分離するか
  • 状態をどこに保存するか
  • 並列化した成果物を誰が統合するか
  • Failure、Retry、Recoveryをどこで管理するか
  • Agent間を直接会話させるか、StateやArtifactで連携するか
  • AgentやRoleごとにどのモデルを使うか
  • VerifierやScorerをどこに置くか
  • どの条件でretry、上位モデル、人間へescalationするか
  • 何をもってタスク完了とするか

これらの組み合わせが、実際のマルチエージェント運用構成になる。