Claude Sonnet 5.5 vs GPT-6 Sol：同価格帯の2つのランタイムを徹底比較

Anthropicは9月28日、Claude Sonnet 5.5の提供を開始しました。価格は入力トークン100万件あたり2ドル、出力トークン100万件あたり10ドルです。OpenAIも9月22日にGPT-6 Solを同じく2ドルと10ドルでリリースしています。わずか6日違いでリリースされ、定価も同じ。いずれも各社のフラグシップモデルの直下に位置するモデルです。コーディングエージェントのデフォルトモデルを選定しようとしているチームにとって、価格設定の比較だけでは何も決まりません。真の争点は、各モデルを取り巻くRuntime（実行環境）としてClaude CodeとCodexのどちらを採用するか、そしてタスク1件を完了するまでにそれぞれいくらのコストがかかるかです。

公平な比較検証を行うには、2つのRuntime、2つの設定、2つの結果セットを用意し、1人のレビュアーが「どちらのターミナルがどのdiffを出力したか」を把握し続けなければなりません。モデルを選ぶだけであれば設定を1行変えるだけで済みますが、この2つを比較するとなると、エージェント特有の混沌とした状況を小規模に再現することになります。

まとめ（TL;DR）

Claude Sonnet 5.5とGPT-6 Solのトークン単価は同等ですが、一般的に実行されるRuntimeが異なります（Sonnet 5.5にはClaude Code、SolにはCodex）。Anthropicのリリース記事にある表には、GPT-6 Solの列を含む項目が4行あります。Sonnet 5.5はそのうち3つのベンチマークで明確にリードしていますが、4つ目のFrontierCodeは推論エフォート（Effort）設定によって結果が分かれます。タスクあたりのコストはベンチマークによって優劣が逆転します。FrontierCodeでは、Sonnet 5.5はSolの最高スコアと同水準を約5分の1のコストで達成しますが、AA-BriefcaseではSolの最高設定がタスクあたり2.67ドルであるのに対し、Sonnet 5.5は29.19ドルかかります。ただし、これは一ベンダーが公開したデータにすぎません。Sonnet 5.5とGPT-6 Solのどちらを選ぶべきかの結論を出すには、自社のコードベースで同じTaskを両方のRuntimeに実行させ、承認された変更1件あたりにかかったレビュー時間を計測するのが確実です。Taskが一元管理された記録として残るのであれば、両方を併用するのも合理的な選択肢となります。

公開データから実際に比較できること

比較できるのは4行のみです。Claude Sonnet 5.5の発表記事では、Sonnet 5.5、Sonnet 5、Opus 5.5、そしてGPT-6 Solが比較されていますが、Solの数値が掲載されているのは以下の行だけです。

これは特定の一ベンダーによる比較表です。OpenAIのSolに関する発表記事はSonnet 5.5が登場する6日前に公開されたため、両モデルを並べて掲載しているベンダーの比較表は現時点でAnthropicのものしかありません。また、どちらの列の測定値にもバグに関する注意点があります。Sonnet 5.5のArtificial Analysisによる測定は、構造化出力のバグ（現在は修正済み）を抱えたリリース前環境で実施されたものであり、OpenAIも最近Solの画像認識のバグを修正していますが、Artificial AnalysisやSurge AIのスコアには反映されていない可能性があります。

コーディングチームが注目すべきはFrontierCodeの行です。これはすでにRuntimeの比較になっているからです。52.1%対49.3%という数字は、Claude Code環境のSonnet 5.5とCodex CLI環境のSolという、実際に本番運用する組み合わせ同士の比較です。また、max設定のスコアに添えられた注記も同様に重要です。FrontierCodeはタスクのスコープ外の変更に対して減点を行いますが、エフォートをmaxに設定したSonnet 5.5は、Claude Codeのコードレビュー用スキルを頻繁に実行し、多数のサブエージェントへ並列展開していました。Cognitionが調査した2つのケースでは、これが原因でタイムアウトが発生したり、タスクの範囲外の編集が行われたりしていました。推論エフォートを上げるほど差分が広がり、必要なレビューも増えることになります。

このページ上の他の項目には、Solの数値は一切記載されていません。Terminal-Bench 4.0やCursorBench 4.0のエフォート別グラフにプロットされているのはGPT-5.6 Solです。GPT-6 Solの数値が公開されていないためです。

第三者機関による集計データが1つ存在します。Artificial AnalysisのIntelligence Indexにおいて、9月29日時点でSonnet 5.5のmaxエフォートのエンドポイントは56を記録し、216モデル中3位にランクインしています。一方、当方が最後に記録した9月23日時点のSolのスコアは48でした。ただし、これらは測定日も異なり、常に変動するインデックスの数値であり、何より自社のリポジトリにおける成果を測ったものではありません。

トークン単価ではなく「完了タスクあたりのコスト」

トークンあたりの単価が同じであっても、請求額の予測にはほとんど役立ちません。タスク1件を完了するために消費されるトークン数は、モデル、推論エフォート、そしてRuntimeによって大きく左右されるからです。Anthropicのリリース記事では、両モデル共通の評価項目のうち2つについて、推論エフォートごとのスコアとタスクあたりコストが公開されています。

まずFrontierCodeに注目してください。Sonnet 5.5はhigh設定で49.4%を記録し、タスクあたりのコストは0.42ドルです。これはSolの最高スコアである49.3%（2.07ドル）と同等の性能であり、Anthropicの表現を借りれば「タスクあたりのコストが約5分の1」で済むことになります。しかし、実務上見逃せないポイントはその手前にあります。medium設定の場合、Sonnet 5.5のスコアは36.5%にとどまり、Solのlow設定のスコアすら下回っています。そして、Claude CodeにおけるSonnet 5.5のデフォルトのエフォート設定こそがmediumなのです。Anthropicのプロンプトガイドラインでは、エフォートをhighから開始することや、仕様が明確に定義されたタスクでのエージェントコーディングにはmediumを用いることが推奨されています。普段見落とされがちな設定値ひとつで、比較結果が大きく左右される可能性があるのです。

一方、ナレッジワーク系ベンチマークであるAA-Briefcaseでは正反対の結果が出ています。Solの最高設定はタスクあたり2.67ドルで済むのに対し、Sonnet 5.5の最高設定はスコアこそ上回るものの、タスクあたり29.19ドルと約11倍の費用がかかります。Solのmax設定のコストに最も近いSonnet 5.5のmedium設定（1.64ドル）では、スコアは1483に対して1461にとどまります。同じ2つのモデルであっても、どちらがコストパフォーマンスに優れているかは評価対象によって真逆になるのです。

プロンプトキャッシングを利用すると、このコスト差は縮小し、バランスも変化します。Sonnet 5.5のキャッシュ入力読み取りは100万トークンあたり0.10ドルで、5分間のキャッシュ書き込みは2.50ドルです（Anthropicの価格表）。GPT-6はキャッシュ入力読み取りが90%割引され、2ドルの通常レートに対して0.20ドルとなるため、キャッシュ読み取り単価自体はSonnet 5.5の方が半額で済みます。差が生じるのはキャッシュが無効化される条件です。OpenAIによると、推論エフォートや利用可能なツールの変更を行ってもキャッシュは無効化されなくなりました。これに対し、AnthropicのSonnet 5.5プロンプトガイドでは、リクエスト間でトップレベルのエフォートを変更するとキャッシュが無効化されると明記されており、ベータ機能であるメッセージ単位のエフォート設定の利用を促しています。タスクの途中で推論エフォートを動的に変更するエージェントでは、その影響が請求額に直結します。

ただし、これらの数値はいずれも「承認された変更1件あたりの実質コスト」を示しているわけではありません。実行コストが安くても、2回の再実行と長時間のレビューが必要になるなら、それこそが最も高くつく選択肢となります。

自社のコードベースで評価・決定する方法

同一のTaskを両方のRuntimeで実行し、人間がその成果物をレビューして承認するまでに要した時間を測定してください。評価基準の詳細は「自社のコードベースでコーディングエージェントを比較検証する方法」に記載されています。今回の2モデルにおける環境構築手順は以下のとおりです。

Sharkly自体がモデルを独自に選定することはありません。Agentsの公式ドキュメントには、「AgentはRuntimeのデフォルトモデルに従います。Agent側で特定のモデル名を保証または表示することはありません。モデルの変更はAgent上ではなく、RuntimeまたはComputerツールの設定で行ってください」と明記されています。したがって、モデルの設定はComputer側で実施します。

• claude-sonnet-5-5を実行するClaude Code：Claude Code v2.1.284以降が必要です。Pro、Max、Team、Enterprise、およびAnthropic APIにおいて、Claude CodeのdefaultモデルはOpus 5.5に設定されているため、明示的に変更しない限りComputer上ではOpusが実行されます。また、sonnetというエイリアスがSonnet 5.5を指すのはAnthropic APIのみです。完全なモデルIDを固定指定し、該当ホスト上でclaude --model claude-sonnet-5-5を実行して設定を確認してください。設定手順の詳細は「SharklyでのSonnet 5.5エージェントの実行方法」に掲載されています。
• gpt-6-solを実行するCodex：該当するComputer上のCodex設定ファイル内でモデルを指定します。具体的な手順は「SharklyでのGPT-6 Solエージェントの実行方法」を参照してください。
• 両Agent共通の一時作業ディレクトリ：各実行に独立したディレクトリを割り当てます。リポジトリ連携の実行であればクリーンなworktreeを個別に用意できるため、2つの試行でチェックアウトが共有されることはありません。

環境が整ったら、テストを実行する前に検証計画を明文化しておきます。

Task:    SH-312, one real Task, same description and starting commit for both runs
Run A:   Claude Code Agent, claude-sonnet-5-5, effort: medium (Claude Code default) or high
Run B:   Codex Agent, gpt-6-sol, effort: whatever Codex on that Computer is set to, written here
Accept:  the same acceptance test for both
Record:  accepted y/n, human review minutes, reruns, files touched outside scope,
         provider cost from your own Anthropic and OpenAI bills
Decide:  after several Tasks of each kind you actually assign, not one

Taskを一方のAgentに割り当て（Assign）、もう一方のAgentはコメント内でメンションして起動します。Sharklyでは、明示的にメンションすることで担当者（Assignee）以外のAgentを起動できます。両方の実行結果が同一のTaskに集約されるため、2つの差分、2つのテスト実行結果、発生した質疑が、別々のスクロールログに散逸することなく1つのタイムライン上で確認できます。単一のバグを対象にした評価ルーブリック付きの検証例は、「同一バグにおけるClaude CodeとCodexの公平な比較検証手法」をご覧ください。

最も重視すべき指標は「人間のレビュー時間」です。Anthropicのプロンプトガイドによると、Sonnet 5.5はあらゆるエフォートレベルでテストやドキュメント、付随ファイルを生成する傾向があり、lowやmediumでは長時間に及ぶタスクの早い段階で確認を求めてくるほか、xhighやmaxでは追加のレビューサイクルやレビュー用サブエージェントを立ち上げます。これらと同じ局面でSol上のCodexがどのような挙動を示すかは、実際の検証によって明らかになります。これらはすべてレビュー時間に跳ね返ってくる要素であり、一般的なベンチマークスコアには一切表れません。

「両方を併用する」が合理的な選択肢となる理由

公開されているベンチマーク結果を見ても、すべての人に当てはまる明確な勝者は存在しません。自社で検証を実施しても、決定的な差が出ない可能性があります。しかし、結果が分かれること自体が有益な検証結果であり、決して失敗ではありません。

レビュー時間の差がほとんど見られない場合や、小規模なチームで契約や設定の管理を一元化したい場合は、どちらか一方のRuntimeに統一するのが賢明です。日常的にClaude Codeのみを使用し、ターミナル中心のワークフローを好むのであれば、そもそも高度な管理レイヤーは不要かもしれません。一方で、タスクの性質によって得意不得意が分かれる場合や、ワークフローを全面的に見直すことなく翌月にデフォルトモデルを切り替えられる柔軟性を確保したい場合は、両方を併用するのが適切です。翌月の情勢変化は決して机上の空論ではありません。Opus 5.5、Sol、Lunaが同日にリリースされ、そのわずか6日後にSonnet 5.5がリリースされたことからもそれは明らかです。

ただし、両方の併用を成功させるには、Runtimeではなく「Task」を信頼できる唯一の情報源（Record）として管理することが前提となります。Sonnet 5.5のThinkingブロック（思考プロセス）を他のモデルが読み取ることはできないため、TaskをClaude Code AgentからCodex Agentへ引き継ぐ際、モデル内部の推論コンテキストは引き継がれず、Task上に記録されたテキストのみが共有されます。したがって、下した決定事項、前提条件、未解決の論点は、必ずTaskの説明文やコメント欄に残しておく必要があります。日常運用におけるプラクティスは「単一コードベースでClaude CodeとCodexを併用運用する方法」を、Claude側でのモデル振り分け戦略については「Sonnet 5.5かOpus 5.5か：タスクに応じたエージェント選定」を参照してください。

エージェントの役割は調査、実装、テスト、そして報告です。進むべき方向性を定め、権限を付与し、最終的な成果物を承認するのは人間の役割です。Runtimeは四半期ごとに変わる可能性がありますが、要求からリリースに至るまでのコンテキスト、進捗状況、ブロッカー、成果物、そして人間によるレビュー履歴は、常に一箇所で可視化されているべきです。

先週取り上げたテーマである「デフォルトRuntimeとしてのOpus 5.5 vs GPT-6 Sol」でも、これと鏡像関係にあるデータ上の問題が発生していました。OpenAIの発表記事でSolの比較対象とされていたClaudeモデルは、そのわずか数時間後に後継モデルに取って代わられたのです。デフォルトの設定方針を文書化し、自社のコードベースで実測し、Runtimeをいつでも切り替え可能な設定値として保持できるようにしておきましょう。単一のエコシステムに縛られることなく、複数のコーディングエージェントを使い分けたいと考えているなら、まさにその課題を解決するために設計されたのがSharklyです。1台のComputerを接続し、RuntimeごとにAgentを1つ作成し、両者に同じ実タスクを実行させてみてください。