なぜこの実験を行ったのか
誰もが Claude Sonnet 4.6 と Opus 4.6 を比較するベンチマーク表を公開しています。検索すれば、そのような表はいくらでも見つかるでしょう。しかし、ベンチマークは標準化されたタスクにおけるモデルのパフォーマンスを測定するものであり、深夜 2 AM に複雑なコードベースにどっぷり浸かりながら、機能をリリースしようと奮闘しているときに何が起こるかを教えてくれるものではありません。
私はもっと単純な問いに答えを出したいと考えました。開発者として毎日行っている実際のタスクにおいて、Opus 4.6 はいつその 5倍の価格プレミアムに見合う価値を発揮するのか？
そこで、コントロールされた実験を行いました。3週間かけて、すべてのコーディングタスクを両方のモデルで実行しました。同じプロンプト、同じコードベース、同じ評価基準を使用しました。コスト、出力の質、完了までの時間、そして必要な修正のやり取りの回数を追跡しました。
請求額はおよそ $500 に達しました。ここで学んだすべてのことを共有します。
セットアップ：テストの構成方法
両方のモデルに同一のシステムプロンプトを使用し、Claude API を直接利用しました。ラッパー、アシスタント、特別な設定は一切使用せず、純粋な API コールのみで比較をクリーンに保ちました。
テストしたモデル：
- Claude Sonnet 4.6 (claude-sonnet-4-6) — 100万 tokens あたり $3 input / $15 output
- Claude Opus 4.6 (claude-opus-4-6) — 100万 tokens あたり $15 input / $75 output
方法論：
- 各タスクに対して同じプロンプトを使用し、同じ時間内に両方のモデルに送信
- 各タスクを「正確性」「コードの質」「網羅性」「必要な追加プロンプトの数」で評価
- すべてのタスクは実際のプロジェクトから抽出（合成ベンチマークはなし）
- 各次元において 1-10 のスケールで各モデルをスコアリング
価格データは Anthropic's official pricing page から直接引用しています。速度の測定値は Artificial Analysis benchmarks に基づいています。
シナリオ 1：非同期コードにおけるレースコンディションのデバッグ
タスク： Node.js アプリケーションで、データベースの書き込みが順序通りに完了しないという断続的な不具合が発生していました。このバグは負荷がかかっている時のみ現れます。関連するソースファイル（約 8K tokens のコンテキスト）とエラーログを両方のモデルに提供しました。
Sonnet 4.6 の結果： 2回のやり取りの中で、Promise チェーンにおける await の欠落を特定しました。書き込みをトランザクションでラップすることを提案しました。クリーンで正確な修正でした。
Opus 4.6 の結果： 最初のやり取りで同じ根本原因を特定しましたが、さらに踏み込みました。隣接するモジュールで私が気づいていなかった 2つ目の潜在的なレースコンディションを指摘したのです。また、なぜバグが断続的だったのか（並行接続下でのイベントループのタイミング）を説明し、書き込みキューを使用した構造的な修正を提案しました。
勝者：Opus 4.6
違いはバグを見つけることではありませんでした。両方とも見つけました。Opus は 2つ目 のバグを発見し、将来の問題を防ぐためのアーキテクチャ上のコンテキストを提供しました。これは、Anthropic reports about Opus 4.6 having better debugging skills と、自身のミスをキャッチする能力に関する報告と一致しています。
コスト： Sonnet $0.12 | Opus $0.58
シナリオ 2：REST API の CRUD エンドポイントの構築
タスク： Express.js アプリケーションにおいて、TypeScript、Prisma ORM、Zod による入力バリデーション、適切なエラーハンドリングを備えた "projects" リソース用の完全な CRUD エンドポイントのセットを生成する。
Sonnet 4.6 の結果： 5つのエンドポイント（作成、1件取得、ページネーション付き全件取得、更新、削除）すべてを 1つのレスポンスで生成しました。入力バリデーションは正確で、エラーハンドリングは堅牢、TypeScript の型も正確でした。そのままコピーしてテストできる状態でした。
Opus 4.6 の結果： ほぼ同一の構造で同じ 5つのエンドポイントを生成しました。わずかに詳細なコメントが追加されていました。また、頼んでいなかった認証用のミドルウェアの提案も含まれていました。
勝者：Sonnet 4.6
出力は機能的に同一でした。Sonnet の方が速く、安価で、求められていないアーキテクチャの提案でレスポンスを水増しすることもありませんでした。CRUD 生成のような明確に定義され、範囲の絞られたタスクでは、Opus の深い推論能力はコストを増やす以外のメリットがありません。
コスト： Sonnet $0.08 | Opus $0.41
シナリオ 3：モノリシックなコンポーネントを小さなパーツにリファクタリングする
タスク： ユーザープロフィールを処理する 600行の React コンポーネント（フォームの状態、API コール、権限チェック、レンダリングロジックを含む）を、より小さくテスト可能なパーツに分割する必要がありました。フルコンポーネントとそのテストファイルを提供しました。
Sonnet 4.6 の結果： コンポーネントを 4つのパーツ（コンテナコンポーネント、フォームコンポーネント、権限用フック、API 用フック）に分割しました。妥当な分解でした。しかし、テストファイル内の 2つのインポートパスの更新漏れがあり、権限用フックにはコールバックをメモ化していないという微妙な状態管理の問題がありました。
Opus 4.6 の結果： よりクリーンな分離で 5つのパーツに分割しました。専用の型ファイルを作成し、テストファイルを含むすべてのインポートを正しく更新し、権限用フックは適切にメモ化されていました。また、元のコンポーネントのエフェクトクリーンアップに潜在的なメモリリークがあることを指摘し、それを修正しました。
勝者：Opus 4.6
ここで差が顕著になります。依存関係の追跡を伴う複数ファイルのリファクタリングは、まさに Opus 4.6's 76% score on MRCR v2（複数ファイルの推論およびコードレビュー）が実用的な価値に変わるシナリオです。Sonnet のソリューションは 2回の修正が必要でしたが、Opus は最初の試行で正確なものを納品しました。
コスト： Sonnet $0.22（修正を含む） | Opus $0.95
シナリオ 4：既存コードのユニットテスト作成
タスク： 期限切れのカード、残高不足、ネットワークタイムアウト、一部返金、通貨換算など、複数のエッジケースを持つ支払い処理モジュールの包括的なユニットテストを作成する。
Sonnet 4.6 の結果： 私が説明したすべてのシナリオをカバーする 14個のテストケースを生成しました。テストは明確な describe/it ブロックで構成されていました。モックの設定も正確でした。私が明示的に言及していなかった 2つのエッジケース（金額が空、負の金額）も含まれていました。
Opus 4.6 の結果： 16個のテストケースを生成しました。同様の構造でした。支払いフロー全体をエンドツーエンドで検証する統合テストスタイルのテストを 1つ追加していました。テストの説明がわずかに冗長でした。
勝者：引き分け（コスパで Sonnet 4.6）
両者とも優れたテストスイートを作成しました。Opus は 2つ余分にテストを追加しましたが、それほど大きな差ではありませんでした。テスト生成に関しては、Sonnet は equivalent quality at 5x lower cost を提供します。極めて複雑なビジネスロジックをテストするのでない限り、Sonnet が正しい選択です。
コスト： Sonnet $0.09 | Opus $0.47
シナリオ 5：技術ドキュメントの作成
タスク： 内部 SDK の API ドキュメントを生成する。12個のパブリックメソッドについて、メソッドのシグネチャ、パラメータの説明、戻り値の型、使用例、エラーハンドリングのガイダンスを含める。
Sonnet 4.6 の結果： クリーンで整理されたドキュメントでした。各メソッドに説明、パラメータ表、戻り値の型、例、エラーセクションがありました。全体を通して一貫したフォーマットでした。
Opus 4.6 の結果： ほぼ同一のドキュメントでした。Opus は最後に、メソッドをどのように組み合わせるかを示す「一般的なパターン」セクションを追加してくれました。これは良かったのですが、頼んだものではありませんでした。
勝者：Sonnet 4.6
ドキュメント作成は、Sonnet の簡潔さがむしろ利点となるタスクです。developers comparing the two models が指摘しているように、Opus は単純なタスクに対して不要な説明を加え、tokens と時間を浪費することがあります。ドキュメントには、冗長で哲学的なものではなく、明確で完全なものが求められます。
コスト： Sonnet $0.14 | Opus $0.72
シナリオ 6：プルリクエストのコードレビュー
タスク： API にキャッシュレイヤーを追加した 400行のプルリクエストをレビューする。両方のモデルに、バグの特定、改善の提案、セキュリティ上の懸念の指摘を求めました。
Sonnet 4.6 の結果： 3つの問題を特定しました。更新時のキャッシュ無効化の漏れ、制限のないキャッシュ増大による潜在的なメモリリーク、そして TTL 追加の提案です。実用的で良いフィードバックでした。
Opus 4.6 の結果： 同じ 3つの問題に加え、さらに 2つ発見しました。キャッシュキー生成におけるタイミング攻撃の脆弱性と、キャッシュ生成中に並行リクエストが古いデータを返す可能性があるという微妙な問題です。並行性の問題を修正するために、特定のパターン（分散ロックを伴うリードスルーキャッシュ）を提案しました。
勝者：Opus 4.6
セキュリティに関連するコードのレビューも、Opus が優位に立つ分野です。タイミング攻撃の脆弱性は現実的で、明白ではないものでした。これは、障害が広いアーキテクチャの表面に及ぶ場合に Opus が特に強力であるという reports from developers と一致しています。
コスト： Sonnet $0.11 | Opus $0.53
シナリオ 7：新機能のラピッドプロトタイピング
タスク： WebSockets を使用したリアルタイム通知システムを構築する。サーバー側のハンドラー、クライアント側のフック、アニメーション付きの通知コンポーネント。優先事項は完璧さではなく時間でした。
Sonnet 4.6 の結果： 1回のレスポンスで動作する実装を納品しました。WebSocket ハンドラー、カスタム React フック、通知コンポーネントがすべて連携して動作しました。アニメーションは CSS ベースでスムーズでした。軽微な問題として、再接続ロジックがありませんでした。
Opus 4.6 の結果： 同様の質の出力でしたが、再接続ロジックとエクスポネンシャルバックオフ戦略が含まれていました。また、ハートビートメカニズムも追加されていました。token 生成速度が遅いため、生成に約 30% 長くかかりました。
勝者：Sonnet 4.6
プロトタイピングでは、完全性よりもスピードが重要です。Sonnet の faster output generation（Opus の約 40 tokens/sec に対し、約 47 tokens/sec）は、よりタイトなイテレーションループを意味します。Opus が追加した再接続ロジックは素晴らしいですが、どのみち 2回目のパスで追加するつもりでした。プロトタイピングは、速くて「十分に良い」出力を報います。
コスト： Sonnet $0.10 | Opus $0.48
シナリオ 8：アーキテクチャの意思決定
タスク： マイクロサービスプロジェクトにおいて、モノリポジトリとポリリポジトリのどちらの構造を選択すべきか決定する必要がありました。チームの規模、デプロイ要件、CI/CD の制約、サービスの境界線を提供しました。両方のモデルにトレードオフを分析し、アプローチを推奨するよう求めました。
Sonnet 4.6 の結果： 堅実な長所/短所の分析を提供しました。チーム規模に基づいて Turborepo を使用したモノリポジトリを推奨しました。妥当ですが、やや一般的でした。
Opus 4.6 の結果： 推奨事項を確定させる前に、デプロイ頻度、サービス間のデータ依存関係、チームにモノリポジトリの経験があるかどうかという 3つの確認の質問をしてきました。私が答えた後、ニュアンスに富んだ分析を提供し、「ハイブリッド」なアプローチを推奨しました。共有ライブラリと密結合されたサービスにはモノリポジトリを使用し、リリースサイクルが異なる独立してデプロイされるサービスには個別のリポジトリを使用するというものです。また、現在の構造からの移行パスも概説しました。
勝者：Opus 4.6
Opus は曖昧さをよりうまく処理します。multiple developer reports confirm しているように、Opus はより適切な確認の質問を行い、より納得感のある仮定を立てます。複雑なアーキテクチャ上の決定に取り組むシニアエンジニアにとって、その挙動は何時間ものやり取りを節約してくれます。
コスト： Sonnet $0.07 | Opus $0.62
最終スコアカード
8つのシナリオすべてにおける各モデルのパフォーマンスを、出力の質について 1-10 のスケールでスコア化した結果がこちらです。
| シナリオ | Sonnet 4.6 | Opus 4.6 | 勝者 |
|---|---|---|---|
| レースコンディションのデバッグ | 7 | 9 | Opus |
| CRUD エンドポイント | 9 | 9 | 引き分け（コスパで Sonnet） |
| コンポーネントのリファクタリング | 6 | 9 | Opus |
| ユニットテスト作成 | 8 | 8.5 | 引き分け |
| 技術ドキュメント | 9 | 8 | Sonnet |
| コードレビュー（セキュリティ） | 7 | 9 | Opus |
| ラピッドプロトタイピング | 9 | 8 | Sonnet |
| アーキテクチャの意思決定 | 6 | 9 | Opus |
Opus 4.6 の勝利：4 シナリオ（デバッグ、リファクタリング、コードレビュー、アーキテクチャ） Sonnet 4.6 の勝利：2 シナリオ（ドキュメント、プロトタイピング） 引き分け：2 シナリオ（CRUD エンドポイント、テスト作成）
しかし、このスコアカードに隠された真実があります。コストを考慮すると、8つのシナリオのうち 6つで Sonnet 4.6 が正しい選択でした。 スコアが著しく低かった 2つのシナリオ（リファクタリングとアーキテクチャ）は、ほとんどの開発者が 1日に何度も行うことではなく、週に数回行うタスクです。
コストの実態
3週間のテスト期間中、請求額は以下のようになりました。
| モデル | 総支出 | 完了タスク数 | タスクあたりの平均コスト |
|---|---|---|---|
| Sonnet 4.6 | ~$80 | 127 タスク | $0.63 |
| Opus 4.6 | ~$420 | 127 タスク | $3.31 |
Opus は平均してタスクあたり 5.25倍のコストがかかりました。同一のタスクセットに対して、Sonnet は 19% のコストで 90% の品質を提供しました。
もしハイブリッドアプローチ（日常的なタスクには Sonnet を使い、リファクタリング、デバッグ、アーキテクチャに関わるタスクの 20% だけに Opus を使う）を採用していたら、総請求額は $500 ではなく約 $160 になっていたでしょう。これは、品質をほとんど損なうことなく 68% の削減を意味します。
これは、production deployments report の報告とも一致しています。リクエストの 80-90% を Sonnet に送り、重要なタスクのみを Opus にエスカレーションするハイブリッドルーターパターンは、API コストを 60-80% 削減します。
ベンチマークでは捉えきれない、気づいた 3つのパターン
1. Opus は「待って、もっと情報が必要だ」と言うのが得意
曖昧なプロンプトに対して、Sonnet は妥当なデフォルトを選んで実行する傾向があります。Opus は立ち止まって質問します。これはアーキテクチャの作業には非常に価値がありますが、単に選択して進めてほしい日常的なタスクでは少し煩わしく感じることもあります。
2. Sonnet は指示に文字通り従うのが得意
詳細な仕様を与えたとき、Sonnet は求めたものを正確に構築しました。Opus は時として、頼んでもいないことを「改善」しようとします（抽象化レイヤーの追加、パターンの提案、範囲外のエッジケースの考慮など）。創造性よりも遵守が求められるタスクでは、Sonnet が勝ちます。
3. コンテキストが長くなるほど品質の差が広がる
10K tokens 未満のコンテキストでは、モデルの違いをほとんど見分けることができませんでした。しかし、大規模なリファクタリングや複数ファイルのレビューなど、コンテキストが 30K tokens を超えると、Opus の一貫性が著しく高まりました。これは、長いコンテキストにおける複数ファイルの推論に対する Opus 4.6's 76% score on MRCR v2 のスコアと一致しています。
参考：ベンチマーク結果
数値を知りたい方のために、2026年 3月時点の主要なベンチマークを掲載します。
| ベンチマーク | Sonnet 4.6 | Opus 4.6 |
|---|---|---|
| SWE-bench Verified | 79.6% | 80.8% |
| GPQA Diamond | 74.1% | 91.3% |
| MRCR v2 (long context) | ~18.5% (4.5 era) | 76% |
| 速度 (tokens/sec) | ~47 | ~40 |
| 最大コンテキスト | 1M tokens | 1M tokens |
| 最大出力 | 64K tokens | 128K tokens |
出典: Anthropic model overview, Artificial Analysis, Claude 5 benchmark analysis
SWE-bench の差はわずか 1.2 ポイントです。しかし、GPQA Diamond（科学的推論）の差は 17 ポイントと巨大です。そして、MRCR v2（長文コンテキストの複数ファイル作業）こそが、現実的な違いを生んでいる場所です。
私の推奨事項：意思決定フレームワーク
$500 と 3週間のテストを経て、私の決定ツリーは以下の通りです。
Sonnet 4.6 を使うべき場合：
- タスクが明確に定義され、要件がはっきりしている
- 新しいコードを一から書いている（エンドポイント、コンポーネント、スクリプト）
- 反復速度が必要（プロトタイピング、探索的コーディング）
- テストやドキュメントを生成している
- コンテキストの長さが 20K tokens 未満
- 予算が限られている、またはリクエスト量が多い
Opus 4.6 を使うべき場合：
- 複雑な依存関係を持つ複数ファイルにわたるリファクタリング
- 設計を確定する前に、モデルにトレードオフを検討してほしい
- 大規模なコードベースで明白ではない問題をデバッグしている
- セキュリティが重要なコードをレビューしている
- コンテキストが 30K tokens を超え、一貫性が重要
- 間違った答えの代償が、モデルの呼び出しコストを上回る
両方（ハイブリッドルーター）を使うべき場合：
- 複雑さが混在するタスクを持つ本番システムを構築している
- Sonnet による 60-80% cost savings を享受しつつ、難題には Opus というセーフティネットがほしい
開発者ツールを構築しているチームにとって（私たちは ZBuild でこのハイブリッドアプローチのバージョンを使用しています）、ルーターパターンは 2026年における業界標準となっています。
次回行うなら変えたいこと
もしこの実験をもう一度行うなら、3つ目の次元を追加します。各モデルが本番環境に耐えうる出力を得るために、何回の追加プロンプトを必要としたかを測定することです。私の直感では、複数ファイルの作業において Opus の初回精度の高さが一貫していたため、複雑なタスクではさらに Opus が有利になるはずです。
また、Opus で Extended Thinking を有効にしてテストしたいと考えています。これにより、すでに強力なデバッグ能力とアーキテクチャ推論能力がさらに向上すると報告されています。
結論：まずは Sonnet 4.6 ですべてを開始してください。タスクがいつ Opus を要求しているかは、すぐにわかります。Opus を必要とするタスクは具体的で、比較的稀であり、そのプレミアムを正当化できるほど高い価値を持っています。
ソース
- Anthropic — Introducing Claude Opus 4.6
- Anthropic — Claude Models Overview
- Anthropic — Claude Pricing
- Artificial Analysis — Claude Sonnet 4.6 Performance
- Claude 5 — Opus 4.6 Benchmark Analysis
- Bind AI — Sonnet 4.6 vs Opus 4.6 for Coding
- Emergent — Claude Sonnet vs Opus 2026
- DEV Community — Opus 4.6 vs Sonnet 4.6 Coding Comparison
- Macaron — Claude Opus 4.6 for Code Review
- Apiyi — Opus 4.6 vs Sonnet 4.6 Comparison Guide
- Medium — Tested Sonnet 4.6 vs Opus 4.6 for Vibe Coding