はじめに

「マルチエージェント開発」や「エージェントチーム」という言葉を最近よく聞くようになりました。きっかけは、Claude Code × tmux を組み合わせた記事をたくさん見かけたことです。「tmux でペインを分割して複数の Claude を同時に走らせる」という使い方に興味を持ち調べてみました。

複数のAIエージェントが協調して開発を進める

との事、そのアイデアは魅力的ですね。ですが、実際にどうやるのか、また単一のエージェントを使用してのバイブコーディングと何がどう違うのか、いまいちよく分かっていませんでした。

ので実際にマルチエージェント体験してみました。

お題は2つ。

• TODO管理 REST API（Hono/Node.js）の実装
• 技術調査レポート の自動生成

それぞれをパラレル型とオーケストラ型の2パターンで実施しました。

なおClaude Code × tmuxを調べている中で amux というツールを知りました。後ほど詳細は説明しますが、Claude Codeを利用したマルチエージェント開発を簡単に実行できるツールで、今回こちらを使用しました。

amux とは

amux は「AIエージェントのコントロールプレーン」を謳うOSSツールです。

ブラウザやスマホから、複数のClaudeエージェントセッションを並列実行・管理するためのダッシュボードシステム、で簡単にいうとマルチエージェント開発を手軽に実行できるツールとなります。

アーキテクチャ

特徴的なのはシンプルさです。Python サーバー + HTML/CSS/JS が1ファイル（ amux-server.py ）に収まっており、Githubからクローンしてインストールして数コマンド実行するのみで利用できます。

1git clone https://github.com/mixpeek/amux && cd amux && ./install.sh
2amux register myproject --dir ~/Dev/myproject --yolo
3amux start myproject
4amux serve # → https://localhost:8822

これだけでダッシュボードが立ち上がります。

amuxの主な機能一覧

amux には多くの機能が搭載されています。

amuxが「やること」と「やらないこと」

今回の実験で使った機能・使わなかった機能

今回の4実験で実際に使ったのは、全機能のうち一部です。

今回使った機能

今回使わなかった機能（リッチ過ぎる。機会があれば試したい）

マルチエージェントのパターン

マルチエージェント開発のパターンは大きく6種類に分類できるようです。

6つのパターン

1. パラレル型（独立並列）

各エージェントが独立してタスクをこなすパターン。amux ではネイティブに対応している模様。

• 各エージェントがボードから「取得→実行→完了」を自律的に繰り返す
• 複数のエージェントが同じタスクに被らないよう保護する仕組みが必要でamux ではこれが組み込まれているみたいです。素敵
• 「退勤前にタスクを積んで、翌朝出社したら全部終わってる」に最適のようです

2. オーケストラ型（階層委譲）

コーディネータがサブエージェントに指示を出すパターンです。依存関係のある複雑な仕事に向いています。

1[コーディネータ]
2↓ 指示を送信
3[サブA] [サブB] [サブC]

3. パイプライン型（直列連鎖）

前工程の出力が次工程の入力になるパターンです。

1エージェントA（設計）→ エージェントB（実装）→ エージェントC（テスト）→ エージェントD（レビュー）

各ステージのスコープが明確なため、コスト管理がしやすいようです。

4. ピアツーピア型（メッシュ）

中央コーディネータなしでエージェント同士が直接通信・協議するパターンです。柔軟性は高いですが、プロンプト設計が複雑になるそうです。と、思ってたのと違う、ってなりそう。

5. 批評/ディベート型

1エージェントA: 案を出す
2エージェントB: 批判・改善案を出す ← ループ
3エージェントA: 修正する

品質向上・ハルシネーション低減が目的のようです。ループ回数次第でコストが膨らみそうですね。

6. スペシャリスト型

役割分担（フロントエンド専門・テスト専門・レビュー専門など）を固定し、タスクの種類によって担当を振り分けるパターンです。役割に応じてモデルを変えれば（例: 単純タスク → Haiku、設計 → Opus）、コスト最適化効果が最も大きいパターンのようです。

パターン別コスト傾向

amuxの各パターン対応状況

実運用ではパターンの組み合わせになることが多いみたい？

• オーケストラ × スペシャリスト（最もよくある構成）
• パラレル × 批評（複数案を出して批評エージェントが選ぶ）

開発内容やモデルの性能などによって採用すべきパターンを柔軟に選択して行くんでしょうね、と予想。

実験設計

今回はパラレル型とオーケストラ型の2パターンを、以下の2つのお題に適用して比較しました。

実験ごとに別ディレクトリを用意し、トークン使用量も個別に計測しました。

実験① TODO API × パラレル型

セットアップ

4つのエージェントをそれぞれ登録・起動し、カンバンボードに4タスクを積みました。

1Agent A: プロジェクト初期化（package.json, db.js, index.js）
2Agent B: GET /todos, GET /todos/:id
3Agent C: POST /todos
4Agent D: PATCH /todos/:id, DELETE /todos/:id

あとは「担当タスクを実装して、完了したらボードを done にしてください」と一斉送信するだけです。

結果：1分48秒、ただし…

4エージェントが一斉に動き出す様子はなかなか壮観でした。ダッシュボードでリアルタイムに各エージェントの動きが見えます。

ファイルはちゃんと揃いました。

1todo-api-parallel/
2├── package.json ← Agent A
3├── db.js ← Agent A
4├── index.js ← Agent A
5└── routes/
6├── todos.get.js ← Agent B
7├── todos.post.js ← Agent C
8└── todos.patch-delete.js ← Agent D

しかし動かしてみると…

1curl http://localhost:3000/todos
2# → 404 Not Found

うーん、404。。。なぜ動かない？

原因は明快でした。index.js を見てみると：

1app.get("/", (c) => c.text("Hello"));
2// routes/ 以下のルートは一切マウントされていない

Agent A が index.js を書いた時点では、まだ routes/ ディレクトリが存在していません。「B/C/D が何というファイル名で何を作るか」が分からないので、つまり app.route() を書きようがなかったみたいですね。
結果 Agent A は「とりあえず動くサーバー」だけを作り、B/C/D が後から作ったルートファイルは宙に浮いたまま接続されなかったようです。

さらに細かい問題もありました。GET/PATCH/DELETE の routes は相対パス（/、/:id）で書かれているのに、POST の routes だけフルパス（/todos）で書かれていました。エージェント間で「どこにマウントされる前提か」の合意がなかったためです。

各エージェントは正しいコードを書きました。が、繋ぎ方の設計がなかったのですね。

これがパラレル型の典型的な落とし穴のようです。

実験② TODO API × オーケストラ型

セットアップ

今度は4セッションのうち1つをコーディネータとして起動し、コーディネータにだけ指示を送りました。

1「Hono + SQLite で TODO API を構築してください。
2サブエージェント3体（sub-a/b/c）を指揮してください」

たったこれだけです。あとはコーディネータが自律的に動きます。

結果：7分8秒、完全動作

コーディネータはまず SPEC.md を書き始めました。

1# TODO API 仕様書
2
3## エンドポイント一覧
4
5| Method | Path | 説明 |
6...
7
8## ファイル構成
9
10## index.js のルートマウント方法
11
12import { getTodosRouter } from './routes/getTodos.js'
13app.route('/', getTodosRouter)

指示していないのに、自分から設計書を作ったのです。優秀。

そしてこの SPEC.md を「読んでから実装してください」という指示とともにサブエージェントに送りました。

1curl http://localhost:3000/todos
2# → [{"id":1,"title":"...","completed":false,...}] ✅

全エンドポイントが完全動作しました。

小さな発見

一点だけ逸脱がありました。指示では done というフィールド名を指定していましたが、コーディネータの SPEC.md には completed と書かれていました。サブ全員が SPEC.md に従ったため 統一はされています。コーディネータが独自判断で仕様を変えた形です。

これはオーケストラ型の特性をよく表しているみたいで、コーディネータは単なる指示伝達者ではなく、設計者として機能します。

しかしプロンプト指示は汲み取って欲しいよなぁ、とも思いました。

コーディネータがスタックした話

実は途中でコーディネータが詰まりました。サブの完了を until ループで待っていたのですが、タイミングがズレてループが空回りしてしまいました。

1until [ "$(curl -sk .../api/sessions/sub-a | python3 -c "...")" = "idle" ]; do
2sleep 10
3done
4# ← ここで無限に待ち続けた

人間が「sub-a は完了しています、次に進んでください」と介入して解決しました。

これもオーケストラ型の課題の一つのようです。コーディネータが「プッシュ型（サブが完了したら通知）」ではなく「ポーリング型（コーディネータが繰り返し確認）」で設計すると詰まりやすいみたいです。

実験①②の比較

コストはほぼ同じなのに、結果は天と地の差です。

パラレル型は速いです。ただし動きません。オーケストラ型はコーディネータが設計書（SPEC.md）を書く時間がかかりますが、その設計投資が統合問題を丸ごと解決しました。

実験③ 技術調査レポート × パラレル型

セットアップ

amux 自身のリポジトリを調査対象として、4エージェントで分担して調査・執筆しました。

1Agent A: 概要・アーキテクチャ
2Agent B: 主要機能・APIリファレンス
3Agent C: セットアップ・デプロイ
4Agent D: 注意点・他ツールとの比較

結果：2分47秒、4ファイル完成

4ファイルがしっかり生成されました。

1A_overview.md : # セクションA: プロジェクト概要・アーキテクチャ
2B_features.md : # セクションB: 主要機能・APIリファレンス
3C_setup.md : # セクションC: セットアップ・デプロイ方法
4D_notes.md : # セクションD: 注意点・制限事項・他ツールとの比較

ただし、AIに各ファイルを要約させたところ内容の重複が発生してて編集が必要とのことでした。

「コンテンツの質自体は高いです。*ただしそのまま1本のレポートにするには、重複の削除・つなぎ文の追加・構成の整理という編集作業が必要です。」（by AI）

うーん、プロンプトの内容である程度は回避できるですかね？

実験④ 技術調査レポート × オーケストラ型

セットアップ

コーディネータ1体のみに指示を送りました。前回のスタック経験を踏まえ「sleep/until ループ禁止」を明示しました。

結果：11分36秒、1068行の完成品

コーディネータがまず作ったのは STRUCTURE.md でした。

1# レポート構成設計書
2
3## 目次（全セクション）
4
51. はじめに
62. amux の概要
73. アーキテクチャ
8...
94. まとめ
10
11## セクション間境界の定義（重複防止マトリクス）
12
13| トピック | section_a | section_b | section_c |
14| ---------------- | --------- | ---------- | ---------- |
15| セルフヒーリング | 詳細記述 | 言及しない | 比較のみ |
16| インストール手順 | 詳細記述 | 言及しない | 言及しない |

またまた設計。優秀。しかしここまで細かく設計するとは思っていませんでした。「重複防止マトリクス」でトピックごとの担当を明示することで、エージェント間の暗黙の前提が排除されました。

最終的に生成された report.md は 1068行・約53KB の完成ドキュメントです。目次・アンカーリンク・セクション間の相互参照付きで、そのまま公開できちゃうんじゃ？なレベルの品質でした。

コストが4倍になった理由

実験③と比べてコストが約4倍（$1.19 → $4.74）になりました。

output tokens を見ると：

コーディネータが STRUCTURE.md の作成・サブへの指示送信・3ファイルの統合・品質確認という全工程をこなすため、output tokens が突出して多くなった模様。

実験③④の比較

全体考察

4実験の最終まとめ

補足：コストの計算方法

各実験のコストは以下の計算式で算出しています。

1コスト = (input_tokens ÷ 1,000,000 × $3.00)
2+ (output_tokens ÷ 1,000,000 × $15.00)
3+ (cache_read_tokens ÷ 1,000,000 × $0.30)

単価は Claude Sonnet 4.6 の API 価格（2026年4月時点）です。最新の単価は Anthropicの公式価格ページで確認できます。

トークン数は Claude Code が ~/.claude/projects/  以下に保存する JSONL 実行ログから取得しました。各行に input_tokens・output_tokens・cache_read_input_tokens が記録されており、実験ごとに集計しています。

パターン選択の指針

実験を通じて見えてきた判断基準です。

パラレル型が向くケース

• タスク間に依存関係がない
• 統合フェーズに人間が介入できる
• とにかく速さが優先
• 事前に SPEC.md（設計書）を用意できる → 統合問題をほぼ解消できる（はず）

オーケストラ型が向くケース

• 成果物に一貫性・統一感が必要
• 人間の介入なしに完成品を出したい
• タスク間に依存関係がある
• コスト・時間より品質を優先したい

最大の発見

パラレル型の問題の9割は「設計書（SPEC.md）がないこと」で説明できる

実験①では各エージェントが正しいコードを書いたのに全体が動きませんでした。原因は技術的な失敗ではなく「統合の前提が共有されていなかった」ことです。

裏を返せば、事前に SPEC.md を用意してパラレル型で動かせば、オーケストラ型に近い品質をより低コスト・短時間で達成できる可能性があります。

オーケストラ型の本質的な価値は「コーディネータが勝手に SPEC.md を書いてくれること」だと気づきました。

amux が光る場面

amux のカンバンボードは、エージェントの意思決定の足跡を可視化してくれます。

実験②では、人間がタスクを登録したのではなく、コーディネータが自律的にボードにタスクを作成しました。ダッシュボードを見ると「AIが何を考えて動いたか」がリアルタイムで追えました。ただ思ってたよりは面白くなかったです（ペルソナ設定したら面白くなるのかも？）。

おわりに

「マルチエージェントは難しそう」と思っていましたが、amux を使えばセットアップのハードルはかなり低いです。コマンド数本でダッシュボードが立ち上がり、API 経由でエージェントに指示を送れます。

今回の実験で一番印象に残ったのは、コーディネータが指示されていないのに自分で SPEC.md や STRUCTURE.md を書いたことです。人間が「設計書を作れ」と言ったわけではありません。コーディネータは「品質を出すには設計が必要だ」と自律的に判断してそれをやりました。

指示通りに動くだけでなく文脈を読んで最善手を選ぶ、これがエージェントチーム開発の面白さなんだなと思いました。

次はパラレル型に事前 SPEC.md を組み合わせた実験、アドバイザーパターン（Sonnet メイン + 設計判断時のみ Opus）の組み合わせ、エージェンティックテストを試してみたいと思いました。
本当は試したかったですが、マルチエージェントでもうお腹いっぱいです、ごちそうさまでした。