Claude Opus 4.7 はエージェントループの何を変えたのか

この記事のポイント

「コーディングベンチマークで13%向上」という数字は、ベンチマーク慣れしたエンジニアにとって眉唾に映るかもしれない。だが今回ばかりは、裏側にある設計変更のほうが気になった。

Anthropicが2026年4月16日に正式リリースしたClaude Opus 4.7は、単なる性能向上版ではない。タスクバジェット・Adaptive Thinking・高解像度ビジョンの3機能は、いずれもエージェントループを設計するビルダー向けに作られた機能だ。公式ドキュメントを読んで気づいたのは、「モデルへの制御権を開発者に戻す」という一貫した意図だった。

背景：Opus 4.6の限界とエージェントループの課題

Claude Opus 4.6は高い汎用性を持つ一方、エージェントループで長時間タスクを走らせると予測不能なトークン消費が起きやすかった。サブエージェントを多く生成しすぎる、推論ブロックに過度のトークンを割く、コンテキストが膨らんでもブレーキがかからない——こうした問題を開発者がプロンプト側で何とかするしかない状況が続いていた。

CursorBenchのスコアが 58% → 70% に上がったのは、こうした自律的な質管理能力の向上と無関係ではないと思う。

タスクバジェット：エージェントループに「予算感覚」を持たせる

最も実用性が高いのがタスクバジェット機能だ。仕組みはシンプルで、エージェントループ全体（思考・ツール呼び出し・ツール結果・最終出力を含む）のトークン目標値を渡すと、モデルが残量をカウントダウンしながらタスクの優先順位をつけ、バジェット内で仕事を完結させようとする。

response = client.beta.messages.create(
    model="claude-opus-4-7",
    max_tokens=128000,
    output_config={
        "effort": "high",
        "task_budget": {"type": "tokens", "total": 128000},
    },
    messages=[
        {"role": "user", "content": "Review the codebase and propose a refactor plan."}
    ],
    betas=["task-budgets-2026-03-13"],
)

max_tokens との違いを押さえておくと使いやすい。max_tokens はリクエスト単位のハードキャップで、モデルはその存在を知らない。一方 task_budget はループ全体への「ゆるやかな目標」として渡され、モデルが自覚的に参照する。作業の絞り込みや、品質と速度のトレードオフ判断をモデル自身がおこなうのが設計上の肝だ。

ただし、タスクに対して過小なバジェットを渡すと、モデルが作業を不完全に終わらせたり実行を拒否する場合がある。最小値は 20,000 トークン。まず余裕のある値から試して徐々に絞るのが無難だ。品質優先のオープンエンドタスクには設定しないほうがよい、とドキュメントは明示している。

Adaptive Thinking：推論をいつ使うかを選べるようになった

Opus 4.6までの「拡張思考」は、有効にするとモデルが自由に思考トークンを消費する形だった。Opus 4.7ではこれが廃止され、Adaptive Thinking に一本化された。

変更点は大きく2つある。まず、thinking: {type: "adaptive"} を明示しない限り思考はデフォルトでオフになった。意図せず推論が走ってトークンが膨らむ事故が減る。次に、思考ブロックの内容はデフォルトで空として返却される——ストリーム上には表示されるが、thinking フィールドは空だ。推論の経緯をユーザーに見せたい場合は "display": "summarized" を指定する必要がある。

# 思考内容をサマリとして表示する場合
thinking = {
    "type": "adaptive",
    "display": "summarized",
}

新設された xhigh 努力レベルは、high と max の間に位置するコーディングやエージェント向けの設定で、深い推論を維持しつつ max より短いレイテンシを得られる。high より低い設定（medium・low）では思考量が減るが、命令の汎化をしなくなる（一つの指示を別の対象に自動適用しない）ことに注意が必要だ。エージェントが指示の曖昧さを補完しすぎて困っていたケースには、むしろ好材料かもしれない。

高解像度ビジョン：スクリーンショット解析とUI操作の精度が変わる

ビジョン面では、最大解像度が 1568px/1.15MP から 2576px/3.75MP へと引き上げられた。数値以上に効いてくるのが座標系の変更だ。これまでモデルが返す座標は実際のピクセル値と一致しておらず、スケールファクターの変換をコード側で処理する必要があった。Opus 4.7 では座標が 1:1 でピクセルに対応するようになり、Computer Use での UI 操作や、スクリーンショットを解析してドキュメントのレイアウトを検証する処理がシンプルになる。

ただし高解像度画像はトークン消費も増える。解像度が必要でない場面では事前にダウンサンプリングするよう公式は推奨している。

その他の注意点：移行で踏みやすい落とし穴

Opus 4.6 からの移行で引っかかりやすい変更が2点ある。

temperature、top_p、top_k のデフォルト以外の値は 400 エラーになった。決定論的な出力を temperature=0 で担保していたコードはそのままでは動かない。これらのパラメータを取り除き、プロンプト側で制御する形に変更する必要がある。

トークナイザーが新しくなったことで、同じプロンプトで最大 35% 程度トークン数が増える可能性がある。コンテキスト圧縮のトリガーや max_tokens を余裕のある値に更新しておくことを勧める。

価格は Opus 4.6 と変わらず、入力トークン $5/百万・出力トークン $25/百万。Amazon Bedrock、Google Cloud Vertex AI、Microsoft Foundry でも 4 月 16 日から利用可能になっている。

意味づけ：「制御量の増大」という方向性

三つの機能を並べてみると、共通のテーマが浮かぶ。タスクバジェットはループ全体のコストをモデルに意識させ、Adaptive Thinking は推論の有無と表示方法を呼び出し元が選べる設計に変え、高解像度ビジョンは座標変換の手間を削って実装コストを下げた。いずれも「モデルが勝手にやりすぎる」問題への対策として読める。

エージェントの信頼性で一番やっかいなのは、モデルが想定以上のことをする予測不能な動作だ。今回の変更はそこに対するAnthropicなりの回答に見える。バジェットと努力レベルの組み合わせを試す余地が増えた分、チューニングの手間も増えるが、それは制御量が増えたということでもある。