GPT-6.1 Sol vs GPT-6 Sol Pro：一方はモデル、もう一方は設定

手短に言えば、GPT-6.1 Sol と GPT-6 Sol Pro は同じ枠を争う 2 つのモデルではなく、両者のベンチマークスコアを比較するのはカテゴリー錯誤です。GPT-6 Sol Pro はそもそも別個のモデルではありません。それは GPT-6 Sol の reasoning.modeをproに設定して Responses API で使うものです — 同じ識別子、gpt-6-sol、同じ料金表、同じ 1,050,000 トークンのウィンドウで、最終回答を返す前にモデル側でより多くの処理を行い、追加トークンは標準料金で請求されます。GPT-6.1 Sol は、真に別個のデプロイメントで、独自の識別子 gpt-6.1-solを持ち、キャッシュ入力料金は GPT-6 Sol の半分です。したがって、本当の問いはどちらがより賢いかではありません。50% のキャッシュ割引があるまったく新しいモデルが、OpenAI が新しいティア向けに pro 構成をまだ文書化していない古いモデルの実行モードを上回るかどうかです。

二つの異なる種類のもの

まず、それぞれの名前をリクエストに入れたときに実際に何へ解決されるのか、そこから見ていきましょう。「GPT-6 Sol Pro」はgpt-6-solにモードパラメータを加えたものへ解決されます。「GPT-6.1 Sol」はgpt-6.1-solへ解決されます — 別のモデルページ上の別個のスナップショットであり、そのページのどこにもモードパラメータについての言及はありません。この非対称性こそが比較のすべてであり、だからこそ以下の仕様リストには、公平に勝負できるものなどほとんど含まれていないのです。

• 概要 — GPT-6.1 Sol は別個のモデルデプロイメントであるのに対し、GPT-6 Sol Pro は gpt-6-sol に reasoning.mode: "pro"
• 送信する識別子 — gpt-6.1-sol 対 gpt-6-sol
• 入力価格 — 100万トークンあたり $2.00 対 100万トークンあたり $2.00。同一であり、pro モードに Sol の料金表上の追加料金はない
• 出力価格 — どちらも100万トークンあたり $10.00。pro モードの追加の推論トークンもこのレートで課金される
• キャッシュ入力 — 6.1 Sol では100万トークンあたり $0.10、Sol では100万トークンあたり $0.20(いずれのモードでも)— 選択にトレードオフが生じない唯一の項目
• キャッシュ書き込み — どちらも100万トークンあたり $2.50
• コンテキスト — どちらも 1,050,000 トークン、最大出力 128,000
• 推論エフォート — low、medium(デフォルト)、high、xhigh、max を伴い、none は 6.1 Sol では非対応であるのに対し、Sol では同じ段階に none が加わり、pro モードはエフォートとは独立している
• ツール呼び出し — どちらも Responses API に対応。6.1 Sol では Chat Completions はツールなしで利用可能だが、Sol はエフォートが none
に設定されている場合に限り Chat Completions で関数呼び出しをサポートする • レイテンシ — どちらも公表された数値はない。pro モードは構造上より低速で、最終回答の前に多くの処理を行うためである
• タスクあたりのコスト — pro モードについては未公表であり、そもそも意味のある比較はできない。pro モードがあなたのタスクでどれだけ追加の処理を行うかに依存するためである

そのリストを読んで、その形に目を向けてほしい。どの行も、同一であるか、文書化された値と文書化されていない値との比較であるかの、どちらかだ。

プロモードがもたらすもの、そしてその代償

OpenAI による pro モードの説明は短く、言い換えるよりも引用する価値がある。曖昧さこそが要点だからだ。それは「単一の最終回答を返す前に、1 つのリクエストにより多くのモデル処理を適用する Responses API の実行モード」であり、難しいタスクでの信頼性を高められることがあり、レイテンシを増大させ、「その処理で使われたトークンを報告される使用量に集約する」もので、選択したモデルの標準トークン料金で課金される。ベンダー自身による使用タイミングの指針は、ローンチ文書としては異例なほど保守的だ。pro モードは「わずかな品質向上が結果に実質的な影響を与える」ケース向けであり、標準モードは「定型的な作業、レイテンシに敏感な作業、大量処理の場合、および評価で pro モードによる意味のある改善が見られない場合は常に」推奨される。

OpenAIが公表していないのは、その乗数だ。タスクごとの数値も、幅も、Solの料金表にproモードの記載もない。コストは完全にボリュームとして現れ、usageオブジェクト内で、出力として課金され、レスポンス本文では決して返されないreasoningトークンの下に見える。出力トークン100万あたり10.00ドルなら、タスクあたり10,000トークンの追加で1セントかかるので、判断が見出しの数字で決まることはほとんどない。問題は、その追加作業があなたの結果を変えるかどうかだ。それは調べればわかることではなく測定であり、この組み合わせについて、読者が誰かのベンチマークを待たずに決着をつけられる唯一の点だ。

この対戦を決めるドキュメントのギャップ

GPT-6.1 Sol のモデルページ — コンテキストサイズ、料金ブロック、エフォートラダー、ツール一覧、スナップショット一覧を掲載しているページ — には、reasoning.mode、pro モード、standard モードのいずれについてもどこにも言及されていない。pro モードを扱う文章形式のガイドは、依然としてこの機能を「任意の GPT-5.6 モデル」で動作するものとして説明しており、開発者には、選択したモデルを維持し、reasoning.modeをproに設定するよう、別の Pro スラッグに切り替えるのではなく指示している。私たちは両方のページを確認したが、OpenAI のドキュメントから、6.1 ティア向けの pro モード設定が存在することを確認できなかった。動作する可能性はある。親の GPT-6 ガイドでは、このファミリーが引き継ぐ機能の中に pro モードが挙げられている。しかし「動作する可能性がある」は本番パスを載せるべきものではなく、2026年9月30日時点の記録の正直な状態である。

そのギャップは、実に偏った意思決定を生み出す。今日プロモードが欲しいなら、それが公式に記載されている置き場所はGPT-6 Solであり、それを選ぶ代償は、再利用されるプレフィックスごとにキャッシュ入力が$0.10ではなく$0.20になること、さらにプロモードの追加作業分が上乗せされることであり、しかもその相手は、Open​AIが公表したあらゆるタスクファミリーにおいてベンダー報告スコアが6.1 Solを下回るモデルだ。今日6.1ティアのキャッシュ料率とそのベンチマーク上の位置づけを得たいなら、公式に記載されたプロ構成を諦めることになる。両方を得られる行は存在しない。なぜなら、2つ目が存在するかどうかを誰も我々に教えてくれていないからだ。

自分のトラフィックで午後のうちに決着をつける

この測定は地味で、ベンチマークスイートではなく1回の実験で済む。難しい仕事を代表するタスクセットを用意し、それを3回実行して、毎回 usage オブジェクトを読む。1回目は gpt-6-sol を standard mode で medium effort にして、次に gpt-6-sol を pro mode を有効にして medium effort で、そして gpt-6.1-sol を medium effort で実行する。3回すべてで effort を一定に保つ — 要は一度に1つの変数を分離することにある。タスク成功率、レイテンシ、課金対象トークンの合計を比較する。pro mode 実行のトークン合計と standard mode の合計の比が、あなたのトラフィックに掛かる倍率になる。これは他の誰の数値とも一致しない。なぜなら、設計上、追加の作業量はリクエストの難易度に応じてスケールするからだ。

実行するにあたっての実用的な注意点が2つある。1つ目は、6.1 の実行と Sol の実行は、1つの文字列だけが異なる同じリクエストボディなので、実験のセットアップは安く済み、回帰テストとして維持するのも簡単だ。2つ目は、6.1 の識別子に対する pro-mode 呼び出しが、結果ではなくエラーを返すなら、ドキュメントのギャップについての答えが無料で手に入る — しかも、それを本番環境に近づける前に学んだことになる。

両構成、1つのキー

これは、トークンよりもむしろ運用上のオーバーヘッドのほうでコストがかかるタイプの比較であり、まさにここでルーティングは脚注では済まなくなる。OrcaRouter は GPT-6 Sol を Open​AI 自身の定価で、マークアップ一切なしで提供しているため、上記の $2.00 / $0.20 / $10.00 という料金表は——272K の再価格設定ルールも含め——ベンダーが掲示しているとおりにそのまま適用される。つまり、前述の実験の3つのアームは、1つのエンドポイント、1つの API キー、2つ目の契約なしで実行できる。2つの Sol 構成はパラメータ1つだけが異なり、6.1 ティアはルーティング可能になった瞬間にその隣に並ぶ。それが可能になるまでは、呼び出せるモデルは pro モードが文書化されているものだけだ。限界的な品質向上が結果を左右するような、難度が高く処理量の少ない作業には、Sol の pro モードこそがベンダー自身のガイダンスが推奨するものである。処理量が多いものやレイテンシに敏感なものすべてについては、標準構成のほうが高速であり、しかも再利用されるプレフィックスにおいては、キャッシュされたトークンあたりのコストが新しいティアの2倍になっている。その線引きに沿ってトラフィックを分割するルーティングルール——報いに値するリクエストには pro モードを、大半にはより安価な構成を——は、ルーティング DSLにおけるパラメータ変更であって、再アーキテクチャではない。そしてこれこそが、次のモデル刷新を生き延びるこの判断の形である。

具体的に、誰がどちらを選ぶべきか。自分のタスクで pro モードによる信頼性の向上をすでに測定しているなら、測定した環境にとどまり、移行する前に OpenAI が 6.1 の同等機能を文書化するのを待ちましょう — キャッシュの節約は確かにありますが、プレフィックスに対する数セントにすぎず、低ボリュームの作業では、品質向上を再測定するコストのほうが割引の価値を上回ります。pro モードをまったく測定したことがないなら、6.1 ティアのほうが良い出発点です。より新しいモデルであり、そのベンダー報告の結果は OpenAI が公開したあらゆるタスクファミリーで首位に立ち、キャッシュ入力は半額で、ドキュメントが追いついた時点で pro の問いは再検討できます。今日、どちらの選択も間違いではありません。間違っているのは、一方が他方のチェックボックスであるのに、両者を代替案だと想定することです。