# Multi Agent Orchestration

> マルチエージェント協調の設計と実行を支援する。複数エージェント/サブエージェントを束ねたい・並列で調査や実装を分担させたい・orchestrator-worker や supervisor 構成を組みたい・既存のマルチエージェント構成をレビューしたい時に使う。「マルチエージェントを組みたい」「サブエージェントで並列処理して」「エージェント協調を設計/実行して」等で発火。単一エージェントのループ設計は harness-design に委ねる。

- Skill: `ntaksh42/multi-agent-orchestration` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add ntaksh42/multi-agent-orchestration`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ntaksh42/multi-agent-orchestration/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: ntaksh42 (https://skillmd.com/u/ntaksh42)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/ntaksh42/multi-agent-orchestration

---


# Multi-Agent Orchestration — マルチエージェント協調の設計・実行

複数エージェントを協調させる構成を **設計（アドバイス）** し、必要なら Claude Code の
`Agent` / `Workflow` ツールで **実際に実行** する。一次情報源は Anthropic マルチエージェント
研究システム・Building Effective Agents・Cognition「Don't Build Multi-Agents」・
context engineering 記事に基づく。

## フェーズ判定

依頼から、必要なフェーズを判定する（通常 1→2→3 の順。実行不要なら 2 で止める）。

- **フェーズ1 判断ゲート**: 常に最初に通す。マルチエージェントが本当に要るか。
- **フェーズ2 設計**: 必要と判断したら topology と協調を設計する。
- **フェーズ3 実行**: この環境で実際に動かす依頼なら Agent/Workflow で組む。

## フェーズ1: 判断ゲート（過剰設計を防ぐ門）

**まずここで止めて評価する。** マルチエージェントは単一エージェントの **約15倍トークン**を
消費し、性能分散の80%をトークン量が説明する（Anthropic）。Cognition は
「Don't Build Multi-Agents」で、並列サブエージェントは暗黙の前提が衝突して成果が壊れるとし、
**単一スレッド線形エージェント + コンテキスト圧縮**を推奨する。

マルチエージェントが正当化されるのは次が揃うとき（Anthropic）:

- **breadth-first / 並列探索**: 独立した方向を同時に探れる（依存が低い）
- **単一コンテキストを超える**規模
- **高価値**でコスト（15倍）を正当化できる

**いずれも満たさないなら、単一エージェント設計を推奨し `harness-design` に委ねて終了する。**
「分割できるが相互依存が高い」タスクは特に危険（inter-agent misalignment の主因）。

## フェーズ2: 設計（topology と協調）

必要と判断したら、対象に合う topology を **1つ** 推奨する。詳細な選択基準・協調機構・
失敗モードは `references/patterns.md` を参照（必要時に読む）。

出力形式:

```
## マルチエージェント設計: <対象>
判断ゲート: <なぜマルチが正当か。15倍コストを上回る理由を1-2行>

### 1. topology
推奨: <orchestrator-worker / supervisor / parallel-sectioning / handoff-network / hierarchical> — 理由

### 2. 協調機構
- コンテキスト共有: <フルトレース共有 vs agent-as-tool で要約だけ返す> — 理由
- 委譲: <各サブエージェントへ渡す 目的/出力形式/ツール/境界>
- 結果の圧縮: <親に返すのは 1-2k トークンの凝縮サマリ>

### 3. 失敗モード対策
- inter-agent misalignment（暗黙の前提衝突）への対策
- 停止条件・スケーリング規則（簡単=1体、複雑=10体以上）

### 最小構成での第一歩
<まず単一 orchestrator + 2-3 worker から。動いてから増やす>
```

## フェーズ3: 実行（Claude Code で動かす）

この環境で実際に協調を走らせる。`Agent`（LLM主導の動的サブエージェント）と
`Workflow`（コードで決定的にオーケストレーション）を使い分ける。具体的な記法・レシピ・
ガードレールは `references/claude-code-recipes.md` を参照。

判断の骨子:

- **動的に分解する必要がある / 探索的** → `Agent` ツールでサブエージェントを spawn
- **構造が決まっている（fan-out → verify → synthesize 等）** → `Workflow` でpipeline/parallel
- **並列でファイルを書く** → worktree 隔離（衝突回避）
- **書き込み範囲を制限したい** → `permissions.deny` か PreToolUse フックでガード
  （単純なパス禁止は deny、条件分岐が要るならフック）

> 注: `Workflow` はトークン消費が大きく、明示的オプトインが要る。本スキルが指示する形で
> 起動する場合も、規模（spawn数・トークン）をユーザーに伝えてから実行する。

## 重要な設計原則（常に効かせる）

- **最も単純に機能するものを採用**: 単一で足りるなら単一。マルチは最後の手段。
- **コンテキストを共有せよ**: 個別メッセージでなくフルのエージェントトレース（Cognition）。
- **行動は暗黙の決定を含む**: 並列ワーカーの前提が衝突すると統合不能になる。
- **委譲は明示的に教える**: 曖昧な指示は重複作業を生む（Anthropic の初期失敗）。
- **サブエージェントはクリーンな文脈で作業し、凝縮サマリだけ返す**（context engineering）。

詳細な一次情報源は各 references ファイル末尾を参照。