ChatGPT 5.6はSolだけ使えばいいのか。考える・作る・捌くを分けるプロンプト

ChatGPTのモデル名が増えると、最初に迷うのはここだと思います。

「5.6と書いてあるなら、5.5や5.4より全部賢いのか」

「Sol、Terra、Lunaは何が違うのか」

「容量が減ってきたら、自分で毎回モデルを落とした方がいいのか」

結論から言うと、5.6は単純に「全部が最上位」という意味ではありません。

ひとつの世代の中に、役割の違うモデルが並んでいる。

そう捉えた方が、実務では使いやすいです。

ClaudeでいうOpus、Sonnet、Haikuのように、賢さ・速さ・コスト感が違うモデルが並んでいる感覚に近いです。

ただし、名前で覚えすぎない方がいいです。

今後、Sol、Terra、Lunaという名前が変わる可能性はあります。

大事なのは、名前そのものではありません。

たとえば、次の3つです。

• 一番深く考えるモデル
• 実務を安定して進めるモデル
• 軽い処理を速く回すモデル

この3つの役割で覚えることです。

この記事では、2026年7月10日時点で確認できるOpenAI公式ドキュメントをもとに整理します。

扱うのは、ChatGPT 5.6の切り分け、旧モデルの位置づけ、そしてそのまま貼って使えるプロンプトです。

参考にした公式情報は、OpenAIのModelsページ、Subagentsページ、Codex rate cardです。

Sol、Terra、Lunaは「強さの順番」ではなく「役割の違い」で見る

まず、ざっくり分けるとこうです。

Solは、いちばん賢い相談相手です。

事業方針を考える。

記事やLPの構成をレビューする。

複雑なコードの原因を探る。

どの作業を誰に任せるかを決める。

最終判断の前にリスクを洗い出す。

こういう「間違えると後工程が全部ズレる仕事」に向いています。

Terraは、実務を進める担当です。

方針が決まった後の記事下書き。

仕様が決まった後の実装。

構成に沿った資料作成。

通常のコード修正。

定型ではないけれど、深い戦略判断までは要らない作業。

ここを毎回Solでやると、品質は安心です。

ただし、その分だけ消費は重くなりやすいです。

逆にLunaだけでやると、文脈の読み違いや粗さが出ることがあります。

なので、Terraは「日常業務の主力」として見ると使いやすいです。

Lunaは、処理係です。

文字起こしを整える。

議事録からタスクを抜き出す。

CSVを分類する。

重複を探す。

表記ゆれを直す。

長い文章から見出し候補だけ出す。

こういう仕事は、必ずしも一番賢いモデルでやる必要はありません。

条件がはっきりしている。

出力形式も決まっている。

この場合は、軽いモデルに逃がした方が全体の効率はよくなります。

旧モデルはどうなるのか

ここも誤解しやすいところです。

5.6が出たからといって、5.5や5.4がその瞬間に全部不要になるわけではありません。

ただ、今後の主役は5.6系に寄っていくと考えた方が自然です。

公式ドキュメント上では、GPT-5.5は前世代のフロンティアモデルとして位置づけられています。

複雑なコード、コンピューター操作、知識労働、リサーチ系のワークフローで使えるモデルです。

GPT-5.4は、プロ向け作業に使われてきたフロンティアモデルです。

今の感覚でいうと、Terra寄りの実務モデルとして見た方が近いです。

GPT-5.4 Miniは、軽く速く回すためのモデルです。

サブエージェントや反応速度が大事な作業では、まだ意味があります。

ただし役割としては、Lunaや軽量workerに近づいていきます。

GPT-5.3 Codex Sparkは、テキスト中心のコーディング反復に向いた研究プレビューとして扱われています。

近い距離で、すばやくコードを直していく用途です。

一方で、公式ドキュメントでは、GPT-5.2やGPT-5.3-Codexのように更新案内が出ているものもあります。

設定やスクリプトで使っている場合は、新しいモデルへ更新するよう案内されています。

なので、実務上はこう考えるのが安全です。

旧モデルは「まだ使えるかどうか」ではなく、「今後も主力に置く理由があるか」で見る。

既存の自動化や固定ワークフローで、5.5や5.4に合わせて安定しているなら、すぐ全部変える必要はありません。

でも、新しく設計するなら、

• 考える仕事は現行の最上位モデル
• 作る仕事は現行の実務モデル
• 捌く仕事は現行の軽量モデル

という役割で組み直した方がいいです。

この分け方にしておけば、あとからモデル名が変わっても崩れにくいです。

消費量はどれくらい違うのか

ここはかなり大事です。

OpenAIの案内では、多くの利用はトークンベースの課金や使用量管理に移っています。

実際の消費は、タスクの長さ、モデル、推論量、ツール使用によって変わります。

ただし、目安として出ているレガシーの平均値もあります。

ローカルタスクあたりの消費は、だいたい次のように見られています。

ここから分かる大事なことがあります。

容量が気になった時に、Solから5.5へ落としても、単純な節約にならない可能性があります。

目安上は、Solと5.5が同じくらいの重さとして扱われているからです。

節約を考えるなら、「新しいか古いか」だけで見ない方がいいです。

見るべきなのは、「その作業に一番賢いモデルが必要か」です。

たとえば、文字起こしの整形をSolでやるより、Lunaに任せる。

仕様が固まった後の実装をSolで続けるより、Terraに任せる。

最後のレビューだけSolに戻す。

この方が、質と消費のバランスを取りやすくなります。

サブエージェントは節約装置ではない

もうひとつ大事なのが、サブエージェントの扱いです。

サブエージェントは便利です。

でも、節約のために何でも分散すればいいわけではありません。

公式ドキュメントでも、各サブエージェントはそれぞれモデルやツールを使うと説明されています。

つまり、単純に「分ければ安くなる」わけではありません。

むしろ、雑に分散すると消費が増えることがあります。

サブエージェントを使う意味があるのは、次のような時です。

• 作業範囲が明確に分かれている
• 入力と出力がはっきりしている
• 本体の思考を邪魔せず、下処理だけ任せられる
• 複数の独立作業を並列で進める価値がある

逆に、まだ方針が曖昧な時に軽いworkerへ丸投げすると危険です。

ズレた作業が大量に返ってきます。

だから順番はこうです。

まずSolで設計する。

実務はTerraに任せる。

抽出や分類はLunaに逃がす。

最後にSolでレビューする。

この流れが一番きれいです。

仕事を指示する時の基本ルール

AIに仕事を頼む時は、最初から全部を一つのモデルに投げない方がいいです。

まず、仕事を3つに分けます。

1つ目は、考える仕事。

これはSolです。

企画、設計、方針決め、優先順位、レビュー、最終判断、リスク検出。

ここはケチらない方がいいです。

2つ目は、作る仕事。

これはTerraです。

記事の下書き、コード実装、資料作成、構成に沿った制作、通常の修正。

方針が決まった後に手を動かす仕事です。

3つ目は、捌く仕事。

これはLunaです。

抽出、分類、整形、要約、タグ付け、表記ゆれ修正、重複確認。

処理条件が明確な仕事です。

この3つを分けるだけで、AIの使い方はかなり変わります。

「一番賢いモデルに全部頼む」ではなく、

「一番賢いモデルには、ズレると困る判断を頼む」。

ここがポイントです。

そのまま貼って使えるプロンプト

ここまでの話を、毎回自分で言葉にするのは大変です。

「これはSolで考えて」

「ここからTerraで作って」

「この下処理はLunaに逃がして」

こうした指示を、毎回口頭で伝えるのは面倒です。

そこで、最初にAIへ渡しておきたいのが、次のプロンプトです。

目的は、AIにいきなり作業させることではありません。

まず仕事を分解させることです。

考える仕事、作る仕事、捌く仕事を分けた上で、どの役割に任せるかをAI自身に整理させます。

そのための初期設定として、以下をChatGPT 5.6に貼って使ってください。

実際にSol、Terra、Lunaを自動で切り替えられるかは、使っている画面やプラン、サブエージェント設定によって変わります。

もし本当にモデル切り替えやサブエージェント起動ができない環境なら、このプロンプトは「役割分担の思考」として働きます。

その場合は、AIにこう明示させてください。

「実際のモデル切り替えはできないが、Sol役、Terra役、Luna役として進める」

つまり、このプロンプトは魔法の自動切り替えボタンではありません。

AIに、仕事の分け方を先に覚えさせるための指示書です。

あなたは、私の仕事を「考える仕事」「作る仕事」「捌く仕事」に分けて進めるAIディレクターです。

今後、私が依頼するタスクは、毎回まず次の3種類に分解してください。

1. 考える仕事
- 戦略、設計、優先順位、要件定義、リスク判断、レビュー、最終判断
- 担当モデル: その時点で使える最上位・旗艦モデル
- 現在の想定: GPT-5.6 Sol

2. 作る仕事
- 記事下書き、コード実装、資料作成、構成に沿った制作、通常の修正
- 担当モデル: その時点で使える実務向け・バランス型モデル
- 現在の想定: GPT-5.6 Terra

3. 捌く仕事
- 抽出、分類、整形、要約、重複確認、表記ゆれ修正、タグ付け、フォーマット変換
- 担当モデル: その時点で使える軽量・高速モデル
- 現在の想定: GPT-5.6 Luna

進め方のルール:

- 最初の方針設計、分解、レビュー、不可逆な判断は、必ず最上位モデルの役割で行ってください。
- 方針が決まった後の実務制作や実装は、実務向けモデルの役割へ渡してください。
- 入力と出力が明確な下処理は、軽量モデルの役割へ渡してください。
- サブエージェントを使える環境では、明確に独立した下処理だけ軽いworkerへ逃がしてください。
- サブエージェントは節約目的でむやみに増やさないでください。各エージェントも別にモデル・ツールを使うため、分散すれば必ず安くなるわけではありません。
- 短い作業や、分けるほどでもない作業は、無理に分散せず、現在のモデル内で低い推論量で処理してください。
- 容量や制限が気になる場合は、まず作業範囲を狭め、抽出・整形・分類を軽量側へ寄せ、最終レビューだけ最上位モデルの役割に戻してください。
- モデル名が将来変わった場合は、Sol/Terra/Lunaという名前ではなく、「最上位」「実務向け」「軽量」という役割で読み替えてください。

出力形式:

1. タスク分解
2. モデル配分
3. 実行手順
4. 実行結果
5. 最上位モデル視点のレビュー

もし、あなたの環境で実際のモデル切り替えやサブエージェント起動ができない場合は、最初にその旨を明示したうえで、同じ役割分担を1つのチャット内で再現してください。

このプロンプトで変わること

このプロンプトを入れると、AIへの指示が「全部やって」から「どこで考えて、どこで作って、どこで処理するか」に変わります。

たとえば、ブログ記事を書く時なら、

• Sol: 読者の誤解、記事の切り口、構成、主張のズレを設計する
• Terra: 構成に沿って本文を書く
• Luna: 誤字、表記ゆれ、見出し一覧、内部リンク候補を整理する
• Sol: 最後に、主張がズレていないかレビューする

という流れになります。

コード修正なら、

• Sol: 何が原因か、どの方針で直すべきか判断する
• Terra: 実装する
• Luna: 差分整理、対象ファイル一覧、チェックリスト化をする
• Sol: 破壊的変更や設計のズレがないか確認する

こうなります。

この形にしておくと、毎回「プランニングはSolで、作業は軽いモデルでお願いします」と言わなくても、AI側が最初に分解してくれます。

もちろん、完全自動でモデル切り替えまでできるかは環境次第です。

でも、仮に切り替え自体が手動だったとしても、AIが最初に「これはSolで考えるところ」「ここからTerraで作るところ」「ここはLunaで捌けるところ」と整理してくれれば、人間側の判断がかなり楽になります。

今週やるなら、まず3つだけ分ける

いきなり全部の仕事を自動化しようとしなくていいです。

まずは、今週やる仕事を3つだけ見てください。

その仕事は、考える仕事ですか。

作る仕事ですか。

捌く仕事ですか。

たとえば、

この分類ができるだけで、AIの使い方は一段上がります。

モデル選びは、賢いかどうかだけで決めるものではありません。

どの仕事を、どの深さで考えるべきか。

そこから決めた方が、AIはずっと仕事の相棒になりやすいです。

関連して読んでおきたい記事

• 高性能AIを毎回使わなくていい。モデル選びは設計と作業で分ける
• AIに仕事を任せる時は、プロンプトより完了条件を渡す
• CodexとObsidianでAIを「育てて使う」実務システム
• AI時代に使われる開発サービスの違い。どこに何を任せるか

AIをうまく使う人は、プロンプトを長くしている人ではありません。

AIに任せる仕事の種類を、ちゃんと分けている人です。

一番賢いAIには、考える仕事を。

実務に強いAIには、作る仕事を。

軽いAIには、捌く仕事を。

この分け方を持っておくと、モデル名が変わっても、AI活用の軸はブレにくくなります。