Opus 5.5のトークン効率は「簡潔に」ではなくeffortで決まる

Opus 5.5のトークン効率を上げたくて、system promptに「簡潔に答えて」と足していませんか？ 公式ガイドを読むと、思考を減らす手段としてまず挙がるのはプロンプトの書き方ではなく effort の設定です。しかもOpus 5の設定をそのまま持ち越すと、トークンはむしろ増えます。

Opus 5.5のトークン効率はどこで決まるか？

公式ガイドによると、Opus 5.5はOpus 5より出力トークンの生成が30%以上速く、同じタスクをより少ないトークンで終える傾向があります。

「乗り換えれば勝手に安くなる」と思いますよね。ところが同じページには、Opus 5で使っていた effort の値を維持するとターンが長くなり、出力トークンが増えるという注意もあります。Opus 5.5では thinking が常時オンで、思考量を決める主要なコントロールが effort だからです。

Prompting Claude Opus 5.5

Behavioral differences from Claude Opus 5 and the prompting and harness patterns that address them: effort calibration, thinking behavior in API integrations and chat, progress updates, unattended and multiagent tasks, safeguard refusals, frontend design, complex visual inputs, multi-app workflows, and pasted text in user messages.

platform.claude.com

Opus 5の設定をOpus 5.5に持ち越すと、トークンは増える

まず変わるのがデフォルト値で、Opus 5の high はOpus 5.5では medium になりました。ややこしいのは、レベル名が同じでも思考量までは同じではないことです。

Anthropicのテストでは、Opus 5.5の medium がコーディングと知識労働の評価でOpus 5の high に並ぶか上回り、いくつかのコーディング評価では low もはるかに低いコストで近い水準を出しています。一方で、同じレベルならOpus 5.5のほうが1ターンあたり多く考える傾向があり、特に xhigh と max で目立ちます。

今の effort の値がOpus 5の頃のままなら、以前より重い設定で回っている可能性があります。low と medium を含めて自分のevalで測り直すのが先です。xhigh と max は、品質の向上を実際に測れた作業に限るよう、公式ガイドは勧めています。

max_tokens も見直しどころです。思考は表示されなくても max_tokens にカウントされるため、Opus 5で thinking をオフにしていた頃の上限のままだと、応答が途中で切れることがあります。長いエージェント型コーディングでは、モデル最大値の128,000がAnthropicのテストでうまくいったと書かれています。

思考を減らすなら、プロンプトよりeffort

公式ガイドの方針は明快で、思考を減らしたいならまずeffortを下げることです。プロンプトの指示より確実に、思考、コスト、レイテンシを減らせます。「簡潔に」は文面には効いても、思考量を狙って減らすならダイヤルを回すほうが早いということです。

Opus 5で thinking: {"type": "disabled"} を使っていた構成は要注意で、Opus 5.5はこれを受け付けません。代わりに low から始めて測り、それでも最初のトークンまでの時間が気になるなら、system promptに次の1行を足します。

Answer directly without deliberating.

「熟考せずに直接答えて」という意味で、思考をさらに減らせます。ただし思考が減れば品質も下がりうるので、足したあとは品質を測るのが公式ガイドの推奨です。

思考の代わりに「回答の中に推論を書き出して」という指示を、自分のsystem promptにまだ残していないか確認しておきたいところです。Opus 5.5ではこの指示を削除し、推論は display: "summarized" で要約された思考ブロックから読みます。本文に推論を再現させる指示は、reasoning_extraction という拒否カテゴリで断られることがあるからです。

Opus 5.5のプロンプトから「よく考えて」を消す

チャット用のsystem promptに「よく考えてから答えて」系の指示があるなら、Opus 5.5では削除を検討する価値があります。どれだけ考えるかはモデルが自分で決め、調整はeffortで行う前提だからです。Anthropicのチャット製品でのテストでは、この一文を消すと返答が早く始まり、品質の明確な低下はありませんでした。

もう1つ、マルチターンの会話では、短いフォローアップに対しても過去の回答を考え直し、思考とレイテンシが増えることがあります。私なら、社内FAQのボットのように追加質問が続くアプリから試します。対策は、system promptの末尾に足す2文です。

Once you have answered something, treat that answer as done. On later turns, focus your thinking on what the user is asking now, and don't go back over an earlier answer unless the user asks about it or points out a problem with it.

「一度答えたものは済んだものとして扱い、以降は今の質問に思考を集中する。ユーザーが尋ねるか問題を指摘しない限り、前の回答を蒸し返さない」という意味です。Anthropicのテストでは、フォローアップの思考が減って返答が早くなり、品質への影響は見られませんでした。

ただし、長い分析や、後のステップで前のミスが見つかるエージェント型タスクには入れないほうがよいです。前の回答の誤りを自分から指摘しにくくなる可能性があるので、それが困る用途なら、入れる前に自分のタスクで試しておきます。

effortの切り替えとプロンプトキャッシュ

トップレベルの effort をリクエスト間で変えると、プロンプトキャッシュが無効になります。軽い質問は low、重い質問は high のように切り替えたい場合は、個別のターンだけ変えられる per-message effort change（beta）を使うとキャッシュを保てます。指定方法は Effort のページにあります。

会話の途中で system prompt や tools を足すと、それまでの thinking ブロックが無効になります。無人実行向けの追記やユーザー通知用ツールは、最初のリクエストから入れておきます。

無言のツール呼び出しが続くときは、turn-scoped system message（clear_at: "next_user_message"）でリマインダーを足す方法があります。追記したまま残すのでキャッシュは一致し続け、エージェント型コーディングのテストでは長い無言区間のあるタスクの割合がおよそ半減し、コストに測定できる変化はありませんでした。それでも無言が続く場合、リマインダーは2〜3回で打ち止めにします。

無人エージェントのコスト削減は止め方で決まる

Opus 5.5は長いタスクの途中で進捗を報告し、一部はツール呼び出しなしのテキストでターンを終えます（stop_reason: "end_turn"）。

厄介なのは、無人のループがこれを完了と見なして作業がそこで止まってしまうことです。テキストだけのターン終了を報告として扱い、未完了の項目が残っていてブロッカーの記述もなければ、短いメッセージで続行を促します。

Your task list still has open items: migrate the remaining two endpoints and update their tests. Continue with them. If one is blocked, say what is blocking it.

「残り2つのエンドポイントの移行とテスト更新を続け、詰まっていれば原因を伝えて」という意味です。自動継続は2〜3回で止めるのがポイントです。

完全無人向けの追記例もありますが、ツール呼び出しと出力トークンがやや増えるうえ、人が確認できるhuman-in-the-loop用途には入れず、危険な操作の確認も省略しないというのが公式の但し書きです。

マルチエージェント構成なら、各メッセージの末尾に elapsed 340s / 1200s のような経過時間を付ける方法もあります。モデルは予算内に収めようとペースを配分し、たいていかなり早く終えます。予算は実際に使いたい時間より少し長めにし、強制停止ではないので自前のタイムアウトは残しておきます。予算を決められないなら経過時間だけを表示し、次の1文を足します。

Time matters here: do not spend time that can be avoided, and the earlier a correct result is obtained, the better.

「避けられる時間は使わない。正しい結果が早く出るほどよい」という意味です。effortを下げると作業そのものが減るのに対し、予算は主に並列で働くエージェントを増やします。縮めたいのが時間なのかトークンなのかで、触る場所が変わります。

Opus 5.5へ移行する前に見直す5か所

プロンプトに「簡潔に」を足す前に、次の5か所を点検してください。

1. effort を明示し、low と medium を含めて自分のevalで比べたか
2. max_tokens は思考トークン込みで足りているか
3. thinking disabled の代わりに書いた指示や「よく考えて」系の一文が残っていないか
4. effortをリクエストごとに切り替えていないか。system promptや tools を途中で足していないか
5. 無人ループの自動継続に2〜3回の上限があり、human-in-the-loop用途には入れていないか

どれも設定とsystem promptを読み返せば確認できるので、Opus 5の頃の名残がどれだけあるか棚卸ししてみてください。