Claude の Opus と Sonnet、コーディングエージェントではどう選ぶか：ロールごとにモデルと effort を決める
「Sonnet と Opus のどちらか」という問いは、1つの答えがチーム全体に当てはまるかのように立てられます。エージェントのチームでは、ロールごとに仕事が違うので、答えもロールごとに違います。しかも決め手は、価格よりも、仕事との相性とリスクです。ここでは、ベンダーが何と言っているか、価格が実際にどう効くか、そして私たちが何を測り、何をまだ測っていないかを書きます。
要点
- $0.20
- 100万トークンあたりのキャッシュ読み取り。Sonnet 5.5 でも Opus 5.5 でも同じで、ほかの項目は Sonnet ではすべて半額
- 10–34%
- 同じステップ数で Sonnet 5.5 に移したときの、ロールごとの節約（平均では16%）。測定ではなく計算
- 29,771件中0件
- のリクエスト（9月10〜29日、試験運用の前の私たちのプロダクトのプロジェクト）は、Sonnet 5.5 でも high の effort でも動いておらず、結果はまだありません
- −2%
- は、ロール表を適用したときの、私たちのプロダクトのプロジェクトの1週間の換算額（API 価格で $3,033）の推定変化。節約と追加コストは、ほぼ打ち消し合います
この記事の内容
ベンダーの言い分
Anthropic は 2026年9月28日に Sonnet 5.5 を公開し、「Claude Opus 5.5 を補う、より速く低コストなモデル」と説明しています。このモデルのプロンプトガイドには、「最も難しい長期の作業には、Opus モデルのほうが良い選択です」とあります。Claude Code のコストのページは、この分担を1行で述べています。「Sonnet はたいていのコーディングタスクをうまくこなし、Opus より安い。Opus は、複雑なアーキテクチャの判断や、複数ステップの推論のために取っておく」。エージェントのチームについては、「チームメイトには Sonnet を使う」とあります。
発表のベンチマークも同じ方向を指していますが、注意点があります。medium の effort での結果ではありません。
| ベンチマーク | Sonnet 5.5 | Opus 5.5 | 発表での effort |
|---|---|---|---|
| Terminal-Bench 4.0 | 70.6% | 66.4% | xhigh または max |
| FrontierCode 1.1 | 46.2% | 54.4% | max |
| CursorBench 4.0 | 55.5% | 57.8% | 記載なし |
| GDPval-AA | 1844 | 1846 | 記載なし |
素直に読めば、日常的な仕事では両者は近く、Terminal-Bench では Sonnet が先行し、最も難しいコードでは Opus が8ポイントリードしています。これは、モデルを仕事に合わせる理由にはなりますが、あなた自身のリポジトリについては、まだ何も言っていません。
価格と、動かない1つの項目
2つのモデルについて Anthropic が公開しているAPI 価格です（100万トークンあたり）。
| 項目 | Sonnet 5.5 | Opus 5.5 |
|---|---|---|
| 入力 | $2 | $4 |
| キャッシュ書き込み（5分） | $2.50 | $5 |
| キャッシュ書き込み（1時間） | $4 | $8 |
| キャッシュ読み取り | $0.20 | $0.20 |
| 出力 | $10 | $20 |
キャッシュ読み取りは、どちらのモデルでも同じ価格です。
Sonnet では、キャッシュ読み取りを除くすべてが半額です。Anthropic は、キャッシュ読み取りを Opus 5.5 では入力価格の0.05、Sonnet 5.5 では0.1としていて、どちらも $0.20 に落ち着きます。エージェントの1ステップは会話の全体を読み直すので、この同額の1項目が、ほかのすべてより大きく効きます。私たちのエージェントのトークンの行き先に、数えた1週間があります。ここで必要なのは、そこから導かれることだけです。
節約が見かけより小さい理由
2026年9月23〜29日の週（私たちのプロダクトのプロジェクト、すべて Opus 5.5、API 価格で $3,033）では、キャッシュ読み取りがロールの換算額の最大の部分でした。リードで81%、ランディングのコピーライターで76%、レビュアーで68%、仕事が短いアーキテクトで32%です。同じステップを Sonnet 5.5 で計算しました。節約は、リードの10%からアーキテクトの34%まで幅があり、週全体では16%（$3,033 のうち $495。ロールの単純平均ではなくコストで加重）でした。ステップ数は同じと仮定しています。
| ロール | キャッシュ読み取り（換算額に占める割合） | Sonnet、同じステップ数 |
|---|---|---|
| リード | 81% | −10% |
| ランディングのコピーライター | 76% | −12% |
| レビュアー | 68% | −16% |
| フロントエンド | 65% | −17% |
| 開発 | 64% | −18% |
| ドキュメント | 58% | −21% |
| アーキテクト | 32% | −34% |
ロールのコンテキストが長いほど、Sonnet で減る分は小さくなります。 リードとコピーライターは1ステップあたり約43万トークンを抱えていて、節約は10〜12%です。アーキテクトは9.2万で、週 $13 に対して34%減ります。
注意が2つあります。同じ仕事に Sonnet が約20%多くステップを必要とするなら（測定ではなく私たちの仮定）、コンテキストの長いロールの節約はなくなります。また、7本の棒は丸1週間働いたロールで、短命のロールはコストが小さすぎて、数字に影響しません。
effort が変えるのは、答えの長さだけではなく、ステップの数も
effort はモデルの設定です。Anthropic は、これが応答の「すべてのトークン」（テキスト、ツール呼び出し、思考）に影響すると説明し、「厳密なトークン予算ではなく、振る舞いの信号」だとも言っています。エージェントでは、ツール呼び出しがいちばん効きます。effort が低いと、ツール呼び出しは少なく、簡潔になります。effort が高いと、ツール呼び出しが増え、行動の前に計画の説明があり、まとめも長くなります。ツール呼び出しが増えればステップが増え、ステップのたびに会話の全体が読み直されます。
- low
最も効率的：速さと最低のコストが必要な、サブエージェントのような単純なタスク。
- medium
バランス型：速さ、コスト、性能のバランスが必要なエージェントのタスク。
Opus 5.5 の既定Claude Code の Sonnet 5.5 - high
複雑な推論、難しいコーディングの問題、エージェントのタスク。
API の Sonnet 5.5 - xhigh
30分を超える、長時間のエージェントやコーディングのタスクで、トークン予算が百万単位のもの。
- max
トークンの使用に制約なし。最も深い推論のため。
Sonnet 5.5 でのエージェント的なコーディングについて、Anthropic は、仕様のはっきりしたタスクは medium から始め、より難しい、あるいはより長いタスクでは high に上げることを勧めています。また、low ではモデルが変更の検証を省くことがあり、長いタスクの low と medium では、終える前に立ち止まって確認を入れやすくなる、とも書いています。
この週、モデル自身の答えは、思考を含めても、ロールの換算額の8〜29%にすぎず、そのうち思考は12〜29%でした。つまり effort が使用量に効くのは、答えが長くなるからではなく、主にステップが増えるからです。これはベンダーの説明と私たちの内訳からの読み取りで、high での測定は私たちにはありません。
ロールごとに：私たちの試験運用の表
ロールごとに選ぶ理由の大半は、相性とリスクです。間違いの代償が大きいところには強い設定を、範囲がはっきりした仕事には速い設定を使います。コストは二の次です。これが、2026年9月29日から harnsy 自身の会社のロールテンプレートに入っている表です（すべてのプロジェクトがこれを継承し、上書きしているものはありません）。例外が1つあり、下に示します。
試験運用の表（2026年9月29日から）
| ロール | モデル | Effort | 理由 |
|---|---|---|---|
| リード | Opus 5.5 | medium | 判断と受け入れを担う。間違いはチームに広がる。キャッシュ読み取りが換算額の81%を占めるので、Sonnet にしても10%しか減らない。 |
| 開発 | Opus 5.5 | medium | 不変条件のあるコード。Anthropic のベンチマークの差は、難しいコードで最も大きい。 |
| レビュアー | Opus 5.5 | high | コードが本番に出る前の最後のフィルター。強い設定にする価値がある。Anthropic は、難しいコーディングとエージェントのタスクに high を挙げている。 |
| 統合 | Sonnet 5.5 | medium | 手順を順に進める作業：マージ、ビルド、確認、デプロイ。Terminal-Bench では Sonnet がリードしている。 |
| フロントエンド | Sonnet 5.5 | medium | 明確なルールに沿った、範囲のはっきりした UI の作業。 |
| ドキュメント、ランディングのコピーライター、マーケター | Sonnet 5.5 | medium | ドキュメントとテキスト：範囲がはっきりした定型の仕事で、差し戻されることがまれ（ドキュメント7%、コピーライターは98件中0件）。 |
| 版の担当 | Sonnet 5.5 | high | ライセンスに入るルール。軽いモデルを、high で補う。 |
| デザイナー、UX | Opus 5.5 | medium | センスと判断。コストは小さい。 |
| 法務 | Opus 5.5 | high | 法的な文章。誤りがお金につながる。 |
| 鍵と暗号に関わるロール | Opus 5.5 | high | 推奨するが未適用で、テンプレートに行はない。この仕事は、最も差し戻される。 |
行の一部は、レビュアーがそのロールの仕事をどれだけ差し戻したかで選びました。2026年9月24日以降の、仕事を出したロール別の、レビュアーの差し戻しメッセージは次のとおりで、サンプル数も添えます。
- 鍵と暗号に関わるロール：25%（52件中13件）。サンプル数が少ない。
- 法務：25%（4件中1件）。サンプル数が非常に小さい。
- 開発：12%（271件中32件）。
- 統合：9%（86件中8件）。
- ドキュメント：7%（54件中4件）。
- デザイナー：7%（15件中1件）。サンプル数が非常に小さい。
- フロントエンド：2%（87件中2件）。
- ランディングのコピーライター：98件中0件。
差し戻しの割合が示すのは、確認で何かが見つかった頻度であって、担当ロールの出来の良さではありません。強い設定をどこに使うかのヒントとして読んでください。それ以上ではありません。
表に載せない2つのこと
稼働中のセッションの途中で、モデルを切り替えないでください。モデルごとにプロンプトキャッシュが別なので、切り替えのあとは、Claude Code のドキュメントの言葉で言えば「次のリクエストは、キャッシュにヒットせず、会話履歴の全体を読み込む」ことになります。そのため Claude Code は、キャッシュがまだ効いているうちに確認を求めます。モデルを選ぶのは、エージェントの起動時か、引き継ぎのときです。同じページには、plan モードで Opus、実行で Sonnet を使う opusplan では、plan モードを切り替えるたびにモデルの切り替えになり、そのたびに新しいキャッシュが始まる、とも書かれています。
effort のほうが、キャッシュへの影響は小さくて済みます。Opus 5.5 と Sonnet 5.5 では、Claude Code で effort を変えてもキャッシュは保たれます（API キーでも Claude のサブスクリプションでも）。API では、ベータ版のメッセージ単位の effort の変更でも保たれますが、リクエストの間で最上位の effort の値を新しくすると保たれないので、キャッシュに頼る会話の中では一定に保ってください。
Sonnet 5.5 向けの Anthropic のガイドからもう1つ、発見ではなくリスクの一覧に入れるべきことがあります。このモデルは、注入された指示に抵抗するよう訓練されていて、「ユーザーの本物のメッセージを、注入の可能性があるものとして扱うことがある」とあり、特にターンの途中でツールの結果の直後にユーザーのメッセージが来たときです。エージェントの作業中にメッセージが届くチームでは、注意しておく価値があります。私たちはこれをリスクとして挙げています。自分たちの仕事では見ていません。
他のハーネスも、同じ判断
「ロールごとに選ぶ」は、1つのベンダーで終わりません。harnsy の起動設定は、まずハーネス（Claude Code、Codex、OpenCode）から始まり、その次にモデルです。Codex についての私たち自身の数字は少なく、期間も別です。セッションファイルの全期間では、1ステップあたりの平均コンテキストは113k〜131kトークンで、上の週の全プロジェクトにわたる Claude の318kと比べて小さく、入力の96.5%がキャッシュから来ていて、Claude の99.0%と比べて低い値でした。9月の Codex は、Claude の入力トークンの約20分の1でした。これは私たちの使い方についての話で、Codex の良し悪しについてではありません。品質の比較は私たちにはないので、行いません。
測定したことと、まだ試験運用のこと
- 測定済み
9月10〜29日、試験運用の前に、私たちのプロダクトのプロジェクトは29,771リクエストを送りました。すべて Opus 5.5 の medium で、Sonnet 5.5 のものも、high のものもありません。キャッシュ読み取りの割合、ロール別の換算額、ロール別のレビュアーの差し戻し、そして価格の計算です。
- 推定
適用したロール表で、1週間は約−2%動きます。Sonnet のロールが約 $146 を節約し、high のロールが約 $81 を追加して、正味で約 −$65 です（私たちのプロダクトのプロジェクトの、API 価格で $3,033 の週）。最初に提案した表は、high と Sonnet のロールがもっと多く、−1.5% でした。high は20%高くつくと仮定しています（範囲は10〜40%）。
- まだ測っていない
Sonnet 5.5 が私たちの仕事でどう振る舞うか。high がステップ数に何をするか。週間の制限を Sonnet が Opus と比べてどれだけ使うか。Anthropic は比率を公開しておらず、Claude Code には Opus ファミリーと Sonnet ファミリーで別々の制限メッセージがあります。
表は2026年9月29日に会社のロールテンプレートに入ったばかりなので、新しく、結果はまだありません。9月23〜29日の基準の週と比べるなら、見るのはロール別の消費、Sonnet の制限が Opus の制限と比べてどれだけ使われるか、ロール別の差し戻しの割合、人の手戻り、統合ロールの失敗したデプロイと git の誤り、そして速さです。そのどれも、まだ測っていません。
harnsy が関わるところ
harnsy では、各ロールに「Launch」のセクションがあり、フィールドが3つ、この順に並びます。ハーネス、モデル、effort です。ハーネスは選択式で、空にすると継承します。モデルは候補つきの自由入力で、エイリアスは自動的に次のバージョンに移るので、完全なモデル ID をお勧めします。effort はハーネスにレベルがあるときだけ表示されます。Claude には low、medium、high、xhigh、max があり、Codex には独自の一覧があり、OpenCode にはありません。ハーネスを変えると、モデルと effort は消えます。
This project’s own launch: new agents of the role start with it; open and restore keep a seat’s harness and take the model and effort only on it.
レベルは2つあります。すべてのプロジェクトが継承する会社のテンプレートと、それを上書きするプロジェクト自身のロールです。1回の起動で指定した値は、どちらにも優先します。変更が適用されるのは新しいセッションだけ（起動、引き継ぎ、復元）で、保存しても誰も再起動されません。エージェントを開く、または復元するときは、すでに動いているハーネスを保ち、そのハーネスがロールのものである場合にだけ、ロールのモデルと effort を取り込みます。
ピッカーが、選択を安くしてくれるわけではありません。あなたが決めた選択をロールに定着させ、次の引き継ぎが選んだ設定から始まるようにするだけです。私たちの表は、最初の1週間の出発点にすぎません。あなたのロールで役に立つものを残してください。ロールごとの起動設定は、harnsy をインストールして設定できます。
出典
- Anthropic、“Introducing Claude Sonnet 5.5”（2026年9月28日）：anthropic.com。
- Claude API の価格：platform.claude.com。
- Effort: platform.claude.com.
- Prompting Claude Sonnet 5.5: platform.claude.com.
- Claude Code、モデルの設定：code.claude.com。
- Claude Code、コストの管理：code.claude.com。
- Claude Code、プロンプトキャッシュの使い方：code.claude.com。
ロールごとに、モデルと effort を決める
harnsy は、Claude Code、Codex、OpenCode のエージェントをロールを持つ1つのチームにつなぎ、各ロールはあなたが選んだハーネス、モデル、effort で起動します。
harnsy をインストール