先に結論を書きます。

私はClaude CodeでSonnet 4.6とOpus 4.7を60日間同じタスクで並走させ、7カテゴリ・全14セル・3指標(成功率・トークン数・完了時間)を実測したところ、タスクの4割でSonnet 4.6の方が結果が良かった。残り約5割はOpus 4.7が優位、残り1割は「どちらでも同じ」でした。「Opusが万能に上位」は、少なくとも私の60日運用データでは嘘です。むしろタスクの種類を分けずに常時Opusで走らせるのは、Max契約者の中で最ももったいない使い方でした。

この記事では、7カテゴリの勝敗を数字で分解します。

この記事のスコープと、既存記事との差分

同ジャンルで書き分けが必要なので、位置づけを最初に置きます。

「Claude Code Max $200/月×8ヶ月を私のタスク別に分解」: Max全体コスト vs ローカルLLM代替可否
「Claude Code・Cursor・Codex、結局どう使い分けるのが正解か」: 3ツール横断比較
「Claude Codeに長期記憶を持たせるMemory設計3つの方法」: Memory機能設計
本記事: Claude Code内部でのSonnet 4.6 vs Opus 4.7 2モデル並走の勝敗表

要するに、Max契約者が同じ$200/月の枠内で「今日はどっちを呼ぶか」を決めるための実測データです。

非Max契約者にも通じる読み方

Max/Pro契約者以外の方は、Anthropic APIで両モデルを直接叩いた場合の相対比較として読んでください。Sonnet 4.6は1MTok入力$3・出力$15、Opus 4.7は入力$5・出力$25で約1.7倍の価格差があり、今回の実測から出てくる「4割でSonnetの方が結果が良い」という結論は、そのままAPI利用の意思決定に転用可能です。

ペインの構造(常時Opusは過剰課金)は同じだからです。

検証条件

条件を先に開示します。読者側で再現可能な粒度まで書きます。

項目	値
期間	2026-06-11 〜 2026-08-10 (60日)
対象モデル	claude-sonnet-4-6 / claude-opus-4-7
Claude Code バージョン	Claude Code CLI (2026-08時点最新)
プラン	Claude Code Max Plan ($200/月)
計測対象	私が実務で発生させた作業 (harness-ops / sns-operations / zenn-content)
並走方法	同一プロンプトを両モデルに投げ、Diffで結果を照合
記録	ANTHROPIC_LOG=debug + セッショントランスクリプト + token使用量
判定基準	「そのままコミットできる品質か」を私が二段階(◎/○/△/×)で採点

判定は最終的に私の主観採点です。「LLM-as-a-Judgeで自動化しろ」というツッコミは正当なので先に受けておきますが、60日で200件を超える作業を1件ずつAIジャッジ用のrubricに乗せると評価コストが本編を超えるため、今回は主観採点でまとめました。

7カテゴリ × 2モデル = 14セルの実測マトリクス

主指標を1枚の表にまとめます。数字は60日累計です。

カテゴリ	Sonnet 4.6 成功率	Opus 4.7 成功率	Sonnet 平均Tok/件	Opus 平均Tok/件	Sonnet 平均秒/件	Opus 平均秒/件
コード生成 (新規関数/小機能)	82%	84%	4,100	6,800	22s	41s
リファクタ (既存200行→整理)	71%	89%	12,400	21,200	68s	128s
コードレビュー (差分50-300行)	75%	88%	8,900	15,300	44s	96s
ドキュメント (READMEやAPI)	88%	86%	5,200	9,700	29s	61s
計画・設計 (章立てや設計書)	68%	92%	7,800	14,900	38s	89s
デバッグ (バグ再現→修正)	64%	83%	11,600	22,500	71s	148s
スクリプト作成 (シェル/一発物)	87%	82%	3,700	6,100	19s	34s

「成功率」は◎+○を分子、全試行を分母にした値です。以下、カテゴリ別に勝敗の内訳を書きます。

カテゴリ別の勝敗確定表

上の数字から「タスクが来たとき、どちらを呼ぶべきか」を決めた表がこちらです。

カテゴリ	推奨モデル	判定理由
コード生成	Sonnet 4.6	成功率差2ptに対しTok1.7倍・時間1.9倍。差が小さいのでコスト側で勝つ
リファクタ	Opus 4.7	成功率18pt差。Opusでないと既存の設計意図を壊す事故が起きる
コードレビュー	Opus 4.7	成功率13pt差。Sonnetは論点の優先度付けが浅い
ドキュメント	Sonnet 4.6	成功率で逆転(88 vs 86)。Opusは丁寧すぎて冗長になる
計画・設計	Opus 4.7	成功率24pt差。ここは無条件でOpus。Sonnetでの節約は失敗コストで相殺
デバッグ	Opus 4.7	成功率19pt差。仮説の質そのものが違う
スクリプト作成	Sonnet 4.6	成功率でSonnet優位(87 vs 82)。一発物にOpusは過剰

7カテゴリのうち 3カテゴリでSonnet推奨 、 4カテゴリでOpus推奨 という結果です。件数ベースで再集計すると、私の60日の総作業件数(213件)のうち Sonnetの方が結果が良かった件数は88件で41% でした。

冒頭の「4割」の内訳はこれです。

なお「引き分け」も別途23件ありました。これは両モデルとも◎判定・両者Diffなしのケースで、迷ったらSonnetでよい層です。

意外だったカテゴリ ① ドキュメント (Opusが負ける)

事前予想では「文章生成はOpusが強い」で、Sonnetに勝ち目はないと踏んでいました。

実測は逆でした。

Opus 4.7のドキュメント生成は、内容が正確なぶん 「一度で言い切ればいい情報を、丁寧に段落分けする」傾向 が強く、Diffで見るとreadme本体が20%ほど膨らんでしまう。校正で削る手間が発生し、実質「Sonnetで書いて手を入れる方が早い」という結論に落ちました。

具体例で言うと、あるnpmパッケージのREADME改訂をSonnetとOpusに同じプロンプトで投げたところ、Sonnetは142行、Opusは178行の出力を返してきました。差分の36行を精査すると、Opusは「補足の段落」「注意点の別項化」「使用例の追加」を独自判断で入れる傾向があります。技術リファレンスならありがたい親切ですが、READMEの初見体験としては情報密度が薄まってしまう副作用が出ます。

もちろん技術リファレンスのような正確性優先の長文ならOpusです。

ここでの「ドキュメント」はREADME/CHANGELOG/CLIヘルプ/PR説明といった中距離文書のことで、その帯ではSonnetの簡潔さが勝つ、という切り分けが必要でした。

意外だったカテゴリ ② 計画・設計 (Opus圧勝)

一方で計画・設計は事前予想を上回るOpus優位でした。私は元々「箇条書きの章立てくらいならSonnetで足りる」と考えていましたが、Opusは章の重み配分と依存関係の順序が明らかに違い、Sonnetは「網羅はしているが並び順が浅い」プランを出す頻度が3倍以上高い。

計画フェーズで並び順を間違えると、下流の実装フェーズ全体が失敗コストを吸います。ここは成功率差24ptという数字以上に、失敗コストの重みでOpus固定です。

実例を出しておくと、あるWebアプリの認証基盤刷新をSonnetに設計させたときは「セッションストア刷新→ミドルウェア差し替え→クライアント側改修」の順を返してきました。Opusに同じプロンプトを投げると「先にクライアント側で並列運用フラグを立てる→サーバ側刷新→フラグ切替」というダウンタイム最小の順序を提示してきます。この差が下流の実装で数日単位の工数差になり、Sonnetで浮かせたトークン代など一瞬で吹き飛びます。

4割Sonnet推奨から出てくる、Max契約者の実務ルール

上記14セルの実測から、私は次の運用ルールに落ち着きました。

デフォルトモデルはSonnet 4.6にする (/model で常時)
Opusを呼ぶのは4カテゴリ限定: リファクタ・レビュー・計画・デバッグ
カテゴリの見極めが曖昧な作業は、まずSonnetで出させて不足があればOpusで再依頼する二段構え

このルールに切り替えてから、私のMaxプラン内のOpusクレジット消費は約38%減、体感の作業速度は約1.6倍になりました。Opusを常時使う方がむしろ遅いという反直感的な結論の背景は、上のトークン数・秒数の列に全部出ています。

Opusはリクエストあたり約1.8-2.3倍時間がかかるので、それだけ手待ちが増えるのです。

2026-08時点でAnthropicはMaxプランの従量制化を予告しています。従量課金移行後は「Opus常用は過剰課金」の構造がさらに強調され、本記事のルール(タスク別使い分け)の重要度がもう一段上がる想定です。

実務での切り替え手順

Claude Code CLIでは /model で対話中にモデルを切り替えられます。私が60日運用で固まった手順はこうです。セッション開始時に必ず /model sonnet を実行してデフォルトをSonnet固定にする。作業内容が「リファクタ」「レビュー」「計画」「デバッグ」の4カテゴリに落ちた時点で /model opus に切り替え、その作業が終わったら 即Sonnetへ戻す。ここで戻し忘れると、次のスクリプト作業などが自動的にOpus消費になり、月末にクレジット残高が想定より30%目減りします。

私は最初の2週間でこれを2度やらかしました。

もう一つ、複数のClaude Codeセッションを並走させる運用では、リポジトリごとにデフォルトモデルを分ける方針にしました。設計/DB周りのリポは .claude/settings.json のmodelをopus固定、シェル/Markdownメインのリポはsonnet固定です。切り替え忘れを人力で管理するのは60日で確実に破綻するので、環境側で寄せる方が安全です。

副次的な発見として、コンテキストが長引いたセッションで /model を切り替えると、前のモデルの応答スタイルが会話履歴に残ったまま新モデルが引き継ぐため、切り替え直後の1〜2ターンは「Sonnetの簡潔さ+Opusのくどさ」というハイブリッド出力になる現象を何度か観測しました。私はこれを「モデル残り香」と勝手に呼んで、切り替え直後のプロンプトに「これまでの応答スタイルはリセットして、簡潔に返してください」と明示するようにしています。

再現性のために公開する条件のバラツキ

数字を信じてもらうために、実測条件の弱点も先に書いておきます。

213件のタスクは私(個人開発+受託ミックス)由来のため、業界寄り(TypeScript/Python/シェル/Markdown中心)
Rust/Kotlin/Swift実務が薄い環境なので、ネイティブ寄りの読者はSonnet推奨率がここまで出ない可能性
「成功率」は◎+○の合算。◎だけで見るとOpusの優位はもう少し広がる(それでもSonnet推奨カテゴリは変わらず)
Claude Code CLIの機能(Skills/Memory/Sub-agents)は本記事の対象外。プレーンな2モデル並走のみ

以上を踏まえた上で、少なくとも「7カテゴリ全部Opusで走らせる」という運用は、私の実測範囲では明確に非効率です。

まとめ

Sonnet 4.6 vs Opus 4.7を60日並走した結果、タスクの4割でSonnetの方が結果が良かった
常時Opusは、Max内で最も高コスト・最も低速な運用パターンだった
カテゴリ別に見ると、リファクタ/レビュー/計画/デバッグはOpus固定、コード生成/ドキュメント/スクリプトはSonnet固定が実務ルール
このルールに切り替えるだけで、Opusクレジット消費が約38%減、体感速度が約1.6倍になった

Sonnet 4.6とOpus 4.7の切り替え運用や、Claude Codeを個人事業主レベルで使い倒すための実務ノウハウは、下記の書籍にまとめてあります。

Claude Code Mastery — AIコーディングエージェント実務ガイド