Anthropicが、Claude Opus 5専用のプロンプトガイドを公開しています[1]。読んで驚くのは、書いてあることの多くが「こう書け」ではなく「その指示を消せ」だという点です。
理由ははっきりしています。Opus 5は言われなくても自分の作業を検証し、間違いに気づいて直します。そこに「最後に検証して」「ダブルチェックして」と書き足すと、同じことを二重にやってトークンだけが増える。公式はこれを「過剰検証（over-verification）」と呼び、削れば品質を落とさずに無駄が減ると明記しています。
この記事では、公式ガイドからそのまま貼って使えるプロンプトを9本取り出し、なぜそう書くのかを添えて整理します。分かること——①ガイド全体を貫く2つの原則 ②「長さ」の制御が2種類あること ③作業範囲とコストの縛り方 ④思考を切って運用する場合の逆説的な直し方 ⑤能力を引き出す渡し方。内容はすべてAnthropicの公式ドキュメントに基づくもので、CAG自身が検証したものではありません（出典は脚注）。プロンプト例は日本語訳と英語原文を併記します。
関連記事 ｜ モデルそのものの解説はこちらClaude Opus 5を、分かりやすく ──価格据え置きで世代交代、倍の値段の最上位モデルを上回った新モデルを解説
→
01 このガイドが言っていること
前提として、公式は「Opus 5は既存のOpus 4.8向けプロンプトのままでも十分に動く」と書いています[1]。作り直しは要りません。そのうえで、調整したくなる振る舞いが6つ挙がっています。
| 変わった振る舞い | 何が起きるか | 打ち手 |
|---|---|---|
| 回答が長くなる | 会話の返答が前世代より冗長になる | 長さをプロンプトで明示（04章） |
| 進捗をよく喋る | 作業中の実況が増える | 報告の頻度と形を書く（03章） |
| 書き出す文書が長い | レポートやMarkdownが膨らむ | 文書の長さを別に指定（04章） |
| 自分で検証する | 検証指示と重なって二度手間 | 検証指示を消す（02章） |
| 作業範囲を広げる | 頼んでいない手順を足す | 範囲を明示して縛る（05章） |
| サブエージェントに振る | 小さな仕事でも下請けを立てて割高に | 委譲の条件を書く（05章） |
サブエージェントとは、メインのAIが作業の一部を切り出して別のAIに任せる仕組みのことです。並行して進められる反面、動かした数だけ費用と時間がかかります。
あわせて、能力が上がったことで「渡し方」が変わった点も3つ挙がっています[1]。
コーディングでは、Opus 5は複数ファイルにまたがる機能追加や大きめのリファクタが最も得意で、仕様を最初にまとめて渡し、そのまま走らせきるのが一番強いと書かれています。途中で書きかけ（スタブや仮置き）を残さず終わらせる、とも明記されています。小刻みに指示を分けるより、要件を出し切ってから任せる形が合います。
画像・図の読み取りでは、グラフや書類の理解、UIの再現が強くなりました。ここで効くのは思考量を増やすことではなく、自分で拡大したり切り出したりして見直せる道具を渡すことです。公式は「道具のほうが、思考だけよりも費用対効果の高いレバーだ」と書いています。前のモデル向けに作った画像まわりの回避策は、まだ要るか見直すよう促されています。
資料作成では、複雑な数式入りの複数シート表計算や、構成のしっかりしたスライドを作れるようになりました。ここは逆にスタイルやテンプレートを渡すことが要ります。
02 原則①：足すより、削る
ガイドの中心にある考え方です。モデルが自分でやることを、プロンプトで重ねて命じない。
消すもの①：検証を命じる指示。「重要なタスクでは最後に検証ステップを入れて」「サブエージェントを使って確認して」。公式は「こうした指示はOpus 5で過剰検証を招く。削れば、品質を落とさずに無駄なトークンが減る」と書いています。プロンプトだけでなく、AIを動かす仕組み（ハーネス）側に昔から入っている検証ステップも同じだと明記されています。
消すもの②：再チェックを命じる指示。「答えをダブルチェックして」「返信前に再確認して」。Opus 5は自分の間違いをよく捕まえて直すので、これらは自身の動きと重なって費用だけが増えます。
消すもの③：レビューでの「重大なものだけ報告して」。 これは少し意外かもしれません。Opus 5はコードレビューの精度が上がり、追加で挙げてくる指摘も多くが本物のバグになりました。そこで「保守的に」「重大な問題だけ」と書くと、モデルが文字どおり受け取って報告を減らしてしまいます。公式の推奨は、全部報告させて、絞り込みは別のパスでやること。
削るのが基本ですが、1つだけ足したほうがよいものがあります。修正の実況を減らす指示です。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.
03 原則②：禁止より、実例で示す
もう1つの原則です。ガイドは進捗報告の項でこう書いています。「してほしくないことについての指示よりも、してほしいコミュニケーションの仕方を実際に示した例のほうが効きやすい」[1]。
これは細かい注意書きに見えて、ガイド全体の設計に効いています。進捗報告を減らしたいときも、「実況するな」ではなく報告の頻度と形を描写する書き方になっています。
最初のツール実行の前に、これから何をするかを一文で言うこと。作業中は、重要な発見があったときか方針を変えるときだけ、短く報告する。終わったら結果から述べる——最初の一文で「何が起きたか」「何が分かったか」に答え、詳しく知りたい読者のための補足はその後に置く。
原文：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.
見落とされやすいのは、このレバーは逆向きにも使えることです。ガイドは「実況を増やしたい、あるいはスタイルを変えたい場合も、同じレバーが逆方向に効く」と書いています。つまりこれは「うるさいAIを黙らせる設定」ではなく、報告の作法を指定する枠です。作業を見せて安心させたい製品なら、増やす方向に書けばよいことになります。
そして増やす場合こそ、禁止形より実例が効きます。「もっと丁寧に報告して」と書くより、望ましい報告文をそのまま1つ書いて見せるほうが確実です。
04 「長さ」は2種類ある
ここは実務でよく取り違えるところです。会話の回答の長さと、書き出すファイルの長さは別々に指定する必要があります。
しかも前提として、公式はeffort（AIが使うトークン量の設定）では回答は短くならないと明言しています[3]。effortが決めるのは考える量であって、喋る量ではありません。長さはプロンプトで指示するしかない、ということです。
回答は要点に絞って簡潔に。免責や注意書きは短くし、大部分を本題に使うこと。説明を求められたときは、詳しい解説を明示的に求められない限り、高いレベルの要約を返す。
原文：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>
出力はほどほどに簡潔に。
</tone_preference>
原文：<tone_preference> Keep outputs reasonably concise. </tone_preference>
これは内容というより構造の話です。システムプロンプトが長いとき、冒頭に書いた方針は薄れます。公式は「長いシステムプロンプトでは、指示に短いリマインダーをプロンプト末尾付近で添えよ」と書いています。同じことを2箇所に置くのは冗長に見えますが、長い指示書では効きます。
書き出す文書の長さは、そのタスクに必要な分量に合わせること。中身は網羅しつつ、埋め草の節・重複した要約・定型文で水増ししない。
原文：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.
Opus 5がディスクに書き出すファイル（レポート、Markdown、要約）は前のモデルより長くなる、と明記されています。AIに文書を書かせる製品を持っているなら、この1行を入れておく価値があります。
05 範囲とコストを縛る
Opus 5は放っておくと仕事を広げます。頼んでいない手順を足したり、「本来こうあるべきだ」という自分の判断を適用したりする。狭いタスクでは明示的に縛ります。
頼まれたことを、意図された範囲で仕上げること。ありふれた判断は自分で下し、解釈の違いで成果物が大きく変わる場合にだけ確認する。依頼が誤っていそうな場合や、より良い方法がある場合は、一文でそれを述べたうえで、依頼どおりの作業を続ける——黙って範囲を狭めたり広げたり作り替えたりしない。タスクは最後までやり切り、明らかに依頼を超える操作は行わない。
原文：Deliver what was asked, at the scope intended. Make routine judgment calls yourself, and check in only when different readings of the request would lead to materially different work. If the request seems mistaken or a better approach exists, say so in a sentence and continue with the task as asked rather than quietly narrowing, widening, or transforming it. Finish the whole task, and stop short of actions that are clearly beyond what was asked.
この一本はよくできていて、「勝手に広げるな」と「勝手に縮めるな」を同時に縛っています。範囲を固定しようとすると、たいていAIは安全側に寄って手を抜くほうへ倒れますが、その逃げ道も塞いであります。
もう1つがサブエージェントです。Opus 5は前のモデルより気軽に下請けへ振ります。本当に独立した大きな作業なら得ですが、小さな仕事に使うと費用と時間が倍々に増えます。
サブエージェントへの委譲は、本当に独立していて並行処理でき、かつ規模の大きい作業のときだけ行うこと（例：多数のファイルにまたがる広い調査）。自分で数回のツール実行を終えられる作業は委譲しない。自分の作業の検証やダブルチェックのためにサブエージェントを使わない。1つのサブエージェントで足りるなら複数立てず、起動数は低く抑える。
原文：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.
ここでも02章の原則が顔を出しています。「検証のためにサブエージェントを使うな」——自分でやることを、下請けを立ててまで重ねさせない。公式は、プロンプトで書く代わりに起動できる数に固定の上限を設けるという手も挙げています。
関連記事 ｜ 決めた指示をどこに置くかプロンプトとスキルは、もう「メモ」じゃない ──AIへの指示を"本番資産"として管理し始めた各社
→
06 思考を切るなら、「禁止」でなく「許可」で直す
最後は少し変わった話です。Opus 5は思考（thinking）が既定でONで、切れるのはeffortが high 以下のときだけです[2]。そのうえで公式は「できる限り思考は有効なままにして、コストはeffortを下げて抑えよ」と勧めています。
それでも切らざるを得ない場合、副作用が2つ出ることがあります。
副作用①：ツール呼び出しが本文テキストとして漏れる。 構造化されたツール呼び出しの代わりに、その内容をユーザー向けの文章として書いてしまいます。呼び出しは実行されないまま会話は正常に終わり、エージェントの履歴にそのゴミが残るので後続のターンにも影響します。検索など、ツールを多く使う処理で起きやすいと書かれています。
直し方が面白いところです。禁止するのではなく、喋る許可を与えます。
ツールを使う前に、短い一文を述べてかまいません。
原文：You may say a brief sentence before using a tool.
副作用②：内部タグが回答に混ざる。 <thinking> などのタグが表に出ます。注意点は2つあって、まず「考えるな」「推論するな」というルールがシステムプロンプトにあるなら削ること（かえってタグの漏れが増えます）。そして、指示を書くなら一般形にすることです。
回答に、内部タグやシステムタグを含めないこと。
原文：Do not include internal or system XML tags in your response.
公式は「タグ名を名指しする指示は、一般形より効きが悪いので避けよ」と書いています。「<thinking> を出すな」と書くと、かえってそれを意識させてしまう、ということです。02章・03章と同じ方向——モデルの内部の動きを、名指しで禁じにいかない。
貼れるプロンプト一覧
| # | 目的 | 章 |
|---|---|---|
| 01 | 訂正の実況を抑える | 02 |
| 02 | 進捗報告の頻度と形を決める | 03 |
| 03 | 会話の回答を短くする | 04 |
| 04 | 長いシステムプロンプトの末尾に置くリマインダー | 04 |
| 05 | 書き出す文書の長さを決める | 04 |
| 06 | 作業範囲を固定する | 05 |
| 07 | サブエージェントの濫発を止める | 05 |
| 08 | （思考OFF時）ツールの前に一言喋る許可 | 06 |
| 09 | （思考OFF時）内部タグを出させない | 06 |
使う前チェックリスト
- プロンプトから「最後に検証して」「ダブルチェックして」を消したか
- ハーネス側に昔から入っている検証ステップも消したか
- レビュー用プロンプトの「重大なものだけ報告」を外し、絞り込みを別パスに移したか
- 会話の長さと、書き出す文書の長さを別々に指定したか
- 長いシステムプロンプトなら、末尾にも短いリマインダーを置いたか
- 作業範囲の固定に「勝手に縮めるな」も入っているか
- サブエージェントの委譲条件を書いたか（または起動数に上限を設けたか）
- 「考えるな」「推論するな」というルールが残っていないか
- 画像まわりで、前のモデル向けに作った回避策が残っていないか
読み終えて残るのは、書き足すコツより引き算の感覚のほうです。モデルが自分でやるようになったことを、プロンプトで重ねて命じない。禁止で塞がずに、望ましい形を実例で見せる。
AIの使い方を設計から見直したいなら
電脳技巧集団（AI職人ギルド）では、AIを使った開発・自動化のご相談を受け付けています。「どう指示するか」より前の、どこに使うかから一緒に整理します。お問い合わせはこちら
出典・注記
- Anthropic公式ドキュメント「Prompting Claude Opus 5」https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5
- Anthropic公式ドキュメント「What's new in Claude Opus 5」https://platform.claude.com/docs/en/about-claude/models/whats-new-opus-5
- Anthropic公式ドキュメント「Effort」https://platform.claude.com/docs/en/build-with-claude/effort
- プロンプト例の日本語は、原文（英語）をCAGが訳したものです。原文も併記しています。効果に関する記述はすべてAnthropicの公式ドキュメントに基づくもので、CAG自身が検証したものではありません。
