Sonnet 5.5とOpus 5.5の使い分け：どんな開発作業でOpusを試す？

要件が明確な開発作業ではSonnet 5.5を、判断が難しい作業、曖昧さがある作業、失敗が続く作業ではOpus 5.5も評価対象に入れましょう。 これは評価するタスクの選び方です。Sonnetなら小さな作業は必ず解ける、Opusなら大きな作業で必ず勝つという証明ではありません。合格基準はリポジトリのテストとレビュー規則です。

AnthropicはSonnetを、より速く低コストでOpusを補うモデルと位置づけ、Opusは慎重な判断が必要な複雑な仕事に適すると説明しています。ただし料金とeffortを考えると、単に「Sonnetは半額」とは決められません。2026年9月29日に確認した資料に基づくガイドであり、独自の直接比較実験ではありません。

単価だけでは選べない

出典：Sonnetの仕様、Opusの仕様。提供元の単価であり、月額契約の利用枠やOfoxの見積もりではありません。リポジトリの文脈を繰り返し使う場合、キャッシュ読み取りの行が重要です。大きな共通プレフィックスをキャッシュから読む場合には、キャッシュなし入力・出力と同じ2倍の差はありません。

キャッシュ読み取り100,000トークンと課金対象出力2,000トークンが同じで、他の課金項目をすべて除いた仮想リクエストを考えます。Sonnetは0.04ドル、Opusは0.06ドルです。この例では読み取り単価が同じなので2倍にはなりません。どちらかのモデルで往復が増えれば、結果はまた変わります。

タスクを検証可能な成果に結びつける

これは試験の設計であり、実測の合格率ではありません。短いパッチでも難しい推論が必要なことがあり、長い機械的変更は容易なこともあります。ファイル数や変更行数だけで難しさを判断しないでください。

ベンチマークは条件と一緒に読む

Artificial AnalysisのSonnet公開時レポートは、複数のタスクで良い結果を示す一方、maxでは出力消費が大幅に増えると報告しています。また、試験した公開前環境に構造化出力の問題があり、再測定を予定しているとしています。両モデルを試す理由にはなっても、自分の用途で最安の設定は確定できません。

Opus mediumとSonnet maxを比べて、純粋なモデル差と呼ばないでください。それは設定を含む比較です。その比較自体には価値がありますが、両方の設定と実際の予算を示す必要があります。同じeffort名でも計算量が等しいとは限りません。

Anthropicの公開告知も、各モデルの強みと評価条件を説明しています。提供元の主張、独立測定、自分の観察は分けて扱います。図の結果が食い違う理由は、課題や設定の違いかもしれません。

切り替えの基準を先に決める

実行前に停止条件を決めます。たとえば「修正案を1回作り、回帰テストを行う」です。失敗したら、再実行の前に原因を確認します。タスクを誤解していたなら、effortを上げ続けるより入力を明確にします。正しい箇所は見つけても有効な修正を作れないなら、条件を管理してOpusを試す意味があります。

新しい実行には、問題説明、関連ファイル、テスト結果を渡します。署名付きの思考ブロックがモデル間で移せるとは限りません。Sonnet 5.5のモデル・会話固有の規則は移行ガイドを参照してください。見えない推論の継続に頼らず、見える証拠を残しましょう。

最初の試行と切り替え後の費用はまとめて記録します。最初の失敗を片方に、最後の成功だけをもう片方に付けると、ルーティングが実際より安く見えます。コンパイルできても大幅な手直しが必要なパッチは完成とはいえないので、レビュー時間も記録してください。

三つの入力構成で料金の比率を計算する

同じモデル同士でも、処理の構成で料金比は変わります。次は使用トークン数を揃え、標準サービスとベンダー定価で計算した合成例です。別料金は含めず、モデルの動作ではなく課金差を切り分けます。

Opus の5分・1時間キャッシュ作成は100万トークン当たり $5・$8、Sonnet は $2.50・$4 です。各モデルで100Kの5分キャッシュを1回作り、9回読み、各回2Kを出力すると、10回の小計は Sonnet $0.63、Opus $1.08。内訳は Sonnet が作成 $0.25＋読み取り $0.18＋出力 $0.20、Opus が $0.50＋$0.18＋$0.40 です。比率は約1.71倍で、一定の2倍ではありません。

モデルを切り替えても既存キャッシュを引き継げるとは仮定しません。この例は各モデルに初回書き込みを計上しています。実際のトークン数と再利用状況は変わり得ます。安いモデルが2倍の試行を必要とすれば優位を失う場合があります。一方、高いモデルが長い説明と同じ失敗パッチを返すだけなら、適切な選択ではありません。

早い段階で Opus を加えるべき難しさとは

難しさは編集量よりも、正しい動作が確定していないことにある場合があります。認可条件の1行は、30ファイルの API 名置換より慎重な判断を要するかもしれません。Anthropic の位置づけは、長時間で判断を要する仕事に Opus を候補とする根拠になりますが、特定の1行バグに Opus が必須という保証ではありません。

根因が未確定か、要件が衝突しているか、結果が高コストの副作用を起こし得るか、正誤照合ではなく代案の評価が必要か。この四つを確認します。複数が当てはまれば、パッチを採用する前にもう一つの設定を試す理由になります。ツール権限を広げる理由にはなりません。

失敗するスナップショットがある局所的な表示バグなら、Sonnet から始め、対象と周辺の回帰テストを要求します。支払いの再試行で二重請求が起こり得るなら、冪等性、部分失敗、復旧を合格条件に含めます。必要なら Opus を調査に加えますが、機微な変更にはフィクスチャと人の確認を使います。強いモデルも外部作用の隔離を代替しません。

設計の仕事では、両候補に制約、代案、戻せる移行手順を出させます。自信に満ちた図ではなく、実際のコードと配備条件に合うかで評価します。関連モジュールへの参照と、途中の状態も有効な実装順序を求めます。その入力が足りないなら、意見の不一致をモデルの弱点と決める前に資料を補います。

最初の試行前にエスカレーション予算を決める

Sonnet で範囲を限定した1回を試し、失敗を診断してから、説明を補うか Opus を試すか決めるのが簡単な方針です。同じプロンプトを無制限に再送しません。依存関係の欠落や壊れたフィクスチャはモデル変更では直りません。環境を修復し、推論の失敗とは別に記録します。

仮に Sonnet の試行が $0.06、Opus への追加試行が $0.12、追加は最大1回とします。タスクのうち追加が必要な割合を e とすると、投入タスク当たりの平均トークン費は $0.06 + $0.12e。e = 25% なら $0.09、50%なら $0.12 で、最初から Opus を1回使う仮定と同じです。50%を超えると、この経路は直接 Opus の基準より高くなります。

これは合格率の予測ではありません。成功率の差、コンテキスト準備、キャッシュ状態、確認作業、遅延を除いています。Opus も失敗したり追加ターンを使ったりすれば計上します。合格タスク費用と未解決の割合を両方示してください。急ぐ仕事では、重要な案件で毎回遅延が追加されるなら、平均が安くても悪い方針になり得ます。

二つ目のモデルへ検証可能な引き継ぎを渡す

期待動作、現在のcommit、再現コマンド、実際の失敗、試したパッチ、不採用理由を短くまとめます。関連ファイルか、次の実行がアクセスできる参照だけを含めます。根因が未確定なら、修正前に根因を説明させ、既に否定された仮説を繰り返さないようにします。

「前のモデルが X と言ったから X は正しい」という資料にしてはいけません。実際のテスト出力とモデルの解釈を分けます。最初の試行がファイルを変えたなら基準へ戻すか、次の開始状態が異なると記録します。そうしないと Opus の見かけの成功は Sonnet が先に行った作業に依存し、見かけの失敗は壊れたワークスペースを引き継いだ結果かもしれません。

レビューでは、各指摘のファイルと行、発生条件、再現可能な影響、修正前から存在したかを確認します。重複をまとめてから件数を数えます。別モデルは説明を疑う助けになりますが、2モデルの同意も再現した欠陥と同じではありません。

タスク分類ごとに運用へ落とし込む

頻繁で仕様が明確、安く検証できる作業には Sonnet を候補として残します。不確実または失敗コストが高い作業には Opus を加え、直接 Opus の基準も残して段階的な切り替え自体の無駄を確認します。ある分類で追加試行が続くなら、プロンプトや連携の不備を除外してから直接割り当てを検討します。

検索、実装、最終レビューは異なる要件を持ち得ますが、分割には引き継ぎ費もかかります。全体を測る前に節約を主張しないでください。サブスクリプションでも品質と時間の考え方は使えますが、API の算式を個別アカウントの利用枠へ置き換えてはいけません。どの作業をどちらへ渡すか、その理由と、判断を変える証拠まで説明できる方針にします。

月額契約で使う場合

API料金表からClaude Codeで送れるプロンプト数を正確に割り出すことはできません。利用枠や上限はアカウントとサービス条件によります。クライアント更新や提供事業者の変更後は、選択中のモデルを確認し、課金方式とモデル名を区別してください。

Claude Code設定ガイドではバージョン確認と明示的なモデル選択を説明しています。EffortガイドはAPIとClaude Codeの既定値を区別しています。他社モデルも試す場合はSonnetとSolの比較方法を利用できます。