本文へスキップ
マルチエージェント・オーケストレーション

コーディングエージェントのためのマルチエージェント・オーケストレーション実践ガイド

Claude Code、Codex、Gemini CLI、Grokをひとつのチームとして動かす方法を解説します。うまくいくパターン、必要な要素、そしてMAOがそれをキャンバス上でどうつなぐかを紹介します。

著者:更新日:約12分で読めます

マルチエージェント・オーケストレーションとは?

マルチエージェント・オーケストレーションとは、複数のAIエージェントをひとつのチームとして動かすための取り組みです。誰が何をするかを決め、エージェント間で作業とコンテキストを受け渡し、結果を集め、どれかが人の判断を必要としたときに介入します。コーディングエージェントの場合は、Claude Code、Codex、Gemini CLI、Grok、OpenCodeがそれぞれ変更の一部を担当し、その引き継ぎを何らかの仕組みが調整する状態を指します。

オーケストレーションがなければ、あなた自身がオーケストレーターです。あるターミナルから計画をコピーして別のターミナルに貼り付け、レビュアーのコメントをコードを書いたエージェントに伝え直し、どのタブが何をしているかを頭の中で把握し続けることになります。エージェントが2つならそれでも回ります。4つになると、1日の大半がウィンドウ間でテキストを移す作業になります。

オーケストレーションは、そのクリップボード作業を明示的な構造に置き換えます。どのエージェントがいるのか、どのエージェント同士がやり取りしてよいのか、それぞれが何を担当するのか、結果がどこへ行くのかを決めておくのです。コーディングをするのは引き続きエージェントです。オーケストレーション層は、チームを見える形にし、エージェント同士が直接やり取りできるようにします。

なぜ複数のコーディングエージェントを使うのか?

多くのタスクは、強力なエージェントが1つあれば十分です。チームが真価を発揮するのは、作業にはっきり異なる役割があるときや、並列で進められるときです。

  • 得意分野の違い。 あるモデルは計画が得意で、別のモデルはテストを書くのが速く、3つ目は慎重なレビュアーです。それぞれを最も得意な場面で使うほうが、1つのモデルにすべてを任せるより、たいていうまくいきます。
  • セカンドオピニオン。 別のプロバイダーのレビュアーエージェントは、作成者エージェントが見落とすミスに気づきます。自分でコードを書いていないからです。
  • 並列作業。 独立したタスク(マイグレーション、そのテスト、ドキュメント)は、3つのエージェントが別々のブランチで同時に進めれば早く終わります。
  • コンテキストの分離。 プロジェクト全体を抱え込む1つの会話ではなく、エージェントごとに焦点を絞ったコンテキストウィンドウを保てます。

代償は連携です。エージェントが1つ増えるたびに、作業が止まったり、衝突したり、失われたりする場所が増えます。まさにそのためにオーケストレーションがあります。

コードでうまくいくマルチエージェントのパターン

役に立つ構成の多くは、いくつかの形のどれかに当てはまります。タスクに合う最もシンプルなものから始めてください。

オーケストレーターとワーカー

1つのエージェントがリクエストを受け取り、タスクに分割して、それぞれをワーカーに渡します。「Codexはエンドポイントを書いて。Geminiはそのテストを書いて」。ワーカーが報告を返し、オーケストレーターが結果をまとめます。複数の部分からなる機能では、これが基本の形です。

作成者とレビュアーのループ

1つのエージェントが書き、別のエージェントがレビューし、作成者がレビュアーの指摘を直します。これをレビュアーが納得するまで繰り返します。2つのプロバイダーのモデルを使うと、レビューの独立性が高まります。

並列ブランチ

複数のエージェントが、リポジトリの別々のコピー上で同時に作業するため、作業中に互いのファイルを編集し合うことはありません。各ブランチをレビューし、良いものをマージします。3つのエージェントを、3倍の衝突ではなく3倍のスループットに変えるのがこのパターンです。

パイプライン

作業は、計画、実装、テスト、ドキュメント化という段階を順に流れます。各段階は1つの役割だけを持つエージェントで、その出力が次の段階の入力になります。

共有ノート

エージェントは、メッセージのたびにコンテキストを繰り返す代わりに、同じノート(仕様、進捗ログ、意思決定の記録)を読み、追記します。ノートがチームの記憶になります。

マルチエージェント構成に必要なもの

どのツールを使う場合でも、コーディングエージェントのチームには同じ要素が必要です。

  1. 本物のセッション。 各エージェントは、自分のログイン、モデル、設定で自分のCLIを実行するため、ターミナルで使うときとまったく同じように動作します。
  2. 宛先の指定。 エージェントは、一緒に作業してよいエージェントを見つけ、そのどれかにタスクを送れます。
  3. 戻ってくる結果。 タスクにはID、送信者、受信者があり、その結果は、ターミナルに打ち込んで届くことを祈るのではなく、依頼した側に返ります。
  4. 権限の境界。 エージェントは、与えられたエージェント、ノート、ツールにしかアクセスできないため、ワーカーが無関係な作業に迷い込むことはありません。
  5. 分離。 並列のエージェントは別々のブランチで作業するため、編集が衝突しません。
  6. 通知。 エージェントが完了したり、失敗したり、承認を求めたりしたとき、すべてのウィンドウを確認しなくても気づけます。
  7. レビュー。 各エージェントが何を変更したかを確認し、何を取り込むかを決められます。

MAOはコーディングエージェントをどうオーケストレーションするか

MAOは、コーディングエージェントのマルチエージェント・オーケストレーションのためのデスクトップアプリです。各エージェントを本物のターミナルとして無限のキャンバスに置き、上で挙げた要素を、目で見て描けるものに変えます。

  • すべてのエージェントは本物のCLIです。 ノードはClaude Code、Codex、Gemini CLI、Grok、OpenCode、Antigravity、または素のシェルを、そのエージェント自身のログインとモデルで実行します。MAOはエージェントをプロキシしたり置き換えたりしません。
  • ワイヤーは権限です。 2つのエージェントの間に接続を描くと、互いを見つけてタスクをやり取りできるようになります。エージェントをノートにワイヤーでつなぐと、そのノートを読み、追記できるようになります。それ以外には何もアクセスできません。
  • エージェントは mao コマンドでやり取りします。 ターミナル内で、エージェントはピアの一覧を表示し、タスクを送り、結果を待ち、接続されたノートを読んだり更新したりできます。
  • オーケストレーターがキャンバスに人員を配置できます。 1つのエージェントをオーケストレーターに指定すると、新しいエージェントを呼び込み、接続し、作業を割り振れるので、目標を伝えるのは一度だけで済みます。
  • レイヤーはGitワークツリーです。 各レイヤーは独自の作業ツリーを持つ本物のブランチなので、並列のエージェントが同じチェックアウトを編集することはありません。キャンバス上で差分をレビューし、準備ができたらレイヤーを取り込みます。
  • 対応が必要なことは向こうから知らせてくれます。 完了した、失敗した、またはあなたを呼び出したエージェントは、そのノードとデスクトップ通知でそれを示します。

レビュアーが必要なワーカーは、自分のターミナルからそのレビュアーに頼むだけです。

mao peers
mao ask reviewer "Review the session refresh changes on this branch"
mao note append progress "Refresh path done; reviewer is on it"

mao ask はタスクを送って回答を待ちます。mao send はすぐにタスクIDを返し、mao wait が後でその結果を受け取ります。結果は依頼したエージェントに送り返され、タスクはアプリを再起動しても失われません。

5分でエージェントのチームを組む

  1. MAOをダウンロード(macOS、Windows、Linux対応)し、リポジトリをワークスペースとして開きます。
  2. エージェントを配置します。 使いたいエージェントごとにノードを追加します(たとえば、計画にClaude Code、実装にCodex、レビューにGemini)。それぞれが、既存のログインで自分のCLIを起動します。
  3. ワイヤーを描きます。 プランナーをビルダーに、ビルダーをレビュアーに接続します。仕様用のノートを追加し、3つすべてにワイヤーでつなぎます。
  4. オーケストレーターを選びます。 プランナーをオーケストレーターに指定すると、作業を割り振り、タスクが大きくなったら手伝いを呼び込めるようになります。
  5. 並列でコードを編集するときは、各エージェントにレイヤーを割り当て、それぞれが自分のブランチで作業できるようにします。
  6. 依頼は一度だけ。 オーケストレーターに、やりたいことを伝えます。エージェントが承認を求めたら対応し、差分をレビューして、良いものを取り込みます。

マルチエージェントフレームワークとオーケストレーションアプリの違い

マルチエージェント・オーケストレーションを検索すると2種類のツールが出てきますが、この2つが解決する問題は別物です。

エージェントフレームワーク(例:LangGraph、CrewAI、AutoGen)MAOのようなオーケストレーションアプリ
オーケストレーションする対象モデルのAPI上に、コードで構築するエージェントすでに使っているコーディングエージェント:Claude Code、Codex、Gemini CLI、Grok
セットアップ方法PythonやTypeScriptを書いて保守するノードを置いてワイヤーを描く。グルーコードは不要
課金とログインAPIキーと従量課金各エージェントが自分のログインとサブスクリプションをそのまま使う
実行場所自分のサービスやスクリプト自分のマシン上、またはSSH経由でサーバー上で動くデスクトップアプリ
向いている用途エージェント製品を提供することコーディングエージェントのチームで実際の開発作業を進めること

AIプロダクトを作っているなら、フレームワークが適したツールです。自分のマシン上のコーディングエージェントに、自分のリポジトリで協力して作業させたいなら、オーケストレーションアプリが適しています。

コーディングエージェントのチームのためのヒント

  • 各エージェントに役割は1つだけ。 「レビュアー:バグとテスト漏れを指摘する。ファイルは編集しない」のようなロールを与えると、エージェントが焦点を保てます。
  • 共有コンテキストは、メッセージではなくノートに置きます。 すべてのエージェントが読める仕様ノートがあれば、認識のずれを防げます。
  • 並列作業を分離します。 2つのエージェントが同じチェックアウトを編集することは、マルチエージェントのセッションがうまくいかなくなる最もよくある原因です。ブランチを分ければ防げます。
  • レビューにはプロバイダーを混ぜます。 別のモデルファミリーのレビュアーは、同じファミリーのレビュアーより多くの問題に気づきます。
  • 小さく始めます。 初日から8つのエージェントでチームを組むより、2つのエージェントと1本のワイヤーのほうが多くを学べます。

よくある質問

マルチエージェント・オーケストレーションとは、複数のAIエージェントがひとつのチームとして働くように調整することです。タスクを割り当て、エージェント間で結果とコンテキストを受け渡し、人が判断すべき場面を知らせます。コーディングでは、あなたがターミナル間でテキストをコピーする代わりに、Claude Code、Codex、Gemini CLIなどのエージェントが互いに作業を引き渡せるようにすることを指します。

はい。MAOでは、それぞれがキャンバス上の独立したターミナルとして動作し、両者をつなぐワイヤーによって、maoコマンドを通じて互いにタスクを送り、結果を返せます。たとえば、Claude Codeが計画し、Codexが実装する、といった使い方ができます。

いいえ。すべてのエージェントは、すでにお持ちのログインとサブスクリプションで自分のCLIを実行します。MAOは、プロンプトを自社のサーバー経由で送ったり、モデルの利用料を請求したりしません。

各エージェントに専用のレイヤーを与えます。MAOのレイヤーは、独自のブランチを持つ本物のGitワークツリーなので、エージェントは別々のチェックアウトで作業し、あなたは良いものをマージできます。

macOS、Windows、Linuxで、Claude Code、Codex、Gemini CLI、Grok、OpenCode、Antigravity、そして任意のシェルコマンドに対応しています。

MAOは買い切りで、ほとんどの国ではUS$20です。アジアと南米の一部の地域では現地の購買力に合わせて安くなります(US$13〜US$18)。カード登録不要の7日間無料トライアルがあります。

ご質問は?Discordで質問するか、hello@miguer.comまでメールでお知らせください。

自分のリポジトリで試す

エージェントをひとつのキャンバスに。

キャンバスの全機能を使える7日間のトライアル。カードは不要です。