Opus 4.7 と Sonnet 4.6 の位置づけ
- 年3月末に公開された Claude Opus 4.7 と、2026年2月に更新された Sonnet 4.6 は、Anthropic のフラッグシップ世代として明確な役割分担を持つ。Opus 4.7 は「深い推論と長期計画」に最適化され、Sonnet 4.6 は「高速・低コスト・高スループット」の実運用ワークホースとして設計されている。
両モデルはトレーニング基盤を共有しているが、Opus 4.7 は追加で extended thinking 専用のポストトレーニングが施されており、長期的な問題分解とツール連鎖の安定性が顕著に向上している。Sonnet 4.6 は推論速度を優先しつつ、基礎的なコード生成と対話タスクで Opus 4.6 に匹敵する品質を保つチューニングがされた。
ベンチマーク結果の読み解き方
SWE-bench Verified での合格率は Opus 4.7 が81.2%、Sonnet 4.6 が74.5%（両者とも agentic scaffolding 使用）。Opus のリードは約7ポイントだが、これは複雑な複数ファイル横断修正での差が大きい。単一ファイル完結のバグフィックスでは差は2ポイント以内に縮まる。
Terminal-bench（シェル環境での実務タスク）では Opus 4.7 が68%、Sonnet 4.6 が61%。MMLU-Pro の学術タスクでは Opus 4.7 が85.1%、Sonnet 4.6 が80.4%。HumanEval Plus では両者の差が縮まり Opus 4.7 が95.2%、Sonnet 4.6 が93.8% と、コード単体タスクでは Sonnet でも十分な品質が出ている。
KGA が内部で実施した100タスクのエージェント検証では、タスク種別で差が二分した。リファクタリング・設計レビュー・長期計画では Opus 4.7 の優位が明確（成功率差15ポイント）だが、定型 CRUD 実装・テスト生成・ドキュメント化では Sonnet 4.6 と有意差がなかった。
コスト構造の比較
Opus 4.7 の価格は入力 $15/MTok、出力 $75/MTok、Sonnet 4.6 は入力 $3/MTok、出力 $15/MTok。Opus は Sonnet の5倍のコストだ。平均的なエージェントタスク（入力15K、出力3K）では Opus 1回あたり $0.45、Sonnet 1回あたり $0.09、約5倍の開き。
ただし extended thinking を有効にすると Opus の出力トークン消費が2〜4倍に膨れ上がる。実運用の課金実績を見ると、extended thinking 付き Opus タスクの平均コストは $1.2〜$2.8 程度まで跳ね上がるケースが多い。タスクの重要度で使い分けない限り、運用コストが急速に膨張する。
Prompt Caching の最適化
両モデルは prompt caching（5分 TTL、または1時間 TTL の拡張モード）に対応しているが、キャッシュヒット率が TCO を大きく左右する。Opus 4.7 のキャッシュ読み取りは入力定価の10%、キャッシュ書き込みは125%。Sonnet 4.6 も同比率だ。
長大なシステムプロンプト（10K トークン超）を複数セッションで再利用するエージェントでは、キャッシュヒット率90%超が容易に達成できる。この場合の実効単価は定価の約20%まで下がり、Opus 4.7 の運用が初見より遥かに現実的になる。KGA では「コード検索 RAG の静的コーパス部分」をキャッシュ対象に固定し、対話ごとに変動するクエリだけを追加投入する設計を標準化した。
使い分けの判断フレームワーク
- 軸の判断基準を提案する。1つ目は「推論の深さ」。複数ステップの仮説検証や長期計画が必要なら Opus 4.7、単発の生成・変換が中心なら Sonnet 4.6。2つ目は「コスト制約」。1タスクあたり $0.1 未満を目指すなら Sonnet 一択。3つ目は「レイテンシ要求」。リアルタイムチャットや IDE 統合では Sonnet 4.6 の高スループットが実用上必須。
エージェントパイプラインでは両者を組み合わせる設計が最適解になりつつある。Planner（計画）を Opus 4.7、Executor（実装）を Sonnet 4.6、Reviewer（検証）を再び Opus 4.7 に戻すという3段構成だ。KGA の社内エージェントではこの構成でタスク成功率を92%まで押し上げ、同時にトータルコストを全 Opus 構成比で58%削減した。
注意点とリスク
Opus 4.7 は強力だが、単純タスクでは「考えすぎ」が発生する。シンプルな質問に対しても extended thinking を走らせてしまい、無駄にトークンを消費する。tool_choice と max_thinking_tokens を適切に設定しないと、運用コストが予算を容易に突破する。
Sonnet 4.6 は逆に「自信過剰」傾向があり、エッジケースでハルシネーションを起こしやすい。特に長いコードベースに対する修正タスクでは、影響範囲の見積もりが甘くなる傾向があるため、必ずテスト自動実行やレビューゲートを挟むべきだ。モデル特性に合わせた scaffolding を用意できるかが、実運用の品質を決める。