実際に使える 5 つのマルチエージェントパターン

マルチエージェント開発ワークフローを何か月も作り、使ってきた結果、いくつかのパターンが繰り返し有効だと分かりました。これは理論ではありません。私たちが日常的に使い、他の開発者も継続的に採用しているパターンです。

ここでは、実際に機能する 5 つを紹介します。

1. コードレビューのパイプライン

構成: 2 つのターミナルタイルを一方向に接続する。

Writer Agent → Reviewer Agent

動き: Writer エージェントが機能や修正を実装します。完了すると、その出力が Reviewer エージェントに送られ、「src/auth/ の変更を、正確性・セキュリティ・エッジケースの観点からレビューして」のようなプロンプトになります。

なぜ機能するか: AI エージェントは、与えられたプロンプトの文脈に応じて、見るポイントが変わります。Writer は正確さと完了に最適化され、Reviewer は明示されたレビュー基準を持つことで、Writer の視野の狭さでは見逃す問題を見つけられます。

コツ: on-idle トリガーと 8 秒の静寂ウィンドウを使います。これで Writer が本当に終わってからレビューを始められます。LGTM のような停止キーワードを設定し、Reviewer が承認したらループを終えます。

典型的な流れ: 1 回の実装 + 1〜2 回のレビュー。焦点の絞られた変更なら、たいてい 10 分以内に収束します。

2. テスト生成器

構成: 実装エージェント 1 つ、テスト作成エージェント 1 つ。

Implementation Agent → Test Agent

動き: 実装エージェントが機能を構築または変更します。完了すると、ルーティングシステムがファイル変更とプロンプトをテストエージェントに送ります。「認証ミドルウェアの変更に対する単体テストを書いて。正常系、エラーケース、エッジケースをカバーして。」

なぜ機能するか: 実装直後、コードがまだ新鮮なうちにテストを書くと、最も安いタイミングでバグを見つけられます。テストエージェントは、何がどう変わったかの完全な文脈を持っています。

バリエーション: 方向を逆にします。テストを先に書き（TDD 方式）、そのテスト仕様を実装エージェントへ送ります。

3. 並列モジュールビルダー

構成: 複数のターミナルタイル、接続なし。中央に調整用のノートタイル。

Agent A (auth)    Agent B (api)    Agent C (database)
      \               |               /
       \              |              /
        Note: Architecture Plan

動き: 大きなタスクを独立したモジュールに分割します。各エージェントには、明確な境界を持つ特定のモジュールを与えます。ノートタイルには、全員が参照する共有アーキテクチャ計画とインターフェース契約を書きます。

なぜ機能するか: これが最もスループットの高いパターンです。独立したモジュールを 3 つのエージェントが並行で処理すれば、1 つのエージェントが順番に処理するより 3 倍速いです。重要なのは、最初にきれいなインターフェースを定義しておくことです。

避けるべき場面: モジュールの結合が強い、あるいは共有状態がある場合です。そうした場合、エージェント同士が干渉します。真に独立し、インターフェースが明確な作業にだけ使いましょう。

4. 反復改善ループ

構成: 2 つのエージェントを双方向接続し、ラウンド上限を設ける。

Agent A ⇄ Agent B (max 3 rounds)

動き: Agent A が最初の案を出します。Agent B がそれを批評し、改善案を出します。Agent A がそのフィードバックをもとに修正します。これを決めた回数（通常 2〜3 ラウンド）続けます。

なぜ機能するか: ラウンドごとに解が締まっていきます。1 回目は構造を整え、2 回目はバグとエッジケースを拾い、3 回目で仕上げます。3 ラウンドを超えると収穫逓減が始まるので、上限もそれに合わせます。

設定: ai-routing 変換を使い、各エージェントのフィードバックを生の出力ではなく実行可能な指示として再構成します。maxRounds: 3 と cooldownMs: 5000 を設定し、各エージェントが完全な応答を返す時間を確保します。

プロンプト例:

• Round 1 (A→B): "このレートリミッター実装を、正確性と性能の観点からレビューしてください。"
• Round 2 (B→A): "次の修正を適用してください: [具体的な問題]。その後、同時アクセスのエッジケースが正しく処理されるか確認してください。"
• Round 3 (A→B): "修正版レートリミッターの最終レビューです。出荷可能なら LGTM で承認してください。"

5. スカウトとビルダー

構成: 軽量で高速なエージェントがコードベースを偵察し、より高機能なエージェントがビルドする。

Scout Agent → Builder Agent

動き: Scout エージェントは（小さく高速なモデルか、簡単なプロンプトを使って）コードベースを探索し、次のような事前質問に答えます。「支払いフローに関係するファイルはどれか」「このコードベースのエラーハンドリングのパターンは何か」「請求モジュールのテストは何があるか」。

Scout が文脈を集め終わったら、その結果を Builder エージェントに送ります。そこには、コードベース固有の文脈が付いた実装タスクが入ります。

なぜ機能するか: 大きな実装タスクは、既存コードベースの文脈が足りないと失敗しがちです。Scout 段階は安価で（高速モデル、読み取り専用操作）、Builder の作業を正確にする文脈マップを作れます。

コツ: このパターンでは full-output 変換を使います。Scout の出力は、Builder が AI による再整形なしでそのまま消費できる構造化情報（ファイル一覧、パターン説明）だからです。

適切なパターンの選び方

これらのパターンは組み合わせ可能です。実際のワークフローでは、Scout と Builder で文脈を集め、Parallel Module Builder で実装し、Code Review Pipeline で検証する、という流れを同じキャンバス上で回せます。

避けるべきアンチパターン

無限ループ: 2 つのエージェントを双方向接続し、ラウンド上限も停止キーワードも設定しない状態です。どんどん抽象的なメタコメントに陥ります。必ず maxRounds を設定してください。

全部載せ: すべてのエージェントの出力を、すべての他のエージェントへ送ることです。情報過多になります。各接続には明確な目的が必要です。

早すぎるルーター: 2 分で終わるタスクに対して、複雑なルーティングを組むことです。接続の設定コストは、単純で自己完結したタスクには見合いません。

最高のマルチエージェントワークフローは、驚くほど楽に感じられます。エージェントが並列で動き、出力が必要な場所へ流れ、あなたは実行の周囲で戦略的な判断に集中できる状態です。