GPT-6 Sol・Lunaが登場｜API料金・Codex対応・SE実務での使い分けを整理【2026年9月】

AIニュース解説

OpenAIは2026年9月22日、GPT-6ファミリーにGPT-6 SolとGPT-6 Lunaを追加しました。9月25日時点では、両モデルはOpenAI APIに加え、ChatGPT WorkとCodexで展開されています。通常のChatGPT会話とは別のモデルとして提供されており、Free・GoユーザーはデスクトップアプリからGPT-6 Lunaへアクセスできます。

今回の変更でSEや開発チームが注目したいのは、単純な「新モデルの性能向上」だけではありません。GPT-6 Solは複雑なコーディングやエージェント処理を担当しやすい価格帯へ、GPT-6 Lunaは大量の定型処理や一次判定へ組み込みやすい価格帯へ下がりました。さらに、長時間動くAIエージェントを意識したプロンプトキャッシュの改善も同時に進んでいます。

つまりGPT-6 Sol・Lunaは、モデル単体の強さを見るよりも、「どの処理をどのモデルへ振り分けるか」「再利用できるコンテキストをどうキャッシュするか」まで含めて考えると実務上の意味が見えやすくなります。

この記事では、2026年9月25日時点のOpenAI公式情報を基に、API料金、提供範囲、コーディング性能、長文入力、プロンプトキャッシュ、SE実務での使い分けを整理します。実際の業務への導入前には、自社のコードや仕様書、ログ、テストケースで評価することを前提にしてください。

GPT-6 Sol・Lunaで変わったことを先に整理

OpenAIの公式モデルガイドでは、GPT-6ファミリーはAstra・Sol・Lunaの3モデルで構成されています。Astraは最も難しい複合タスク向け、Solは知能とコストのバランス、Lunaはコストを抑えた大量処理向けという位置付けです。

モデル 主な位置付け 入力料金 / 100万トークン 出力料金 / 100万トークン コンテキスト 最大出力
GPT-6 Astra 最難関の複合タスク $10 $50 約105万 128K
GPT-6 Sol 複雑なコーディング・エージェント $2 $10 約105万 128K
GPT-6 Luna 定型・大量処理 $0.10 $0.50 約105万 128K

OpenAIはSolとLunaについて、GPT-5.6のプロモーション価格と比べてAPI価格を大きく引き下げたと説明しています。現行のAPIカタログでは、Solが入力$2・出力$10、Lunaが入力$0.10・出力$0.50です。キャッシュ済み入力はSolが$0.20、Lunaが$0.01となっています。

この価格差は、AIエージェントを一日に数回試す程度なら大きく感じないかもしれません。しかし、コード検索、ログ解析、問い合わせ分類、仕様書の整理などを大量に回すと、モデル選択の差がそのまま月額コストへ積み上がります。

以前のGPT-5.6ではSol・Terra・Lunaの3層構成でしたが、GPT-6ではAstra・Sol・Lunaという構成になっています。GPT-5.6の整理は「GPT-5.6は何が変わった？Sol・Terra・Lunaの違いとSE実務での使い分け」で扱っています。今回の記事では、旧世代のモデル比較を繰り返すのではなく、GPT-6で価格性能比とエージェント運用がどう変わるかに絞ります。

GPT-6 Solは「難しい仕事を常時Astraへ送らない」ためのモデル

GPT-6 Solは、OpenAIが「complex coding and agentic workflows」向けとして案内しているモデルです。設計レビュー、複数ファイルにまたがる修正、既存コードの調査、ツールを何度も呼び出すエージェント処理など、単発の文章生成よりも長い手順を必要とする仕事が中心になります。

公式発表では、ソフトウェア開発タスクを評価するDeepSWE v1.1で、GPT-6 Solは最大推論設定で68.8%を記録しています。また、実際のコードベースで「マージできる変更」を評価するFrontierCodeでも、GPT-5.6 Solからの改善が示されています。

ただし、こうしたベンチマークをそのまま「自社開発でも68.8%成功する」と読むのは危険です。OpenAI自身も、評価は研究環境またはAPIで行われ、実際のChatGPT製品ではシステムプロンプトや利用可能なツールが異なるため、出力が変わる可能性があると説明しています。

SE実務で見るなら、Solを使う候補は「一度の失敗で手戻りが大きい仕事」です。たとえば、障害原因の調査、複数モジュールをまたぐリファクタリング、既存仕様を読みながらの改修、テスト計画まで含む変更、複数の外部ツールを使う調査などです。

逆に、短いSQLの整形、定型メールの分類、ログ行のラベル付け、決まった形式への変換までSolへ固定すると、必要以上にコストを使う可能性があります。高性能モデルを常用するより、失敗コストの高い処理だけSolへ上げる設計の方が現実的です。

GPT-6 Lunaは大量処理の「最初の一手」に使いやすい

GPT-6 Lunaは、OpenAIが「focused, high-volume tasks」向けとする効率重視モデルです。入力100万トークンあたり$0.10、出力$0.50という料金は、エージェントや業務ツールから大量に呼び出す用途で意味を持ちます。

たとえば問い合わせの分類、ログの一次要約、エラー種別のタグ付け、CSVの項目補正、監視アラートの一次整理、検索結果の前処理などは、いきなり最上位モデルへ送る必要がないケースがあります。Lunaで処理し、判定が難しいケースだけSolへエスカレーションする構成なら、処理量が増えてもコストを管理しやすくなります。

公式のDeepSWE v1.1では、GPT-6 Lunaも最大推論設定で66.6%と報告されています。低価格モデルだから単純作業しかできない、という位置付けではありません。ただし、これもベンチマーク上の結果であり、自社コードでの品質を保証するものではありません。

実務では、Lunaを「安いから全部任せる」モデルにするより、品質を自動判定しやすい処理から使う方が安全です。JSONの形式チェック、既知カテゴリへの分類、ルールで検証できるデータ変換など、出力が正しいかプログラム側で判定できる仕事は導入しやすい領域です。

一方、最終的な設計判断、顧客向けの重要文書、セキュリティ上の判断、業務ルールの例外処理などは、人間の確認や上位モデルへの切り替えを残した方がよいでしょう。低コスト化は重要ですが、誤りを見つけにくい仕事ほどチェック工程が必要です。

ChatGPTではどこで使える？9月25日時点の提供範囲

2026年9月25日時点で、GPT-6 SolとGPT-6 LunaはChatGPT WorkとCodex向けのモデルとして案内されています。OpenAI Help Centerでは、通常のChatGPT会話で使うモデルとは分けて説明されています。

Plus、Pro、Business、Enterprise、Eduでは、WorkとCodexでGPT-6 Sol・Lunaが展開されています。ただし、実際に表示されるモデルや推論レベルは、契約プラン、ワークスペース設定、ロールアウト状況によって異なります。Free・Goユーザーは、デスクトップアプリからGPT-6 Lunaへアクセスできます。

ここは初心者が混同しやすい点です。「GPT-6 Solが発表された＝通常のChatGPTのモデル選択で必ずSolを選べる」という意味ではありません。9月25日時点の公式ヘルプでは、Work・Codex向けであることが明記されています。

Codexを開発で使っている場合は、モデルピッカーの設定も確認したいところです。Codexは手動で選択したモデルを保持します。新モデルが追加されても、既存セッションやデスクトップ環境が自動で切り替わるとは限りません。

既存のCodex運用やAgents APIとの役割分担については、「OpenAI Agents APIとは？Codexの仕組みをAPIから使う方法・料金・導入前の注意点」も合わせて確認すると、モデル選択とエージェント基盤を分けて整理しやすくなります。

API料金は単価だけでなく「長文入力」とキャッシュまで見る

GPT-6 Sol・LunaのAPI単価は魅力的ですが、見積もりで見落としやすいのが長文入力の料金です。OpenAIのモデルページでは、272K入力トークンを超えるプロンプトについて、リクエスト全体の入力・キャッシュ料金が2倍、出力料金が1.5倍になると案内されています。

約105万トークンのコンテキストウィンドウがあるからといって、毎回リポジトリ全体や大量の設計書をそのまま送る設計が安いとは限りません。長い入力は便利ですが、必要な情報だけを検索して渡す設計、古い会話を要約する設計、RAGで関連資料を絞る設計は引き続き重要です。

たとえば、毎回20万トークンの共通仕様書とツール定義を送るエージェントがあるとします。そこへユーザーごとの入力を追加するだけなら、共通部分をキャッシュで再利用できる可能性があります。一方、毎回ツール定義の順序やシステム指示を細かく変えると、キャッシュが効きにくくなります。

APIコストを管理するときは、「モデルの入力単価 × トークン数」だけでは不十分です。少なくとも、入力トークン、出力トークン、キャッシュ済み入力、キャッシュ書き込み、272Kを超える長文入力、再試行回数まで分けて見る必要があります。

特にAIエージェントは、一つの依頼で複数回APIを呼ぶため、ユーザーから見える一往復より内部の呼び出し回数が多くなります。月額の予算を考えるときは「1チャットの料金」ではなく「1タスク完了までの総コスト」で比較した方が実態に近くなります。

GPT-6のプロンプトキャッシュ改善は長時間エージェントで効く

今回のGPT-6では、モデル価格だけでなくプロンプトキャッシュの改善も重要です。OpenAIは、同じ命令やツール定義、過去の文脈を何度も引き継ぐ長時間エージェントを想定し、共有プレフィックスの再利用を強化しています。

公式説明では、キャッシュ済み入力トークンは通常入力から最大90%の割引が適用されます。GPT-6 Solなら通常入力$2に対してキャッシュ済み入力$0.20、Lunaなら$0.10に対して$0.01です。キャッシュへの書き込みは通常入力の1.25倍で課金されます。

また、GPT-6では対象となる共通プレフィックスを30分のウィンドウで再利用でき、Prompt Caching Dashboardでキャッシュ率を確認できます。想定外のキャッシュミスが起きた場合は、診断ツールでモデル、ツール、設定、入力のどこが変わったかを確認できるようになりました。

SE目線では、これは「キャッシュを使えば安くなる」というだけでなく、プロンプト設計を運用対象として監視できるようになった点が大きいです。ツール定義を毎回並べ替える、共通ルールをリクエストごとに書き換える、固定資料を先頭ではなくバラバラに挿入するといった設計は、キャッシュ効率を落とす原因になります。

さらに、GPT-6では会話途中でreasoning effortを変更しても、適切な方法を使えばそれまでのキャッシュを壊さずに再利用できます。簡単な追質問では推論量を下げ、難しい判断だけ上げる運用がしやすくなりました。

長時間動くコーディングエージェントや社内ナレッジエージェントでは、モデル変更だけでなく、共通プロンプト、ツール定義、参照資料の配置を整理してから移行した方が、GPT-6の価格メリットを引き出しやすくなります。

SE実務ではSolとLunaをどう使い分けるか

実務での使い分けは、仕事内容ではなく「失敗したときの影響」と「検証しやすさ」で決めると整理しやすくなります。

業務例 最初に試す候補 理由
ログの一次分類・タグ付け Luna 大量処理しやすく、正解ルールを作りやすい
FAQ・問い合わせのカテゴリ分け Luna 高頻度処理でコスト差が効きやすい
SQL・テストケースの初稿 LunaまたはSol 難易度に応じて切り替えやすい
複数ファイルの改修 Sol 長い文脈と複数ステップの判断が必要
障害原因の調査 Sol 誤判断の手戻りが大きい
大規模リファクタリング Sol 依存関係・テスト・影響範囲の確認が必要
最終的な設計判断 Sol＋人間確認 説明責任や業務固有ルールが絡む

たとえば障害対応で、すべてをSolへ送る必要はありません。大量ログの一次抽出や類似エラーのグルーピングをLunaに任せ、原因候補の整理や修正方針の検討だけSolへ渡す構成が考えられます。

逆に、最初からLunaへ難しい障害解析を丸投げし、何度も失敗して再試行するなら、結果的にSolを一度使うより時間も料金も増える可能性があります。安いモデルを使うことと、タスク全体を安く完了させることは同じではありません。

フリーランスSEの場合も、単価だけで判断するより、納期、レビュー時間、失敗時の修正工数まで含めて考える方が現実的です。自分一人で確認する案件では、誤った変更を後から追う時間が大きなコストになります。定型処理をLunaへ、判断が重い処理をSolへ分けるだけでも、使い分けの軸が明確になります。

導入前に確認したい5つの注意点

GPT-6 Sol・Lunaへ切り替える前に、少なくとも次の点は確認したいところです。

  1. 既存プロンプトをそのまま本番へ入れない
    モデルが変わると、同じ指示でも回答の長さ、ツール選択、確認の入り方が変わる可能性があります。代表的なタスクを20〜50件程度用意し、旧モデルと比較してから切り替える方が安全です。
  2. Chat CompletionsとResponses APIの違いを確認する
    GPT-6 Sol・Lunaでツール利用を伴う推論を使う場合、OpenAIはResponses APIを案内しています。Chat Completionsでは、function callingがreasoning effort「none」の場合に限られる点に注意が必要です。
  3. 長文入力の追加料金を見落とさない
    272Kを超える入力では料金体系が変わります。1.05Mコンテキストを使えることと、1.05Mを毎回送ることが経済的であることは別です。
  4. キャッシュヒット率を監視する
    長時間エージェントでは、共通プロンプトの再利用率がコストへ影響します。モデル移行後にキャッシュ率が落ちていないか確認した方がよいでしょう。
  5. ベンチマークではなく自社タスクで評価する
    コード規約、日本語仕様書、独自フレームワーク、社内用語、古いシステムの癖は公開ベンチマークへ反映されません。正解例を持つ評価セットを作る方が実務判断につながります。

特にチーム導入では、モデルを変更できる人、推論レベルを変えられる人、本番データを入力してよい範囲、ツール実行の権限を決めておく必要があります。モデル性能が上がっても、アクセス制御やレビュー責任まで自動で解決されるわけではありません。

向いている人・まだ急いで移行しなくてよい人

GPT-6 Solが向いているのは、CodexやAPIで複数ステップのコーディング作業を回している人、AIエージェントを業務フローへ組み込んでいる人、GPT-5.6 Solのコストを下げながら同等以上の仕事を狙いたい人です。

GPT-6 Lunaが向いているのは、分類・要約・整形・一次判定などを大量に処理する人、バックグラウンド処理やバッチ処理へAIを入れている人、エラー時に自動で再試行や上位モデルへの切り替えができる人です。

一方、通常のChatGPT会話しか使っていない人は、9月25日時点では急いで切り替える必要はありません。SolとLunaはWork・Codex向けとして提供されており、通常のChatGPT会話のモデルとは分かれています。

また、APIを月に数回しか使わず、現在のモデルで困っていない場合も、移行作業そのものがコストになります。新モデルへ変えることを目的にせず、料金、失敗率、処理時間、レビュー負荷のどれを改善したいのかを先に決めた方がよいでしょう。

これから試すなら小さな評価セットから始める

これからGPT-6 Sol・Lunaを試すなら、本番環境を一気に切り替えるより、小さな評価セットを作るのが現実的です。

最初に、自分の仕事から「正解を判断できるタスク」を20件ほど集めます。たとえば、過去に解決した障害ログ、マージ済みのバグ修正、レビュー済みのSQL、確定したテストケース、正しく分類された問い合わせなどです。

次に、同じ入力を現在使っているモデル、GPT-6 Luna、GPT-6 Solへ渡し、品質だけでなく、処理時間、入力・出力トークン、再試行回数、ツール呼び出し回数、人間が直した時間を記録します。AIの評価では、回答の見た目より「仕事が何分で終わったか」の方が役立つことがあります。

その結果、Lunaで十分な仕事、Solへ上げる仕事、人間が最初から判断した方がよい仕事を分けます。さらに長時間エージェントなら、Prompt Caching Dashboardでキャッシュ率も確認します。

この小さな評価を終えてから、本番のモデルルーティングを変える方が、価格表や公開ベンチマークだけで決めるより失敗を減らせます。GPT-6の強みはモデル単体の性能だけではなく、推論量、ツール利用、キャッシュ、モデル階層を組み合わせて業務ごとに調整できる点にあります。

まとめ：GPT-6 Sol・Lunaは「モデル選択」から「処理設計」へ進む更新

GPT-6 Sol・Lunaの発表で目立つのはAPI料金の引き下げですが、SE実務で重要なのは、低価格化によってAIを呼び出す回数を増やせること、そしてキャッシュ改善によって長時間エージェントの運用コストを下げやすくなったことです。

Solは複雑なコーディングやエージェント処理、Lunaは大量の定型処理という役割が分かりやすくなりました。さらにAstraを含めれば、難易度と失敗コストに応じて3段階でモデルを使い分けられます。

ただし、モデルを新しくするだけで業務が自動的に改善するわけではありません。長文を毎回送りすぎる、キャッシュが効かないプロンプト構成にする、低価格モデルで何度も失敗して再試行する、といった運用ではコストメリットを失います。

まずは自分の代表的な業務を20件ほど選び、LunaとSolで品質・時間・総コストを比較する。そこで十分な差が確認できた処理から段階的に切り替える。GPT-6 Sol・Lunaを実務へ入れるなら、この進め方が判断しやすいでしょう。

参考情報

コメント