個人開発のソフトウェアをリリースする前に、Claude Code のサブエージェントで不具合を洗い出しました。範囲を 15 の区分に分け、各区分で、レビューを担当するサブエージェント(以下、レビュー担当)を同じ指示で 2〜3 本並べて走らせました。effort は high と xhigh を混ぜ、レビュー担当は合わせて 42 本です。指摘はすべて、サブエージェントを起動したメインのセッションが裏取りし、本物の不具合だけを数えました。

この記録から、Opus 5.5 の effort high と xhigh の違いと、同じレビューを 2 本走らせるダブルチェックの効き目を集計しました。結論は次のとおりです。

件数の差は小さく、重い不具合で差が出た: 1 本が見つけた割合(網羅率)は high が 55%、xhigh が 67% でした。重要度「高」の不具合を見つけた割合(「高」の検出率)は high が 52%、xhigh が 85% です。「高」17 件のうち 8 件は xhigh だけが見つけました。high だけが見つけた「高」はありません
件数では、effort の差より実行ごとのばらつきの方が大きい: high が 3 本の中で最多だった区分もあります。xhigh 1 本の網羅率が 36% にとどまったこともありました
xhigh を 2 本にすると、取りこぼしが大きく減った: 網羅率は 1 本平均の 61% から 85% に、「高」の検出率は 78% から 100% に上がりました。2 本が見つけたもののうち、両方が見つけたのは半分以下(45%)です
文書の指摘は、見つけたのが 1 本だけという形になりやすい: 2 本以上が見つけた割合は、コードの指摘が 58%、文書の指摘が 29% でした
誤検出と捏造はどちらの effort も 0 件でした
xhigh のコスト: high と比べて、1 本あたりの時間は約 1.3 倍、処理したトークンは約 1.8 倍でした

何をしたか

対象

対象は、個人開発の Python 製ライブラリと CLI です。テストは数千件あります。既存の CLI ツールと同じ挙動にすることを目標にしているので、そのツールの版を固定して手元に置きました。レビュー担当には、既存ツールとの挙動の差も、両方を実際に動かして確かめさせています。

区分

一度に全体を見せると取りこぼしが増えるので、範囲を狭く切りました。ファイル群ごとの区分に、機能をまたぐ観点の区分を足しています。

区分	範囲
1	直近の変更差分
2	転送処理
3	公開 API
4	ローカル側の入出力
5	リモート側の入出力
6	同期の判定とフィルタ
7	SDK との連携
8	CLI の起動と設定
9	サブコマンド
10	補助機能
11	横断: 似た経路への直し漏れ
12	横断: 例外と終了コード
13	横断: 設定とセッションの組み合わせ
14	初めて使う人の目線(配布物を素の環境に入れ、文書のコード片を全部実行する)
15	本番環境での実測(有料のクラウド環境に実際に要求を送る)

15 の区分を、17 日間で順に進めました。

1 区分に 2〜3 本

各区分で、同じ指示を 2〜3 本のサブエージェントに渡し、同時に走らせました。effort の組み合わせは途中で変えています。

区分	high	xhigh	この形にした理由
1〜3	1 本	1 本	最初の形(high と xhigh を 1 本ずつ比べる)
4〜8	2 本	1 本	high を 2 本にしてもダブルチェックになるかを見るため
9〜15	1 本	2 本	区分 4〜8 で、xhigh だけが「高」をすべて拾っていたため

effort は、エージェント定義ファイルの front matter で指定しました。effort だけが違う定義を ~/.claude/agents/ に置きました。

---
name: opus-xhigh-worker
description: Opus を effort xhigh で動かす実装・レビュー用の汎用エージェント。明示的に指名されたときだけ使う。
model: opus
effort: xhigh
---

high 用の定義は、name、description、effort の 3 行だけが違います。

役割

役割	モデル
指示書の作成、指摘の裏取りと判定、修正	メインのセッション(区分 1〜8 は Claude Fable 5.1、区分 9〜15 は Claude Opus 5.5)
レビュー担当	Claude Opus 5.5(サブエージェント、high または xhigh)
修正のレビュー	Claude Opus 5.5(サブエージェント、xhigh)

条件を揃えるための工夫

指示書だけでなく、起動文も同じにする: 起動文は、サブエージェントを起動するときに渡す文です。違うのは「A」「B1」のような実行の名前だけです。起動文の原文は、指示書の末尾に置きました(理由は、考察の「比較では起動文まで揃える」に書きます)
同時に起動し、互いの結果は見せない: 報告はそれぞれ別のファイルに書かせました
重要度の基準を固定する: 基準は次の 3 段階です
- 高: データの消失、誤った転送や削除、異常終了、終了コードの反転、利用者が普通の使い方で出会うもの
- 中: 限られた条件でだけ出る誤動作、出力・文言・警告のずれ、性能の退行
- 低: 文書、コメント、型注釈、整形

捏造を防ぐ決まり

レビュー担当には、次のことを守らせました。

証拠に引くコードは、対象のファイルから一字一句そのまま写す。提出前に該当行を読み直して照合する
「実行した」と書いてよいのは、実際に実行したものだけ。読んで判断しただけの項目には「証拠: 読解」と書く
不具合を主張するときは、「この入力・この状態 → この誤った出力」という具体的な筋書きを付ける。「〜の可能性がある」だけの項目は報告しない
再現用のスクリプトを、再実行できる形で残す
見つからなければ 0 件で返してよい。数を水増ししない

メインのセッションは、指摘を 3 段階で裏取りしました。

引用が実在するかを確かめる
残された再現スクリプトを再実行する
必要なら、自分でも測る

数え方

実欠陥: 裏取りで本物と確かめた不具合です。仕様どおりのもの、既知の事項、誤読、捏造は除きました
網羅率: その区分でどれかのレビュー担当が見つけた実欠陥のうち、その 1 本が見つけた割合です。メインのセッションだけが見つけたものは分母に入れていません
「高」の検出率: 網羅率と同じ数え方を、重要度「高」の実欠陥だけで計算したものです
集計から外した実行: 区分 1〜3 では、あとで high をもう 1 本ずつ追加で走らせました。ところが起動文が元と違っていたので、集計から外しています

結果

規模

レビュー担当が見つけた実欠陥は 159 件で、そのうち重要度「高」は 17 件でした。誤検出(事実の誤り)と捏造は、どの実行も 0 件です。指摘のうち数件は「仕様どおり」や「既知」として採りませんでしたが、観察そのものは正しいものでした。

high と xhigh(1 本あたり)

	high	xhigh
本数	20	22
網羅率	55%	67%
「高」の検出率	52%(12/23)	85%(22/26)
その effort だけが見つけた「高」	0 件	8 件(全 17 件中)
誤検出・捏造	0	0
平均の所要時間	約 50 分	約 62 分

期間ごとに分けると、次のとおりです。

区分	high 1 本の網羅率	xhigh 1 本の網羅率	「高」の検出 high / xhigh
1〜3	56%	68%	1/2、2/2
4〜8	55%	78%	7/12、6/6
9〜15	55%	61%	4/9、14/18

「高」の検出の分母は、「高」の件数 × 本数です。たとえば区分 4〜8 の high の 7/12 は、「高」6 件を 2 本で探し、2 本が見つけた件数の合計が 7 だったことを表します。

網羅率の差は区分 4〜8 では大きかったものの、区分 9〜15 では 6 ポイントまで縮みました。区分ごとに見ると、区分 10 と 12 では high が 3 本の中で最多でした。xhigh 1 本の網羅率が 36% にとどまった実行も 2 本あります。

ダブルチェック

2 本を組み合わせたときに、どれだけ拾えたかを比べました。

組み合わせ	区分	網羅率	「高」の検出
high + high	4〜8	76%	4/6
high + xhigh	4〜8	92〜94%	6/6
high + xhigh	9〜15	83〜85%	7〜8/9
xhigh + xhigh	9〜15	85%	9/9

分母は 3 本の和なので、3 本そろえば定義上 100% になります。範囲で書いた行は、組み合わせ方が 2 通りあるためです(区分 4〜8 は high 2 本のどちらを使うか、区分 9〜15 は xhigh 2 本のどちらを使うか)。

2 本の重なりは半分以下: xhigh 2 本の和 60 件のうち、両方が見つけたのは 27 件(45%)でした。区分 4〜8 の high 2 本も 44% で、ほぼ同じです
網羅率の低い 1 本を補う: xhigh 1 本が 14 件中 5 件しか見つけなかった区分が 2 つありました。どちらも、2 本の和では 10〜11 件まで上がりました
区分 9〜15 で high が xhigh 2 本に足したもの: 11 件で、内訳は中 7・低 4 でした。「高」はありません。一方で、3 本の中で xhigh の 1 本だけが見つけたものには、「高」が 3 件含まれていました

文書の指摘

実欠陥 159 件のうち、文書の指摘は 34 件でした。重要度は中 6 件・低 28 件です。

	文書	コード
high 1 本の網羅率	47%	57%
xhigh 1 本の網羅率	57%	69%
2 本以上が見つけた割合	29%	58%

区分 9〜15 の文書 13 件では、high と xhigh の差は見えませんでした(high 54%、xhigh の 2 本は 54% と 38%)。文書の網羅率は、xhigh 1 本平均の 46% から、2 本の和では 69% に上がりました。

修正のレビュー

判定のあと、メインのセッションが不具合を直しました。その修正自体も、xhigh のサブエージェントにレビューさせています。

区分 1〜5 の修正 53 件: 1 回目のレビューで実欠陥 36 件(「高」2 件)が見つかりました。その指摘を直した修正を 2 回目のレビューにかけると 18 件、さらに 3 回目では 5 件でした
区分 9〜15: 区分ごとに 2〜5 回レビューし、指摘は合わせて 80 件ありました。そのうち約 3 割は、修正が持ち込んだ退行か、直し残しでした
区分 12〜15: 指摘 45 件のうち 18 件(40%)が文書でした。主に、修正のときにメインのセッションが書いた説明の誤りや言い過ぎです

コスト

レビュー担当 1 本あたりのコストは、次のとおりです。

	high	xhigh	比
時間	約 50 分	約 62 分	約 1.3 倍
処理したトークン(API の使用量の累計)	約 3,500 万	約 6,000 万	約 1.8 倍(区分ごとに 1.1〜2.7 倍)
完了通知のトークン数	約 41 万	約 55 万	約 1.35 倍

Claude Code のサブエージェントの完了通知にもトークン数が付いてきます。ただしこれは、処理したトークンの総量ではありませんでした。fork を除く 79 本すべてで、その実行のコンテキストが最も大きくなった時点の大きさと、0.4〜3.3% の差で一致しました。コストを比べるなら、会話記録に残る API の使用量を足し合わせる必要があります。

17 日間の合計は次のとおりです。

	本数	時間	トークン
メインのセッション	—	約 26 時間	15.9 億
レビュー担当 high	23	18.7 時間	7.9 億
レビュー担当 xhigh	22	22.9 時間	13.5 億
修正のレビュー(xhigh)	34	22.2 時間	10.4 億
その他(fork。メインのセッションの複製)	4	1.8 時間	0.5 億
合計	83	約 92 時間	48.2 億

トークンの大半はキャッシュ読み: 全体の 98.5% がキャッシュ読みでした
レビュー担当 high の本数: 集計から外した区分 1〜3 の追加の実行 3 本も含みます(そのため、1 本あたりの表の 20 本より 3 本多くなっています)
メインのセッションの時間: 会話記録の時刻から、作業していた時間だけを足しました。サブエージェントの完了待ちと、私の返答待ちの時間は除いています

考察

effort の差は、件数より重さに出る

high と xhigh の網羅率の差は 10 ポイント前後で、区分によっては逆転しました。一方、「高」の検出率は 52% と 85% で、はっきり差がつきました。high だけが見つけた「高」は 1 件もありません(集計から外した区分 1〜3 の追加の実行では、high が他の 2 本の落とした「高」を 1 件見つけています)。

各区分の記録の所見を読むと、high は多くの箇所を広く確かめ、xhigh は内部の処理経路を深く追う傾向がありました。high だけが見つけたのは、たとえば次のような指摘です。

互換サーバーが返す、標準と異なる応答
依存ライブラリの版による挙動の違い
文書の例を書かれたとおりに動かすと失敗する箇所

件数は実行ごとのばらつきが大きい

同じ effort、同じ指示でも、1 本ごとに見つかるものがかなり変わります。同じ effort の 2 本でも、重なりは半分以下でした。1 回ずつ走らせて effort を比べると、偶然の差を effort の差と取り違えやすくなります。

ダブルチェックはよく効く

1 本では、xhigh でも 3〜4 割を取りこぼします。2 本目を足すと網羅率は 20 ポイント以上上がり、xhigh 2 本では「高」の取りこぼしが 0 件になりました。2 本は並べて走らせるので、待ち時間はほとんど増えません。

文書は複数本で見る

文書の指摘は、見つけたのが 1 本だけという形が 7 割でした。1 本で済ませると、文書の不具合の大半を落とします。修正のレビューでも、文書の指摘が 4 割を占めました。修正のときに書き足した文書にも、レビューが要ります。

修正にも不具合が入る

修正をレビューにかけるたびに指摘が出ました。回を重ねると減りますが、0 にはなりませんでした(36 → 18 → 5 件)。修正レビューの指摘の約 3 割は、修正が持ち込んだ退行か、直し残しでした。

比較では起動文まで揃える

区分 1〜3 では、あとから high をもう 1 本ずつ追加で走らせ、新しい不具合を 7 件見つけました。ところが、その追加の実行の起動文は元より短く、重点の順序や報告の決まりの要約が入っていませんでした。そのため、7 件が実行ごとのばらつきによるものか、起動文の違いによるものかを切り分けられませんでした。指示書が同じでも、起動文が違えば条件は揃っていません。

実環境を触らせるときは、仕組みで縛る

本番環境に要求を送る区分 15 では、指示書で決めた上限や禁止事項を守らなかったレビュー担当が 2 本ありました。1 本は外部への要求数の上限を超え、もう 1 本は第三者の公開リソースに要求を送りました。どちらも実害はありませんでした。それでも、外部に触れる検証では、指示だけでなく権限や上限を仕組みで縛るべきだと感じました。

この検証の限界

本当の網羅率は分からない: 分母は 3 本の和です。どの 1 本も見つけなかった不具合は数に入らないので、本当の網羅率はこれより低いはずです
標本が小さい: 「高」は 17 件、区分 9〜15 では 9 件だけです
期間ごとに組み合わせと難しさが違う: 期間ごとに effort の組み合わせが違い、区分の難しさも違います。期間をまたいだ比較(たとえば区分 4〜8 と 9〜15)には、難しさの違いが混ざっています
判定にバイアスがありうる: 本物かどうかと重要度の判定は、修正を書いたのと同じメインのセッションが行いました。途中でモデルも変わっています(Claude Fable 5.1 から Claude Opus 5.5)
対象は 1 つ: 1 つのプロジェクトでの結果です

まとめ

1 本だけ走らせるなら xhigh を選びます。件数の差は小さいものの、重い不具合を見つける割合がはっきり違います
重要な範囲には xhigh を 2 本並べます。網羅率は 61% から 85% に上がり、「高」の取りこぼしがなくなりました。コストは 1 本分増えますが、待ち時間はほとんど増えません
3 本目の high は、中・低の取りこぼしを拾います。予算に余裕があれば足す価値があります
文書と修正にも、レビューを複数回かけます

effort を上げるより、走らせる本数を増やす方が取りこぼしは減ります。ただし、重い不具合は xhigh しか見つけられないことがありました。だから「xhigh を 2 本」が今回の答えです。