まず削る — 自分で検証させる文すべて

このドキュメントで最初にやるべきことです。削る文は 2 種類あり、どちらも見覚えがあるはずです。

1 つ目はタスク単位の検証要求。典型は「単純でないタスクにはすべて最終検証ステップを含める」「サブエージェントで検証する」。2 つ目は回答単位の自己チェック要求で、「もう一度答えを確認する」「回答前に再確認する」といった書き方です。どちらも処置は同じ — 削除します。

削る対象はプロンプトの文だけではありません。ドキュメントはわざわざ触れています — 旧モデル向けに組んだ処理の足場（harness）に検証工程が独立して入っているなら、それも一緒に外すこと。プロンプトはモデルに向けた言葉、足場は外側に書いたフローのコードで、いつモデルを呼ぶか、何回呼ぶか、毎回何を渡すかを管理します。両方の層を掃除する必要があります。

レビュープロンプトに「重大なものだけ」と書くと、本当に減る

最も直感に反し、自分の自動化フローで最も踏みやすい落とし穴です。

まず前提。Opus 5 はコードレビューの精度も網羅性も高く、1 ラウンドで本物のバグを拾う割合が高い。しかも多く挙がった分の大半は本物の問題で、誤検出の水増しではありません。実用上さらに効くのは、この精度が思考の強さを下げても保たれる点です。だから安いレベルでざっと 1 周スキャンし、あとで詳しくもう 1 周、という進め方ができます。

問題は絞り込み条件の書き方です。プロンプトに「重大度の高い問題だけ報告して」あるいは「保守的に」と入っていると、Opus 5 は文字どおり実行する可能性があり、結果として報告が減ります。示された解決策は、絞り込みをプロンプトの外に出すこと — すべて報告させ、別ラウンドで絞ります。

2 つの書き方の違いは、突き詰めれば一言です。何を重大とみなすか、誰が決めるのか。プロンプトに書けば、その判断はあなたに見えない場所でモデルが済ませてしまいます。別ラウンドにして初めて、判断が手元に戻ります。

饒舌になる 3 か所は、別々に抑える

Opus 5 がユーザーに見せる回答は、前世代の Opus より長めです。多くの人はまずレベルを下げて文字数を節約しようとしますが、この道は通りません。まず effort というパラメータが何を管理しているかを押さえる必要があります。

effort（思考の強さ）が決めるのは、モデルが今回どれだけのトークンを使って考えるかであって、最終的にどれだけ話すかではありません。下げれば思考量は減りますが、見える回答の長さが連動して短くなるとは限りません。短く話させたいなら、はっきり要求するしかありません。

1 か所目 — ユーザーに見せる回答

Keep responses focused, brief, and concise. Keep disclaimers and caveats short, and spend most of the response on the main answer. When asked to explain something, give a high-level summary unless an in-depth explanation is specifically requested.

システムプロンプトが長い場合は、組み合わせ技があります。長いプロンプトの末尾に短いリマインダーを足し、上の一段とペアで使います。

<tone_preference>
Keep outputs reasonably concise.
</tone_preference>

2 か所目 — ディスクに書き出すファイル

これは会話の饒舌さとは別物で、個別に抑える必要があります。Opus 5 が書くレポート、Markdown 文書、まとめファイルも前世代より長めです。製品がモデルに文書を生成させてユーザーに渡すなら、長さの明確な基準を与えてください。

Match the length of written documents to what the task needs: cover the substance, but do not pad with filler sections, redundant summaries, or boilerplate.

3 か所目 — 作業中の実況

Opus 5 は自走させる（agentic な）場面でよく喋ります。動く前に何をするつもりか一言述べ、各メッセージも前世代より長い。抑えるには、黙れと命じるのではなく、望むテンポと形を具体的に描写すれば足ります。

Before your first tool call, say in one sentence what you're about to do. While working, give a brief update only when you find something important or change direction. When you finish, lead with the outcome: your first sentence should answer "what happened" or "what did you find," with supporting detail after it for readers who want it.

逆にもっと実況させたい、あるいは別のスタイルにしたい場合は、同じレバーを反対に倒します。ここから一般的なコツも見えてきます — 望むコミュニケーションスタイルの良い例を示すほうが、「こうするな」を並べるより効きます。

サブエージェントに投げたがる — 小さい仕事まで

サブエージェント（subagent）とは、メインのモデルが仕事の一塊を切り出し、新しく立てた分身に独立して片づけさせて戻す仕組みです。分身はそれぞれ自分でコンテキストを読み、自分で生成し、それぞれトークンを消費します。

Opus 5 は前世代より積極的に投げます。本当に独立していて規模の大きいタスク — 多数のファイルにまたがる調査など — では割に合いますが、小さいタスクに使うと、コストも時間も掛け算になります。

Delegate to a subagent only for large tasks that are genuinely independent and parallelizable, such as a wide multi-file investigation. Do not delegate work you can finish yourself in a handful of tool calls, and do not use subagents to verify or double-check your own work. If one subagent can complete the task, use one rather than several, and keep spawn counts low.

この中の一文は第 2 節と噛み合っています — 自分の作業の再チェックにサブエージェントを使わない。同じ癖を 2 か所で塞いでいるわけです。一方は検証という行為そのもの、もう一方は仕事を投げる習慣。

もっと硬い手もあります。外側のフローが対応しているなら、起動できる分身の数をコードで上限固定してしまうこと。プロンプトは説得、足場の上限は遮断です。コストがシビアな場面では両方を併用します。

タスクに勝手に色を付ける

過剰検証に加えて、Opus 5 はタスクの範囲を自分で広げることがあります。求められていない工程を足したり、自分の判断でタスクの定義そのものを引き直したり。範囲がはっきりした狭いタスクでは、境界を書き切っておく必要があります。

ドキュメントが示すこの一段は 8 本の中で最も長く、最も凝っています。同時に 4 方向のブレを防いでおり、分解すると各文が何を管理しているか見えてきます。

この言い回しは Claude Code のデフォルトシステムプロンプトにある数段落とかなり近い書き方です（当サイトの観察で、ドキュメントは両者の関係に触れていません）。自分のプロジェクトで似た境界制約を書いたことがあるなら、照らし合わせて足りない文を補えます。

思考はデフォルトでオン、切ると 2 種類の不具合が出る

Opus 5 と前世代のあいだには、本当の仕様変更が 1 つあります。Opus 4.8 ではリクエストに thinking フィールドを書かなければ思考なし。Opus 5 では同じリクエストが思考ありで走ります。旧来の挙動に戻すには、自分で thinking: {"type": "disabled"} を書き足す必要があります。

しかもこのスイッチには条件があります。思考を切れるのは effort が high 以下のときだけ。xhigh や max と組み合わせると 400 エラーが返り、検証はリクエストごとに行われます（エラーコードとリクエスト単位の検証という 2 点は Anthropic の移行ガイド由来。段階の上限そのものはこのプロンプトガイドに書かれています）。

実際に切ると、2 種類の不具合がときどき顔を出します。1 つ目のほうが高くつきます。無言で起きるからです。

この状況はツールを頻繁に使う場面 — 検索系の仕事など — で最も起きやすくなります。2 つ目の不具合は比較的わかりやすい。<thinking> のような内部タグを、ユーザーに見える回答へ吐き出してしまうケースです。

2 つ目には直感に反する落とし穴が付いています。システムプロンプトに「考えるな」「推論するな」というルールがあるなら削除してください。この種の指示があるとタグの漏れがむしろ増えます。同じ理由で、thinking タグを名指しする書き方は汎用的な書き方に劣ります。だから下の緩和用プロンプトには、タグ名が 1 つも出てきません。

When you use a tool, you may say a brief sentence first. If no tool can express what the user asked for, say so instead of guessing. Do not include internal or system XML tags in your response.

3 つの文はそれぞれ 1 つの原因に対応しています。1 文目は「ツールを呼ぶ前に喋ってよい」と許可を与える — だから喋りたいことを呼び出しに押し込む必要がなくなる。2 文目は適切なツールがないときの逃げ道を用意し、無理に間に合わせるのを防ぐ。3 文目は汎用のタグ禁止で、特定のタグを名指ししません。

5 段階の effort の選び方と、400 が返る組み合わせ

プロンプトガイド本体は段階の推奨を一段落で流しており、完全な段階表は Anthropic の Effort ドキュメントにあります。この節の材料は主にそのページと移行ガイドから取っており、プロンプトガイドからの引き写しではありません。

Opus 5 の推奨はこうです。デフォルトの high から始め、自前の評価に沿って上下に振る。難しいコーディングと agentic な仕事は xhigh まで上げ、コストを問わない価値があるタスクはさらに max へ。一方 low と medium はどんどん使うべきで、評価で品質が保てると確認できる限り、トークンコストと応答時間を抑える第一のレバーとして扱ってください。

この出発点は前世代と異なり、取り上げる価値があります。Opus 4.8 の公式推奨は「コーディングと agentic は xhigh から」でしたが、Opus 5 では「high から」に変わりました。同じ能力一覧にはこうも書かれています — low と medium は今や、高い段階のごく一部のトークンとレイテンシで、かなり良い品質を出せる。

プロンプトキャッシュは、プロンプトのうち毎回変わらない部分を保存しておく仕組みです。次に同じ書き出しを送れば、計算し直して課金されることも、待ち直すこともありません。しきい値が 1024 から 512 に下がったので、これまで短すぎてキャッシュに載らなかったプロンプトも、この分を節約できるようになりました。

付随する動作が 3 つ。自動化フローを組んでいれば必ず当たります。1 つ目、旧モデルから移すとき、旧来の段階設定をそのまま持ち込まないこと。普段よく走らせる実タスクを一組そろえ、新旧の段階でそれぞれ回して結果を比べます。2 つ目、Opus 4.8 で思考なしで走らせていたタスクは、移行後は思考ありで走ります。max_tokens は思考と回答の合計を管理する値なので、ここを見直してください。3 つ目、段階を変えるとプロンプトキャッシュが無効になります。キャッシュに依存する長い会話では、冒頭で決めた段階を途中で変えないこと。変えるならタスクの切れ目でどうぞ。

一枚で — 古いプロンプトから何を削り、何を足すか

上の 8 節を実行可能なチェックリストに畳みます。削る 3 つを先頭に置いたのは、お金がかからず、すぐ効くからです。

本文で単独に立てなかった一段

Opus 5 は自分で以前の誤りに気づいて直します。これは良いことですが、前世代よりユーザーの前で「さっきのは間違いでした」と言いたがります。ユーザー向け製品を作るなら、この一段で訂正の実況を本当に重要なものだけに絞れます。

Only correct an earlier statement when the error would change the user's code, conclusions, or decisions. State corrections plainly and briefly, then continue the task. For slips that change nothing for the user, make the fix and move on without noting it.

このドキュメントにないもの

「回答が長い」「実況が多い」「サブエージェントに投げたがる」— どれも定性的な記述で、パーセンテージは 1 つも出てきません。前世代よりどれだけ長いのか、どれだけ多いのか、読者は予測できず、自分で比較を 1 周回すしかありません。同様に「検証指示を削ればトークンが減り、品質は落ちない」は結論として示されるだけで、比較データは付いていません。「思考をオンのまま低い段階で走らせるほうが、切るより良い」も同じく判断であって、実測値ではありません。

確かなのは 8 本のプロンプトそのものです。これはそのままコピーできる材料であり、直すか直さないかは、よく走らせるタスクで前後 1 周ずつ試せばわかります。

削る文は 2 種類、どちらも見覚えがあります。タスク単位の「最後に検証ステップを」「サブエージェントで再チェック」と、回答単位の「もう一度答えを確認する」です。

掃除するのはプロンプトだけではありません。旧モデル向けに組んだ外側のフローコード（harness。モデルの外側で、いつ何回呼ぶかを管理する層）に検証工程がぶら下がっているなら、それも一緒に外します。

Opus 5 はコードレビューの精度も網羅性も高く、思考の強さを下げても保たれます。だから、ざっと 1 周スキャンしてから詳しく 1 周、という進め方に向きます。問題は絞り込み条件をどこに書くかです。

Opus 5 は前世代より口数が多く、仕事も投げたがります。最初の反応はたいてい effort（思考の強さ。今回どれだけのトークンを使って考えるかを決めるつまみ）を下げることですが、この道は通りません。

• ユーザーに見せる回答 — 短く書くよう要求する。システムプロンプトが長いなら末尾に短いリマインダーも
• ディスクに書く文書 — レポートやファイルの分量は別の層、個別に調整
• 作業中の実況 — 望むテンポを描写する。禁止事項を並べるより良い例が効く
• サブエージェント委任（仕事の一塊を新しい分身に独立して片づけさせる仕組み。分身ごとにトークンを消費） — 本当に並列化できる大きな仕事だけ。小さい用件に分身 3 体だと、請求も待ち時間も掛け算
• タスク範囲 — 一言の意見は許すが、頼まれたとおりに完遂させる。黙って縮小・拡大・別物化させない

「訂正の言及を減らす」と「思考を切らざるを得ないとき」の 2 段を合わせ、ドキュメントはそのままシステムプロンプトにコピーできる英語のプロンプトを計 8 本示しています。本文では各段に和訳を付けました。

Opus 4.8 では thinking フィールドを書かなければ思考なし。Opus 5 では同じリクエストが思考ありで走ります。切るには手動で一文が要り、しかも effort が high 以下のときだけ許されます。

上の 3 つの数字は Anthropic の Effort ドキュメントと移行ガイド由来で、このプロンプトガイドには載っていません。「回答が長い」「サブエージェントに投げたがる」については、Anthropic はパーセンテージを 1 つも出していないので、差は自分で 1 周比べるしかありません。