Claude Opus 5とGPT-5.6-SOLを10問で検証：中核回答の正答率は両モデルとも10/10

Claude Opus 5とGPT-5.6-SOLを10問で検証：正解率はともに10/10、完遂率と形式遵守には差#

モデル比較では、ひとつの総合点だけを見ても、実際の業務適性は判断しにくいものです。最終的な答えが正しいこと、指定されたすべての要件を満たすこと、機械処理できる形式で返すことは、それぞれ別の能力だからです。

そこで今回は、Crazyrouterの同一OpenAI-compatible endpointを通じて、Claude Opus 5とGPT-5.6-SOLに10問の検証課題を実行しました。評価対象は、数学・物理の正解、誤った前提の指摘、Pythonコードの隠しテスト、全サブ要件の完遂です。厳密なJSON出力は、推論問題とは分けて指示遵守テストとして扱いました。

結果は次のとおりです。

• 中核となる回答の正解率：Opus 5は 10/10、GPT-5.6-SOLも 10/10
• すべてのサブ要件を完了した割合：Opus 5は 9/10、GPT-5.6-SOLは 10/10
• Pythonアルゴリズム2問の隠しテスト：両モデルとも 2/2
• 厳密なJSONの初回提出：Opus 5は 0/1、GPT-5.6-SOLは 1/1
• Opus 5は追加の2回の再試行でも、JSON以外の文章またはコードフェンスを付加

この結果から言えるのは、10問の中核正解率は同率だった一方、タスクの完遂と出力形式の遵守には違いが見られた、ということです。単純な順位にまとめるより、正解率・完遂率・形式遵守を分けて読むほうが、実運用には役立ちます。

API Keyを作成し、実際の業務問題で再検証する

早見表#

数学・物理・アルゴリズムの正しさを重視する用途では、このサンプルから明確な差は確認できませんでした。一方、応答をそのままJSONとして解析する処理や、すべてのサブ要件を1回で満たす必要がある用途では、今回のGPT-5.6-SOLのほうが完全な形で提出できています。

まず分けて読むべき3つの指標#

今回の結果を解釈する際は、以下の3層を混同しないことが重要です。

1. 中核回答の正解率
   主要な数値、結論、物理モデル、アルゴリズムの動作が正しいか。

2. タスク完遂率
   設問に列挙されたサブ要件を、最後まで漏れなく回答したか。

3. 機械的な受け入れ可否
   コードがテストに合格するか、JSONをそのまま解析できるか。

たとえば、正しい数値を出していても最後の説明が欠けていれば、中核回答は正解でもタスク完遂とは判定できません。また、JSON内の値がすべて正しくても、前後に説明文が付いていれば、厳密なJSONを要求する処理では受け入れられません。

この分離によって、「推論を間違えた」のか、「出力が途中で切れた」のか、「形式だけが要件に違反した」のかを区別できます。

応答速度を知能スコアから除外した理由#

モデルAPIの端から端までの待ち時間には、モデルの推論能力以外の要因が含まれます。

• ゲートウェイから各上流サービスまでのネットワーク経路
• 検証時点のチャネル負荷やアカウント制限
• キャッシュの有無
• 実際に割り当てられたサービスインスタンス
• 上流側におけるreasoning tokenの計測方法や非表示処理

単発のリクエストが数秒早かったとしても、それだけではモデルの推論能力が高いとは判断できません。上流環境を固定し、十分な回数を反復し、信頼区間まで示さない限り、待ち時間は運用監視の指標であって、知能の指標ではありません。

そのため、今回はネットワーク待ち時間を知能スコアから明示的に除外しています。また、応答速度について、どちらかを優位とは判定していません。

利用可能なモデルや接続範囲はCrazyrouterのモデル一覧、費用計画はCrazyrouter pricingで別々に確認できます。

検証環境と採点方法#

検証前にモデル一覧APIを呼び出し、対象とする正確なモデルIDが表示されることを確認しました。

GET https://cn.crazyrouter.com/v1/models

claude-opus-5
gpt-5.6-sol

本番の検証リクエストには、次のAPIを使用しました。

POST https://cn.crazyrouter.com/v1/chat/completions

各テストでは、両モデルに同じsystem prompt、user prompt、temperature、max_tokensを設定しました。外部ツールは使用せず、HTTP 200が返っただけでは合格と判定していません。

採点は次の手順で行っています。

1. 期待値、必須要件、テスト条件を事前に定義する
2. 両モデルに同一条件で問題を送信する
3. 数値や必須文字列を自動検査する
4. Pythonコードは保存して隠しテストを実行する
5. JSONは実際にパーサーへ渡す
6. 自動判定後に人手で内容を再確認する
7. 中核正解、完遂、形式遵守を別々に記録する

人手による再確認を行ったのは、表記差による偽陰性を避けるためです。LaTeXの書き方、英字の大小、厳密な分数と丸めた小数の違いだけで、不正解と判定すべきではありません。

実際に、GPT-5.6-SOLは確率問題で参照用の分数をそのまま複製していませんでしたが、等価な式と正しい小数を提示しました。また、Opus 5は物理問題の0.302 mを有効数字2桁の0.30 mとしていました。いずれも中核的な誤りではありません。

10問の検証結果#

10問の中核回答は両モデルとも 10/10 です。ただし、すべてのサブ要件を満たした完全な回答は、Opus 5が 9/10、GPT-5.6-SOLが 10/10 でした。

最難関の確率問題：正解と完遂を分けて評価する#

対象パターンはHHTHで、偏りのあるコインの確率はP(H)=0.62、P(T)=0.38です。

設問では、最長の接頭辞・接尾辞一致に基づく状態を使って方程式を立て、さらに次の2点を説明するよう求めました。

• 状態HHの後に再びHが出たとき、なぜ状態がHHのままなのか
• なぜ期待待ち時間を単純に1/P(HHTH)とは書けないのか

両モデルが得た期待値は正しいものでした。

E[N] ≈ 12.6547

GPT-5.6-SOLは状態遷移と導出を最後まで提示し、パターンの重なりを考慮して次の関係を示しました。

E[N] = 1 / P(HHTH) + 1 / P(H)

Opus 5も、正しい状態、方程式、厳密な分数、小数値を提示しています。しかし、応答のfinish_reasonはfinish_reason=lengthでした。

この問題ではmax_tokens=3200が出力上限となり、Opus 5の回答は追加の状態期待値を記述している途中で終了しました。そのため、最後に要求されていた「なぜ単純な逆確率を使えないのか」という説明が欠けています。

評価は次のように分けました。

• 期待値12.6547と状態方程式は正しいため、中核回答は正解
• 最後の説明要件がないため、完全なタスク提出としては不合格

つまり、正しい途中結果が含まれていることと、依頼全体を完遂したことは同義ではありません。

この点は、以前のmax_tokensによる打ち切りの再検証とも共通します。検証時は回答本文だけでなく、finish_reasonと出力上限も保存する必要があります。

実行可能コードの検証：見た目ではなくテスト結果で判定#

コード生成では、長い実装や丁寧なコメントが正しさを保証するわけではありません。そこで今回は、両モデルの出力を.pyファイルとして保存し、隔離した環境で同一の隠しテストを実行しました。

ログ集計アルゴリズム#

関数には、次の要件を設定しました。

• 半開区間の時間窓を正しく処理する
• 成功リクエストと失敗リクエストで異なる集計規則を適用する
• ユーザーまたはモデルが欠落した入力を処理する
• cache hit rateを計算する
• costが同じ場合はユーザー名の辞書順で並べる
• 入力オブジェクトを変更しない

両モデルの実装が隠しテストに合格しました。

信頼性制約付きの安定経路選択#

経路探索では、次の条件を同時に処理する必要があります。

• 総コストが最小の経路を選ぶ
• コストが同じ場合はlatencyが最小の経路を選ぶ
• latencyも同じ場合はreliabilityが最大の経路を選ぶ
• それでも同じ場合は経路の辞書順で選ぶ
• banned nodes、最大hops、最小reliability、不正な辺を処理する

こちらも両モデルが隠しテストに合格しました。

したがって、今回のコード検証結果は両モデルとも 2/2 です。コードの長さや説明の読みやすさではなく、実行結果に基づいて同率と判定しています。

GPT-5.6-SOLの別の複雑な物理・依存関係アルゴリズムの検証については、GPT-5.6-SOL vs GPT-5.5 高難度物理・コード検証も参照できます。

厳密なJSON：推論の正しさではなく形式遵守を測る#

厳密なJSONの課題では、事故データを単一オブジェクトへまとめ、次の条件を明記しました。

exactly one JSON object and no Markdown

両モデルとも、失敗率、チャネルの帰属、再試行後も復旧しなかった件数を正しく計算しました。違いは、JSONの前後に何を出力したかです。

• GPT-5.6-SOLは初回からJSONだけを返し、json.loadsで直接解析できた
• Opus 5は初回にコードフェンスとVerificationを付加した
• Opus 5の1回目の再試行では、圧縮されたJSONの後にVerificationを付加した
• Opus 5の2回目の再試行では、再びコードフェンスと説明を付加した

したがって、厳密なJSONの初回提出結果は次のとおりです。

Opus 5はデータや計算を間違えたのではありません。すべてのフィールドと値は正しかったものの、要求された出力形式に違反しました。これは「計算能力の失敗」ではなく「形式および指示遵守の失敗」です。

本番環境では、最低限でもローカル側で次のような検証を行えます。

import json

REQUIRED_KEYS = [
    "window",
    "total_requests",
    "failed_requests",
    "failure_rate_pct",
    "provider_owned_failures",
    "customer_owned_failures",
    "recovered_by_retry",
    "unrecovered_failures",
    "root_cause",
    "action",
]


def parse_incident_json(raw: str) -> dict:
    payload = json.loads(raw)
    if list(payload) != REQUIRED_KEYS:
        raise ValueError("unexpected schema or key order")
    if payload["failed_requests"] != 84:
        raise ValueError("failed request count mismatch")
    return payload

system promptだけで構造化出力を保証することはできません。より堅牢にするには、供給元が対応する構造化出力パラメータを使用し、ローカルでschema検証を行い、解析に失敗した場合は再試行またはモデルの切り替えを実施します。

同一APIで再検証する方法#

以下はOpenAI-compatible chat completions endpointを使う最小構成です。API endpoint自体にはUTMパラメータを付けません。

import os
import requests

BASE_URL = "https://cn.crazyrouter.com/v1"
API_KEY = os.environ["CRAZYROUTER_API_KEY"]


def ask(model: str, prompt: str, max_tokens: int = 4000) -> dict:
    response = requests.post(
        f"{BASE_URL}/chat/completions",
        headers={
            "Authorization": f"Bearer {API_KEY}",
            "Content-Type": "application/json",
        },
        json={
            "model": model,
            "messages": [
                {"role": "system", "content": "Answer accurately and follow every requested constraint."},
                {"role": "user", "content": prompt},
            ],
            "temperature": 0.2,
            "max_tokens": max_tokens,
        },
        timeout=600,
    )
    response.raise_for_status()
    return response.json()


for model in ("claude-opus-5", "gpt-5.6-sol"):
    result = ask(model, "Your benchmark prompt here")
    choice = result["choices"][0]
    print(model, choice.get("finish_reason"), choice["message"].get("content", ""))

再検証では、少なくとも次の情報を保存しておくと、後から判定根拠を追跡しやすくなります。

• response ID
• returned model
• finish_reason
• 原文の回答
• リクエスト時のmax_tokens
• ローカル検証の結果
• JSON解析エラー
• コードテストの標準出力と終了コード

現在のモデル表示はCrazyrouterのモデル一覧で確認し、その後に実際の業務promptを使って小規模な回帰テストを行うのが安全です。

本番導入時の考え方#

両モデルを候補にしやすい用途#

• 正解や許容誤差を事前に定義できる数学・物理問題
• 単体テストを実行できるPythonアルゴリズム
• 誤った前提や不十分な統計的結論を指摘する処理
• ローカル検証器によって成功・失敗を判定できる作業手順

今回、両モデルは10問すべてで中核回答が正解し、2問のコード課題でも隠しテストに合格しました。そのため、検証可能な処理では、どちらも候補に含められます。

今回の結果でGPT-5.6-SOLを優先しやすい条件#

• すべてのサブ要件を1回の応答で満たす必要がある
• 応答本文が厳密なJSONでなければならない
• 説明文から構造化データを抽出する処理を減らしたい

これは総合的な知能順位を意味するものではありません。今回の観測範囲では、GPT-5.6-SOLがタスクの完遂と厳密なJSON提出で要件を満たした、という限定的な判断です。

Opus 5を使う場合に追加したい保護策#

• 長い導出には十分なmax_tokensを設定する
• 必ずfinish_reasonを確認する
• JSONは下流へ渡す前に解析する
• 余分なMarkdownや説明文がある場合の回退処理を用意する
• 必須サブ要件を個別に検査する
• 打ち切り時には出力上限を調整して再試行する

Opus 5の推論が弱かったという結果ではありません。今回の10問では中核回答がすべて正しく、2つのコード実装も隠しテストを通過しました。差が表れたのは、正しい内容を最終応答の中にすべて収められたか、指定形式だけで返せたかという点です。

Claude系モデル内での提出挙動も比較する場合は、Claude Opus 5 vs Claude Fable 5 実API検証も参考になります。

FAQ#

Claude Opus 5とGPT-5.6-SOLのどちらがより賢いですか？#

今回の10問では、両モデルの中核回答が 10/10 でした。この結果だけでは、一方が全面的により賢いとは判断できません。用途別に正解率、完遂率、形式遵守率を確認する必要があります。

中核正解率とタスク完遂率は何が違いますか？#

中核正解率は、主要な数値や結論が正しいかを評価します。タスク完遂率は、それに加えて、指定された説明や根拠などの全サブ要件を満たしたかを評価します。正しい答えを出しても、一部の要求が欠けていれば完遂とは判定しません。

なぜ完遂率は同率ではないのですか？#

Opus 5の難しい確率問題がmax_tokens=3200で打ち切られ、finish_reason=lengthとなったためです。期待値12.6547と状態方程式は正しかったものの、最後に求められた説明が欠けました。GPT-5.6-SOLはすべてのサブ要件を完了しました。

Opus 5は確率問題を間違えたのですか？#

いいえ。中核となる確率計算は正しく、期待値は12.6547でした。不足していたのは、なぜ期待値を単純に1/P(HHTH)とできないかという最後の説明です。

JSONの形式違反は知能上の誤りですか？#

数学や推論の誤りとは分けて扱うべきです。Opus 5が計算したJSONのフィールドと値は正しかった一方、JSON以外の文字列を追加したため、厳密な形式要件には違反しました。より正確には、形式および指示遵守の失敗です。

厳密なJSONの結果はどうなりましたか？#

初回はGPT-5.6-SOLが 1/1、Opus 5が 0/1 でした。Opus 5は追加の2回の再試行でも、説明文またはコードフェンスを付加し、厳密なJSON要件には準拠しませんでした。

コード課題はどのように採点しましたか？#

モデルの出力をPythonファイルとして保存し、同一の隠しテストを実行しました。境界条件、並べ替え規則、不正入力、入力オブジェクトの不変性などを検査し、両モデルとも 2/2 で合格しました。

なぜ応答速度の優劣を出していないのですか？#

端から端までの待ち時間には、ネットワーク経路、チャネル負荷、キャッシュ、上流インスタンス、アカウント制限などが影響します。固定された上流環境で十分な反復を行わない限り、モデルそのものの推論性能から分離できないため、知能スコアには含めていません。

10問だけで長期的なモデル選定はできますか？#

できません。今回は再現可能な小規模サンプルです。本番導入前には、実際の業務問題を使って20～50回程度反復し、中核正解率、タスク完遂率、コードテスト合格率、形式違反率を別々に集計する必要があります。

自社で比較を始めるには何が必要ですか？#

まず実際の業務から10～30件のpromptを選び、各問題について機械的に実行可能な合格条件を定義します。その後、同じAPI条件で両モデルに同一入力を送り、回答本文だけでなく、finish_reason、コードテスト、JSON解析結果も保存します。先に結論を決めてから都合のよい事例を選ぶ方法は避けてください。

最終評価#

今回の検証を単純なモデル順位にまとめるのは適切ではありません。確認できた事実は、次のように指標別に整理できます。

Claude Opus 5とGPT-5.6-SOLは、10問の中核回答でともに10/10。すべてのサブ要件を完了した割合はOpus 5が9/10、GPT-5.6-SOLが10/10。Pythonの隠しテストは両モデルとも2/2。厳密なJSONの初回提出はOpus 5が0/1、GPT-5.6-SOLが1/1で、Opus 5は追加の2回の再試行でも非準拠だった。

正解や隠しテストを用意できる業務であれば、両モデルとも候補に含められます。一方、下流システムがJSONを直接処理する場合は、形式検証、再試行、モデルの切り替えを必須の構成要素として設計すべきです。

また、長い推論では中核回答の正しさだけでなく、finish_reasonと出力上限を確認しなければなりません。今回のmax_tokens=3200の事例が示すように、正しい答えが含まれていても、タスク全体が完了しているとは限らないためです。

Crazyrouterアカウントを作成し、Opus 5 / GPT-5.6-SOLを自社問題で検証する