Claude Opus 5のプロンプトから検証の指示を外す — 訂正の語りも抑える
Opus 5は頼まなくても自分の作業を検証します。「最後に検証して」「もう一度確認」を残すと何が起きるか、範囲を絞る一文と訂正の語りを抑える一文の書き方までを具体的な文面で示します。
Claude Opus 5は、頼まれなくても自分の作業を検証します。旧モデル向けに書いた「最後に検証ステップを入れて」「回答前にもう一度確認して」といった指示は、Opus 5ではそのまま無駄なトークンになります。Opus 5のプロンプト解説は、こうした指示は外すよう書いています。外しても品質は落ちないというのが公式の説明です。
この記事では、外すべき指示の見分け方と、外したあとに残る2つの癖(作業範囲の拡大、訂正の語りすぎ)を抑える文面を扱います。
検証の指示を残すと、Opus 5では何が増えるのか
Opus 5のプロンプト解説の「Task scope and over-verification」節は、明示的な検証指示を例に挙げています。「重要なタスクには最終検証ステップを入れる」「サブエージェントに検証させる」の2つです。これらは、Opus 5では過剰検証(over-verification)を招きます。削除すると、品質を落とさずに無駄なトークンが減るとされています。
対象は、プロンプトの文面だけではありません。検証を別ステップとして足す旧来のハーネスの足場(scaffolding)にも、同じことが当てはまります。
過剰検証の中身は、モデルが自力でやる確認に、指示された確認が重なることです。確認が二重になるぶん、出力トークンと待ち時間が増えます。品質の上積みはありません。
外す対象と残す対象
検証まわりの指示は、次のように振り分けられます。
| 指示の種類 | 例 | 扱い |
|---|---|---|
| 検証ステップの義務づけ | 例「最後に必ず検証ステップを入れる」 | 扱い外す |
| サブエージェントによる検証 | 例「別のエージェントで確認させる」 | 扱い外す |
| 再確認の念押し | 例「回答前にもう一度確認して」 | 扱い外す |
| 検証専用の工程 | 例ハーネスに残る旧来の足場 | 扱い外す(評価で確かめてから) |
| 判断基準そのもの | 例「合格条件は〇〇」「このコマンドの結果を根拠にする」 | 扱い検証の「やり方」ではなく仕様なので別扱い |
最後の行は、記事側の整理です。公式が外すよう書いているのは「検証しなさい」という命令の類で、合格条件や成果物の仕様まで消せとは書いていません。CIのテストのようにモデルの外側で走る機械的なチェックも、プロンプトの指示ではないので、この節の対象とは別の話です。
古い検証指示の探し方
自分のプロンプト資産から該当しそうな文言を洗い出すには、grepが手軽です。次は一例で、語句は自分の言い回しに合わせて足します。
grep -rnE "検証|再確認|もう一度確認|ダブルチェック|verify|double-check|re-verify" \
prompts/ CLAUDE.md .claude/agents/ .claude/skills/ヒットした行を、次の3つに分けます。
- 検証を命じているだけの行は、削除候補です
- 合格条件を述べている行は、残します
- 判断がつかない行は、評価セットで外した場合と比べます
「検証」はプロンプト中の別の意味(たとえば検証環境、入力値の検証ルール)でも出てくるので、機械的に全部消してはいけません。
「もう一度確認して」も、同じ理由で外す
同じプロンプト解説の「Self-correction」節は、Opus 5が自分の誤りに気づいて直す力を、プロンプトなしでも十分に持つとしています。そのうえで、「回答をダブルチェックして」「応答の前に再検証して」のような再確認の指示は避けるよう書いています。モデルがすでにやっていることに重なって、コストだけが増え、結果は良くならないからです。
つまり、検証ステップの指示と再確認の指示は、同じ原因による同じ症状です。前者は工程として、後者は一言の念押しとして現れるだけです。
旧モデル向けのプロンプトには、「重要な箇所は必ず見直すこと」のような念押しが、あちこちに散らばっていることがあります。1箇所ずつ外して効果を測るより、検証系の文言を一括で外したプロンプトを作り、評価セットで元のプロンプトと比べるほうが速く判断できます。比べ方はプロンプト評価の実践ガイドにまとめています。
検証を外す前に確認したい、effortとの関係
検証の指示を外すことと、effortを下げることは別の操作です。effortはモデルがどれだけ考えるかを調整する値で、Opus 5ではeffortを変えても、見える応答の長さが確実に短くなるとは限りません。応答の長さは、プロンプトで指定します。
Opus 5のAPI既定のeffortはhighです。要求の内容に応じてxhighやmaxに上げたり、lowやmediumをコストと応答速度の主な調整手段にしたりします。検証指示の削除は、これらのどの段階でも使えるプロンプト側の調整です。段階の選び方はOpus 5のeffort使い分けで扱っています。
作業範囲が広がるときは、範囲を決める一文を足す
Opus 5は、頼まれていない手順を足したり、タスクの中身を自分の判断で解釈し直したりして、範囲を広げることがあります。狭い作業を頼むときは、範囲を明示します。公式の英文例の趣旨は次のとおりです(訳)。
頼まれたことを、意図された範囲で届ける。通常の判断は自分で下し、
読み方によって作業内容が大きく変わるときだけ確認する。依頼が誤って
いそうなとき、より良い方法があるときは、一文で伝えたうえで、依頼
どおりに作業を続ける。黙って範囲を狭めたり、広げたり、作り替えた
りしない。作業全体を終わらせ、依頼の範囲を明らかに超える行動は
しない。この文面で効くのは、後半の「一文で伝えて、依頼どおり続ける」です。モデルが異論を持ったときの出口が用意されているので、黙って作業内容を変える動きが減ります。
範囲の拡大は、過剰検証と合わせて起きやすい症状です。検証指示を外すと同時に範囲を決める一文を足す、と1回の改訂にまとめると、評価の回数も減らせます。Claude Codeの過剰実装との関係は、Claudeの過剰実装を防ぐプロンプトで、Opus 5の項目を含めて整理しています。
「慎重に」「保守的に」と書くと、逆に報告が減る
検証とは別の話ですが、Opus 5のプロンプト解説はコードレビューについて、「重大度の高いものだけ報告する」「保守的に」と指示すると、モデルが文字どおりに従って報告を減らすことがあるとしています。網羅的に報告させ、絞り込みは別の工程で行うほうが安全です。「慎重にやって」という検証風の指示が、思わぬ形で出力を絞る例といえます。
訂正の語りが増えたら、訂正してよい条件を書く
もう1つ、Opus 5は自分の前の発言への訂正を、旧モデルより多く言葉にします。ユーザー向けのプロダクトでは、これがノイズになります。「先ほどの説明に誤りがありました」が頻繁に挟まるためです。
公式の対策は、訂正を語る条件を絞る一文です(英文例の訳)。
前の発言を訂正するのは、その誤りがユーザーのコード、結論、判断を
変えるときだけにする。訂正は平易に短く述べ、そのまま作業を続ける。
ユーザーにとって何も変わらない些細なミスは、直すだけにして、触れ
ずに先へ進む。ポイントは、訂正をやめさせるのではなく、語る基準を決めている点です。コードや結論が変わる誤りは、これまでどおり伝わります。
検証の指示とは目的が違う
3つの症状は、原因も効く対策もそれぞれ違います。
| 症状 | 原因 | 対策 |
|---|---|---|
| 無駄に確認が増え、トークンと時間がかさむ | 原因自己検証に、指示された検証が重なる | 対策検証・再確認の指示を外す |
| 応答に「訂正します」が頻出する | 原因訂正を言葉にする頻度が高い | 対策訂正を語る条件を絞る一文を足す |
| 頼んでいない作業が付いてくる | 原因範囲を自分で広げる | 対策範囲を決める一文を足す |
どの対策も、足すのは短い一文で、消すのは古い念押しです。プロンプト全体が短くなる方向に変わります。
Claude CodeとAgent SDKでは、サブエージェントによる検証も見直す
「サブエージェントで検証させる」は、検証指示のなかでもコストへの影響が大きいものです。Opus 5はもともとサブエージェントへの委任に積極的で、公式は小さなタスクにまで委任すると、コストと時間が膨らむと説明しています。委任を絞る文面の例には、次の趣旨の一節が含まれます(訳)。
本当に独立していて並列化できる大きな作業にだけサブエージェントを
使う。数回のツール呼び出しで自分で終えられる作業は任せない。自分の
作業の検証や二重確認のためにサブエージェントを使わない。最後の一文が、検証指示の削除と一致します。プロンプトの文面だけでは不安なら、上限を機械的にかける手段もあります。
- 環境変数
CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH: サブエージェントの階層の深さの上限 - 環境変数
CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS: 1セッションで同時に動かせるサブエージェントの数の上限 - Agent SDKの
max_budget_usd(TypeScriptではmaxBudgetUsd): 支出の上限
2つの環境変数は、Claude Code 2.1.217以降で使えます。バージョンを固定したSDKを使う環境では、Opus 5に向ける前に更新が必要です。
もう1点、注意があります。Claude Codeがサブエージェントについて自前の委任指示を足すのは、claude_codeのシステムプロンプトのプリセットを使うときです。システムプロンプトを自作する、または省略すると、その指示は入りません。委任を絞りたいなら、上の例のような一節を自分で足します。Claude Code側の仕組みはサブエージェントの解説にあります。
CLAUDE.mdに入れるなら、こう書く
ここまでを、Claude Codeのプロジェクトに入れる形に落とすと、次のようになります。これは公式の例文をつなげた記事側の応用で、公式が示す完成形ではありません。
## 作業の進め方
- 依頼された範囲で作業を終える。通常の判断は自分で下し、読み方に
よって作業内容が大きく変わるときだけ確認する。
- 依頼が誤っていそうなときは一文で伝え、依頼どおりに続ける。
- 前の発言を訂正するのは、コードや結論が変わるときだけにする。
- 自分の作業の検証のためにサブエージェントを使わない。見てのとおり、「最後に検証する」「もう一度確認する」の行がありません。意図して入れていません。合格条件(「npm testが通ること」など)は、検証の命令ではなく仕様なので、別の行として足して構いません。
外したあとの確かめ方
検証指示を外した結果は、自分の評価セットで確かめます。見るのは次の3点です。
- 品質: 元のプロンプトと同じ合格率か
- コスト: 1タスクあたりの出力トークンと所要時間が減ったか
- 副作用: 訂正の語りや範囲の拡大が目立っていないか
公式は品質の低下がないと説明していますが、これはAnthropicの一般的な説明です。自分のタスクで同じになるかは、測らないと分かりません。減ったトークンの見積もりは、Opus 5.5のタスクコスト試算の分解の考え方が使えます。
thinkingを無効にした運用では、別の論点が出ます。ツール呼び出しが文章として出る、内部のタグが出力に混ざる、といった症状です。その場合の書き方は、thinking無効のプロンプト移行で扱っています。
まとめ
Opus 5のプロンプトは、足すより削るほうが効く場面が多いモデルです。検証と再確認の念押しは外し、範囲と訂正の2つだけを短い一文で決める。この3点で、旧モデル向けの長いプロンプトはかなり軽くなります。
最初の一歩として、grepで検証系の文言を洗い出し、削除したプロンプトと元のプロンプトを同じ評価セットで比べてみてください。差が出なければ、そのまま削除後のプロンプトを採用できます。