結論から言うと、GPT-6 Solは「複雑なコーディングや複数ステップのエージェント処理を、Astraより費用を抑えて任せたい人」、GPT-6 Lunaは「分類・抽出・定型文生成など、焦点の定まった処理を大量に回したい人」に向くモデルです。APIの標準料金は100万トークン当たり、Solが入力2ドル・出力10ドル、Lunaが入力0.10ドル・出力0.50ドル。入出力ともLunaはSolの20分の1です。ただし、安いモデルを選べば必ず総費用が下がるわけではありません。難しい処理でやり直しが増えるなら、最初からSolを使う方が結果的に安くなる場合があります。
OpenAIは2026年9月22日、GPT-6ファミリーにSolとLunaを追加しました。両モデルはChatGPT WorkとCodexでPlus、Pro、Business、Enterprise、Eduの利用者向けに順次提供され、FreeとGoではデスクトップアプリからLunaを利用できます。APIではそれぞれgpt-6-sol、gpt-6-lunaとして提供されています。発表直後は段階的な展開のため、対象プランでもモデル一覧にすぐ表示されない可能性があります。
この記事では、公式発表とAPIモデルページを基に、GPT-6 SolとLunaの違い、料金、性能、Astraとの関係、ChatGPT・Codex・APIでの使い方を整理します。さらに、一般的な比較記事だけでは判断しにくい「1回の処理で実際に何ドルかかるのか」「どの段階でLunaからSolへ切り替えるべきか」を、条件を明示した試算と判断表で解説します。情報は2026年9月23日確認時点です。
GPT-6 SolとLunaの違いを一目で比較
まず、選択に必要な違いを表にまとめます。文脈長や最大出力は共通ですが、設計上の中心用途と料金が大きく異なります。
| 比較項目 | GPT-6 Sol | GPT-6 Luna |
|---|---|---|
| 公式の位置付け | 複雑なコーディングとエージェント型ワークフロー向け | 焦点の定まった大量処理向けの高効率モデル |
| API入力料金 | 100万トークン当たり2ドル | 100万トークン当たり0.10ドル |
| API出力料金 | 100万トークン当たり10ドル | 100万トークン当たり0.50ドル |
| キャッシュ済み入力 | 100万トークン当たり0.20ドル | 100万トークン当たり0.01ドル |
| コンテキストウィンドウ | 1,050,000トークン | 1,050,000トークン |
| 最大出力 | 128,000トークン | 128,000トークン |
| 知識カットオフ | 2026年4月20日 | 2026年5月18日 |
| 推論強度 | none、low、medium、high、xhigh、max | none、low、medium、high、xhigh、max |
| 向く仕事 | 難しい実装、長い調査、複数ツールをまたぐ自動化、レビュー | 分類、抽出、要約、定型変換、一次判定、大量の短い処理 |
| 判断の軸 | 失敗コストや修正コストが高いか | 処理件数が多く、正解条件が明確か |
重要なのは、Lunaが単なる「短文用」、Solが単なる「長文用」ではない点です。両方とも大きなコンテキストを扱えます。差が出るのは、資料の量そのものより、資料を基に何段階の判断をさせるか、曖昧な依頼をどこまで自律的に解釈させるか、失敗したときに人がどれだけ修正しなければならないかです。
GPT-6 Solとは何か
GPT-6 Solは、OpenAIが「複雑なコーディングとエージェント型ワークフローを支えるためのモデル」と説明するGPT-6の中核モデルです。難しいコード変更、複数アプリをまたぐ作業、長い手順を保持しながら進める処理など、単発の回答よりも「作業を最後まで成立させること」が重要な場面を中心に設計されています。
Solが得意とする仕事
具体的には、大規模なコードベースから関連ファイルを探し、影響範囲を判断し、実装してテストまで行う仕事が代表例です。業務面では、複数のデータソースを調べ、条件に従って表を更新し、結果を検証するようなワークフローも該当します。途中の判断が後続工程に影響し、誤りを早い段階で見つけなければ手戻りが大きくなる仕事ほどSolの価値が出やすくなります。
ただし「Solなら確認不要」という意味ではありません。AIモデルの出力には誤りがあり得ます。特に契約、医療、財務、セキュリティ、公開前のコード変更では、人間の承認、テスト、一次資料の確認を残す必要があります。Solを選ぶ目的は責任をAIへ移すことではなく、複雑な作業で発生する調査と反復の効率を上げることです。
Solの価格とGPT-5.6 Solからの変化
標準API料金は、入力100万トークン当たり2ドル、出力100万トークン当たり10ドルです。OpenAIの発表では、GPT-5.6 Solのプロモーション料金である入力4ドル、出力20ドルから50%引き下げられました。キャッシュ済み入力は0.20ドルで、通常入力の10%です。
出力単価は入力単価の5倍なので、費用を抑えるには不要に長い回答を出させないことが重要です。「必要な項目だけJSONで返す」「変更点と検証結果だけを報告する」「説明文は300字以内」といった出力条件は、読みやすさだけでなくコスト管理にも効きます。一方、短くし過ぎて根拠や検証結果が消えると、後で人が確認する負担が増えます。削るべきなのは必要な情報ではなく、重複や定型的な前置きです。
GPT-6 Lunaとは何か
GPT-6 Lunaは、OpenAIが「焦点の定まった大量処理に最も効率的なモデル」と位置付けるモデルです。入力と出力の形式が決まっており、同じ種類の処理を数百件、数千件と繰り返す用途で、低い単価が大きな差になります。
Lunaが得意とする仕事
問い合わせのカテゴリ分け、商品説明から属性を抽出する処理、会議メモを決められた項目に整理する処理、短い文章の言い換え、検索候補の一次選別などが向いています。判定基準を例とともに明示でき、出力を機械的に検証できる仕事なら、Lunaを最初に試す価値があります。
たとえば「問い合わせ本文から、製品名、緊急度、返金希望の有無をJSONで返す」という処理は、目的と出力形式が明確です。これに対し「顧客の過去履歴、契約条件、在庫、社内規程を確認して最適な解決策を実行する」は、参照先と判断段階が増えます。後者はSolから検討する方が安全です。
Lunaは安いが、用途を限定することが前提
Lunaの標準API料金は、入力100万トークン当たり0.10ドル、出力100万トークン当たり0.50ドルです。Solの20分の1であり、大量処理では強い魅力があります。キャッシュ済み入力は0.01ドルです。
一方で、曖昧な仕様を解釈しながら長い計画を立てる、複数の例外を同時に処理する、失敗時に自分で原因を切り分ける、といった仕事ではLunaの安さだけを見ない方がよいでしょう。1回の単価が20分の1でも、誤分類を人が全件確認したり、失敗した処理を何度も再実行したりすれば、総費用と所要時間は増えます。
SolとLunaのAPI料金を実際の仕事量で試算
API料金は「100万トークン当たり」と表示されるため、小規模な処理でいくらになるか直感的に分かりにくいことがあります。標準処理、キャッシュなし、ツール利用料や地域処理の追加料金なしという条件で試算します。為替換算はレートが変動するため行わず、ドルで比較します。
基本式は、入力トークン数÷100万×入力単価+出力トークン数÷100万×出力単価です。
| 処理例 | 入力/出力 | Sol | Luna | 差額 |
|---|---|---|---|---|
| 短い分類を1,000件 | 合計100万/10万 | 3.00ドル | 0.15ドル | 2.85ドル |
| 資料を基に報告書を1回作成 | 10万/2万 | 0.40ドル | 0.02ドル | 0.38ドル |
| 月間の中規模バッチ | 1,000万/200万 | 40.00ドル | 2.00ドル | 38.00ドル |
| 入出力各100万 | 100万/100万 | 12.00ドル | 0.60ドル | 11.40ドル |
試算1:問い合わせ1,000件を分類する
1件平均1,000トークンの入力と100トークンの出力を想定すると、1,000件で入力100万、出力10万トークンです。Solは入力2ドル、出力1ドルで合計3ドル。Lunaは入力0.10ドル、出力0.05ドルで合計0.15ドルです。分類ルールが明確で、一定割合を人が抜き取り検査できるなら、Lunaの費用優位が生きます。
ただし、緊急度の誤判定が重大事故につながる場合は、単価だけで決められません。Lunaで一次分類し、高リスク候補や確信度が低いケースだけSolまたは人へ回す二段階構成が現実的です。すべてをSolで処理するか、すべてをLunaで処理するかという二択にしないことが、品質と費用を両立するポイントです。
試算2:10万トークンの資料から2万トークンを出力する
Solは入力0.20ドル、出力0.20ドルで合計0.40ドルです。Lunaは入力0.01ドル、出力0.01ドルで合計0.02ドルです。この20倍差は大きく見えますが、報告書の誤りを担当者が修正する時間の方が高くつくケースがあります。定型の抜粋や要約ならLuna、複数資料の矛盾を解きほぐしながら提案まで作るならSol、というように成果物の難しさで分けます。
長大な入力では料金倍率に注意
公式モデルページでは、272,000トークンを超える入力を含むリクエストは、そのリクエスト全体について入力とキャッシュ料金が2倍、出力料金が1.5倍になると案内されています。両モデルに共通する重要な条件です。105万トークンのコンテキストを使えることと、常に通常単価で使えることは同じではありません。
長い資料を何でも1回のプロンプトへ入れるのではなく、検索で関連部分を絞る、章ごとに構造化する、変わらない前提をキャッシュ対象にする、といった設計が必要です。特に反復型のエージェントでは、毎回同じ仕様書を通常入力として送り直すと費用が積み上がります。
Batch、Flex、Fast、地域処理の違い
モデルページでは、BatchとFlexは標準料金の50%、Fastは該当料金の2倍、利用可能な地域処理には10%の上乗せがあるとされています。急がない大量処理はBatchやFlexを検討でき、応答速度を優先する処理はFastの追加費用と時間短縮の価値を比較します。EUデータレジデンシーはStandard処理のみ利用可能とされているため、料金だけで処理方式を選べない場合もあります。
ここでの試算はテキストトークンだけです。検索やコンピュータ操作など、ツール固有の料金が発生するモデル・機能では別費用が加わる可能性があります。請求を予測するときは、モデルのトークン単価、推論で増える出力、ツール呼び出し、再試行、長文入力の倍率を分けて記録すると原因を追いやすくなります。
GPT-6 Astra・Sol・Lunaはどう使い分けるか
OpenAIはAstraを「全体として最良のモデル」と位置付け、妥協せず最良の結果を求める場合に選ぶよう案内しています。したがって、モデル階層は「Solが最上位、Lunaが廉価版」ではありません。品質最優先のAstra、複雑な作業と費用のバランスを取るSol、大量処理の効率を優先するLunaという三つの軸で考えるのが分かりやすいでしょう。
| 状況 | 最初に試す候補 | 理由 |
|---|---|---|
| 重要な経営判断や難度の高い研究支援 | Astra | 品質を最優先し、妥協を避けたい |
| 大規模コード変更とテスト | Sol | 複雑なコーディングと長い作業工程が中心 |
| 複数アプリをまたぐ業務自動化 | Sol | 途中判断とツール操作の連鎖がある |
| 問い合わせや文書の大量分類 | Luna | 正解条件と出力形式を固定しやすい |
| 大量の項目抽出やデータ整形 | Luna | 件数が多く、機械的な検証が可能 |
| 品質条件がまだ曖昧な新規業務 | Solで基準作り | まず成功例と失敗例を集め、その後Lunaを評価できる |
Astraの特徴を先に確認したい場合は、LUMARION MediaのGPT-6 Astraの特徴と使い方の解説も参考になります。今回の記事は、Astraの概要を繰り返すのではなく、SolとLunaの実務上の選択に焦点を絞っています。
性能表はどう読めばよいか
OpenAIは発表で、業務自動化、コーディング、コンピュータ操作、事実性に関する評価結果を示しています。ただし、ベンチマークの数字だけで自社の結果を予測することはできません。推論強度、ツール、システム指示、対象データ、採点条件が違えば結果も変わるからです。
業務自動化ではSolが費用対効果を示した
47のツールを使う業務ワークフローの評価AutomationBenchでは、Solのxhighが33.2%、1タスク当たり0.27ドルでした。Astraのlowは30.3%で、費用はSolの3.9倍。比較対象のClaude Opus 5のmaxは26.9%、費用はSolの11.1倍と報告されています。
ここから読み取れるのは、特定の評価条件ではSolが高い費用対効果を示したことです。「Solがあらゆる業務でAstraより優れる」と一般化してはいけません。Astraはlow、Solはxhighであり、推論強度が同じではありません。また、ベンチマークは典型的な社内手順、独自ツール、例外処理をそのまま再現するものではありません。
コーディングではSolとLunaの距離が意外に近い
実際のコードベースで複雑なソフトウェア工学タスクを評価するDeepSWE v1.1では、Solのmaxが68.8%、Lunaのmaxが66.6%と報告されました。Lunaは比較対象のOpus 5より1タスク当たり93%、Fable 5より96%低い費用だったと説明されています。
この結果は、Lunaを単純作業専用と決めつける必要がないことを示します。ただし、2.2ポイントの差が実務で小さいとは限りません。失敗1件の修正に数時間かかる大規模変更では、成功率の差が運用費へ強く効きます。逆に、独立した小さな修正を大量に作り、自動テストで失敗を除外できるなら、Lunaの低単価が有利になります。
コンピュータ操作でも「価格込み」で見る
OSWorld 2.0のオフライン評価では、Solのxhighが60.5%で、比較対象のOpus 5 mediumの60.3%に近く、1タスク当たり費用は約80%低いと報告されています。LunaのmaxはGPT-5.6 Sol mediumを上回り、費用は10分の1とされています。
コンピュータ操作では、画面の変化、権限、確認ダイアログ、外部サービスの障害など、評価環境と本番環境の差が大きくなります。重要な操作の前に確認を挟む、変更対象を限定する、操作ログを残す、失敗時に安全に停止する仕組みが必要です。モデルの点数は、権限設計や監査を省略する理由にはなりません。
事実性の改善にも条件がある
OpenAIの内部評価では、Solは前世代と比べて誤りが約半分になり、Lunaも高い推論強度ではGPT-5.6 Solと同程度の事実性を約100分の1の費用で示したと説明されています。ただし、この評価は過去に利用者が誤りを指摘した匿名化会話を基にしており、通常の利用全体を代表するものではありません。文章がもっともらしいことと、出典で確認できることは別です。
最新ニュース、価格、法令、人物の役職、サービス提供条件などは、モデルの知識カットオフ後に変わります。Solの知識カットオフは2026年4月20日、Lunaは2026年5月18日です。より新しい日付だからLunaの方が常に正確という意味でもありません。変化する情報は検索や社内データベースを使い、回答内に確認日と出典を残す設計が必要です。
105万トークンのコンテキストで何が変わるか
SolとLunaはいずれも1,050,000トークンのコンテキストウィンドウと、128,000トークンの最大出力を持ちます。大量の資料、長い会話、コードベースの多くの部分を一つの処理に含められる余地があります。ただし、収まることと、必要な箇所を正確に使えることは別問題です。
長い資料を全部入れる前に検索設計を考える
100万トークン近い入力を毎回送ると、料金倍率だけでなく、不要情報による判断のぶれ、応答時間、検証の難しさも増えます。規程集であれば、質問に関連する章を検索してからモデルへ渡す方が、安く、根拠も追いやすくなります。大きな文脈は「絞り込みが不要」という機能ではなく、「必要なときに広い範囲を参照できる」余裕として使うのが安全です。
キャッシュを使うと反復処理の費用を抑えられる
両モデルのキャッシュ済み入力単価は通常入力の10%です。共通のシステム指示、固定された仕様書、長い会話の変わらない前半などを再利用できれば、反復処理の入力費用を抑えられます。OpenAIはGPT-6で、推論強度やツールの有効・無効を変えても、それ以前の文脈のキャッシュを維持しやすくしたと説明しています。
ただし、キャッシュは自動的にすべての費用を9割減らす保証ではありません。入力の先頭部分が一致するか、保持条件を満たすか、どの部分が再利用されたかを計測する必要があります。Prompt Caching Dashboardや診断機能でヒット率を見て、固定部分を前に、案件ごとの可変部分を後ろに置く設計を検討します。
reasoning.effortはどこまで上げるべきか
SolとLunaは、none、low、medium、high、xhigh、maxの推論強度をサポートし、既定値はmediumです。難しい問題ほど高くすればよいように見えますが、推論強度を上げると時間やトークン消費が増える可能性があります。常にmaxへ固定するのではなく、失敗率と費用を測って決めます。
推論強度の現実的な決め方
- まずmediumで、実際の入力から代表的な50〜100件を評価する。
- 正解、不正解、判断不能を、人が確認できる基準で採点する。
- 不正解のうち、推論強度を上げれば改善しそうな例と、入力不足や仕様矛盾による例を分ける。
- highまたはxhighで再評価し、精度向上と費用増を比較する。
- 難しいケースだけ高い強度へ回すルーティングを検討する。
データが足りない問題は、推論強度を上げても解決しません。顧客の契約種別が入力に含まれていないのに返金可否を判定させる、といった設計ミスが典型です。モデル変更の前に、必要情報、正解基準、例外、失敗時の扱いを確認する方が効果的な場合があります。
APIの機能呼び出しで注意する点
公式モデルページでは、組み込みツールと関数呼び出しにはResponses APIを使うよう案内されています。Chat Completionsで関数呼び出しを使えるのは、推論強度をnoneにした場合のみです。既存システムをChat Completionsのまま移行する場合、モデル名だけを変えると意図した推論設定とツール利用を両立できない可能性があります。
複数ツールを使うエージェントへ移行するなら、APIの選択、タイムアウト、再試行、冪等性、承認が必要な操作を先に設計します。特に送信、購入、削除、公開のような外部状態を変える操作は、モデルの性能に関係なく、明示的な許可と確認を置くべきです。
ChatGPT Work・Codex・APIでの提供範囲
2026年9月22日の公式発表では、SolとLunaはChatGPT WorkとCodexでPlus、Pro、Business、Enterprise、Eduの利用者向けに提供開始とされています。FreeとGoの利用者はデスクトップアプリでLunaを利用できます。発表時点では通常のChatにはまだ提供されておらず、当日中に段階的に展開する計画と説明されています。
そのため、同じプランでも地域、アプリ、アカウント、展開状況によって表示時期がずれる可能性があります。モデルが見つからないときは、対象プランか、ChatGPT WorkまたはCodexを開いているか、アプリが更新されているかを確認し、少し時間を置きます。APIではモデルIDを直接指定できますが、組織の利用制限や権限も確認してください。
ChatGPTの月額料金とAPI料金は別
100万トークン当たりの価格はOpenAI APIの従量料金です。ChatGPT Plusなどの月額契約に、その金額が直接加算されるという意味ではありません。ChatGPTやCodexの利用枠、クレジット、モデル選択条件は各製品・プランの規則に従います。記事やSNSで「Lunaは0.10ドルだからChatGPTもその値段」と説明されていたら、API単価とサブスクリプションを混同していないか確認が必要です。
APIではモデルIDを明示する
APIでのモデル名はgpt-6-solとgpt-6-lunaです。運用では、コード全体へモデル名を直書きせず、設定ファイルや環境変数で切り替えられるようにしておくと比較が容易です。入力と採点条件をそろえ、モデル名、推論強度、処理時間、入力・出力トークン、エラー、再試行回数をログへ残します。
用途別:どちらを選ぶべきか
文章作成と編集
定型の商品説明、見出し候補、既存文の表記統一を大量に作るならLunaから試します。複数の一次資料を突き合わせ、矛盾を解消し、読者別の構成を組み立てる長文記事はSolが候補です。ただし、公開物ではどちらを使っても出典確認と編集が必要です。文章の自然さだけで事実性を判断しないようにします。
プログラミング
大規模な機能追加、複数ファイルのリファクタリング、再現しにくい不具合調査、テスト設計はSolが適しています。独立した小さな変換、型定義の生成、単純なテストケース作成、コード分類を大量に行うならLunaも有力です。Lunaで生成し、自動テストに合格しない案件だけSolへ送る構成も考えられます。
カスタマーサポート
問い合わせの分類、言語判定、固有項目の抽出はLunaが向きます。複数の契約条件を調べて個別の解決策を作る、感情的な顧客に配慮しながら例外判断を行う、返金やアカウント変更を伴う処理はSolまたは人の承認を組み合わせます。顧客へ自動送信する前に、禁止表現、個人情報、根拠のない約束を検査します。
社内検索と文書分析
文書へのタグ付け、日付や担当者の抽出、重複候補の検出はLuna向きです。複数規程の優先関係を整理する、例外条項を含めて対応案を作る、根拠となる箇所を示しながら意思決定を支援する場合はSolを検討します。重要な判断では、回答だけでなく参照した文書名、版、ページ、確認日を返すようにします。
エージェントとコンピュータ操作
画面を操作し、途中結果に応じて次の手順を変え、最終状態を確認する仕事はSolが基本候補です。Lunaは、操作手順が短く、分岐が少なく、失敗を自動検出できる大量処理で試せます。どちらの場合も、支払い、外部送信、公開、削除は承認を挟み、操作対象の範囲を制限します。
最も実用的なのは二段階ルーティング
多くの現場で費用対効果が高いのは、一つのモデルへ全件を固定する方法ではありません。Lunaで安く一次処理し、難しい案件だけSolへ回す二段階構成です。さらに重要度が高い少数案件をAstraまたは人へ送れば、品質と費用を段階的に管理できます。
ルーティング条件の例
- 必要項目が欠けている場合はSolまたは人へ送る。
- 複数の規程が競合する場合はSolへ送る。
- 返金、契約変更、公開、削除を伴う場合は人の承認を必須にする。
- 出力形式の検証に失敗した場合は、1回だけ再試行してからSolへ送る。
- Lunaの回答に根拠となる箇所がない場合は処理を完了扱いにしない。
モデル自身に「難しいかどうか」を自己申告させるだけでは不十分です。入力の長さ、参照資料数、例外条件、ツール数、検証エラーなど、外側から観測できる条件を使います。誤りが重大な領域では、人間が無作為抽出して正解率を継続的に確認します。
三つの導入パターンで考える
小規模なコンテンツ制作では、Lunaにタイトル候補、要点抽出、表記統一を任せ、Solに構成の矛盾確認と最終編集案を任せる方法があります。Lunaの生成物を無条件に連結するのではなく、参照元URL、確認日、未確認事項を共通の形式で渡すと、Solが検証すべき箇所を把握しやすくなります。公開前の事実確認は人が行います。
ECの商品データ整備では、Lunaで商品名、型番、色、容量などを抽出し、JSON Schemaで形式を検証します。必須項目が欠ける、単位が矛盾する、説明文と価格表で型番が異なるといった案件だけSolへ回します。画像だけで断定できない材質や、原文にない効能を補完させないルールも必要です。処理件数が多いため、Lunaの単価差と自動検証が組み合わさると効果が大きくなります。
ソフトウェア開発では、Solを主担当としてリポジトリ調査、実装計画、複数ファイル変更、テストを行わせ、Lunaを補助的な静的分類やログ整理に使えます。逆に、小さく独立した修正が大量にある場合は、Lunaで候補を作り、自動テストとレビューを通過しないものだけSolへ送ります。どちらの構成でも、保護ブランチ、テスト、差分レビューを外さないことが前提です。
切り替え基準は運用後も更新する
開始時に決めたルーティング条件は固定しません。LunaからSolへ送られた案件のうち、実際にはLunaで十分だった割合、Solでも失敗した割合、人が修正した時間を月ごとに確認します。Lunaで安定して処理できる種類が見つかれば対象を広げ、重大な誤りが続く種類はSolまたは人へ戻します。
また、同じ「失敗」でも原因を分けます。出力形式の崩れはスキーマや再試行で直せるかもしれません。根拠資料が不足しているならモデル変更では直りません。長い作業の途中で目的を見失うなら、工程を分割したり中間状態を保存したりする設計が必要です。モデルの選択を、プロンプトやシステム設計の問題を覆い隠す手段にしないことが大切です。
20倍安いLunaは、何回失敗しても得なのか
トークン単価だけなら、同じ入出力量でLunaはSolの20分の1です。しかし、単純に「19回やり直しても同額」とは言えません。再試行ごとに入力や会話履歴が増え、人の確認時間や待ち時間も発生するためです。誤った出力が後工程へ流れた場合、回収や修正の費用はAPI料金を大きく上回ります。
判断には、AI利用料+人の確認時間+失敗の修正費+待ち時間による損失を使います。正答率だけでなく「重大な誤り率」「人が直す平均時間」「再試行率」を計測すると、Solへ上げる境界が見えます。
導入前に行う比較テスト
一般的なベンチマークより、自社の実データに近い評価セットが重要です。個人情報や機密情報の取り扱い条件を確認した上で、過去案件から難易度の異なる例を集めます。成功例だけでなく、曖昧な入力、情報不足、矛盾、禁止操作を含む例も入れます。
- 成功条件を決める:正確さ、形式、根拠、所要時間、費用を数値化する。
- 入力を固定する:SolとLunaへ同じ資料、同じ指示、同じツールを与える。
- 推論強度をそろえる:まずmedium同士で比較し、必要に応じて別設定を試す。
- 盲検で採点する:可能なら評価者にモデル名を見せず、出力だけを判定する。
- 総費用を記録する:トークン料金だけでなく、再試行と人の修正時間を含める。
- 失敗を分類する:モデル能力、入力不足、ツール障害、仕様矛盾を分ける。
- 段階導入する:影響の小さい処理から始め、監視できる範囲で件数を増やす。
50件で99%に見えても、標本が小さく、重大な例外を含まなければ本番性能は分かりません。件数だけでなく、業務上重要なパターンを網羅することが大切です。モデル更新で挙動が変わる可能性もあるため、評価セットと採点基準を保存し、変更時に再実行できるようにします。
GPT-5.6から移行するときのチェックリスト
- モデルIDを設定で切り替えられるようにする。
- 同じ実データで旧モデルと新モデルを比較する。
- 入力・出力トークン、キャッシュヒット、再試行を記録する。
- 272,000トークン超の料金倍率を予算へ反映する。
- Chat CompletionsとResponses APIの機能差を確認する。
- 推論強度を既定のmediumから機械的にmaxへ変えない。
- ツール操作の権限、承認、停止条件を再確認する。
- 最新情報を扱う処理では検索・参照元・確認日を出力させる。
- 個人情報、機密情報、保存地域の要件を確認する。
- 品質低下時に旧モデルへ戻せる手順を用意する。
価格が半額になっても、移行直後から予算が必ず半分になるわけではありません。モデルの回答量、推論設定、処理件数が変われば使用トークンも変わります。新しい用途を増やすことで総額が上がる場合もあります。1件当たり費用と月間総額を分けて監視してください。
注意点:比較で誤解しやすい5つのポイント
1.LunaはSolの20分の1だが、能力も20分の1ではない
価格差をそのまま能力差と考えることはできません。公式評価では、Lunaが一部の難しいコーディングやコンピュータ操作で前世代の上位モデルに迫る結果も示されています。用途が合えば非常に高い費用対効果を得られます。
2.コンテキスト長が同じでも、同じ仕事に向くとは限らない
両モデルとも105万トークンを扱えますが、長い資料の中から複数の矛盾を解消し、計画を立て、ツールで実行する仕事と、長い一覧から項目を抽出する仕事では難しさが違います。入力の長さより、判断の連鎖と失敗コストを見ます。
3.ベンチマークの最高設定は普段の既定値ではない
発表に出るxhighやmaxの結果を、既定のmediumでそのまま再現できるとは限りません。推論強度が高いほど処理時間や費用が増える可能性があります。比較するときはモデル名だけでなく、推論強度も記録します。
4.知識カットオフは最新情報の保証ではない
Lunaの知識カットオフはSolより約1か月新しいものの、2026年5月18日以降の出来事はモデル内部の知識だけでは確認できません。それ以前の情報でも誤る可能性があります。変化する情報は公式サイトや信頼できるデータ源へ接続します。
5.提供開始日と自分の画面に出る日はずれる
公式発表は2026年9月22日ですが、段階展開と明記されています。対象プランでも一時的に表示されない可能性があります。表示されないことを理由に、非公式の拡張機能へ認証情報を渡したり、アクセス制御を回避したりしないでください。
よくある質問
GPT-6 SolとLunaでは、結局どちらが高性能ですか?
複雑なコーディングやエージェント処理ではSolが基本候補です。Lunaは大量の焦点を絞った処理で効率を重視するモデルです。単純な順位ではなく、仕事の複雑さ、件数、失敗時の影響で選びます。最高品質を妥協なく求める場合、OpenAIはAstraを推奨しています。
個人のChatGPT利用でもAPI料金がかかりますか?
ChatGPTのサブスクリプションとAPI従量課金は別です。この記事の入力2ドル、0.10ドルといった数値はAPIの100万トークン当たり料金です。ChatGPT内の利用条件や上限は、契約プランと画面上の案内を確認してください。
無料ユーザーはSolを使えますか?
2026年9月22日の発表では、FreeとGoはデスクトップアプリでLunaを利用できるとされています。Solについて同様の案内はありません。有料プランでも段階展開のため、表示まで時間がかかる場合があります。
Lunaで長文記事やコードを書けますか?
最大出力はSolと同じ128,000トークンなので、仕様上は長い出力が可能です。ただし、長く出せることと、複雑な構成や変更を高い精度で完遂できることは別です。定型構成の大量生成ならLuna、複数資料を統合する難しい記事や大規模コード変更ならSolから比較します。
SolとLunaを同じシステムで併用できますか?
可能です。むしろ、Lunaで一次処理し、例外や難しい案件をSolへ送る構成が有力です。モデルを切り替えても評価できるよう、入力形式、出力スキーマ、ログ、失敗時の経路を共通化します。
料金を最も下げる方法は何ですか?
単にLunaへ変えるだけでなく、不要な入力を減らす、出力形式を絞る、固定部分をキャッシュする、急がない処理にBatchやFlexを使う、再試行の原因を直すことが重要です。272,000トークンを超える長い入力には料金倍率がかかるため、検索や分割も検討します。
まとめ:迷ったら仕事の複雑さと失敗コストで決める
GPT-6 SolとLunaの最も大きな違いは、Solが複雑なコーディングとエージェント型ワークフロー、Lunaが焦点の定まった大量処理を中心に設計されていることです。API料金はSolが入力2ドル・出力10ドル、Lunaが入力0.10ドル・出力0.50ドルで、Lunaは20分の1です。両方とも105万トークンのコンテキストと12.8万トークンの最大出力を備えます。
選び方は、まずLunaで安く試し、難しいものだけSolへ送ればよい、で終わりません。誤りを検出できるか、修正に何分かかるか、外部へ影響する操作があるかを含めて考えます。品質最優先の少数案件にはAstra、複雑な作業にはSol、検証可能な大量処理にはLunaという役割分担が基本です。
導入時は、実際の案件から評価セットを作り、同じ条件でSolとLunaを比較してください。トークン料金、再試行、人の修正時間、重大な誤り率まで記録すれば、価格表だけでは見えない自分の業務に合った境界を決められます。
公式情報
- OpenAI「Introducing GPT-6 Sol and Luna」(2026年9月22日発表、2026年9月23日確認)
- OpenAI API「GPT-6 Sol Model」(2026年9月23日確認)
- OpenAI API「GPT-6 Luna Model」(2026年9月23日確認)


コメント