※この記事は2026年8月19日時点のOpenAI公式情報をもとにしています。モデルや推論レベル、利用条件は今後変更される可能性があります。
Codexでソフトウェア開発をしていると、 「とりあえず一番強いモデルを選んでおけばよいのでは？」 という疑問が出てきます。しかしながら、モデルが強力になると推論に要する時間もかかり、消費するクレジットも大きくなってしまうため、たとえChatGPT Pro プランを契約していたとしても１週間もたないケースが出てきます。
(筆者は最初このことをあまり意識せず、Sol - Ultra を使っていたら１週間分のクレジットが一気に溶けました…)
現在のGPT-5.6系では、Codexで主に次の3モデルを選択できます。
- GPT-5.6 Luna
- GPT-5.6 Terra
- GPT-5.6 Sol
さらに、モデルとは別にLight、Medium、High、Extra High、Max、Ultraといった推論レベルがあります。OpenAIも、必要な結果が得られる範囲で低い推論レベルから始め、より計画・分析・検証が必要な場合に引き上げることを推奨しています。(OpenAI Developers)
この記事では、単純なベンチマーク比較ではなく、
ソフトウェア開発のどの工程で、どのモデルを使うとよいのか
という観点から整理します。
第1章 Luna / Terra / Sol と推論レベルの使い分け
1.1 モデル選択で何が変わるのか
まず重要なのは、
モデルと推論レベルは別の軸
だということです。
感覚的には、次のように考えると分かりやすいでしょう。
- モデル：問題を理解して処理するための基本能力
- 推論レベル：その問題にどの程度の計画・分析・検証を行わせるか
たとえばLunaを高い推論レベルに設定したからといって、Solと同じモデルになるわけではありません。
逆に、Solだからといって常に最大限の推論を行わせる必要もありません。
そのため、
「どのモデルを使うか」
と
「どの程度考えさせるか」
を分けて判断した方が、品質・速度・使用量のバランスを取りやすくなります。
1.2 Luna / Terra / Sol の基本的な違い
OpenAIは現在、それぞれを概ね次のように位置づけています。
| モデル | 特徴 | ソフト開発でのイメージ |
|---|---|---|
| Luna | 高速・低コスト・大量処理向け | 作業担当 |
| Terra | 性能・速度・コストのバランス | 普段の開発担当 |
| Sol | 複雑・曖昧・高難度な仕事向け | 設計・判断担当 |
公式には、Solは複雑な推論、曖昧な問題、高度なコーディング、重要な判断向け、Terraは日常的な本番作業やコーディングを含む主力モデル、Lunaは分類・抽出・自動処理・明確なコーディング作業など高速・大量処理向けと説明されています。(OpenAI Developers)
~ Luna ~
Lunaが向いているのは、正解条件が明確な仕事です。
たとえば、
- DTOを追加する
- Enumを作る
- JSON形式を変換する
- テストデータを生成する
- ファイルを分類する
- 同じパターンの変更を大量に行う
といった仕事です。
「何をすればよいのか」は既に決まっていて、作業量だけが多いケースに向いています。
~ Terra ~
Terraは、日常的なソフトウェア開発の中心として使いやすいモデルです。
たとえば、
- APIを追加する
- Unityの画面を実装する
- Editor拡張を作る
- テストを追加する
- 既存クラスをリファクタリングする
- 明確なIssueを実装する
といった用途です。
本記事では、通常の開発ではTerraを基準にするという方針で考えます。
~ Sol ~
Solが向いているのは、
「何をするべきか」そのものを考える必要がある仕事
です。
たとえば、
- アーキテクチャを設計する
- 原因不明のバグを調査する
- 要件間の矛盾を見つける
- 大規模な変更の影響範囲を調査する
- プロジェクト全体から開発タスクを抽出する
といった仕事です。
Codexの公式ドキュメントでも、要求が曖昧で、多段階の計画、ツール利用、検証、大きなコンテキストを必要とするエージェントには上位モデルを使うことが推奨されています。(OpenAI Developers)
1.3 Light ～ Ultra の考え方
現在のCodexでは、環境やモデルによってLight、Medium、High、Extra High、Max、Ultraなどを選択できます。(OpenAI Developers)
大まかな使い分けは次のように考えられます。
| レベル | 向いている仕事 |
|---|---|
| Light | 明確で局所的な作業 |
| Medium | 普通の実務 |
| High | 複数要素を追う難しい仕事 |
| Extra High | かなり複雑な分析 |
| Max | 1つの難問をより深く考えさせる |
| Ultra | 複雑な仕事を複数のサブタスクへ分けて並列に調査・分析する |
ここで注意したいのがUltraです。
Ultraは単純に「Highより長時間考える」という設定ではありません。
OpenAIの説明では、Maxは選択したモデルに1つのタスクをより長く考えさせるモードであるのに対し、Ultraは複雑な仕事を意味のある単位へ分割し、サブエージェントを使って並列処理できるモードです。大半の仕事ではMaxやUltraは不要ともされています。(OpenAI Developers)
つまり、
難しい問題を1つ深く考える → Max
複数領域へ分割可能な大きな問題 → Ultra
という違いがあります。
1.4 モデルと推論レベルの組み合わせ
実際にはすべての組み合わせを均等に使う必要はありません。
ソフトウェア開発では、まず次のあたりを覚えておけば十分だと思います。
| 組み合わせ | 主な用途 |
|---|---|
| Luna Light / Medium | 定型処理、大量処理 |
| Terra Medium | 普通の実装 |
| Terra High | 少し難しい実装 |
| Sol Medium | 要求分析、設計、レビュー |
| Sol High | 難しい設計・デバッグ・全体分析 |
| Sol Ultra | 複数領域に分けられるプロジェクト横断分析 |
特に、個人的にはTerra MediumとSol Highの2つが使いやすいと考えています。
1.5 モデルを上げるか、推論レベルを上げるか
ここはモデル選択で迷いやすいところです。
たとえば、
Luna Ultraにするべきか？
Terra Mediumにするべきか？
というケースがあります。
判断基準としては、
問題自体が難しくなった
→ モデルを上げる
問題の種類は同じだが、慎重な検討が必要
→ 推論レベルを上げる
と考えると分かりやすくなります。
たとえば、
指定された100個のクラスへ同じ属性を追加する
ならLunaでもよいでしょう。
しかし、
この属性をどこへ付けるべきか、
コードベース全体を調査して判断する
となった瞬間に、仕事の性質が変わります。
これは推論レベルを上げ続けるより、TerraやSolへモデルを切り替えた方が自然です。
1.6 ソフト開発向けの基本セット
モデル選択をかなり単純化すると、私は次の4段階で考えます。
Luna Light / Medium
単純・大量処理
Terra Medium
通常のソフトウェア開発
Sol Medium / High
要求分析・設計・難しいデバッグ
Sol Ultra
複数サブシステムを横断する大型分析
この4つを基準にして、必要に応じて一段上下させる程度で十分でしょう。
第2章 ソフト開発プロセスごとのモデル選択
ここからは、モデルではなく開発工程を軸に考えてみます。
2.1 開発工程によってモデルを切り替える
ソフトウェア開発では、
要望
↓
要求
↓
要件
↓
設計
↓
タスク分解
↓
実装
↓
テスト
↓
レビュー
↓
リリース
と工程が進みます。
すべてをSolで行う必要はありません。
むしろ、
上流工程では判断力が必要になり、実装段階では速度と反復性が重要になる
という違いがあります。
そこで、工程によってモデルを切り替えます。
2.2 要望メモを作る
私は、AIを使った開発でも最初から要件定義書を書かせない方がよいと考えています。
まずは、
00_request_notes.md
のようなファイルを作り、
- 何を作りたいか
- なぜ必要なのか
- 誰が使うのか
- 現在何に困っているのか
- 絶対に必要なこと
- できれば欲しいこと
- やりたくないこと
- 技術上・業務上の制約
- まだ分からないこと
- 思いつき
などを書いておきます。
この段階では、
ユーザーはCSVファイルをインポートできること
のような「要件らしい文章」にする必要はありません。
むしろ、
毎回画面から入力するのが面倒。
Excelからまとめて登録できるとうれしい。
1万件くらいになる可能性がある。
形式はまだ決まっていない。
くらいの方が、元の要求を失いません。
とは言え、決して要件定義書と無関係であるというわけではありません。
要件定義書の各項目がなぜ書かれたのか？
その背景を記録として残しておくという位置づけで
要望メモを書き殴っておくとよいでしょう。
推奨モデル
Terra Light / Medium
この時点では高度な設計判断よりも、ユーザーの考えを整理することが中心です。
2.3 要望を要求へ整理する
次に、要望メモの内容を分類します。
たとえば、
- 確定事項
- 要望
- 仮説
- 未確定事項
- 制約
- 矛盾
- 確認が必要な事項
へ整理します。
ここで重要なのは、
要望を勝手に要件へ昇格させないこと
です。
たとえば、
AIで自動判定したい
はまだ要望です。
要求を掘り下げると、
判定結果を5秒以内に表示する
最終判断は人間が行う
AIの判断理由を確認できる
誤判定を修正できる
といった具体的な要件候補へ変わっていきます。
推奨モデル
通常は、
Terra Medium
複数部門の要求や既存システムとの関係などが絡むなら、
Sol Medium
へ上げます。
2.4 少しずつ要件を明らかにする
要件定義では、一度の巨大なプロンプトで完成させるより、
対話を繰り返して曖昧な部分を少しずつ減らす
方が扱いやすいと考えています。
たとえばAIに、
現時点では仕様を確定しないでください。
確定事項、仮説、未確定事項を分けて整理し、
要件を決めるうえで重要な質問を3つだけ挙げてください。
と依頼します。
回答したら、また次の3つを聞かせます。
この方法なら、
- 正常系
- 例外系
- 権限
- データ量
- 性能
- セキュリティ
- 運用
- バックアップ
- 外部システム連携
などを段階的に掘れます。
推奨モデル
- 通常のヒアリング：Terra Medium
- 複雑な要求分析：Sol Medium
- 全体の矛盾確認：Sol High
2.5 要件定義書を作成・レビューする
要求がある程度整理できたら、初めて正式な要件定義書へ落とします。
流れとしては、
00_request_notes.md
↓
01_requirements_analysis.md
↓
02_requirements.md
のように、元の要望と確定仕様を分けておくと扱いやすくなります。
作成
内容が既に確定しているなら、
Terra Medium / High
で十分です。
レビュー
一方で、
- 要件同士に矛盾がないか
- 抜けているケースがないか
- 曖昧な言葉が残っていないか
- 既存システムと衝突しないか
といったレビューでは、
Sol Medium / High
を使います。
2.6 アーキテクチャを設計する
要件から、
- システム分割
- データモデル
- API
- 保存方式
- モジュール境界
- 外部サービス
- 将来変更への対応
- テスト戦略
などを決めます。
この工程は、実装よりも
選択肢を比較して判断する仕事
です。
推奨モデル
小～中規模：
Sol Medium
複数システムが絡む場合：
Sol High
とします。
2.7 プロジェクト全体から開発タスクを作る
設計が決まったら、
Epic
↓
Feature
↓
Task
のように実際の作業へ分解します。
ここでは単にToDoリストを作るのではなく、
- タスクの依存関係
- 実装順序
- 並列化可能性
- 共通基盤
- テスト
- データ移行
- ドキュメント
- リスク
まで考える必要があります。
推奨モデル
普通のプロジェクト：
Sol High
複数サブシステムを横断し、それぞれを独立して調査できる大きなプロジェクト：
Sol Ultra
です。
Ultraは複数サブエージェントへ仕事を分けられるため、たとえば
Frontend
Backend
Database
Infrastructure
Testing
Migration
を個別に調査して最後に統合するといったタスクと相性がよいでしょう。Ultraでは適切な仕事をサブエージェントへ委譲でき、複数エージェントの結果を統合する仕組みが公式に提供されています。(OpenAI Developers)
2.8 「大規模」はコード量だけでは決まらない
ここでいう大規模プロジェクトは、
単純にコード行数が多いプロジェクト
とは限りません。
より重要なのは、
1つの判断に必要な依存関係の広さ
です。
特にUnityでは、
C#コード
Scene
Prefab
ScriptableObject
Addressables
UI
Animation
Editor Tool
Save Data
などが相互に関係します。
たとえば、
採点項目を1つ追加する
だけでも、
入力データ
↓
採点処理
↓
結果データ
↓
保存データ
↓
キャンペーン進行
↓
UI
まで変更が波及するなら、変更自体はかなり大きなものになります。
そのため私は、
プロジェクト全体のコード量より「変更半径」を見る
方が、AIに仕事を任せる際には重要だと考えています。
2.9 Issueを具体化する
プロジェクト全体のタスク分解ができたら、それぞれを実装可能なIssueへ落とします。
Issueには少なくとも、
- 目的
- 変更対象
- 完了条件
- 変更してはいけない範囲
- 必要なテスト
- 依存タスク
を入れておきます。
ここまで方針が決まっていれば、仕事の中心は判断ではなく文章化です。
推奨モデル
Terra Medium
2.10 通常の機能実装
ここが日々もっとも多く発生する工程でしょう。
たとえば、
- API追加
- Unity UI追加
- EditorWindow追加
- 保存処理
- 小～中規模リファクタリング
- テスト追加
などです。
推奨モデル
基本：
Terra Medium
少し難しい：
Terra High
このあたりを通常運転にすると、Solの使用量を重要な判断へ回しやすくなります。
2.11 定型・反復作業
一方で、
- DTO生成
- Enum追加
- テストケース量産
- JSON変換
- コメント追加
- ファイル整理
- 同じ形式のコードを複数追加
といった作業はLuna向きです。
推奨モデル
Luna Light / Medium
OpenAIもLunaを、明確で反復可能な高ボリューム作業や、焦点の絞られたコーディングタスク向けとしています。(OpenAI Developers)
2.12 難しい不具合を調査する
実装作業でも、
このメソッドを実装してください
と
原因が分からないので調べてください
では必要な能力が違います。
後者では、
- 仮説を作る
- コードを横断する
- ログを確認する
- 前提を疑う
- エッジケースを調べる
- 修正後の副作用を見る
といった作業が必要です。
推奨モデル
Sol Medium
難しいケース：
Sol High
Highは、複雑なロジックを追跡し、仮定やエッジケースを確認するようなエージェントに適した設定として公式にも案内されています。(OpenAI Developers)
2.13 コードレビュー
コードレビューでは、変更規模によって使い分けます。
普通のPR
- コード品質
- テスト不足
- エラー処理
- 明らかなバグ
程度なら、
Terra High / Sol Medium
重要な変更
- 保存データ互換性
- セキュリティ
- 認証
- DB移行
- 並行処理
- 大規模リファクタリング
などでは、
Sol High
を使います。
2.14 リリース前の全体レビュー
リリース前には、局所的なコード品質だけではなく、
- 要件との整合性
- 未実装機能
- テスト漏れ
- データ互換性
- 運用上の問題
- 技術的負債
- サブシステム間の不整合
などを横断して確認します。
推奨モデル
普通：
Sol High
複数領域を独立して監査できる大規模案件：
Sol Ultra
たとえばUltraで、
- セキュリティ
- テスト
- データ互換性
- パフォーマンス
- 保守性
を別々のサブエージェントへ確認させ、最後に統合するといった使い方ができます。Codexでは複数エージェントによる並列ワークフローそのものが正式な機能として提供されています。(OpenAI)
2.15 開発工程全体でのモデル切り替え例
ここまでをまとめると、次のようになります。
| 開発工程 | 推奨 |
|---|---|
| 要望メモ | Terra Light / Medium |
| 要求整理 | Terra Medium |
| 複雑な要求分析 | Sol Medium |
| 要件レビュー | Sol Medium / High |
| アーキテクチャ設計 | Sol Medium / High |
| プロジェクト全体のタスク化 | Sol High / Ultra |
| Issue具体化 | Terra Medium |
| 通常実装 | Terra Medium |
| 難しい実装 | Terra High / Sol Medium |
| 定型・大量処理 | Luna Light / Medium |
| 難しいデバッグ | Sol Medium / High |
| 通常コードレビュー | Terra High / Sol Medium |
| 重要変更レビュー | Sol High |
| リリース前全体監査 | Sol High / Ultra |
つまり、1つのモデルを固定するのではなく、
要望
↓
Terra
要求・要件
↓
Terra / Sol
設計
↓
Sol
タスク分解
↓
Sol
Issue化
↓
Terra
実装
↓
Terra
定型作業
↓
Luna
難しい問題
↓
Sol
最終レビュー
↓
Sol
という形です。
2.16 モデル選択を単純化する3原則
ここまで細かく説明してきましたが、実際には次の3つだけ覚えておけばかなり判断できます。
決まったことを処理する
→ Luna
決まったことを実装する
→ Terra
何をするべきか考える
→ Sol
さらに推論レベルについては、
明確で局所的
→ Light / Medium
複数要素を慎重に考える
→ High
1つの非常に難しい問題を深く考える
→ Max
複数領域へ分割して並列調査できる
→ Ultra
と考えると、かなり迷わなくなります。
2.17 まとめ
AIを使ったソフトウェア開発では、
常に一番強いモデルを使うことが最適とは限りません。
開発工程によって、必要な能力が違うからです。
通常の実装ではTerraを使い、単純な大量作業はLunaへ任せます。
そして、
- 要求が曖昧
- 設計を判断する必要がある
- 原因が分からない
- 複数システムを横断する
- プロジェクト全体を見る必要がある
という状況になったらSolへ切り替えます。
私自身が運用するとすれば、まず次の組み合わせから始めます。
Luna Light / Medium
定型・大量処理
Terra Medium
通常開発
Sol Medium / High
要求分析・設計・難しい問題
Sol Ultra
分割可能なプロジェクト横断分析
特に重要なのは、
AIに仕事を丸ごと投げるのではなく、開発工程を分け、その工程に合ったモデルを割り当てる
という考え方です。
Codex自体も、複数エージェント、並列ワークフロー、Skillsなどを使って、設計から実装、レビュー、保守までソフトウェア開発ライフサイクル全体で利用する方向へ拡張されています。(OpenAI)
モデル選択も同じで、「最強モデルを選ぶ」という問題ではなく、その時点でAIにどの役割を担わせるのかを決める問題として考えると、使い分けがかなり分かりやすくなると思います。