Claude Opus 4.7 API の使い方

Lena です。4 月 16 日のリリース後、ほとんどが見慣れたものだと思って公式ドキュメントと移行資料に目を通しました。実際、大部分はそうです。でも、構造的な変化が十分多い——3 つの breaking な API 変更、新しい effort システム、token カウントをシフトさせる tokenizer——ので、今回のアップグレードを「model ID の入れ替え」程度に扱うと事故が起きます。

以下は、自分で一通り手を動かした後に見えてきたことです。

Claude Opus 4.7 API に含まれるもの

Model ID、コンテキストウィンドウ、output 上限、ツール

まず基本から。ここははっきり言っておく価値があります。

​**Model ID：​claude-opus-4-7**​。Anthropic の公式 models overview によれば、標準 API 価格で 1M token のコンテキストウィンドウ をサポートし、長コンテキストプレミアムはありません。同期版の Messages API では 最大 128k output token。Message Batches API では、output-300k-2026-03-24 beta header を使うことで Opus 4.7 は 300k output token まで出せます。

ツールセットは Opus 4.6 からそのまま引き継ぎ：bash、code execution、computer use、text editor、web search、web fetch、MCP connector、memory tools が初日から全部使えます。vision サポートも全面的に存在し、実質的にアップグレードされています——これは後でまた戻ってきます。

Claude API、Amazon Bedrock、Google Cloud Vertex AI、Microsoft Foundry で利用可能——そして GitHub Copilot 上で Copilot Pro+、Business、Enterprise ユーザーへ展開中。価格は 100 万 input token あたり $5、100 万 output token あたり $25——Opus 4.6 から変更なしです。

Opus 4.6 からの新しいもの

API 表面で本当に新しいのは 3 つです。

Adaptive thinking が唯一の thinking モードに。 古い {"type": "enabled", "budget_tokens": N} パターンはなくなりました。今これを送ると ​400 エラー​ が返ります。Opus 4.7 は {"type": "adaptive"} を使います——モデルがタスクの複雑度に応じて、どれだけ推論するかを動的に決めます。adaptive thinking はデフォルトでオフ。モデルに考えてほしいなら明示的に有効化する必要があります。

​xhigh​ effort level。 high と max の間に位置する新しいレベルで、コーディングと agentic ユースケースで推奨される新しい出発点です。API のデフォルトは high のまま。output_config を通じて明示的に xhigh に設定します。構造は下で示します。

Task budgets（beta）。 新しい仕組みで、agentic ループ全体に対する助言的な token 目標値をモデルに与えます——thinking、tool call、tool result、最終 output をすべて合算して計算します。モデルはカウントダウンを見ながら、予算が尽きるときに優先順位付けと優雅な着地をします。

削除されたもの：​非デフォルトの sampling パラメータ​。temperature、top_p、top_k をデフォルト以外の値に設定すると、今は 400 エラーが返ります。決定性のために temperature=0 を使っていたなら、それが同一出力を保証したことは元々なかった点に注意してください——移行ガイドはこれらのパラメータを丸ごと省略することを推奨しています。

最小限の Claude Opus 4.7 API セットアップ

最初のリクエストの構造

Opus 4.7 の最小動作リクエストはこうなります：

import anthropic

client = anthropic.Anthropic()

message = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=4096,
    messages=[
        {"role": "user", "content": "Explain the tradeoffs between BFS and DFS for a graph with cycles."}
    ]
)

print(message.content[0].text)

このリクエストは thinking を有効にしていません。モデルは直接応答します。ほとんどのタスクではこれが正しい出発点——理由があるときだけ複雑さを足していく方針です。

Adaptive Thinking と Effort Level を選ぶ

モデルに応答前の推論を求めるなら、thinking 設定を足して effort を明示的に設定します：

message = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=16384,
    thinking={"type": "adaptive"},
    output_config={"effort": "xhigh"},
    messages=[
        {"role": "user", "content": "Review this pull request for security vulnerabilities..."}
    ]
)

Anthropic の公式 effort ドキュメント に基づく、effort level について知っておく価値があるポイント：

• high は API のデフォルト。複雑な推論、ニュアンスのある分析、難しいコーディング問題で、品質を優先するときに使います。
• xhigh は新しいレベル——コーディングと agentic タスクに推奨。Claude Code は全プランでデフォルトを xhigh に上げました。
• max は token 制約なしの最も深い推論を提供します。現在のセッションにのみ適用（環境変数で設定しない限り）で、永続化しません。
• low​ と ​​**medium** は精度を速度とコストに交換します。限界的な品質差がコストを正当化しない、高ボリュームの分類やルーティングに有用です。

2 回読み返したディテール：​Opus 4.7 は Opus 4.6 よりも厳密に effort level を尊重します​、特に low と medium で。複雑なタスクで浅い推論を観察したら、正しい打ち手は effort を上げること——prompt の周りに足場を組むことではありません。ドキュメントはこの点を明確にしています。

xhigh または max で走らせるときは、max_tokens を少なくとも 64k に設定 して、モデルが subagent と tool call をまたいで考え動くための余地を与えます。64k から始めて調整するのが Anthropic 自身の推奨です。

長時間稼働 agent にとって重要な機能

高解像度 vision、xhigh effort、tool workflow

vision のアップグレードは、agent ビルダーにとって最も具体的な能力向上です。Vellum AI による Opus 4.7 の benchmark 分析 が記録しているように、OSWorld-Verified（computer use）は Opus 4.6 の 72.7% から 78.0% に上昇——5 ポイントの向上で、解像度アップと組み合わせると UI 自動化の経済学を実質的にシフトさせます。

Opus 4.7 は ​高解像度画像をサポートする最初の Claude モデル​：最大解像度は 1,568 ピクセル（約 1.15MP）から 2,576 ピクセル（約 3.75MP）長辺 に増えました。ピクセル予算で 3 倍以上です。密度の高い UI を読む computer-use agent、スクリーンショット基盤のワークフロー、ドキュメント理解パイプラインにとって、これは有意味な変化です。重要なのは、座標が実画像ピクセルと 1:1 対応 するようになったこと——座標抽出のためにかつて必要だったスケール係数計算は不要になりました。

リクエストでの vision：

message = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=4096,
    messages=[
        {
            "role": "user",
            "content": [
                {
                    "type": "image",
                    "source": {"type": "url", "url": "https://example.com/diagram.png"}
                },
                {"type": "text", "text": "List every service shown and the connections between them."}
            ]
        }
    ]
)

あるタスクにその追加解像度が不要なら、送信前にダウンサンプリングしてください——高解像度画像はより多くの token を生成し、コストに敏感なワークロードでは積み上がります。

ツール重視の agentic ループでは、effort を上げると tool call の頻度と深さが増えます。関係は直接的：effort が低い → tool call が少なく推論チェーンが浅い；effort が高い → tool 相互作用がより徹底的。これは prompt でもステアリングできますが、effort パラメータのほうがクリーンなレバーです。

本番利用のためのコストとレイテンシ制御

Task budgets は長い agentic ループの支出をコントロールする新しい仕組みです。beta header で有効化：

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"]
)

モデルはカウントダウンを見て、優先順位付けと優雅な着地に使います。task budget がない場合、デフォルト挙動は「必要なだけ使う」——xhigh 下での複雑な agentic タスクでは、単一ターンのリクエストから予想するよりも有意に多い output token になり得ます。

非同期ワークロード——評価 run、夜間サマリ、バッチ分析——には Batch API が 50% 割引 を提供し、リアルタイムトラフィックから rate-limit の圧力を取り除きます。prompt caching は引き続き利用可能で、安定した system prompt や大きな静的プレフィックスを持つワークロードでは、繰り返しの input コストを最大 90% 削減できます。

避けるべき移行ミス

4.6 の prompt がそのまま通用すると仮定すること

これは繰り返し出てくるミスです。

Opus 4.7 は Opus 4.6 よりも より文字通りに指示に従います。行間を読んだり、1 つのケースから静かに一般化することはもうしません。柔らかい言い回し——「try to」、「if possible」、「roughly」——は今、実際により重みを持っています。4.6 の解釈の柔軟性に依存していた prompt は、ときに違う挙動をします。しかも必ずしも期待する方向とは限りません。

3 つの breaking な API 変更はコード修正を要求し、prompt 編集だけでは済みません：

1. thinking: {type: "enabled", budget_tokens: N} を thinking: {type: "adaptive"} に置き換え
2. リクエストから temperature、top_p、top_k を完全に削除
3. max_tokens を監査する——新しい tokenizer は同じテキストを最大 ​1.35× 多い token​ にマッピングし得るため、以前は収まっていた応答が切られる可能性があります

トーンについて：Opus 4.7 は 4.6 より直接的で主張が強く——絵文字は少なめで、validation を前に置く言い回しは減っています。プロダクトが 4.6 の温かめのスタイルに合わせて調整された特定の声に依存しているなら、本番昇格前に style prompt を新しいベースラインに対して再評価してください。

Anthropic の Opus 4.7 ローンチアナウンス は完全な移行チェックリストに直接リンクしており、Claude Code ユーザーは /claude-api migrate を実行することで、コードベース全体の model ID 置換と breaking パラメータ変更を自動化できます。

長コンテキストを永続メモリのように扱うこと

ドキュメントでこの箇所を読んだとき、一度手を止めました。2 つは混同しやすいんです。

1M token のコンテキストウィンドウは永続メモリではありません。 これが意味するのは、1 つのリクエストに 100 万 token を詰め込めるということです。そのリクエストが終わると——セッションが閉じる、agent がクラッシュする、新しい会話が始まる——そのコンテキストは消えます。次のリクエストはゼロから始まります。

Opus 4.7 は改善されたファイルシステムベースのメモリを含みます：モデルは複数セッションの作業にまたがって notes ファイルを読み書きし、このパターンを使う agent で目に見えて信頼性の高い挙動を示します。でもそれはあなたが設定するツールです。長いコンテキストウィンドウから自動的に出てくるものではありません。

セッションをまたいで「何かを覚えている」ことになっている agent を作っている人には、この区別が重要です。1M ウィンドウはセッション内で助けになります。セッション横断のメモリは明示的なアーキテクチャを必要とします。

API が依然として解決していないこと

能力の再利用と検証済みの修復履歴

この部分は API ガイドにきれいに収めるのが難しいのですが、言う価値があると思います。

Opus 4.7 が planning フェーズで論理的誤りをつかまえるとき——リリース資料はこれを本物の能力として記述しています——その推論はセッション内で起きます。そのエラーを捕まえた事実、そしてどう修正したかという事実は、次回のために再利用可能なパターンとして自動的に永続化されません。同じクラスの問題が次に現れたとき、モデルはゼロから推論します。

2026 年初頭に発表された AI agent の信頼性に関する研究論文 によれば、ほとんどのモデルは run をまたいだ一貫性ではなく平均精度でベンチマークされる——これは、モデルがベンチマークで高いスコアを出しつつ、同じクラスのタスクで異なる時点に予測不可能に失敗することがあり得るということです。Opus 4.7 は Opus 4.6 のベースラインを改善しています。それは本物です。でもセッション内の修正とセッション横断の能力継承は別の問題で、API は前者を解きますが後者は解きません。

本番 agent を走らせるビルダーにとって、これが意味することは、信頼できるシステムを作るエンジニアリングワーク——評価 harness、repair ドキュメント、モニタリング——は依然としてモデルの外側にあるということです。API はより強力なモデルを提供します。その能力を時間をかけてどう活用するかは、依然としてあなたのアーキテクチャ次第です。

FAQ

Q：Opus 4.7 の正しい model ID は？

A：claude-opus-4-7。これは Claude API、Amazon Bedrock、Google Cloud Vertex AI、Microsoft Foundry をまたいだ API 呼び出しで安定した model 文字列です。

Q：adaptive thinking はデフォルトでオンですか？

A：いいえ。Opus 4.7 では adaptive thinking はデフォルトでオフです。有効化するには thinking: {"type": "adaptive"} を明示的に設定する必要があります。thinking フィールドなしのリクエストは thinking なしで走ります。

Q：temperature や budget_tokens を送ったらどうなりますか？

A：両方とも Opus 4.7 で 400 エラー を返します。すべてのリクエストから temperature、top_p、top_k を削除してください。budget_tokens を output_config: {"effort": "..."} と thinking: {"type": "adaptive"} に置き換えてください。

Q：xhigh と high はいつ使い分けますか？

A：コーディングと agentic タスクの出発点として xhigh を使ってください——これは全プランで Claude Code のデフォルトになりました。ほとんどの知性感度の高いタスクには high。レイテンシやコストが推論の深さより重要なら medium や low に下げます。複雑なタスクで低めのレベルで浅い出力を観察したら、prompt に足場を組むのではなく effort を上げてください。

Q：1M コンテキストウィンドウは、agent がセッションをまたいで物事を覚えているという意味ですか？

A：いいえ。コンテキストウィンドウは 1 つのリクエスト内で適用されます。セッションが終わると、そのコンテキストは消えます。マルチセッションのメモリは明示的なツーリング——ファイルベースメモリ、外部ストア、または類似のアーキテクチャ——を必要とします。

Previous Posts

• モデルのアップグレードがシステムコストを下げない理由を理解したいなら：Claude Opus 4.7 vs Reliability: Why Better Models Don't Fix Agent Systems
• 真のコストが token 価格の外側のどこに隠れているかを理解したいなら：Harness Engineering: The Hidden Layer Behind Agent Cost and Reliability
• Opus の Sonnet に対するプレミアムが実際に価値を持つのがいつかを評価中なら：Claude Managed Agents: When You Should Actually Use Opus vs Sonnet
• agent システムを構築していて、挙動と支出の両方をコントロールする必要があるなら：Agent Superpowers: Behavior Constraints as a Cost Control Layer
• agent の利用を単一のワークフローの外側にスケールさせることを考えているなら：Best MCP Servers for Claude Code: Real Production Use Cases