GPT-6 Sol/Lunaとは？Astraとの違い・料金・使い分け｜中小企業はどれを選ぶ？【2026年9月】
結論｜GPT-6では「一番強いモデル」ではなく、仕事ごとの役割分担で選ぶ
GPT-6 SolとGPT-6 Lunaは、2026年9月22日にOpenAIが発表したGPT-6ファミリーのモデルです。結論から言えば、すべての業務をAstraへ寄せる必要も、安いLunaへ寄せる必要もありません。OpenAI自身が、Astraは最も難しいエンドツーエンド業務、Solは判断を伴う日常業務やコーディング、Lunaは範囲が明確で高頻度な処理という使い分けを案内しています。中小企業では「業務の難しさ」「実行頻度」「失敗したときの手戻りコスト」で振り分けるのが実務的です。
また、GPT-5.6にもSol/Lunaという同名モデルがありますが、GPT-6とは別世代です。特にGPT-5.6ではSolがフラッグシップ、Terraが性能とコストのバランス役でした。GPT-6ではAstraが最上位に入り、Solの役割が「能力とコストのバランス」に寄っています。名前だけで新旧を判断しないことが重要です。
この記事で分かること
GPT-6 Astra / Sol / Lunaの違いと、どの業務に向くか
GPT-5.6 Sol / Terra / Lunaとの名前・役割の違い
2026年9月23日時点のAPI料金と、長文・Fast modeなどで単価が変わる条件
ChatGPT、Work、Codex、APIでの提供状況をどう読み分けるか
GPT-5.6から今すぐ切り替えるべき場合と、WAITした方がよい場合
HSビルが実際に確認できた範囲と、まだ検証していないこと
確認日：2026年9月23日。料金・提供状況・モデル仕様は更新される可能性があるため、契約・本番実装前にはOpenAI公式ページで再確認してください。
Astra・Sol・Lunaはどう選ぶ？まず見る判断表
モデル | OpenAIの位置付け | HSでの最初の候補 | 向いている仕事 | まずWAITするケース |
GPT-6 Astra | 最も難しいエンドツーエンド業務 | 難所・高リスク工程 | 曖昧な要件、複数ツール、高い完成度が必要な成果物 | Solで十分な定型業務、単価差を吸収できない大量処理 |
GPT-6 Sol | 複雑なcoding・agentic workflow／能力とコストのバランス | 日常の標準候補 | コーディング、調査、分析、判断を伴う業務フロー | 既存5.6で安定稼働中なのに評価なしで一括移行 |
GPT-6 Luna | focused・high-volume向けの高効率モデル | 大量処理の候補 | 分類、抽出、定型要約、明確な指示で繰り返す処理 | 失敗コストが高い最終判断、曖昧な要件の一発完成 |
この表の「HSでの最初の候補」はOpenAIの保証ではなく、公式のモデル位置付けを業務設計へ翻訳したHSの編集判断です。最終的には同じ入力・同じ評価基準で自社タスクを比較し、最も軽い設定で品質基準を満たすモデルを残すのが安全です。
GPT-6 Sol/Lunaとは何か｜9月22日にGPT-6ファミリーが3モデルへ
OpenAIは9月22日、GPT-6 SolとGPT-6 Lunaを発表しました。現行のモデルカタログでは、GPT-6 Astra・Sol・Lunaの3モデルがフラッグシップ系として案内されています。Astraは「最も高性能で最難関の仕事」、Solは「複雑なコーディングとエージェント型ワークフロー」、Lunaは「範囲が明確で高頻度な仕事」に向けたモデルです。
ここで重要なのは、3モデルが単純な「松・竹・梅」ではないことです。価格差は大きい一方、OpenAIのModel selectionでは、Lunaにもreasoning effortを上げた使い方、Solにもlowからxhighまでの使い分けが示されています。つまり、モデル名だけでなく「モデル × reasoning effort × 業務」の組み合わせで考える必要があります。
GPT-5.6と同じSol/Lunaでも役割は同じではない
世代 | 上位／高難度 | バランス | 高頻度・低コスト |
GPT-5.6 | Sol：複雑な専門業務のフラッグシップ | Terra：知能とコストのバランス | Luna：コスト重視の大量処理 |
GPT-6 | Astra：最難関のエンドツーエンド業務 | Sol：能力とコストを両立する日常の高性能枠 | Luna：focused・high-volume向け |
GPT-5.6では「Sol＝最上位」と覚えていた人ほど混乱しやすいポイントです。GPT-6ではAstraが最上位に入り、Solは日常の高性能モデルという位置付けになりました。一方でLunaは、5.6でも6でも高頻度・コスト重視という方向性が比較的一貫しています。
したがって、社内マニュアルやAPI設定で「Sol」とだけ書く運用は避けた方が安全です。少なくとも「GPT-5.6 Sol」「GPT-6 Sol」のように世代まで明記し、APIではモデルIDを固定して管理します。
GPT-6 Astra / Sol / Lunaの主要仕様
項目 | Astra | Sol | Luna |
モデルID | gpt-6-astra | gpt-6-sol | gpt-6-luna |
コンテキスト | 1,050,000 | 1,050,000 | 1,050,000 |
最大出力 | 128,000 | 128,000 | 128,000 |
knowledge cutoff | 2026-04-30 | 2026-04-20 | 2026-05-18 |
reasoning effort | low / medium / high / xhigh / max | none / low / medium / high / xhigh / max | none / low / medium / high / xhigh / max |
公式の主用途 | 最難関のend-to-end work | complex coding / agentic workflows | focused / high-volume tasks |
コンテキスト長と最大出力だけを見ると3モデルは共通です。そのため「105万トークンだからAstra相当」とは判断できません。違いは能力・価格・想定用途・reasoning設定にあり、実務では完成品質と再試行回数まで見て選ぶ必要があります。
SolとLunaはreasoning effortにnoneを選べます。OpenAIは、Responses APIでbuilt-in toolsやfunction callingを使うことを案内しており、Chat Completionsでfunction callingを使う場合はreasoning_effort=noneに限られると説明しています。既存APIをモデル名だけ差し替える場合は、ここが移行時の確認点です。
料金比較｜「SolはAstraの5分の1」だけで判断しない
OpenAIのStandard料金で、入力が272Kトークン以下の短いコンテキストを使う場合、100万トークンあたりの価格は次の通りです。
モデル | 入力 | cached input | cache write | 出力 |
GPT-6 Astra | $10.00 | $1.00 | $12.50 | $50.00 |
GPT-6 Sol | $2.00 | $0.20 | $2.50 | $10.00 |
GPT-6 Luna | $0.10 | $0.01 | $0.125 | $0.50 |
単価だけならSolはAstraの約5分の1、LunaはSolよりさらに大幅に安価です。ただし、APIコストは「トークン単価 × 1回」で終わりません。品質不足で再実行する回数、人が直す時間、失敗時の影響まで含めると、最安モデルが最安運用になるとは限りません。
また、入力が272Kトークンを超えるプロンプトでは、リクエスト全体について入力・キャッシュ関連の料金が2倍、出力料金が1.5倍になります。BatchとFlexはStandardの50%、Fast modeは適用料金の2倍です。EUデータレジデンシーはSol/LunaではStandardのみ対応し、対象のregional processingには10%の上乗せがあります。APIを使う会社は、モデル価格だけでなく処理条件まで見て見積もる必要があります。
OpenAIはGPT-6 Sol/Lunaについて、GPT-5.6のプロモーション価格と比べAPI価格を50%引き下げたと説明しています。これはOpenAIの料金比較であり、HSの請求実績から算出した削減率ではありません。
ChatGPTでは使える？Work・Codex・APIを分けて確認する
利用面 | 2026-09-22発表時点の公式案内 | 判断 |
ChatGPT Work | Plus / Pro / Business / Enterprise / Eduへ提供開始 | 対象でも段階ロールアウト。表示を実画面で確認 |
Codex | Plus / Pro / Business / Enterprise / Eduへ提供開始 | 同上。model pickerや実行環境を確認 |
Free / Go | Lunaをdesktop app経由で提供 | 通常Chatと同一視しない |
通常のChat | 発表時点では未提供 | 記事確認日にも公式発表はこの表記。UIの最新状態を確認 |
OpenAI API | gpt-6-sol / gpt-6-lunaで利用可能 | 本番移行前に同条件evalを実施 |
「ChatGPTで使えるか」という質問は、通常Chat、Work、Codex、デスクトップアプリ、APIを分けないと答えを誤ります。OpenAIの9月22日発表ページを9月23日に確認した時点では、Sol/LunaはWorkとCodex、APIを中心に展開され、通常Chatにはまだ提供されていないと記載されています。段階的ロールアウトのため、実際の表示はアカウントや時点で変わる可能性があります。
無料・Goで足りる？有料側を検討する？
GPT-6 Sol/Lunaを理由に、すぐ有料プランへ上げる必要はありません。OpenAIの9月22日発表では、FreeとGoはGPT-6 Lunaをデスクトップアプリ経由で試せる一方、GPT-6 Sol/LunaのWork・Codex提供はPlus、Pro、Business、Enterprise、Eduが対象です。したがって「何を使いたいか」で判断します。
利用目的 | まずの判断 | 理由 |
通常のチャット・軽い質問が中心 | 今のプランを維持してWAITも合理的 | Sol/Lunaは発表時点で通常Chat未提供。使えない機能のためだけに契約を変えない |
Free / GoでLunaを試したい | デスクトップアプリで適合確認 | 対象サーフェスで実際に使えるか確認してから判断 |
Codex / WorkでSol・Lunaを使いたい | 対象の有料プランを確認 | モデル利用面と契約を一致させる必要がある |
APIで業務処理を組む | ChatGPTプランではなくAPI要件で判断 | API料金・tool calling・eval・権限設計が主要論点 |
つまり「GPT-6が出たからPlus以上へ」という判断ではなく、「通常Chatで十分か」「Work/Codexが必要か」「APIとして組み込むのか」を先に分けます。モデル追加より、使うサーフェスと業務を明確にする方が無駄な契約を減らせます。
業務別の使い分け｜HSでは「失敗コスト」で振り分ける
モデル選択を「一番賢いモデルはどれか」で始めると、コスト過多か品質不足のどちらかに寄りやすくなります。HSでは、業務を①頻度、②要件の明確さ、③失敗したときの手戻り、④人の確認コストで分ける考え方を採ります。
業務例 | 最初に試す候補 | 理由 | Human Gate |
大量の分類・タグ付け・形式変換 | Luna | 条件が明確で反復回数が多い | サンプル監査＋異常値確認 |
定型資料の要約・情報抽出 | Luna→不足時Sol | 合格基準を定義しやすい | 数字・固有名詞を確認 |
日常の調査・分析・文章のたたき台 | Sol | 判断と網羅性のバランスが必要 | 出典・事実・最終表現を確認 |
コード修正・テスト・エージェント処理 | Sol→難所Astra | 公式にSolはcomplex coding / agentic向け | 実行権限・テスト・差分レビュー |
複数システムをまたぐ高難度業務 | Astra | 失敗時の再作業や影響が大きい | 実行前承認＋完了後レビュー |
外部公開・契約・請求など高リスク最終判断 | Astraでも人間承認必須 | モデル能力より責任分界が重要 | 人間が最終決定 |
これはモデルの永久固定表ではありません。Lunaで品質基準を満たすならLunaを残し、満たさないときだけSolへ上げる。Solで不足する難所だけAstraへ上げる。こうした「段階昇格」にすると、品質とコストの両方を管理しやすくなります。
すでに複数の有料AIを契約している方へ：「どれを残すか」を3分で整理する無料AI選定診断。モデルを増やす前に、重複している契約と用途を整理しておくと判断しやすくなります。
HSの一次観察｜まだSol/Lunaの性能比較はしていない
HSでは2026年9月23日、既存のChatGPT/Codex環境でGPT-6 Sol/Lunaの利用可否を確認しました。その時点のHSアカウント／サーフェスではgpt-6-sol / gpt-6-lunaが明示的に露出せず、モデル名を指定した呼び出しも当該サーフェス上では非対応の応答でした。
この観察から言えるのは「HSが確認したその環境では、まだ比較テストを実行できなかった」ということだけです。OpenAI全体で使えない、他のPlus/Pro利用者にも出ていない、性能が低い、という意味ではありません。段階的ロールアウトと整合する範囲のアカウント固有観察です。
そのため本記事では、Sol・Luna・Astraの性能順位や速度差をHS独自の実測として断定しません。OpenAIが公表するベンチマークは「OpenAIの評価」として扱い、HSの一次経験と混ぜない方針です。利用可能になった後に比較する場合も、同じ入力・同じreasoning effort・同じツール条件・同じ評価基準を固定して判定します。
OpenAIのベンチマークはどう読むべきか
OpenAIは発表資料で、GPT-6 Sol/Lunaが専門業務、coding、computer use、安全性などで前世代から改善したと説明しています。たとえばOSWorld 2.0 offlineでは、Solを高いreasoning effortで実行した結果を他社モデルや旧モデルと比較し、コスト当たり性能の優位性を訴求しています。
ただし、OpenAI自身も評価環境と実際のChatGPTではsystem promptやtoolsが異なり、出力が変わる可能性があると注記しています。ベンチマークはモデル候補を絞る材料にはなりますが、自社の請求書処理、記事制作、コード修正、顧客対応で同じ結果になる保証ではありません。
GPT-5.6から乗り換えるべき？GO / WAITの判断
状況 | 判定 | 理由 |
新規にOpenAI APIの標準モデルを選ぶ | GO候補 | Sol/Lunaを新世代候補として同条件評価する価値がある |
既存GPT-5.6処理で品質・コスト基準を満たしている | WAIT寄り | 新しいという理由だけの移行は手戻りを増やす |
大量処理のAPIコストが課題 | Lunaを検証 | 単価差が大きく、明確な合格基準を作りやすい |
coding / agentic workflowのコストが課題 | Solを検証 | 公式の主用途と一致。既存evalを再実行する |
最難関タスクの失敗コストが高い | Astraも比較 | 単価ではなく合格率・再試行・人手まで見る |
通常Chatだけを使い、Sol/Lunaが画面に出ていない | WAIT | 使えないサーフェスの比較を先にしても実務効果がない |
API移行時にtool callingを使う | 要検証 | Responses APIやreasoning設定の差分を確認してから本番変更 |
最も避けたいのは、既存処理が安定しているのに「GPT-6だから」という理由だけでモデルIDを一括置換することです。移行前後で同じ代表タスクを流し、品質、再試行、処理時間、人間の修正量、API料金を比較してから切り替えます。
コストは「1Mトークン単価」ではなく、合格した仕事1件あたりで見る
API料金表は重要ですが、経営判断では「合格した成果物1件を作る総コスト」に直した方が実態に近づきます。たとえば安いモデルで3回やり直し、人が20分修正するなら、高いモデルで1回通る方が安い可能性があります。逆に、単純な分類を大量に流すならAstraの高い能力を使う必要はありません。
モデル料金：入力・出力・キャッシュ・ツール利用
再試行コスト：失敗や品質不足で何回やり直すか
人間確認コスト：事実確認、修正、承認に何分かかるか
障害コスト：誤送信、誤更新、顧客影響が起きた場合の損失
移行コスト：prompt、tool calling、eval、権限設計を変更する工数
HSのAI組織でも、モデルの単価だけでなくFirst Pass、Human Intervention、Rework、Cost per Successful Jobのような指標で見る設計を採っています。新モデル導入の目的は「最新モデルを使うこと」ではなく、同じ業務をより少ない手戻りと適正コストで終わらせることです。
モデルを上げる前にreasoning effortも調整する
GPT-6 SolとLunaはreasoning effortをnone、low、medium、high、xhigh、maxから選べ、既定はmediumです。OpenAIは、低いeffortは速度とトークン使用量を抑え、高いeffortはより完全な推論に向くと説明しています。つまりコスト調整は「LunaかSolか」だけではありません。
たとえばSol mediumで安定している仕事を、毎回Astraへ上げる必要はありません。逆にLuna noneで取りこぼしが出る業務では、Lunaのeffortを上げる、Solへ上げる、Human Gateを増やす、という順序で比較できます。モデルとeffortを同時に変えると原因が分からなくなるため、検証時は一度に1つだけ変えます。
状況 | 最初に試す調整 | 注意 |
明確な定型処理で速度・コスト優先 | Luna none / low候補 | 品質基準を満たすかサンプル監査 |
日常の判断・coding | Sol mediumを基準候補 | 既定値をbaselineとして記録 |
難しいケースだけ品質不足 | 同モデルのeffortを上げて比較 | モデル変更と同時に変えない |
高effortでも手戻りが大きい | 上位モデルを比較 | 合格率と人間修正時間まで測る |
今すぐGPT-6 Sol/Lunaへ切り替えなくてよいケース
現在のGPT-5.6ワークフローが安定し、品質・コスト・納期の基準を満たしている
通常Chatしか使わず、利用したいモデルがまだ自分の画面に提供されていない
代表タスクと合格基準を用意できておらず、比較しても『なんとなく良い』で終わる
本番データや顧客接点へ直接接続するのに、Human Gateやrollback手順がない
長大な入力が多く、272K超の料金条件を見ずに短文単価だけで予算を組んでいる
APIのtool callingやResponses移行の差分を確認していない
複数AIを契約しているが、そもそも用途が重複しており、モデル追加より契約整理が先
「新しくて安いなら、すぐ移行」が危ない理由
GPT-6 Sol/Lunaは価格面で魅力があります。それでも「新しい・安い・公式ベンチマークが良い」だけで一括移行するのは早計です。モデル変更では、回答品質だけでなく、プロンプトへの反応、ツール呼び出し、reasoning設定、出力量、キャッシュ、エラー時の挙動まで変わる可能性があります。
反対に、慎重になりすぎて新モデルを一切試さないのも合理的ではありません。特に大量処理や日常的なcodingでは、単価差が積み上がるため、同条件evalを小さく回す価値があります。結論は「全面移行する／しない」ではなく、「代表タスクだけで比較し、合格したルートから置き換える」です。
導入手順｜最小コストでAstra・Sol・Lunaを決める7ステップ
対象業務を1つだけ選ぶ。まず『大量の分類』『日常のcoding』『高難度の最終成果物』のように仕事を具体化する。
合格基準を決める。正確性、形式遵守、必要な出典、実行成功、修正時間などを先に固定する。
現在使っているGPT-5.6または他モデルをbaselineとして保存する。
Luna→Sol→Astraの順ではなく、業務に合う候補2つ程度を同じ入力・同じツール条件で比較する。
API料金だけでなく、再試行回数・人間修正時間・失敗時の影響を記録する。
品質基準を満たす最も軽いモデルを既定にし、難しいケースだけ上位へ昇格させる。
本番反映後もモデル名・reasoning effort・tool条件を記録し、更新時に再現できるようにする。
この手順なら、Astraを全件に使う過剰コストと、Lunaへ寄せすぎて修正が増える状態の両方を避けやすくなります。
中小企業向けの最小構成｜まず3モデル全部を契約・固定しなくてよい
中小企業で重要なのは、モデルの数を増やすことではなく、業務ごとの入口を少なくすることです。OpenAI APIを使うなら、日常の標準候補をSol、定型大量処理をLuna、難所だけAstraへ昇格する構成から検証できます。一方、ChatGPTを人が直接使うだけなら、画面で利用できるモデルとプランの範囲で十分です。
また、ClaudeやGeminiをすでに契約している場合は、GPT-6を追加する前に重複用途を確認してください。文章、検索、coding、画像、Google Workspace連携などを全社で重複契約すると、モデル単価を下げてもSaaS月額と運用負荷が増えることがあります。
すでに複数の有料AIを契約している方へ：「どれを残すか」を3分で整理する無料AI選定診断。新モデルへの乗り換え前に、現在の契約・用途・重複支出を確認できます。
よくある質問
Q1. GPT-6 SolとGPT-5.6 Solは同じモデルですか？
いいえ。別世代のモデルです。APIモデルIDもgpt-6-solとgpt-5.6-solで異なります。GPT-5.6ではSolがフラッグシップでしたが、GPT-6ではAstraが最上位に加わり、Solは能力とコストのバランスを重視する位置付けになっています。
Q2. GPT-6 SolとLunaはどちらを選べばよいですか？
判断を伴う日常業務、coding、agentic workflowではSolを候補にし、範囲が明確で高頻度な分類・抽出・定型処理ではLunaを候補にします。ただし実際の品質は自社タスクで同条件比較してください。
Q3. GPT-6 Astraは高いので使わなくてよいですか？
一律には言えません。失敗時の手戻りが大きい難題や、複数工程をまたぐ成果物ではAstraの高い能力が総コストを下げる可能性があります。逆に定型大量処理へAstraを常用する必要性は低くなります。
Q4. GPT-6 Sol/LunaはChatGPTの通常画面で使えますか？
OpenAIの2026年9月22日発表ページを9月23日に確認した時点では、WorkとCodex、APIを中心に提供され、通常Chatにはまだ提供されていないと記載されています。段階的ロールアウトのため、実際のモデルpickerは自分のアカウントで確認してください。
Q5. GPT-5.6から自動的にGPT-6へ移行すべきですか？
いいえ。既存業務が安定しているなら、代表タスクを同条件で再評価してから切り替える方が安全です。モデル名の新しさだけで本番ルートを変更しないことをおすすめします。
Q6. HSではSol/Lunaの性能を実測しましたか？
2026年9月23日時点では、HSの対象Codex環境でモデルを固定した比較を実行できていないため、独自の性能ランキングや速度比較は掲載していません。利用可能性を確認した観察と、OpenAI公式情報を分けて記載しています。
公式一次情報・参考資料
2026-09-23確認：OpenAI｜Introducing GPT-6 Sol and Luna
2026-09-23確認：OpenAI API｜Models
2026-09-23確認：OpenAI API｜GPT-6 Sol
2026-09-23確認：OpenAI API｜GPT-6 Luna
2026-09-23確認：OpenAI API｜GPT-6 Astra
2026-09-23確認：OpenAI API｜Pricing
2026-09-23確認：OpenAI API｜Changelog
2026-09-23確認：OpenAI API｜Model selection
関連記事
HSビル・ワーキングスペース 基本情報
項目 | 内容 |
施設名 | HSビル・ワーキングスペース |
運営会社 | FULMiRA Japan 合同会社 |
代表者 | 三宅 悠生 |
所在地 | 奈良県奈良市西大寺北町1丁目2-4 ハッピースクールビル |
事業者住所 | 〒631-0817 奈良県奈良市西大寺北町1-2-4 HSビル1階 |
最寄駅 | 近鉄「大和西大寺駅」北口 徒歩4分 |
営業時間 | 8:00〜23:00 / 年中無休 |
電話番号 | 0742-51-7830 |
メール | hsbuild.m@gmail.com |
公式サイト | https://www.hsworking.com/ |
主なサービス | コワーキングスペース、個室ブース、貸し会議室、バーチャルオフィス、AI活用・AI導入支援 |
HSビル・ワーキングスペースは、奈良・大和西大寺エリアで物理スペースを運営しながら、自社業務でAI・SEO/AIO・Wix・LINE導線の実運用を行っています。
筆者プロフィール
筆者：HSビル AIメディア編集部
HSビル AIメディア編集部は、HSビル・ワーキングスペースのAI活用、SEO/AIO、Wix導線改善、LINE予約・相談導線、コワーキング・貸し会議室・バーチャルオフィス運営の実務経験をもとに、中小企業・個人事業主向けにAI活用と業務整理の記事を作成しています。
記事では、単なるAIツール紹介ではなく、実際の業務に落とし込むための役割分担、コスト管理、人間確認の範囲、検索データ、相談・申込導線まで含めて整理します。
三宅 悠生
FULMiRA Japan 合同会社代表。HSビル・ワーキングスペースを運営し、施設運営・Web集客・AI組織運用を自社実務に組み込んでいます。AIを単なるツール追加ではなく、業務ごとの役割分担と成果につなげる運用として実践・発信しています。
コメント