Codexのモデル選びで迷わない。Astra・Sol・Terraの使い分け

はじめに

Codexで新しいタスクを作ろうとすると、Astra・Sol・Terraというモデルが並んでいます。

ClaudeのFable・Opus・Sonnetの使い分けはわかったけど、Codexは全然わからん！

せっかくなら、Codexも上手く使いたい！

名前だけ見ても、どれが何？ 軽・中って何？ となったので調べてきました！

先に結論を書くと、自分は普段Sol + 軽（Low）を使っています。そのうえで、作業に合わせて次のように動かすと選びやすいと思いました。

普段の作業               → Sol + 軽
調査や判断が増える作業    → Sol + 中以上
失敗したくない難しい仕事  → Astra + 高以上

この記事では、CodexのAstra・Sol・Terraを、公式ドキュメントの位置づけと普段の開発作業に当てはめて整理します。

まだ同じタスクを3モデルへ投げて比較検証したわけではありません。今回は、公式情報を読んでも「で、自分の作業ではどれを選ぶん？」となったので、現時点の自分用ルールまで落とし込みました。

2026年9月16日時点の情報です。モデルの種類や利用条件は変わる可能性があるため、使うときはCodexのモデル選択画面と公式ドキュメントも確認してください。

Astra・Sol・Terraは何が違うのか

正式なモデル名は次の3つです。

Codexでの表示	正式なモデル名	公式の位置づけ
Astra	GPT-6 Astra	最も高性能。難しいエンドツーエンドの仕事向け
Sol	GPT-5.6 Sol	複雑な専門業務向けの主力モデル
Terra	GPT-5.6 Terra	性能とコストのバランス型

3モデルとも扱える情報量と主なツールは同じです。単純に「Terraは長いファイルを読めない」という違いではなく、同じ大きさの仕事場で、どれだけ難しい判断を任せるかで考えるとわかりやすいです。

Codexでは、まずこの表で選ぶ

ここからは公式の位置づけをもとに、自分なら開発作業へどう割り当てるかを整理したものです。

やりたいこと	おすすめ	理由
誤字修正、文言変更、小さなUI調整	Terra	目的と変更箇所がはっきりしている
既存コードを読んで通常の機能を追加	Terra / Sol	判断が少なければTerra、複数ファイルにまたがるならSol
原因不明のバグ調査	Sol	調査と仮説検証のバランスを取りやすい
設計から実装、テストまでまとめて任せる	Sol / Astra	長い工程で判断が積み重なる
大規模なリファクタリング	Astra	影響範囲が広く、途中の判断ミスが後まで響く
セキュリティや本番障害の調査	Astra	見落としたときの損失が大きい。最終判断は人が行う
たくさんの定型作業を繰り返す	Terra	1件ごとの難しさより処理量を優先したい

図にすると、最初に見るのは「変更箇所と方針が決まっているか」です。決まっていればTerra、調査や設計が必要ならSol、さらに手戻りの影響が大きければAstraへ上げます。

迷ったら、コード量よりも途中で何回判断が必要になるかを見ます。

1ファイルに100行追加するだけでも、仕様が曖昧で既存機能との整合を考えるなら重い仕事です。逆に20ファイルを同じルールで機械的に直すなら、見た目ほど難しくないこともあります。

行数だけでは決められん。

Terraは「指示が明確な軽作業」

GPT-5.6 Terraは、公式ドキュメントで「性能とコストのバランスを取るモデル」と説明されています。以前のGPT-5系でいうmini相当の位置づけです。

Codexで任せるなら、ゴールと変更箇所が見えている作業が合います。

• ボタンの文言を変える
• テストケースを追加する
• 指定したルールでファイルをまとめて直す

たとえば「このエラーを直して」だけだと調査が必要ですが、「原因はこの型の不一致なので、呼び出し側を新しい型に合わせて」と渡せるならTerraで進めやすいです。

人間側で問題を切り分けられているほど、Terraを選びやすくなるということです。

自分で方針を決めたあとの実装担当。そんな感じです。

Solは「迷ったときの主力」

GPT-5.6 Solは、複雑な専門業務向けの主力モデルです。Terraより難しい判断を任せたいけれど、毎回Astraを出すほどではない。そんな普段の開発に置きやすいモデルです。

• 関連ファイルを探して変更箇所を決める
• 原因がまだわからない不具合を調査する
• 実装後にテストし、失敗を見て修正する

「何を変えるか」だけでなく、「どこをどう変えるか」からCodexに考えてもらうならSolが候補になります。

自分は普段、Sol + 軽を基準にしています。モデルはSolのまま、調査や判断が増えたら中へ上げ、失敗したときの手戻りが大きい仕事ではAstraへ動かす使い方です。

名前も真ん中っぽくないのに、役割はだいぶ真ん中です。

Astraは「考え直しが高くつく仕事」

GPT-6 Astraは、OpenAIが最も高性能なモデルと位置づけています。複雑な推論、コーディング、Computer use、調査、ドキュメント作成など、難しい仕事を最初から最後まで進める用途向けです。

Codexでは、次のような場面で使いたいです。

• 要件を読んで設計から組み立てる
• 既存仕様を壊さずに大規模な整理をする
• ブラウザや複数ツールを使う作業を最後まで任せる

ポイントは、「難しそうだから」だけではありません。

序盤の判断を間違えると、後半の実装を全部やり直す仕事ならAstraを使う価値が出ます。モデル選びで節約して、あとから人間が何時間もレビューすることになったら本末転倒です。

ただし、Astraへ変えただけで曖昧な仕様が消えるわけではありません。何をもって完了とするか、触ってよい範囲、必ず確認してほしいことはプロンプトやAGENTS.mdに書いておく必要があります。

もちろん、本番障害やセキュリティに関わる作業はAstraへ丸投げして終わりではありません。モデルを上げても、変更内容のレビューと動作確認は人間側で行います。

モデルだけでなくreasoning effortも選ぶ

Codexでは、モデルとは別にreasoning effort（どれくらい深く考えるか）も選べます。

この記事では、Lowを「軽」、Mediumを「中」と呼びます。実際の表示名や選べる段階は、Codexのバージョンや利用環境を優先してください。

モデル             = 誰に頼むか
reasoning effort   = その人にどれくらい考えてもらうか

設定の考え方としては、同じTerraでも軽なら効率を優先し、中なら品質・安定性とのバランスを取ります。軽だから文章が短い、中だから文章が長い、という設定ではありません。 回答の長さではなく、答えを出す前の推論へ使う量の違いです。

公式ドキュメントの説明をもとに、Codexの作業へ当てはめると次のようになります。

表示の目安	英語表記	違い	Codexで向いている作業
軽	Low	推論を抑え、速さと消費量を優先	文言修正、明確な1ファイル修正、単純な変換
中	Medium	品質・安定性・待ち時間のバランス型	普段の実装、テスト追加、複数ファイルの軽い調査
高	High	時間よりも難しい推論を優先	原因不明の不具合、設計判断、影響範囲の広い修正
最高域	XHigh / Maxなど	最も難しい非同期・長時間作業向け	大規模な設計変更、長い調査、評価用の難問

軽は、作業の正解と進め方が見えているとき向け。中は、探す → 方針を決める → 実装する → 確認するという普段の開発に置きやすい設定です。

高以上は、原因不明の不具合や設計判断など、待ち時間より難しい推論を優先したい仕事向けです。ただし、高くすれば必ず正解になるわけではありません。指示が曖昧なまま上げると、考えすぎたり不要な調査が増えたりすることもあります。

自分は普段使いのSolを軽にして、調査や判断が増えたら中へ上げています。高ければ毎回よいわけではない。多いねん！

逆に、モデルを上げる前にreasoning effortを1段上げるだけで十分な場合もありそうです。

自分なら、次の組み合わせから始めます。

組み合わせ	使いどころ
Terra + 軽	文言変更、明確な小修正、定型作業
Sol + 軽	自分の普段使い。日常的な実装や修正
Sol + 中	調査や複数ファイルの判断が必要
Sol + 高	原因不明の不具合や設計を含む
Astra + 高以上	失敗コストが高い長時間の仕事

そこで調査が浅い、変更の影響範囲を拾いきれないと感じたら、reasoning effortかモデルを1段ずつ上げます。同時に両方変えると、どちらが効いたのかわからなくなるためです。

いきなり全部盛りにしない。

なお、公式API情報ではAstraはnoneに対応せず、SolとTerraはnoneからmaxまで対応しています。Codex上で実際に選べる段階は、アプリや利用環境の表示を優先してください。

まとめ

CodexのAstra・Sol・Terraは、次のように使い分けると迷いにくくなります。

• Terra：指示が明確な軽作業や定型作業
• Sol：調査や判断を含む日常開発の主力
• Astra：設計や長時間作業など、判断ミスの手戻りが大きい仕事

迷ったときは、「変更箇所が決まっているか」「Codex側で調査や判断が必要か」「失敗したときの手戻りが大きいか」の順に見ます。

モデル単体の賢さより、人間の手戻りまで含めて早く終わるかで選ぶ。まず次のタスクを開くときに、「コードは何行変わるか」ではなく「途中で何回判断が必要か」を見てみてください。

自分はSol + 軽（Low）を普段使いにしています。調査や判断が増えたら中へ上げ、怖い変更はAstraへ。完了までの時間、修正回数、人間のレビュー量まで比べた実測も、そのうち記事にしたい。

参考

• Models - OpenAI API … Astra・Sol・Terraの公式な位置づけと、モデル選択の基本方針
• GPT-6 Astra Model - OpenAI API … Astraの用途、対応機能、コンテキスト長、API料金
• GPT-5.6 Sol Model - OpenAI API … Solの位置づけ、対応するreasoning effort、API料金
• GPT-5.6 Terra Model - OpenAI API … Terraの位置づけ、対応するreasoning effort、API料金
• Model guidance - OpenAI API … Astraの特性とreasoning effortの考え方

関連記事

• プロンプト1発でCodexに赤枠・番号付きの手順画像を自動で作ってもらった … Codexへ実際の作業を任せ、画像の生成から確認まで進めた話
• 初めてのAI駆動開発。勤怠管理アプリを1ヶ月で本番公開した全8ステップ … AIへ設計・実装を任せるとき、人間がどこを判断したかをまとめた話

告知

最後にお知らせとなりますが、イーディーエーでは一緒に働くエンジニアを
募集しております。詳しくは採用情報ページをご確認ください。

みなさまからのご応募をお待ちしております。