Claude 4.6 モデル選択 実践ガイド — Sonnet vs Opus、コスト・性能・Claude Codeでの使い分けを徹底解説
「Sonnet 4.6とOpus 4.6、結局どっちを使えばいいの?」——開発者なら一度は悩む問いだと思います。SWE-bench Verifiedのスコア差はわずか1.2ポイント(79.6% vs 80.8%)、一方で価格差は入出力ともに約1.7倍。この微妙な差をどう判断するかで、月々のAPI費用が大きく変わります。
本記事では、Claude Codeでの体感差、APIでの移行時の落とし穴(Prefill廃止・Adaptive Thinking移行)、ユースケース別の判断フローを実コード付きで解説します。
Claude 4.6ファミリーの現在地を整理する
Opus 4.6・Sonnet 4.6・Haiku 4.5 — スペック早見表
| モデル | モデルID | 入力 ($/MTok) | 出力 ($/MTok) | コンテキスト | 最大出力 | SWE-bench Verified |
|---|---|---|---|---|---|---|
| Opus 4.6 | claude-opus-4-6 | $5 | $25 | 1M | 128K | 80.8% |
| Sonnet 4.6 | claude-sonnet-4-6 | $3 | $15 | 1M | 64K | 79.6% |
| Haiku 4.5 | claude-haiku-4-5-20251001 | $1 | $5 | 200K | 64K | — |
APIでの基本呼び出しはシンプルです。
import Anthropic from "@anthropic-ai/sdk";
const client = new Anthropic();
// Sonnet 4.6(コスト重視の日常タスク)
const response = await client.messages.create({
model: "claude-sonnet-4-6",
max_tokens: 4096,
messages: [{ role: "user", content: "このコードをレビューしてください" }],
});
// Opus 4.6(複雑な推論が必要な場面)
const response = await client.messages.create({
model: "claude-opus-4-6",
max_tokens: 4096,
messages: [{ role: "user", content: "このアーキテクチャの改善案を提案してください" }],
});
SWE-bench 1.2%差の実態:ベンチマークと実務のギャップ
SWE-bench Verifiedでの差は79.6% vs 80.8%。統計的に有意ではありますが、実務タスクの大半——コード生成、レビュー、要約、データ変換——ではSonnet 4.6で十分です。Opusが真価を発揮するのは、超長文の複雑な推論チェーンや、大規模コードベース全体を俯瞰するような場面に限られます。
注意: ネット上で「Claude Sonnet 5(SWE-bench 92.4%)」という情報を見かけた方もいるかもしれません。実際のClaude Sonnet 5は2026年2月3日にリリースされた実在モデルで、SWE-bench Verifiedスコアは82.1%です。92.4%という数値は誤情報ですのでご注意ください。モデル選択は必ずAnthropic公式ドキュメントで確認してください。
4.6移行で壊れるコード — Breaking Changesと対処法
Prefill(アシスタントメッセージ先頭固定)の廃止
Claude 3.5世代まで広く使われていた「assistant messageの先頭を固定して出力形式を制御する」テクニックが、4.6で400エラーを返すようになりました。正直、最初にこれに遭遇したときは面食らいました。
Error: This model does not support assistant message prefill.
The conversation must end with a user message.
この変更はLiveKit、CrewAI、Agnoなど多くのフレームワークに影響を与えました。
Before(3.5時代のPrefillパターン):
// ❌ 4.6ではこれが400エラーになる
const response = await client.messages.create({
model: "claude-sonnet-4-6",
max_tokens: 4096,
messages: [
{ role: "user", content: "売上データを分析してください" },
{ role: "assistant", content: '{"analysis":' }, // Prefill
],
});
After(4.6対応パターン):
// ✅ system promptで出力形式を指示
const response = await client.messages.create({
model: "claude-sonnet-4-6",
max_tokens: 4096,
system: "必ずJSON形式で回答してください。キー: analysis, summary, recommendations",
messages: [
{ role: "user", content: "売上データを分析してください" },
],
});
より厳密に出力形式を制御したい場合は、tool_useを使ったStructured Outputパターンが確実です。
Extended Thinking → Adaptive Thinkingへの移行
budget_tokensを手動で指定するExtended Thinkingは、4.6で非推奨になりました。代わりに導入されたAdaptive Thinkingは、モデルが自律的に思考の深さを調整します。
// ❌ 非推奨(まだ動くが将来削除予定)
const response = await client.messages.create({
model: "claude-sonnet-4-6",
max_tokens: 16000,
thinking: { type: "enabled", budget_tokens: 10000 },
messages: [{ role: "user", content: "..." }],
});
// ✅ Adaptive Thinking(推奨)
const response = await client.messages.create({
model: "claude-sonnet-4-6",
max_tokens: 16000,
thinking: { type: "adaptive" },
// effort: "medium" | "high" | "max"(省略時はhigh)
messages: [{ role: "user", content: "..." }],
});
effortパラメータがポイントです。Sonnet 4.6では多くのユースケースでmediumが速度・コスト・品質のバランスが良く、Opus 4.6ではmaxを指定すると最高精度が出ます。Adaptive Thinkingではインターリーブ思考(ツールコール間の推論)も自動で有効になるため、エージェントワークフローとの相性が特に良くなっています。
プロダクション障害の実例
chanl.aiのブログ記事では、本番エージェントが4.6移行後2時間で停止した事例が報告されています。主な原因はPrefillへの依存でした。
移行前チェックリスト:
- コードベース内の
role: "assistant"で終わるmessages配列を検索 - Prefill箇所をsystem prompt指示またはStructured Outputに書き換え
budget_tokensの使用箇所をthinking: { type: "adaptive" }に置換- ステージング環境で全エンドポイントをテスト
ユースケース別 判断フロー
Claude Codeでのモデル切り替え実践
Claude Codeでは/modelコマンドでOpusとSonnetを即座に切り替えられます。実用的な使い分けとしては:
- 日常のコーディング・バグ修正・リファクタリング → Sonnet 4.6(十分な精度で高速)
- 複雑なアーキテクチャ設計・大規模リファクタ → Opus 4.6(推論の深さが活きる)
- 簡単な質問・コード補完 → Haiku 4.5(最速・最安)
APIルーティング: コスト最適化のRouterパターン
タスクの複雑度に応じてモデルを自動選択するRouterを実装すると、コストを大幅に削減できます。
import Anthropic from "@anthropic-ai/sdk";
type ModelTier = "haiku" | "sonnet" | "opus";
interface RouterConfig {
tokenThreshold: { sonnet: number; opus: number };
complexityKeywords: string[];
}
const DEFAULT_CONFIG: RouterConfig = {
tokenThreshold: { sonnet: 500, opus: 5000 },
complexityKeywords: [
"アーキテクチャ", "設計", "リファクタ", "セキュリティ監査",
"パフォーマンス最適化", "architecture", "refactor", "security audit",
],
};
const MODEL_MAP: Record<ModelTier, { id: string; inputCost: number; outputCost: number }> = {
haiku: { id: "claude-haiku-4-5-20251001", inputCost: 1, outputCost: 5 },
sonnet: { id: "claude-sonnet-4-6", inputCost: 3, outputCost: 15 },
opus: { id: "claude-opus-4-6", inputCost: 5, outputCost: 25 },
};
function selectModel(prompt: string, config = DEFAULT_CONFIG): ModelTier {
const estimatedTokens = Math.ceil(prompt.length / 3); // 粗い推定
const hasComplexity = config.complexityKeywords.some((kw) =>
prompt.toLowerCase().includes(kw.toLowerCase())
);
if (hasComplexity || estimatedTokens > config.tokenThreshold.opus) return "opus";
if (estimatedTokens > config.tokenThreshold.sonnet) return "sonnet";
return "haiku";
}
// 使用例
async function routedRequest(prompt: string) {
const client = new Anthropic();
const tier = selectModel(prompt);
const model = MODEL_MAP[tier];
console.log(`[Router] Selected: ${tier} (${model.id})`);
const response = await client.messages.create({
model: model.id,
max_tokens: 4096,
messages: [{ role: "user", content: prompt }],
});
const inputTokens = response.usage.input_tokens;
const outputTokens = response.usage.output_tokens;
const cost = (inputTokens * model.inputCost + outputTokens * model.outputCost) / 1_000_000;
console.log(`[Router] Cost: $${cost.toFixed(6)} (${inputTokens} in / ${outputTokens} out)`);
return response;
}
Opusを選ぶべき残りのケース
個人的な体感ですが、以下のタスクではOpusの差が明確に出ます:
- 1Mコンテキストをフルに使う大規模コード解析
- 微妙なニュアンスが求められる文章生成(法務文書、技術仕様書)
- 複数ステップにまたがる複雑な推論チェーン
effort: "max"での最高精度が必要な場面
逆に言えば、これら以外の実務タスク——体感で8割以上——はSonnet 4.6で十分カバーできます。
コスト試算 Before/After
全リクエストOpus vs Sonnet主体+Opus併用の比較
月間10万リクエスト、平均入力2,000トークン・出力1,000トークンの想定で試算します。
| パターン | 入力コスト | 出力コスト | 月額合計 | 削減率 |
|---|---|---|---|---|
| 全てOpus | $1,000 | $2,500 | $3,500 | — |
| 全てSonnet | $600 | $1,500 | $2,100 | 40% |
| Router導入(80% Sonnet / 20% Opus) | $680 | $1,700 | $2,380 | 32% |
| Router + Prompt Caching | ~$340 | $1,700 | ~$2,040 | 42% |
Prompt Cachingの活用
Prompt Cachingを併用すると、キャッシュヒット時の入力コストが基本価格の10%まで下がります。system promptや共通のコンテキストをキャッシュに載せることで、入力コストを大幅に圧縮できます。
// Prompt Cachingの基本パターン
const response = await client.messages.create({
model: "claude-sonnet-4-6",
max_tokens: 4096,
system: [
{
type: "text",
text: "あなたはコードレビューの専門家です。以下のコーディング規約に従ってレビューしてください...(長い規約テキスト)",
cache_control: { type: "ephemeral" }, // 5分間キャッシュ
},
],
messages: [{ role: "user", content: "このPRをレビューしてください: ..." }],
});
キャッシュ書き込みは基本価格の1.25倍(5分間)ですが、2回目以降の読み取りが10%になるため、同じsystem promptで複数リクエストを送るパターンでは確実に元が取れます。
まとめ: 4.6時代のモデル選択チートシート
タスクの判断フロー:
入力が短い&単純な質問/補完?
→ Yes: Haiku 4.5(最安・最速)
→ No: ↓
複雑な推論・大規模コード解析・高精度が必須?
→ Yes: Opus 4.6(effort: "max")
→ No: ↓
それ以外の開発タスク全般
→ Sonnet 4.6(effort: "medium" or "high")
迷ったらSonnet 4.6から始めて、品質に不足を感じたらOpusに上げる。 これが現時点での最適戦略です。
SWE-benchの差はわずか1.2ポイント、コストは約1.7倍違います。日常の開発タスクの大半はSonnetで十分に対応でき、Opusは複雑な推論が必要な場面に限定して使うのが合理的です。
移行時はPrefill廃止とAdaptive Thinkingへの切り替えを忘れずに対処してください。この2つのBreaking Changesさえクリアすれば、4.6移行でコスト削減と性能向上を同時に実現できます。
最後に、モデルIDはハードコードせず環境変数や設定ファイルで外部化しておくことを強く推奨します。次のモデルリリースが来たときに、コード変更なしで切り替えられる柔軟性は、地味ですが確実に効いてきます。
参考リンク:
