dev-orchestra のレビュアーとロールを組み替えてみた Rearranging dev-orchestra's Reviewers and Roles

はじめに

前回は、dev-orchestra のプリセットを比べました。 プリセットは「マシン全体で、どこにお金をかけるか」をまとめて決めるものです。

今回は、その中身を自分で組み替える方法を書きます。

• 役（ロール）ごとに、どの CLI・どのモデルを使うか
• レビュアーを何人、どの観点で並べるか
• リポジトリに合わせた分野の専門役を、config suggest-roles に提案させる

最後に、わざとバグを仕込んだ変更を 9 人のレビュアーに見せて、人数を増やすと何が変わるのかを測ってみました。

この記事の内容は dev-orchestra 1.0.0 で確かめたものです。最新の情報は 設定のドキュメント を見てください。

dev-orchestra は GitHub で公開しています（MIT ライセンス）。役に立ちそうと思ったら、スターを付けてもらえるとうれしいです。

→ github.com/istb16/dev-orchestra

手順

1. 役（ロール）を知る

dev-orchestra には 5 つの役があります。

役	設定の名前	やること
指揮	orchestrator	どの工程が要るかを決め、結果をまとめる
設計	architect	調べて計画を書く（読み取り専用）
実装	implementer	計画からコードとテストを書く
レビュー	reviewers	同じ差分を、互いの結果を見ずに読む（読み取り専用）。何人でも置ける
修正	review_fixer	トリアージで採用した指摘だけを直す

レビュアー以外の 4 つは 1 人ずつ、レビュアーは何人でも並べられます。

2. モデルは「系列名 ＋ latest」で指定する

dev-orchestra の設定には、モデルの名前（日付入りの ID）を書きません。書くのは系列名と「その系列の最新を使う」という指定です。

implementer:
  provider: claude
  model:
    family: opus        # 系列名
    version: latest     # その系列の最新

こうしておくと、新しいモデルが出ても設定を書き換えずにそのまま追従します。 実行するたびに、入っている CLI に「opus の最新はどれか」を確かめてから使うので、存在しないモデル名で動いたつもりになることもありません。確かめられなければ、推測せずに止まります。

使える系列名は dev-orchestra model list で分かります。手元ではこう出ました（抜粋）。

claude: installed
  fable                        family=fable                source=cli-help
  opus                         family=opus                 source=cli-help
  sonnet                       family=sonnet               source=cli-help
codex: installed
  CLI default (recommended coding model) family=recommended-coding   source=cli-default
  GPT-6.1-Sol                  family=gpt-6.1-sol          source=cli-catalog
  GPT-6-Astra                  family=gpt-6-astra          source=cli-catalog

どうしても 1 つのモデルに固定したいときは、version: pinned と ID を書くこともできます。ただし新しいモデルには追従しなくなるので、意図して使います。

3. 役ごとに CLI やモデルを変える

組み替えは、エージェントに頼むのがいちばん簡単です。裏ではこんなコマンドが動きます。

頼み方	動くコマンド
「実装には Claude の opus を使って」	config set implementer.model.family opus
「設計は Codex にやらせて」	config set architect.provider codex（＋ Codex が受け付ける系列名）
「このプロジェクトだけ変えて」	書き込むコマンドに --scope project を付ける

設定はプロジェクト → グローバル → 組み込みの既定値の順に効きます。プリセットの上から、変えたいところだけを上書きする形です。

4. 1 つの役に、安いモデルとセカンドオピニオンを持たせる

model tier（モデルティア）を使うと、1 つの役に別のモデルを予備として持たせられます。

implementer:
  provider: claude
  model:
    family: opus
    version: latest
  model_tiers:
    light:                 # 1 行の修正などは安いモデルで
      model:
        family: sonnet
        version: latest
    second-opinion:        # 別の会社の AI でもう一度
      provider: codex

どのティアを使うかは、オーケストレーターが依頼の難しさを見て選びます（run implementer --tier light）。 存在しないティアを指定するとエラーになり、黙って既定のモデルで走ることはありません。

5. レビュアーの観点を選ぶ

レビュアーには**観点（role）**を持たせます。同じ差分でも、観点によって見るところが変わります。

観点	主に見るところ
general	正しさ、エッジケース、エラー処理など全般
security	認証・認可、インジェクション、秘密情報の扱い
performance	計算量、N+1 クエリ、不要な I/O
test	変更した挙動のテスト、意味のないアサーション
architecture	責務の分け方、結合度、既存の慣習との整合
database	マイグレーションの安全性、ロック、制約、インデックス
frontend	状態の扱い、描画、アクセシビリティ
backend	API の契約、バリデーション、ステータスコード

レビュアーの追加・削除・変更は、こうします（これもエージェントに頼めます）。

dev-orchestra reviewer add --provider codex --role security   # Codex のセキュリティ担当を足す
dev-orchestra reviewer set 2 --provider codex --role general  # 2 番目を差し替える
dev-orchestra reviewer remove performance                     # 外す
dev-orchestra reviewer list                                   # 確かめる

reviewer set <id> --when high-risk で、危ない変更のときだけ動くレビュアーにすることもできます。

6. 分野の専門役を config suggest-roles に提案させる

ここが今回いちばん紹介したかった機能です。

config suggest-roles は、リポジトリのファイル名を見て、database・frontend・backend の専門役が要るかを判断します。モデルは呼ばないので、トークンを使いません。

記事用に、フロントエンド・API・DB のマイグレーションを持つ小さな TODO アプリのリポジトリを作って試しました。

Proposed:
  claude-database  claude / sonnet  role database
    when.paths: migrations/*, */migrations/*, *.sql
    evidence: migrations/: 2 files, e.g. db/migrations/001_create_users.sql, db/migrations/002_create_todos.sql
  claude-frontend  claude / sonnet  role frontend
    when.paths: *.tsx
    evidence: *.tsx: 2 files, e.g. frontend/src/TodoItem.tsx, frontend/src/TodoList.tsx
  claude-backend  claude / sonnet  role backend
    when.paths: api/*, */api/*, routes/*, */routes/*
    evidence: api/: 3 files, e.g. api/db.py, api/routes/todos.py, api/routes/users.py
Each joins only code rounds touching its paths, and every design review round.

**なぜ提案したのか（evidence）**まで出してくれます。

一方、このブログのリポジトリ（Astro）で動かすと、何も提案されませんでした。

Not proposed:
  database: no signal (no migrations/, migrate/, alembic/ or prisma/ directory; fewer than 2 *.sql files; no schema.prisma)
  frontend: no signal (fewer than 2 *.tsx, *.jsx, *.vue or *.svelte files)
  backend: no signal (no api/, server/, backend/, handlers/, routes/ or controllers/ directory holding 2 files outside a frontend)
Nothing to add.

提案しなかった理由も出るので、「なぜ足されないのか」で迷いません。

提案を受け入れるときは --write を付けます。プロジェクトの設定ファイル（.dev-orchestra.yaml）に、こう追加されました。

reviewers_extra:
  - id: claude-database
    provider: claude
    model:
      family: sonnet
      version: latest
    role: database
    when:
      paths:
        - "migrations/*"
        - "*/migrations/*"
        - "*.sql"

ポイントは when.paths です。専門役は、コードのレビューにはそのパスのファイルが変わったときだけ加わります。CSS だけを直したときに database の担当が呼ばれることはないので、ふだんのコードレビューは重くなりません。 ただし、出力の最後の行にあるとおり、設計のレビューには毎回加わります。設計レビューの費用はそのぶん増えます。

	プリセット	suggest-roles
何を決めるか	マシン全体の、費用のかけ方	リポジトリに合わせた専門家の追加
保存先	グローバル設定	プロジェクトの設定
動くタイミング	いつも	コードレビューはそのパスが変わったときだけ。設計レビューは毎回

7. レビュアーを増やすと何が変わるか、測ってみた

最後に、レビュアーの人数で結果がどう変わるかを測りました。

やり方

• 上の TODO アプリに、わざとバグを 6 つ仕込んだ変更を作った（4 ファイル）
• quality プリセット（Claude と Codex の 6 人）に、suggest-roles の専門役 3 人を足した 9 人で、1 回だけレビューした
• レビュアーは互いの結果を見ずに動くので、「1 人だけ」「2 社」などの構成の結果は、9 人の結果を組み合わせて数えた
• 指摘はすべて私がトリアージして、仕込んだバグ（B1〜B6）と、仕込んでいないが本物だった問題（E1〜E6）に分けた

	仕込んだバグ
B1	検索語を f-string で SQL に埋め込む（SQL インジェクション）
B2	削除で持ち主を確かめない（他人の TODO を消せる）
B3	ページ送りの offset に + 1（1 件ずれる）
B4	NOT NULL の列を既定値なしで追加（マイグレーションが失敗する）
B5	タイトルを dangerouslySetInnerHTML で表示（XSS）
B6	削除のテストが、持ち主の確認を検証していない

結果

構成ごとにまとめると、こうなりました。

構成	見つかった問題（全 12）	指摘の数（重複をまとめる前）
Claude fable（general）1 人	10	10
Codex（general）1 人	5	5
2 社（上の 2 人）	10	15
quality の 6 人	12	43
6 人 ＋ 専門役 3 人	12	60

分かったこと

• 分かりやすいバグは、ほぼ全員が見つけた。B1〜B5 は、frontend の専門役（観点がフロントエンド）を除く 8 人全員が見つけた
• 2 人から 6 人に増やすと、見つかる問題が 2 つ増えた（10 → 12）。増えたのは E5 と E6 の 2 つ
• 6 人から 9 人に増やしても、問題は増えず、指摘だけが増えた。6 人で 12 個すべてが見つかり、9 人にすると指摘が 43 件から 60 件になった。dev-orchestra が重複をまとめると、60 件は 51 件になった
• 差が出たのは、仕込んでいない問題のほう。「関数の引数が変わって呼び出し側が壊れる」（E5）は architecture の観点だけ、「検索のテストがない」（E6）は test の観点だけが見つけた
• モデルの差も大きかった。同じ general の観点でも、Claude fable は 1 人で 12 個中 10 個、Codex は 5 個だった。この回では、モデルの違いと観点の違いを切り分けられていない
• Codex の 2 人は、仕込んだバグ 5 つを空振りなしで見つけたが、この回ではほかの人が見つけなかった問題は出さなかった
• 9 人分の費用は、合計で約 11 万トークンだった（差分が 4 ファイルと小さかったため）

これは 1 回だけ、小さなサンプルでの結果です。仕込んだバグは分かりやすいものばかりで、仕込んでいない問題を「本物」とみなしたのも私の判断です。実際の開発の、もっと込み入った変更では、別の会社の AI を混ぜる効果が違って見える可能性があります（以前の記事では、実際のコードで別の傾向が出ています）。

この結果から、自分の使い方としてはこう考えています。

• 人数より、観点の違いを足してみる。この 1 回では、architecture と test が 1 つずつ、ほかの人が見つけなかった問題を出した。ただし general を何人も並べる構成は試していないので、「同じ general を増やすより効く」とまでは言えない
• 専門役は when.paths 付きで足す。コードレビューでは、そのパスが変わったときだけ加わる
• 指摘が増えるほどトリアージの量が増える。dev-orchestra が重複をまとめてくれる（今回は 60 件が 51 件になった）が、人数は「多いほどよい」ではない

まとめ

• 役は 5 つ（指揮・設計・実装・レビュー・修正）。レビュアーだけは何人でも並べられる
• モデルは系列名 ＋ latest で指定する。新しいモデルにそのまま追従し、確かめられない名前では動かない
• model tier で、1 つの役に安いモデルやセカンドオピニオンを持たせられる
• レビュアーには 8 つの観点がある。reviewer add / set / remove で組み替える
• config suggest-roles は、ファイル名から database・frontend・backend の専門役を提案する。トークンは使わない。コードレビューにはそのパスが変わったときだけ、設計レビューには毎回加わる
• 9 人で 1 回だけ測ったら、2 人から 6 人で問題が 2 つ増え、6 人から 9 人では指摘だけが増えた
• この 1 回では、architecture と test が 1 つずつ、ほかの人が見つけなかった問題を出した。同じ general でもモデルによって大きな差があった

次回は、自作のエージェント（ローカル LLM）を dev-orchestra に繋ぐ方法を書きます。

GitHub: istb16/dev-orchestra（スターを付けてもらえると励みになります）

---

English version

Introduction

Last time, I compared dev-orchestra’s presets. A preset decides, all at once, “where to spend money across the whole machine.”

This time, I’ll cover how to rearrange what’s inside it yourself.

• Which CLI and which model to use for each role
• How many reviewers, and with which focuses, to line up
• Having config suggest-roles propose domain specialists that fit the repository

At the end, I showed a change with deliberately planted bugs to 9 reviewers and measured what changes as you add more of them.

Everything in this post was checked with dev-orchestra 1.0.0. For the latest information, see the configuration docs.

dev-orchestra is open source on GitHub (MIT license). If it looks useful, a star would mean a lot.

→ github.com/istb16/dev-orchestra

Steps

1. Get to know the roles

dev-orchestra has five roles.

Role	Config name	What it does
Lead	orchestrator	Decides which stages are needed and summarizes the results
Design	architect	Investigates and writes a plan (read-only)
Implementation	implementer	Writes code and tests from the plan
Review	reviewers	Read the same diff without seeing each other’s results (read-only). You can have any number
Fix	review_fixer	Fixes only the findings accepted in triage

The four roles other than review have one agent each, but you can line up any number of reviewers.

2. Specify models as “family + latest”

In dev-orchestra’s config, you don’t write a model name (a dated ID). You write a family name and “use the latest in that family.”

implementer:
  provider: claude
  model:
    family: opus        # model family
    version: latest     # latest in that family

This way, when a new model comes out, it follows along without any config changes. On every run, it checks with the installed CLI which model is the latest opus before using it, so you never think you’re running on a model name that doesn’t exist. If it can’t confirm, it stops instead of guessing.

dev-orchestra model list shows which family names you can use. Here’s what I got (excerpt).

claude: installed
  fable                        family=fable                source=cli-help
  opus                         family=opus                 source=cli-help
  sonnet                       family=sonnet               source=cli-help
codex: installed
  CLI default (recommended coding model) family=recommended-coding   source=cli-default
  GPT-6.1-Sol                  family=gpt-6.1-sol          source=cli-catalog
  GPT-6-Astra                  family=gpt-6-astra          source=cli-catalog

If you really need to pin a single model, you can write version: pinned with an ID. It will no longer follow new models, though, so only do it on purpose.

3. Change the CLI or model per role

The easiest way to rearrange things is to ask the agent. Behind the scenes, commands like these run.

What you ask	Command that runs
”Use Claude’s opus for implementation”	config set implementer.model.family opus
”Have Codex do the design”	config set architect.provider codex (+ a family name Codex accepts)
“Change it for this project only”	Adds --scope project to the writing command

Settings take effect in the order project → global → built-in defaults. You override only what you want to change on top of the preset.

4. Give one role a cheaper model and a second opinion

With model tiers, you can give one role other models as alternates.

implementer:
  provider: claude
  model:
    family: opus
    version: latest
  model_tiers:
    light:                 # a cheaper model for things like one-line fixes
      model:
        family: sonnet
        version: latest
    second-opinion:        # another pass with a different company's AI
      provider: codex

The orchestrator picks which tier to use based on how hard the request is (run implementer --tier light). Specifying a tier that doesn’t exist is an error; it never silently runs on the default model.

5. Choose reviewer focuses

Each reviewer gets a focus (role). Even on the same diff, the focus changes what it looks at.

Focus	Mainly looks at
general	Correctness, edge cases, error handling, and so on
security	Authentication/authorization, injection, handling of secrets
performance	Complexity, N+1 queries, unnecessary I/O
test	Tests for changed behavior, meaningless assertions
architecture	Separation of responsibilities, coupling, consistency with existing conventions
database	Migration safety, locks, constraints, indexes
frontend	State handling, rendering, accessibility
backend	API contracts, validation, status codes

You add, remove, and change reviewers like this (you can ask the agent for this too).

dev-orchestra reviewer add --provider codex --role security   # add a Codex security reviewer
dev-orchestra reviewer set 2 --provider codex --role general  # replace the 2nd one
dev-orchestra reviewer remove performance                     # remove
dev-orchestra reviewer list                                   # check

With reviewer set <id> --when high-risk, you can also make a reviewer that runs only on risky changes.

6. Have config suggest-roles propose domain specialists

This is the feature I most wanted to introduce this time.

config suggest-roles looks at the repository’s file names and decides whether database, frontend, or backend specialists are needed. It doesn’t call a model, so it uses no tokens.

For this post, I made a small TODO app repository with a frontend, an API, and DB migrations, and tried it.

Proposed:
  claude-database  claude / sonnet  role database
    when.paths: migrations/*, */migrations/*, *.sql
    evidence: migrations/: 2 files, e.g. db/migrations/001_create_users.sql, db/migrations/002_create_todos.sql
  claude-frontend  claude / sonnet  role frontend
    when.paths: *.tsx
    evidence: *.tsx: 2 files, e.g. frontend/src/TodoItem.tsx, frontend/src/TodoList.tsx
  claude-backend  claude / sonnet  role backend
    when.paths: api/*, */api/*, routes/*, */routes/*
    evidence: api/: 3 files, e.g. api/db.py, api/routes/todos.py, api/routes/users.py
Each joins only code rounds touching its paths, and every design review round.

It even shows why it proposed each one (evidence).

On the other hand, running it on this blog’s repository (Astro) proposed nothing.

Not proposed:
  database: no signal (no migrations/, migrate/, alembic/ or prisma/ directory; fewer than 2 *.sql files; no schema.prisma)
  frontend: no signal (fewer than 2 *.tsx, *.jsx, *.vue or *.svelte files)
  backend: no signal (no api/, server/, backend/, handlers/, routes/ or controllers/ directory holding 2 files outside a frontend)
Nothing to add.

It also shows why it didn’t propose anything, so you’re never left wondering why nothing was added.

To accept the proposal, add --write. This was added to the project config file (.dev-orchestra.yaml).

reviewers_extra:
  - id: claude-database
    provider: claude
    model:
      family: sonnet
      version: latest
    role: database
    when:
      paths:
        - "migrations/*"
        - "*/migrations/*"
        - "*.sql"

The key is when.paths. A specialist joins code reviews only when files under those paths change. The database reviewer isn’t called when you only fix CSS, so everyday code reviews don’t get heavier. However, as the last line of the output says, specialists join every design review. Design reviews cost that much more.

	Presets	suggest-roles
What it decides	How to spend money across the whole machine	Adding specialists that fit the repository
Where it’s saved	Global config	Project config
When it applies	Always	Code reviews only when those paths change; design reviews every time

7. Measuring what changes as you add reviewers

Finally, I measured how the results change with the number of reviewers.

Method

• I made a change with 6 deliberately planted bugs (4 files) in the TODO app above
• I reviewed it only once with 9 reviewers: the quality preset (6 reviewers across Claude and Codex) plus the 3 specialists from suggest-roles
• Since reviewers run without seeing each other’s results, I counted results for setups like “1 reviewer only” or “2 companies” by combining the 9 reviewers’ results
• I triaged every finding myself and split them into the planted bugs (B1–B6) and real problems I hadn’t planted (E1–E6)

	Planted bug
B1	Embeds the search term into SQL with an f-string (SQL injection)
B2	Delete doesn’t check the owner (you can delete someone else’s TODO)
B3	+ 1 on the pagination offset (off by one item)
B4	Adds a NOT NULL column with no default (the migration fails)
B5	Renders the title with dangerouslySetInnerHTML (XSS)
B6	The delete test doesn’t verify the owner check

Results

Grouped by setup, it came out like this.

Setup	Problems found (out of 12)	Findings (before merging duplicates)
Claude fable (general) alone	10	10
Codex (general) alone	5	5
2 companies (the 2 above)	10	15
The 6 in quality	12	43
6 + 3 specialists	12	60

What I learned

• Obvious bugs were found by almost everyone. B1–B5 were found by all 8 reviewers except the frontend specialist (whose focus is the frontend)
• Going from 2 to 6 reviewers found 2 more problems (10 → 12). The 2 added were E5 and E6
• Going from 6 to 9 added no problems, only findings. The 6 found all 12, and with 9 the findings went from 43 to 60. After dev-orchestra merged duplicates, the 60 became 51
• The difference showed up in the unplanted problems. “A function’s arguments changed and broke its callers” (E5) was found only by the architecture focus, and “no tests for search” (E6) only by the test focus
• The model difference was also large. With the same general focus, Claude fable alone found 10 of the 12, while Codex found 5. In this run, I couldn’t separate the effect of the model from the effect of the focus
• The 2 Codex reviewers found 5 of the planted bugs with no false positives, but in this run they didn’t raise any problem that the others missed
• The cost for all 9 was about 110,000 tokens in total (because the diff was small, just 4 files)

This is the result of a single run on a small sample. The planted bugs were all obvious ones, and treating the unplanted problems as “real” was my own judgment. On more complex changes in real development, the effect of mixing in a different company’s AI may look different (an earlier post (in Japanese) showed a different tendency on real code).

From these results, here’s how I’m thinking about my own usage.

• Rather than more reviewers, try adding different focuses. In this one run, architecture and test each raised one problem nobody else found. However, I didn’t try a setup with several general reviewers, so I can’t go as far as saying “it works better than adding more general reviewers”
• Add specialists with when.paths. In code reviews, they join only when those paths change
• More findings mean more triage. dev-orchestra merges duplicates (this time, 60 became 51), but with reviewers it’s not “the more the better”

Summary

• There are 5 roles (lead, design, implementation, review, fix). Only reviewers can be lined up in any number
• Specify models as family + latest. It follows new models as they come out and won’t run on a name it can’t confirm
• With model tiers, you can give one role a cheaper model or a second opinion
• Reviewers have 8 focuses. Rearrange them with reviewer add / set / remove
• config suggest-roles proposes database, frontend, and backend specialists from file names. It uses no tokens. Specialists join code reviews only when those paths change, and every design review
• Measured once with 9 reviewers: going from 2 to 6 found 2 more problems, and going from 6 to 9 only added findings
• In this one run, architecture and test each raised one problem nobody else found. Even with the same general focus, results differed a lot by model

Next time, I’ll write about how to connect your own agent (a local LLM) to dev-orchestra.

GitHub: istb16/dev-orchestra (a star is always appreciated)