Opus 5.5のチャットで「think carefully」を外す理由

Opus 5.5では「じっくり考えて」の指示を外すと速くなる

チャットアプリのシステムプロンプトに「回答前にじっくり考えて」のような指示を書いている場合、Claude Opus 5.5ではその行を外すと、応答が速く始まります。Opus 5.5はどれだけ思考するかを自分で判断するモデルで、思考量を外側から直接コントロールする手段はeffortパラメーターです。Anthropicのチャット製品でのテストでは、この種の指示行を外すと、返信の品質に目立った低下がないまま応答開始が速くなりました。

Claude Opus 5.5はOpus 5より出力トークンの生成が30%以上速く、同じタスクをより少ないトークン数で終える傾向があります。既存のOpus 5向けプロンプトは変更なしでも動きます。ただし「じっくり考えて」型の指示は、Opus 5.5の特性と噛み合わなくなった代表例です。

なぜ外すと応答が速くなるのか

Opus 5.5では常にthinkingが有効で、モデルは入力の複雑さに応じて自分で思考の深さを決めます。思考量を動かす主要な手段はeffortで、既定値はmediumです(Opus 5の既定はhighでした)。Opus 5.5のmediumは、コーディングや知識作業の評価でOpus 5のhighと同等かそれ以上でした。effortを省いたリクエストは、Opus 5のときより1段低いmediumで動くことになります。

この構造の下では、システムプロンプトに「じっくり考えて」と書いても、思考量への効き方はeffortほど直接的ではありません。effortを下げる方が、思考量とともにコストとレイテンシーをプロンプトの指示より確実に減らせます。

effortの段階名は、モデルをまたいで同じ思考量を意味しません。いくつかのコーディング評価では、Opus 5.5のlowがOpus 5のhighに近い水準まで届いています。しかもlowのコストは大幅に低くなります。

Opus 5から引き継ぐときに膨らむもの

Opus 5で使っていたeffortの値をそのまま持ち込むと、ターンが長くなり出力トークンが増えます。同じ段階で比べると、Opus 5.5はOpus 5より1ターンあたりの思考が多く、xhighとmaxで差が目立つためです。公式ガイドは、Opus 5の設定をそのまま持ち込まず、自分の評価データで複数の段階を試すよう勧めています。調整は3つあります。

多ターンで前の回答を掘り返す挙動を止める2文

チャットでの「じっくり考えて」削除とは別に、Opus 5.5には多ターン特有の挙動があります。会話が続く中で、短い追加質問に答えるときでも、新しいメッセージを考えながら前の回答を思考の中で見直すことがあり、後続ターンの思考とレイテンシーを押し上げます。

前の回答を決着済みとして扱わせたいときは、システムプロンプトの末尾に2文を加えます。公式の英文を日本語に直すと次のとおりです。

一度答えた内容は、完了したものとして扱う。以降のターンでは、いまユーザーが尋ねていることに思考を集中し、ユーザーがその回答について尋ねるか問題を指摘しない限り、過去の回答を見直さない。

この指示は、思考の対象を「いま尋ねられていること」に絞ります。Anthropicのテストでは、後続ターンの思考が減り、回答開始も速くなり、品質への影響は出ませんでした。

この2文を入れる場面と入れない場面

2文は常に有効なわけではありません。モデルが過去の出力を見直し続けること自体に価値がある場面では、入れない方が合います。

もう一つ、公式が書いている副作用があります。この指示を入れると、モデルが過去の回答の誤りを自分から指摘する可能性が下がるかもしれません。誤りの自己発見が重要な用途では、採用前に自分のトラフィックで試します。

後続ターンだけeffortを下げる

会話の途中から思考量を変えたいときは、トップレベルのeffortを書き換えずに、メッセージ単位の指定を使います。Opus 5.5が対応しているやり方で、プロンプトキャッシュを保ったまま切り替えられます。ベータ機能で、ベータヘッダーmid-conversation-output-config-2026-07-01が必要です。

messagesの途中に、contentを空にしたrole: "system"のメッセージを置き、新しい段階をoutput_config.effortに書きます。新しい段階は次のuserターンから効き、後のメッセージで変えるまで続きます。それまでのメッセージは変わらないため、キャッシュされた接頭辞とも一致します。

{"role": "assistant", "content": "…前のターンの回答…"},
{"role": "system", "content": [], "output_config": {"effort": "low"}},
{"role": "user", "content": "いまの内容を1文でまとめて"}

これは公式ドキュメントの例を、チャット向けに言い換えた断片です。メッセージ単位の変更に対応していないモデルでは、次のリクエストに新しいトップレベルの値を書くことになり、そのたびにキャッシュが最初からやり直しになります。Opus 5.5では、段階を変えたいターンがあるチャットほど、この違いが効いてきます。最初のターンはhighで深く考え、定型の追加質問はlowで素早く返す、という切り替えに使えます。5つの段階は次のように使い分けます。

レイテンシーが重視されない用途では無理に外さなくてよい

ここまでの根拠は、チャット製品でのテストです。ユーザーが画面の前で応答を待つ用途では、開始の速さがそのまま待ち時間として見えます。「じっくり考えて」を外す判断は、この用途で最も当てはまります。

バッチ処理や夜間実行のレポート生成のように、応答までの時間をユーザーが待たない用途では、開始の速さを優先する理由が薄くなります。そうした用途まで一律に外す必要はありません。指示を外すかどうかは、その用途でレイテンシーが実際にボトルネックになっているかで決めます。effortを上げる場合は、xhighとmaxに品質向上を計測できた作業だけを回す、という前述の条件に従います。

Opus 5とOpus 5.5でシステムプロンプトの前提はどう変わったか

「じっくり考えて」の扱いが変わった背景には、思考量の既定の制御方式そのものの変化があります。

Opus 5ではhigh以下のeffortでthinking: {"type": "disabled"}を選べました。Opus 5.5では、どのeffortでもこの指定が400エラーになります。thinkingを無効にしていた実装の移行手順は、Claude Opus 5.5でthinking無効のプロンプトを移行するにあります。

その移行の文脈では、公式ガイドは4つの変更を挙げています。lowから始めて計測すること、思考の代わりに推論を返信へ書かせていた指示を外すこと、thinking無効用の対策を再点検すること、レスポンスをブロックの種類で読むことです。最初のトークンまでの時間がなお気になるなら、システムプロンプトに「Answer directly without deliberating.」のような1行を足すと、思考をさらに減らせます。ただし思考が減ると品質が下がることもあるため、足した後に品質を測ります。

推論を返信本文に書き出させる指示には、別のリスクもあります。Opus 5.5では、モデルの内部推論を返信テキストで再現させようとする依頼が、reasoning_extractionの区分で断られることがあります。そうした指示を使っていたら外し、display: "summarized"で要約された思考ブロックから読む形に移します。

見直しの手順

既存のシステムプロンプトは、次の順で点検すると判断しやすくなります。

Opus 5.5以外のモデルにもそのまま当てはまるか

ここで紹介した根拠は、公式ガイドがClaude Opus 5.5に限って示したテスト結果です。Opus 5、Sonnet 5.5、Fable 5.1の各ガイドには同じ記述がありません。モデルを混在させて運用するチャット製品では、モデルごとにシステムプロンプトを出し分ける運用があります。他のモデルに同じ変更を当てるなら、そのモデルとプロンプトでの応答速度と品質を個別に測ります。

effortのページでは、Sonnet 5.5の既定はhighで、チャットのようにレイテンシーを重視する用途はmediumかlowから始めるとされています。既定がmediumのOpus 5.5とは出発点が違うため、混在運用ではeffortの値もモデルごとに決めることになります。

まとめ

思考量を動かすのは指示行ではなくeffortです。ユーザーが待つチャットでも、誤りの自己指摘が大事な用途では、2文で速さを買う代わりに指摘が減る点を、自分のトラフィックで天秤にかけます。

effort変更とキャッシュの関係はthinking設定を変えるとプロンプトキャッシュのヒット率が下がる理由にあります。

thinkingブロックの読み取りはthinkingのdisplay: summarizedとはで扱っています。