Claude Sonnet 4.6 と Opus 4.6 の使い分け — タスク別の実体験ベース選択ガイド

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 つ挙げて」と明示的に求めたりして対応しています。

体感を数字で裏取りする — ベンチマークが示す差

ここまでは私の体感を並べてきました。ただ、体感だけでは説得力に欠ける場面もあります。公開当時に発表されていた主要ベンチマークの数字を並べると、私の使い分けとほぼ重なることが見えてきます。

コーディングの差は約 1 ポイント、GUI 操作はほぼ横並びです。つまり日々のコード生成や自動化タスクでは、5 分の 1 のコストで走る Sonnet を選ばない理由がほとんどありません。私が定型的なコード生成を Sonnet に振り切っているのは、この数字の裏付けがあるからです。数値は当時の発表値ですので、最新の世代で判断するときは公式の最新表で引き直してください。

一方、GPQA Diamond の 17 ポイント差が、私が「悔しいけど Opus 案件」と呼ぶ領域そのものです。推論の段数が深くなるほど、この差は体感に効いてきます。難しいデバッグや 0 からの設計で Opus に切り替えると解決する、あの瞬間ですね。

コンテキストウィンドウは両モデルとも標準 200K トークンです。Opus 4.6 はベータで 100 万トークンに対応しており、大規模なコードベースを一度に読ませたい場面ではここも判断材料になります。私自身、個人開発で複数リポジトリのコードをまとめて読ませるとき、この 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("複数リポジトリ共通のデプロイ前チェックを設計する")
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("複数リポジトリ共通のデプロイ前チェックを設計する", results)
print(final)

個人開発では Opus のレートリミットも財布も自分持ちなので、この配分は効きました。この形にしてから、Opus の呼び出し回数は体感で 5 分の 1 以下になりました。それでいて、設計の質は Opus 単体で回していた頃とほとんど変わりません。最初の計画さえ筋が通っていれば、各ステップの実装は Sonnet で十分に追従できるからです。

注意点を1つだけ。私自身、最初にここで何度かつまずきました。設計役の出力は、実行役がそのまま読める形で渡すことが肝心です。曖昧な計画を Sonnet に投げると、解釈のばらつきが各ステップへ伝播します。Opus には「次の工程がそのまま着手できる粒度で」と頼んでおくと、後段がぐっと安定します。

やり直しコストまで金額化する — 5 倍差が逆転する条件

本文の序盤で「やり直しコストを見落としている方が意外に多い」と書きました。ここを、私が手元で使っている概算モデルとして数字に落としておきます。判断がぶれたときに立ち返れる物差しがあると、迷いがずいぶん減ります。

見積もる費目は 2 つです。API 単価（1 試行あたり）と、出力を人間が確かめる確認コスト（時間）。API 単価は Sonnet を 1 とすると Opus は約 5、という本文の前提をそのまま使います。

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 秒あれば裁けます。

1. その出力の確認に何分かかるかを見積もります（数秒 / 数分 / 数十分）。
2. 確認が数秒で済むなら Sonnet に振り、試行回数で押します。
3. 確認が数分以上かかるなら、やり直し想定回数 × 確認コストを暗算します。
4. それが 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 です。前者が安いのは次の条件を満たすときです。

5 倍差なら、Sonnet が 8 割落ちるまでは「まず Sonnet」が正解になります。実運用で昇格率が 8 割に達するタスクはほとんどありません。私のパイプラインでは 12〜18% で推移しています。

ですので、迷ったら昇格方式を初期値にして構いません。ただし escalated を必ずログに残してください。r が跳ね上がったタスク種別は、Sonnet に向いていないという事実を教えてくれます。プロンプトを直すか、Opus 直行に切り替えるか、判断材料はそこに揃います。

4.6 世代の物差しを、いまのラインナップへ移す

ここまでの内容は 4.6 系列が現役だった頃の記録です。その後 Sonnet 5 が既定モデルになり、Opus も 4.8 まで進みました。

モデル名は変わりましたが、ここまで使ってきた物差し — やり直しのコスト、失敗したときに誰が困るか、その問いが検索可能か — は、そのまま流用できます。入れ替わるのは、そこに代入する数字のほうです。

コード側の移行自体は定数の差し替えだけで済みます。

# 4.6 世代
SONNET = "claude-sonnet-4-6"
OPUS = "claude-opus-4-6"
 
# 現行世代への読み替え
SONNET = "claude-sonnet-5"
OPUS = "claude-opus-4-8"

ただ、定数を書き換えて終わりにできない箇所が 3 つあります。

単価比が動くと、昇格方式の分岐点も動く

世代が替わると、Sonnet と Opus の単価比は変わります。導入期の価格や改定の時期もありますので、単価は必ず公式の料金表で自分で確認してください。

前節で置いた昇格方式の条件 r < 1 − Cs / Co は、単価比 Cs/Co にそのまま従います。5 倍差を前提にした「r < 0.8」は、比が縮めばそのぶん厳しくなります。

比が 2 分の 1 まで縮むと、昇格率 5 割で損益が並びます。私のパイプラインの 12〜18% にはまだ余裕がありますが、「まず Sonnet に投げておけば安い」が無条件に成り立つ前提ではなくなります。

実務としては、単価の改定を知るたびに escalated のログを持ってきて、実際の単価で一度引き直すのが安全です。自分の昇格率が上の表のどの行に落ちるかだけ確認できれば、判断は数分で済みます。

「長いから Opus」という理由づけが消えた

本文のベンチマーク節では、100 万トークンのコンテキストを Opus 側の判断材料として挙げました。当時は Opus 4.6 のベータ機能だったからです。

現行世代の Sonnet が長いコンテキストを扱えるかどうかは、公式のモデル仕様で確かめてください。扱えるなら、入力の長さを理由に Opus を選ぶ場面はほぼ無くなります。いま Opus を選ぶ理由は、長さではなく推論の段数の深さに絞られます。

私の運用では、複数リポジトリのコードをまとめて読ませる用途を Sonnet 側へ移しました。読ませる量の多さと、そこから引き出す判断の難しさは別物だった、という整理です。

廃止されるパラメータを棚卸しする

モデルが替わるたびに、特定世代だけの機能（たとえば speed: "fast" のような指定）が廃止されることがあります。廃止後にそのパラメータを送ると、呼び出しがエラーになりかねません。実際の廃止日は公式の非推奨一覧でご確認ください。

自動化パイプラインに埋め込んだ設定は、動いている限り読み返さないものです。次の 3 点だけ確認しておくと、当日に慌てずに済みます。

3 つめが抜けていると、深夜に走るバッチが音もなく落ち続けます。私は以前これで丸一日気づかなかったことがあり、それ以来モデル移行のたびに通知経路のほうを先に確かめるようにしています。

結局のところ、私の現在の比率

参考までに、4.6 世代を回していた頃の私の比率は Sonnet が約 80%、Opus が約 20% でした。世代が変わってもこの配分はほとんど動いていません。上位モデルが強くなるほど下位モデルも底上げされるので、比率そのものは安定するようです。

Sonnet が 80% を占めているのは、サボっているからではなく、Sonnet で十分なタスクが多いからです。逆に Opus の 20% は、その多くが「Sonnet では届かないと判明した瞬間」で消費されています。

明日からあなたに試してほしいのは、この比率を 1 度測ってみることです。今週、Opus を使った場面をメモしておき、その中で「本当に Opus が必要だった」と思える割合を数えてください。3 割を切っているなら、Opus を Sonnet に切り替えても満足度はほぼ変わらず、月々のコストだけ下がる可能性があります。逆に「Sonnet で済ませたが本当は Opus だった」場面が多ければ、品質を上げるチャンスが眠っています。