Opus 5では今までのプロンプトが逆効果に。「検証して」を消して「簡潔に」と書くべし。公式プロンプトガイドを読み解く
こんにちは、ログラスの松岡(@little_hand_s)です。 
3行まとめ
- Opus 5は放っておくと応答が前より長くなる。「簡潔さの指示」を基本セットとして書いておこう（effortでは短くならない）
- 公式ガイドは、プロンプト内の検証指示を 「削除してください」とまで明言。今までの品質担保の常識が逆効果になる
- 思考はデフォルトオンのまま使い、effortは
highから調整。旧モデル向けのプロンプト資産は見直しが必要
はじめに
Claude Opus 5の公式プロンプティングガイドが公開されました。
読んでみると、Opus 4.8向けのノウハウが そのままだと逆効果になるポイント がいくつもあります。この記事では、特に重要な2つのポイントを先に押さえた上で、ガイド全体の要点と、Opus 4.8・Fable 5のガイドとの比較をまとめます。
なお、前提として公式はこう言っています。
既存のClaude Opus 4.8のプロンプトでも、そのまま良好に動作します。
つまり「移行したら壊れる」話ではなく、「チューニングすればもっと良くなる（放置するとトークンを無駄にする）」話です。
最重要ポイント①：放っておくと長くなる。「簡潔さの指示」を基本セットに
Claude Opus 5のデフォルトのユーザー向け応答は、以前のOpusモデルよりも長くなります。エフォートパラメータは、モデルがどれだけ発言するかではなく、どれだけ思考するかを制御します。
ポイントは2つです。
- 放っておくと前より長くなる
- effortを下げても応答は短くならない（effortが制御するのは思考量。原典いわく「確実に短くすることはできません」）
つまり「長いからeffortを下げる」は効かない打ち手で、長さの制御は明示的なプロンプト指示で行います。公式は「短い簡潔さの指示が効果的です」として、次の例を示しています。
応答は焦点を絞り、手短かつ簡潔に。免責事項や注意書きは短くし、
応答の大部分を本題の回答に使うこと。何かの説明を求められたときは、
詳細な説明が明示的に要求されない限り、高レベルの要約を返すこと。
基本、これを書いておきましょう。置き場所としては、毎回プロンプトに書くよりも、プロジェクトやユーザールートのCLAUDE.md（システムプロンプト相当の場所）に入れておくのが良さそうです（※ここは記事からの筆者の解釈で、未検証です）。
最重要ポイント②：「検証して」は削除せよ
この強調は大きいです。「削除して」と明示的に書かれています。
Claude Opus 5は、指示されなくても自身の作業を検証します。プロンプトに明示的な検証指示（「自明でないタスクには最終検証ステップを含める」「サブエージェントを使用して検証する」）が含まれている場合は、削除してください。
「検証して」「再確認して」といった指示は、多くの現場プロンプトが品質担保のために慣習的に足してきたものです。Opus 5は検証を勝手にやるので、これらの指示は 過剰検証によるトークンの無駄 になります。削除しても品質は落ちない、と明言されています。
自己修正も同様です。
すでに実行している再チェックを指示すること（「答えを再確認する」「応答前に再検証する」）は避けてください。
「ダブルチェックして」系の指示は、結果を改善せずコストだけ増やす、と明言されています。CLAUDE.mdに書かれていたら削除しましょう。
ちなみに、放っておくと広がるのは検証だけではありません。タスクのスコープを拡大し、頼んでいないステップを足したり独自の判断を加えたりすることもあるとのこと。狭いタスクでは、スコープを明示的に制約することが推奨されています。
その他のポイント
思考はオンのまま使う
Opus 5は 思考がデフォルトで有効 です（無効化できるのはhighエフォート以下のみ）。コストが気になっても、思考はオンで固定しておくのが良さそうです。公式の推奨は「思考をオフにする」ではなく「思考オンのままeffortを下げる」だからです。
ほとんどのタスクでは、
lowエフォートで思考を有効にした方が、同程度のコストで思考を無効にするよりも優れたパフォーマンスを発揮します。
effortの選び方：デフォルト（high）から始めて調整
effortのドキュメントにOpus 5向けの推奨がまとまっています。整理するとこうです。
| effort | 使いどころ |
|---|---|
high（デフォルト） |
まずここから始めて、評価に基づいて調整 |
xhigh |
要求の厳しいコーディングやエージェント型作業にステップアップ |
max |
制約のないトークン消費を正当化できるタスクのみ |
medium / low
|
品質が維持できるなら、コストと応答時間の主要な制御手段として積極的に使う |
注意点は3つ：
- 以前のモデルからeffort設定を引き継いだ場合は、再利用せず評価をやり直すよう明記されている（Opus 4.8の推奨は「コーディングは
xhighから」だったので、起点が変わっている） -
xhigh/maxでは思考を無効化できない（400エラーになる）。またこの2つで実行する場合はmax_tokensを大きく（64kから調整） - 前述の通り、effortは文章量には関係ない。応答の長さはプロンプトで制御する
サブエージェントは放っておくと使いすぎる
Claude Opus 5は、以前のモデルよりも積極的にサブエージェントに委任します。
委任が効果的なのは大きくて独立した作業であり、小さいタスクに使うとコストと時間が無駄になる可能性があるとのことです。そのため公式ガイドでは、以下のようなプロンプトを記述しておくことが推奨されています。
サブエージェントへの委任は、広範囲にわたる複数ファイルの調査のような、
本当に独立していて並列化できる大きなタスクに限ること。
数回のツール呼び出しで自分で終えられる作業は委任しないこと。
また、自分の作業の検証やダブルチェックのためにサブエージェントを使わないこと。
1つのサブエージェントでタスクを完了できるなら複数ではなく1つを使い、
生成数は少なく保つこと。
その他の期待される効果（未検証）
ここからは筆者自身は未検証ですが、公式ガイドで言及されている注目ポイントを紹介します。
複雑なコーディングタスクへの適性 複数ファイルにまたがる機能、大規模リファクタリング、エンドツーエンドの機能開発のような、難易度の高いタスクほど力を発揮するとのことです。
スタブやプレースホルダーを残すのではなくタスクを完全に完了し、最初に完全なタスク仕様を与えて実行に任せたときに最高のパフォーマンスを発揮します。
「TODOだけ残して実装が完了しない」という問題に悩まされてきた方には朗報かもしれません。
コードレビュー精度の向上 高い精度（precision）と再現率（recall）でコードをレビューするとのことです。そしてレビュープロンプトについての、この注意はそのまま強調したいポイントです。
レビュープロンプトに「重大度の高い問題のみを報告する」や「保守的に」と書かれている場合、モデルはその指示を文字通りに従って報告を減らす可能性があります。代わりに、すべてを報告させて別のパスでフィルタリングするよう依頼してください。
ビジュアル的な制御の向上 チャート・ドキュメント・図の理解や、UIとフロントエンドの視覚的な再現に優れるとのことです。
スプレッドシートやスライドの生成 「複雑な数式を含む複数シートのスプレッドシートを生成・操作し、よく構造化されたスライドデッキを作成します」とのこと。従うべきスタイルやテンプレートがあれば、プロンプトで指定することが推奨されています。
マルチエージェント調整の向上 サブエージェントは「抑えるべき」という話を先に書きましたが、効果的に活用する方向の能力も強化されているとのことです。
Claude Opus 5は、サブエージェントのチームをうまく調整し、効果的なライター・ベリファイアーパターンを実現し、エージェント同士が互いの作業を上書きするケースはほとんどありません。
書き手（ライター）と検証者（ベリファイアー）でエージェントを分けるパターンが効果的、というのは設計のヒントになりそうです。
Opus 4.8・Fable 5との比較
3つのガイドを並べると、モデルごとに「デフォルト行動」と「プロンプトで補うべき方向」が違うことがはっきり見えます。
比較表
| 観点 | Opus 4.8 | Opus 5 | Fable 5 |
|---|---|---|---|
| 位置づけ | 長期エージェント作業・ナレッジワーク | 複雑なエージェント的コーディング・企業業務 | 人間で数時間〜数週間かかるE2E作業 |
| 思考のデフォルト |
オフ（adaptiveを明示設定して有効化） |
オン（無効化はhigh以下のみ） |
適応的思考のみ |
| effortの起点 | コーディング等は**xhighから**（他も最低high） |
highから。low/mediumを積極活用 |
highから。低effortでも旧モデルのxhigh超えも |
| サブエージェント | 生成が少なめ → 促す指示を書く | 積極的 → 抑える指示・上限を書く | 並列ディスパッチが積極的かつ高信頼 → 非同期設計を推奨 |
| 検証の指示 | （レビュー用途では網羅性を指示） | 検証・再確認指示は削除 | 長時間実行では検証サブエージェントを明示的に指示 |
| 指示追従の特徴 | 字義通り（特に低effort）。暗黙の一般化をしない | レビュー指示（「保守的に」等）を文字通り適用 | 強力。簡潔な指示でほぼ制御できる |
頭を切り替えるべきこと
① プロンプトは「足す」から「削る」へ
最重要ポイント②の通り、検証・再確認の指示は重複コストになります。Fable 5のガイドも同じ方向を指しています。
以前のモデル向けに開発されたスキルは、Claude Fable 5にとって規範的すぎることが多く、出力品質を低下させる可能性があります。
モデルが賢くなるほど、細かい手順書は邪魔になる。これはOpus 5とFable 5に共通の潮流です。
② effortの起点はxhighからhighへ。下も上も試す
Opus 4.8のガイドは「コーディングではxhighから始める」でした。Opus 5では、highから始めて、品質が維持される限りlow/mediumを積極的に使い、要求の厳しいコーディングやエージェント作業ではxhighに引き上げる、という組み立てに変わりました。
③ サブエージェント指示は方向が真逆
Opus 4.8では「委任が少ないので促す」、Opus 5では「委任しすぎるので抑える」。同じプロンプトスニペットを使い回すと、モデルによって逆効果になる代表例です。ハーネスやスキルにサブエージェント指示を書いている場合は、対象モデルごとに見直しが必要です。
④ 「保守的に」が文字通り効く前提でレビューを設計する
前述の「その他の期待される効果」の通り、Opus 5のコードレビューでは「重大度の高い問題のみ報告」と書くと、その通りに報告が減ることがあります。発見ステージは網羅、フィルタは別パス、という 役割分離 が公式推奨です（これはOpus 4.8のガイドと同じ推奨です）。
⑤ Opus 5とFable 5は「似た性格の別物」として扱う
どちらも「勝手に委任する・長く書く」方向ですが、検証は逆です。Opus 5は「検証指示を削除せよ」なのに対し、Fable 5の長時間実行では「検証サブエージェントを明示的に指示せよ」が推奨。さらにFable 5は数時間〜数日単位の自律実行が前提で、非同期ハーネス・メモリシステム・send-to-userツールといった インフラ側の投資 まで視野に入る点で、適応コストの重さが一段違います。
おわりに
やることはシンプルで、足すのは「簡潔さの指示」、削るのは「検証の指示」 です。
旧モデル向けに積み上げた「ちゃんとやらせるための指示」は、新モデルでは過剰品質とコスト増の原因になります。まずは手元のCLAUDE.mdやスキルを開いて、簡潔さの指示を足し、「検証して」「再確認して」を探して消す。この2つから始めてみてください。
書籍紹介
本記事では、モデルの進化に合わせてプロンプトをどうチューニングするかを扱いました。
一方で、モデルがどれだけ賢くなっても変わらず重要なのが、複雑なビジネスロジックをどう設計するかです。AIに実装を任せる場面が増えるほど、設計の指針を人間が示せることの価値は上がっています。この課題に対しては、ドメイン駆動設計（DDD） が役立ちます。DDDはビジネスロジックを整理し、保守しやすいコードを書くための設計手法です。
筆者はドメイン駆動設計について以下の書籍を執筆しています：
①基礎編: 初めてDDDを学ぶ方向け。基礎概念から実装パターンまで幅広く解説しています
②実践編: 実践時の頻出の疑問にサンプルコード付きで回答しています
著者について
AI駆動開発・DDD・アジャイルに関する情報を発信しています。よろしければフォローしてください。
Discussion