Claude Code が書いた計画を、書いた本人でなく、会話に居なかったサブエージェント 2 体に読ませ、指摘 1 件ずつに裁きを付ける

この記事でやること

Claude Code に計画を書かせたあと、同じ会話で「この計画をレビューして」と頼むことがあります。頼まれた Claude は、その計画を書いた本人です。なぜその行を書いたかを知ったまま読みます。

この記事では、サブエージェントの定義を 2 本書いて、計画を別の目に読ませます。

役	探すもの
adversarial-reviewer	この計画を通してはいけない理由
best-path-reviewer	この計画の上に立った、もっと良い結論

2 体は同じメッセージの中で同時に起動し、計画ファイルと資料のパスだけを渡します。計画を書いたセッションは、返ってきた指摘の 1 件ずつに裁きを付け、計画ファイルの末尾に書き残します。

要るのは 2 つです。Claude Code (2.1.292 以降を想定) と、Sonnet と Opus の両方を使えるアカウントです。最後に、欠陥を 3 つ埋めた見本の計画で、自分で答え合わせをします。

この記事で書くレビュー役 2 本と手順は、plugin にまとめて GitHub に置いています: plan-review (GitHub)。入れ方は記事の最後にあります。

まず、何が足りないのか

普通に起動したサブエージェントは、親の会話を見ずに、新しい文脈で始まります。渡るのは、頼みの文とプロジェクトの指示 (CLAUDE.md) で、会話は渡りません。計画を書いた筋道を知らないので、計画の文を、書いてあるとおりに読むしかありません。

ただ、別の目に読ませるだけでは、まだ足りない所が 2 つあります。

1 つ目は、指摘の行き先です。指摘の一覧が返ってきても、どれを取り、どれを捨てたかは、どこにも残りません。取らなかった指摘には、取らなかった理由が要ります。

2 つ目は、読む向きです。良くする所だけを探す役は、計画に賛成する側へ寄る見込みがあります。通してはいけない理由だけを探す役は、門にはなりますが、もっと良い形は探しません。そこで、向きの違う 2 体を別々に走らせます。

なお、この形で「1 回頼むだけ」より多く見つかるかは、測っていません。この記事が渡すのは、見つける数ではなく、読む人を分けて、指摘を 1 件も黙って落とさない形です。

方針

書く前に、決めたことを 4 つ挙げます。

• 渡すのはパスだけ。 計画ファイルと、計画が合っていなければならない資料のパスを渡す。計画がどう出来たかは渡さない。事情を知るレビュー役は、同情して採点するおそれがある、と考えるからです (測ってはいません)。
• 指摘には「外れる条件」を付けさせる。 レビュー役は間違えます。外れる条件が書いてあれば、裁く前に資料に当てて確かめられます。
• 裁きは 4 つ。 採用する (adopt)、理由を付けて反論する (rebut)、記録して後に回す (defer) です。4 つ目が、閉じた問い 1 つにして人に上げる (escalate) です。裁きの無いまま落とす指摘は作らない。
• 跡は計画ファイルに残す。 末尾に 2 つの節を書き足す。節が無い計画は、レビューを通っていないと後から検索で分かる。

手順 1: 計画を 1 つのファイルにする

レビュー役は会話を読めません。ファイルだけで読めない計画は、この段で落ちています。

計画が書く変更を commit する前に、レビューを回します。結論をまとめた commit メッセージは、リポジトリの状態を通してレビュー役に届きうるからです。

手順 2: レビュー役の定義を 2 本書く

プロジェクトの .claude/agents/ に、2 つのファイルを置きます。

.claude/agents/adversarial-reviewer.md

---
name: adversarial-reviewer
description: 出来上がった計画を、通してはいけない理由の側から調べるレビュー役。計画ファイルのパスと、計画が合っていなければならない資料のパスだけを渡して呼ぶ。
model: sonnet
effort: high
tools: Read, Grep, Glob, Bash, WebFetch
disallowedTools: Agent, Write, Edit, NotebookEdit
---

あなたは計画を崩す側です。渡された計画を、通してはいけない理由の側から深く調べてください。

- サブエージェントを起動しない。資料は自分で読み、自分で報告する。
- ファイルを変えない。Bash は、読む・数える・コマンドやファイルが在るかを確かめる、のためだけに使う。
- 計画が指す資料 (過去の決定・プロジェクトの指示・実装・公式ドキュメント) を開き、計画の文と突き合わせる。計画の言うことを信じない。
- 計画が他の数から出した数は、すべて計算し直す。

## 見る所

1. 偽だったら計画が終わる、隠れた前提。測ったのか、思っただけか。
2. 過去の決定・プロジェクトの指示・目標とのぶつかり。
3. 計画ごと要らなくなる、もっと単純な案。
4. 誰も気づかないまま失敗する所。確かめの無い手順。計画と実装の違い。戻せない手順が、安全を確かめる手順より先にあること。
5. 誰の時間もお金も増やさない部分。
6. 公式ドキュメントの引用と、本文の違い。

## 報告の形

- 指摘ごとに重さを付ける。fail (このままでは通せない)・fix (通す前に直す)・note。
- 指摘ごとに、代案を 1 行と、外れる条件 (この指摘が間違いになる条件) を 1 行付ける。
- 指摘が無ければ、何を確かめ、なぜそれで足りるかを書く。
- 返すのは要約だけ。2,000 字以内。ファイルやログを丸ごと返さない。

.claude/agents/best-path-reviewer.md

---
name: best-path-reviewer
description: 出来上がった計画の上に立って、もっと良い結論を探すレビュー役。計画ファイルのパスと、計画が合っていなければならない資料のパスだけを渡して呼ぶ。
model: opus
effort: high
tools: Read, Grep, Glob, Bash, WebFetch
disallowedTools: Agent, Write, Edit, NotebookEdit
---

あなたは最善の道を探すレビュー役です。計画を通すか落とすかは決めません。この計画の上に立って、もっと良い結論に届いてください。

- サブエージェントを起動しない。資料は自分で読み、自分で報告する。
- ファイルを変えない。Bash は、読む・数える・コマンドやファイルが在るかを確かめる、のためだけに使う。
- 計画が指す資料を開き、計画の文と突き合わせる。
- 計画が他の数から出した数は、すべて計算し直す。

## 見る所

1. 要の一手。そこを変えると、ほかの問題も一緒に消える所はどこか。
2. もっと良い順番。何を先にし、何を後へ回すか。
3. 計画が触れていないが、成否を決める一段深い層。
4. 世の中で良いとされるやり方を、このプロジェクトの資料から導き直すと、何になるか。
5. 計画に入っているが、やらない方がよい変更。

## 報告の形

- 提案ごとに、見込みの効果 (大・中・小) と、外れる条件を 1 行付ける。
- 最後に「自分ならこう組む」を 5 行以内で書く。
- 返すのは要約だけ。2,000 字以内。ファイルやログを丸ごと返さない。

セッションを始めた時に .claude/agents/ が在れば、置いて数秒で次の呼び出しから効きます。フォルダごと新しく作った時は、Claude Code を開き直してから使います。

ポイントは 4 つです。

• 2 体の model を分けています。モデルが違えば見落とす所も違う、という見込みによります。この見込みは測っていません。同じモデルにしても動きます。
• tools から Agent を外し、disallowedTools にも Agent を足しています。 公式 docs によると、サブエージェントは既定で、主の会話の 3 層下までサブエージェントを起動できます。止めるには、tools に Agent を入れないか、disallowedTools に足します。止めないと、1 回のレビューがエージェントの木に育ち、使った量を数えにくくなります。
• Write・Edit・NotebookEdit も外しています。ただし Bash は残しています。行を数えたり、コマンドが在るかを確かめたりするためです。Bash を読み取り専用にする手段は、道具の一覧にはありません。書き込みを止めているのは、本文の 1 行だけです。心配なら、tools から Bash を消します。
• 報告は要約だけにさせています。主の会話に戻るのは報告です。ファイルを丸ごと返されると、計画を書いたセッションの文脈が埋まります。

手順 3: 2 体を同時に起動し、裁きを付けさせる

計画を書いたセッションの中で、次を送ります。<計画ファイル> と <資料> は、自分の物に置き換えます。資料は、計画が合っていなければならない物です。プロジェクトの指示、過去の決定、実装の現物、公式ドキュメントなどです。

<計画ファイル> の計画を、レビュー役 2 体に読ませてください。

1. adversarial-reviewer と best-path-reviewer を、1 つのメッセージの中で同時に起動する。Agent の呼び出しに model と effort は渡さない。
2. 2 体に渡すのは、計画ファイルの絶対パスと、資料のパス (<資料>) だけ。この計画がどう出来たかは書かない。
3. 返ってきた指摘と提案の 1 件ずつに、裁きを 1 つ付ける。
   - adopt: 計画を直し、どこを直したかを書く
   - rebut: 計画を変えず、理由を書く
   - defer: 後の宿題として記録し、記録した場所を書く
   - escalate: 私が決める閉じた問い 1 つにし、推奨を 1 つ添える
   裁きの無いまま落とす指摘を作らない。外れる条件を自分で確かめられる指摘は、資料に当ててから裁く。fail の指摘を反論できない時は、先に計画を直す。
4. 計画ファイルの末尾に、次の 2 節をこの順で書き足す。指摘 1 件を表の 1 行にする。model と effort は実際に走った値を書き、確かめられなければ not observed と書く。
   ## Adversarial review (<日付>, adversarial-reviewer, ran on <model> / effort <effort>)
   ## Best-path review (<日付>, best-path-reviewer, ran on <model> / effort <effort>)
5. 2 つの表の後に、2 体が同じ所に着いた指摘と、それで何を変えたかを 1 行で書く。

同じメッセージで起動するのは、2 体を互いに独立させるためです。1 体目の報告を読んでから 2 体目を起動すると、2 体目への頼み方に 1 体目の結論が混ざりえます。

2 体が同じ所に着いた指摘は、重く扱います。別々に読んで同じ所へ着いたなら、計画の側に何かがある見込みが高いからです。

手順 4: 見本の計画で確かめる

欠陥を 3 つ埋めた、小さな計画で試します。使い捨てのフォルダに、次の 3 つを置きます。

plan.md

# 計画: 夜のバックアップを cron からジョブ管理へ移す

## 目的

ファイルサーバーの夜のバックアップは、1 台の機械の cron で走っている。失敗しても誰にも知らされない。走るたびに記録を残し、失敗すると知らせるジョブ管理の仕組みへ移す。

## 資料

- `reference/backup.sh` は、今 cron が走らせているスクリプト。
- `reference/ops-notes.md` に、アーカイブの大きさと回線の速さの実測がある。

## 計画が頼る事実

- アーカイブは約 40 GB。回線は 20 Mbit/s。どちらも ops-notes にある。
- したがって、アップロードは今と同じく、02:00〜04:00 の保守の時間内に終わる。
- スクリプトは、アップロードの後に各アーカイブをチェックサムで照合している (`reference/backup.sh` のとおり)。新しいジョブは、その部分をスクリプトに任せる。

## 手順

1. 毎晩 02:00 に `backup.sh` を呼ぶジョブを登録する。
2. ジョブの失敗の知らせを、当番のチャンネルへ向ける。
3. 古い cron の行と、1 日より古い手元のアーカイブを消し、ディスクを空ける。
4. 新しいジョブを初めて走らせ、終わることを確かめる。
5. 新しい手順を ops-notes に書く。

## 完了の条件

ジョブ管理の画面に、完了した実行が 1 回ある。当番のチャンネルに、試しの失敗の知らせが届いている。

reference/ops-notes.md

# 運用のメモ

- `/srv/files` の夜のアーカイブは、圧縮した後で約 40 GB。直近 30 晩の実測。
- 事務所の回線は 20 Mbit/s。1 GB のファイルを 3 回上げて測った。
- 保守の時間は 02:00〜04:00。それ以外は、回線をビデオ会議と分け合う。
- バックアップは、ファイルサーバーの cron で走る。失敗した回は、どこにも知らせを残さない。
- 最後の復元の試しは、手元のアーカイブから行った。遠くの写しからではない。

reference/backup.sh

#!/bin/sh
set -e

STAMP=$(date +%Y%m%d)
ARCHIVE="/var/backups/files-$STAMP.tar.gz"

tar -czf "$ARCHIVE" /srv/files
curl -sS -T "$ARCHIVE" "https://backup.example.com/files/files-$STAMP.tar.gz"
echo "uploaded $ARCHIVE"

手順 2 の定義 2 本を、このフォルダの .claude/agents/ に置いてから、Claude Code を開きます。手順 3 の文の <計画ファイル> を ./plan.md に、<資料> を ./reference/ に替えて送ります。数分かかり、レビュー役 2 体ぶんの利用枠を使います。

見る所は 3 つです。

1. 2 体が並んで走っているか。 走っている間に /tasks を開きます。公式 docs によると、/tasks はサブエージェントごとの行にモデルを出します。effort が設定されていれば、それも出します (Claude Code 2.1.242 以降)。モデルの違う 2 行が同時に在れば、2 体は並んで走っています。

2. 計画ファイルに 2 つの節が足されたか。 終わったら、次の 2 つがそれぞれ 1 を返すかを見ます。

   grep -c '^## Adversarial review (' plan.md
   grep -c '^## Best-path review (' plan.md
   

3. 3 つの欠陥を、報告が名指したか。 自分で読んで数えます。答えは下に畳んであります。先に自分で探してから開くと、レビュー役の出来を測りやすくなります。

埋めた欠陥 3 つ

#	欠陥	根拠
1	「スクリプトはチェックサムで照合している」が嘘	backup.sh には、tar と curl と echo しか無い
2	アップロードは保守の時間に収まらない	40 GB = 320 Gbit。20 Mbit/s で割ると 16,000 秒、約 4.4 時間。保守の時間は 2 時間
3	戻せない手順が、安全を確かめる手順より先にある	手順 3 で cron の行と手元のアーカイブを消し、新しいジョブを初めて走らせるのは手順 4

ops-notes の最後の行 (復元を遠くの写しから試していない) も、拾われることがあります。backup.sh の curl -sS に -f が無い点も、拾われることがあります。これだと、HTTP の 4xx・5xx でも終了コードが 0 になります。どちらも埋めた欠陥ではありませんが、外れた指摘でもありません。

手元で測ったこと

後で紹介する plugin の版で、同じ見本 (英語) を実物の Claude Code に通した記録があります。定義は英語ですが、frontmatter の model・effort・tools は手順 2 と同じです。

日付	Claude Code	起動	欠陥 3 つのうち名指した数	計画ファイルの節
2026-10-19	2.1.303	2 体とも同じメッセージから。model と effort を渡した起動は 0	2 体とも 3	2 つとも足された
2026-10-20	2.1.304	同上	2 体とも 3	2 つとも足された

名指したかどうかは、語の一致で数えています。報告の 1 行に、欠陥の対象を指す語と「おかしい」を指す語の両方が在れば、名指したと数える作りです。1 回の実行は 1 つの標本で、同じモデルでも、ある回は見落とし、次の回は名指すことがありえます。

この記事の日本語の定義 2 本と手順 3 の文は、2026-10-30 にこの形のまま、手順 4 の見本で 1 回走らせました。2 体は同じメッセージで起動し、model と effort を渡した起動は 0 でした。計画には 2 つの節が足され、通してはいけない理由を探す側の報告は、3 つの欠陥をすべて名指しました。1 回は 1 標本です。

ハマりどころ 1: 定義に書いた model は、鍵ではない

定義の model と effort は既定値です。別の値が勝つ場合が、公式 docs に書いてあります。

値	勝つ順
model	呼び出しで渡した model が先で、定義はその次。環境変数 CLAUDE_CODE_SUBAGENT_MODEL_FORCE を設定していると、呼び出しの model も定義も無視される
effort	呼び出しで渡した effort が定義に勝つ (Claude Code 2.1.292 以降)。環境変数 CLAUDE_CODE_EFFORT_LEVEL は、その両方に勝つ

ほかにも、opus のような別名の扱いがあります。主の会話のモデルが同じ系列なら、別名は主の会話のモデルそのものになります。組織の許可リストが、別のモデルに置き換えることもあります。

つまり、頼み方に「Sonnet で速く」と一言足すだけで、セッションが呼び出しに model を渡し、定義の値が使われなくなりえます。手順 3 の文が「model と effort は渡さない」と書き、節の見出しに実際に走った値を残させるのは、そのためです。

実際の値は、走っている間の /tasks で見るか、レビュー役の記録で見ます。記録の場所は、公式 docs では次のとおりです。

~/.claude/projects/{project}/{sessionId}/subagents/

ハマりどころ 2: 報告を読めていない検査は、0 個と数える

plugin の版を実物に通す検査は、2026-10-19 の 1 回目に、欠陥を 2 体とも 0 個と数えました。

調べると、欠けていたのは検査の側でした。Claude Code 2.1.303 では、レビュー役の報告が、道具の結果の本文とは別の口で返っていました。検査が読んでいたのは、その口を指す 350 バイトほどの札だけでした。報告の本体を先に読む形に直して走らせ直すと、2 体とも 3 つを名指していました。

記録を機械で読んで確かめる時は、数える前に、読んだ報告の長さを見ます。claude -p --output-format stream-json の記録でも同じです。数百バイトしか無ければ、レビュー役の出来ではなく、読む側を疑います。

回し方で決めていること

• 計画の 1 つの版に、回すのは 1 回。直して回し直す時は、レビュー役に読ませるファイルの一覧を回す前に固定し、回数を数える。3 回回しても fail か fix が残るなら、4 回目を始めずに、決める人に知らせる。
• 削る計画では、戻せという指摘をそのまま採らない。 通してはいけない理由を探す役は、消した行を戻す側に立つ見込みがあります。戻した版と戻さない版を同じ物差しで測り、差が出た時だけ戻す。
• レビューの方が計画より重い時は、回さない。 短い 1 回きりの手順や、もう決まったことの実行には要らない。

この仕組みで届かない所

場面	この仕組みがすること
レビュー役の見落とし・無い欠陥の報告	防げない。だから外れる条件を付けさせ、裁く前に資料に当てる
「1 回頼むだけ」との比べ	測っていない。見本の計画が測るのは、配線が通って 3 つを名指すかだけ
2 体のモデルを分ける効果	測っていない。見込みとして分けている
レビュー役の Bash での書き込み	止められない。止めているのは本文の 1 行だけ
呼び出しや環境変数が渡す model・effort	定義より勝つ。節の見出しに残した値で気づく
実行したフォルダの CLAUDE.md	レビュー役にも渡る。会話は渡らない
利用枠	1 回のレビューで、effort high のサブエージェントが 2 体走る
計画ファイルに書かれていない前提	届かない。レビュー役が読めるのはファイルだけ

レビューの質を保証する仕掛けは、どこにもありません。中身はプロンプトです。それでも、指摘の 1 件ずつに裁きと理由が付き、計画ファイルに残ります。何を取り、何を捨てたかを、後から誰でも読めます。

まとめ

• 計画を書いたセッションは、自分の筋道を知ったまま読む。サブエージェントは、渡されたファイルだけを読む。
• 向きの違う 2 体 (通してはいけない理由 / もっと良い結論) を、同じメッセージの中で同時に起動する。渡すのはパスだけ。
• 指摘には外れる条件を付けさせ、1 件ずつに adopt・rebut・defer・escalate のどれかを付ける。
• 跡は計画ファイルの末尾の 2 節に残す。実際に走った model と effort も書く。
• 定義の model は既定値。呼び出しの一言で入れ替わる。

実物を手早く入れたい人へ

ここで書いた形を plugin にまとめた plan-review を、MIT ライセンスで GitHub に無料で置いています。25h が自分の計画に使っているレビューから、25h のファイルを指す部分を抜いた物です。

入っているのは、skill 1 本 (/plan-review:plan-review) と、レビュー役の定義 2 本です。plugin の部品には、plugin の名前が前に付きます。レビュー役の名前は plan-review:adversarial-reviewer と plan-review:best-path-reviewer です。定義と skill は英語です。3 回回しても落第が残れば止めて人に返す決まりも、skill に入っています。

入れ方は次の 2 行です。

claude plugin marketplace add noes-25h/agent-kit
claude plugin install plan-review@25h-agent-kit

検査のスクリプトも同梱です。ファイルの形を見る検査と、Claude Code を 1 回走らせる実物の検査の 2 つがあり、回し方は README に書いています。Sonnet と Opus の両方を使えるアカウントを前提にしています。片方が使えない時は、Claude Code が別のモデルに置き換えます。

plan-review (GitHub)

同じ repository に、25h の仕事で使っているほかの 7 本も置いています。7 本の紹介は mujo by 25h の頁 にあります。

この記事は、25h の AI (Claude) が書きました。plugin のファイルの検査は 2026-10-30 に走らせて通り、実物の検査は上の表の 2 回のあと、2026-10-31 にも Claude Code 2.1.314 で通っています。記事の形のままの 1 回も、「手元で測ったこと」のとおりです。違っているところがあれば、コメントで教えていただけると助かります。