Claude Opus 5 プロンプト書き換え術【2026年7月】

「Opus 5に切り替えたら、Claude Codeの返答が急に長くなったんですけど、壊れました？」——先週から今週にかけて、複数のクライアント先で同じ相談を受けました。壊れてはいません。むしろ公式ドキュメントに、この挙動変化がはっきり明記されています。

Uravationでは法人向けにClaude Code・Claude APIの研修と個別指導を行っていますが、モデルが変わるたびに「システムプロンプトやCLAUDE.mdの何を直せばいいのか」という質問が必ず出ます。今回のOpus 5は、Opus 4.8までとAPIレベルの挙動が変わった珍しいケースで、Anthropicも専用のプロンプトガイド（Prompting Claude Opus 5）を公式に公開しているほどです。それだけ「そのまま流用すると事故る」箇所が多いということです。

この記事では、Opus 5の使い方や料金そのものではなく、「Opus 4.8時代のプロンプトを、Opus 5でどう書き換えるべきか」だけに絞って整理します。thinking・effort・検証指示・サブエージェント委譲・応答の長さという5つの論点について、公式ドキュメントに書かれている挙動変化と、書き換え前→書き換え後のプロンプト例をセットで紹介します。

Opus 5そのものの機能・料金・使い方はClaude Opus 5の使い方｜effort設定と1M活用で、発表内容の全体像はClaude Opus 5登場｜料金据え置きで最高性能にで解説済みです。本記事はその続編として、プロンプト設計だけを深掘りします。数字・仕様・挙動は全てAnthropic公式ドキュメント（Prompting Claude Opus 5 / What’s new in Claude Opus 5 / Effort）の記載に基づいており、公式に記載のない挙動は「公式未記載」と明記します。

Opus 4.8→Opus 5で変わった5つのポイント（まず一覧で）

プロンプトの書き換えに入る前に、何が変わったのかを一覧にします。すべてAnthropic公式ドキュメントの記載です。

コンテキスト長・料金・チャネル別の使い方など、モデル全体の仕様はClaude Opus 5の使い方｜effort設定と1M活用にまとめているので、ここでは上記5点のうち「プロンプトの書き換えが必要になる部分」だけを深掘りします。

【書き換え前→書き換え後】プロンプト対比表

まず全体像を対比表で見てください。詳細な理由と実際のプロンプト例は、この後のセクションでひとつずつ解説します。

① 検証指示を消す — Opus 5は言われなくても検証する

個別指導の現場で一番多いのがこのパターンです。多くの企業のCLAUDE.mdや社内プロンプト集には「最後にテストを実行して検証すること」「サブエージェントを使って自分の作業をダブルチェックすること」という一文が、いわば”お守り”として入っています。Opus 4.8までは有効な指示でしたが、Opus 5にはこの一文がそのまま裏目に出ます。

Anthropic公式のプロンプトガイドは、この点をかなりはっきりと書いています。

“Claude Opus 5 verifies its own work without being told to. If your prompt contains explicit verification instructions (“include a final verification step for any non-trivial task,” “use a subagent to verify”), remove them: instructions like these cause over-verification on Claude Opus 5, and removing them reduces wasted tokens with no loss in quality.”

日本語で意味を取ると「Opus 5は指示されなくても自分の作業を検証する。プロンプトに明示的な検証指示（”重要なタスクには必ず最終検証ステップを入れて” “サブエージェントで検証させて”）が含まれている場合は削除すること。この種の指示はOpus 5では過剰検証を引き起こし、削除すれば品質を落とさずに無駄なトークンを減らせる」ということです。

タスクの範囲（スコープ）についても、同様に明示的な歯止めが必要になっています。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.

「double-checkして」「re-verifyしてから答えて」といった、間違いを見つけたときの言い直し方に関する指示も同様です。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.

Uravationの生成AI研修についてはAIエージェント活用ガイドで全体像をまとめているので、CLAUDE.mdの設計自体から見直したい場合はあわせてご覧ください。

② effortパラメータで思考の深さをコントロールする

Opus 5ではeffortパラメータが5段階（low / medium / high / xhigh / max）に揃い、公式ドキュメントは「デフォルトのhighから始めて、自社の評価結果に応じて上下させる」ことを推奨しています。特筆すべきは、low・mediumでも品質が大きく落ちない効率の良さが向上している点です。

Opus 4.8向けに「まずxhighから始めて、必要なら下げる」という運用をしていたチームは要注意です。公式ガイドはOpus 5について「まず既定のhighから始め、評価結果を見てxhigh・maxに上げる」という逆方向の順序を推奨しています。旧モデルのeffort設定をそのまま引き継がず、自社の評価（eval）で再検証することが公式にも明記されています。

effortをmaxまで上げるリクエストの例（公式ドキュメントより）です。

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-opus-5",
    "max_tokens": 64000,
    "stream": true,
    "output_config": {
      "effort": "max"
    },
    "messages": [
      {
        "role": "user",
        "content": "Explain why the sum of two even numbers is always even."
      }
    ]
  }'

重要な注意点があります。公式ガイドは「effortは思考の”量”を制御するものであり、応答の”長さ”を制御するものではない」とはっきり書いています。「effortを下げれば返答も短くなるはず」という思い込みでeffortだけ触っても、ユーザーに見える返答の分量はあまり変わりません。返答の長さを変えたいときは、後述する⑤の分量指示を別途プロンプトに書く必要があります。

③ thinking無効化のルールが変わった — xhigh/maxでは400エラーになる

これはAPI連携をしているエンジニアが最も踏みやすい落とし穴です。Opus 4.8では、thinkingの有効・無効はeffortの値と無関係に自由に設定できました。Opus 5ではこの前提が崩れています。

“On Claude Opus 5, thinking: {“type”: “disabled”} is accepted only when the effort level is high or below. Setting thinking: {“type”: “disabled”} with effort xhigh or max returns a 400 error.”

つまり「thinkingを無効化しつつ、effortはxhighやmaxのまま」というOpus 4.8時代の組み合わせは、Opus 5では通信エラー（400）になります。Anthropic自身がこれを”breaking change”（破壊的変更）と明記しています。バッチ処理やCI/CDに組み込んだプロンプトで、この組み合わせを固定値として持っていないか確認してください。

公式の推奨は「thinkingを無効化するのではなく、有効なまま低いeffortでトークンコストを抑える」という方向転換です。実際、公式ガイドには次の一文があります。

“For most tasks, thinking enabled at low effort performs better than thinking disabled at similar cost.”

それでもthinkingを無効化した運用を続けなければならない場合、公式は2つの副作用（ツール呼び出しが構造化されずテキストに混入する／内部の<thinking>のようなXMLタグが応答に漏れる）が起きうると明記しています。この副作用を軽減するための指示文がこちらです。

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.

公式は「thinkingタグの名前を名指しで禁止する指示（例：”thinkingタグを出力しないで”）はかえって漏洩を増やす」とも書いています。上記のような一般的な言い回しにとどめるのがポイントです。

④ サブエージェントを勝手に増やさせないプロンプト設計

Claude Code研修の受講者から「Agent Teams機能を使わせたら、指示していないのに複数のサブエージェントを勝手に立ち上げていた」という声を、今回のOpus 5切り替え後に複数聞くようになりました。公式ドキュメントも、Opus 5は複数エージェントの協調が上手くなった一方で、「委譲のしやすさ」自体が上がったと明記しています。

“Claude Opus 5 delegates to subagents more readily than prior models. Delegation pays off on genuinely independent, sizeable tracks of work, but it multiplies cost and time when applied to small tasks.”

コストを気にする用途では、委譲していい条件を明示的に絞るか、上限を決めるべきだと公式は推奨しています。ガイドに掲載されている指示文はこちらです。

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.

この一文の最後、「do not use subagents to verify or double-check your own work（自分の作業をサブエージェントに検証させない）」は、①で紹介した「検証指示を消す」原則ともつながっています。Opus 4.8時代に「品質担保のためにサブエージェントで再確認させる」設計にしていたワークフローは、Opus 5では二重に無駄なコストを生む組み合わせになるため、優先的に見直してください。

⑤ 応答が長くなる・喋りすぎるOpus 5を制御する3つの型

公式ドキュメントは「Opus 5のデフォルトの応答は、以前のOpusモデルより長くなる」「エージェント的な作業中に、次に何をするか宣言する頻度が増える」「ディスクに書き出すファイル（レポート・Markdownドキュメント・要約）も長くなりがち」という3つの変化を挙げています。それぞれに対応する指示のパターンが公式ガイドに用意されています。

型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：エージェント作業中の進捗報告の頻度を決める

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.

型3：ファイルに書き出す成果物（レポート・議事録等）の分量を絞る

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つとも共通するのは「何をするな」ではなく「どう振る舞ってほしいか」を具体的に書く形式です。公式ガイドも「ナレーションを増やしたい場合も、”〜しないで”という否定形より、欲しい発話の例を見せる方が効きやすい」と補足しています。

実装者向け：max_tokens・prompt cache・関連の新機能

プロンプト文面以外にも、API連携部分で見直すべき設定変更が公式ドキュメントに記載されています。

• max_tokensの見直し：thinkingが既定ONになったため、max_tokensは「thinking＋応答テキストの合計」に対する上限として効いてきます。Opus 4.8でthinkingなしで運用していたワークロードは、この上限に達しやすくなっている可能性があるため見直しが必要です。
• prompt cacheの最小長：キャッシュ可能な最小プロンプト長がOpus 4.8の1,024トークンから512トークンに下がりました。以前は短すぎてキャッシュされなかったプロンプトも、コード変更なしでキャッシュ対象になる場合があります。
• mid-conversation tool changes（ベータ機能）：会話の途中でツール一覧を追加・削除しても、プロンプトキャッシュを維持できる機能です。利用するにはmid-conversation-tool-changes-2026-07-01というベータヘッダーをリクエストに含める必要があります。
• Fast mode（リサーチプレビュー）：Claude APIでのみ利用可能で、Amazon Bedrock・Google Cloud・Microsoft Foundryでは現時点で提供されていません。料金は入力$10／出力$50（100万トークンあたり）です。

これらの詳しい料金体系・チャネル別の可否はClaude Opus 5料金完全ガイド｜日本円換算と損益分岐で確認できます。

日本語運用での注意点

ここまで引用したAnthropic公式ドキュメントは、いずれも英語の指示文で例を示しています。これは公式ドキュメント自体が英語で書かれているためで、日本語運用における効果差についてAnthropicが個別に検証結果を公表しているわけではありません。ここから先は、Uravationが日本企業のClaude Code・Claude API運用を支援してきた実務上の考え方であり、公式の断定ではない点を明確にしておきます。

Claudeは英語のシステムプロンプトと日本語のユーザー入力・出力が混在する構成にも対応できるため、上記の英語プロンプト例をCLAUDE.mdやシステムプロンプトにそのまま貼り付けても機能上の問題はありません。日本語チームで運用ルールとして共有したい場合は、指示の”意図”を保ったまま日本語に訳して構いません。例えば①の検証指示削除ルールを日本語のCLAUDE.mdに反映するなら、次のように書き換えるイメージです。

# Opus 5移行時のCLAUDE.md調整（日本語チーム向け例）
- 「最後に検証ステップを入れる」「サブエージェントで再確認する」という指示は
  記載しない（Opus 5は指示なしで自己検証するため、二重指示は無駄なトークン
  消費につながる）
- タスクの範囲を明確に絞りたい場合のみ、「依頼された範囲だけを実行し、
  判断が分かれる場合のみ確認を挟む」と明記する
- 簡潔な応答が必要な場面では、「前置き・免責は短く、結論から書く」と
  明記する（effortを下げても応答の長さそのものは変わらないため）

断定できるのはあくまで「公式ドキュメントに書かれている英語圏での挙動変化」までです。日本語プロンプトで同じ変化がどの程度の強さで再現されるかは、各社の評価（eval）で確認することをおすすめします。

法人向け：社内プロンプト集・CLAUDE.mdの更新チェックリスト

Opus 4.8からOpus 5へ切り替える際、社内のプロンプト集・CLAUDE.md・システムプロンプトを棚卸しするならこの順番で確認してください。

【要注意】書き換え時によくある失敗パターン

失敗1：検証指示を「念のため」残してしまう

❌ 悪い例：「Opus 5は自己検証するらしいけど、念のため今まで通り検証指示も残しておこう」と両方入れる。
⭕ 良い例：公式が明記している通り、検証指示は削除する。品質は落ちず、無駄なトークン消費だけが減る。

失敗2：xhigh/maxのままthinkingを無効化しようとしてAPIエラーになる

❌ 悪い例：Opus 4.8時代の設定をそのまま流用し、thinking: {"type": "disabled"}とeffort: "xhigh"を同時に指定して400エラーを受け取る。
⭕ 良い例：thinkingは有効なままeffortだけで調整する。無効化したい場合はeffortをhigh以下に下げる。

失敗3：effortを下げれば返答も短くなると思い込む

❌ 悪い例：応答が長すぎるのでeffortをlowに下げたが、応答の分量はほとんど変わらず驚く。
⭕ 良い例：effortは思考の量を制御するもの。応答の長さを変えたい場合は、別途「簡潔に」という明示的な指示を加える。

失敗4：thinkingタグの名前を名指しで禁止する

❌ 悪い例：thinking無効化時のタグ漏洩を防ごうと「thinkingタグを出力しないでください」と名指しで禁止する。
⭕ 良い例：公式ガイドの一般的な言い回し（「内部的・システム的なXMLタグを応答に含めないこと」）にとどめる。名指しの禁止指示はかえって漏洩を増やすと公式が明記している。

よくある質問（FAQ）

Q. Opus 4.8向けのプロンプトはOpus 5でそのまま使えますか？

公式ドキュメントによれば「既存のOpus 4.8向けプロンプトでも、そのまま高い性能を発揮する」とされています。ただし、検証指示・thinking無効化とeffortの組み合わせ・max_tokensの3点は、そのまま使うと非効率またはエラーの原因になるため、本記事で紹介した箇所だけは個別に見直すことを推奨します。

Q. thinkingを無効化する必要がある場合、effortはどうすればいいですか？

Opus 5ではthinking: {"type":"disabled"}はeffort: "high"以下でのみ有効です。xhigh・maxeffortで動かしたいタスクでthinkingを無効化することはできません。公式は「無効化するより、有効なまま低いeffortでコストを抑える方が同等以上の性能になりやすい」としています。

Q. effortとthinkingは何が違うのですか？

公式ドキュメントでは、thinkingパラメータは「応答前にthinkingブロックで考えるかどうか」を制御し、effortパラメータは「応答全体（thinking込み）にどれだけの労力をかけるか」を制御する、と整理されています。adaptiveモードが使える場合は、thinkingの深さを調整する手段としてeffortを使うことが公式に推奨されています。

Q. 検証指示を消すと品質が落ちませんか？

公式ドキュメントは「削除しても品質の低下はなく、無駄なトークン消費が減る」と明記しています。Opus 5は指示なしでも自分の作業を検証する挙動を持つため、明示的な検証指示は同じ検証を重ねて行わせているだけの状態になりやすい、という理屈です。

Q. Claude Code（CLAUDE.md）でも同じ書き換えが必要ですか？

公式のOpus 5挙動変化（自己検証・サブエージェント委譲・応答の長さ・進捗報告）は、APIに限定した記載ではなく「モデルの挙動」として説明されているため、Claude Codeのようなエージェント環境でも同様の傾向が見られます。CLAUDE.mdやプロジェクト設定に検証指示・サブエージェント指示を書いている場合は、本記事のチェックリストに沿って見直すことをおすすめします。

まとめ：今日から始める3つのアクション

1. 今日やること：CLAUDE.mdやシステムプロンプトから「検証してください」「サブエージェントで再確認して」の一文を探し、削除するか条件を絞る
2. 今週中：thinking: {"type":"disabled"}とeffort: "xhigh"／"max"の組み合わせが残っていないかAPI連携部分を確認し、max_tokensも見直す
3. 今月中：法人向けチェックリストの7項目を使って、社内のプロンプト集全体を棚卸しし、Opus 4.8時代のeffort設定を自社evalで再検証する

より広くClaude Codeのプロンプト設計を体系的に学びたい場合はClaude Codeプロンプト集30選｜コピペで使えるを、Fable 5世代のプロンプトと比較したい場合はClaude Fable 5 プロンプト50選もあわせてご覧ください。社内プロンプト集の刷新を伴走支援してほしい場合は、Uravationの生成AI研修・Claude Code個別指導でも具体的な業務プロンプトへの落とし込みを支援しています。

参考・出典

• Anthropic Claude Docs「Prompting Claude Opus 5」（2026年7月25日参照）
  https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5
• Anthropic Claude Docs「What’s new in Claude Opus 5」（2026年7月25日参照）
  https://platform.claude.com/docs/en/about-claude/models/whats-new-opus-5
• Anthropic Claude Docs「Effort」（2026年7月25日参照）
  https://platform.claude.com/docs/en/build-with-claude/effort
• Anthropic Claude Docs「Migration guide」（2026年7月25日参照）
  https://platform.claude.com/docs/en/about-claude/models/migration-guide

佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載7回執筆（NewsPicks最大1,125ピックス）。