Codex ニュース｜GPT-6 Sol / Lunaの違いと対象プラン

GPT-6 Sol / LunaがCopilotに追加された内容

GitHubが2026年9月22日に公開したChangelogでは、GitHub Copilotで選べるGPT-6系のモデルとしてSolとLunaが追加されたと案内されています。Solは対話的なエージェント型開発と、慎重な多段階の検証を必要とする開発作業に向く均衡型です。Lunaは小さく速い作業向けの軽量モデルで、GPT-6系の中では費用を抑えやすい選択肢として説明されています。これは公式の位置づけであり、すべてのコードベースで同じ速度や品質になるという測定結果ではありません。

対象プランにも差があります。SolはCopilot Pro+、Max、Business、Enterpriseで利用可能とされ、LunaはPro、Pro+、Max、Business、Enterpriseが対象です。さらに、モデル選択欄はVisual Studio Code、Visual Studio、Copilot CLI、GitHub Copilotのクラウドエージェントやアプリ、github.com、モバイル、JetBrains、Xcode、Eclipseなどに表示されると案内されています。ただし、反映は段階的なので、対象プランでも確認した時点でまだ表示されない場合があります。出典 URL: https://github.blog/changelog/2026-09-22-openais-gpt-6-sol-and-gpt-6-luna-now-available/

GitHubは、この2モデルが利用量に応じた請求の対象になることも記載しています。したがって、モデル名だけを見て「使える」と判定するのではなく、対象プラン、選択欄への表示、利用量の表示、請求への反映を別々に確認する必要があります。価格の具体的な数字や上限は契約しているプランによって変わり得るため、記事の時点で一つの金額に固定せず、公式のモデル料金案内と自分の画面を照合します。出典 URL: https://github.blog/changelog/2026-09-22-openais-gpt-6-sol-and-gpt-6-luna-now-available/

SolとLunaは公式の位置づけを出発点に選ぶ

SolとLunaの使い分けは、モデル名の印象や番号の大きさではなく、依頼する作業の長さと確認の細かさから始めます。複数のファイルや段階的な判断を含む作業ではSolを候補にし、小さな修正や短い確認を素早く繰り返したい場合はLunaを候補にします。ただし、これはGitHubが示す方向性に沿った最初の選び方であって、手元の速度、回答の正確さ、利用量を保証するものではありません。

Solを候補にする場面

Solは、作業をいくつかの段階へ分け、途中の判断を確認しながら進めたい場合に候補になります。たとえば、複数の関連ファイルを読み、変更の影響を調べ、テスト結果まで確認するような依頼です。ここで大切なのは、長い作業を任せきりにすることではありません。最初に対象範囲と完了条件を決め、どの段階で差分を読み、どの結果なら採用するかを明記しておくと、公式説明の「多段階の検証」に近い形で試せます。

Solを使った結果を評価するときも、返答が長かったか、説明が詳しかったかだけで判断しません。同じ対象、同じ入力、同じ確認方法で、読み落としがないか、不要な変更が増えていないか、想定した検査を通るかを記録します。モデルの表示がSolだったことと、作業結果が採用できることは別の項目です。

Lunaを候補にする場面

Lunaは、小さな修正、短い質問、限定した範囲の確認など、結果をすぐ読める仕事から試すと位置づけを確かめやすくなります。たとえば一つの設定値を調べる、短い関数の入力例を確認する、表示文の候補を比較する、といった題材です。短い作業でも、対象ファイル、入力、期待する結果を決めておけば、速さだけでなく内容も評価できます。

費用を抑えやすいという公式説明も、無条件に安くなるという意味ではありません。利用量に応じた請求は、契約プラン、モデルの選択、依頼の回数や長さによって見え方が変わります。Lunaを候補にするときは、同じ小課題でSolと比べ、完了までの時間、追加の確認回数、利用量の表示を自分の条件で残します。出典 URL: https://github.blog/changelog/2026-09-22-openais-gpt-6-sol-and-gpt-6-luna-now-available/

速度と費用を一般化しない

「Solは遅い」「Lunaは品質が低い」といった短い結論は、公式Changelogからは導けません。公式に示されているのは、モデルを選ぶときの位置づけと対象範囲です。実際の所要時間は、コードの量、入力の具体性、応答を確認する回数、利用する入口によって変わります。自分の課題で観測した結果だけを条件付きで書き、別の製品や別のプランにもそのまま当てはめないことが大切です。

表示・利用・請求・結果を四つに分ける

今回のcodex ニュースで最も混同しやすいのは、モデル選択欄に名前が出たことと、実際の作業が同じ条件で完了したことです。確認を四つの段階に分けると、どこまで確定したかを説明しやすくなります。画面の表示は入口の確認、要求が受け付けられたかは利用の確認、利用量や料金の表示は契約の確認、生成物や差分の確認は結果の確認です。

最初にモデル選択欄のスクリーンショットや表示文を残し、次に対象プランと組織側の設定を確認します。その後、重要度の低い同じ小課題をSolとLunaで試し、結果の差分と利用量を別々に記録します。ここで、モデルを変える以外の条件まで同時に変えると、結果の原因が分かりにくくなります。

1. モデル名と表示時刻を記録する

表示欄にGPT-6 SolまたはGPT-6 Lunaが出たら、製品名、入口、確認日時を記録します。表示がない場合も、対象プランではないと即断せず、段階的な反映の途中か、管理側のモデル設定が影響しているかを分けます。画面を見た事実と、依頼を送れる状態は別なので、同じ欄へまとめないようにします。

2. 対象プランと組織設定を確認する

BusinessまたはEnterpriseでは、管理者がCopilot設定のモデルポリシーを通じてGPT-6系モデルへのアクセスを管理できます。新しいモデルを既定で有効にする設定があっても、全体の既定設定を無効にしていたり、対象モデルだけを無効にしていたりすれば、利用者の選択欄に影響します。個人向けの対象プランと組織向けの設定を同じ条件として扱わないことが重要です。出典 URL: https://github.blog/changelog/2026-09-22-openais-gpt-6-sol-and-gpt-6-luna-now-available/

3. 利用量の表示を結果から切り離す

利用量が表示されたことは、処理が完了したことや結果が正しいことを示しません。反対に、作業結果が得られたことだけから、請求上の扱いを推測することもできません。モデル名、利用量の単位、確認日時、同じ課題の結果を別の欄に置き、分からない項目は未確認として残します。

4. 結果は差分と検査で判断する

SolとLunaを比べるなら、同じ入力と同じ対象を使い、変更された範囲、期待した出力、検査結果を並べます。返答が速かった、文章が自然だったという印象は補助情報にとどめ、採用するかどうかは差分と検査で決めます。試していない課題について、モデルの一般的な性能として説明しないことが安全です。

Copilotの条件をCodex・Cursor・Aiderへ転用しない

GitHub CopilotでSolとLunaが表示されることは、Codex、Cursor、Aiderでも同じモデル名、同じプラン、同じ利用量で使えることを意味しません。製品ごとにモデルの入口、契約、表示欄、版番号、結果の記録方法が異なります。今回のニュースを横断比較へ広げるときは、共通点を探す前に、どの公式ページが何を説明しているかを分けて書きます。

Copilotの対象プランをCursorやAiderの利用条件として書き写すと、読者が自分の画面で確認できない情報を断定することになります。逆に、Codexの版番号を見てCopilotのモデル選択欄を説明することもできません。製品名、入口、モデル名、契約、確認時刻を一つの記録に置きながら、根拠 URL は製品ごとに分けます。

Codex 0.156.0 alpha.16〜alpha.18は別の更新情報として読む

同じ時期に、OpenAI Codexの公式リリース欄では0.156.0-alpha.16、alpha.17、alpha.18が公開されています。alpha.16とalpha.17のページはPre-releaseとして表示され、alpha.18も固有のタグと公開ページを持っています。確認できるのは、これらの版がリリース欄に並んでいることと、版ごとの公式ページがあることです。版番号の更新だけから、GPT-6 SolやGPT-6 LunaがCodex CLIへ同じ条件で追加されたとは判断しません。

出典 URL: https://github.com/openai/codex/releases/tag/rust-v0.156.0-alpha.16
出典 URL: https://github.com/openai/codex/releases/tag/rust-v0.156.0-alpha.17
出典 URL: https://github.com/openai/codex/releases/tag/rust-v0.156.0-alpha.18

版番号とモデル名を同じ欄に置かない

Codexの0.156.0-alpha.18は入口側の版番号であり、Copilotのモデル選択欄に表示されるGPT-6 SolやGPT-6 Lunaとは別の識別情報です。記録表では「クライアント版」と「選択モデル」を分け、どの画面で確認した値かを添えます。両方が同じ日に更新されたとしても、公式に対応関係が書かれていない限り、同じ機能として結び付けません。

alpha版は公開事実と手元の結果を分ける

alpha版を試す場合は、公開ページの区分、手元に表示された版、対象作業、変更差分、検査結果を残します。Pre-releaseの表示は、その版が公開されたことを示しますが、日常の作業で安定して使えることや、特定のモデルが追加されたことを保証しません。必要な差分を確認できなかった場合は、保留として記録する方が、番号の新しさだけで判断するより再現しやすくなります。

Copilot CLIのC++全体索引はモデル追加と別の改善

GitHubは同じ9月22日のChangelogで、GitHub Copilot CLIのC++コード理解について、プロジェクト全体の索引に対応したと案内しています。C++のソースとヘッダーにあるシンボルを持続的な索引へまとめ、現在開いていないファイルも含めて、定義、参照、型、インクルード、ファイル間の関係を再利用する仕組みです。大きなリポジトリで毎回プロジェクト情報を探し直す時間を減らすことが目的で、GPT-6 SolやLunaのモデル追加とは別の話です。

この索引は既定で有効と説明されています。C++プロジェクトを最初に開いたときに作成され、進行状況は/lsp logsで確認できます。初回の作成には追加の時間がかかり、特に大規模または複雑なリポジトリでは一時的にメモリ使用量が増える場合があります。作成後は索引を再利用し、変更に合わせて更新されます。初回だけ待ち時間が増えたことを、モデルの速度差やCodexの更新と混同しないようにします。出典 URL: https://github.blog/changelog/2026-09-22-faster-c-code-intelligence-with-whole-codebase-indexing/

C++を扱わない利用者にとっては、今回の情報はCopilot CLIの特定言語向け改善として読むのが適切です。C++プロジェクトで試す場合は、索引の作成前後で定義検索や参照検索にかかった時間、最初の待ち時間、メモリの変化を自分の環境で記録します。これも、SolとLunaの出力品質を比較した結果として扱うことはできません。

CursorとAiderは公式の変更欄を製品別に確認する

CursorとAiderは、今回のCopilot追加をそのまま受け取らず、それぞれの公式ページで変更を確認します。Cursorの公式変更欄には2026年9月10日付のProjectsに関する案内や、9月2日付のself-hosted machinesに関する案内が掲載されています。Aiderは公式リリース欄で版ごとの変更を公開しており、一覧にはv0.86.0などのリリースが表示されます。これらは各製品の更新情報であり、Copilotの対象プランや請求条件を説明する資料ではありません。

出典 URL: https://cursor.com/changelog
出典 URL: https://github.com/Aider-AI/aider/releases

製品別に確認するときは、まずページ上の版や公開日を記録し、次に自分の入口で同じ機能名が見えるかを確かめます。最後に、短い同じ課題を試した結果と、利用量や料金の表示を残します。Cursorの変更欄にある機能説明をCodexの機能として書いたり、Aiderのリリース番号からCopilotのモデル対応を推測したりしないことが、比較記事の境界になります。

同じ小課題で比較する記録表を作る

SolとLunaの使い分けを自分の判断へ落とすには、モデルを変える以外の条件をできるだけ固定します。対象ファイル、入力文、確認方法、利用する入口を先に決め、片方だけでなく両方に同じ課題を渡します。結果が違ったときも、どちらが優れているとすぐ一般化せず、記録した条件の範囲で採用・保留を決めます。

たとえば、最初の課題を「一つの関数に入力例を追加し、既存の検査を通す」と決めます。SolとLunaの両方で同じ対象を使い、追加された差分、検査の結果、確認に要した時間、利用量の表示を残します。片方だけが別のファイルを変更した場合は、モデルの違いではなく依頼条件の違いが原因かもしれません。

作業が大きくなったら、一度に比べる要素を増やさないことも重要です。モデル、入口、プラン、対象コードを同時に変えると、結果の理由が分からなくなります。まず同じ入口と同じプランでモデルだけを比べ、次に別の入口を調べます。確認できない欄は空欄のままにし、推測で補わない記録を残します。

まとめ：codex ニュースは条件と結果を分けて読む

今回のcodex ニュースで確定している中心情報は、GitHub CopilotにGPT-6 SolとGPT-6 Lunaが追加され、モデルごとに公式の位置づけと対象プランが示されたことです。Solは多段階の開発、Lunaは小さく速い作業の候補ですが、速度や品質、費用の実測値は利用条件によって変わります。モデル選択欄への表示、依頼が受理されたこと、利用量の表示、結果の採用を一つにまとめないことが第一歩です。

Codex 0.156.0-alpha.16〜alpha.18の公開、Copilot CLIのC++全体索引、Cursorの変更欄、Aiderのリリース欄は、それぞれ別の公式情報として読む必要があります。版番号が同じ時期に更新されたことや、複数の製品がAIコーディングエージェントであることだけを根拠に、同じモデルや同じ料金条件だと断定することはできません。

確認するときは、対象日と入口を記録し、公式ページで条件を照合し、同じ小課題の結果を表へ残します。分からない項目を未確認と書ければ、次に表示が変わったときも、どの条件が変わったのかを追跡できます。Codex、Copilot、Cursor、Aiderを使い分けるときほど、製品ごとの境界を守ることが、ニュースを実際の選択へつなげる近道になります。