Claude Opus 5のプロンプトは、足すより引く。移行時に見直したい7つのポイント
Claude Opus 5向けの公式プロンプティングガイドを、既存プロンプトの棚卸しとして整理します。effortと回答の長さ、進捗報告、検証指示、タスク範囲、サブエージェント、thinking無効時の注意点まで解説します。
今回のOpus 5は期待できそうなモデルですね。
Opus 5が出るまでは、Fableの利用停止騒動と、Opues 4.8の性能がいまいちなことがありながらも我慢して使っていました。少しずつリミットを気にしながらFableで設計して、定期実行タスクではOpus 4.8にルーティンをやってもらっていたところ、Opus 5で一気に性能アップが感じられそうです。
そんなClaude Opus 4.8向けに育てたシステムプロンプトは、そのままClaude Opus 5へ持ち込んでももちろん動きます。公式ガイドも、既存のOpus 4.8向けプロンプトは良好に動作すると書いています。
ただ、そのまま使うと気になる場面が出てきます。
回答が前より長い。作業中の説明が多い。頼んでいない範囲まで直してくる。数分で終わる調査でもサブエージェントが立ち上がる。
これはモデルの不調ではありません。旧モデルの弱点を埋めるために定義したスキルやプロンプトが、Opus 5が最初からやることと重複してしまい、無駄な指示になってしまっている可能性があります。
Anthropicが公開したClaude Opus 5向けのプロンプティングガイドも、新しい呪文を足す話ではなく、調整が必要になりやすい挙動の一覧として書かれています。検証指示にいたっては「含まれていたら削除してください」と明記されているんですね。
ちなみに、このガイドが扱うのはOpus 5に固有のプロンプティングだけです。モデルの能力やAPIの変更点は「Claude Opus 5の新機能」と移行ガイドへ、全モデル共通の手法はプロンプティングのベストプラクティスへ分かれています。
なので、この記事では公式ガイドの内容として何を削り、何を残し、何を新しく決めるかについて、機能紹介ではなく既存プロンプトの棚卸しの順番で並べ直します。
最後に、そのまま貼って使える統合プロンプトと移行チェックリストを置きました。
※本記事は2026年7月25日時点のAnthropic公式情報をもとにしています。
まず、Opus 5で性能アップした場所を確認する
削る話の前に、Opus 5はどの領域が性能アップしているのかを見ていきましょう。
公式ガイドがプロンプティングに関係する改善として挙げているのは、次の領域です。
エージェント型コーディング。 複数ファイルにまたがる機能開発、大規模なリファクタリング、エンドツーエンドの実装で最も能力を発揮します。スタブやプレースホルダーを残さず、タスク全体を完了させます。最初に完全な仕様を渡し、その後は任せた場合に最も良い結果が出ます。1回のやり取りで終わる編集でも問題なく動きますが、そこでは以前のモデルとの差が小さくなります。
これはFable 5との相性が最もよいと想像でき、ユーザーも意識しやすいグッドポイントですね。
コードレビューとバグ検出。 高い適合率と再現率でレビューし、追加で報告される指摘の大半も偽陽性ではなく実在する問題だと説明されています。低いeffortでも精度が落ちにくいため、まず高速なレビューを回し、そのあと詳細なレビューを行う運用ができます。
ここで一つ、意外な注意点があります。
レビュー用プロンプトへ「重大度の高い問題だけを報告してください」「保守的に判断してください」と書くと、モデルが指示を文字どおり受け取り、報告する問題を減らす可能性があります。公式ガイドの推奨は、まずすべての問題を報告させ、絞り込みは別の処理段階で行うことであるとしています。
指示追従性が高いモデルほど、遠慮を求める言葉が効きすぎます。
低いeffortでの効率。 lowとmediumは、高い設定と比べてトークン数とレイテンシーを大幅に削りながら品質を保ちます。まずデフォルトのhighから始め、評価結果で調整しながら、lowとmediumを積極的に使用することを推奨しています。
ビジョン。 グラフ、文書、図表の理解に優れ、UIやフロントエンドの外観を視覚的に再現する能力も上がっています。以前のモデル向けにプロンプト側で入れていた回避策は、もう不要になっているかもしれません。
ビジョンで性能が出るのは、モデルがツールを使って反復的な分析、画像の切り抜き、成果物の視覚的な確認を行える場合です。思考量を増やすことだけに頼るより、ツールを使わせるほうが費用対効果の高い改善になります。
長いコンテキスト。 100万トークンのコンテキストウィンドウがデフォルトかつ最大値として用意され、その全体を通じて指示への追従、ツール呼び出し、推論の一貫性が維持されます。
オフィス業務と文書作成。 単純ではない数式を含む複数シートのスプレッドシートを扱え、構成されたスライド資料も作れます。ただ、従うべきスタイルやテンプレートがあるなら、そこはプロンプトで指定してほしいとのこと。ここらへんはスキル化すれば問題なさそうですよね。
マルチエージェントの調整。 サブエージェントのチームを調整でき、「作成者と検証者」の役割分担も機能します。複数のエージェントが互いの作業を上書きするケースもほとんどないと説明されています。
ループエンジニアリングやハーネスエンジニアリングが徐々に浸透してくるにつれて、作成と検証(ジェネレーター・エヴァリュエーター)の役割をサブエージェントで役割分担することが当たり前になってきましたね。
この7つの領域をこれまでに強化しようとして補うために書いたスキルやプロンプトは、削除・削減候補になっていきます。
Opus 5への移行で最初にやるのは、指示を足すことではない
新しいモデルが出ると、専用の書き方を足して性能を確かめたくなってしまうんですけど、もうやめてもよさそうですね。
なぜなら、旧モデル向けのプロンプトには、能力不足を埋めるための指示が積もっているから。
- 最後に必ず検証してください
- 回答する前に、もう一度すべて確認してください
- 検証用のサブエージェントを起動してください
- いま何をしているか、逐一説明してください
Opus 5は、これらを指示されなくてもやります。同じ指示を重ねても品質は上がらず、トークン、レイテンシー、サブエージェントの起動回数だけが増えます。
しかも、効かない指示は残り続け、効果を測っていないので、誰も消せないし、マイナスになっていることも確認できない悪循環になりそうです。
ここらへんはこれからOpus 5を実戦に投入することで体感としても徐々に分かっていくことだと思いますね。
移行作業は、追加ではなく棚卸しから始めます。ここからは、公式ガイドが挙げた調整ポイントを7つに整理します。
1. effortを下げても、回答は短くならない
effortが制御するのは、モデルがどれだけ思考するかであって、どれだけ話すかではありません。
なので「回答が長いからeffortを下げる」という対処は、狙いと手段がずれてしまいます。effortの制御によって思考トークンは減りますが、画面に出てくる文章が必ず短くなるわけではありません。
回答の長さは、プロンプトで直接指示します。短い指示でも十分に効きます。
こちらはAnthropic公式が推奨している簡潔さを求める時の効果的なプロンプトです。
回答は焦点を絞り、短く簡潔にしてください。免責事項や注意事項は短くし、
回答の大部分を主要な答えに充ててください。何かの説明を求められた場合、
詳細な説明が明示的に求められていない限り、概要レベルの要約を提示してください。
システムプロンプトが長い場合は、この指示に加えて、末尾付近に短いリマインダーを置く方法が案内されています。
<tone_preference>
出力は適度に簡潔にしてください。
</tone_preference>
長いシステムプロンプトでは、前半に書いたトーンの指定が後半の細かい業務ルールに埋もれます。末尾の一行は、そのための保険です。
effort、画面に出る回答の長さ、ファイルとして作る文書の長さは、それぞれ別の設定で制御します。
次の表は、減らしたい対象と、そのために変更する設定の対応表です。
たとえば、画面の回答だけを短くしたい場合は、effortを下げるのではなく、出力形式で文章量を指定します。
| 下げたいもの | 使う手段 |
|---|---|
| 推論コストとレイテンシー | effort |
| 画面に表示される文章量 | 出力形式の指示 |
| ディスクへ書き出す文書の分量 | 文書の長さの指示 |
| 全部 | それぞれ別に設定する |
「全部」を減らす場合も、一つの設定でまとめて短くするわけではありません。
推論コスト、画面の文章量、文書の分量を、それぞれ対応する手段で個別に調整します。
次の表は、タスクの性質ごとに最初に試すeffortの目安です。タスクを評価するときの出発点として使い、品質、コスト、応答時間を見ながら上下させます。
公式ガイドはデフォルトのhighから始めて評価で調整するよう勧めていて、要求の厳しいコーディングやエージェント型作業ではxhighへ引き上げます。
| タスク | 開始時の候補 |
|---|---|
| 短い変換、分類、整形 | low |
| 一般的な調査、文章作成 | medium |
| 通常の実装、分析、コードレビュー | high |
| 大規模な実装、長時間のエージェント作業 | xhigh |
たとえば、分類や整形はlowから始め、品質が足りなければmediumへ上げます。
大規模な実装はhighから評価し、長い依存関係の追跡や長時間の作業で完了率が足りない場合にxhighを試します。
ここで一つ、見落としやすい移行作業があります。
以前のモデルで使っていたeffortのデフォルトをそのまま引き継いでいる場合は、自分の評価環境でもう一度検証します。品質を維持できる範囲でlowとmediumを積極的に使うことが、コストと応答時間を制御する主要な手段になります。
2. 進捗報告は、頻度と形式を決める
Opus 5は、エージェント型の作業中に、自分がやっていることを積極的に説明します。これから何をするのかを事前に伝えることが多く、1メッセージあたりの出力量も以前より長くなります。
透明性としては良いことです。ただ、ツール呼び出しが多い仕事だと、説明そのものがノイズになりますし、そもそも人間側が全部を読むことは希ではないかなと思います。
この出力を減らしたいなら、希望する更新頻度と形式を指定します。
最初のツール呼び出しを行う前に、これから何をするのかを一文で説明してください。
作業中は、重要な発見があった場合、または方針を変更した場合にのみ、
短い進捗報告を行ってください。
作業が完了したら、結果から書き始めてください。最初の一文で「何が起きたのか」
または「何が分かったのか」に答え、その後に、詳しく知りたい読者のための
補足情報を続けてください。
反対に、進捗をもっと出してほしい場合も同じ方法を逆向きに使います。どんな報告がほしいのかを説明し、例を見せます。
公式ガイドでは、避けるべきことを指示するより、望ましいコミュニケーションスタイルの肯定的な例を提示するほうが効果的だとされています。
「説明しすぎるな」と書くより、「いつ、何を、どの長さで報告するか」を書く。エージェントの使い心地は、推論能力だけでなく、途中経過の編集設計で決まります。
3. 文書の長さは、会話とは別に指定する
チャットの回答が適切な長さでも、ディスクへ書き出すファイルは別です。
Opus 5がファイルとして生成するレポート、Markdown文書、要約も、以前のモデルより長くなる傾向があります。Claudeが作った文書をプロダクトへ組み込むなら、ここは個別に調整します。
作成する文書の長さは、タスクに必要な分量に合わせてください。
内容は十分に網羅しつつ、単なる水増しになるセクション、重複した要約、
定型的な文章を追加しないでください。
読み方を間違えそうなのが、「短く書け」ではないことです。
- 必要な内容は網羅する
- 水増しのためのセクションを作らない
- 同じ要約を何度も置かない
- 定型的な導入と結論を付けない
つまり、文字数ではなく、意思決定に必要な情報量で止めるという方針です。
社外へ出す成果物ほど、この一行の有無で読みやすさが変わります。
4. 「必ず検証する」を削り、「完了条件」を残す
ここがプロンプト移行作業の中心かもしれません。
Opus 5は、明示的に指示しなくても自分の作業を検証します。間違いを見つけて直す精度も高くなっています。
なので、次のような指示は削除の対象になります。
単純ではないタスクには、最後に検証ステップを含めてください。
サブエージェントを使用して検証してください。
回答を提出する前に、もう一度すべてを確認してください。
公式ガイドの表現は明確です。こうした最後に検証ステップを含めることやサブエージェントを使用して検証することといった、よくやりそうな指示はOpusでは過剰な検証を招いてしまい、品質を向上させないままトークンを無駄にするそうです。
検証のためだけに独立したステップを差し込む、旧来のハーネス側のスキャフォールディングも同じとのこと。
ただし、テストや検証そのものが不要になったわけではありません。
削るのは、合格条件のない抽象的な再確認です。残すのは、何を満たせば終わりかを決める受け入れ条件です。
変更後に既存テストを実行し、失敗したテストがある場合は原因を特定してください。
生成したJSONが指定されたスキーマを満たすことを確認してください。
変更前後でAPIレスポンスの互換性が維持されていることを確認してください。
もう一つ、自己修正まわりで調整したい挙動があります。
Opus 5は、先に述べた内容の訂正について、以前のモデルより詳しく説明します。エンドユーザーが見る画面では、これが不要な場合があります。
以前の記述に含まれる誤りが、ユーザーのコード、結論、または意思決定を
変える場合にのみ、その記述を訂正してください。訂正は明確かつ簡潔に伝え、
そのままタスクを続けてください。ユーザーにとって何も変わらない軽微な誤りに
ついては、訂正したことを説明せず、修正して作業を続けてください。
「よく確認して」は削る。「何を満たせば完了か」は残す。この一本の線で、既存プロンプトの検証指示はだいたい仕分けできます。
5. 手順ではなく、タスク範囲を書く
Opus 5は自律性が高い一方で、タスクの範囲を自分で広げることがあります。依頼していない手順を追加したり、タスクが本来どうあるべきかについて独自の判断を持ち込んだりします。
限定的な作業ほど、範囲を先に閉じておきます。
依頼された内容を、意図された範囲で提供してください。
日常的な判断は自分で行い、依頼の解釈によって作業内容が大きく変わる場合に
のみ確認してください。
依頼に誤りがあるように見える場合や、より良い方法が存在する場合は、
そのことを一文で伝えたうえで、依頼されたタスクをそのまま続行してください。
範囲を暗黙のうちに狭めたり、広げたり、別のタスクへ変換したりしないで
ください。タスク全体を最後まで完了し、明らかに依頼範囲を超える行動は
行わないでください。
この指示が面白いのは、範囲を狭める方向にも効くことです。手を広げすぎる問題だけでなく、勝手に簡略版で済ませる問題も同時に閉じています。
書き換えると、こういう変化です。
- 旧来のプロンプト：モデルを手順から逸脱させない
- Opus 5向けのプロンプト：手順は任せる。責任範囲からは逸脱させない
手順の指示を減らした分は、境界の記述へ回します。
6. サブエージェントは、並列化できてコストが合うときだけ使う
Opus 5は、以前のモデルより積極的にサブエージェントへ委任すると明確に書かれています。
委任が効くのは、互いに独立していて、一定以上の規模があり、並列化できる作業です。逆に、小さなタスクへ使うとコストと所要時間が増えます。サブエージェントは無料の知能ではなく、コンテキストの複製、追加の推論トークン、追加のツール呼び出し、結果の統合が乗ります。
ハーネスがサブエージェントに対応しているなら、委任の条件を明示するか、起動できるエージェント数へ決定論的な上限を設定します。
広範囲にわたる複数ファイルの調査など、規模が大きく、作業が実質的に独立
しており、並列化できるタスクの場合にのみ、サブエージェントへ委任して
ください。
自分で数回のツール呼び出しによって完了できる作業は委任しないでください。
また、自分の作業を検証または再確認する目的でサブエージェントを使用しないで
ください。
1つのサブエージェントでタスクを完了できる場合は、複数ではなく1つだけ使用し、
起動するエージェント数を少なく保ってください。
判断に迷ったら、次の表を目安にしています。
| 作業 | サブエージェント |
|---|---|
| 単一ファイルの修正 | 原則不要 |
| 数件のドキュメント確認 | 原則不要 |
| 自分の回答の再確認 | 原則不要 |
| 直列に依存する作業 | 効果が小さい |
| 大規模リポジトリの領域別調査 | 有効 |
| 複数市場、複数地域の並列調査 | 有効 |
| 独立した複数案の作成 | 条件付きで有効 |
コストを重視するワークロードでは、委任の回数そのものを制限します。マルチエージェントは高度だから使うのではなく、並列化の利益が委任コストを上回るときに使います。
7. thinkingは無効にせず、effortでコストを下げる
Opus 5ではthinkingがデフォルトで有効です。無効にできるのはeffortがhigh以下の場合に限られます。
そして、無効にすると2種類のアーティファクトがユーザー向け出力に現れることがあります。
ツール呼び出しがテキストとして出力される。 構造化されたtool_useブロックの代わりに、ツール呼び出しの内容を本文へ書いてしまう現象です。ターン自体は正常に完了しますが、そのツールは実行されません。
厄介なのは、エージェント型のループで起きた場合です。漏れ出したテキストが会話履歴に残り、その後のターンにも影響します。検索など、ツールを多用するワークロードで最も出やすいとされています。
内部XMLタグが出力される。 <thinking>タグやそのほかの内部タグが、ユーザーへ表示される回答に混ざります。システムプロンプトに「思考や推論を行わないでください」というルールが含まれている場合は、削除します。その種の指示は、タグが漏れる可能性を高めます。
どうしてもthinkingを無効にする必要があるインテグレーション向けに、両方を軽減する統合された指示が案内されています。
ツールを使用する場合は、その前に短い一文を述べても構いません。
ユーザーが依頼した内容を表現できるツールが存在しない場合は、推測するのでは
なく、そのことを伝えてください。
内部XMLタグやシステム用XMLタグを回答に含めないでください。
この指示は、ツール呼び出し前に短く発言することを明示的に許可し、適切なツールがない場合の代替行動を示し、内部タグを出さないという一般的なルールを与えています。thinkingタグの名前を具体的に挙げる指示は、この形より効果が低くなるため、特定のタグ名は名指ししません。
ただ、そもそもの推奨はthinkingの無効化ではないとのこと。
thinkingは有効なままにして、effortを下げてコストを制御します。ほとんどのタスクでは、thinking有効でlowのほうが、同程度のコストでthinking無効よりも高い性能を発揮すると説明されています。
なお、Claude Opus 4.8でもthinkingはデフォルトで有効で、無効にした場合のeffort上限はhighでした。APIの差分は移行ガイドに整理されています。
プロンプトの役割が、指示書からハーネス設計へ変わる
7つを個別のテクニックとして覚えると、これまでのモデル変更の時と同じように、おそらく次のモデルでまた同じ棚卸しをすることになると思います。
変わっているのは、プロンプトの役割のほうです。
以前は、モデルが途中で止まる、検証しない、作業を完遂しないという問題を補うために、工程を書き足す必要がありました。Opus 5は、タスクを完遂し、作業を検証し、間違いを直し、必要なら委任し、ツールを使うところまで自分でやります。
なので人間が設計するのは、工程ではなく境界になります。決めるのは5つです。
- 目的：何を達成するのか
- 対象範囲：どこまで変更、調査、生成するのか
- 完了条件：何を満たせば終了なのか
- リソース制約：時間、トークン、ツール、サブエージェントをどこまで使えるのか
- コミュニケーション形式：途中経過と最終結果を、誰にどの粒度で伝えるのか
強いモデルほど、細かく命令する必要は減ります。でも、目的、責任範囲、完了条件、コスト上限を曖昧にしてよくなったわけではありません。むしろ逆で、自律性が上がるほど、曖昧な部分はモデルの判断で埋められます。
この流れは、プロンプトエンジニアリングからコンテキストエンジニアリング、ハーネスエンジニアリングへ関心が移っていることとも一致します。上手な頼み方より、エージェントへの仕事の渡し方の設計ですね。
これを見ると、チームリーダーが行う仕事の依頼方法と全く同じだなぁと思いますね。タスク依頼方法によって精度が変わるから成果に直結するという考え方です。
既存プロンプトをOpus 5向けに移行するチェックリスト
手を動かす順番で並べます。
削除を検討する指示
- 「最後に必ず再確認してください」
- 「回答前にもう一度考えてください」
- 「検証専用のサブエージェントを起動してください」
- 「すべての作業で複数のサブエージェントを使ってください」
- 「逐一、現在の作業内容を説明してください」
- 「推論や思考を行わないでください」
- 「重大度の高い問題だけ報告してください」（レビュー用途の場合）
- 旧モデルのビジョン性能を補うための回避策
- 検証専用ステップを差し込む旧来のハーネス側スキャフォールディング
追加、または明確化する指示
- タスクの目的
- 対象範囲と対象外
- 完了条件と受け入れ条件
- 回答の長さ
- 文書成果物の長さ
- 進捗報告を行う条件と粒度
- サブエージェントを使う条件と上限数
- 訂正を説明する条件
- より良い方法を見つけた場合の扱い
設定として見直す項目
effort（旧モデルからの引き継ぎ値を評価環境で再検証）thinking（無効化していないか、無効化が本当に必要か）- 最大トークンとコンテキストの使い方
- サブエージェント数の上限
- レビュー工程（高速レビューと詳細レビューの二段構え）
一度に全部やる必要はありません。まず削除候補を1つ消して、同じ仕事を流します。品質が落ちないなら、その指示は最初から効いていなかったということです。
そのまま使える、Opus 5向けの統合プロンプト
ここまでの内容から、Opus 5へ移行するときに使えそうなプロンプトとしてまとめました。
こういったプロンプトを考えるのは面倒ですので、ぜひ使ってみてください。
<task>
達成すべき目的、対象範囲、必要な成果物を記述する。
</task>
<scope>
依頼された内容を、意図された範囲で最後まで完了してください。
日常的な判断は自分で行ってください。
解釈によって結果が大きく変わる場合にのみ確認してください。
より良い方法が存在する場合は一文で指摘し、
依頼されたタスク自体はそのまま続行してください。
依頼範囲を暗黙に狭めたり、広げたり、
別のタスクへ変換したりしないでください。
</scope>
<completion>
完了と報告できるのは、次を満たした場合とする。
- 依頼された成果物が存在する
- 指定した受け入れ条件（テスト、スキーマ、互換性など）を確認している
- 未確認、失敗、スキップした項目をそのまま報告している
</completion>
<delegation>
サブエージェントは、規模が大きく、作業が独立しており、
並列化できる場合にのみ使用してください。
自分で数回のツール呼び出しによって完了できる作業や、
自分の結果を再確認するだけの作業には使用しないでください。
1つのサブエージェントで完了できる場合は、
複数のエージェントを起動しないでください。
</delegation>
<communication>
最初のツール呼び出しの前に、これから行うことを一文で説明してください。
作業中は、重要な発見があった場合、
または方針を変更した場合にのみ短く報告してください。
完了時は作業過程ではなく、結果から書き始めてください。
以前の記述の訂正は、ユーザーのコード、結論、意思決定が変わる場合にのみ
説明してください。
</communication>
<output>
回答は焦点を絞り、主要な結論を先に示してください。
内容は十分に網羅してください。ただし、水増しのためのセクション、
重複した要約、不要な定型文は追加しないでください。
作成する文書の長さは、タスクに必要な分量に合わせてください。
</output>
このプロンプトは完成形ではありませんので、実際の業務に合わせて、権限、受け入れ条件、使えるツールをプラスしてみてください。
反対に、効果を確かめられない指示は削って調整が必要だと思います。
削ったあとに残るものが、仕事の仕様
Opus 5への移行でやることは、新しい書き方を覚えることではありませんでした。
自分たちのプロンプトから、モデルの弱点を補うために書いた行を見つけて消す。残った行が、目的、範囲、完了条件、報告のルールになっているかを確かめる。それだけです。
僕なら、まず社内でいちばん長いシステムプロンプトを開いて、検証指示の行から消します。効果を測っていない一言が、静かにコストを増やすと公式ガイドに書かれていますからね...。
それではまた！