はじめに
前回は、dev-orchestra の作業単位で、計画を分けて並べて実装しました。
dev-orchestra は、1 文の依頼から設計・実装・テスト・複数の AI によるレビュー・修正までを回す、Claude Code / Codex / Antigravity のプラグインです。
連載では「時間とトークンが増える」と書きましたが、実際に測った数字は出していませんでした。そこで今回は、次の 2 つを測ってみました。
- 依頼 1 件に、どれくらい時間がかかるか
- レビュアーを 1 人・2 人・4 人にすると、指摘の数と、そのうち採用できる数がどう変わるか
先に書いておくと、回数はとても少ないです（通しの依頼が 1 回、レビューは人数ごとに 2 回）。題材も小さな Python のパッケージ 1 つです。傾向をつかむための記録として読んでください。
dev-orchestra は GitHub で公開しています（MIT ライセンス）。役に立ちそうと思ったら、スターを付けてもらえるとうれしいです。
測った条件
| 項目 | 内容 |
|---|---|
| dev-orchestra |
1.2.1、プリセット standard、optimization.level は既定の balanced
|
| 呼び出し元 | Claude Code 2.1.309（モデルは Opus 5.5）。claude -p で依頼し、計画の承認だけ 2 回目の claude -p --resume で渡した |
| 各役のモデル | architect は Claude Fable、implementer と review_fixer は Claude Opus |
| レビュアー |
claude-general（Opus）、codex-general（Codex CLI 0.163.0、gpt-6.1-sol）、claude-security（Sonnet）、claude-test（Sonnet） |
| 題材 | 作業用に作った小さな Python のパッケージ textkit（関数 1 つとテスト 3 件） |
| 環境 | Windows 11、Python 3.14.7。設定は普段とは別のフォルダ（DEV_ORCHESTRA_HOME）に置いた |
依頼はこれです。
textkit に truncate(text, width, suffix="…") を追加して。表示幅で切り詰め、全角文字（East Asian Width が W か F）は幅 2、それ以外は幅 1 と数える。切り詰めたときは suffix を含めて width 以内に収める。README とテストも更新して。
依頼 1 件にかかった時間
依頼を出してから最終報告までは、計画の承認を待っていた時間を除いて 6 分 12 秒でした。
| 区間 | 時間 |
|---|---|
| 依頼 → 計画が出て承認を求められるまで | 2 分 19 秒 |
| 承認 → 最終報告まで | 3 分 53 秒 |
| 合計 | 6 分 12 秒 |
工程ごとの内訳は、dev-orchestra の記録（state.json）に残っていました。各役の実行時間はこうです。
| 工程 | 担当 | 時間 |
|---|---|---|
| 設計 | architect（Fable） | 75 秒 |
| 実装 | implementer（Opus） | 45 秒 |
| レビュー | claude-general（Opus）1 人 | 19 秒 |
| 修正（1 回目） | review_fixer（Opus） | 27 秒 |
| 修正（2 回目） | review_fixer（Opus） | 45 秒 |
5 回の実行を足すと 3 分 31 秒です。残りの約 2 分 40 秒は、呼び出し元の Claude Code（オーケストレーター）が、工程を選ぶ・テストを走らせる・指摘をトリアージする・報告を書く、に使った時間です。
設計のレビューは、変更が小さく高リスクのパスもないので、自動で飛ばされました。
レビュアーは 4 人ではなく 1 人だった
standard のレビュアーは 4 人ですが、この依頼では 1 人に減らされていました。レビューの記録にはこう出ています。
note: low-risk change (4 file(s), 76 line(s)): 1 reviewer instead of the full panel (claude-general). Cross-model disagreement is what a second reviewer buys; raise optimization.level or the low_risk thresholds to keep it.
balanced では、変更が 5 ファイル・150 行以下で高リスクのパスに触れていなければ、レビュアーを 1 人にします（optimization.low_risk_max_files と optimization.low_risk_max_lines）。小さな依頼が軽く済むのはこのためです。逆に、小さな変更でも別ベンダーの目を入れたいなら、optimization.level を上げるか、この 2 つの値を下げます。
修正が 2 回走った理由
レビューの指摘は 2 件で、オーケストレーターは 1 件を採用、1 件を却下しました。却下したのは「結合文字やゼロ幅文字は幅 0 にすべき」という指摘で、依頼の「それ以外は幅 1」と食い違うからです。
採用したのはテストの指摘でしたが、その中にも結合文字のテストを足す提案が混ざっていました。オーケストレーターは「範囲を限定して採用」とメモしましたが、修正役に渡す指示（fix-brief.md）にはレビュアーの提案がそのまま載っていて、1 回目の修正では却下したはずのテストまで足されました。オーケストレーターがそれに気づき、範囲を書いた指示で修正役をもう一度走らせています。
トリアージのメモが修正役への指示に入らないのは、1.2.1 の時点での動きです。部分的に採用するときは、最後の差分を自分でも見ておくのがおすすめです。
トークンと費用
dev-orchestra が呼んだ 5 回分は、tokens show で見られます。
stage meas. input output total billed cost tools tool out
architect 1/1 34 5,890 - 14,703 $0.4737 5 2,368
implementer 1/1 14 4,103 - 27,614 $0.3380 14 10,107
review 1/1 2 1,517 - 7,364 $0.0778 0 0
review_fixer 2/2 26 5,495 - 43,959 $0.5371 14 6,369
ALL 5/5 76 17,005 - 93,640 $1.4265 33 18,844
これとは別に、呼び出し元の Claude Code 自身が 2 回の claude -p で $1.74 と報告しました。合わせて 約 $3.2 です。どちらも CLI が出した API 料金換算の金額で、サブスクリプションで使っているなら、実際に請求される額ではなく利用枠の消費の目安になります。
レビュアーの人数と、指摘数・採用数
次に、レビューだけを取り出して人数を変えました。上の実行で実装が終わった時点の差分（4 ファイル、75 行追加・1 行削除）を、毎回まっさらなリポジトリに当て直し、同じ差分を 1 人・2 人・4 人でレビューさせました。人数ごとに 2 回ずつ、合わせて 6 回です。
dev-orchestra review snapshot
dev-orchestra review run --only claude-general codex-general --json
dev-orchestra review show --json
--only でレビュアーを名指しすると、上の「1 人に減らす」は効きません。人数は次のように組みました。
| 人数 | レビュアー |
|---|---|
| 1 人 | claude-general |
| 2 人 | claude-general、codex-general |
| 4 人 | claude-general、codex-general、claude-security、claude-test |
採用の基準
指摘は、通しの実行のオーケストレーターと同じ基準で仕分けました。
- 採用：依頼と承認した計画の範囲で、本当に足りていないもの。一部だけ範囲内なら、範囲を絞って採用
- 却下：依頼の「それ以外は幅 1」と食い違うもの（結合文字・ゼロ幅文字を幅 0 にする、書記素の途中で切らない、など）や、直す必要のないもの
- 重複：採用した別の指摘と、主な中身が同じもの
dev-orchestra の重複の統合は保守的で、今回の 6 回では自動でまとめられた指摘は 0 件でした。「重複かもしれない」組は出してくれるので、それを見て仕分けています。
結果
| 人数 | 回 | 指摘 | 採用 | 却下 | 重複 | 時間 | トークン |
|---|---|---|---|---|---|---|---|
| 1 人 | 1 | 2 | 1 | 1 | 0 | 25 秒 | 6,992 |
| 1 人 | 2 | 2 | 1 | 1 | 0 | 23 秒 | 6,751 |
| 2 人 | 1 | 4 | 2 | 2 | 0 | 53 秒 | 16,529 |
| 2 人 | 2 | 4 | 1 | 3 | 0 | 48 秒 | 14,837 |
| 4 人 | 1 | 8 | 4 | 3 | 1 | 25 秒 | 27,795 |
| 4 人 | 2 | 9 | 4 | 4 | 1 | 38 秒 | 27,964 |
時間は review run の開始から終了まで、トークンはレビュアーの billed トークンの合計です（Codex の分も含みます）。
わかったこと
指摘の数は、人数にほぼ比例して増えました。 1 人で 2 件、2 人で 4 件、4 人で 8〜9 件です。
採用できる指摘も増えましたが、増えたのはテストの指摘でした。 4 人のときに増えた採用は、ほとんどが claude-test の指摘です。「suffix の幅と width がちょうど等しいとき（truncate("abc", 1) が "…" になる）のテストがない」「既定の suffix … が幅 1 と数えられることを確かめていない」のように、どれも本当に足りないテストでした。一方で、コードの不具合として直すべき指摘は、どの人数でも 0 件でした。
いちばん多かったのは、依頼と食い違う指摘でした。 「結合文字やゼロ幅文字を幅 1 と数えている」という指摘は、6 回すべてで出ました。Claude（claude-general）と Codex（codex-general）が独立に同じことを言い、4 人のときは claude-test も「そのテストがない」という形で同じ点に触れています。一般的には正しい指摘ですが、今回は依頼で「それ以外は幅 1」と決めていたので却下しました。通しの実行でも同じ指摘が出ています。仕様として決めたことでも、レビュアーからは不具合に見えることがあります。
Codex は毎回 1 件だけで、中身はいつもこの「幅の数え方」でした。今回の差分では、別ベンダーを足したことで新しく見つかったものはありませんでした。2 人のときに採用が増えた 1 回（1 回目）は、Claude が出した「docstring と動きが合っていない」という指摘です。
レビューの時間は、いちばん遅いレビュアーで決まります。 レビュアーは並列に走るので、4 人にしても 4 倍にはなりません。2 人のときに 4 人より長かったのは、その回の Codex か Claude のどちらかが 45 秒以上かかったからです。一方、トークンは人数に比例して増えます（1 人で約 7,000、4 人で約 28,000）。
claude-security は 2 回とも指摘 0 件でした。外部の入力や秘密情報を扱わない差分なので、当然の結果です。
この数字の限界
- 題材は 1 つ、依頼も 1 つです。差分は 76 行と小さく、仕様もはっきり決めていました。もっと大きな変更や、仕様があいまいな依頼では、別の結果になると思います
- 回数は人数ごとに 2 回だけです。同じ人数でも、回によって指摘の数や中身は少し変わりました
- 採用・却下は私が決めました。基準は上に書いたとおりですが、人によって分け方は変わります
- 別ベンダーのレビュアー（Codex）が効く場面、つまり Claude が見落とした本物の不具合を Codex が見つける場面は、今回の差分では出てきませんでした。「効かない」とは言えず、「今回は測れなかった」です
デメリットも書いておく
- 時間とトークンが増えます。 今回の依頼は、承認待ちを除いて約 6 分、API 料金換算で約 $3.2 でした。1 つの AI に直接頼んだ場合とは比べていませんが、AI を 5 回呼ぶので、そのぶん時間とトークンはかかります
- レビュアーを増やすと、却下する指摘も増えます。 4 人のときは 8〜9 件のうち 4〜5 件が却下か重複でした。トリアージはオーケストレーターがしますが、最後に確かめるのは自分です
- コードはレビュアーの各ベンダーに送られます。 2 人以上の構成では、差分が Anthropic と OpenAI の両方に送られました。レビュアーは差分のまわりのファイルも読めるので、送られるのは差分だけとは限りません。外に出せないコードの扱いは紹介の記事に書いています
まとめ
- dev-orchestra 1.2.1 で小さな機能追加を 1 件依頼したら、承認待ちを除いて 6 分 12 秒、API 料金換算で約 $3.2 だった
- そのうち各役の実行は 3 分 31 秒。残りはオーケストレーターの判断・テスト・報告
- 小さな変更では、
balancedがレビュアーを 4 人から 1 人に減らす - 同じ差分をレビューさせると、指摘は 1 人で 2 件、2 人で 4 件、4 人で 8〜9 件。採用は 1 件、1〜2 件、4 件
- 人数を増やして増えた採用はテストの指摘で、コードの不具合の指摘はどの人数でも 0 件だった
- いちばん多かったのは、依頼で決めた仕様と食い違う指摘。レビュアーからは不具合に見える
- 回数も題材も少ない計測なので、傾向をつかむための記録として
次回（2026 年 11 月 7 日公開予定）は、1.3.0 で入った、最後に変更全体をもう一度レビューする機能を試します。
GitHub: istb16/dev-orchestra（スターを付けてもらえると励みになります）
この連載の記事は、「dev-orchestra」の一覧でまとめて読めます。
この記事は tk3.biz のブログ からの転載です。