やす研究所 AI Lab
戻る

Claude Extended Thinking実践2026:effortで思考予算を制御する設計

Claude Extended Thinking実践2026:effortで思考予算を制御する設計

Claude API で budget_tokens を指定するコードをそのまま Opus 4.7 に投げたら、いきなり 400 エラーで落ちました。

2026 年前半に Anthropic は Extended Thinking の指定方法を静かに切り替えていて、知らないと請求書で殴られるか、コードが動かないかの二択になります。私自身、Sonnet 4.6 と Opus 4.7 を 2 週間ほど混在で運用して、ようやく effort と adaptive thinking の塩梅が掴めてきた感触があります。この記事では、その実装パターンを最短ルートで共有します。

結論:effortパラメータと adaptive thinkingに切り替える

先に答えを書きます。2026 年 6 月時点で Claude の Extended Thinking を新規に組むなら、次の 3 点を押さえれば事故りません。

この 3 つを外すと、コードが動かないか、月の API 請求が想定の 2〜3 倍に膨らみます。実際、Opus 4.7 で effort を脳死で high に固定すると、1 人あたり月 2,000 ドル前後まで膨らむケースが報告されています。

なぜbudget_tokensは廃止されたのか

Claude 4 系の初期(Sonnet 4 / Opus 4)では、Extended Thinking を有効にするときに thinking: {type: "enabled", budget_tokens: 10000} のように、思考に使うトークン上限を整数で指定していました。

これが Opus 4.7 で挙動が変わります。Opus 4.7 では budget_tokens が deprecated になり、effort パラメータでしか adaptive thinking を受け付けません。古いサンプルコードをそのままコピペすると即落ちる、というのが現状です。

なぜか。Anthropic 側で「簡単な質問には少なく、難しい質問には多く」を自動配分する adaptive thinking が成熟したからです。固定の budget を渡すより、モデル側で動的に決めるほうがコスト効率が良くなった、というのが私の理解です。

Sonnet 4.6 / Opus 4.6 と Opus 4.7 の違い

少しややこしいのが、モデルごとに挙動が分かれている点です。私が実機で触った範囲だと、こういう住み分けになっています。

出力トークンの上限も差があり、Opus 4.6 / 4.7 / 4.8 は 128k、Sonnet 4.6 と Haiku 4.5 は 64k までサポートされています。長文の出力を出す予定があるなら、ここはモデル選定の判断材料になります。

effort パラメータの選び方:4段階の使い分け

effort は low / high / xhigh / max の 4 段階。直感的には「低いほど安く、速く、思考が浅い」です。私の実運用での目安はこんな感じです。

low:雑談・分類・短文要約

短い質問への返答、メール分類、ラベリングのような決定が軽いタスク。これに high 以上を当てるのは完全に無駄打ちです。私は最初、社内 Slack ボットを全部 high で動かしていて、月末に請求を見て青ざめました。

low に落としてからは品質はほぼ変わらず、コストだけ落ちた印象です。

high:コード生成・中規模のリファクタ

Claude Code や Agent SDK のデフォルト相当だと思って差し支えありません。50〜200 行程度のコード生成、テスト作成、ドキュメント執筆。9 割のユースケースはここで足ります。

xhigh:複雑なバグの原因究明・設計レビュー

複数ファイルにまたがる調査、再現条件の絞り込み、アーキテクチャ提案。ここから「明らかに考えてる」アウトプットになります。ただし応答時間が体感で 2〜3 倍に伸びるので、対話 UI に直結させるとユーザーが離脱しがちです。

max:数学的証明・複雑な最適化

正直、日常業務ではほぼ使いません。SAT ソルバー的な探索、複雑な制約付き最適化、長い数学的論証あたり。コスト感覚としては、low の 10 倍以上を覚悟する場面と思っています。

実装サンプル:Python での最小コード

抽象論ばかりだと使えないので、最小コードを置いておきます。Sonnet 4.6 と Opus 4.7 で書き分けが必要なのが地味なポイントです。

import anthropic

client = anthropic.Anthropic()

# Opus 4.7 以降:effort で指定
response = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=16000,
    thinking={
        "type": "enabled",
        "effort": "high",  # low / high / xhigh / max
    },
    messages=[
        {"role": "user", "content": "このSQLが遅い原因を特定してください: ..."}
    ],
)

for block in response.content:
    if block.type == "thinking":
        # 思考の要約。Claude 4 系は要約版のみ返す
        print("[thinking summary]", block.thinking)
    elif block.type == "text":
        print(block.text)

注意点を 2 つ。thinking ブロックは要約版が返ってきますが、課金は要約前の 完全な思考トークン量 に対して発生します。請求の出力トークン数とレスポンスの可視トークン数が一致しないのは、これが理由です。

もうひとつ、Tool Use と組み合わせるときは、前ターンの thinking ブロックを 改変せず API に戻す必要があります。ここを省略するとモデルの推論が分断され、回答品質が露骨に落ちます。

interleaved thinkingとツール呼び出しの組み合わせ

ここからが Opus 4.6 / 4.7 / Sonnet 4.6 の本領発揮ゾーンです。

通常の Extended Thinking は「最初に長考 → 一気に回答」ですが、interleaved thinking はツール実行のたびに再思考します。

エージェント的なワークフローで効果が大きく、Opus 4.6 / Sonnet 4.6 では adaptive thinking 込みで自動オンになっています。それ以外の Claude 4 系で明示的に有効化したいときは、ベータヘッダ interleaved-thinking-2025-05-14 を付ける形です。

私の体感では、複数ステップの調査タスク(SQL → ログ参照 → 修正案提示など)で、ツール呼び出し回数が 30〜40% ほど削れました。途中で「これ違うな」と気づいて方向転換してくれるからです。

プロンプトキャッシュとの相性:キーに thinking 設定が入る

「Extended Thinking を使うとキャッシュが効かない」と勘違いしている人が一定数いますが、半分正解、半分間違いです。

公式ドキュメントによると、プロンプトキャッシュのキャッシュキーには thinking の設定が含まれます。つまり、こうなります。

もうひとつ、Opus 4.5+ と Sonnet 4.6+ では、過去ターンの thinking ブロックがキャッシュ済みプレフィックスに残るようになりました。それ以前のモデルでは、過去の thinking ブロックは毎回コンテキストから削除されます。長い対話で「なぜか過去の推論を忘れる」と感じたら、モデルバージョンを疑うと良いです。

実践的なルール:effort はリクエスト種別で固定する

運用上の鉄則として、私は エンドポイントごとに effort を固定 しています。「同じ種類のリクエストは同じ effort」にしておけば、キャッシュヒット率が大きく崩れません。

ユーザーごとに動的に切り替える設計は、見た目は柔軟ですが、キャッシュ効率の観点では地雷です。

コスト感覚:high を当たり前に使わない

2026 年 5 月時点の公式ベンチで、Opus 4.8 は SWE-bench Verified で 88.6% を達成しています。性能は文句なしですが、effort を上げれば請求もリニアに伸びます。

コスト最適化のセオリーは 3 つだけです。

  1. デフォルトは Sonnet 4.6 + effort: high。これで 90% のタスクは足りる
  2. 失敗したものだけ Opus 4.7 / 4.8 にエスカレーション(再試行は xhigh)
  3. プロンプトキャッシュとバッチ API を併用する。両方使うと実効コストが 90% 以上削れるケースもある

私の感覚だと、Sonnet 4.6 で済むタスクを Opus 4.7 max で処理するのは、自宅から駅まで F1 マシンで通勤するようなものです。性能は出ますが、目的にまったく合っていない。

まとめ:今日からやる4つのアクション

長くなったので、今日のうちに手を動かしてほしい順に整理します。

  1. 既存コードの budget_tokens を全部洗い出し、Opus 4.7 系を呼んでいる箇所は effort パラメータに置き換える
  2. エンドポイントごとに effort を固定し、low / high / xhigh / max のどこに置くか決める
  3. プロンプトキャッシュを使っているなら、effort 変更がキャッシュ破棄を招くことを意識して設計を見直す
  4. Tool Use と組み合わせる場合は、過去ターンの thinking ブロックを 無改変で 再送する処理を実装する

Extended Thinking は「賢くなる魔法のスイッチ」ではなく、コストと品質のダイヤルです。effort をシーンに応じて回せるようになると、Claude API の運用は一段ラクになります。

次は、この effort 設計を Agent SDK 側のサブエージェントに反映していく流れを別記事で書く予定です。

参考リンク

この記事をシェア:
X で共有 Facebook で共有 Telegram で共有
次の記事
AIプロンプト販売で稼ぐ実践設計図|ニッチ特化パックの作り方2026