Claude Opus 5がリリースされ、これまでのプロンプトの「常識」が通用しなくなりつつあります。公式のプロンプティングガイドを読み解くと、旧モデル向けに積み重ねてきた工夫がむしろ逆効果になるケースが見えてきました。今回はその要点を整理します。
デザイナーこれまでのプロンプトの常識が通用しなくなってるって、結構衝撃的じゃない？何がどう変わったんだろうね？
エンジニアはい、Opus 5は賢くなりすぎて、以前の指示が逆効果になるケースがあるようです。特に、プロンプトの「長さ」と「検証」に関する変更は要チェックですね。
3行まとめ
- Opus 5は放っておくと応答が以前より長くなる。「簡潔さの指示」を基本セットとして書いておく必要がある(effortを下げても短くはならない)
- 公式ガイドは、プロンプト内の検証指示を「削除してください」と明言。今までの品質担保の常識が逆効果になる
- 思考はデフォルトオンのまま使い、effortは
highから評価して調整する。旧モデル向けのプロンプト資産は見直しが必要
エンジニアこの3行まとめだけでも、かなり大きな変更点が含まれていますね。「簡潔さの指示」と「検証指示の削除」は、特に注意すべきポイントです。
デザイナーへぇ、品質を上げるために頑張って書いていた指示が、逆に良くないってことか。それは早く見直さないとね！
放っておくと応答が長くなる
公式ガイドいわく、Opus 5のデフォルトの応答は以前のOpusモデルよりも長くなる傾向があります。ポイントは2つです。
- 放っておくと前より長くなる
- effortを下げても応答は短くならない(effortが制御するのはあくまで思考量)
つまり「長いからeffortを下げる」は効かない打ち手です。長さの制御は明示的なプロンプト指示で行う必要があります。公式が示す簡潔さ指示は以下の通りです。
応答は焦点を絞り、手短かつ簡潔に。免責事項や注意書きは短くし、
応答の大部分を本題の回答に使うこと。何かの説明を求められたときは、
詳細な説明が明示的に要求されない限り、高レベルの要約を返すこと。
毎回プロンプトに書くよりも、CLAUDE.mdなどシステムプロンプト相当の場所に入れておくのが実用的です。
デザイナー応答が長くなるのは、細かく説明しようとしてくれてるのかな？でも、簡潔にしてほしい時には困っちゃうよね。
エンジニアええ、なので明確に「簡潔に」という指示を与える必要があります。effort調整では長さは制御できないので、ここが旧モデルとの大きな違いですね。
「検証して」は削除せよ
もう一つの重要な変更点は、検証指示の扱いです。公式ガイドは次のように明言しています。
Claude Opus 5は、指示されなくても自身の作業を検証します。プロンプトに明示的な検証指示が含まれている場合は、削除してください。
「検証して」「再確認して」といった指示は、多くの現場プロンプトが品質担保のために慣習的に足してきたものですが、Opus 5は検証を自律的に行うため、これらの指示は過剰検証によるトークンの無駄になります。削除しても品質は落ちないとされています。「ダブルチェックして」系の自己修正指示も同様に、コストだけ増やす要因になるため見直しが必要です。
エンジニアこれは本当に大きな変化です。これまで品質確保のために必須だと思っていた「検証指示」が、Opus 5では不要になり、むしろコスト増になるという…。
デザイナーえー、つまり「過剰なおせっかいはしなくていいよ」ってこと？賢くなった証拠だね。でも、ついつい書いちゃいそうだなぁ。
サブエージェントは放っておくと使いすぎる
Opus 5は以前のモデルよりも積極的にサブエージェントへ委任する傾向があります。委任が効果的なのは大きく独立した作業に限られ、小さいタスクに使うとコストと時間の無駄になりかねません。公式ガイドでは、委任範囲を明示的に制約するプロンプトを書いておくことが推奨されています。
サブエージェントへの委任は、広範囲にわたる複数ファイルの調査のような、
本当に独立していて並列化できる大きなタスクに限ること。
数回のツール呼び出しで自分で終えられる作業は委任しないこと。
また、自分の作業の検証やダブルチェックのためにサブエージェントを使わないこと。
デザイナーサブエージェントって、賢いんだけど使いすぎちゃうこともあるんだね。適材適所ってやつかな。
エンジニアまさにその通りです。大規模なタスクには有効ですが、ちょっとした作業に使うとオーバーヘッドが大きい。人間が部下に指示するのと同じ感覚で、効率を意識する必要がありますね。
effortの選び方
| effort | 使いどころ |
|---|---|
| high(デフォルト) | まずここから始めて、評価に基づいて調整 |
| xhigh | 要求の厳しいコーディングやエージェント型作業にステップアップ |
| max | 制約のないトークン消費を正当化できるタスクのみ |
| medium / low | 品質が維持できるならコストと応答時間の制御手段として積極的に使う |
旧モデル(Opus 4.8)の「コーディングはxhighから」という起点は変わっているため、以前のeffort設定をそのまま引き継がず評価をやり直すことが推奨されています。また思考はデフォルトで有効になっており、コストが気になる場合も「思考をオフにする」のではなく「思考オンのままeffortを下げる」方が良いパフォーマンスが出るとされています。
エンジニアeffortのデフォルトがhighになったのは、それだけ自信があるということでしょうね。旧モデルの常識でxhighから始めるのはもう違うと。
デザイナーなるほどね！とりあえずhighで試してみて、ダメなら調整するってことだ。思考はオフにしない方がいいってのも、面白いな。
まとめ
やることはシンプルです。足すのは「簡潔さの指示」、削るのは「検証の指示」。旧モデル向けに積み上げてきた「ちゃんとやらせるための指示」は、新モデルでは過剰品質とコスト増の原因になります。まずは手元のCLAUDE.mdやスキルを見直し、簡潔さの指示を足し、「検証して」「再確認して」を探して消すところから始めてみてください。
