あなたのシステムプロンプトに、こんな一文が入っていませんか。
最後に、出力内容を検証してください。
Claude Opus 5 では、これは消したほうがいい一文になりました。
「効かなくなった」のではありません。逆効果になったのです。
同じように、これまで良かれと思って書いてきた定番の指示が、Opus 5 では裏目に出るようになりました。この記事では、そのうち特に意外な3つ（＋おまけ1つ）を紹介します。
「うちはまだ Opus 4.8 だから関係ない」と思った方も、少しだけ読んでいってください。モデルが賢くなるとプロンプトの定石が変わるという話なので、次に来るモデルでも同じことが起きます。
逆転1: 「検証してください」は消したほうがいい
これまでの常識
「AI に自己チェックをさせると精度が上がる」
これはプロンプトエンジニアリングの定番中の定番です。実際、これまでのモデルではそのとおりでした。だからみんな、こう書いてきました。
作業が終わったら、最後に検証ステップを実行してください。
別のエージェントを立てて、結果をレビューさせてください。
回答する前に、もう一度答えを確認してください。
Opus 5 で何が起きるか
Opus 5 は、言われなくても自分で確認作業をします。
なので上のような指示を残しておくと、二重に検証します。すでに終わっている確認作業を、もう一度やり直すわけです。当然その分だけトークンを使い、時間もかかります。
つまりこの指示は、料金と待ち時間を増やすだけの一文になりました。
どうすればいいか
消してください。 書き直すのではなく、消すのが正解です。
「消したら品質が下がるのでは」と心配になりますが、下がりません。モデルが自分でやるからです。
社内のプロンプト規約に「必ず自己検証の一文を入れること」と書いてあるチームは、けっこうあると思います。これまでは正しいルールでした。Opus 5 では、そのルール自体が足を引っ張ります。
規約を運用しているなら、Opus 5 は例外扱いにしてください。
ハーネス側（プロンプトではなく、呼び出す仕組みのほう）に組み込んだ検証ステップも同じです。「生成 → 検証 → 修正」というパイプラインを組んでいるなら、検証フェーズが本当に必要か一度外して試してみる価値があります。
逆転2: 「もっと分担して」が高くつくようになった
これまでの常識
Claude に複数の作業を任せるとき、サブエージェント（下請けのエージェント）に分担させると効率が上がります。ところが Opus 4.8 は、これをあまりやりたがりませんでした。
なので、こう書いて背中を押す必要がありました。
可能な限りサブエージェントに作業を委譲してください。
並列化できるタスクは積極的に分割してください。
Opus 5 で何が起きるか
Opus 5 は、放っておいても自分から分担します。
そこにさらに「もっと分担しろ」と書いてあると、必要以上に分担します。サブエージェントを立てるたびに、その子に状況を説明し、報告を受け取り、それを読む——というやり取りが発生します。数が増えれば増えるほど、料金も待ち時間も膨らみます。
つまり、Opus 4.8 のために書いた背中押しが、Opus 5 ではアクセルの踏みすぎになっているわけです。
どうすればいいか
促す指示を消したうえで、上限をはっきり決めるのが確実です。「必要なときだけ使って」のような曖昧な言い方より、数で縛るほうが効きます。
# Before（Opus 4.8 向け）
可能な限りサブエージェントに作業を委譲してください。
# After（Opus 5 向け）
サブエージェントの起動は最大 3 体までとします。
逆転3: effort を下げても、回答は短くならない
これまでの発想
Opus 5 は、以前より回答が長めになりました。
ここで多くの人が考えることは同じです。「effort（どれくらい念入りに取り組むかの設定）を下げれば、軽い回答になって短くなるだろう」
実際にはこうなる
短くなりません。
effort が変えるのは考える量です。書き出す文章の長さは、確実には変わりません。「念入りに考える」と「長く書く」は別のことなので、片方を絞っても、もう片方はついてこないわけです。
しかも effort を下げると、当然ながら回答の質のほうに影響が出ます。長さは変わらないまま、質だけ落ちるという一番おいしくない結果になりかねません。
どうすればいいか
短くしたいなら、素直にプロンプトで頼んでください。
実際のテストでは、短い一文を足すだけで回答の長さが約20%減っています。設定をいじるより、よほど効きます。
長いシステムプロンプトを使っている場合は、いちばん最後にこんな一行を置いておくと効果的です。
<tone_preference>
回答は簡潔に。前置きと要約の繰り返しを避ける。
</tone_preference>
ちなみに、ファイルに書き出すレポートやドキュメントも長くなっています。こちらは会話の長さとは別問題なので、成果物の長さは成果物として別に指示してください。
おまけの逆転: 「重大な問題だけ報告して」で見逃しが増える
これはコードレビューを自動化しているチーム向けの話ですが、いちばん怖い逆転かもしれません。
指摘が多すぎてノイズになるとき、こう書きたくなります。
重大な問題だけを報告してください。細かい指摘は不要です。
Opus 5 は、これを言葉どおりに守ります。バグはちゃんと見つけているのに、「これは重大ではない」と自分で判断したものを報告しなくなります。
結果として、報告件数は減り、見逃しが増えます。しかも報告されなかったバグは、当然ログにも残りません。「最近レビューが静かだな」と思ったら、実は素通りしていた——ということが起こりえます。
どうすればいいか
全部報告させて、選別は別の工程でやってください。
気づいた問題はすべて報告してください。確信が持てないものや、
軽微だと思うものも含めて構いません。
それぞれに「確信度」と「重大度」を付けてください。
重要度の判断は後段で行うので、ここでは網羅性を優先します。
「重大度を判断させない」のがポイントです。判断させると、律儀に切り捨ててしまうからです。
4つに共通していること
並べてみると、共通点が見えてきます。
| 指示 | 何のための指示だったか | Opus 5 では |
|---|---|---|
| 「検証して」 | 見落としを防ぐ補助 | 自分でやるので二重になる |
| 「もっと分担して」 | 苦手な分担を促す補助 | 自分からやるので過剰になる |
| 「effort を下げる」 | 出力を軽くする調整 | もともと効かない場所を触っている |
| 「重大な問題だけ」 | ノイズを減らす調整 | 律儀に切り捨てて見逃す |
上の2つは、モデルの苦手を補うために書いた指示です。モデルがその苦手を克服したので、補助輪が邪魔になりました。
下の2つは、モデルの出力を抑える指示です。指示に忠実になったぶん、抑えすぎるようになりました。
つまり Opus 5 では、こう考えるとうまくいきます。
- 背中を押す指示は減らす（勝手にやるので）
- 抑える指示は具体的にする（曖昧に抑えると効きすぎる）
「モデルが賢くなったぶん、こちらが手取り足取り教える必要が減った」と言い換えてもいいかもしれません。丁寧に作り込んだプロンプトほど、そのまま持ち込むと逆効果になります。
ついでに: コードのほうも2箇所だけ壊れます
プロンプトの話がメインですが、Opus 5 に乗り換えるならコード側にも必ず確認すべき点が2つあります。どちらもエラーが出ないまま壊れるタイプなので、簡単に触れておきます。
1. 何も指定しないと「考える」ようになった
Claude には、回答を書く前に内部で考える機能（thinking）があります。この設定が逆転しました。
-
Opus 4.8 / 4.7:
thinkingを書かなければ、考えない -
Opus 5:
thinkingを書かなければ、考える
問題は max_tokens です。これは「回答の長さの上限」だと思われがちですが、正確には出力全体の上限で、思考もここに含まれます。
【Opus 4.8】thinking を書いていない = 考えない
|<---------------- max_tokens ---------------->|
+----------------------------------------------+
| 回答 |
+----------------------------------------------+
【Opus 5】thinking を書いていない = 考える
|<---------------- max_tokens ---------------->|
+--------------------+-------------------------+
| 思考 | 回答 | <- ここで切れる
+--------------------+-------------------------+
max_tokens を小さめに設定していると、思考が先に容量を使い、回答が途中で終わります。しかもリクエストは成功（HTTP 200）で返ってくるので、エラーログには何も残りません。
thinking を書いていない箇所は、max_tokens を見直してください。
2. 断られたときも「成功」で返ってくる
Opus 5 は安全性のチェックが強化されていて、内容によってはリクエストを断ることがあります。
このとき、HTTP 200（成功）で返ってきて、stop_reason が "refusal" になります。例外は飛ばないので try / except では捕まえられません。
# Before: 断られたときに壊れる
text = response.content[0].text
# After: まず stop_reason を確認する
if response.stop_reason == "refusal":
print(response.stop_details.category) # "cyber" / "bio" など、断った理由
else:
for block in response.content:
if block.type == "text":
print(block.text)
セキュリティ関連や生命科学系の話題は、問題のない内容でもまれに誤って断られることがあります。「うちは関係ない」と決めつけないほうが安全です。
明日からやること
プロンプトから消すもの
自分のプロンプトを検索して、こういう趣旨の文があったら削除してください。
✂ 最後に検証ステップを実行してください
✂ 別のエージェントにレビューさせてください
✂ 回答する前に、もう一度確認してください
✂ 可能な限りサブエージェントに委譲してください
✂ 重大な問題だけを報告してください
代わりに足すもの
+ 回答は簡潔に。前置きと要約の繰り返しを避ける。
+ サブエージェントの起動は最大 N 体までとします。
+ 頼まれた範囲だけを実施してください。
+ 気づいた問題はすべて報告し、確信度と重大度を付けてください。
3つ目の「頼まれた範囲だけ」も入れておくと安心です。Opus 5 は、頼んでいないことまで気を利かせてやってしまうことがあるためです。
コードで確認するもの
-
thinkingを書いていない箇所のmax_tokensを見直す -
stop_reasonが"refusal"のときの分岐を入れる
まとめ
Claude Opus 5 で逆転したのは、次の4つでした。
- 「検証して」は消す — 言わなくても自分でやるので、指示すると二重になる
- 「もっと分担して」は上限に変える — 放っておいても分担するので、促すと過剰になる
- 短くしたいなら effort ではなくプロンプト — effort は考える量を変えるだけで、文章の長さは変わらない
- 「重大な問題だけ」は見逃しを生む — 律儀に切り捨てるので、全部出させて後で選別する
共通しているのは、モデルの苦手を補うために書いた指示が、苦手でなくなった今は邪魔になっているという点です。
これは Opus 5 に限った話ではないはずです。モデルが賢くなるたびに、昨日までのベストプラクティスが今日の技術的負債に変わります。プロンプトも定期的に棚卸しする対象だ、と考えておくのがよさそうです。
まずは自分のプロンプトを開いて、「検証してください」を検索してみてください。たぶん、見つかると思います。
JQITのエンジニアの95%以上は未経験からの採用です。
よければコーポレートサイトにも遊びに来てください。
エンジニア採用も行っています。もしご興味あれば覗いてみてください。
▶ 採用サイト