Projects / 実践記録

CodexのGPT-5.6 Sol・Terra・Lunaを66件の実運用で使い分けた結論

本ページはアフィリエイトプログラムを利用しています

GPT-5.6には、Sol、Terra、Lunaという3つの選択肢があります。
公式の説明を読むと、それぞれの役割はわかる。
でも、実際の仕事を前にすると「この作業にはどれを選ぶか」で迷います。

僕も提供開始直後は、難しそうならSol、軽そうならTerraかLuna、という大まかな選び方でした。
ところが、記事制作、Web開発、調査、WordPress更新、公開QAを重ねると、作業量の多さだけでは決めにくいとわかってきます。

そこで、2026年7月22日までに記録したschema検証済み正式run 66件を固定し、モデル選びを見直しました。
結論は、明確な反復作業ならLuna、通常運用ならTerra、曖昧で失敗影響が大きい仕事ならSolです。

これはモデルの順位表ではありません。
自分の環境で、仕事の曖昧さ、失敗時の影響、反復性、元に戻せるかを見て割り当てた運用記録です。

先に結論。迷ったらTerra、重い判断はSol、反復作業はLuna

今の僕は、モデル名より先に4つの質問を置いています。

失敗した時の影響は大きいか
依頼や正解が曖昧か
同じ形式を繰り返す仕事か
失敗しても簡単にrollbackできるか

この4軸で分けると、次の表になります。

仕事の特徴	第一候補	上げる条件
明確、反復、失敗しても戻せる	Luna / 軽〜中	判断や公開影響が入ればTerra
通常の実装、調査、記事差分、日次運用	Terra / 軽〜中	複数領域、曖昧な仕様、重大な影響があればSol
複雑、曖昧、高価値、長時間、最終判断	Sol / 軽から	セキュリティ、migration、複雑な設計で高へ

OpenAIのCodex向けモデル案内では、Solは複雑でopen-endedな仕事、Terraはeveryday work、Lunaは明確で反復可能な仕事に位置づけられています。
迷った場合はSolを選ぶ、というのが公式の一般案内です。

一方、僕の通常運用では、迷った段階ならTerraから始めます。
失敗影響や曖昧さが見えたらSolへ上げ、正解形式が明確ならLunaへ下げる。
公式仕様を否定するのではなく、独立QAとrollbackを組み込んだ自分の環境での運用結論です。

GPT-5.6の提供開始時点に確認した機能や初期印象は、ChatGPTデスクトップアプリにCodexが統合された時の記録にまとめています。
今回は機能紹介ではなく、その後の実仕事から見えた割り当てに絞ります。

66件をどう記録したか

観測対象は、2026年7月22日までに記録したschema検証済み正式run 66件です。
このうちcompleteは62件で、内訳はSol 41件、Terra 19件、Luna 2件です。
完了要約と成果物のmetadataから、完了状態、初回出力がそのまま使えたか、修正回数、人の介入、独立QAで見つかった指摘を記録しました。

model	run	complete	first output usable	revision	human intervention	QA issue
Sol	43	41	30	22	7	47
Terra	21	19	13	22	4	24
Luna	2	2	1	2	0	2

この数字は、同じ仕事を無作為に3モデルへ割り付けたA/Bテストではありません。
Solには複雑な開発、長時間作業、公開判断を多く渡し、Terraには日次運用や調査、定型記事を多く渡しています。
Lunaは2件しかなく、一般化できません。

QA issueも、そのままモデルの失敗数にはできません。
仕事が難しく、確認項目が多ければ指摘も増えます。
ブラウザ接続、ネットワーク、外部ツールの失敗は、モデル品質とは分けて扱いました。

つまり、この66件から「Solの勝率は何%」とは言えない。
言えるのは、どの特徴の仕事で修正や介入が起き、どこに独立QAを置くと閉じやすかったかです。

Solは複雑さより「失敗時の影響」で使う

Solを選ぶ基準は、作業が長いかどうかだけではありません。
僕の記録では、複数の成果を統合する仕事、複数repoをまたぐ変更、DBやmigration、公開前の最終判断、長時間goalとの相性がよく見えました。

とくに重要なのは、間違えた時に戻しにくい仕事です。
文章が少し長いだけならTerraでも進められる。
短い変更でも、公開URL、データ、権限、外部サービスへ影響するならSolを選ぶ理由があります。

ただし、Solを選べばQAが不要になるわけではありませんでした。
デザインの違和感、画面の最終状態、計測期間の意味、公開後の表示は、人や別担当の独立確認で修正した例があります。

僕はSolでも軽いreasoning effortから始めます。
セキュリティ、architecture、重大incidentなど、探索の幅と失敗影響が大きい時だけ上げる。
最初から高い設定を常用するより、Solが必要な判断だけを切り出す方が運用しやすいです。

Terraは日常の主力。ただし最後の整合をQAする

Terraは、僕の環境では通常運用の第一候補です。
公式情報の調査、範囲が明確な更新、記事の差分作成、日次処理、通常規模の実装では、十分に完了まで進めた記録が複数あります。

当初は、軽いモデルほど必須docsを読み飛ばすのでは、と疑っていました。
しかし、正式runでは、その仮説は再現しませんでした。
弱点として現れたのは、技術仕様と複数箇所の整合、最後の完了条件、公開後確認を閉じる場面です。

これは「Terraだから雑」という意味ではありません。
作業の途中までは正しくても、別ファイル、公開HTML、metadata、rollbackまで揃えるには確認設計が必要だったという話です。

通常作業をTerraへ渡し、最後にチェックリストや独立QAを置く。
そこで曖昧さや高い影響が見つかったらSolへ上げる。
この流れにすると、Solを常用せずに品質を保ちやすくなりました。

Lunaは明確な反復作業へ。2件だけなので過信しない

Lunaは、抽出、分類、形式変換、表整形など、正解の形が先に決まっている仕事へ使います。
入力と出力の契約が明確で、失敗しても再実行でき、後段にQAがある工程です。

ただ、僕の正式runは2件だけです。
新規設計、公開判断、商品同定、曖昧な文章品質まで推奨できる量ではありません。

Lunaに向くのは、「考えなくていい仕事」ではなく、「判断範囲を先に狭められた仕事」だと思っています。
抽出後にTerraやSolが判断する、人が差分を確認する、といった後段を用意して使う。
小さいモデルへ丸投げするのではなく、工程を分解した結果としてLunaを選びます。

reasoning effortはモデル名より先に上げない

モデルを選んだあとも、reasoning effortを最初から上げすぎないようにしています。
まず必要品質を満たす最も低い設定から始め、曖昧さ、失敗影響、rollbackの難しさに応じてmediumやhighへ上げます。

Solのhighやmaxを使えば、すべての仕事が速く安く終わるとは限りません。
探索が広がり、利用枠も多く使う可能性があります。
明確な差分なら、TerraやLunaの軽い設定で終わる方が自然です。

ここで、OpenAI APIのtoken単価とCodex subscriptionの利用枠は分けて考える必要があります。
公式発表にあるAPI価格は、API利用時の価格です。
Codexの週次枠を同じ金額へ置き換えたり、モデルごとの固定消費量として説明したりはできません。

利用者の反応も「Sol一択」ではなかった

Redditでは、Solの品質を評価しつつ、週次利用枠の消費を心配し、通常作業をTerraやLunaへ分ける投稿がありました。
別の利用者は、明確な小作業をLuna、通常や探索をTerra、複雑で高影響な仕事をSolへ割り当てています。

これはOpenAIの公式仕様でも、僕の66件の実測でもありません。
投稿者ごとにplan、repo、threadの長さ、reasoning effortが違うため、「Solは必ず何倍消費する」とは言えません。

ただ、モデルを能力順に固定するのではなく、仕事の曖昧さと影響でrouteする考え方が、コミュニティにもあることはわかります。
ここでは利用者反応のsignalとしてだけ扱います。

Claude Fable 5のusage credits化で、今この比較を書く理由

この使い分けを今まとめた背景には、Claude側の提供条件の変化もあります。

Anthropicは2026年6月30日の公式発表で、Fable 5を7月1日から再提供し、対象planでは7月7日まで週次利用枠の最大50%に含め、その後はusage creditsで利用できると案内しました。
公式Helpではusage creditsを、planの含有枠を超えた後も標準API rateで利用を続ける仕組みとして説明しています。

Redditでは、この変更を受けてCodexへの移行を検討する声もありました。
ただし、一部コミュニティの反応を市場全体の結論にはしません。
ClaudeとCodexの優劣を決めることも、この記事の目的ではありません。

利用条件が変わると、「最も高性能なモデルはどれか」より、「普段の仕事をどのモデルへ割り当てるか」が重要になります。
だからこそ、Codex内の3モデルを同じ順位表へ置かず、用途で分ける必要がありました。

僕なら今こう割り当てる

現在の割り当ては、次の3行に戻ります。

task	model / effort
抽出、分類、表整形、決まった差分	Luna / 軽〜中
通常実装、公式調査、記事差分、日次運用	Terra / 軽〜中
複雑設計、複数repo、公開事故、最終判断	Sol / 軽から必要時に高

長期作業では、モデルを変えることと、作業履歴を安全に引き継ぐことも分けています。
Codexの長期タスクを安全に移行した手順では、現在有効な状態だけを渡し、古い前提を持ち込まない境界を整理しました。

モデル選びも同じです。
Solへ全部を寄せるのではなく、仕事を分解し、必要な判断だけを上げる。
どのモデルでも、独立QAとrollbackは残す。

迷ったらTerra。
失敗時の影響が大きいならSol。
正解形式が明確ならLuna。

66件を観測した時点では、この使い分けが自分の環境で最も閉じやすい結論です。
今後、モデルや利用枠が変わるか、同じ用途の比較可能な記録が揃った時に、あらためて見直します。

AIエージェントへ仕事を渡す時は、モデル名だけでなく、タスクの分け方と確認点を先に設計する必要があります。
その全体像を短時間で整理したい読者向けに、この記事では『60分でわかる！ AIエージェント超入門』を選びました。
僕の実使用品ではなく、記事の次に基礎を確認するための選定です。