Anthropic公式ドキュメントの「Prompting Claude Opus 5」のまとめ。読んでみると、指示を足す話より「今まで入れていた指示を消す」話が目立つ。Opus 5は指示しなくても自分で検証や自己修正をやるので、「再確認せよ」系の指示はむしろ邪魔になるらしい。

やること一覧

困る挙動	やること
応答が長い	簡潔さをプロンプトで明示する。effortを下げても応答は短くならない
作業中のナレーションが多い	報告のペースと形式を指定する
書き出すレポートやMarkdownが長い	長さ調整の指示を1文足す
検証をやりすぎる	既存の「最終検証ステップを含めよ」系の指示を削除する
タスク範囲を勝手に広げる	スコープを明示的に制約する
サブエージェントに委任しすぎる	委任してよい条件と上限を書く
細かい訂正をいちいち口に出す	重要な訂正だけ言及させる
コードレビューの報告が少ない	「重大なもののみ報告」をやめ、全部報告させて別パスでフィルタする
思考オフでツール呼び出しがテキストに漏れる	基本は思考オン+低effort。オフ必須なら緩和プロンプトを入れる

各プロンプトの日本語訳

原文は英語。各ブロックは見出しつきにしてあるので、そのままCLAUDE.mdに貼れる。

1. 応答の簡潔化

### 応答の簡潔さ
応答は焦点を絞り、手短で簡潔に保つこと。免責や注意書きは短くし、応答の大半を本題の回答に費やすこと。説明を求められたときは、掘り下げた説明を明確に求められない限り、要点レベルの要約を返すこと。

長いシステムプロンプトでは、終わり近くに短いリマインダーを置いてペアにする。

<tone_preference>
出力は適度に簡潔に保つこと。
</tone_preference>

2. 進捗報告のペース

### 進捗報告
最初のツール呼び出しの前に、これから何をするかを1文で述べること。作業中は、重要なものを見つけたときか方向を変えたときにだけ短く報告すること。終わったら結果を先頭に置くこと。最初の1文が「何が起きたか」「何が見つかったか」に答え、補足の詳細は読みたい人のためにその後ろに書くこと。

逆にナレーションを増やしたい場合も手段は同じで、望む報告の形を例つきで書く。やらないことの列挙より、肯定的な例の方が効くとのこと。

3. 書き出すドキュメントの長さ

### ドキュメントの長さ
書き出すドキュメントの長さは、タスクに必要な分に合わせること。中身は押さえつつ、埋め草のセクションや冗長な要約、決まり文句で水増ししないこと。

4. タスクのスコープ制約

### タスクのスコープ
頼まれたことを、意図された範囲で仕上げること。日常的な判断は自分で下し、依頼の読み方しだいで成果が大きく変わるときにだけ確認すること。依頼が間違っていそうなときや、もっと良いやり方があるときは、1文でそう伝えたうえで、黙って狭めたり広げたり別物に変えたりせず、頼まれたとおりにタスクを続けること。タスク全体を完了させ、頼まれた範囲を明らかに超える行動は控えること。

検証まわりはプロンプトを足すのではなく消す対応になる。「自明でないタスクには最終検証ステップを含める」のような指示が既にあるなら削除する。Opus 5は指示がなくても検証するので、二重になってトークンを無駄にするだけらしい。

5. サブエージェント委任の抑制

### サブエージェント委任
サブエージェントへの委任は、広範囲のマルチファイル調査のように、本当に独立していて並列化できる大きなタスクに限ること。数回のツール呼び出しで自分で終えられる作業を委任しないこと。自分の作業の検証やダブルチェックにサブエージェントを使わないこと。1体で完了できるなら複数ではなく1体を使い、起動数は少なく保つこと。

6. 訂正ナレーションの抑制

### 自己訂正の扱い
以前の発言の訂正は、その誤りがユーザーのコードや結論、意思決定を変える場合にだけ行うこと。訂正は率直かつ手短に述べ、タスクを続けること。ユーザーにとって何も変わらないミスは、指摘せずに直してそのまま進むこと。

「答えを再確認せよ」「応答前に再検証せよ」といった指示も不要。勝手にやっている作業と重複してコストが増えるだけなので消す。

7. 思考オフ時の緩和

公式の推奨は、思考をオフにするのではなく、オンのまま低effortでコストを抑える方。lowで思考ありの方が、同程度のコストで思考なしより成績が良いらしい。どうしてもオフにする場合は次の指示で、ツール呼び出しのテキスト漏れと内部XMLタグの混入をまとめて緩和できる。

### 思考オフ時の出力ルール
ツールを使うときは、先に短い1文を添えてよい。ユーザーの依頼を表現できるツールがない場合は、推測する代わりにその旨を伝えること。内部用やシステム用のXMLタグを応答に含めないこと。

タグ名を名指しで禁止する書き方(thinkingタグを出すな、など)は上の一般形より効きが悪いとのこと。システムプロンプトに「推論するな」系のルールがあるとタグ漏れが増えるので、それも消す。

参照ソース

この記事は公式ドキュメントの次のページだけをまとめたもの。プロンプト原文(英語)もここにある。