0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@dachshund129(ダックス フント)

なんとなくOpusを選んでいませんか？—工夫すればSonnetでもいけるかもしれません

0
Posted at

こんにちは、ダックスフントです。

以前、ステータスライン設定に関する記事（ Claude Codeのステータスラインを設定して、使用中のモデルやブランチ、利用料金をいつでもすぐに見れるようにした）を投稿したのですが、Claude Codeにステータスラインを設定してから、エージェントとのやり取りにどれくらい料金が発生しているかを日常的に意識するようになりました。ちょうどアプリの設計書やソースコードの量が増えてきた時期で、Sonnet（性能と精度がコスパ良いモデル）への1回あたりの作業依頼に10$掛かるケースも増えてきました。また、Opus（高性能で高価なモデル）をつい選んでしまう癖もあり、「これでOpusを常用していたら一体いくらかかっていたんだろう」と不安になることが多々ありました。

Anthropicの公式ドキュメントを読むと、Opusは長時間の実行タスクや難易度の高いタスク向けだと書かれています。振り返ってみると、自分がお願いしている「調べもの」や「実装計画を立てて完了させる」くらいの作業は、そこまでの難易度を要求しているのか怪しい気がしてきました。

この記事では、公式ドキュメントや実測データが提示している「Opusが本当に必要な場面」「Sonnetのポテンシャル」を紹介しつつ、Opusの中毒から抜けるための解決策（OpusとSonnetを効率よく使い分ける方法や、Opusを使わずにSonnetでも頑張る方法など）を紹介します。

Claudeで普段からOpusを結構な頻度で使用していて、利用料金の増加に困っている方や、これからSonnetも試してみようかなと考えている方の参考になればうれしいです。

TL;DR

  • まず、公式がOpus向けとして挙げる基準（数時間規模の自律コーディング、大規模リファクタリングなど）と自分のタスクのスケールを比べる。日常的な調べものや実装とはそもそもスケールが違うことが多い
  • Opusが必要、あるいは部分的に必要だと判断した場合は、effortを下げる・advisor・opusplan・サブエージェントのmodel指定など、「Opusだけ使う、Sonnetだけ使う」の二択をやめる仕組みを使う
  • Sonnetを使用している場合は、まずeffortを上げてみて、それでもだめならOpusに切り替える
  • 手軽な調整で足りなければ、CLAUDE.mdとauto memoryを育てながらclaude doctorで肥大化をチェックし、それでも足りなければ仕様駆動開発や暗黙知の洗い出しでコンテキストの設計そのものを作り込む

目次

  1. 高性能モデル（Falbe, Opus）に中毒になったきっかけ
  2. Opusをなるべく止めてSonnet主体に切り替えようとしたきっかけ
  3. 公式が推奨する「Opusが必要な場面」とは
  4. ベンチマークで見るモデルやeffortのポテンシャル
  5. 解決策①：必要な場面だけOpusを使いたい方へ
  6. 解決策②：手軽にSonnetの精度を上げたい場合
  7. 解決策③：コンテキスト設計で本格的にSonnetの精度を高めたい場合
  8. まとめ

1. 高性能モデル（Falbe, Opus）に中毒になったきっかけ

自分はもともとモデルに拘りがなく、Sonnetを使い続けていました。そんな中、Opusを超える最高性能モデルであるFableが発表され、期間限定の割引価格で使えるとあって、多くの人がFableの精度に熱狂していました。その流れに乗って何気なく使ってみたところ、Sonnetよりも意図に近い、大量のアウトプットが得られた気がして、ちょこちょこ使うようになりました。ここで芽生えたのが、「Sonnetで上手くいかないときは、高性能モデルに切り替えるだけでタスクが成功するかもしれない」という感覚です。今思うと、この辺りから高性能モデルへの中毒が始まっていたのだと思います。

Fableの割引キャンペーンが終了すると、価格の安いOpusの方にも注目が集まり、周りでも「Opusは良い」という口コミを聞くようになって、自分もOpusを使い始めました。Sonnetで思い通りの出力が出ないときにOpusへ切り替えるだけであっさり解決する、という経験を何度か重ねるうち、Fableで芽生えた「モデルを切り替えるだけで解決する」という感覚がさらに強化され、中途半端なモデルで指示や追加質問を繰り返すより、最初から高性能なモデルに一発で出してもらう方が楽だと感じるようになりました。

そこに追い打ちをかけたのが、アプリの規模拡大です。今取り組んでいるのはフィジカルAIを活用したアプリで、エージェントはネット上の情報とコード、実行結果のログしか見られないため、AIの学習後の精度やシミュレーション環境内での実際の挙動までは考慮できません。そのため従来の開発と同じような実装を依頼しても、シミュレーション環境で意図した通りに動かないことが多く、手戻りや副次的なバグの修正が発生しがちです。ファイルや設計書の量が増えて見るべき範囲が広がるほど、こうした「なかなか前に進まない」もやもやが積もり、「Opusのような高性能モデルなら、様々な条件を一気に考慮して解消してくれるかもしれない」という期待も膨らんでいきました。

2. Opusをなるべく止めてSonnet主体に切り替えようとしたきっかけ

そんな中、Claude Codeにステータスライン（選択中のモデルや料金などの任意の情報を常に表示しておける仕組み）を設定したことで、料金を常に意識するようになりました。表示された数字を見ると、Opusで簡単な調べものを1回実行するだけで10ドル、まれに30〜40ドルかかることもあり、単純に「高い」と感じる場面が増えていきました。利用料金を一切気にせず最高性能を常用できるならOpusのままでもよいですが、現実には使った分だけ費用が請求されます。このことから、Opusはほどほどにして、Sonnetを主体に使うよう心掛けようと思うようになりました。

Sonnetに切り替えても、作業を依頼すると5〜10ドル程度かかる場合はあります。それでもタスク自体は問題なく完了するケースがほとんどで、「Sonnetでも使い方次第では十分なのでは？本当にOpusが必要なケースって結局何だったんだろう？」と気になり始めました。

3. 公式が推奨する「Opusが必要な場面」とは

Anthropic公式が公開しているモデル選択の基準に関するドキュメント「Choosing the right model」が示す用途基準と、モデルそれぞれの価格を表にまとめました。

モデル 必要な性能 代表的なユースケース 入力 $/M tokens 出力 $/M tokens
Claude Fable 5.1 最高水準の性能 数時間に及ぶエージェントセッション、複数ステップの徹底的な調査、完成文書・スプレッドシート・デッキまで仕上げる分析 10.00 50.00
Claude Opus 5 複雑なエージェント型コーディングとエンタープライズ業務 数時間にわたる自律コーディングエージェント、大規模なリファクタリング、複雑なシステムエンジニアリング、ビジョンを多用するワークフロー、コンピュータ操作 5.00 25.00
Claude Sonnet 5 日常的なコーディング・エージェント・エンタープライズ業務における速度と性能のバランス コード生成、データ分析、コンテンツ作成、視覚理解、エージェント的なツール利用 2.00 10.00
Claude Haiku 4.5 最も低いレイテンシと価格、かつ拡張思考も使える リアルタイムアプリケーション、大量の高度な処理、強い推論力が必要なコスト重視のデプロイ、サブエージェントのタスク 1.00 5.00

用途基準の面から見ると、Opus 5が想定する場面は4モデルの中でも特に「複雑なエージェント型コーディングとエンタープライズ業務」に絞られており、Sonnet 5は日常的なコーディング・エージェント業務における速度と性能のバランスを取るモデル、Fable 5.1は数時間に及ぶエージェントセッションや徹底的な調査など「最高水準の性能」が必要な場面向けと位置づけられています。

次に料金を比較すると、Opus 5はSonnet 5のちょうど2.5倍（入力・出力とも）、Fable 5.1はSonnetの5倍の価格です。ただ、価格の差がそのままタスク全体のコスト差になるわけではなく、より高性能なモデルは少ないターン数・少ない探索・少ない後戻りでタスクを終えることが多く、トークン単価の高さがその作業量の少なさで相殺されるケースがあります。このため、Anthropic公式やその他の団体において、コストを比較検証する時は、単純な価格の差ではなく「タスクを完了させるまでのコスト」で比較することがほとんどです。

また、Anthropic公式では、モデルの性能が要件に届かない場合の対処順序として、まずはeffortをxhighやmaxに引き上げて、それでも上手くいかなかった場合は、一段階上の高性能モデルに切り替える順序を推奨しています。そのため、SonnetでうまくいかないときにいきなりOpusへ切り替えるのではなく、まずSonnetのeffortを上げてみて、それでも及ばない場合にOpusへ切り替える、という順序で試すのが良いと考えられます。

ここまでのAnthropicの公式情報を元に、自分のタスクを振り返ってみると、公式が例に挙げる「Opus向け」の作業規模は、数時間規模の自律コーディングや大規模リファクタリングであり、それに対して自分が依頼しているものは「調べもの（10分くらいで終わる）」や「実装計画を1個立てて完了させる（30分くらいで終わる）」くらいの作業で、明らかにスケールが違います。「Opusは難易度が高いタスク向け」という理解自体は間違っていませんでしたが、公式が言う「難易度が高い」は思っていたよりずっと大規模な作業を指しているようです。こう見ると、Sonnetとそのeffort設定だけで十分なのではないかと予想されます。

4. ベンチマークで見るモデルやeffortのポテンシャル

公式ドキュメント「Optimizing for cost and intelligence」では、いくつかのベンチマークで、モデルやeffortを切り替えた場合の「タスク完了精度」と「タスクを完了させるまでのコスト」を比較検証しています。

まず、知識労働・検索系のベンチマーク（WideSearch、DeepWideSearch、BrowseComp、GDPval）の検証結果では、OpusやFableのような高性能モデルでeffortをデフォルトからmediumやlowに下げても、タスク完了精度はほぼ変わらないまま、約10%～50%とまちまちですがコストだけ下げられることが示されています。

また、保険金査定タスクの検証結果について、10件の査定タスクをOpus・Sonnetそれぞれ3段階のeffortで解かせた結果は次のとおりです。Sonnet・mediumはOpus・highと同じ10/10正解を保ったまま、コストは約1/3に収まっています。

モデル・effort 正解数 1タスクあたりのコスト
Opus・high 10/10 $0.1498〜0.1512
Opus・medium 10/10 $0.1367〜0.1370
Opus・low 10/10 $0.1205〜0.1206
Sonnet・high 10/10 $0.0526〜0.0548
Sonnet・medium 10/10 $0.0494〜0.0500
Sonnet・low 8〜9/10 $0.0484〜0.0519

この2つの検証結果から、まず、Opus・Fableのような高性能モデルを使う場合でもeffortをmediumやlowに下げれば、精度をほぼ落とさずコストを抑えられる可能性があることが分かります。また、モデル自体をSonnetに下げてeffortを調整すれば、Opus・highと同等の精度をより低いコストで再現できることが分かります。

5. 解決策①：必要な場面だけOpusを使いたい方へ

Opusの常用は控えたいが、やはり必要な場面ではOpusを使いたいという方向けに、次の4つのテクニックを紹介します。

No テクニック 概要
1 effortを下げる Opusを使う場面でも、デフォルトのhighからmedium/lowに下げることで、精度をほぼ落とさずコストを削減できる可能性がある
2 /advisorコマンドを活用 タスク中の重要な局面で、Opusのような強力な2番目のモデルに相談する
3 /model opusplanコマンドを活用 プランモード中だけOpusが担当し、実装などの他の作業はSonnetが担当する
4 サブエージェントのmodel指定 サブエージェントごとに指定したモデルが作業を担当する

1つ目はeffortを下げることです。先ほど紹介した知識労働・検索系のベンチマーク検証では、OpusやFableのような高性能モデルでもeffortをhighからmediumやlowに下げれば、精度をほとんど落とさずコストだけ下げられることが示されていました。このことから、Opusを使うこと自体は変えなくても、デフォルトのhighのまま固定せず一度effortを下げてみる価値があります。しかもこのeffort調整は、これから紹介するadvisor・opusplan・サブエージェントのどのテクニックにも組み合わせて活用できます。たとえばopusplanでプランモード中にOpusを使う場合でも、そのeffortをmediumに下げてコストをさらに抑える、といった使い方ができます。

2つ目はadvisor機能です。これは、Claude Codeで標準で提供している機能で、方針を決める前や、繰り返すエラーで詰まったとき、タスク完了を宣言する前といった重要な局面で、Claudeがもう一つの（通常はより強力な）モデルに相談できる仕組みです。有効化したい場合は/advisor opusのように対話中にコマンドを打つだけです。また、設定ファイルのadvisorModelや起動時の--advisorフラグでも指定できます。どの局面で相談するかはClaude自身が判断しますが、プロンプトで相談の頻度を促すこともできます。課金は相談が実際に発生した分だけなので、Sonnetをメインに使用して、Opusをadvisorとして使用する構成であれば、「Sonnetが日常的な作業を処理し、計画・曖昧な失敗・完了判定だけOpusにエスカレーションする」という動きになります。advisorの有効・無効を切り替えてもメインモデルのプロンプトキャッシュは壊れないという、細かな配慮もされています。

3つ目はopusplanという設定です。これもClaude Codeが標準で提供している機能で、プランモード中だけOpusを使い、実行フェーズになったらSonnetに切り替えるという構成です。「計画は高性能モデル、実作業は日常モデル」という発想を標準機能として持っています。/modelコマンドで実際に切り替える際の画面は次のようになります。

opus_plan_modeへの切り替え.png

一覧に「Opus Plan Mode」という項目があり、選択すると「Use Opus in plan mode, Sonnet otherwise（プランモードではOpusを、それ以外の場面ではSonnetを使う）」という説明が表示されます。もし選択肢に「Opus Plan Mode」が表示されていなければ、一度/model opusplanコマンドを実行すると切り替えられ、以降も選択肢に表示されるようになると思います。

4つ目は、サブエージェントの設定ファイルの中のmodelフィールドを使ったorchestrator戦略です。メインの会話は高性能モデルのままにしつつ、.claude/agents/の設定ファイルにおいてmodel: sonnetのように指定すれば、実際の調査や実装作業だけを安価なモデルのサブエージェントに任せられます。CLAUDE_CODE_SUBAGENT_MODELとCLAUDE_CODE_SUBAGENT_MODEL_FORCEという環境変数を使えば、すべてのサブエージェントを一括で1つのモデルに固定することもできます。

ただし、サブエージェントへの委任がいつも有効というわけではありません。公式は「委任が効くのは、独立した作業がたくさんあり、できれば1コンテキストウィンドウに収まらないほど多い場合」に限ると明記しています。作業が1本の依存関係のある直列タスクだったり、単一のコンテキストに収まる場合は、委任は「計画・引き渡し・統合」という余分なコストを払うだけになりがちです。自分がお願いしている「1回の調べもの」や「実装計画を1個立てる」ような作業は、独立した作業が並列にたくさんあるわけではなく、1本の直列に近いタスクです。つまり、このスケールの作業ではサブエージェントへの委任はむしろ効きにくい可能性があるので、advisorやopusplanの方が相性が良いと考えられます。

6. 解決策②：手軽にSonnetの精度を上げたい場合

Opusから脱却してSonnetを使用していく場合、簡易的にSonnetの精度を上げるための手軽なテクニックを紹介します。

No テクニック 概要
1 effortを上げる Anthropic公式は、モデルを切り替えるより先にeffortを調整することを推奨
2 memory機能とCLAUDE.mdを育てる CLAUDE.mdやauto memoryで伝えたいことを渡しつつ、/doctorで肥大化を定期的にチェックする

1つ目はeffortを上げることです。Anthropic公式も、モデルを切り替えるより先にeffortを調整することを推奨しており、Sonnet 5には最も粘り強いxhighという選択肢も用意されています。Opusへ切り替える前に、まず同じSonnetのままeffortをxhighまで上げてみる価値は十分にあります。さらに、4章で見た保険金査定タスクのように、知識労働・検索系のタスクではeffortをmediumやlowまで下げても精度が落ちないケースもあるので、Sonnetを使っていてさらにコストを抑えたい場合は、反対にeffortを下げてみるのも良いと考えられます。

2つ目は、memory機能とCLAUDE.mdを育てていくことです。CLAUDE.mdは自分で書く永続的な指示、auto memoryはClaudeが訂正や好みから自動的に学習して書き残す仕組みで、どちらも会話のたびに読み込まれます。この仕組みはモデルの種類に関わらず同じように動くため、「毎回説明しなくても伝わってほしいことを渡しておく」という工夫は、次の章で紹介するOpenSpecやgrill-meのような大掛かりな仕組みを使わなくても、まずCLAUDE.mdを整えるだけでも一歩進められます。ただし、CLAUDE.mdやスキルは育てるほど肥大化しやすく、情報が増えすぎるとむしろ精度を下げかねません。書き足すだけで終わらせず、/doctorコマンドで肥大化を定期的にチェックする運用まで含めて「育てる」と捉えるのがよさそうです。

7. 解決策③：コンテキスト設計で本格的にSonnetの精度を高めたい場合

前章よりもう一歩踏み込んで、モデルに渡す情報そのものを事前に作り込んでおく考え方もあります。実装計画を仕様としてまとめておくことと、自分の頭の中にある暗黙知を洗い出して渡しておくことは、どちらも「モデルを大きくする」のではなく「モデルの周りの設計を変える」ことで、Sonnetの精度を引き出すアプローチになります。

No テクニック 概要
1 仕様駆動開発で実装計画を立てる エージェントが迷わず実装できる形に、あらかじめ仕様を落とし込んでおく考え方。OSSのスキルとして、OpenSpec、Spec Kit、Kiroが存在
2 暗黙知を洗い出してエージェントに渡す 作業者の頭の中にある暗黙知を徹底的に洗い出し、仕組みとしてエージェントに渡す考え方。OSSのスキルとして、grill-me、Superpowersが存在

1つ目は、エージェントが実装しやすい実装計画を立てる「仕様駆動開発」という考え方です。OSSのスキルがいくつか存在しますが、今回はOpenSpecを例に紹介します。Fission-AIが開発しているMITライセンスのツールで、コードを書く前に「何を作るか」を軽量なスペックとして合意しておく仕組みです。1つの実装計画に対して、改修の目的（proposal）・要求仕様（specs）・設計方針（design）・タスク一覧（tasks）という複数の観点をそれぞれファイルとして作成するため、エージェントは実装中に判断がブレにくくなり、人間もレビューのときに見るべき観点がはっきりします。実装計画を頭の中だけに留めず、複数の視点から言語化して人間とエージェントですり合わせるイメージです。

2つ目は、作業者の暗黙知を徹底的に洗い出し、それをエージェントに渡す仕組みです。OSSのスキルがいくつか存在しますが、今回はgrill-meを例として紹介します。計画やデザインについて、共通理解に達するまで容赦なく質問を重ね、意思決定の分岐を一つずつ潰していくスキルです。かなり深いところまで聞かれるようで、何度も繰り返すと人間側が疲れてしまうという声も見かけます。ただ、人間の頭の中にある暗黙知を質問というプロセスを通じて洗い出せる分、Planモードだけで済ませるよりも一段深い計画に落とし込める可能性があります。

余談として、こうした「モデルの周りの設計を変える」という発想は学術的にも裏付けがあります。カーネギーメロン大学の論文（arXiv:2607.08938）は、7種類の業務系エージェントタスクで、タスクに合わせて調整したハーネス（指示・ツール・オーケストレーションループ）を組み合わせると、小型モデルがコストを90%削減しながら大型モデルに近い性能を出せることを示しました。21のタスク×モデルの組み合わせのうち16組で改善が見られ、最良のケースでは大型モデル性能の89.7%をコストの4%で再現したそうです。また、テストという明確な合格基準をエージェントに渡す「テスト駆動でのエージェント開発」という手法（arXiv:2603.17973）でも、軽量なオープンウェイトモデルでの検証で回帰の発生率が6.08%から1.82%に下がったと報告されています。Claude Sonnet・Opusでの実測ではないため直接の比較はできませんが、「安いモデルでも、明確な合格基準を渡せば自己修正できる」という考え方自体は参考になります。

8. まとめ

まとめとして、ここまでの内容を実際に判断するときの流れとして整理します。

  1. まず、公式がOpus向けとして挙げる基準（数時間規模の自律コーディング、大規模リファクタリングなど）と、自分のタスクのスケールを比べる
  2. Opusが必要、あるいは部分的に必要だと判断した場合は、5章「解決策①：必要な場面だけOpusを使いたい方へ」のテクニックを検討する
    • effortを下げる、advisor機能でOpusに相談する、opusplanで計画時だけOpusを使う、サブエージェントにOpusを指定する、のいずれかを組み合わせる（サブエージェントへの委任は、独立した作業が並列に多数あるときだけ効く点に注意）
    • あるいは、Opusに切り替える前にSonnetのeffortを上げるだけで対応できないかを先に確かめる
  3. Sonnetで十分そうだと判断した場合、まず手軽に精度を上げたいなら、6章「解決策②：手軽にSonnetの精度を上げたい場合」のテクニックを活用する
    • effortを上げる、CLAUDE.mdとauto memoryを育てながら/doctorコマンドで肥大化をチェックする
  4. それでも足りない、あるいは本格的にSonnetの精度を高めたい場合は、7章「解決策③：コンテキスト設計で本格的にSonnetの精度を高めたい場合」のテクニックを活用する
    • 実装計画を仕様として渡す「仕様駆動開発」や、暗黙知を洗い出してエージェントに渡す仕組みで、コンテキストの設計そのものを作り込む

「なんとなく高性能だから」でOpusを選ぶ前に、たまにはSonnetも使ってみるのをおすすめします。
そのままでも思った以上に綺麗に動いたり、ちょっとした工夫を挟むだけで、SonnetでもOpus並みに十分にこなせるポテンシャルがあるかもしれません。

参考文献

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?