OpenAIの現行モデルの選び方:GPT-6 AstraとGPT-5.6 Sol・Terra・Lunaを比較

GPT-6 AstraとGPT-5.6 Sol・Terra・Lunaの位置付け、最新API料金、コンテキスト、推論設定を比較。費用の計算例とタスク評価を通じて選び方を解説します。

複雑で時間がかかり、ツールを連続して操作するタスクでは、まずGPT-6 Astraを評価しましょう。日常業務はTerraから始め、難度が高く予算が限られる場合はSolと比較し、ルールが明確な大量処理ではLunaを先に試すのが出発点です。

これは公式の位置付けに基づく選定の目安であり、すべてのタスクに共通する性能順位ではありません。最終的には、同じ仕事を完了する際の正確さ、所要時間、総費用を比較します。

情報の確認日は2026年9月10日です。OpenAI公式のモデル一覧、APIドキュメント、GPT-6 Astraの発表に基づいています。用途の割り当てと評価方法は実務上の提案であり、公式デモを当サイトの実測として扱ってはいません。

4モデルの位置付け

本記事では、テキスト、コード、ツール呼び出しを扱う汎用モデルに絞ります。画像生成、リアルタイム音声、文字起こしには専用モデルがあり、同じ汎用能力ランキングで比べるのは適切ではありません。

モデル 公式の位置付け 最初に試したいタスク 選定時の主な問い
GPT-6 Astra 最も難しいエンドツーエンドの仕事 複数ツールをまたぐ長時間タスク、複雑なデバッグ、調査と文書作成 失敗や人手による手直しを大幅に減らせるか
GPT-5.6 Sol 複雑な専門業務向けのフラッグシップ 難しいコーディング、複数制約の分析、確立したワークフロー Astraより低い費用で要件を満たせるか
GPT-5.6 Terra 知能と費用のバランス 日常的な開発、コンテンツ処理、中程度の複雑さのアシスタント 通常のリクエストの大半を処理できるか
GPT-5.6 Luna 費用重視の大量処理 分類、フィールド抽出、短い要約、形式変換 ルールが明確で、結果を検証しやすいか

公式では、迷った場合はAstra、能力と費用の両立にはTerra、大量処理にはLunaが推奨されています。上表の具体的な用途は、その位置付けに基づく提案です。出典:モデル一覧

開発者は、まずAstraでそのタスクが到達できる品質を確認し、同じ入力で低価格モデルと比較できます。安定稼働しているアプリケーションがある場合は、現行モデルを比較対象として残す方が有用です。

Sol・Terra・Lunaと従来の名称の関係

GPT-5.6ファミリーは、従来の製品区分を参考にすると理解しやすくなります。

  • Solは、おおむねminiやnanoの接尾辞がない従来の主力モデルに相当します。
  • Terraは、おおむね従来のminiクラスに相当します。
  • Lunaは、おおむね従来のnanoクラスに相当します。

これは位置付けの類比であり、旧モデルと挙動、料金、制限、品質が完全に同じという意味ではありません。

また、gpt-5.6はSolを指すエイリアスです。どのクラスを選んだか明確にするには、設定にgpt-5.6-solと書くと分かりやすくなります。出典:SolTerraLuna

Solと比べたGPT-6 Astraの注目点

Astraの発表では、コンピューター操作、長時間タスク、複雑なソフトウェア作業が重視されています。利用者が確かめたいのは、複数の手順を最後まで実行できるか、途中で新しい情報が入った際に方針を修正できるかです。

以下は発表から抜粋した比較データです。OpenAIが公開した評価であり、本記事で実行したテストではありません。

評価 Astra Sol
Terminal-Bench 4.0 57.9% 37.3% +20.6ポイント
社内データベース移行タスク 63.9% 42.7% +21.2ポイント
DeepSWE v1.1 74.1% 72.7% +1.4ポイント
GPQA Diamond 96.0% 94.6% +1.4ポイント
MRCR v2、512K–1M 96.3% 73.8% +22.5ポイント

改善幅はタスクによって大きく異なり、「あらゆる開発能力が2倍になった」とは言えません。発表では、各推論強度で得られた最高スコアを掲載し、評価環境は本番のChatGPTと異なる場合があると説明されています。出典:Astraの発表と評価注記

長時間タスクは工程全体で評価する

たとえばインポート失敗の修正には、ログの確認、解析コードの特定、実装変更、検証、影響を受けたデータの説明まで含まれることがあります。

最後の修正報告だけを比較しても、正しいファイルを見つけたか、既存の挙動を維持したか、実際に失敗した入力を見落としていないかは分かりません。

AstraとSolを比較する際は、タスク全体の実行履歴を残し、特に次を記録します。

  • 問題の原因を正しく特定したか。
  • 失敗後に対処方法を調整したか。
  • 必要な検証を完了したか。
  • 未完了の部分を正確に報告したか。

新しいAPI機能にはアプリ側の対応が必要

Astraのドキュメントには、非同期ツール呼び出し、作業中の追加指示、キャッシュ済みプレフィックスを維持したまま会話中に推論強度を変更する機能が記載されています。

非同期ツール呼び出しでは、ツールの応答を待つ間にモデルが独立した作業を進められます。ただし、ツール実行と未完了の呼び出しは引き続きアプリ側が管理します。作業中の追加指示はResponses APIのWebSocketフローを使うため、クライアントの対応も必要です。出典:Astra利用ガイド

テキストを1回送信して回答を待つだけのアプリが、Astraへ切り替えるだけで完全な非同期タスクシステムになるわけではありません。

最新API料金:4クラスの価格差

以下は確認時点のStandard・短コンテキスト料金で、単位は100万トークン当たりの米ドルです。入力をすべて同じ単価で計算しないよう、キャッシュ読み取りと書き込みを分けています。

モデル 通常入力 キャッシュ読み取り キャッシュ書き込み 出力
GPT-6 Astra $10.00 $1.00 $12.50 $50.00
GPT-5.6 Sol $4.00 $0.40 $5.00 $20.00
GPT-5.6 Terra $2.00 $0.20 $2.50 $12.00
GPT-5.6 Luna $0.20 $0.02 $0.25 $1.20

Solは現在プロモーション料金で、公式では少なくとも2026年11月21日まで提供するとしています。長期予算で恒久的な単価として扱うのは避けましょう。出典:API料金

通常入力と出力のトークン数が同じなら、Astraはどちらの単価もSolの2.5倍です。Terraは入力、出力ともにLunaの10倍です。

これは単価の比率にすぎません。モデルごとに推論量やツールとのやり取りが異なるため、実際のタスク費用は別途測定します。

同じトークン数での1リクエストの計算例

通常入力20,000トークン、課金対象の出力4,000トークンを使い、キャッシュ、ツール料金、地域追加料金、長コンテキスト割増がないと仮定します。

費用は「入力トークン数÷1,000,000×入力単価」と「出力トークン数÷1,000,000×出力単価」の合計です。原文の計算例をそのまま示します。

1
2
单次费用 = 输入 token / 1,000,000 × 输入单价
         + 输出 token / 1,000,000 × 输出单价
モデル 入力費用 出力費用 合計
Astra $0.2000 $0.2000 $0.4000
Sol $0.0800 $0.0800 $0.1600
Terra $0.0400 $0.0480 $0.0880
Luna $0.0040 $0.0048 $0.0088

これは料金表からの計算であり、実際の仕事を完了した際の実測費用ではありません。特に、課金対象の出力4,000トークンを、一定の長さの表示回答と同一視しないでください。

同じ使用量で1,000回実行すると、それぞれ400、160、88、8.8米ドルです。安いと言えるかは、結果のうち何件が合格するかにも左右されます。

Astraの追加費用に見合うかを判断する

あるタスクで、Solが1回0.16米ドル、Astraが0.40米ドルかかると仮定します。

この仮定の例では、Solが納品まで平均3回の完全な試行を要すると、モデル費用は0.48米ドルになります。Astraが1回で完了すれば、そのタスクでは安くなる可能性があります。

実際の再試行では入出力が変わることが多く、この例を固定の損益分岐点にはできません。最終成果の費用を比べるには、失敗、再試行、人手の修正を数える必要があるということです。

文章の形式変換では修正が少なく済む一方、複雑なコード障害ではトークン費用より人の調査時間が重要になる場合があります。同じ選定ルールを両方に適用する必要はありません。

100万トークンのコンテキストでも常に短コンテキスト料金とは限らない

4モデルの公式仕様ページには、次の容量が記載されています。

項目 Astra Sol / Terra / Luna
コンテキストウィンドウ 1,050,000トークン 1,050,000トークン
最大入力 922,000トークン 922,000トークン
最大出力 128,000トークン 128,000トークン
知識カットオフ 2026-04-30 2026-02-16
入力モダリティ テキスト、画像 テキスト、画像
出力モダリティ テキスト テキスト

出典:Astra仕様Sol仕様Terra仕様Luna仕様

これはAPIモデルの仕様であり、ChatGPTのすべてのプランや画面で同じ添付容量、会話枠を約束するものではありません。

ウィンドウ容量が同じでも、長文の理解品質が同じとは限りません。投入できる情報量と、その中の制約、例外、矛盾を正確に見つけられるかは、別々に確認する必要があります。

入力が272Kを超えた場合の料金

公式仕様では、入力が272Kトークンを超えるとリクエスト全体に長コンテキスト料金が適用されます。入力は短コンテキストの2倍、出力は1.5倍です。

したがって、しきい値を超えた部分だけに割増を適用する計算はできません。キャッシュにも対応する長コンテキスト料金を使います。出典:モデル仕様料金表全体

実際の設計では、まず次の3点を考えます。

  1. 資料全体を1回のリクエストに入れる必要があるか。
  2. 関連する章を先に検索し、出典とともに渡せるか。
  3. 分割すると重要な情報を失うような、章をまたぐ関係があるか。

全文入力、検索、分割処理はタスクの要件に合わせて選びます。入力削減によって根拠が欠ければ、後の手直しが増えることもあります。

画像入力と画像生成の違い

4つの汎用モデルはいずれも画像を受け取り、テキストを出力できます。スクリーンショットの読み取り、グラフ分析、画面レイアウトの説明などが例です。

仕様ページには画像生成ツールへの対応もありますが、これは該当ツールを呼び出せるという意味です。モデル自体の出力モダリティを「テキストと画像」としてよいわけではありません。

画像編集やリアルタイム音声を導入する際は、専用モデルの仕様と課金を確認し、本記事のテキスト費用例を流用しないようにします。

推論強度とFast modeは別々に選ぶ

推論強度は問題に投入する計算量に関わり、Fast modeはリクエスト処理のサービス区分です。1つの速度設定として混同しないようにします。

モデル APIドキュメントに記載されたreasoning.effort
Astra lowmediumhighxhighmax
Sol nonelowmediumhighxhighmax
Terra nonelowmediumhighxhighmax
Luna nonelowmediumhighxhighmax

GPT-5.6の3モデルでは、仕様ページに既定値がmediumと記載されています。Astraはnoneに対応しないため、旧設定から切り替える際は明示的に確認します。出典:Astra利用ガイドSol仕様Terra仕様Luna仕様

推論設定を明確にした比較条件を作り、一度に変える変数は1つにしましょう。モデル、推論強度、処理区分を同時に変えると、費用や時間の差を説明しにくくなります。

Fast modeが適する場面

現行の4モデルのFast料金は、対応するStandard料金の2倍です。AstraのEUデータレジデンシーのリクエストでは現在Fastを利用できず、AstraのFastにはレイテンシーSLAもありません。出典:料金ページAstra利用ガイド

利用者が重要な結果を待っているなら、Fastも評価対象にできます。バックグラウンドの仕事なら、まず通常処理と利用可能なバッチ処理を比較する方が合理的です。

ワークフロー全体が一定倍率で高速化するとは考えないでください。ページ読み込み、ダウンロード、外部サービスの応答にも時間がかかります。

実際の仕事に合わせて選ぶ

以下は最初の試験に使うための提案です。手元のサンプルで異なる結果が出たら、実際の結果に合わせて調整します。

執筆、翻訳、資料整理

構成が明確な初稿、要約、一般的な翻訳はTerraから試し、用語、抜け、文体を抜き取り確認できます。

資料が矛盾している、複数の出典を照合する必要がある、長い記事に多くの制約がある場合は、SolとAstraで同じ課題を比較します。

見出し抽出、分類ラベル付け、フィールド統一など、規則が決まった大量処理ではLunaを先に試す価値があります。

特に「文章が自然」と「根拠が正しい」は分けて評価します。流暢な表現は出典確認の代わりにはなりません。

開発、デバッグ、リポジトリ変更

小規模な関数修正、一般的なスクリプト、テストの説明では、まずTerraを評価できます。

複数ファイルの変更、複雑な依存関係、再現しにくい障害では、SolとAstraの成果全体を比較します。

テスト結果だけでなく、差分が要件を満たすか、無関係な変更がないか、実行していない検証を実行済みと主張していないかも確認します。

既存のSolワークフローが安定しているなら、過去の難しい課題でAstraを試してから、利用範囲を広げるか決めます。

ブラウザーとコンピューター操作

視覚認識、状態判断、連続操作を伴うことが多いため、Astraを早い段階で候補にできます。

評価時は初期ページと権限をそろえ、終了後の実際の状態を記録します。ファイルが保存されたか、表が更新されたか、結果を再び開けるかなどです。

「モデルが成功したと言った」だけでは完了と判定できません。ツール環境、アプリの権限、ページの変化も結果に影響します。

分類、抽出、バックグラウンドのバッチ処理

Lunaに明確なフィールド、少数の代表例、空値や異常入力の扱いを渡します。

形式や業務ルールの検証に通らなかった項目をTerraやSolで再確認する、試験的な振り分けも考えられます。

上位モデルへの切り替えは、フィールド不足、値の範囲の矛盾、根拠不足など、確認できるエラーを条件にします。モデル自身が示す確信度だけには頼らないようにします。

そのまま使えるモデル評価表

初回サンプルとして実際のタスクを20~50件用意すると、同じひっかけ問題を繰り返すより実務に近い評価になります。この件数は初期選別用であり、まれなエラーがなくなったと証明するには不十分です。

日常のリクエスト、過去の失敗例、少数の境界条件を含め、合格基準を先に書いておきます。

記録項目 記録する内容 目的
タスク番号 固定した入力と期待結果 比較を再現可能にする
モデルと推論強度 完全なモデルID、effort 設定差が結論に混ざるのを防ぐ
ツール環境 利用可能ツール、権限、初期状態 外部条件をそろえる
初回合格 すぐに要件を満たしたか 手直しの必要性を測る
総所要時間 開始から成果を渡せるまで ツールや再試行の待ち時間を含める
トークン使用量 入力、出力、キャッシュ読み書き 費用差を説明する
実際の費用 適用料金による合計 タスク全体の費用を比べる
人の介入 回数と所要時間 隠れた利用費用を把握する
失敗の種類 事実、形式、ツール、抜けなど モデル変更か工程改善かを判断する

タスク別の合否確認

  • フィールド抽出:人が付けた正解ラベルと照合し、欠落と誤りを別々に数えます。
  • 翻訳:否定、数値、単位、固有名詞、段落の抜けを確認します。
  • コード変更:実際の差分を読み、変更に関係する検証を実行します。
  • 資料調査:引用を開き、対応する結論を出典が裏付けるか確認します。
  • コンピューター操作:対象アプリやファイルの最終状態を再取得します。

モデルに確認を補助させる場合も、人による抜き取り確認を残します。回答を生成するモデルと評価するモデルが、似た盲点を持つ可能性があります。

結果の読み取り方

Lunaが日常タスクの大半に合格し、少数の複雑な種類に誤りが集中するなら、タスク分類による振り分けを検討できます。

TerraとSolの品質が近くても、Solがツール作業を速く終えるなら、入力単価だけでなく総時間と費用を比較します。

Astraが少数の価値の高い難題でのみ優れている場合でも、その難題に限定して使うのは合理的です。

4モデルとも同じ箇所で失敗するなら、まず入力資料、ツールの応答、合格基準を見直します。モデルを上げても、欠けたデータが補えるとは限りません。

GPT-5.6からAstraへ切り替える際のAPI確認

以下は認証とクライアントコードを省いた、最小のResponses APIリクエスト本文です。モデル名と推論フィールドを示す例であり、当サイトで実行した呼び出し記録ではありません。原文の中国語プロンプトは、添付案の制約、費用、未解決事項を比較するよう求めています。

1
2
3
4
5
6
7
{
  "model": "gpt-6-astra",
  "reasoning": {
    "effort": "medium"
  },
  "input": "请比较所附方案的约束、成本和未解决问题。"
}

GPT-5.6を使っていたアプリでは、次の互換性も確認します。

  1. 既存の推論強度がnoneまたはminimalなら、Astraが対応するlowで比較を始めます。
  2. Astraが対応しないtemperaturetop_ptop_logprobsを削除します。
  3. ツール呼び出しにはResponses APIを使います。AstraがChat Completionsに対応することは、そこでツール呼び出しも使えることを意味しません。
  4. Chat Completionsではlogprobsを確認して削除し、Responsesではinclude内のmessage.output_text.logprobsを確認します。
  5. EUデータレジデンシーのリクエストはStandardとし、FastやPriorityの設定が残っていないか調べます。

以上は公式の移行ガイドに明記された項目です。複雑なアプリでは、キャッシュ、会話状態、ツール実行方式に応じた互換性も確認します。出典:Astra移行ガイド

移行中は既存モデルを選べる設定を残し、まず同じ合格判定用サンプルを実行します。テキストが返ることは基本的な呼び出しの成功を示すだけで、業務品質の達成までは証明しません。

ChatGPT・Codex・APIの違い

モデル名は使うモデルを表し、ChatGPT、Codex、APIは利用経路です。各経路のツール、コンテキスト管理、権限、課金方法が体験に影響します。

Astraの発表では、対象の有料ChatGPTプラン、APIなどへ段階的に提供すると説明されています。企業ワークスペースでは公開当初は既定で無効で、管理者による有効化が必要です。自分のアカウントで利用できるかは、モデル選択画面や組織の権限を確認してください。出典:Astraの発表

そのため、本記事のAPI料金表をChatGPTプランの送信可能メッセージ数へ直接換算することはできません。Codex画面のすべての設定がAPIパラメーターと1対1で対応するとも限りません。

比較結果を報告するときは、モデル名だけでなく、利用経路、ツール、推論強度を書いた方が再現しやすくなります。

よくある質問

Astra登場後もSolを使う意味はありますか?

引き続き比較する価値があります。Solは現在の単価が低く、既存アプリがすでにSolで検証済みの場合もあります。切り替えるかは、自分のタスクでAstraが誤り、納品時間、手直し費用を減らせるかによります。

Lunaが安いのは、簡単な会話しかできないからですか?

そうとは言えません。公式では費用重視の大量処理向けとされ、推論やツールにも対応しています。制約が明確か、出力が安定して検証に通るかで判断する方が適切です。

コンテキスト容量が同じなのに、なぜ料金が大きく違うのですか?

コンテキストウィンドウは容量の仕様です。選定には推論品質、ツール実行能力、費用も関係するため、容量だけから同等の能力とは判断できません。

すべてのリクエストでmaxを既定にすべきですか?

まず評価しましょう。単純なフィールド抽出と複雑なデバッグでは必要な計算量が異なります。推論強度を上げたことで検証可能な改善があるか確認します。

GPT-5.5やGPT-5.4は、もう検討しなくてよいのでしょうか?

既存アプリでは引き続き比較対象になり得ます。本記事は現行の主要汎用4モデルを扱っています。安定した旧ワークフローは、同じサンプルで比較してから移行します。

最終的にはどう選べばよいですか?

最低限必要な品質を決め、合格したタスクの費用を比較します。タスクごとに別のモデルを使えるようにし、料金、モデルの挙動、業務データが変わったら再びサンプル評価します。

公式参考資料