GPT-6 SolとAstraの違い｜どちらを使うかの判断軸

OpenAI が 2026年9月22日に GPT-6 Sol と GPT-6 Luna を発表し、GPT-6 のラインナップは Astra / Sol / Luna の3枚になりました。「結局どれを使えばいいのか」「全部いちばん賢い Astra でよいのでは」という疑問に、公式発表の数値だけで線を引きます。

結論：Astra は全方位で最良、Sol はコスト効率で勝つ領域がある

まず公式の位置づけです。OpenAI は GPT-6 Sol / Luna の発表ページで、GPT-6 Astra は引き続き全方位で最良のモデルであり、最高の結果と妥協のない体験が要るときは Astra を使うべきだと明記しています。つまり「Sol が Astra の上位互換になった」わけではありません。

一方で、同じページには逆向きの数字も載っています。Zapier の AutomationBench 1.0.6 では GPT-6 Sol (xhigh) が 33.2%・1タスクあたり $0.27 で、GPT-6 Astra (low) の 30.3% を上回り、しかも Astra (low) のコストは Sol の 3.9倍でした。ここが今回いちばん重要な示唆です。

読み替えるとこうなります。「上位モデルの effort（推論量）を落として使う」より「下位モデルの effort を上げて使う」ほうが、スコアもコストも有利になる領域がある。予算の都合で Astra を low で回している運用は、Sol を xhigh で回したほうが安くて強い可能性がある、ということです。

GPT-6 の3モデル比較表

Astra の単価は今回の発表ページには書かれていないため、ここでは断定しません。Astra 単体のコスト感は GPT-6 Astra の月額を3ケースで試算した記事と、プラン別の利用上限をまとめた記事を併せてご覧ください。

用途別の使い分け（実務での線引き）

最重要・長時間の難案件 → Astra

失敗のやり直しコストが API 料金より圧倒的に高い仕事は Astra です。公式が「全方位で最良」と言っている以上、ここを節約して事故らせるのは筋が悪い。特にコンピュータ操作（ブラウザや OS を実際に触らせる系）の最強は引き続き Astra と明記されています。OSWorld 2.0 offline では Sol (xhigh) が 60.5% で Claude Opus 5 (medium) の 60.3% とほぼ並び、コストは約80%減という数字が出ていますが、それでも「最強は Astra」という但し書きが付いています。

日常の業務ワークフロー・コーディングエージェント → Sol

毎日大量に回す自動化、CI に組み込むコード修正、社内の問い合わせ処理。ここが Sol の主戦場です。Agents' Last Exam では Sol (max) が 56.4% で Claude Opus 5 の最高スコアを超え、コストは60%減。DeepSWE v1.1 では Sol (max) 68.8% が Claude Fable 5 の最高 69.9% と 1.1pt 差、コストは約80%減と公表されています。実務では「Astra でないと無理」と思い込んでいた工程の大半がここに降りてきます。

大量処理・分類・下ごしらえ → Luna

入力 $0.10 / 出力 $0.50 という単価は、分類・要約・タグ付け・一次スクリーニングのような「数で殴る」工程のためのものです。DeepSWE v1.1 で Luna (max) が 66.6%＝Opus 5・Fable 5 の medium 相当という数字もあり、下ごしらえ用途なら十分に実用域です。現場で多いのは、Luna で候補を絞ってから Sol か Astra に渡す2段構えで、総コストを一桁落とすパターンです。

どのモデルをどの工程に置くか、社内の業務に当てはめて設計するところが一番つまずきやすい部分です。Mihata では AI 導入支援としてこの整理からお手伝いしています。記事の途中で恐縮ですが、よろしければ覗いていただけたら嬉しいです。

effort（推論量）をどう決めるか

GPT-6 は reasoning effort を xhigh / high / medium / low から選べます。同じモデルでも effort によって精度もコストも変わるため、「モデル名だけで比較する」のは実務では意味がありません。先ほどの AutomationBench が典型で、Sol (xhigh) と Astra (low) では下位モデルのほうが勝っています。

実務での決め方はシンプルです。まず Sol の high か medium で走らせ、品質が足りなければ effort を1段上げる。それでも届かない工程だけ Astra に上げる。逆に、結果が安定している工程は effort を下げてコストを回収する。モデルを変えるより effort を動かすほうが、影響範囲が小さく戻しやすいためです。

ベンチマークの数字は「effort 条件込み」でしか比較できない

ここは強調しておきます。OpenAI と Anthropic のベンチ数値は、それぞれが自社に有利な effort 条件で測った値です。同じ AutomationBench でも、OpenAI の表では Claude Opus 5 (max) が 26.9%、Anthropic の表では GPT-6 Astra が 41.4%・Claude Opus 5.5 が 40.0% と、まったく別の景色になります。

したがって「A社のモデルがB社より上」と断定できる材料は、公開ベンチだけでは揃いません。数字はあくまで「その effort 条件で、その実施主体が測ったらこうなった」という範囲で読み、最後は自社のタスクで小さく実測するのが確実です。モデル横断の比較の読み方は GPT-6 Astra と Fable 5.1・Gemini 3.8 を比較した記事でも整理しています。

切り替えの実務：モデルIDと effort の動的切り替え

API 側の切り替えは、モデルIDを gpt-6-sol または gpt-6-luna に変えるところから始まります。加えて今回の発表で効いてくるのがキャッシュ周りの改善です。

• 既定でキャッシュヒット率が向上し、キャッシュされた入力トークンの読み出しは90%引き。
• Prompt Caching のダッシュボード・診断ツール・明示的なブレークポイントが提供される。
• reasoning effort やツールの有効・無効を変えてもキャッシュが壊れない。
• GitHub は数か月で、新規に処理が必要なプロンプトトークンの割合が50%超減ったと報告している。

4つ目が実務的に大きい。従来は effort を変えるとキャッシュが効かなくなるため、「簡単な入力は低 effort、難しい入力は高 effort」という動的な出し分けがコスト的に割に合いませんでした。それが壊れない仕様になったことで、1本のプロンプトを共有したまま effort だけリクエスト単位で切り替える設計が現実的になったわけです。

なお ChatGPT 側では、Sol / Luna は ChatGPT Work と Codex で提供され、Chat ではまだ使えません。ロールアウトも一日かけて段階的に行われるため、見当たらない場合は時間をおいて再度確認するよう公式が案内しています。表示されない場合の切り分けは GPT-6 Sol が出てこないときの確認手順にまとめました。新しい2モデルの概要そのものは GPT-6 Sol と Luna の発表内容をまとめた記事、単価の詳細は GPT-6 Sol の料金を整理した記事が対応しています。

まとめ：判断軸は「失敗コスト」と「回す量」

迷ったときの順番はこうです。①その工程は失敗したときに人が尻拭いするコストが高いか → 高いなら Astra。②毎日大量に回すか → 回すなら Sol を high 前後で。③単純な分類・下ごしらえか → Luna。④それでも品質が足りなければ、モデルを上げる前に effort を1段上げる。

「全部 Astra」は確実ですが、AutomationBench の 3.9倍という数字が示すとおり、効かせどころを外すと費用だけが膨らみます。逆に「全部 Sol」も、コンピュータ操作のように Astra が明確に強い領域を取りこぼします。工程ごとに分けるのが、いまのところ最もコスパの良い答えです。

自社の業務のどこを Sol に落とし、どこを Astra に残すか。実際の業務フローに当てはめて設計するところからご相談いただけます。