AIに複数レビューさせるのが面倒すぎて、自動で回すプラグインを作ってみた AIに複数レビューさせるのが面倒すぎて、自動で回すプラグインを作ってみた

はじめに

dev-orchestra という Claude Code / Codex 用のプラグインを作って、1.0.0 を出しました。

1 文で依頼すると、設計 → 実装 → テスト → 複数の AI による独立したレビュー → 指摘の仕分け → 修正 → 再テスト、までを順に回してくれるものです。

• GitHub: istb16/dev-orchestra（MIT）

この記事では、何ができるかの詳しい説明は次の記事に回して、なぜ作ったのかと、作って使ってみてどうだったかを書きます。

作る前：人が運び屋になっていた

AI にコードを書かせるようになってから、気になっていたことがありました。 AI は自分が書いたコードのレビューが苦手です。バグを生んだ前提を、レビューするときもそのまま持っているからです。

なので、書かせたコードを別の AI にもレビューさせるようにしていました。 やっていたのはこういうことです。

1. ターミナル A のエージェントに実装させる
2. 差分をコピーして、ターミナル B と C のエージェントにレビューを頼む
3. 終わるのを待つ
4. 結果をコピーしてターミナル 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 以降のいちばんの課題です。

よければ使ってみてください

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。よければ使ってみてください