Anthropic から Claude 4.6 系列が公開されてから、私が日々受ける質問でいちばん多いのが「結局どっちを使えばいいんですか?」というものです。Sonnet 4.6 と Opus 4.6 の使い分けですね。
公式ドキュメントには「Opus は最も高度な推論に、Sonnet はバランス型に」といった抽象的な説明しか載っていません。間違ってはいないのですが、実際に手を動かす人にとっては「で、自分のこの作業はどっちなの?」が知りたいはずです。
私は個人で 4 つのウェブサイトと複数のモバイルアプリを運営しているので、Claude を 1 日に 100 回以上叩く生活をしています。両モデルをひと月以上並行して使い込んだ体感をベースに、タスク別の使い分けをまとめてみます。あくまで個人の体感ですが、似た判断軸で迷っている方の参考になれば嬉しいです。
まず大前提として、料金差は約 5 倍
判断の入り口になるのは料金差です。原稿執筆時点での API 価格でいうと、Sonnet 4.6 と Opus 4.6 の入出力単価には約 5 倍の開きがあります。チャット UI の Pro プランでも、Opus にはレートリミットが厳しめにかかっています。
つまり「迷ったら Opus にしておこう」は、コスト的にも回数制限的にも持続可能ではありません。Sonnet で十分に解ける問題まで Opus に投げるのは、現代における過剰品質です。逆に、Sonnet では届かない問題に Sonnet を投げ続けると、何度もやり直しが発生して結局トータルの料金は Opus より高くつくことがあります。
この「やり直しコスト」を見落としている方が意外に多いというのが、私の実感です。Opus に一発で解いてもらうほうが、Sonnet で 3 回試行錯誤するより安いケースは普通にあります。
Sonnet 4.6 で十分な、私が日常的に投げているタスク
私が「これは Sonnet で 1 発」と決めているタスクをいくつか挙げます。
ひとつは、定型的なコード生成です。React コンポーネントの雛形作成、ユーティリティ関数の実装、CRUD 画面のスキャフォールディングなど、パターン化された作業は Sonnet で十分です。Opus との差はほぼ感じません。
ふたつめは、文章の校正・翻訳・要約です。私は記事を日英で書きますが、片方を書いてもう片方に翻訳させる作業はすべて Sonnet にお願いしています。Opus と並べて品質を見比べたこともありますが、ブログ記事レベルの翻訳ではほぼ違いがわかりませんでした。一方で API コストは 5 倍違うので、Sonnet 一択です。
3 つめは、シンプルな質問応答や Slack ボット的な使い方です。よくある FAQ や、すでに知っていることを整理して伝えるような場面では、Opus は明らかなオーバースペックです。
4 つめは、テストコードの生成です。前述の TDD ワークフローでは私はほぼ Sonnet を使っています。テストは「振る舞いを言語化する」作業であって、深い推論を要する作業ではないからです。
Opus 4.6 でないと厳しい、悔しいけど Opus 案件
逆に、Sonnet で何度試しても満足できず、Opus に切り替えた瞬間に解決した経験があるタスクもあります。
ひとつは、複数ファイルにまたがる構造的なリファクタリングです。たとえば「この機能の責務を、認証層・ビジネスロジック層・データアクセス層に分離してください」のような依頼は、Sonnet だと個々のファイルは綺麗になるのに、全体の整合性が崩れることがあります。Opus はこれを高い確度で揃えてくれます。
ふたつめは、難しいデバッグです。原因が複数の要因の絡み合いで、ログだけ見ても直感的にわからない問題、いわゆる「妙なバグ」のたぐいですね。Sonnet だと「これかもしれません」「あれかもしれません」と推測の段数が増えてしまうのですが、Opus は仮説の確度が一段高い印象です。
3 つめは、新しい設計を 0 から起こす作業です。「マルチサイトのオートメーション基盤を設計してください」のように、トレードオフの判断が連鎖する場面は、Opus のほうが踏み込んだ提案をくれます。Sonnet は無難な案を出してくれるのですが、Opus は「ここで MQ を挟むと将来こういう拡張が楽になりますが、最初の半年は YAGNI かもしれません」のような、判断材料まで添えてくれることが多いです。
4 つめは、長文の論理整合性チェックです。記事の論理展開におかしなところがないか、契約書や規約のドラフトに矛盾がないかをチェックさせる場合、Opus の検出力は明確に上です。
中間ゾーンをどう判断するか
実務では「これは Sonnet で行けるか、Opus にすべきか微妙」というタスクがいちばん多いと思います。私が使っている判断軸を共有します。
まず「やり直しのコストは高いか?」と自問します。コードレビューに 1 時間かかるような出力なら、Opus で精度を上げる価値があります。逆に、目で見れば数秒で良し悪しがわかる出力なら、Sonnet で試行回数を増やすほうが合理的です。
次に「失敗したら誰が困るか?」です。本番にデプロイされる Stripe Webhook の実装は、自分のコードレビュー時間を増やすより Opus に任せるほうが安全です。一方、社内ツールの管理画面のスタイル調整なら Sonnet で十分です。
3 つめは「この問いは検索可能か?」です。Stack Overflow に答えがありそうなレベルの質問なら Sonnet で十分です。世界中の誰も解いていないであろう独自の問題なら、Opus の出番です。
最後に「会話の途中で行き詰まったら、Opus に切り替える」を習慣にしています。Sonnet で 3 ターンやって埒が明かないときは、コンテキストを貼り付けて Opus に投げ直します。これで解決しないことのほうが珍しいです。
並行運用の小技 — 同じ問いを両方に投げる
少し変則的ですが、私が高頻度で使っているテクニックを共有します。重要な意思決定が絡む問いには、Sonnet と Opus の両方に同じ質問を投げて答えを比較します。
たとえば「この技術選定で、Cloudflare Workers と Vercel Edge どちらが良いか」のような判断系の問いです。両者の答えを並べて読むと、共通する論点と、Opus だけが拾った視点が見えてきます。コストは 1 回分余計にかかりますが、自分で検索して 30 分調べるより遥かに早いです。
逆に、コード生成では並行運用しません。出力をマージするコストが高すぎるからです。これはあくまで「答えを比較したい」場面に限った技です。
「Opus は遅い」をどう乗り越えるか
Opus の体感的な弱点は、応答速度です。Sonnet と比べて明らかに待ち時間が長く、長い回答になればなるほど差が開きます。インタラクティブに対話したい場面では、この遅さが思考のリズムを乱します。
私の対処は 2 つです。ひとつは「Opus に投げる質問は、長めに整える」ことです。短い問いを連射するなら Sonnet、まとまった依頼を 1 発で投げるなら Opus と切り分けます。Opus に短い質問を連投するのは、性能を活かしきれず、待ち時間ばかり浪費します。
もうひとつは「Opus に投げたら別作業に移る」ことです。Opus が考えている間に、Sonnet で別タスクを処理するか、メールを返すか、コーヒーを淹れます。回答を待ちながら何もしない時間がいちばん損です。
それぞれの「外し」パターンを知っておく
両モデルとも、それぞれ典型的な「外し」のパターンがあります。これを知っておくと、出力を見たときに「あ、外してるな」と早く気づけます。
Sonnet の典型的な外しは、「もっともらしいが浅い回答」です。一見正しそうな構造で答えてくれるのですが、よく読むと根拠が薄いか、エッジケースを取りこぼしています。コードでいうと、ハッピーパスは動くがエラー処理が雑、というやつです。
Opus の典型的な外しは、「過剰な丁寧さ」です。聞いていないことまで説明してくれて、本題が薄まることがあります。あと、「これは最終的にはあなたの判断ですが」のような留保が長くなりがちです。これは Opus のほうが慎重に振る舞うように訓練されているせいで、悪い性質ではないのですが、即断したい場面では邪魔になります。
私はそれぞれの外しに対して、プロンプトで「結論を 1 行で先に出して」と指定したり、「エッジケースを 5 つ挙げて」と明示的に求めたりして対応しています。
体感を数字で裏取りする — ベンチマークが示す差
ここまでは私の体感を並べてきました。ただ、体感だけでは説得力に欠ける場面もあります。公開されている主要ベンチマークの数字を並べると、私の使い分けとほぼ重なることが見えてきます。
ベンチマーク 測るもの Opus 4.6 Sonnet 4.6
SWE-bench Verified コーディング総合力 80.8% 79.6% GPQA Diamond 大学院レベルの科学的推論 91.3% 74.1% OSWorld-Verified GUI 操作・デスクトップ自動化 72.7% 72.5%
コーディングの差は約 1 ポイント、GUI 操作はほぼ横並びです。つまり日々のコード生成や自動化タスクでは、5 分の 1 のコストで走る Sonnet を選ばない理由がほとんどありません。私が定型的なコード生成を Sonnet に振り切っているのは、この数字の裏付けがあるからです。
一方、GPQA Diamond の 17 ポイント差が、私が「悔しいけど Opus 案件」と呼ぶ領域そのものです。推論の段数が深くなるほど、この差は体感に効いてきます。難しいデバッグや 0 からの設計で Opus に切り替えると解決する、あの瞬間ですね。
コンテキストウィンドウは両モデルとも標準 200K トークンです。Opus 4.6 はベータで 100 万トークンに対応しており、大規模なコードベースを一度に読ませたい場面ではここも判断材料になります。私自身、個人開発で Dolice の複数サイトのコードをまとめて読ませるとき、この 100 万トークンの余裕に助けられています。
さらに一歩 — Opus に設計させ、Sonnet に量産させる二層構造
前節の choose_model は「1つのタスクを丸ごとどちらかに振る」発想でした。もう一段踏み込むと、ひとつのタスクの中で役割を分ける手があります。Opus を設計役（アドバイザー）、Sonnet を実行役に据える二層構造です。
私が個人開発でマルチサイトの自動化を組むときに落ち着いたのが、この形でした。最初に Opus へ「何をどの順で作るか」を一度だけ相談します。Opus は判断材料を添えた計画を返してくれます。その計画を Sonnet に渡し、各ステップのコードや文章を量産させます。最後にもう一度だけ Opus に通して、全体の整合性をレビューしてもらいます。
つまり Opus を呼ぶのは「最初の設計」と「最後のレビュー」の2回だけ。中身の繰り返し作業はすべて Sonnet が担います。Opus の判断力を一番効く2点に集中させ、量がかさむ部分は Sonnet のコストで回す、という配分です。オーケストレーター側をさらに安いモデルへ寄せる派生形については、二段構えのモデル構成 — Haiku 4.5 オーケストレーター × Opus 4.6 ワーカーで保つコストと品質の均衡 で詳しく扱っています。
import anthropic
client = anthropic.Anthropic()
ADVISOR = "claude-opus-4-6" # 設計とレビュー EXECUTOR = "claude-sonnet-4-6" # 量産
def plan (goal: str ) -> str : """Opus に、実行役がそのまま着手できる粒度の手順を立ててもらう""" msg = client.messages.create( model = ADVISOR , max_tokens = 2048 , messages = [{ "role" : "user" , "content" : ( f "目的: { goal }\n " "これを実装する手順を、各ステップが独立して着手できる粒度で列挙してください。" "ステップごとに『入力・やること・完了条件』を明記してください。" ), }], ) return msg.content[ 0 ].text
def execute (step: str ) -> str : """Sonnet に各ステップを実行させる（量がかさむ部分はすべてここ）""" msg = client.messages.create( model = EXECUTOR , max_tokens = 4096 , messages = [{ "role" : "user" , "content" : f "次のステップを実装してください: \n{ step } " }], ) return msg.content[ 0 ].text
def review (goal: str , outputs: list[ str ]) -> str : """最後にもう一度だけ Opus に全体整合性を見てもらう""" joined = " \n\n --- \n\n " .join(outputs) msg = client.messages.create( model = ADVISOR , max_tokens = 2048 , messages = [{ "role" : "user" , "content" : ( f "目的: { goal }\n 以下は各ステップの実装結果です。 \n{ joined }\n\n " "全体として矛盾・抜け・重複がないか指摘し、必要なら修正方針を示してください。" ), }], ) return msg.content[ 0 ].text
# Opus 2回（設計・レビュー）＋ Sonnet N回（量産） steps_text = plan( "4サイト共通の記事生成パイプラインを設計する" ) steps = [s for s in steps_text.split( " \n " ) if s.strip().startswith(( "-" , "1" , "2" , "3" ))] results = [execute(s) for s in steps] final = review( "4サイト共通の記事生成パイプラインを設計する" , results) print (final) 個人開発では Opus のレートリミットも財布も自分持ちなので、この配分は効きました。この形にしてから、Opus の呼び出し回数は体感で 5 分の 1 以下になりました。それでいて、設計の質は Opus 単体で回していた頃とほとんど変わりません。最初の計画さえ筋が通っていれば、各ステップの実装は Sonnet で十分に追従できるからです。
注意点を1つだけ。私自身、最初にここで何度かつまずきました。設計役の出力は、実行役がそのまま読める形で渡すことが肝心です。曖昧な計画を Sonnet に投げると、解釈のばらつきが各ステップへ伝播します。Opus には「次の工程がそのまま着手できる粒度で」と頼んでおくと、後段がぐっと安定します。
やり直しコストまで金額化する — 5 倍差が逆転する条件
本文の序盤で「やり直しコストを見落としている方が意外に多い」と書きました。ここを、私が手元で使っている概算モデルとして数字に落としておきます。判断がぶれたときに立ち返れる物差しがあると、迷いがずいぶん減ります。
見積もる費目は 2 つです。API 単価（1 試行あたり）と、出力を人間が確かめる確認コスト（時間）。API 単価は Sonnet を 1 とすると Opus は約 5、という本文の前提をそのまま使います。
費目 Sonnet 4.6（3 回試行） Opus 4.6（1 回）
API 単価（1 試行 8 円想定） 24 円 40 円 確認コスト（1 回 10 分・時給 3,600 円＝1 分 60 円） 1,800 円 600 円 合計 1,824 円 640 円
API 単価だけを見ると Sonnet 3 回の 24 円は Opus 1 回の 40 円より安く見えます。ところが出力を目視で確かめるのに 1 回 10 分かかり、自分の時間を時給 3,600 円で見積もると、確認コストは 1 試行あたり 600 円。試行回数がそのまま確認回数に乗るため、Sonnet 3 回では確認だけで 1,800 円、Opus 1 回なら 600 円です。合計すると Sonnet 3 回が 1,824 円、Opus 1 回が 640 円。API 単価では 5 倍差だったのに、確認コストを乗せた瞬間に逆転します。
損益分岐はシンプルで、「やり直し 1 回あたりの確認コスト ÷ API 単価差」で決まります。確認に人手がかかる出力ほど Opus が有利で、良し悪しが数秒で判る出力、たとえば見た目の微調整などは確認コストがほぼ 0 なので、Sonnet の試行回数を増やすほうが常に安い。私が中間ゾーンで迷ったときは、まずこの一点を暗算するようにしています。
手順にすると、次の 4 ステップで 30 秒あれば裁けます。
その出力の確認に何分かかるかを見積もる（数秒 / 数分 / 数十分）。
確認が数秒で済むなら Sonnet に振り、試行回数で押す。
確認が数分以上かかるなら、やり直し想定回数 × 確認コストを暗算する。
それが API 単価差を超えるなら、Opus に一発で任せる。
この物差しは、月次のコスト設計と組み合わせると効きます。トークン単位の削減はAnthropic APIコスト削減：月額費用を50〜70%削減する最適化技術 に、月末着地の予測はClaude API のトークンコストを月初3日間データから±10%精度で月末予測する にまとめています。モデルの振り分けにこの 2 つを重ねると、「どのタスクを・どのモデルで・月いくら」まで見通せるようになります。
暗算を関数に落とす — 失敗したら昇格させるルーティング
ここまでの物差しは、私が手で投げるときには十分に回ります。困るのは自動化パイプラインに組み込んだときで、人間の暗算が挟めません。
最初に書いたのは、タスク種別で固定的にモデルを振り分けるコードでした。これは早々に破綻しました。「本番レビューは Opus、下書きは Sonnet」と決め打ちしても、下書きの中に難しいものが混ざるからです。
いま使っているのは、まず Sonnet に投げ、機械的な検証に落ちたときだけ Opus に昇格させる形です。
from dataclasses import dataclass from typing import Callable
import anthropic
client = anthropic.Anthropic()
SONNET = "claude-sonnet-4-6" OPUS = "claude-opus-4-6"
@dataclass class RouteResult : text: str model: str escalated: bool
def _ask (prompt: str , model: str ) -> str : message = client.messages.create( model = model, max_tokens = 2048 , messages = [{ "role" : "user" , "content" : prompt}], ) return message.content[ 0 ].text
def route (prompt: str , verify: Callable[[ str ], bool ]) -> RouteResult: """まず Sonnet。verify が False を返したときだけ Opus に昇格する。""" draft = _ask(prompt, SONNET ) if verify(draft): return RouteResult(draft, SONNET , escalated = False )
final = _ask(prompt, OPUS ) return RouteResult(final, OPUS , escalated = True )
# verify は「機械が数秒で判定できるもの」に限る def valid_json (text: str ) -> bool : import json try : json.loads(text) except json.JSONDecodeError: return False return True
result = route( "次のログを JSON 配列に整形してください: ..." , verify = valid_json) print (result.model, result.escalated) 肝は verify の設計です。JSON がパースできるか、生成したテストが通るか、lint が黙るか。人間が目視しないと判らない基準を verify に入れた途端、この仕組みは前節の確認コストに飲まれます。
昇格方式が得になる条件
昇格率を r、Sonnet の単価を Cs、Opus の単価を Co とすると、昇格方式の期待コストは Cs + r × Co。最初から Opus に投げれば Co です。前者が安いのは次の条件を満たすときです。
条件 意味
r < 1 − Cs / Co 昇格方式のほうが安い Cs / Co = 1 / 5 のとき r < 0.8 なら昇格方式が有利
5 倍差なら、Sonnet が 8 割落ちるまでは「まず Sonnet」が正解になります。実運用で昇格率が 8 割に達するタスクはほとんどありません。私のパイプラインでは 12〜18% で推移しています。
ですので、迷ったら昇格方式を初期値にして構いません。ただし escalated を必ずログに残してください。r が跳ね上がったタスク種別は、Sonnet に向いていないという事実を静かに教えてくれます。プロンプトを直すか、Opus 直行に切り替えるか、判断材料はそこに揃います。
結局のところ、私の現在の比率
参考までに、私の Claude 利用は現在 Sonnet 4.6 が約 80%、Opus 4.6 が約 20% です。Anthropic がモデルをアップデートするたびに少しずつ比率が変わっていますが、ここ数ヶ月はだいたいこの感じで安定しています。
Sonnet が 80% を占めているのは、サボっているからではなく、Sonnet で十分なタスクが多いからです。逆に Opus の 20% は、その多くが「Sonnet では届かないと判明した瞬間」で消費されています。
明日からあなたに試してほしいのは、この比率を 1 度測ってみることです。今週、Opus を使った場面をメモしておき、その中で「本当に Opus が必要だった」と思える割合を数えてください。3 割を切っているなら、Opus を Sonnet に切り替えても満足度はほぼ変わらず、月々のコストだけ下がる可能性があります。逆に「Sonnet で済ませたが本当は Opus だった」場面が多ければ、品質を上げるチャンスが眠っています。