Opus 5、結局どう付き合えばいいのか

Opus 5が出てから、性格の違う情報がいくつも出てきました。公式のプロンプトガイド、ベンチマークの実測、Claude Codeで挙動が変わったという報告。どれも面白いのですが、単体で読むとバラバラに見えるので、一本の筋として整理してみます。

結論から書くと、Opus 5への適応はこの一文にほぼ集約されます。

モデルが自力でやるようになったことは指示から消す。モデルも本体promptも規定しなくなったことを指示で埋める。

削る場所と足す場所を取り違えると、コストだけ増えて品質は上がらない、という状態になります。以下、その中身です。

能力の話：一段跳んだが、跳んだ場所に癖がある

数字の面では、新世代の通常設定（effort=high）が前世代の最大設定を上回る、というあたりが一番わかりやすい変化です。コーディング系のベンチだと初の90点台という報告も出ていて、素の実力が上がったのは間違いないと思います。

面白いのは伸びた場所で、アクセシビリティとコンポーネント設計が特に動いています。a11yは長らく「Claudeの弱点、GPT系の強み」と言われてきた領域なので、ここが逆転したのは地味に効きます。

一方で、スコアの高さから期待するほどにはモダンなAPIを使ってこないという指摘もあって、これは実感とも合います。Reactで言えば並行機能がほとんど出てこず、手動メモ化はむしろ増えている。React Compilerを入れているコードベースだと、この書きぶりは「コンパイラを信用せず手で抱え込んでいる」評価になりかねません。

なので、モダンAPIを使わせたいならスコアの高さに任せず、プロンプトかlintで明示したほうが早いです。Opus 5は指示に文字通り従う傾向が強いので、言えば素直に従います。

effortの話：起点が下がった

Opus 4.8の頃は「コーディングならxhighから」でしたが、Opus 5ではhighが起点になりました。公式の推奨を整理するとこうなります。

起点が一段下がったうえに、下方向にも積極的に振ることが推奨されている、という構図です。

実測系の記事を見ても、high→maxの伸びは前世代より小さくなっています。以前はmaxを焚かないと届かなかった水準にhighで届いているので、常用はhigh、maxは上積みを買うオプションという整理でよさそうです。

ここで見落としがちなのが、maxは「安定して良くなる」わけではないという点。難所での分布が押し広がる挙動で、うまくいった回は跳ねるが外すとhighと同水準に落ちる。期待値は上がるけれど当たり外れも大きくなる。CIやバッチのように再現性が欲しい用途はhigh固定が無難で、maxはn=1で評価してはいけないやつです。

仕様面で押さえておくこと：

• 思考はデフォルトで有効。無効化できるのはhigh以下のeffortのみ
• 推奨は「思考をオフにする」ではなく「思考オンのままeffortを下げる」。低effort＋思考ONのほうが、同コストで思考OFFより性能が出る
• xhigh/maxで走らせるならmax_tokensを大きめに
• 旧モデルから引き継いだeffort設定は、そのまま再利用せず評価をやり直す

そしてこれが地味に重要なのですが、effortは応答の長さを制御しません。制御するのは思考量です。Opus 5はデフォルトの応答が以前より長いのですが、「長いからeffortを下げる」は効かない打ち手。長さはプロンプトで指示します。

プロンプトの話：足すより削る

ここが一番の変化だと思います。公式ガイドが挙げている調整項目を、削る／足すで並べ替えるとこうなります。

以下、それぞれの中身です。

削るもの

検証の指示。 Opus 5は言われなくても自分の作業を検証します。なので「最終検証ステップを含める」「サブエージェントで検証する」といった指示は過剰検証を招くだけで、消しても品質は落ちません。公式ガイドが「削除してください」とまで書いているのが印象的でした。ハーネス側に独立した検証ステップを仕込んでいる場合も同じです。

再確認・ダブルチェックの指示。 自己修正も同様で、モデルが既にやっていることを指示すると重複してコストだけ増えます。CLAUDE.mdに「必ずダブルチェックすること」があるなら消す対象。

レビュープロンプトの「保守的に」。 これは削り方に注意が要ります。Opus 5は指示を文字通りに取るので、「重大度の高いものだけ報告」と書くと本当に報告が減ります。発見フェーズは全部出させて、フィルタは別パスでやる。役割を分ける形が推奨されています。

思考OFF運用をしているなら「推論するな」系のルール。 内部タグが可視応答に漏れる確率が上がるそうです。そもそも思考はONのまま使うのが推奨なので、この運用自体を見直すのが先ですが。

足すもの

簡潔さの指示。 短い一文で効きます。「応答は焦点を絞って簡潔に。免責や注意書きは短く、大部分を本題に使う。説明を求められたら、詳細を明示的に求められない限り高レベルの要約を返す」くらいの温度感。長いシステムプロンプトなら、末尾近くにもう一度短いリマインダーを置くとよいとされています。置き場所は毎回のプロンプトよりCLAUDE.mdが実用的でしょう。

成果物ドキュメントの長さ調整。 会話の冗長性とは別に、ディスクに書き出すレポートやMarkdownも長くなります。「必要な長さに合わせ、水増しの節や重複する要約で埋めない」を明示。

スコープの制約。 頼んでいないステップを足したり、タスクの解釈を勝手に広げたりすることがあります。「依頼された範囲を依頼されたスコープで届ける」「ルーチンな判断は自分で下し、解釈の違いが実質的に違う作業になるときだけ確認する」「依頼が間違っていそうなら一文で指摘してから依頼どおり進める」あたりを書いておく。

サブエージェントの上限。 以前より積極的に委任します。大きく独立した作業では効きますが、小タスクに使うとコストと時間が倍増する。「本当に独立・並列化できる大きい作業に限る」「数回のツール呼び出しで終わる作業は委任しない」「自分の作業の検証に使わない」「1つで足りるなら1つ」を書くか、ハーネス側で起動数に上限を置く。

訂正のナレーション制限。 自分の以前の発言への訂正をやたら宣言する傾向があります。「ユーザーのコードや結論や判断が変わる誤りのときだけ訂正し、簡潔に述べて作業を続ける。何も変わらない言い間違いは黙って直す」で絞れます。

Claude Codeで「思考が浅くなった」と感じる問題

これは公式ガイドに書かれていない領域で、個人的には今回一番面白かった話です。

rulesを一切変えずモデルだけ切り替えたのに、応答がフラットな散文になる、原因説明が1層で止まる、複数案に評価軸が付かない、発話に返答せずいきなり作業に入る——という報告が出ています。しかも「もっと深く考えて」と促し直しても効かない。単発の回答品質ではなく、対話を通じた検討そのものが成立しなくなるタイプの劣化です。

原因はrules側の劣化ではなく、Claude Codeが配る本体system promptがClaude 5世代で大幅に削減されたこと。lean system promptとしてchangelogにも載っています。そしてOpus 5に配られるものには、応答の書き方を規定する文が入っていない。散文か構造か、見出しや表の使い方、簡潔さ——旧世代に書かれていた規定が丸ごとない。加えて「十分な情報が揃ったら動け」「網羅的な調査ではなく推奨を出せ」という自律方針が入っている。

これで症状は全部説明がつきます。書き方の規定がないので素の出力傾向がそのまま出る。「網羅より推奨」が評価軸の省略を後押しする。「揃ったら動け」が返答より先の作業着手を後押しする。

空白は「こちらの余白」ではない

ここが一番効く洞察でした。

「規定が空白なら、こちらのrulesが唯一の規定になってむしろよく効くのでは」と思いたくなるのですが、実際は逆です。この空白は利用者に委ねられた余白ではなく、訓練で焼き込まれたモデルの既定動作に委ねられたもの。lean promptは「細かく書かなくても新世代モデルは内在化した行動に従う」前提で削られているので、削られた規定の代わりを埋めるのはこちらのrulesではなくモデルの学習済み既定です。

そして興味深いことに、同じClaude 5世代でもモデルによって配られるpromptが違う。Fable 5には応答形式の規範を持つ節があるので出力の形が崩れにくい。Opus 4.7はlean prompt適用外なので旧世代の長いpromptのまま。Opus 5で強烈に出るのは、規定ゼロのprompt・即作業を促す方針・旧前提のrulesという3つが同時に揃うから、という整理です。

直し方

一般論の追記では負ける。 「複数案には評価軸を付ける」と書いてあっても症状は出ます。本体の「網羅ではなく推奨を」と並んだとき、モデルから見れば同じ話題に2つの指示があるだけで優先の手がかりがない。本体promptの原文を引いて名指しで優先を宣言すると、衝突と優先が明示されます。そもそも規定が存在しない項目については、上書きではなく「空白をこちらの定義で埋める」指示として働きます。

禁止ではなく望ましい動きを書く。 「〜するな」は違反の検知には使えても、代わりに何をすべきかを運びません。「テスト未完了でcommitを提案するな」ではなく「commitを提案する時は、その成果物を使う人の操作手順で動かした結果を本文に書く」。発火条件も「重要な変更のときは」のような自己分類頼みではなく、「interruptを受けた」のような解釈の余地がない観測で書く。強調マーカーもセキュリティと承認ゲートだけに絞る。全部が強調されている文書は、何も強調されていない文書と同じです。

そして、どの層で届けるか。 これが実は一番効きました。Claude Codeには指示を届ける経路が複数あって、効き方が違います。本体system promptは最強だが変更不可。CLAUDE.md等の常時rulesは会話履歴の先頭、つまり行動から最も遠い。output styleは毎ターンのattachmentとして届くので中くらい。UserPromptSubmit hookは最新のユーザー発話の直後、行動に最も近い位置に入るので強い。

実際、「構造で書く」のような書き方はoutput styleで改善傾向が出る一方、「発話に返答せず作業に入る」癖はoutput styleでは止まらず、hookで毎発話の直後に一行注入して初めて止まった、という観察が報告されています。コストは1発話あたり50トークン程度なので誤差です。

一般則としては、変えたい行動の直前に、短く、毎回届ける指示がいちばん効く。効かない指示の多くは、内容が悪いのではなく行動の瞬間に手元に届いていない。これは覚えておいて損がないと思います。

「削れ」と「書け」は矛盾していないのか

公式は「検証指示を削除しろ」と言い、現場の記事は「応答形式を書け」と言う。逆のことを言っているように見えますが、基準は同じです。

• 削るのは、モデルが既にやることと重なる指示（検証、再確認、ダブルチェック）
• 書くのは、モデルも本体promptも規定していない空白（応答形式、スコープ、簡潔さ、委任の上限）

要するに「既定動作と重なるものを消し、既定に無い／既定と逆のものだけを書く」。本体promptと自分のrulesを突き合わせて矛盾を洗い出す、という手順は、この基準を機械的に実行しているだけとも言えます。

ついでに、モデル間でスニペットを使い回すのは危険です。公式ガイドはモデルごとに出ていて、並べると「デフォルト挙動」と「プロンプトで補うべき方向」がはっきり違います。

サブエージェントの行と検証の行が、モデルによって真逆を向いているのがわかると思います。特に「委任を促す指示」と「検証を指示する指示」は、旧モデル向けのCLAUDE.mdやスキルにそのまま残っていることが多いので、Opus 5に乗り換えるならここは必ず見直す価値があります。似た性格の別物として扱うのが安全です。

やることリスト

手元のCLAUDE.md／rules／ハーネスを開いて、上から順に。

削る

• 「検証して」「最終検証ステップ」を検索して削除
• 「再確認して」「ダブルチェックして」を検索して削除
• ハーネス側の独立した検証ステップを見直す
• レビュープロンプトの「保守的に」「重大度の高いものだけ」を外し、フィルタは別パスへ

足す

• 簡潔さの指示を常設（長いプロンプトなら末尾にもリマインダー）
• 成果物ドキュメントの長さ調整
• 狭いタスク向けのスコープ制約
• サブエージェント委任の条件と上限
• 応答形式の規定（Claude Codeでは特に）

設定

• effortはhigh起点で評価し直す。旧モデルの設定を引き継がない
• 品質が保てる範囲でlow/mediumをコスト制御の主手段に
• 思考はONのまま、コストはeffortで絞る
• maxは再現性が落ちる前提で使う

書き方

• 禁止形を、望ましい動きの記述に変換
• 発火条件を、自己分類ではなく観測可能な事実で書く
• 強調をセキュリティ・承認ゲートだけに絞る
• 本体方針と張り合うruleは、原文を名指しして優先を宣言
• 効かない指示は、内容ではなく届く層を疑う

おわりに

旧モデル向けに積み上げた「ちゃんとやらせるための指示」は、新モデルでは過剰品質とコスト増の原因になります。一方で、promptが軽くなったことで空いた「書き方」の穴は、誰かが埋めないとモデルの素の傾向がそのまま出る。

削る場所と足す場所を取り違えないこと。それがOpus 5移行の実務のほぼ全てだと思います。そしてどちらの作業も、まず本体promptと公式ガイドを読んでから始めるのが結局は近道でした。モデルの更新は、本体system promptの更新でもあるので。

同じところで詰まっている方の参考になれば幸いです。

参考

• Claude Opus 5のプロンプティング（公式）
• Effort（公式）
• Opus 5では今までのプロンプトが逆効果に。「検証して」を消して「簡潔に」と書くべし
• Opus5が思考が浅いように感じる問題への対策
• 【速報】Opus 5、React習熟度ベンチマークで余裕のFable 5超え