Claude Opus 5.5 vs GPT-6 Sol：Crewのデフォルトランタイムの選び方

設定ファイルのたった1行が、この四半期にチームのトークンの大半がどこへ流れるかを決める。2026年9月22日、その1行の候補が同時に変わった。AnthropicはClaude Opus 5.5を、OpenAIはGPT-6 SolとGPT-6 Lunaをリリースした。複数のコーディングエージェントを並行して走らせているなら、問いはどのモデルが賢いかではない。自分のエージェントがデフォルトでどちらを使うか、そしてそれが担当者の承認待ちの行列に何をもたらすかだ。

どちらの発表記事を読む前にも知っておく価値のある、証拠側の落とし穴がひとつある。OpenAIがSolをベンチマークした相手はClaude Opus 5であり、Opus 5.5ではない。あの記事が書かれた時点でOpus 5.5は存在せず、その数時間後に、Opus 5の入力100万トークンあたり$5に対して$4でリリースされた。つまりOpenAIの記事にある「Opus 5をはるかに安いコストで上回る」という記述はすべて、同じ日に取って代わられたモデルを基準に測ったものだ。だから数字が間違っているわけではない。現行の数字ではなく、最後に公開された数字だというだけのことだ。

TL;DR

デフォルトランタイムとは、誰も別途指定しなかったときにエージェントが使うモデルであり、実際にはほとんどの実行がこれにあたる。選ぶ際の軸は3つ。完了したタスクあたりのコスト、人間の介入が必要になるまでタスクを保持できる時間、そして行き詰まったときの挙動だ。公開された数値を見る限り、完了タスクあたりのコストはSolのほうが安い。ただし公開されている比較はOpus 5に対してのものだけで、長いタスクでも止まらずに走り続けるのはOpus 5.5のほうだ。両者を共通のハーネスで比較した人は誰もいない。だからどちらの発表記事もベンダーの主張として扱い、実際の決着は自分のリポジトリでつけるべきだ。

各ベンダーが実際に公開した内容

Anthropicは、Opus 5.5はOpus 5より実行コストが40%低く、出力は約30%速く、18時間以上タスクに留まり続けると述べている。最大出力は128kトークンで、fastモードは$8 / $40と別料金だ。

OpenAIは、SolとLunaはどちらもGPT-5.6のプロモーション価格より50%安いと述べている。プロモーションという言葉はOpenAI自身が使ったもので、ここは重要だ。比較対象は割引価格であり、GPT-5.6の定価ではない。OpenAIはまた、GPT-6 Astraが「引き続きあらゆる面で当社最高のモデル」とも述べており、Solが自社ファミリーのバリューティアであってフラッグシップではないことを思い出させてくれる。

軸1：100万トークンあたりのコストではなく、完了したタスクあたりのコスト

トークン単価は、実際に支払う金額の代理指標にすぎない。単価が半分でも3回試行が必要なモデルは、1回で仕上げるモデルより高くつく。OpenAIはスコアと並べてタスクあたりのコストを公開しており、これは珍しいほど直接的だ。

多くの人が引用しているのは最初の行だ。extra-high推論でのSolは、max推論でのClaude Opus 5よりスコアが高く、タスクあたりコストはOpus 5の約9%で済む。$0.27に11.1を掛けると、そのハーネス上でのmaxのOpus 5はタスクあたり$3近くになる。これはOpenAIが示した2つの数値からこちらで計算したもので、OpenAIが印刷した数字ではない。

ここで先ほどの落とし穴を当てはめよう。AnthropicはOpus 5.5の実行コストをOpus 5より40%低いとしているので、この$3という数字はすでに古い。しかも単純に同じ40%だけ下がるわけでもない。タスクあたりのコストは、そこに至るまでにモデルがどれだけトークンを燃やすかで動くもので、定価だけで決まるものではないからだ。公開された差は大きく、その片側は同じ日に公表された分だけ動き、そして誰も比較をやり直していない。自分のコードベースでのその数値が欲しいなら、ラボが代わりに計測してくれるのを待つのではなく自分のリポジトリで比較を実行しよう。

規模感を示すと、OpenAIは自社の研究者の中央値がコーディングエージェントに1日$600以上、90パーセンタイルでは1日$7,000を費やしていると報告している。タスクあたりコストは、すぐに抽象論ではなくなる。

軸2：タスクをどれだけ保持できるか

2つのベンダーは、同じ問題に対して異なる場所で答えを出した。

Anthropicはモデル側で答えた。Opus 5.5は18時間以上タスクに留まり続ける。自分の労働時間より長く生き残る実行は、監視のしかたを変える。ずっと見張るのをやめ、あとから戻って確認するようになる。これが成り立つのは、実行が自分が閉じてしまったターミナル以外のどこかに報告してくれる場合だけだ。

OpenAIはキャッシュ側で答えた。GPT-6はキャッシュされた入力の読み取りを90%割引きし、デフォルトでヒット率を高め、エージェント作業にとって重要なことに、推論の強度や利用可能なツールのセットを変えてもキャッシュを壊さなくなった。明示的なブレークポイントを使えば、キャッシュされたプレフィックスがどこで終わるかを選べる。GitHubは、数十億件のリクエストを通じて、新たな処理を要するプロンプトトークンが50%以上減ったと報告している。長いエージェント実行は、ほとんどが同じコンテキストを何度も読むことなので、これは継続時間そのものの改善ではなく、継続時間にかかるコストの改善だ。

Opus 5.5をデフォルトにするのは、典型的なタスクがマイグレーション、大規模なリファクタリング、あるいは途中で止まることがトークン代より高くつくようなものである場合だ。Solをデフォルトにするのは、典型的なタスクが範囲の限られたもので、1日に何度も繰り返し、やり直しが安い場合だ。ほとんどのチームには両方の種類がある。だからデフォルトは、例外について意識的に決めることほど重要ではない。

軸3：行き詰まったときの挙動

この軸にはベンチマークがなく、そしてサポートへの問い合わせを生むのはまさにこれだ。

どちらのベンダーでもない第三者であるArtificial Analysisは、「max」推論のバリアントを計測し、Solが毎秒115.2出力トークンで初回トークンまで102.15秒、Lunaが毎秒153.9トークンで124.23秒だった。これらはmax努力の設定であり、当てにする前に現行のリストで確認してほしい。大事なのはその形だ。高い推論努力では、安いモデルが起動の速いモデルとは限らない。

102秒間考え込んでいるエージェントと、ハングしたエージェントは、ターミナルでは同じに見える。40分前に終わったエージェントと、誰も見ていない質問を投げて止まったエージェントも同じだ。モデルのリリースでこれが直ることはない。タスクに戻ってくるステータスなら直せる。In Progress、Waiting for human、Failed、Ready for release、それぞれにログと質問が添付されている状態だ。エージェントは調査し、実行し、テストし、報告する。人間は方向を定め、権限を与え、結果を承認する。

各ランタイムが進捗と失敗をどう伝えるかには、ベンチマーク表と同じ重みを与えよう。ステータスは週に100回読むが、ベンチマークは1回しか読まない。

2つのベンチマーク表を並べて比べてはいけない

両ベンダーが今週、AutomationBenchの数値を公開した。OpenAIはextra-high推論でのSolがAutomationBench 1.0.6で33.2%と報告。AnthropicはOpus 5.5がAutomationBenchで40.0%と報告した。両者ともOSWorld 2.0も報告しており、それぞれ60.5%と81.8%だが、OpenAIの数値はofflineセットでのものだ。

これらは直接対決ではない。推論設定が異なり、少なくとも1つはベンチマークのバリアントが異なり、ハーネスも違い、共通のタスクあたりコストの数値もなく、しかもそれぞれ自分に有利な側が実行している。Opus 5.5とGPT-6 Astraを具体的な数値で比較している記事はツイートであって、ベンダーのデータではない。Artificial Analysisは共通のインデックスを1つ公開しており、それによればOpus 5.5が58で212モデル中1位、Solが48、Lunaが37だ。これも第三者の集計値であり、自分のコードベースを測ったものではない。

次のリリースを生き残る意思決定

デフォルトは書き留めておこう。誰かが抱いている好みとしてではなく、エージェントに紐づいたルールとして。このエージェントはこのランタイムで動く、こうしたタスクはこちらに回す、そして定型的なものはこちらの安いエージェントが引き受ける、という形だ。チームが目にする場所に、こんなふうに置いておくといい。

Default Runtime: Claude Code on claude-opus-5-5
  Tasks: migrations, wide refactors, anything that fails badly halfway
Second Runtime: Codex on gpt-6-sol
  Tasks: bounded, repeated many times a day, cheap to retry
Escalation: a Sol Task that fails twice returns to the Task for a person,
  it does not silently re-run on the expensive Runtime

これがどのモデルにどのタスクを割り当てるかをスループットに変える。そして次のリリースにも耐える。答えが変わったとき、6人に何を使っているか聞いて回るのではなく、ルールを1つ編集すればいいからだ。2つのラボが同じ日に最強のバリューティアを出荷し、片方は数時間で世代交代したモデルに対してベンチマークを取った。1か所で変えられるデフォルトランタイムは、今週正しく選ぶことより価値がある。

どちらのリリースでも変わらなかったものがある。行列だ。完了タスクあたりのコストは両陣営で大きく下がったので、同じ予算で買えるエージェントの完了作業量は先週の何倍にもなった。だがレビュアーの工数は1時間も増えていない。レビュー能力こそが上限であり、値下げはその上限に向かって量を押し付けるだけで、和らげてはくれない。ゴール、実行、ブロッカー、差分、そして人間のレビューを、依頼からリリースまで1か所で見えるようにしておけば、デフォルトランタイムは賭けではなくただの設定になる。

Sharklyはモデルを実行せず、あなたの代わりに選びもしない。実際に動くツール群の周りにある、共有のタスク、コンピュータ、コンテキスト、レビューのレイヤーだ。1つのエコシステムに決め打ちするのではなく複数のコーディングエージェントを使い続けたいなら、それはまさにSharklyが想定して設計された課題だ。1台のコンピュータを接続し、各ランタイムにエージェントを1つずつ作り、同じ地味なタスクを渡してみよう。