Claude Opus 4.7・Opus 4.6・Sonnet 4.6はどう使い分けるべきか

まず見るべき比較表

迷ったときの短い答え

• 通常のproduction defaultはSonnet 4.6。 速度、費用、品質のバランスを取りやすく、Anthropicのdocsでもlatencyはfast、価格はOpus 4.7より低く設定されています。
• 難しいrequestはOpus 4.7へescalation。 多段のcoding agent、複雑なrefactor、長い技術文書、visionを含む分析など、失敗コストがtokenコストを上回る場面に向いています。AnthropicはOpus 4.7をcoding、agents、vision、multi-step tasksで強調しており、max outputも128K tokensです。
• Opus 4.6はbaselineとして残す。 既存systemがOpus 4.6で安定しているなら、Opus 4.7へ一気に置き換えるより、同じeval setで回帰を確認するほうが堅実です。

Opus 4.7はOpus 4.6と何が違うのか

大きな違いは、Opus 4.7がより新しいOpusとして、難しい作業の品質を押し上げる方向で紹介されている点です。AnthropicはOpus 4.7について、coding、agents、vision、multi-step tasksでの性能向上と、重要な作業における丁寧さ・一貫性の改善を説明しています。

これはOpus 4.6の流れを引き継ぐものです。Opus 4.6の発表時点でも、Anthropicはcoding、慎重なplanning、long-running agents、大規模codebase、code review、debuggingの改善を打ち出していました。 そのため、Opus 4.6ですでに短いpromptや安定した処理がうまく回っている場合、Opus 4.7を試す価値が高いのは、むしろ失敗しやすい領域です。たとえば長いtool call chain、何度も修正が入るagent workflow、大規模codebase、細かい制約が多いinstruction、reasoningとvisionが混ざるtaskです。

ただし、ここで避けたいのは一括移行です。公式資料はOpus 4.7の改善領域を示していますが、自社のprompt、JSON schema、tool calling、style guide、latency要件のすべてで必ず改善するとは限りません。移行前に、Opus 4.6とOpus 4.7を同じevalで比較し、正答率、完了率、修正回数、tool call error、token cost、latencyを見てから判断するべきです。

Opus 4.7とSonnet 4.6の差は、品質だけでなく運用設計の差

1. 高難度品質を取るか、速度と費用を取るか

Anthropicのモデル概要では、Opus 4.7はcomplex reasoningとagentic codingに強いmodelとして、Sonnet 4.6は速度と知能の組み合わせに優れるmodelとして説明されています。 実務上は、この違いがもっとも重要です。

同時requestが多い、応答を速く返したい、token予算を厳しく管理したい。そうした本番運用では、Sonnet 4.6をdefaultにする判断が自然です。Docs上のlatencyはfastで、価格は100万input tokensあたり$3、100万output tokensあたり$15です。 またAnthropicは、FreeおよびProユーザー向けのclaude.aiとClaude CoworkでSonnet 4.6をdefault modelにしていると説明しています。

一方、Opus 4.7はrequest数は少なくても価値が高い処理に回すのが向いています。難しいcoding agent、長いreasoning、多段のsoftware workflow、一貫性が重要な出力などです。DocsではOpus 4.7のlatencyはmoderate、価格は100万input tokensあたり$5、100万output tokensあたり$25です。

2. Contextは同じ1M、差が出るのはmax output

Opus 4.7とSonnet 4.6はいずれも、model overviewでcontext windowが1M tokensとされています。 つまり、この2つの比較では、どちらが長い入力を読めるかが主戦場ではありません。

より明確な違いはmax outputです。Opus 4.7は128K tokens、Sonnet 4.6は64K tokensです。 長い設計書、分割された実装計画、大規模refactorの提案、構造化された技術報告書など、出力そのものが長くなるworkflowではOpus 4.7の余裕が効く可能性があります。逆に、短〜中程度のrequestでは、最大出力長よりもlatency、cost、format安定性のほうが重要になりがちです。

3. Thinking modeはAPI pipelineに影響しうる

見落としやすいのがthinking modeです。Model overviewでは、Opus 4.7はadaptive thinking、Sonnet 4.6はadaptive thinkingとextended thinkingに対応するとされています。 Opus 4.6のsystem cardにも、extended thinkingとadaptive thinking modesの項目があります。

すでにextended thinkingを前提にprompt、token上限、logging、監査設計を組んでいる場合、Opus 4.7へ全面切り替えする前に互換性を確認してください。これはOpus 4.7を使わない理由ではありませんが、rollout前に必ず検証すべき運用上の論点です。

本番では3段階routingが扱いやすい

一つのmodelを全trafficに固定するより、routingを分けるほうが現実的です。

1. Default route: Sonnet 4.6。 一般的なend-user request、通常のcoding補助、要約、文書分析、knowledge work、リスクの低いagent planningに使います。主な理由は、docs上のfast latencyと低いAPI価格です。
2. Escalation route: Opus 4.7。 Sonnet 4.6で失敗したtask、難度が高いtask、長い出力が必要なtask、多段tool use、大規模codebase、visionを含むworkflowに使います。AnthropicはOpus 4.7をcoding、agents、vision、multi-step workで強調しています。
3. Control route: Opus 4.6。 既存systemがOpus 4.6で安定している場合、移行期間中のcontrolとして残します。format、instruction following、cost、latency、tool callingの回帰を見つけるための基準になります。

この設計なら、trafficの大半はSonnet 4.6で効率よく処理し、品質の経済価値が高い場所だけOpus 4.7に予算を使えます。

model変更前のeval checklist

切り替え前に、少なくとも次の観点を同じtest setで比較してください。

• 本番に近いcase: 成功prompt、失敗prompt、長いrequest、tool useを含むtask、大規模codebase、visionが必要なworkflowなら画像やscreenshotも入れます。
• 品質指標: 正しさ、instruction adherence、多段taskの完了率、修正回数、tool call error、最終出力の実用性を見ます。
• 運用指標: input/output token、cost、p50/p95 latency、timeout、escalation率を測ります。価格とlatencyは、最新のmodel overviewと照らし合わせて確認します。
• Regression test: JSON format、schema、style guide、guardrail、tool callingの挙動が壊れないかを見ます。
• Canary rollout: いきなり全面移行せず、小さなtrafficまたはshadow trafficで先に流します。

結論

短くまとめるなら、Sonnet 4.6をproduction default、Opus 4.7を難しいtaskのescalation model、Opus 4.6を安定運用中systemのbaselineとして扱うのが無難です。Sonnet 4.6は公式docs上で価格が低くlatencyもfastです。一方、Opus 4.7はcoding、agents、vision、multi-step tasksで強調され、Sonnet 4.6より大きい128K tokensのmax outputを持ちます。

最重要なのは、modelを一つに決め打ちすることではありません。実際のworkloadに合わせてroutingを設計し、evalで確認することです。Anthropicの資料は期待値を示してくれますが、あなたの製品でどれが最適かを決めるのは、自社のprompt、tool、latency要件、cost上限を反映した検証です。