MCO - 複数の AI coding CLI に同じ repository を相互 review させる
AI coding CLI は増え続けています。Team の中で Claude Code、Codex、Gemini CLI、OpenCode を同時に使うこともあります。Task によって model や tool を使い分けることもあります。しかし、これらの tool が repository を読み、file を変更し、command を実行できるなら、workflow はすぐに「最初に patch を出した tool が勝つ」形になりがちです。
個人の実験ならそれでもよいかもしれません。Team の code では少し危ういです。今日紹介する mco-org/mco は、単一の AI CLI を唯一の実行者にするのではなく、複数の CLI を local orchestration flow に入れ、run、review、比較、まとめを分担させる tool です。
公開時点の GitHub page では、およそ 366 stars、31 forks。主な言語は Python、license は MIT です。Repository の最初の commit は 2026-02-26、最新 commit は 2026-05-23。最新 Git tag は v0.9.1 で、GitHub Releases page で表示される latest release は v0.8.0、2026-03-17 公開です。README の先頭では、new work は successor project の Hive に移ったと説明されており、MCO は利用可能な early implementation として残されています。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| Repository | mco-org/mco |
| 位置づけ | Local multi AI coding CLI orchestrator |
| Stars | 約 366 |
| Forks | 31 |
| 主な言語 | Python |
| License | MIT |
| Latest tag | v0.9.1 |
もう一つの agent ではなく、agent の coordinator
MCO の面白さは、Claude、Codex、Gemini、OpenCode を置き換えようとしていない点です。むしろ、すでに存在する CLI を provider として扱い、それらを同じ task flow の中で走らせます。
これは現実的な問題に向いています。単一の agent は、自分の context の中で筋の通った説明を作れます。Test も通せるかもしれません。しかし、別の model、別の prompt structure、別の tool habit から自分の patch を疑うとは限りません。
MCO は run と review の役割を分けます。ある agent が patch を作り、別の agent が diff、log、constraints を見て risk を指摘する。この構造は、agent が自問自答するより、人間の team における author と reviewer に近いです。
Cloud console ではなく local-first
README から読み取れる設計方針は local-first です。MCO は local machine 上で動き、すでに install され、authorization された CLI を呼び出します。Repository を新しい SaaS dashboard に upload する前提ではありません。すべての provider を一つの closed platform に包み込むわけでもありません。
これには実務上の利点があります。
一つ目は、permission boundary が分かりやすいことです。Claude Code、Codex、Gemini CLI がもともとどのように login し、repository を読み、command を実行するのか。その設定を大きく変えずに、MCO が orchestration layer として上に乗ります。
二つ目は、migration cost が低いことです。Team が一度に一つの vendor を選び切る必要はありません。ある task は Claude に任せ、別の task は Codex に review させ、Gemini や OpenCode を比較に入れることもできます。MCO が扱うのは workflow であり、provider の能力を再実装することではありません。
三つ目は、experiment しやすいことです。小さな repository で「patch generation + cross review」を一度走らせ、provider ごとの output の違いを観察してから、より正式な process に入れるか判断できます。
Prompt 一発から review workflow へ
多くの agent tool の入り口は prompt です。「この bug を直して」と書くと、tool は file を読み、code を変更し、test を走らせ、summary を返します。この mode は便利ですが、一回の conversation に責任が集中しすぎます。
MCO の考え方は workflow に近いです。Task description、provider、reviewer、output directory、failure handling、log retention を同じ flow の中に置けます。目的は agent を魔法のようにすることではなく、AI による変更を review 可能な artifact に近づけることです。
Team にとって重要なのは、賢そうな output よりも traceability です。AI が生成した patch に問題があったとき、本当に確認したいのは次のような情報です。
- どの provider が生成したのか。
- Reviewer は存在したのか。
- Reviewer は何を疑ったのか。
- どの test が実行されたのか。
- どの command が失敗したのか。
- 最後に人間の review に渡った file は何か。
MCO のような orchestrator は、agent output を chat log から engineering artifact へ近づけます。
Code review にも、案の比較にも使える
MCO の分かりやすい用途は code review です。一つの CLI に修正を生成させ、別の CLI には diff と constraints だけを見せ、test gap、edge case、error handling、security risk を見るように依頼する。これにより、同じ model が自分の変更を正当化してしまう問題を減らせます。
二つ目の用途は design comparison です。少し複雑な requirement に対して、複数の provider に別々の implementation を提案させ、その違いを reviewer にまとめさせる。人間は agent の output を盲目的に選ぶのではなく、complexity、risk、test cost の違いを見ることができます。
三つ目は regression check です。人間がすでに作った patch に対して、一つまたは複数の CLI で review を走らせる。正式な code review の代替ではありませんが、人間の review 前に目立つ問題を拾う layer にはなります。
これらの用途に共通するのは、output をそのまま merge しないことです。MCO は full automation の merge bot というより、review と comparison の材料を作る tool と見るほうが安全です。
Provider-neutral であることが重要
Orchestrator が一つの model や一つの vendor に強く結びつくと、長期的な価値は狭くなります。MCO は provider-neutral な考え方を取っています。CLI provider が実行でき、結果を返し、run/review flow に参加できることを重視します。
2026 年の AI coding tool では、これはかなり重要です。Model と CLI は更新が速く、code understanding、long context、test repair、frontend detail、command execution habit で得意不得意が変わります。Team が唯一の勝者を事前に選び切るのは難しいです。
Provider-neutral な orchestration layer があると、「tool selection」と「workflow design」を分けられます。Workflow は固定できます。先に生成し、次に review し、最後にまとめ、人間が判断する。Underlying provider は model capability や team preference に応じて変えられます。
注意点: MCO は移行期に入っている
MCO は境界のない新しい toy ではありません。README の先頭では、新しい方向は Hive に移ったと明記されています。つまり、長期的に採用するなら、MCO だけではなく Hive も見るべきです。
ただし、MCO に価値がないという意味ではありません。むしろ、軽量な実装例として有用です。Multi-CLI orchestration、run/review separation、provider neutrality、local agent workflow といった考え方が、実際の code でどう表現されるかを見られます。
試すなら、次の点に注意したいです。
- Agent output を main branch に直接 merge しない。
- 小さな repository や低リスク task から始める。
- 各 provider の permission と executable command を明確にする。
- Reviewer output を補助的な review として扱い、最終判断にはしない。
- Production 化を考えるなら successor Hive の protocol、license、activity も確認する。
まとめ
mco-org/mco が面白いのは、新しい AI coding agent を発明しているからではありません。複数の既存 agent CLI を、run、review、comparison、summary、human decision という engineering workflow に近い構造へ置いているからです。
AI CLI が増えるほど、問題は「どの model が一番強いか」だけではなくなります。「複数の tool の output を、どうやって audit 可能で、比較可能で、rollback しやすい development process に変えるか」が重要になります。MCO はその方向を見せる、小さくても代表的な project です。