Anthropicは、Opus 5.5のリリースから6日後の9月28日にClaude Sonnet 5.5をリリースしました。入力トークン100万あたり2ドル、出力トークン100万あたり10ドルという価格設定は、Opus 5.5の4ドル／20ドルと比べて半額です。さらに発表ページを見ると、多くの項目でOpus 5.5と数ポイント差に迫っており、Anthropicが独自に実施したベンチマーク「Terminal-Bench 4.0」ではOpusを上回っています。複数のコーディングエージェントを運用しているチームなら、すべてのAgentをSonnetに切り替えてコスト差額を丸ごと浮かせたくなるのも当然でしょう。
しかし、同じページに掲載されている思考量（effort）別のグラフを見ると、そう単純ではないことが分かります。Terminal-Benchの華々しいスコアは、Sonnetのeffortを最大（top effort）に設定したときのものであり、1試行あたり12.54ドルもかかっています。日常的に常時稼働させるような現実的な設定で比較すると、順位は逆転します。Opus 5.5（medium）は2.94ドルでスコア57.6%を記録するのに対し、Sonnet 5.5（high）は1.94ドルで43.0%にとどまります。SonnetがOpusのmediumを超えるのはxhighに設定したときだけであり、その際のスコアは61.5%、コストは5.30ドルに跳ね上がります。
TL;DR
明確にスコープが定まったタスクは、デフォルトでSonnet 5.5（medium）に割り当てましょう。作業が長期に及ぶもの、曖昧なもの、あるいは複数のモジュールを横断するタスクについては、Sonnetのeffortをxhighに引き上げるのではなく、Opus 5.5に任せるべきです。Anthropicが公開した3つのコーディングベンチマークすべてにおいて、Opus（high）はSonnet（xhigh）とほぼ同等かそれ以下のコストで、より高いスコアを出しています。この方針は担当者の頭の中の好みに留めず、Agentのルールとして明文化してください。モデルとeffortの階層ごとに1つのAgentを用意し、エスカレーション条件と「完了の定義」を明確に定めます。なお、Sharkly自体がモデルやeffortを選択するわけではありません。どのAgentがそのTaskで何を実行したかを記録・管理するのがSharklyの役割です。
発表時のベンチマーク数値が示していること
発表ページに掲載された表を、各セルのeffortレベルと測定者とともに整理したものが以下です。
| ベンチマーク | 測定元 | Sonnet 5.5 | Opus 5.5 |
|---|---|---|---|
| Terminal-Bench 4.0 | Anthropic | 70.6% (max) | 66.4% (xhigh) |
| FrontierCode 1.1 | Cognition | 52.1% (xhigh), 46.2% (max) | 54.4% (max) |
| CursorBench 4.0 | Cursor | 55.5% (max) | 57.8% (max) |
| SWE-Bench Pro | Anthropicシステムカード (max effort) | 81.3 | 89.9 |
| HLE, with tools | Anthropic | 64.5% | 67.7% |
| OSWorld 2.1 | Anthropic | 80.1% | 81.8% |
Terminal-Benchの行には2つの注意点があります。まずシステムカードによると、フラグ付きリクエストの影響を受けた試行はSonnetがわずか1.5%だったのに対し、Opus 5.5は10%に達していました。また、Artificial Analysisが独自に実施した測定では、Sonnet 5.5のスコアは70.6%ではなく63.6%でした。一方、SWE-Bench ProではOpusが8.6ポイント差をつけてリードしています。Anthropic自身の位置付けもこれと一致しています。Sonnet 5.5はスコープが明確な日常のタスクやバグ修正向けであり、Opus 5.5は「複雑でオープンエンドな作業において依然として明確な優位性を保っている」と説明されています。
また、見出しに並ぶ派手な数値は、実運用でのルーティングルール策定に必要な情報を隠してしまっています。実際に現場で指定する現実的なeffort設定において、3つのコーディングベンチマークがどのようなスコアとタスクあたりコストを示しているかを見る必要があります。
| ベンチマーク | Sonnet 5.5 medium | Sonnet 5.5 high | Sonnet 5.5 xhigh | Opus 5.5 medium | Opus 5.5 high |
|---|---|---|---|---|---|
| Terminal-Bench 4.0 | 28.8%, $0.83 | 43.0%, $1.94 | 61.5%, $5.30 | 57.6%, $2.94 | 64.2%, $3.88 |
| CursorBench 4.0 | 39.2%, $0.70 | 47.8%, $1.67 | 53.1%, $3.88 | 52.5%, $2.91 | 56.0%, $3.97 |
| FrontierCode 1.1 | 36.5%, $0.24 | 49.4%, $0.42 | 52.1%, $1.59 | 54.6%, $0.80 | 54.0%, $1.09 |
Sonnet 5.5はmediumとhighの設定では最も安価に試行できますが、スコアも最も低くなります。しかしhighを超えるとコストと性能の逆転現象が起きます。3つのベンチマークすべてにおいて、Sonnet（xhigh）はOpus（medium）よりもコストが高く、ほぼ同等かそれ以下のコストで済むOpus（high）に対してスコアで完敗しています。安価なモデルを高価なモデルのように振る舞わせようとした瞬間、安さのメリットは消え去るのです。なお、CursorBenchにおけるSonnetのコストはAnthropicによる試算値であり、これらのベンチマークタスクも読者のリポジトリそのものではありません。そのため、この分岐点は検証すべき仮説として捉えてください。
ルーティングルールの明文化
過去の記事では、モデルとAgentの役割のマッチング、タスクの性質に応じた担当エージェントの選定、そしてモデル階層のルール化について取り上げてきました。Sonnet 5.5の登場により、ここにもうひとつの軸が加わります。Terminal-Benchにおいて、同一モデルであってもmediumとmaxでは1試行あたりのコストに約15倍もの開き（0.83ドル対12.54ドル）があります。つまり、「このタスクはSonnetに任せる」という指示は、effortレベルまで指定しなければルールとして成り立ちません。
| タスクの性質 | Agent（ランタイムモデル） | Effort | 選定理由 |
|---|---|---|---|
| 再現手順とテストが明示されたバグ修正 | Sonnet 5.5 | medium | 仕様が明確なタスクでの自律コーディングにはmediumが推奨される（Anthropicのプロンプトガイドより） |
| テストの雛形作成、ドキュメント、変更履歴、依存関係の更新 | Sonnet 5.5 | medium | スコープが狭く検証が容易。3つのベンチマークすべてで1タスクあたり1ドル未満で済む |
| 単一モジュール内で完結し、受入条件が明確な機能実装 | Sonnet 5.5 | high | すべてのベンチマークでOpus（medium）より安価。Sonnetの実用的な能力を最大限活かせる上限設定 |
| 夜間に大量処理するトリアージ作業 | Sonnet 5.5 | low（＋検証ステップ） | 1実行あたりのコストが最安。ただしlowではテストを実行せずに完了報告する可能性があるため検証が必須 |
| 大規模または曖昧なリファクタリング、移行、横断的な変更 | Opus 5.5 | medium または high | high設定なら、ほぼ同等かそれ以下のコストで、3つのベンチマークすべてでSonnet（xhigh）を上回る |
| プランニング：曖昧な要望を具体的なTaskに落とし込む | Opus 5.5 | high | 複雑でオープンエンドなタスクこそ、Anthropicが主張するようにOpusが真価を発揮する領域 |
| 他のAgentの成果物のレビュー | Opus 5.5（のちに人間が確認） | high | 別のモデルが客観的な証拠を検証し、最終的に人間が結果を承認するフローを組む |
エスカレーション（上位モデルへの引き継ぎ）の境界線こそ、ルールの真価が問われる部分です。SonnetのAgentが行き詰まったとき、反射的にeffortを引き上げたくなるかもしれません。しかしグラフが示しているのは「モデルそのものを変えるべき」という事実です。Sonnet（xhigh）を必要とするようなTaskは、データを見る限りOpus（high）に任せるべきTaskなのです。実際の条件はチームに合わせて設定すべきですが、以下に代表的な基準の例を挙げます。
- 同じ検証チェックに2回連続で失敗した場合：人間がログを添えてTaskをOpusのAgentに再割り当てする（上位設定で勝手に自動リトライさせない）。
- 変更対象ファイル数が作業者に許容された上限（例：8ファイル）を超える場合、またはTaskに明記されていないパスに手を加える必要がある場合。
- AgentがTaskの文言解釈ではなく、設計上の判断を求めてきた場合。
- あるカテゴリーのTaskが、Sonnetのhighを超える設定でしかパスしない場合：次のスプリントからそのカテゴリー全体をOpusのAgentに移行する。
この考え方は逆方向にも機能します。Opusに割り当てたものの、常に1回の試行・小さなdiffで完了しているようなTaskは、ひとつ下の階層のAgentへ格下げすべきです。
各モデルがレビュー待ちキューに与える影響
モデル名とeffortだけを指定したルールは、まだ半分にすぎません。もう半分は「何をもって完了とするか（Doneの定義）」です。階層ごとにレビュアーの手元に届く成果物の性質は大きく異なり、両モデルが登場する前からレビュー作業はすでにボトルネックになっていました。実行コストが下がっても増えるのはコードの差分（diff）だけであり、レビュアーの時間が増えるわけではないからです。
AnthropicによるSonnet 5.5向けプロンプトエンジニアリングガイドには、レビュアーが直面することになる挙動が率直に記載されています。
- lowやmediumでは、長時間の自律タスクの途中で早々に確認を求めてくる：カンバンボード上では、午前2時に人間の返信待ちで止まっているTaskが生まれます。あるHacker Newsの投稿者は、独自ベンチマークでSonnet 5が17.8%だったスコアがSonnet 5.5で7.4%に落ち込んだ原因として、まさにこの挙動を挙げていました。
- lowでは検証ステップをスキップすることがある：テストを実行しないまま、コードが完成したと報告してしまうケースがあります。トリアージAgentの「完了」報告は、チェックの実行ログが伴っていなければ信用できません。
- どのeffortレベルでも、指示されていないテストやドキュメント、小さなファイルを勝手に追加する：ありがたい場合もありますが、いずれにしてもレビューすべき差分が無駄に膨らむことになります。
- xhighやmaxでは、レビューのラウンドを勝手に増やしたり、レビュー用のサブエージェントを立ち上げたりする：発表ページによれば、FrontierCodeにおいてSonnet 5.5のスコアがxhighよりもmaxで低下した理由はここにあります。Claude Codeのコードレビュー機能が頻繁に呼び出されて多数のサブエージェントに分岐し、Cognitionが調査した2つのケースでは、タイムアウトやスコープ外の編集が発生していました。予期しないスコープ外の変更は、レビュアーが1行ずつ探知しなければならないため、最も手戻りコストが高くなります。
一方、Opus 5.5がレビューキューにかける負荷の質は異なります。Anthropicによると、Opusは最大128kトークンの出力を生成しながら18時間以上タスクに取り組み続けることができます。したがってOpusの課題はノイズではなく「生成量の膨大さ」にあり、レビュアーが必要とする引き継ぎパケットの重要性はOpusにもそのまま当てはまります。
そのため、完了の定義（Definition of Done）は作業を担当するAgentの指示プロンプト内に明記しておく必要があります。Sharklyではすべての実行時にこの指示が組み込まれます。
Agent: sonnet-worker (Claude Code, claude-sonnet-5-5, effort medium)
Done means:
- The checks named in the Task ran. Paste each command and its exit
code. "Tests pass" without output is not done.
- Changes stay inside the paths the Task names. List every file you
created that the Task did not ask for, and why.
- New tests are welcome. New docs files only if the Task asks.
Keep working on long Tasks. Ask only when two readings of the Task
would produce different code; otherwise proceed and record the
assumption in your report.
Stop and return to the Task, without retrying, when a check has failed
twice, the change needs more than 8 files, or the question is about
design rather than the Task's wording.
Sharklyで両方の階層を運用する
Sharkly自体はモデルの選定やeffortの設定を行いません。Agentsのドキュメントにも明記されています。「AgentはRuntimeのデフォルトモデルに従います。特定のモデル名を保証または表示することはありません。モデルの変更はAgent上ではなく、RuntimeまたはComputerツールの設定で行ってください。」また、Agent側に思考深度を調整するコントロールも存在しません。階層（tier）とはComputer上で設定されたClaude Codeの構成そのものであり、Agentはその環境にチームが作業を割り当てるためのインターフェースです。
したがって、階層ごとに1つのAgentを用意します。sonnet-workerはClaude Codeがclaude-sonnet-5-5に設定されたComputer上で動作し、opus-leadはclaude-opus-5-5に設定された環境で動作します。Computerはコンテナ環境として構成できるため、階層を分けるために物理マシンを何台も用意する必要はありません。なお、Claude Codeのモデル設定ドキュメントに記載されている以下の3つのポイントは、各階層が意図通りに構成されているかどうかの重要な分かれ目となります。
- 完全なIDを指定して固定（pin）すること。
sonnetというエイリアスがSonnet 5.5を指すのはAnthropic APIのみであり、BedrockやGoogle Cloudでは依然としてSonnet 4.5に解決されます。また、Sonnet 5.5を利用するにはClaude Code v2.1.284以降が必要です。 - Pro、Max、Team、Enterprise、およびAPIプランにおいて、Claude Codeの
defaultモデルはOpus 5.5です。つまり、何も明示的に構成していないComputerは、最初からOpus階層として動作しています。 - Claude CodeにおけるSonnet 5.5のデフォルトeffortはmediumであり、これは前述のワーカー階層の設定と一致します。これを変更する場合はAgentではなくComputer側で設定します。
SharklyはRuntimeがどのモデルを使用しているかを外部から確実に判別することはできません。そのため、Agentの名前に階層を含め、名前の変更と設定の変更をセットで行うようにしてください。具体的な手順はSonnet 5.5セットアップガイドに記載されています。
1つのTaskで両方の階層を連携させる必要がある場合は、Crewを活用します。Crewとは、1つのリーダーAgentによって統括される、人間とAgentの再利用可能なチーム編成です。opus-leadをリーダー、複数のSonnetワーカーをメンバーとして設定すると、リーダーがTaskを読み解き、自ら処理するか、特定の部分をメンバーにメンションして割り当てます。メンバーは同じTask上に各自の結果を書き込みます。これはHacker Newsのユーザーたちが提案していた「Opusがオーケストレーターを務める」構成であり、作業の引き継ぎ内容を人間が確認できる形で可視化できます。小規模で明確な作業であれば、Crewを使わずにsonnet-workerを直接アサインすれば十分です。
Claude Codeのopusplanエイリアスは、これに近い動作を単一セッション内で実現します。プランニングモードではOpusが動き、実行フェーズではSonnetが動作する仕組みです。ただし、このSonnet側がSonnet 5.5として解決されるのはAnthropic API経由の場合のみであり、BedrockやGoogle Cloud、Foundryでは旧バージョンのSonnetが呼び出されます。1人の開発者がセッションの実行とレビューを一貫して行う場合はこのエイリアスで十分ですが、誰が計画を立て誰が実行したのかを他のメンバーにも明確に把握させたい場合は、2つのAgentに分ける運用が適しています。
ただし、階層間を決して移動しない要素が1つあります。それは「思考プロセス（reasoning）」です。Sonnet 5.5の思考ブロック（thinking blocks）は、そのモデル自身と現在の会話セッションに強く紐付いています。他のモデルがそれを読み取ることはできず、Sonnet 5.5もOpus 5.5の思考ブロックを読むことはできません。Crewでディレクトリを再利用しても共有されるのはファイルだけであり、前のAgentのセッション情報そのものは引き継がれません。リーダーが下した判断は、Taskの記述として明記された場合にのみワーカーに伝達されます。この点については専用の記事で詳しく解説しています。
これらの運用を行っても、作業の最終承認者が人間であることに変わりはありません。Agentは調査、実行、テスト、報告を担当します。方向性を定め、権限を付与し、成果物を承認するのは人間の役目です。また、モデルの利用料金は各ツールで設定したサブスクリプションやAPIキーを通じて発生するため、前述のコストはプロバイダーからの請求書にそのまま反映されます。次の四半期にどのモデルが主役に躍り出ようとも、アサイン履歴、実行ログ、質問内容、成果物、そして人間によるレビューの記録はすべてTask上に残り続けます。Sonnet 5.5とGPT-6 Solの比較が示しているように、このロジックはベンダーの違いを超えて普遍的に通用するものです。単一のエコシステムに縛られることなく、複数のコーディングエージェントを柔軟に使い続けたいチームのために、Sharklyは設計されています。
