はじめに
dev-orchestra という Claude Code / Codex 用のプラグインを作って、1.0.0 を出しました。
1 文で依頼すると、設計 → 実装 → テスト → 複数の AI による独立したレビュー → 指摘の仕分け → 修正 → 再テスト、までを順に回してくれるものです。
この記事では、何ができるかの詳しい説明は次の記事に回して、なぜ作ったのかと、作って使ってみてどうだったかを書きます。
dev-orchestra は GitHub で公開しています（MIT ライセンス）。役に立ちそうと思ったら、スターを付けてもらえるとうれしいです。
作る前：人が運び屋になっていた
AI にコードを書かせるようになってから、気になっていたことがありました。AI は自分が書いたコードのレビューが苦手です。バグを生んだ前提を、レビューするときもそのまま持っているからです。
なので、書かせたコードを別の AI にもレビューさせるようにしていました。やっていたのはこういうことです。
- ターミナル A のエージェントに実装させる
- 差分をコピーして、ターミナル B と C のエージェントにレビューを頼む
- 終わるのを待つ
- 結果をコピーしてターミナル A に戻し、直させる
これが想像以上に面倒でした。
- いつ終わるかが毎回ちがう。数十秒で返ってくることもあれば、何分もかかることもある。そのあいだ待機するしかない
- レビュー役を増やすほど、コピペの往復が増える
- 返ってきた指摘は重複していたり、的外れだったりする。どれを直すかを自分で仕分けてから戻す必要がある
つまり、AI に仕事をさせているはずなのに、自分が AI どうしの運び屋になっていたわけです。
別の AI に見せる意味はあったのか
手間をかけてまで続けていたのは、手応えがあったからです。
数字で確かめたのは、少しあとのことです。dev-orchestra の初期版ができてから、それで回した結果を以前の記事に書きました。自分で書いて自分で動かしていたスクリプト（1418 行）を 3 つの AI にレビューさせ、実在するバグが 11 件見つかりました。うち 3 件は、自分ではまず気づけないものでした。
ただし、これは 1 回だけの結果です。3 つ目のレビュアー（ローカルLLM）は 6 件中 1 件しか当たらず、3 つとも見逃した欠陥もありました。複数の AI に見せれば完璧、というわけではありません。
それでも、「1 つの AI に書かせて終わり」よりは明らかにましでした。問題は効果ではなく、手間のほうだったわけです。
作ったもの：dev-orchestra
そこで、運び屋の仕事をまるごと任せられるようにしました。普段どおりエージェントに話しかけるだけです。
この issue を設定済みのワークフローで実装して
すると dev-orchestra が、依頼に必要な工程だけを選んで順に回します。
| 工程 | やること |
|---|---|
| 設計 | 調べて計画を書く。承認するまで実装には進まない |
| 実装 | 計画からコードとテストを書く |
| レビュー | 2 つ以上の AI が、同じ差分を互いの結果を見ずに読む |
| トリアージ | 重複をまとめ、どの指摘が本物かを仕分ける |
| 修正 | 採用した指摘だけを直し、テストをやり直す |
typo の修正なら編集だけ、仕様の変更なら全部、というように工程は依頼の大きさで変わります。
使ってみてよかったこと
1. トリアージがいい塩梅
いちばん効いたのはここでした。
複数の AI にレビューさせると、指摘は重複するし、的外れなものも混ざります。それを全部「直して」と渡すと、要らない変更が量産されます。
dev-orchestra は、指摘を機械的に重複統合したうえで、オーケストレーター役の AI が採用・却下・重複に仕分けます。修正役に届くのは採用した指摘だけです。この仕分けが、自分でやるのとほぼ同じ感覚の、いい塩梅で進みます。
2. 実装の精度が上がった
測って比べたわけではなく、体感です。設計・実装・レビューを分けて回すようになってから、実装がおおむね狙いどおりに仕上がると感じています。
たとえばテストコードを書かせるだけの依頼でも、レビューと修正の工程を挟んだあとのほうが、出来上がりがよくなっていました。
実働 3 週間で作り直したもの
0.1.0 を出したのが 9/10、1.0.0 が 10/12。期間は 1 か月ほどですが、実際に手を動かしたのは 3 週間ほどです。その間にバージョンを 30 回ほど刻みました。使いながら「ここが困る」を潰していった結果です。印象に残っているものを挙げます。
| 作り直したこと | 理由 |
|---|---|
| モデル名を推測しない | 存在しないモデル名で動いたつもりになるのを防ぐ。設定には系列名と「最新」だけを書く |
| レビューする差分を凍結する | 全員が同じものを見ていないと、指摘を比べられない |
| 2 回目のレビューは修正分だけ | 毎回全部を見せ直すと、時間もトークンも倍になる |
| 小さい変更はレビュアーを減らす | typo に 3 人がかりは無駄 |
| 計画の承認を待つ | 設計がずれたまま実装まで走ると、やり直しが大きい |
| 読み取り専用は CLI で強制する | 「書き換えないで」とお願いするだけでは守られないことがあった |
困ったこと：トークンがすぐ尽きる
作っていていちばん困ったのは、動かすたびにお金（トークン）がかかることでした。
複数の AI を本物の CLI で動かすので、テストのつもりで回しただけでもトークンがみるみる減ります。何度か上限に当たって、作業が止まりました。
そこで、上の表のうち「2 回目は修正分だけ」「小さい変更はレビュアーを減らす」のような、無駄に AI を呼ばないための仕組みを少しずつ入れてきました。
とはいえ、まだ十分とは思っていません。トークンの使い方をもっと効率的にするのが、1.0.0 以降のいちばんの課題です。
この課題への答えとして、トークンの使い方を見て削る方法を連載の 17 本目（2026 年 11 月 23 日公開予定）で書きます。
よければ使ってみてください
Claude Code なら 2 行で入ります。
claude plugin marketplace add istb16/dev-orchestra
claude plugin install dev-orchestra@dev-orchestra
Codex でも動きます。何ができるのか、どんな構成で使えるのかは、紹介の記事にまとめました。
複数の AI を動かすぶん、トークンの消費は 1 つの AI で済ませるより増えます。まずは小さな依頼から試すのがおすすめです。
まとめ
- AI に書かせたコードを別の AI にもレビューさせると、自分では気づけないバグが見つかる
- ただ手作業では、ターミナル間のコピペと待機で自分が運び屋になっていた
- それを任せられるようにしたのが dev-orchestra。1 文の依頼で、設計からレビュー・修正まで回る
- よかったのはトリアージのいい塩梅と、実装（テストだけでも）の精度が上がったと感じたこと（体感）
- 困ったのはトークン消費。効率化が 1.0.0 以降の課題
- 実働 3 週間ほどで 1.0.0。よければ使ってみてください
GitHub: istb16/dev-orchestra（スターを付けてもらえると励みになります）
この連載の記事は、「dev-orchestra」の一覧でまとめて読めます。
この記事は tk3.biz のブログ からの転載です。