Claude Haiku 5.5の思考を減らすには — 「直接答えて」でなくeffortを下げる

Claude Haiku 5.5で定型の確認ターンまで思考が走ってしまうとき、ユーザーターンに「Answer directly without deliberating.」を足しても、思考は確実には減りません。効くのは文面ではなくeffortです。会話の途中でターンごとに下げたいなら、メッセージ単位のeffort変更(ベータ)を使います。

この記事は、その「文面が効かない」点と、代わりに使う2つの手段(effortの引き下げ、メッセージ単位のeffort)の書き方に絞っています。

「直接答えて」の一文はHaiku 5.5で何を保証しないか

ユーザーターンの末尾に一文を足してターン単位で思考を誘導する方法は、Claudeの思考の仕組みの一部として書かれています。「Please think hard before responding.」を足すと思考を促し、「Answer directly without deliberating.」を足すと思考を抑える、という使い方です。エージェントの実行基盤が、計画ステップでは前者を、定型の確認ステップでは後者を付ければ、システムプロンプトにもリクエストのパラメーターにも触れずに済みます。

ところがHaiku 5.5では、この抑制側の一文が思考を確実には減らしません。Steering thinkingのページは、Haiku 5.5に「直接答えて」とプロンプトで伝えても思考は止まらなかったと、Anthropicのテスト結果として書いています。Haiku 5.5のプロンプトガイドにも同じ記述があります。システムプロンプトで思考を減らすよう頼む方法もSonnet 5.5では確実に効かないと書かれていて、2つの新しいモデルは「文面で減らす」前提を置けません。

押さえておきたいのは、この記述が「効かない」と断定していないことです。ページの言い方は「確実には減らさない」で、減る場面があるかどうかは述べていません。つまり、効いたように見えるターンがあっても、それを設計の前提にはできません。

思考を減らす順番はeffort、次にメッセージ単位

思考を減らす手段は、効き方の確かさで並べると次の順になります。

ドキュメントはステップを2つに分けています。まず、ワークロードの標準的な品質と遅延の釣り合いに合うeffortを決めます。そのうえで、そのeffortでも思考の出方が合わないときだけプロンプトで足します。順番が逆になると、文面のわずかな言い回しの差に結果が左右されます。

まずeffortを下げる

Haiku 5.5はeffortの5段階(low、medium、high、xhigh、max)をすべて使え、既定はmediumです。lowは最も安く速い水準で、チャットや短いツール作業、単純で件数の多い処理に向くとされています。

{
  "model": "claude-haiku-5-5",
  "max_tokens": 4096,
  "output_config": { "effort": "low" },
  "messages": [{ "role": "user", "content": "..." }]
}

effortはoutput_config.effortに置きます。thinkingオブジェクトの中ではありません。lowでは長いエージェントプロンプトで検索を飛ばす、早めに止まる、確認を省くといった傾向が出やすい点は、同じページに注意書きがあります。会話全体をlowにするのが重い場合に、次のメッセージ単位の変更が役立ちます。

thinking: {"type": "disabled"}で思考そのものを切る手もあります。low、medium、highでだけ使え、xhighとmaxでは400エラーになります。後述のとおり、この設定にするとメッセージ単位のeffortが使えなくなります。

ターンごとに変えるならメッセージ単位のeffort

会話の大半はhighで回し、定型の確認だけlowにしたい、という場面には、メッセージ単位のeffort変更を使います。ドキュメントがHaiku 5.5について「文面の代わりに使う」と明記している手段です。

条件は4つあります。

• ベータヘッダーmid-conversation-output-config-2026-07-01が必要です。付けないと、messages.N.output_config: Extra inputs are not permittedという400エラーになります
• Claude APIとGoogle Cloudで使えます。Amazon BedrockではHaiku 5.5が対象外です
• role: "system"でcontentを空にし、output_config.effortだけを持つメッセージを差し込みます
• 変更は、次に新しい入力を持つuserターンから効き、後続のメッセージが変えるまで続きます

公式の例を、Haiku 5.5向けに組み替えると次のような形になります。最初のターンはhighで、続く定型の確認をlowにします。

import anthropic
 
client = anthropic.Anthropic()
 
response = client.beta.messages.create(
    model="claude-haiku-5-5",
    max_tokens=4096,
    output_config={"effort": "high"},
    messages=[
        {"role": "user", "content": "3ステップで移行計画を立てて。"},
        {"role": "assistant", "content": "1. エクスポート 2. スキーマ作成 3. 取り込みと検証"},
        # effortだけを持つシステムメッセージ。次のuserターンから効く
        {"role": "system", "content": [], "output_config": {"effort": "low"}},
        {"role": "user", "content": "計画を1文に要約して。"},
    ],
    betas=["mid-conversation-output-config-2026-07-01"],
)

これは公式のFable 5.1向けの例(モデル名と会話内容を差し替えた形)に沿った書き方です。実際にどの程度思考が減るかは、手元のトラフィックで測る必要があります。

メッセージ単位のeffortが「直接答えて」より扱いやすい理由

文面を足すのとメッセージ単位のeffortを使うのとでは、確実性のほかにもう1つ差があります。プロンプトキャッシュです。

トップレベルのeffortをリクエスト間で変えると、解決されたeffortの値がプロンプトにレンダリングされるため、キャッシュのブレークポイントが無効になります。メッセージ単位のeffortは、変更点より前のメッセージを書き換えないので、キャッシュされたプレフィックスが一致し続けます。長い会話を回すエージェントで、定型ターンだけ思考を軽くしたい場合は、この差が料金に出ます。

ドキュメントは、トップレベルの変更よりこの形を推奨しています。Fable 5.1の項には、トップレベルの変更だと前のレベルで書かれた自分の返答に引きずられやすいという注意があります。Haiku 5.5についての記述ではないので、同じ挙動が出るかはこのページからは分かりません。

400エラーになる組み合わせ

メッセージ単位のeffortで詰まりやすいのは、thinkingの設定です。

disabledでも、いま効いているレベルと同じ値を指定するだけなら、このエラーの条件には当たりません。差があるときだけ400になります。

もう1つ、モデルによって対応が違います。メッセージ単位のeffortに対応しないモデル(Fable 5など)でベータヘッダー付きで送ると、output_config.effort requires a model that supports per-turn effort; this model does notという400エラーです。Haiku 5.5から別のモデルへ切り替えて使うコードでは、モデルごとに分岐が要ります。

ここまでのエラー文言を、起きた症状から見分ける表にまとめます。

思考が減ったかの確かめ方

効いたかどうかは、応答の中身ではなく使用量で見ます。usage.output_tokens_details.thinking_tokensに、内部で生成された思考トークン数が入ります。表示される思考の要約ではなく、課金される側の数字です。output_tokens以下の値になります。

{
  "usage": {
    "input_tokens": 25,
    "output_tokens": 348,
    "output_tokens_details": {
      "thinking_tokens": 312
    }
  }
}

ストリーミングでは、この内訳は最後のmessage_deltaイベントにだけ出ます。進捗の表示まで作るなら、Agent SDKのthinking_tokensで思考中の進捗を表示するが参考になります。

比較のしかたはドキュメントの勧めどおり、代表的なトラフィックの一部を、変更あり・なしで流します。見る指標は4つです。

• 思考ブロックが付く割合
• 出力トークン数
• 遅延
• 難しいケースでの回答品質

思考を減らすと、推論が効く課題で品質が落ちることがあります。effortを下げるほうが、文面よりも調整のきく操作です。

また、思考ブロックは常に付くわけではありません。Claudeはリクエストごとに思考するかを決めるため、思考ブロックがない応答も正常です。「毎ターン思考ブロックがある」前提でアプリを組まないでください。

症状別の切り分け

effortを触っても思考の深さが変わらない場合は、別の原因を探します。thinkingの設定とeffortの組み合わせ、モデルごとの既定値の違いはeffortを変えてもthinkingの深さが変わらないときの原因切り分けにまとめてあります。Haiku 5.5全般のプロンプト調整はClaude Haiku 5.5のプロンプトガイド、Sonnet 5.5との選び分けはClaude Haiku 5.5とSonnet 5.5の違いが扱っています。

会話の途中にシステムメッセージを差し込む際の制約(置ける位置、tool_resultだけのターンの扱い)は会話途中のシステムメッセージの制約にあります。effort専用のシステムメッセージは本文を持たないので、その配置ルールの対象外です。どこにでも置けますが、効き始めるのは次の新しい入力を持つユーザーターンからです。ツール実行ループの中では、tool_resultだけを持つターンは新しい入力に数えないため、変更は次のユーザー入力まで待たされます。

まとめ

Haiku 5.5の定型ターンで思考を減らしたいなら、「直接答えて」の文面を足す前に、effortをlowに下げるかメッセージ単位のeffortを使います。会話全体を軽くするなら前者、ターンごとに切り替えたい・キャッシュを保ちたいなら後者です。後者を使うときはthinkingをadaptiveのままにしておくことが前提になります。文面は、effortを決めたあとの微調整に回すのが無理のない順序です。