Claude Code に dev-orchestra を入れて、1文で開発を回してみた I installed dev-orchestra in Claude Code and ran development from a single sentence

はじめに

前回は、dev-orchestra で何ができるかを紹介しました。 今回は実際に、Claude Code だけの環境に入れて使ってみます。

• 読むのに 5 分、試すのに 10 分くらいを目安にしています
• Codex は入っていない前提です（Codex で使う話は次回）

必要なもの

もの	メモ
Claude Code	ログインまで済ませておく
Python 3.11 以上	標準ライブラリだけで動く
git	レビューする差分を取るのに使う

API キーは要りません。Claude Code のログインをそのまま使います。

手順

1. インストールする

ターミナルで 2 行です。

claude plugin marketplace add istb16/dev-orchestra
claude plugin install dev-orchestra@dev-orchestra

Claude Code の中からなら、次のように入力しても同じです。

/plugin marketplace add istb16/dev-orchestra
/plugin install dev-orchestra@dev-orchestra

入れたあとに新しく開いたセッションから使えるようになります。

2. 初回にプリセットを選ぶ

dev-orchestra を使う依頼を初めて出すと、まだ設定が無いことに気づいて、今の構成を見せたうえでプリセットを聞いてきます。

プリセットは「どこにお金（トークン）をかけるか」の選択で、3 つあります。

プリセット	ひとことで
quality	強いモデルを多めに使う。品質優先
standard	迷ったらこれ。品質と費用のバランス型
fast	軽いモデル中心。速さと費用優先

プリセットの中身はこの連載の後半でくわしく書くので、ここでは standard で進めます。

初回の設定では、返事をする言語も聞かれます。日本語を選ぶと、Claude Code のユーザー設定に「日本語で返す」ためのフックが入ります。

3. Claude だけで組まれていることを確かめる

ここがいちばん見てほしいところです。 Codex が入っていないマシンで standard を選ぶと、構成はこうなりました（dev-orchestra 1.0.0 の config show の抜粋）。

Preset: standard (implicit; fitted to claude)
  note: codex not found on PATH: reviewer seat 2 (general) went to claude as claude-general-2 (sonnet)

  Architect
    claude / fable / latest
  Implementer
    claude / opus / latest
  Reviews
    1. claude / opus / latest / general / claude-general
    2. claude / sonnet / latest / general / claude-general-2
    3. claude / sonnet / latest / security / claude-security (opus when high-risk)
    4. claude / sonnet / latest / test / claude-test

本来 Codex に置かれるはずのレビュアーの枠が、自動で Claude（sonnet）に置き換わっています。 入っていない CLI を前提にした設定で、毎回レビューが失敗する、ということが起きません。

• 設計は fable、実装は opus と、役割ごとにモデルが分かれている
• レビュアーは 4 人。全員 Claude だが、実装したときの会話を持たない別プロセスとして動く
• 4 人の役割も general（全般）・security・test と分かれている

4. 準備ができているか確かめる

念のため、エージェントに「dev-orchestra の doctor を実行して」と頼んで、環境をチェックしてもらいます。Claude Code の部分はこう出ました（抜粋）。

Claude Code (claude)
  Installed: yes
  Model selection: supported
  Models (cli-help): fable, opus, sonnet
  Read-only runs: enforced by --permission-mode plan --disallowed-tools Edit,Write,NotebookEdit --tools Read,Grep,Glob --strict-mcp-config --restricted

Read-only runs: enforced は、設計役とレビュー役が読み取り専用で動くことを、Claude Code のフラグで強制しているという意味です。「書き換えないで」とお願いしているのではなく、そもそも書き換える道具を渡していません。

最後に No problems found. と出れば準備完了です。

5. 1 文で依頼する

あとは普段どおり話しかけるだけです。

この issue を設定済みのワークフローで実装して

この関数のテストを書いて、マルチモデルレビューまで回して

実装役にテストを走らせるには、先に .claude/settings.json の permissions.allow にテストのコマンドを足しておきます（例: Bash(npm test:*)）。足していないと、シェルコマンドは自動では実行されません。

依頼の大きさに合わせて、必要な工程だけが動きます。大きめの依頼だと、こう進みます。

1. 設計: 計画を書いて、「この計画で進めてよいか」を聞いてくる
2. 承認: 計画を読んで OK と答えると、実装に進む（勝手には進まない）
3. 実装 → テスト
4. レビュー: 4 人のレビュアーが、同じ差分を互いに見ずにレビュー
5. トリアージ → 修正 → 再テスト
6. 最終報告

最終報告は、こんな形で返ってきます（例）。

Tests      ✓ 12 passed
Reviews    4/4 ✓
Triage     5 findings → 2 accepted, 2 rejected, 1 duplicate
Models     architect Claude/fable, implementer + fixer Claude/opus
Changed    src/calc.py, tests/test_calc.py
Remaining  none

どの指摘を採用して、どれを却下したかまで報告されるので、気になる指摘があれば理由を聞き返せます。

複数のレビュアーを動かすぶん、トークンは 1 つの AI で済ませるより増えます。最初は小さな依頼から試すのがおすすめです。

Claude Code の場合だけの機能・制限

Claude Code で使うときに知っておくと役に立つ点を、まとめておきます（dev-orchestra 1.0.0 時点。くわしくは providers.md）。

	内容
○ 読み取り専用の強制がいちばん強い	設計とレビューは Read / Grep / Glob の 3 つの道具だけで動き、MCP も使わない
○ モデルは名前で指定	opus / sonnet / fable と書けば、その系列の最新が使われる
○ 設計の続きから再開できる	計画の手直しで、前の設計の会話を引き継げる（確認済みの Claude Code の版で）
△ 設計・レビューでは自分の permissions.deny が効かない	ユーザー・プロジェクト・ローカルの設定（settings.json）をどれも読まないため。設計役とレビュアーはリポジトリ内のどのファイルも読めるので、秘密のファイルを隠すルールは managed settings に移す（下で説明）
△ 実装役はシェルコマンドを自動で実行しない	テストを走らせるには、.claude/settings.json の permissions.allow にテストのコマンド（例: Bash(npm test:*)）を足す
× 古い Claude Code では設計・レビューが動かない	必要なフラグが無い版では、doctor が NOT ENFORCEABLE と出して実行を止める

.env を隠すには managed settings を使う

managed settings は、管理者向けの設定ファイルです。ユーザーやプロジェクトの設定では上書きできず、設計役とレビュアーを動かすときの --restricted でも読み込まれます。

OS	置き場所
macOS	/Library/Application Support/ClaudeCode/managed-settings.json
Linux・WSL	/etc/claude-code/managed-settings.json
Windows	C:\Program Files\ClaudeCode\managed-settings.json（書き込むには管理者権限が要る）

.env などをモデルに読ませないようにするには、こう書きます。

{
  "permissions": {
    "deny": ["Read(./.env)", "Read(./.env.*)", "Read(./secrets/**)"]
  }
}

置き場所は Claude Code の版によって変わることがあります。公式のドキュメントで確かめてください。

まとめ

• Claude Code への導入は 2 行。API キーは要らない
• 初回にプリセットを選ぶだけ。迷ったら standard
• Codex が無くても、レビュアーは自動で Claude だけで組まれる
• 設計とレビューは Claude Code のフラグで読み取り専用を強制
• あとは 1 文で依頼。計画は承認するまで実装に進まない
• テストを走らせるなら、.claude/settings.json でテストのコマンドを許可しておく
• 設計とレビューでは permissions.deny が効かない。.env などを隠すルールは managed settings に移しておく

詳しい使い方は README（日本語） にまとめています。 次回は、Codex で使ってみます。

---

English version

Introduction

Last time, I introduced what dev-orchestra can do. This time, I actually install it in a Claude Code-only environment and use it.

• Expect about 5 minutes to read and about 10 minutes to try it
• This assumes Codex is not installed (using it with Codex is the next post)

What you need

Item	Notes
Claude Code	Already logged in
Python 3.11 or later	Runs on the standard library only
git	Used to get the diff to review

No API key is needed. It uses your existing Claude Code login.

Steps

1. Install it

Two lines in the terminal.

claude plugin marketplace add istb16/dev-orchestra
claude plugin install dev-orchestra@dev-orchestra

From inside Claude Code, typing the following does the same thing.

/plugin marketplace add istb16/dev-orchestra
/plugin install dev-orchestra@dev-orchestra

It becomes available in sessions you open after installing.

2. Pick a preset on first use

The first time you make a request that uses dev-orchestra, it notices there is no configuration yet, shows you the current setup, and asks you to pick a preset.

A preset is a choice of “where to spend money (tokens)”, and there are three.

Preset	In a nutshell
quality	Uses strong models more. Quality first
standard	Pick this if unsure. A balance of quality and cost
fast	Mostly lighter models. Speed and cost first

I will cover what is inside the presets in detail later in this series, so here I go with standard.

The initial setup also asks which language it should reply in. If you choose Japanese, a hook to “reply in Japanese” is added to your Claude Code user settings.

3. Confirm it is built from Claude alone

This is the part I most want you to look at. On a machine without Codex, choosing standard gave me this setup (an excerpt of config show in dev-orchestra 1.0.0).

Preset: standard (implicit; fitted to claude)
  note: codex not found on PATH: reviewer seat 2 (general) went to claude as claude-general-2 (sonnet)

  Architect
    claude / fable / latest
  Implementer
    claude / opus / latest
  Reviews
    1. claude / opus / latest / general / claude-general
    2. claude / sonnet / latest / general / claude-general-2
    3. claude / sonnet / latest / security / claude-security (opus when high-risk)
    4. claude / sonnet / latest / test / claude-test

The reviewer seat that would normally go to Codex was automatically replaced with Claude (sonnet). So you don’t end up with a configuration that assumes a CLI you don’t have, with reviews failing every time.

• Design uses fable and implementation uses opus: the model is split by role
• There are 4 reviewers. All are Claude, but they run as separate processes that don’t have the conversation from implementation
• The 4 reviewers also have different roles: general, security, and test

4. Check that everything is ready

To be safe, I asked the agent “Run dev-orchestra’s doctor” to check the environment. The Claude Code part looked like this (excerpt).

Claude Code (claude)
  Installed: yes
  Model selection: supported
  Models (cli-help): fable, opus, sonnet
  Read-only runs: enforced by --permission-mode plan --disallowed-tools Edit,Write,NotebookEdit --tools Read,Grep,Glob --strict-mcp-config --restricted

Read-only runs: enforced means that the design and review roles are forced to run read-only by Claude Code flags. It is not asking them “please don’t edit”; it simply never gives them tools that can edit.

If it ends with No problems found., you are ready.

5. Make a request in one sentence

From here, you just talk to it as usual.

Implement this issue with the configured workflow

Write tests for this function and run it through the multi-model review

To let the implementer run tests, first add your test command to permissions.allow in .claude/settings.json (e.g. Bash(npm test:*)). Without it, shell commands are not run automatically.

Only the steps needed for the size of the request run. For a larger request, it goes like this.

1. Design: writes a plan and asks “OK to proceed with this plan?”
2. Approval: once you read the plan and say OK, it moves on to implementation (it does not proceed on its own)
3. Implementation → tests
4. Review: 4 reviewers review the same diff without seeing each other’s reviews
5. Triage → fixes → re-test
6. Final report

The final report comes back in a form like this (example).

Tests      ✓ 12 passed
Reviews    4/4 ✓
Triage     5 findings → 2 accepted, 2 rejected, 1 duplicate
Models     architect Claude/fable, implementer + fixer Claude/opus
Changed    src/calc.py, tests/test_calc.py
Remaining  none

It even reports which findings were accepted and which were rejected, so if a finding catches your eye you can ask why.

Because it runs several reviewers, it uses more tokens than doing everything with a single AI. I recommend starting with small requests.

Features and limitations specific to Claude Code

Here are the points worth knowing when using it with Claude Code (as of dev-orchestra 1.0.0; see providers.md for details).

	Details
Plus: The strongest read-only enforcement	Design and review run with only 3 tools (Read / Grep / Glob) and use no MCP
Plus: Models are specified by name	Write opus / sonnet / fable and the latest model in that line is used
Plus: Design can resume where it left off	When revising a plan, it can carry over the previous design conversation (on verified Claude Code versions)
Caveat: Your own permissions.deny does not apply in design and review	Because none of the user, project, or local settings (settings.json) are read. The architect and reviewers can read any file in the repository, so move rules that hide secret files to managed settings (explained below)
Caveat: The implementer does not run shell commands automatically	To run tests, add your test command (e.g. Bash(npm test:*)) to permissions.allow in .claude/settings.json
Not available: Design and review don’t run on old Claude Code	On versions without the required flags, doctor reports NOT ENFORCEABLE and stops the run

Use managed settings to hide .env

Managed settings is a settings file for administrators. User and project settings cannot override it, and it is still loaded under --restricted when the architect and reviewers run.

OS	Location
macOS	/Library/Application Support/ClaudeCode/managed-settings.json
Linux / WSL	/etc/claude-code/managed-settings.json
Windows	C:\Program Files\ClaudeCode\managed-settings.json (writing it requires administrator rights)

To keep the model from reading .env and similar files, write this.

{
  "permissions": {
    "deny": ["Read(./.env)", "Read(./.env.*)", "Read(./secrets/**)"]
  }
}

The location can change between Claude Code versions. Check the official documentation.

Summary

• Installing into Claude Code takes 2 lines. No API key needed
• On first use, just pick a preset. If unsure, standard
• Even without Codex, the reviewers are automatically built from Claude alone
• Design and review are forced read-only by Claude Code flags
• Then just make a request in one sentence. The plan does not move to implementation until you approve it
• If you want tests to run, allow your test command in .claude/settings.json
• permissions.deny does not apply in design and review. Move rules that hide .env and similar files to managed settings

Detailed usage is in the README. Next time, I will try it with Codex.