ほとんどの移行ガイドはコードで何が壊れるかを説明しています。本記事では、プロンプトで何が壊れるかを扱います。
Claude Opus 5は2026年7月24日にリリースされ、Anthropicはそれに合わせて専用のプロンプトガイドを公開しました。このガイドでは、Opus 4.8では有効だった一部の指示が、Opus 5では悪影響を及ぼすことが説明されています。
影響は微妙なものではありません。コストが増え、出力が冗長になり、場合によってはエージェントループが機能しなくなります。
理由は単純です。Opus 5は、以前は明示的に指示する必要があった検証や自己説明を、すでに自力で行います。古いプロンプトで同じ挙動を重ねて指示すると、精度が上がるのではなく、検証や説明が二重化されます。
この記事では、Opus 5向けにシステムプロンプトを更新するための、コピー＆ペースト可能なスニペットを紹介します。また、thinkingを無効にした場合に発生する、エージェントループを壊し得る2つの失敗モードも扱います。
コードレベルの変更については、Opus 4.8からOpus 5への移行ガイドを参照してください。同じプロンプトを異なる設定で実行し、リクエスト・レスポンスの差分を比較するには、Apidogが利用できます。
一行の要約
Opus 5はOpus 4.8よりも、検証し、記述し、委任し、自己説明します。
Opus 4.8向けのプロンプトは、モデルをこれらの挙動へ誘導するためのものでした。Opus 5では、同じ指示がモデルを必要以上に押し進めます。
対応は加算ではなく減算です。多くの場合は指示を追加せず、古い指示を削除します。追加すべきものは、短さ・範囲・委任数を制御する制約です。
1. 検証指示を削除する
最も重要な変更です。
Anthropicによると、Opus 5は指示されなくても自身の作業を検証します。出力を再読し、計算を確認し、テストを再実行し、見落としたエッジケースを探します。
Opus 4.8では、次のような指示をプロンプトに含めることが一般的でした。
Double-check your work before responding.
Verify each step before moving to the next one.
Review your answer for errors, then revise it.
Check your reasoning carefully.
Make sure the output is correct before returning it.
Opus 5でこれらを残すと、モデルはデフォルトの検証に加えて、プロンプトで要求された検証も実行します。長時間動作するエージェントでは、この重複がトークン消費と請求額に直接影響します。
まず、システムプロンプトから上記のようなグローバル検証指示を検索して削除してください。
特定の重要ステップだけを検証したい場合は、例外を局所化します。
Do not add general verification passes; you already verify by default.
The only exception: after writing the migration SQL, run it against the
schema dump once and report any mismatch. Do not re-verify anything else.
重要なのは、検証対象を限定することです。
- 悪い例: すべてを常に検証する
- 良い例: SQL生成後だけ、スキーマダンプと1回照合する
APIコストも最適化する場合は、Opus 5の料金内訳およびClaude APIの請求額を削減するためのガイドも参照してください。
2. 簡潔さを明示的にプロンプトする
Opus 5のデフォルト出力は、Opus 4.8より長くなりがちです。これは会話の応答だけでなく、レポート、設計書、README、要約などの成果物にも当てはまります。
ここで注意すべき点は、effortを下げても出力文量は大きく減らないことです。
effortはモデルがどれだけ思考するかを制御します。表示される回答がどれだけ長いかを直接制御するものではありません。
たとえば、xhighからmediumへ下げると、思考トークンは減る可能性があります。しかし、最終回答の長さはほぼ変わらない場合があります。Opus 5のeffortパラメーターガイドでは、各レベルの違いを確認できます。
回答を短くしたい場合は、具体的な上限をプロンプトに入れてください。
Response format: at most 150 words unless I ask for more.
No preamble, no restatement of my question, no summary at the end.
Lead with the answer, then the reasoning if it is needed.
文書を作成させる場合は、含める内容だけでなく、省略する内容も指定します。
Write the migration doc at 800 words maximum.
Include: the breaking changes, the fix for each, and a rollback step.
Exclude: background on the old system, a glossary, and a conclusion section.
If a section would exceed its share, cut examples before cutting steps.
コード変更だけが必要な場合は、説明を抑制します。
Return the diff and nothing else.
No explanation of what you changed unless the change is non-obvious,
in which case one sentence above the hunk.
3. サブエージェントの委任を制限する
Opus 5はOpus 4.8よりもサブエージェントへ委任しやすい傾向があります。複数ステップのタスクと、サブエージェント生成をサポートするハーネスがある場合、作業を分散することがあります。
これは有効な場合もあります。しかし、各サブエージェントには独自のコンテキストとトークンコストが発生します。コストやレイテンシーが重要なワークロードでは、委任をモデルの判断だけに任せず、上限を設定してください。
サブエージェントを使わない場合:
Do not spawn subagents for this task. Handle it in this conversation.
限定的に利用する場合:
You may delegate to at most 2 subagents, and only for independent
file-level work that can run in parallel.
Do research, planning, and final synthesis yourself in this thread.
避けるべきなのは、委任のための委任です。たとえば次のようなケースです。
- 1ファイルを読むだけのためにサブエージェントを生成する
- メインスレッドのコンテキストだけで判断できる内容を委任する
- 調査・計画・最終統合まで不要に分散する
意図的にサブエージェントを設計する場合は、Claude Codeサブエージェントの作成ガイドを参照してください。
4. 狭いタスクではスコープを明示的に制約する
Opus 5は、与えられたタスクの周辺まで改善しようとすることがあります。
たとえば、失敗しているテストの修正を依頼すると、テスト対象のヘルパーをリファクタリングし、型定義を更新し、追加テストまで書くことがあります。変数名の変更を依頼すると、周囲の関数を整理する可能性もあります。
広範な改善が必要なタスクでは有用です。しかし、外科的な変更が必要な場合、未要求のリファクタリングはレビュー対象の差分を増やし、変更の影響範囲を広げます。
変更境界と禁止事項を明示してください。
Scope: change only the retry-count constant in src/client/http.ts.
Do not refactor surrounding code, do not rename anything, do not add
tests, do not update docs. If you believe another change is required,
stop and tell me instead of making it.
最後の1文が重要です。
If you believe another change is required,
stop and tell me instead of making it.
これがない場合、モデルは必要と思われる追加変更を実施するか、問題に気付いても報告しない可能性があります。この文を加えることで、差分を増やさずに懸念だけを報告させられます。
5. 修正説明を抑制する
Opus 5は、途中で方針を変えた場合に、その修正理由を説明する傾向があります。
インタラクティブな会話では有用です。しかし、レスポンスをパーサー、UI、JSONストレージ、別モデルに渡すパイプラインでは、説明文がノイズになります。
最終結果だけを返させたい場合は、次のように指定します。
Do not narrate corrections or changes of approach.
Return only the final answer. If you revised your thinking, that
revision belongs in your reasoning, not in the response.
構造化データを後続処理へ渡す場合は、プロンプトだけでなく構造化出力も利用してください。要求するだけでなく、レスポンス形式を強制できます。
思考を無効にした場合の失敗モード
ここまでの内容は主にチューニングの問題です。ここからは正しさの問題です。
Anthropicは、thinking: {type: "disabled"}で思考を無効にした場合、Opus 5で時折発生する2つのアーティファクトを文書化しています。
ツール呼び出しがプレーンテキストになる
モデルがツール呼び出しのような文字列を返しても、構造化されたtool_useブロックではなく、通常の応答本文として出力される場合があります。
この場合、ツールは実行されません。
単発チャットでは気付きやすい問題ですが、エージェントループでは見落としやすくなります。ループはツール呼び出しを検出できないため何も実行せず、漏れたテキストだけが会話履歴に残ります。
後続ターンでは、そのテキストをツール実行済みの記録のようにモデルが解釈する可能性があります。ターンを重ねるほど失敗が蓄積し、原因追跡が難しくなります。
内部XMLタグが表示される
ユーザーに見える出力に、<thinking>のような内部タグが混ざることがあります。
これは見た目の問題だけではありません。HTMLとしてレンダリングしたり、構造を解析したりする処理では、パイプラインに影響する可能性があります。
タグ名をプロンプトで指定して抑制しようとしないでください。
<thinking> タグを絶対に出力しない
このような指示は、対象トークン列をコンテキストに含めるため、漏洩を抑制するどころか発生可能性を高める場合があります。
Anthropicが推奨する対策は、思考を有効にしたまま、低いeffortでコストを制御することです。
{
"model": "claude-opus-5",
"max_tokens": 4096,
"output_config": { "effort": "low" },
"messages": [
{ "role": "user", "content": "..." }
]
}
この構成では、「思考無効」時のアーティファクトを避けつつ、低コスト側の設定を利用できます。
また、Opus 5では次の点にも注意してください。
-
thinking: {type: "disabled"}とxhighまたはmaxのeffortを組み合わせると、400エラーになる - 思考無効時の
effortはhighまでに制限される -
thinkingフィールドを省略しても、Opus 4.8のように思考無効にはならない - Opus 5では思考はデフォルトで有効であり、適応型思考として実行される
思考を無効にすることが必須の場合、プロンプトで対処するのではなく、エージェントループに防御的な検証を追加してください。
具体的には、アシスタントの応答本文に未実行のツール呼び出し形式の文字列が含まれる場合、そのターンを履歴へ追加する前に拒否します。幽霊のツール呼び出しを会話履歴へ残すのではなく、明示的に失敗させてください。
推測ではなく変更をテストする
プロンプト変更は、文章を読んだだけでは評価できません。
応答長、検証パス、サブエージェント数といった挙動は、トークン数やペイロード構造に現れます。実際にリクエストを送信し、結果を比較してください。
これは、オールインワンのAPI開発・テストプラットフォームであるApidogで簡単に設定できます。
- Anthropic Messagesエンドポイントに対するリクエストを作成し、
"model": "claude-opus-5"を指定します。APIキーはリクエストボディではなく環境変数として保存します。 - 古いOpus 4.8用システムプロンプトと、調整後のOpus 5用システムプロンプトを、同じ入力用の保存済みリクエストとして作成します。
- 各レスポンスの
usageブロックを比較します。出力トークンで簡潔性制約の効果を確認し、入力トークンとキャッシュ関連フィールドでプロンプト編集がキャッシュプレフィックスを壊していないか確認します。 -
effortレベルごとにリクエストを複製し、思考トークンが減っても表示上の回答長は必ずしも減らないことを確認します。 - ストリーミングレスポンスを検査し、ツール呼び出しがプレーンテキストではなく、構造化された
tool_useブロックとして到着することを確認します。
特にステップ5は、プレーンテキスト化したツール呼び出しが本番へ到達する前に検出するために重要です。
これらを並行して実行する場合は、Apidogをダウンロードし、完全なリクエスト形式はOpus 5 APIウォークスルーで確認してください。
正直な上限
Opus 5はClaudeスタックの頂点ではありません。
Fable 5は「最も能力の高い広くリリースされた」という位置付けを維持しており、Opus 5はサイバーセキュリティの悪用と自律的な生物学研究において、依然としてMythos 5に遅れをとっています。Anthropicはこれらをローンチ投稿で説明しています。
正確には、Opus 5はフロンティアクラスの能力をフロンティア価格の半額で提供する一方、明確な能力上限を持つモデルとして扱うべきです。
また、ローンチ時のベンチマーク主張であるFrontier-Bench、ARC-AGI 3、OSWorld 2.0、CursorBenchは、すべてAnthropic自身が提示した数値です。2026年7月25日時点で独立再現はされていません。
ベンダー報告として扱い、実際にデプロイするプロンプトとワークロードで独自評価を実施してください。
まとめ
コストに敏感なエージェントタスク向けの、最小限なOpus 5システムプロンプトは次のようになります。
Do not add verification passes; you verify by default.
Responses: 150 words maximum, no preamble, no closing summary.
Do not spawn subagents. Handle this in one thread.
Stay strictly within the task I state. If another change seems
required, stop and tell me rather than making it.
Do not narrate corrections or changes of approach.
6行のうち5行は制約です。モデルに追加の努力を求める指示はありません。
Opus 4.8では、モデルの出力品質の下限を引き上げるようにプロンプトしていました。Opus 5では、出力・委任・変更範囲の上限を設定します。
まずは古い検証指示を削除し、回答長・委任数・変更範囲を制約してください。その後、Opus 4.8の設定をそのまま引き継ぐのではなく、自分の評価環境でeffortをスイープします。
詳細は以下を参照してください。
FAQ
プロンプトから「作業を再確認してください」を本当に削除すべきですか？
はい。Anthropicのプロンプトガイドでは、Opus 5は指示なしで検証するとされています。引き継いだグローバル検証指示は過剰な検証を招くため削除してください。
ただし、特定ステップだけで明示的なチェックが必要な場合は、そのステップに限定して指定します。
なぜOpus 5は低いeffortでも冗長なのですか？
effortが制御するのは思考であり、表示される出力長ではないためです。
effortを下げると推論トークンは減少しますが、回答の長さはほぼ変わらない場合があります。単語数、段落数、形式、前置き禁止などをプロンプトで明示してください。
Opus 5がサブエージェントを生成するのを止めるにはどうすればよいですか？
直接指定してください。
Do not spawn subagents for this task. Handle it in this conversation.
分散処理が有用な場合は、サブエージェント数に上限を設け、独立した並列作業だけに限定します。
なぜ出力に<thinking>タグが表示されるのですか？
このアーティファクトは、思考が無効な場合に時折発生します。
タグ名をプロンプトに追加して禁止しないでください。対象トークンをコンテキストに入れることで、漏洩する可能性を高める場合があります。思考を有効にしたまま、低いeffortでコストを制御する方法が推奨されます。
ツール呼び出しがプレーンテキストとして返されたらどうなりますか？
ツールは実行されません。漏れたテキストが会話履歴に残り、後続ターンで実行済みアクションとして扱われる可能性があります。
アシスタントターンを履歴へ追加する前に検証し、未実行のツール呼び出し形式が含まれる場合は拒否してください。可能であれば、思考を無効にせず、有効なまま運用することを推奨します。
Top comments (0)