GPT-6 Astra・Sol・Lunaの選び方：タスク難度と総コストで振り分ける
検証しやすい限定タスクはGPT-6 Lunaを低コストの出発点にし、複雑なコーディングやエージェント型ワークフローはSol、失敗コストが高い最難関のエンドツーエンド作業はAstraを候補にします。本稿ではOpenAI StandardとBetterTokenの料金、272Kを超える長コンテキスト料金、キャッシュ、Codexのプラン課金とAPI課金の違い、GPT-5.5からの管理された移行方法を整理します。
目次
Lunaが最も安く、Astraが最も高性能だと分かっていても、目の前のタスクに20倍、100倍のToken単価を払う価値があるかは別問題です。基本ルールは、明確に検証できる大量処理はLuna、複雑なコーディングと通常のエージェント処理はSol、曖昧さや失敗コストが大きいエンドツーエンド作業はAstraから始めることです。 この記事を読めば、最初のモデル、エスカレーションの条件、同じToken使用量でのOpenAI StandardとBetterTokenの費用を判断できます。
最初の選択：検証可能な大量処理はLuna、複雑な開発はSol、高リスクはAstra
タスクの境界と失敗コストで最初のモデルを選び、その後に自分の合格データで既定ルートを修正します。
| モデル | OpenAIの公式な位置付け | 最初に割り当てやすいタスク | 上位モデルへ切り替える条件 |
|---|---|---|---|
gpt-6-luna | 集中的で大量のタスク向けの効率的なモデル | 小規模で範囲が明確な修正、構造化抽出、分類、形式変換、明確な仕様からのテスト作成、決定的な検証があるバッチ処理 | 検証に繰り返し失敗する、複数ファイルをまたぐ推論が必要、ツール連鎖が長くなる、重大な曖昧さが残る |
gpt-6-sol | 複雑なコーディングとエージェント型ワークフロー向け | 複数ファイルの機能開発、デバッグ、コードレビュー、複数のツール呼び出しを伴うリポジトリ作業、境界が明確な中程度の調査・文書作成 | 誤った計画の影響が大きい、複数回の計画でも重要制約を落とす、システム間のトレードオフや難しい調査が必要 |
gpt-6-astra | 最も難しいエンドツーエンド作業向けの最上位モデル | アーキテクチャ判断、複雑な移行、システム横断障害の分析、高リスクなコード変更、調査・文書作成・computer useを含む長い処理 | Astraはこの3モデルの最上位です。それでも失敗する場合は、名前でさらに上げるのではなく、タスクを狭め、根拠を追加し、人の判断点を置く |
重要なのは「簡単そうな仕事は必ずLuna」という固定ルールではありません。必要な品質基準を安定して満たす最小コストのモデルを探すことです。安いモデルが何度もやり直しを生むなら、最終コストは上がります。一方、仕様が明確なすべての仕事をAstraから始めると、使わない能力に料金を払うことになります。
公開情報には、Astra、Sol、Lunaを同じ実タスクで独立比較した結果がまだありません。このマトリクスを実行可能な出発点とし、初回合格率、再試行、合格結果までの実時間、合格タスク1件当たりの総コストを記録してください。
コンテキスト上限が似ていても、モデルは代替可能ではない
3モデルはコンテキストとツールの範囲が近いため、ウィンドウサイズよりタスク形状、推論設定、失敗コストが重要です。OpenAIはAstraを複雑な推論・コーディング・computer use・調査・文書作成、Solを複雑なコーディングとエージェント処理、Lunaを集中的な大量処理向けと位置付けています。これは最初の候補を決める材料ですが、既定モデルは自分のタスク結果で決めます。
3モデルはいずれもコンテキストウィンドウが1,050,000 Token、最大入力が922,000 Token、最大出力が128,000 Tokenです。そのため、単に「長い文脈が入るか」だけでは差がつきません。実務では次の点が重要です。
- Astraの
reasoning.effortはlow、medium、high、xhigh、maxに対応します。 - SolとLunaは
noneにも対応し、デフォルトはmediumです。範囲が明確なタスクでは、まず低い推論強度を試すと、コスト増がモデル選択によるものか過剰なreasoningによるものかを切り分けられます。 - ツール利用が多いエージェント処理ではResponses APIを優先します。SolとLunaでChat Completionsのfunction callingを使う場合、
reasoning_effortはnoneである必要があります。 - 実使用量はモデル、コンテキスト、reasoning、ツール、retrieval、キャッシュの影響を受けます。Promptの文字数だけではタスクコストを推定できません。
公平に比べるには、インターフェース、コンテキスト、ツール、reasoning effort、最大出力、合格条件を固定します。複数の変数を同時に変えると、見えている差がモデルではなく設定の差である可能性があります。
同じTokenならBetterTokenはOpenAI Standardと比較する
同じToken使用量なら、2026-09-24に確認したBetterToken料金は対応するOpenAI Standardの68%でした。ただし常に最安という意味ではありません。OpenAI BatchとFlexはさらに低く、再試行、ツール、人手修正を含む総コストで判断する必要があります。表はUSD・100万Token当たり、入力コンテキスト272K以下の料金です。
| Model ID | 提供元 | 入力 | キャッシュ読み取り | キャッシュ書き込み | 出力 |
|---|---|---|---|---|---|
gpt-6-astra | OpenAI Standard | $10.00 | $1.00 | $12.50 | $50.00 |
gpt-6-astra | BetterToken | $6.80 | $0.68 | $8.50 | $34.00 |
gpt-6-sol | OpenAI Standard | $2.00 | $0.20 | $2.50 | $10.00 |
gpt-6-sol | BetterToken | $1.36 | $0.136 | $1.70 | $6.80 |
gpt-6-luna | OpenAI Standard | $0.10 | $0.01 | $0.125 | $0.50 |
gpt-6-luna | BetterToken | $0.068 | $0.0068 | $0.085 | $0.34 |
1回のリクエストの入力コンテキストが272Kを超えると、両サービスで3つのGPT-6すべてが長コンテキスト料金になります。入力、キャッシュ読み取り、キャッシュ書き込みは表の2倍、出力は1.5倍になり、その高い料金がリクエスト全体に適用されます。 たとえば長コンテキストのgpt-6-solは、入力/キャッシュ読み取り/キャッシュ書き込み/出力の順に、OpenAI Standardで$4.00/$0.40/$5.00/$15.00、BetterTokenで$2.72/$0.272/$3.40/$10.20です。
料金は動的です。本番投入前に現在の価格を確認し、モデルの提供状況、通貨、適用される料金帯を再確認してください。OpenAIのBatchとFlexは現在Standardの50%で、この時点のBetterToken料金より低い設定です。非同期処理や低優先度処理が可能なら、OpenAI Standardと同じ比較枠に混ぜないでください。表には地域処理の追加料金、ツール呼び出し、コンテナ、再試行も含まれません。
BetterTokenのGPTグループは、API、Codex、カスタムBase URLに対応する外部ツールから利用できます。BetterTokenはOpenAIの公式製品ではなく、そのAPI使用量はChatGPTやCodexのサブスクリプションに含まれるメッセージ数、利用枠、creditsとは別物です。
GPT-5.5を利用中なら、移行前に基準を残す
GPT-5.5のワークフローが安定しているなら、新しいモデル名だけを理由に切り替えないでください。現在の品質、実時間、コストを基準として保存し、同じタスクをSol、Luna、Astraで再実行します。以下は2026-09-24確認のUSD・100万Token当たりの料金です。
| Model ID | 提供元 | コンテキスト | 入力 | キャッシュ読み取り | 出力 |
|---|---|---|---|---|---|
gpt-5.5 | OpenAI Standard | ≤ 272K | $5.00 | $0.50 | $30.00 |
gpt-5.5 | OpenAI Standard | > 272K | $10.00 | $1.00 | $45.00 |
gpt-5.5 | BetterToken | 料金帯なし | $3.40 | $0.34 | $20.40 |
BetterTokenのgpt-5.5には長コンテキストの別料金帯がありません。OpenAI Standardは272Kを超えると高い料金帯になります。キャッシュ書き込み価格は、OpenAIが公開するGPT-5.5料金行に値がないため記載せず、推定もしません。
移行には別の2つの論点があります。OpenAIによると、GPT-5.5は2026-10-14にChatGPT、ChatGPT Work、Codexの全プランから終了しますが、OpenAI APIには影響しません。Codexのプラン利用者はその日までに代替ルートを用意する必要があります。一方、API Keyのワークロードは、プラン側の終了だけを理由に急いで移行する必要はありません。Codexのプラン枠、追加credits、USDで従量課金されるAPIは別々の課金体系です。
見るべき指標は合格タスク1件当たりのコスト
1回の呼び出し価格だけでは、仕事を完了する最安モデルは分かりません。失敗、再試行、キャッシュ書込、ツール料金、人手修正を合計し、合格結果数で割ります。以下ではまず同じToken構成で2つの課金経路だけを比較します。
合格した1回の実行が次を使うとします。
- 未キャッシュ入力120,000 Token
- キャッシュ入力100,000 Token
- 出力10,000 Token
- 今回は新しいキャッシュ書き込みなし
- 総入力コンテキストは220Kなので短コンテキスト料金
「Token数 ÷ 1,000,000 × 各料金」で計算すると、1回のモデル料金は次のとおりです。
| Model ID | OpenAI Standard | BetterToken |
|---|---|---|
gpt-6-luna | $0.01800 | $0.01224 |
gpt-6-sol | $0.36000 | $0.24480 |
gpt-6-astra | $1.80000 | $1.22400 |
gpt-5.5 | $0.95000 | $0.64600 |
これは同じToken構成の請求額を比べる例であり、品質、速度、最終的な費用対効果の比較ではありません。同じToken構成と処理モードなら、SolはLunaの20倍、AstraはSolの5倍です。ただし、失敗した試行、長い出力、追加ツール、人手による修正があると、完了総コストの差は縮まったり逆転したりします。
より実用的な式は次です。
完了コスト = 全試行のToken料金 + キャッシュ書き込み + ツール料金 + 失敗した再試行と手直し。
この合計を合格タスク数で割ると、合格結果1件あたりのコストが得られます。本番のルーティング判断には、成功した1リクエストの価格よりこちらの指標が適しています。
ワークフローで最初のモデルを決め、エスカレーション条件を置く
既定ルートは明確にできます。信頼できる自動検証がある低リスク作業はLuna、複雑な開発はSol、高リスクまたは強い曖昧さがある作業はAstraから始めます。
検証可能な大量処理：Lunaから始める
schema、linter、unit testなどの決定的な規則で失敗をすぐ検出できるなら、Lunaを最初に試します。固定形式変換、既知フィールドの抽出、局所的な名前変更、正確な仕様からのテスト作成、信頼できる自動受け入れがある大量出力が候補です。
検証に失敗した、未提示の依存関係が見つかった、モジュール間判断が必要になった場合はSolへ上げます。小さいモデルに同じ誤った方向を無制限に繰り返させないようにします。
複数ファイルとエージェント処理：Solから始める
複数ファイルの理解、連続したツール利用、実行結果に応じた計画変更が必要ならSolから始めます。複数ファイルへの機能実装、テスト失敗の診断、変更前のリポジトリ検索、ツール結果を受けた継続作業が典型例です。
ただし、タスク範囲は明確にします。「分析し、変更し、最も関連するテストを実行し、未解決事項を報告する」という完了条件は、計画なしにreasoning.effortを上げるより有効です。代表タスクでSolがアーキテクチャ制約を繰り返し落とす場合にAstraへ上げます。
曖昧または高リスクなエンドツーエンド作業：Astraから始める
誤答コストがモデル追加料金を明確に上回るなら、Astraから始めます。システム間移行、難しい本番障害、重要なセキュリティ境界、調査量の多い意思決定、コーディング・computer use・長いツール連鎖を組み合わせた処理が該当します。
Astraにも検証は必要です。計画、根拠、変更、確認のチェックポイントに分け、最上位モデルが誤った前提を長時間追わないようにします。
まだ迷うなら、同じ実タスクで比較する
普遍的な固定サンプル数は必要ありません。通常、境界、失敗ケースを含む代表的な集合と、各モデルに共通する受け入れ基準が必要です。
- 代表的なタスク集合を選びます。 小変更、複数ファイル開発、デバッグ、ツール利用、知識作業を含め、整えたデモだけにしません。
- 実行前に受け入れ基準を決めます。 tests、lint、schema、事実チェックリスト、人手レビューを使います。回答後に基準を変えると比較の信頼性が落ちます。
- 他の変数を固定します。 同じコンテキスト、ツール、API、推論強度、最大出力、環境を使います。異なる
reasoning.effortは別実験にします。 - すべての試行を記録します。 初回合格、再試行、合格結果までの実時間、入力・キャッシュ・出力Token、ツール呼び出し、最終費用を保存します。
- 合格結果1件当たりのコストを計算します。 最後の成功だけでなく、失敗試行と人手修正も含めます。
- タスク種別ごとに結論を出します。 コード変更では合格しても、調査や長いエージェント処理では失敗するモデルがあります。単一の全体既定値で差を隠さないでください。
- 各種別で複数の実運用結果が集まったら見直します。 上位モデルが合格率や総コストを繰り返し改善しないなら、小さいモデルか既存のGPT-5.5 APIワークフローへ戻します。
最低でも初回合格率、最終合格率、合格結果1件当たりの総コスト、完了時間の中央値と高パーセンタイルを比べます。実際の品質基準で継続的に勝つモデルだけを既定にします。
モデルの格ではなく、反復失敗とリスクでエスカレーションする
高価なモデルなら自動的に優れると考えず、観測できる失敗シグナルでエスカレーションします。
- Luna → Sol: 決定的な検証が同種タスクで繰り返し失敗する、ファイル・モジュール横断の推論が必要、ツール結果が計画を大きく変える、または条件を補っても重要な曖昧さが残る。
- Sol → Astra: 複数回の計画でも重要制約が抜ける、誤りが本番・セキュリティ・大規模移行に影響する、または難しい推論・調査・文書・実行を同時に扱う。
- Astra → タスクを狭める: Astraでも合格しないなら、コンテキストや推論を増やし続けず、根拠を追加し、工程を分け、人の判断点を置きます。
- 新モデル → GPT-5.5へ戻す: APIでは、GPT-5.5が品質、遅延、保守要件を満たす限り残せます。新しい名前だけでは移行理由になりません。
既定のエスカレーションはLuna → Sol → Astraです。信頼できる検証器があればLuna、複雑な開発ならSol、高リスクならAstraとし、自分の合格率、再試行、実時間、合格結果コストが別ルートを支持するときだけ変更します。
