Claude Opus 5でプロンプト設計はどう変わる？変更点と移行時の注意点

Anthropic は2026年7月24日、Claude Opus 5 を公開しました。

発表では、Opus 5 は Claude Fable 5 に近い知能を半分の価格で提供し、コーディングや知識労働の複数評価で最先端の性能に達したと説明されています。API料金は Opus 4.8 と同じ、入力100万トークンあたり5ドル、出力100万トークンあたり25ドルです。

ただし、今回の変化で本当に重要なのは、ベンチマークの順位だけではありません。

Opus 5 は、自ら検証し、先回りし、タスクを広げ、必要ならサブエージェントまで使うモデルです。 そのため、過去のモデル向けに積み重ねた「必ず二重チェックして」「別のエージェントにも確認させて」といった指示が、品質向上ではなく過剰検証やコスト増につながる場合があります。

この記事では、次の3つを分けて整理します。

1. 公式に確認できる能力・API・挙動の変更
2. 公開直後にSNSで報告されている初期の使用感
3. 実務でプロンプトとエージェント設計をどう見直すか

結論から言うと、Opus 5では「細かい手順を増やす」より、目的、成果物、作業範囲、権限、予算の境界を明確にすることが重要です。

Opus 5の概要

まず、公式情報から主要仕様を押さえます。

項目	Claude Opus 5
APIモデルID	claude-opus-5
入力料金	$5 / 100万トークン
出力料金	$25 / 100万トークン
コンテキスト	100万トークン（既定かつ最大）
最大出力	12万8000トークン
thinking	adaptive thinkingが既定で有効
Fast mode	約2.5倍速、基本料金の2倍
主な用途	複雑なエージェント型コーディング、長時間タスク、企業実務

Anthropic は、Frontier-Bench v0.1で Opus 4.8 の性能を2倍以上に伸ばし、CursorBench 3.2の最大effortでは Fable 5 の最高スコアに0.5%以内まで近づいたとしています。ARC-AGI 3、OSWorld 2.0、AutomationBenchなどでも、性能とタスク単価の両面を強く訴求しています。

これらはAnthropicによる評価、または初期顧客による評価です。自社のコードベースや業務で同じ改善幅が出るとは限らないため、モデル名だけを置き換えて採用を決めず、自社タスクで再評価する必要があります。

Opus 4.8から何が変わったのか

公式のOpus 5プロンプトガイド は、Opus 4.8との違いを「能力が上がった」だけでなく、プロンプト調整が必要な行動変化として説明しています。

1. 難しいタスクを最後まで完了しやすい

Opus 5は、複数ファイルにまたがる機能追加、大規模なリファクタリング、設計から実装までの一貫した作業に強いとされています。スタブやプレースホルダーを残すより、与えられた仕様を最後まで完成させる方向へ動きます。

ここで重要なのは、Anthropicが「完全なタスク仕様を最初に渡し、走らせる」使い方を勧めている点です。

一つひとつの手順をマイクロマネジメントするより、次の情報を先に揃える方が効果的です。

• 何を完成とするか
• どのファイルやシステムが対象か
• 受け入れ条件は何か
• 何を変更してはいけないか
• どこから先は人間の承認が必要か

これは、フィールフロウが取り組んでいるAI仕様駆動開発とも相性のよい変化です。仕様が曖昧なまま自由度だけを上げると暴走しやすく、仕様と境界が明確なら、細かな手順を減らしても最後まで進みやすくなります。

2. コードレビューは「広く出して、後で絞る」

Opus 5はコードレビューとバグ検出の精度・再現率が高く、追加で報告する指摘も偽陽性が少ないとされています。

一方で、レビュー用プロンプトに「重大な問題だけ報告する」「保守的に判断する」と書くと、その指示を文字どおり受け取り、報告数を減らすことがあります。

Anthropicの推奨は、最初のパスでは問題を広く報告させ、重要度による絞り込みを別パスに分けることです。

まず、重大度を限定せず、根拠のある問題をすべて列挙してください。
各指摘に、影響、再現条件、根拠となるコード位置を付けてください。

その後、別のステップで重大度と修正優先度を評価してください。

「検出」と「優先順位づけ」を分けることで、強いフィルターが発見そのものを止めるのを防げます。

3. low・medium effortでも実用性が高い

Opus 5は、low や medium effortでも比較的高い品質を保ちやすいとされています。難しいコーディングや長時間タスクでは xhigh が候補になりますが、すべてを最初から高いeffortで動かす必要はありません。

大切なのは、effortが制御するのは主に考える量であり、ユーザーに見える回答の長さではないことです。

回答を短くしたい場合は、effortを下げるだけでなく、プロンプトで出力形式と長さを指定します。

結論を先に、400字以内で答えてください。
注意点は最大3件に絞り、各項目を2文以内にしてください。

4. 画像、図表、UI理解が強くなった

Opus 5は、チャート、文書、図解の理解や、UI・フロントエンドの視覚的な再現に強いとされています。

過去のモデルで精度を補うために入れていた画像説明や回避策が、Opus 5では不要になっている可能性があります。Anthropicは、思考量だけを増やすより、画像を分析・切り抜き・再確認できるツールを与える方が費用対効果が高いと説明しています。

つまり、UIタスクでは「もっと深く考えて」だけでなく、ブラウザ、スクリーンショット、比較、再撮影という検証ループを設計する方が重要です。

5. 長い文脈と複数エージェントを扱いやすい

100万トークンのコンテキストが既定になり、長い会話でも指示追従、ツール呼び出し、推論が安定しやすいとされています。また、執筆役と検証役を分けるwriter-verifierのような複数エージェント構成も得意です。

ただし、得意であることと、毎回使うべきことは別です。

Opus 5は従来モデルよりサブエージェントへ委任しやすいため、小さなタスクでも分担を始めると、時間とトークンが一気に増えます。独立して並列化できる大きな作業だけに限定し、起動数には明示的な上限を持たせるべきです。

最重要：古い「念押しプロンプト」をそのまま移植しない

Opus 5は、指示されなくても自分の作業を検証し、間違いを見つけて修正しやすいモデルです。

そのため、過去のモデル向けに追加してきた次のような指示は、削除候補になります。

• 非自明なタスクでは必ず最終検証を入れる
• 回答前にもう一度ダブルチェックする
• 別のサブエージェントにも検証させる
• すべての可能性を網羅するまで調査を続ける

Anthropicは、明示的な再検証指示がOpus 5自身の検証行動と重なり、品質を上げずにトークンを増やす可能性があると説明しています。

これは「検証をやめる」という話ではありません。

テスト、ビルド、実画面確認、外部システムの読み戻し確認など、結果を証明する検証手段は残すべきです。削る対象は、モデルがすでに行う内省を何度も繰り返させる抽象的な念押しです。

残すべき指示は、たとえば次のようなものです。

変更後に pnpm check と対象テストを実行してください。
学習者向けの導線を変更した場合は、実画面で到達できることを確認してください。
失敗した検証は成功扱いにせず、失敗内容を報告してください。

「よく考えて確認して」ではなく、何を実行すれば完了を証明できるかを指定します。

Opus 5は作業範囲を広げやすい

Opus 5は、依頼された内容に加えて「よりよい結果に必要だ」と判断した作業まで進めることがあります。

これは、大きな機能開発では長所です。途中で必要なテストや補助コードを見つけ、自力で完成まで進められます。

しかし、文言を1か所直す、1つのMarkdownを更新する、といった狭いタスクでは、関連ファイルの全面整理や別リポジトリの調査まで始める可能性があります。

公開直後のRedditでも、計画文書の小さな修正から依頼範囲を大きく広げた、参照先として示したリポジトリだけでなく親ディレクトリの多数のリポジトリまで調べようとした、という報告が出ています。

これは、公式ガイドが説明する「作業範囲を広げやすい」という傾向と方向性が一致します。ただし、SNS上の報告は個別環境での初期体験であり、一般的な再現性が確認されたベンチマークではありません。

狭いタスクでは、次のように境界を明示します。

対象は docs/plan.md の「導入」セクションだけです。
他のファイルは参照して構いませんが、変更しないでください。
構成の全面変更や関連タスクの追加は行わず、必要なら最後に提案だけ添えてください。
依頼した修正が完了したら停止してください。

「何をするか」と同じくらい、どこまで行ったら止まるかが重要です。

Opus 5に渡すべき5つの境界

Opus 5向けのプロンプトは、長くするより、判断に必要な境界を揃える方が有効です。

1. 目的：何を終えるか

「調べて」ではなく、「比較して、採用判断に使えるメモを完成させる」まで書きます。

2. 成果物：形式と長さ

Markdown、表、コード、Issueコメントなど、最終成果物の形を決めます。回答や文書が長くなりやすいため、必要なら文字数や項目数も指定します。

3. 範囲：どこを触るか

対象ファイル、対象リポジトリ、調査期間、変更してよい領域を示します。参照は許可するが変更は禁止する、といった区別も有効です。

4. 権限：どこで止まるか

ローカル編集までは進めてよい、外部送信は確認する、削除や公開は止まる、といった境界です。能力が高いほど、可逆性と承認点を明確にする必要があります。

5. 予算：どれだけ考え、どれだけ広げるか

effort、時間、サブエージェント数、調査件数を決めます。「必要なだけ」では上限になりません。

このタスクは medium effort 相当で進めてください。
外部情報は公式資料を優先し、補助資料は最大5件に絞ってください。
サブエージェントは使わないでください。
800字以内の判断メモを完成させたら停止してください。

API移行で壊れやすいポイント

Opus 4.8からOpus 5への移行は、モデルIDの置換だけでは終わりません。migration guide には、2つの破壊的変更が明記されています。

thinkingが既定で有効になる

Opus 4.8では、thinkingを指定しないリクエストはthinkingなしで動きました。Opus 5では、同じリクエストがadaptive thinkingありで動きます。

max_tokensは、thinkingとユーザーに見える回答を合わせた総出力の上限です。以前thinkingなしで動かしていた処理は、同じ上限のままだと回答本文が途中で切れる可能性があります。

thinking無効化とxhigh・maxは併用できない

Opus 5でも thinking: { type: "disabled" } は使えますが、effortはhigh以下に限られます。xhighまたはmaxと併用すると400エラーになります。

# Opus 5: thinkingを使ってxhighで動かす
response = client.messages.create(
    model="claude-opus-5",
    max_tokens=16000,
    output_config={"effort": "xhigh"},
    messages=[{"role": "user", "content": "..."}],
)

コストを抑えたい場合も、thinkingを完全に無効化するより、thinkingを有効にしたままlowまたはmedium effortを試す方が推奨されています。

thinking無効時に出力上の乱れが現れることがある

thinkingを無効にすると、まれに次のような出力上の乱れが現れることがあります。

• 本来は構造化されたtool_useになる内容を、ただのテキストとして書く
• 内部XMLタグのような文字列を回答本文へ出す

ツールを多用する検索系ワークロードでは特に注意が必要です。可能ならthinkingを有効にし、effortでコストを調整します。

prompt cacheの最小長が512トークンになる

Opus 5では、キャッシュできるプロンプトの最小長が Opus 4.8 の1,024トークンから512トークンへ下がりました。これまで短すぎてキャッシュされなかった共通指示も、コード変更なしでキャッシュ対象になる可能性があります。

会話の途中でツールを増減できる

Opus 5の公開と同時に、会話途中のツール変更がベータ提供されました。

会話の最初に全ツールを宣言しておき、tool_additionとtool_removalで利用可能なツールをターンの途中から増減できます。tools配列そのものを変更しないため、それ以前のプロンプトキャッシュを維持できるのが利点です。

利用にはmid-conversation-tool-changes-2026-07-01ベータヘッダーが必要です。また、最初から使わせないツールにはdefer_loading: trueを指定します。

refusalを通常の終了理由として扱う

安全分類器によって拒否された場合に備え、stop_reason: "refusal"とstop_details.categoryを処理します。ベータのfallbacks: "default"を使うと、拒否カテゴリに応じてAnthropic推奨のモデルへ自動的にフォールバックできます。

なお、Opus 5ではweb fetchとPriority Tierがサポートされていません。Opus 4.8でこれらに依存している場合は、移行前に別経路を設計する必要があります。

SNSの初期反応から何を読み取るか

公開からまだ日が浅く、SNS上の評価は大きく割れています。

• トークン効率が非常によいという報告がある一方、同じスレッド内でも1回の高effortタスクで利用枠を大きく消費したという報告がある
• 小さな依頼でも調査範囲を広げすぎる、サブエージェントを増やす、長く作業するという報告がある
• コード自体は妥当でも、前提にした仕様や既定値の読み取りを誤ったという初期レビューがある

一見すると矛盾していますが、実務上の示唆は共通しています。

モデル単体の印象ではなく、effort、システムプロンプト、読み込むCLAUDE.mdやスキル、Model Context Protocol（MCP）、会話履歴、サブエージェント設定を含む実行環境全体で計測する必要があるということです。

「Opus 5は省トークン」「Opus 5はトークンを浪費する」のどちらも、現時点で一般化するのは早すぎます。

同じタスクセットを使い、少なくとも次を記録すると比較しやすくなります。

記録項目	見るポイント
成功率	受け入れ条件を満たしたか
総トークン	thinking、回答、tool_resultを含むか
所要時間	最終成果物までの時間
ツール呼び出し	必要な呼び出しと寄り道を分ける
変更範囲	依頼外のファイルを触っていないか
人間の手戻り	修正、差し戻し、事実確認にかかった時間

モデルの利用料金だけでなく、人間が戻すために使った時間まで含めることが重要です。

既存プロンプトをどう書き換えるか

従来のエージェント向けプロンプトが、次のようになっていたとします。

このリポジトリを詳しく調べて、必要な修正をすべて実施してください。
必ず何度も検証し、別のサブエージェントにも確認させてください。
改善できるところがあれば、あわせて修正してください。
最後にもう一度すべてを確認してください。

Opus 5では、これを単純に強い指示として受け取ると、範囲が広がり、検証が重複し、複数エージェントが動く可能性があります。

次のように、完了条件と境界へ書き換えます。

目的:
Issue #123の受け入れ条件を満たす最小の変更を完成させる。

範囲:
- 変更可能: src/auth/ と関連テスト
- 参照のみ: docs/architecture.md
- 対象外: 依存関係更新、命名の全面整理、別Issueの修正

成果物:
- 実装
- 追加または更新したテスト
- 400字以内の完了報告

検証:
- pnpm check
- pnpm test auth
この2つの結果を完了証拠とする。

権限と停止条件:
- 破壊的変更や外部送信は行わない
- 別の設計解釈で成果が大きく変わる場合だけ確認する
- 受け入れ条件と上記検証を満たしたら停止する

予算:
- サブエージェントは使わない
- 関係のない改善は提案だけに留める

プロンプトが短くなるとは限りません。しかし、抽象的な念押しが減り、モデルが判断に使える境界が増えています。

フィールフロウでの実務判断

Opus 5は、日常のすべてのタスクをxhighで置き換えるモデルではありません。

まず試す価値が高いのは、次のような仕事です。

• 複数ファイルにまたがる機能開発
• 原因が深い不具合の調査
• 大規模なコードレビュー
• 長い仕様書と既存実装をつなぐ作業
• スプレッドシート、資料、図表をまたぐ分析
• ブラウザやテストを使って最後まで完了できるエージェント作業

一方、文言修正、単純な変換、短い要約などでは、lowまたはmedium effort、あるいは別の軽量モデルで十分な可能性があります。

導入時は、次の順番が安全です。

1. 代表タスクと受け入れ条件を固定する
2. Opus 4.8とOpus 5を同じ条件で比較する
3. low、medium、highを順に試す
4. 古い検証指示を外した版も比較する
5. スコープ逸脱と人間の手戻りを計測する
6. 効果が出るタスクだけOpus 5へ寄せる

特に、公開、送信、削除、課金、権限変更のような戻しにくい操作は、モデルの自己検証能力が上がっても、人間の承認境界を残すべきです。

まとめ

Claude Opus 5は、Opus 4.8と同じAPI料金で、難しいコーディング、長時間のエージェント作業、コードレビュー、画像・文書理解を大きく強化したモデルです。

しかし、能力が上がったことで、プロンプト設計の注意点も変わりました。

• thinkingは既定で有効になった
• effortと回答の長さは別に制御する
• 「必ず再検証」のような念押しは重複しやすい
• 狭いタスクでは作業範囲と停止条件を明示する
• サブエージェントの利用条件と上限を決める
• thinking無効時の出力、refusal、prompt cache最小長を確認する
• 自社のタスクでコスト、時間、手戻りを再計測する

Opus 5に必要なのは、より長い命令書ではありません。

能力を信頼して任せながら、目的、成果物、範囲、権限、予算の境界を設計すること。

プロンプトエンジニアリングは、モデルを細かく誘導する技術から、強いエージェントが安全に完了できる仕事の枠を設計する技術へ移りつつあります。

参考

• Introducing Claude Opus 5 - Anthropic
• Prompting Claude Opus 5 - Claude Platform Docs
• Migration guide - Claude Platform Docs
• What’s new in Claude Opus 5 - Claude Platform Docs
• Mid-conversation system messages and tool changes - Claude Platform Docs
• Models overview - Claude Platform Docs
• Pricing - Claude Platform Docs
• Opus 5 is way too eager - Reddit
• Opus 5 Token Usage is Amazing - Reddit
• Opus 5 First Impressions (vs Fable) - Reddit