「検証して」と書けば書くほど、動きが遅くなる。そんな逆転が起きています。
Claude Opus 5の公式プロンプティングガイドを読んでいて、率直に驚きました。これまで積み重ねてきたプロンプトの「お作法」が、そのまま通用しなくなっていたからです。
きっかけ
新しいモデルが出るたびに、プロンプトを微調整して使い回してきました。今回は事情が違い、公式ガイドと、それを読み解いたZennの解説記事の両方が「削れ」と言っています。
積み上げてきたプロンプト資産をアップデートする前に、何がどう変わったのかを自分の言葉で整理しておきます。
Opus 5のプロンプティングとは
Opus 5は、複数ファイルにまたがる機能開発や大規模リファクタリングといった、長期的なエージェント的タスクに強みを持つモデルです。
そのぶん自律性も高くなっています。指示しなくても自分の作業を検証し、ミスがあれば自分で直す。積極的にサブエージェントへ仕事を振る。この性質が、プロンプトの書き方そのものを変えています。
「足す」から「削る」への転換
旧モデル向けのプロンプトには、「検証してください」「もう一度確認してください」といった指示が当たり前のように含まれていました。モデルが指示なしでは検証をサボりがちだったからです。
Opus 5では事情が逆転します。指示しなくても検証してしまうモデルに「検証して」を重ねると、同じ確認が何度も走り、トークンだけが消費されます。
つまりプロンプトの改善が「足す」作業から「削る」作業に変わりました。ここが一番の頭の切り替えどころだと感じています。
検証指示を消す
「検証して」「再確認して」は削除します。品質を落とさずにトークンを節約できる、数少ない明快な変更点です。
かわりに、タスクの範囲は明確に絞っておきます。Opus 5は自分の判断でスコープを広げがちなので、「頼まれたことをやりきったら、そこで止める」ことを言葉にしておくとよさそうです。
簡潔さを明示する
Opus 5のデフォルトの応答は長めです。厄介なのは、effortを下げても応答の長さは変わらないという点です。effortが制御するのは思考の量であって、文章量ではありません。
簡潔な応答が欲しければ、「焦点を絞って手短に」という指示をプロンプトに明示するしかありません。これは成果物のドキュメントについても同じで、長さを指定しない限り、放っておくと長くなります。
effortはhigh起点、思考は常時オン
旧モデルの感覚でxhighから入ると、コストに見合わないケースが多いようです。Opus 5ではhighを起点に評価し、品質が保てるならlowやmediumを積極的に使うほうがよいとされています。
思考はデフォルトで有効になっています。ここを無効化すると、ツール呼び出しが文章として漏れ出したり、内部的なタグが応答に混ざったりする副作用があるそうです。コストを抑えたいときは、思考のオンオフではなくeffortのほうを動かします。
サブエージェント委任には上限を
Opus 5は以前のモデルより積極的にサブエージェントへ仕事を振ります。放っておくとコストと時間が膨らみやすくなります。
「独立していて、並列化できる大きなタスクだけを委任する」と条件を決めておく。これが歯止めになります。
読んでみて変わった考え方
一番の学びは、プロンプトの改善を「賢くするための追加」だと思い込んでいたことに気づけた点です。
モデルが賢くなるほど、プロンプト側の役目は指示を増やすことではなく、モデルが持つ余計な癖を打ち消すことに変わっていきます。Opus 5のガイドは、その転換をはっきり示しています。
Zenn記事にあったOpus 4.8・Opus 5・Fable 5の比較表を見ても、検証指示やeffortの起点、サブエージェントの扱いは、モデルが変わるたびに方向が入れ替わっています。プロンプトを資産として使い回す発想そのものを、一度見直したほうがよさそうです。
まとめ
- 検証指示（「検証して」「再確認して」）は削除する
- 簡潔さは明示しないと出ない。
effortは文章量を制御しない effortはhigh起点で調整し、思考は常時オンのまま使う- サブエージェント委任は「独立した大きなタスクだけ」に絞る