GPT-5.6のCodexでSolを使い続けたら、利用制限がすぐ来た/追加課金で学んだTerraとの使い分け

GPT-5.6になってから、私はCodexを使って簡単なアプリを作るようになりました。

ただ、正直に言うと、最初はモデルの違いをほとんど理解していませんでした。

分かっていたのは、Solはとても賢いらしいということくらいですw

「それなら、CodexでもSolを選んでおけば間違いないだろう」

そう考えて、画面の調整やちょっとした機能追加、軽いコード修正まで、ほとんどすべてSolに任せていました。
しかも推論設定は、しっかり考えてくれそうな「非常に高い」です。

今振り返れば、毎回フェラーリのようなスーパーカーで、近所へ買い物に行ってたようなものかもしれません。

もちろん、Solの仕事ぶりには満足していました。
こちらの曖昧な指示も読み取り、複雑な内容まで考えてくれます。

ところが、困ったことが起きました。

Codexの利用制限が、思っていたよりずっと早く来てしまったのです。

アプリ開発の途中で止まるのは困るし、次のリセットまで待つこともできず、私は追加クレジットを購入しました。

そして、その追加分も使い切って、また購入・・・

気がつけば、3回ほど追加クレジットを買っていました。

現時点ではチョット笑えますが、購入しているときは「Codexは便利だけれど、ずいぶんクレジットを使うんだな」と思っていたのです。

自分のモデル選びに原因があるとは、まったく気づいていませんでした。

その後、SolとTerraの役割をあらためて確認して、ようやく分かりました。

私が作っているような簡単なアプリであれば、普段の作業はTerraでも十分に進められます。

Solが悪かったのではありません。どんな作業にもSolの「非常に高い」を使い続けていた私の使い方に問題があったのです。

🔷 Solが一番賢いなら、全部Solでいいと思っていた

GPT-5.6になり、CodexでSolが選べるようになったとき、私の考えはとても単純でした。

一番賢いモデルを使えば、失敗も少なくなるだろう。

アプリ開発では、コードの細かな違いが私には分からないこともあります。

Codexが何かを書き換えている画面を見ながら、「きっと必要なことをやってくれているのだろう」と任せる場面も少なくありません。

だからこそ、できるだけ賢いモデルを選んでおきたかったのです。

モデルの選択画面にSolとTerraが並んでいても、私の中では「Solのほうが賢いなら、こちらを選ぶのが正解」という理解でした。

Terraが何のために用意されているのか、どのような作業に向いているのかまでは、ほとんど考えていませんでした。

せっかく高性能なSolが使えるのに、わざわざTerraを選ぶ必要があるのだろうか・・・・そんな感覚だったんです。

今になって考えると、私はSolとTerraを役割の違うモデルではなく、単純に「上位モデル」と「下位モデル」のように見ていたのでしょう。

もちろん、難しいアプリを作っていたわけではありません。

私がCodexに頼んでいたのは、個人で使うアプリや、これから販売を考えている比較的小規模なアプリの開発です。

それでも、プログラミング原人のような私にとっては、どの作業が難しく、どの作業が簡単なのかを判断すること自体が簡単ではありませんでした・・・いやチンプンカンプンですｗ

それなら最初から、一番賢いモデルに任せておけば安心です。

この安心感が、Solを選び続けていた一番の理由だったのかもしれません。

🔺 簡単なアプリ開発まで「非常に高い」で任せていた

さらに私は、モデルだけでなく推論設定も「非常に高い」を選んでいました。

名前からして、しっかり考えてくれそうですよね。

「『高い』よりも『非常に高い』のほうが、細かいところまで確認して、間違いの少ないコードを書いてくれるんじゃないかな〜」私はそのくらいの感覚で選んでいました。

しかも、その設定を作業内容によって変えることもありませんでした。

アプリ全体の設計を考えるときもSolの「非常に高い」。

新しい機能を追加するときもSolの「非常に高い」。

ボタンの表示を少し直すときも、文章を変更するときも、ちょっとした不具合を確認するときも、やはりSolの「非常に高い」です。

今思えば、すべての仕事を同じ難易度として扱っていたことになります。

ただ、そのときの私は、推論設定を下げると仕事の質まで大きく下がってしまうような気がしていました。

Codexには、私の代わりにコードを読み、必要なファイルを探し、修正し、動作まで確認してもらいます。

途中で間違われるより、時間をかけてでも慎重に考えてもらったほうがいい・・・そう思っていたのです。

実際、Solはかなり頼もしく働いてくれましたよ、ホントに。

曖昧な説明から意図をくみ取ってくれることもありましたし、複数のファイルにまたがる修正も進めてくれます。

その様子を見れば見るほど、「お〜〜スゲェ〜〜！コイツぅ！やはりSolを選んで正解だったじゃん」と感じました。

ところが、私は一つ大切なことを見ていませんでした。

どれだけ賢く考えてくれるかだけでなく、その作業にどれだけの性能が必要なのかという視点です。

Solがきちんと仕事をしてくれるので、使い方に問題があるとは思いませんでした。

そして、利用制限が思った以上に早く来ても、最初はモデルや推論設定が関係しているとは考えなかったのです・・・・・・・

🔷 利用制限が早すぎる。それでも理由が分からなかった

Codexを使っていると、アプリ開発がどんどん前へ進みます♪

自分では書けないコードを作ってくれるだけでなく、エラーが出れば原因を探し、必要なファイルを修正し、動作確認までしてくれます。

私にとってCodexは、分からないことを質問するだけのAIではありませんでした。

実際にアプリを一緒に作ってくれる相棒のような存在になっていたのです。

そんな状態で、突然利用制限が来ました。

「えっ、もう・・・・・・・・・・使えないの？」

正直、最初は驚きました。

まだ作業の途中ですよ！画面を少し直したあと、新しい機能を追加しようとしていたかもしれません！あるいは、不具合の原因を調べてもらっている最中だったかもしれません。

どちらにしても、そこで止まられると困ります。

次に使えるようになるまで待てばいいのでしょうが、アプリ開発には流れがあります。

「今日はここまで進めよう」と思っているときに止まると、なかなか「では、数日後に続きをやろう」とは切り替えられません。

それに、Codexが使えないからといって、私が続きを自分で書けるわけでもありません(泣)

そこで表示されたのが、追加クレジットの購入でした・・・・

「え？つ、追加クレジットを・・・買えと・・・買えとおっしゃる？」

少し迷いましたが、開発を止めたくなかった私は、「仕方がない。続きをやるために買おう」と考えました。

購入すれば、またすぐにCodexを使えます。

実際、クレジットを追加すると作業を再開できました。

その瞬間は、モデルの選び方を見直そうとは思いませんでした。

「まぁね・・・Codexは便利だから、たくさん使えばこれくらい消費するのだろう」

その程度に考えていたのです。

🔺 一度では終わらず、3回ほど購入してしまった

ところが、追加したクレジットも、しばらくすると少なくなっていきました。

「え？？？？また？おねだり？OpenAIさん・・・欲しがるねぇ・・・ｗ」

それでも私は、Solの「非常に高い」を使い続けていました。

最初に利用制限が来たときと同じ設定のまま、同じように画面を修正し、機能を追加し、不具合を調べてもらっていたのです。

当然ながら、使い方を変えなければ状況も大きくは変わりません。

再びクレジットが足りなくなり、私はまた購入しました。

そして、もう一度。

「ん？また？リセットされるのは？5日後？・・・・待てるかぁ！」

正確な回数をきっちり記録していたわけではありませんが、気がつけば3回ほど追加クレジットを購入していました。

一度目は「開発の途中だから仕方がない」。

二度目は「あと少し進めたいから仕方がない」。

三度目になると、もはや「ここまで来たら止められない」といった感じです。

今になって振り返ると、なかなか見事な使い方をしていたと思いますwww

高性能なSolを選び、推論設定も「非常に高い」にして、クレジットが足りなくなれば追加購入する・・・しかも、自分の設定を一度も疑っていません。

Codexの画面に利用制限が表示されるたびに、「便利だけれど、ずいぶん早く使えなくなるな」と思っていました。

それでもSolを選び続けたのは、やはり性能を下げることへの不安があったからです。

Terraに変えたら、コードの間違いが増えるのではないか。

推論設定を下げたら、こちらの意図を理解できなくなるのではないか。

そんな心配がありました。

ところが、あとから考えると、私はTerraをきちんと試したうえで不安を感じていたわけではありません。

「一番賢いモデルではないから、きっと何かが劣るだろう」と勝手に思い込んでいただけでした。

その思い込みに気づかないまま、私は追加クレジットを買い続けていたのです。

そうなんです！！！問題はCodexの性能ではなく、私がモデルと推論設定の違いを理解せず、すべての作業に同じ設定を使っていたことでした。

🔷 問題はCodexではなく、私の使い分けだった

追加クレジットを何度か購入したあと、私はようやくSolとTerraの違いをきちんと調べました・・・・遅いと言われれば、ぐうの音も出ません。。

そして、そこで気づいたのは、私の理解が少しズレていたことです。

私はSolを「一番賢いモデル」、Terraを「Solより性能を抑えたモデル」と考えていました。

間違いではないのかもしれませんが、それだけでは大切な部分が抜けています。

SolとTerraは、単純に優劣だけで選ぶものではなく、担当する仕事が違うモデルだったのです。

OpenAIの公式説明では、Solは複雑で答えが一つに決まっていない仕事や、難しい判断を必要とする作業に向いています。

たとえば、アプリ全体の構造をゼロから考える、複数の問題が絡んだ不具合を調べる、曖昧な要望から最適な仕様を組み立てるといった場面です。

一方のTerraは、日常的な作業をこなす実用的な万能モデルとして位置づけられています。

Terraにも推論力やツールを使う能力があり、普段の仕事を任せるには十分な性能があります。

つまり、Solが上でTerraが下というより、Solは難所に強く、Terraは日常的な作業を効率よく進めるという違いです。

もちろん、TerraではできないことをSolなら必ずできる、という単純な話でもありません。

反対に、Terraでできる仕事をSolに頼んだからといって、間違いというわけでもありません。

ただし、必要以上に高性能なモデルを使い続ければ、その分だけ利用量とのバランスが悪くなります。

私がCodexへ頼んでいた作業を振り返ると、すべてが複雑だったわけではありません。

新しいアプリの基本設計を考えてもらう場面では、Solの深い判断力が役立ったと思います。

しかし、いったん仕様が決まったあとの画面作成や、ボタンの追加、表示内容の変更まで、同じようにSolへ任せる必要があったのかと聞かれると、そうではありません。

作るものが決まり、完成条件もはっきりしているなら、Terraでも十分に対応できます。

私は一つのアプリを作り始めたら、最初から最後まで同じモデルを使うものだと思っていました。

ところが実際には、作業の段階によってモデルを切り替えてよかったのです。

最初の設計や難しい判断ではSolを使い、方向性が固まったあとの実装はTerraへ任せる。

たったそれだけでも、Solを常に使い続ける必要はなくなります。

「OpenAIの公式モデル選択ガイド」を読んで、私はようやく「一番賢いモデルを選ぶ」のではなく、今から頼む仕事に合ったモデルを選ぶという考え方が分かりました・・・・・チ〜〜〜ン！

🔺 モデルと推論設定の両方が使用量に影響する

もう一つ、私が見落としていたものがあります。

それが推論設定です。

私が使っていたのはSolなのですが、正確には、Solの「非常に高い」を使い続けていました。

これは、難しい仕事に対して、より深く考えてもらうための設定です。

OpenAIも、複雑な仕事では推論設定を高くすると結果が良くなる可能性がある一方、時間がかかり、使用するトークンも増えると説明しています。

さらに、必要な結果を得られる範囲で低い推論設定を使い、より深い計画や分析が必要な場合に引き上げることを勧めています。

ところが私は、文字を少し変更するだけの作業にも「非常に高い」を使っていました。

「設定画面の説明文を直して」

このような明確な依頼に対しても、Solにじっくり考えてもらっていたのです。

もちろん、丁寧に考えてくれること自体は悪くないのですが、変更する場所も内容も決まっているなら、そこまで深い推論は必要ありませんよね。

まさに「フェラーリに乗って、ご近所で買い物」状態です。

私は、モデルも高性能、推論設定も非常に高いという組み合わせを、作業の難しさに関係なく固定していました。

クレジットの違いも、あとから知りました。

公式のクレジット表では、GPT-5.6 Solは100万入力トークンあたり125クレジット、Terraは50クレジットです。出力トークンもSolが750クレジット、Terraが300クレジットとなっています。

単純に比べると、Solの基準値はTerraの約2.5倍です。

ただし、実際の消費量が毎回きれいに2.5倍になるわけではありません。

使用量はモデルだけでなく、会話の長さ、読み込ませる内容、推論、ツールの使用、検索やキャッシュなど、さまざまな条件によって変わります。

そのため、私の利用制限が早く来た原因を、Solだけに決めつけることはできません。

長い会話のまま開発を続けたり、多くのファイルを読み込ませたり、何度も動作確認を頼んだりしたことも影響していたはずです。

それでも、簡単な作業までSolの「非常に高い」を使い続けていたことが、クレジットを早く消費した大きな要因の一つだったとは考えられます。

私はCodexを使いすぎたのではなく、仕事の内容に対して設定が重すぎたのです。

Solが悪かったわけでも、Codexの利用制限がおかしかったわけでもありません。

近所への買い物から長距離旅行まで、毎回同じフェラーリで出かけていた私が、燃料の減りを見て驚いていただけでした・・・・いや、燃費を考えると旧いアメ車かもしれないｗｗ

しかも、燃料がなくなるたびに追加していたのですから、今思えば少し笑ってしまいます。

でも、この失敗があったからこそ、モデル名だけで選ぶのではなく、作業の難しさや完成条件を見て設定を変える必要があると分かりました。

そして次に出てきた疑問は、とても単純です。

では、私が作っているような簡単なアプリなら、Terraでどこまでできるのだろう。

🔷 簡単なアプリ開発ならTerraで十分だった

SolとTerraの役割を知ったあと、私は自分がCodexに頼んでいる作業をあらためて振り返ってみました。

アプリ開発という言葉だけを見ると、どの作業も難しそうに感じます。

実際、プログラミングに詳しくない私にとっては、ボタンを一つ追加するだけでも簡単ではありません。

どのファイルを開き、どこにコードを書けばよいのか分からないからです。

しかし、私にとって難しいことと、AIにとって難しいことは同じではありません。

「この画面に保存ボタンを追加する」

「説明文をこの文章へ変更する」

「背景色をもう少し暗くする」

「このエラーが出ないように修正する」

このように、変更する内容や完成した状態がはっきりしていれば、Codex側で一から仕様を考える必要はありません。

既存のコードを確認し、該当する場所を見つけ、指示された内容へ変更して、問題がないか確かめる。
こうした日常的な作業であれば、Terraでも十分に進められます。

先にも触れましたが、私は「アプリを作るのだから、常に一番賢いモデルが必要だ」と考えていました。

でも、アプリ開発にはさまざまな段階があります。

全体の構造を考える作業もあれば、決まった設計に沿って画面を作る作業もあります。

原因不明の重大な不具合を調べることもあれば、ボタンの文字を変えるだけのこともあります。

これらをすべて同じ難易度として扱う必要はなかったのです。

もちろん、Terraを使えば必ずうまくいくという意味ではありません。

Terraでも間違えることはありますし、動作確認や修正が必要になる場合もあります。

ただ、それはSolで、高性能なモデルを使っているからといって、確認せずにすべて任せてよいわけではありません。

それなら、普段の作業はTerraへ任せ、必要な確認をしながら進めていき、難しい問題が出たときだけSolへ切り替えるほうが、私の使い方には合っています。

なんだぁ・・毎回Solへお願いしなくても、アプリ開発は進められるじゃん・・・そう分かっただけで、モデルを切り替えることへの不安はかなり小さくなりました。

🔺 仕様が固まるほどTerraを使いやすくなる

同じアプリを作る場合でも、開発の最初と途中では、Codexに頼む仕事の内容が変わります。

たとえば、まだ構想しかない段階では、考えることがたくさんあります。

• どのような画面が必要なのか

• どの機能を初回版へ入れるのか

• データをどこへ保存するのか

• MacとWindowsの両方へ対応するのか

こうした段階では、選択肢が多く、正解も一つではありませんし、こちらの希望も曖昧なので、Codexには意図をくみ取りながら設計そのものを考えてもらう必要があります。

このような場面では、Solの深い推論が役立ちますが、設計が決まり、仕様書ができたあとは状況が変わります。

作る画面、必要な機能、保存方法、完成条件が決まっていれば、Codexが迷う範囲も狭くなります。

「何を作ればよいか」から考えてもらうのではなく、決まった内容をどのように実装するかという仕事になるからです。

ここまで来れば、Terraを使いやすくなります。

つまり、モデル選びはアプリ単位で決めるものではありませんでした。

「このアプリは難しそうだから、最初から最後までSol」
「このアプリは小さいから、すべてTerra」

そのように固定するのではなく、同じアプリの中でも作業に合わせて切り替えればよかったのです。

• 最初の設計ではSolを使い、仕様が固まったらTerraへ交代する

• 開発中に原因の分からない問題が出てきたら、そこだけSolへ相談する

• 問題が解決し、再び明確な実装作業へ戻ったら、Terraへ切り替える

こう考えると、SolとTerraは競い合うモデルではなく、同じ開発を交代しながら進める担当者のようにも見えてきます。

私はそれまで、Solを選ばないことを「性能を下げること」のように感じていました。

Terraへ切り替えるのは、わざわざ仕事に合っていない担当者へ任せることだと思っていたのです。

しかし、それは私の思い込みでした。

仕様が決まったあとの日常的な作業なら、Terraはむしろその仕事に合っています。

Terraを使うことで、私は性能を妥協したのではなく、ようやく仕事に合った担当者へ渡せるようになったのです。

もっと早く気づいていれば、追加クレジットを3回ほど買わずに済んだかもしれません。

まあ、そのおかげでモデルの使い分けを本気で覚えたのですから、少し高めの授業料だったと思うことに・・・・・します(冷笑)

🔷 今はTerraを普段使いし、Solは難所だけにした

モデルの役割が分かってから、私はCodexの使い方を変えました。

現在は、普段のアプリ開発にはTerraの「高い」を使うことにしています。

仕様書に沿って画面を作る、機能を追加する、表示を調整する、原因がある程度絞れている不具合を直すといった、日常的な作業は、まずTerraへ任せます。

「高い」を選んでいるのは、コードの修正だけでなく、関連するファイルの確認や動作チェックまで含めて、ある程度しっかり考えてもらいたいからです。

ただし、これも絶対ではなく、変更する場所と内容が明確で、「この文章を差し替える」「ボタンの色を変える」といった軽い作業なら、推論設定を一段下げてもよいでしょう。

私は以前、設定を下げることを少し怖がっていました。

しかし、必要なのは常に深く考えてもらうことではありません。作業に必要なだけ考えてもらうことです。

毎回同じ設定へ固定するのではなく、仕事の内容を見て少しずつ調整する。これだけでも、クレジットの使い方はかなり変わってくるはずです。

🔺 Solへ切り替えるのは本当に難しい場面だけ

もちろん、Solを使わなくなったわけではありません。

私にとってSolは、普段使いのモデルから、難しい場面で頼る切り札へ変わりました。

Solへ切り替えるかどうかは、次の3つで考えます。

• 作業そのものが難しいか

• 仕様や完成条件が曖昧ではないか

• 判断を間違えた場合の影響が大きいか

たとえば、新しいアプリの構造をゼロから考える場面では、まだ正解が決まっていません。
必要な機能を選び、保存方法や将来の拡張まで考える必要があります。

このような設計段階では、Solの深い推論が頼りになります。

また、原因が分からない重大な不具合や、複数の機能が絡んでいそうな問題も、Solへ相談したい場面です。

一方で、仕様書があり、作るものが決まっているなら、まずTerraで進めます。途中でTerraが行き詰まったとしても、その時点でSolへ交代すればよいのです。

この使い方なら、最初から最後までSolを使い続ける必要はありませんしね！

Terraで日常の作業を進め、難所に来たらSolへ相談する。問題が解決したら、またTerraへ戻す。

今の私には、この役割分担が一番分かりやすく感じられます。

Solを選ばないことは、性能を妥協することではなく、Solにしか任せられない難しい仕事のために、出番を残しておくことでもあるのです。

🔷 高性能モデルは、必要な場面で使ってこそ頼もしい

今回の失敗で、私はモデル選びの考え方が大きく変わりました。

以前は、「どのモデルが一番賢いのか」ばかり気にしていましたが、本当に考えるべきだったのは、今から頼む仕事には、どの程度の性能が必要なのかということです。

仕様が決まっていて、完成した状態も説明できるなら、まずTerraへ任せてみる。

アプリ全体の設計を考える、複数の選択肢から方針を決める、原因の分からない問題を調べるといった難しい場面ではSolへ切り替える。

これなら、モデル選びで毎回悩む必要もありません。

私のようにプログラミングが詳しくない人間は、Codexに頼む作業は何でも難しく見えます。

でも、ボタンを一つ追加する作業と、アプリ全体の構造を考える作業では、Codexに求められる判断の深さが違います。

私にとって難しいかどうかではなく、Codexが新しく判断しなければならないことが多いかどうか・・・

この見方をすると、Solへ切り替える場面も分かりやすくなります。

もちろん、最初にTerraを選んでうまく進まなければ、途中でSolへ交代して構いません。

一度選んだモデルを、最後まで使い続ける必要はないのです。

モデル選びに迷ったら、まずTerraで進めてみる。難しいと感じたところだけSolへ相談する。

今の私には、このくらいシンプルな使い方が合っています。

🔺 一番賢いモデルを選ぶことが、一番賢い使い方とは限らない

私は、Solを使ったことを悔やんでいるわけではありません。

Solがこちらの曖昧な意図をくみ取り、複雑な内容まで考えてくれたからこそ、進められた事もあります。

問題だったのは、Solを使ったことではなく、Solが必要ではない場面まで使い続けていたことです・・・しかも、推論設定はずっと「非常に高い」・・・

利用制限が来れば追加クレジットを購入し、それでも設定は変えない。

今振り返ると、ホントに、なかなか豪快な使い方でしたｗｗｗ

追加クレジットを3回ほど購入したあとで、ようやく「もしかして、モデルの使い方が違うのでは？」と気づいたのですから、少し遅かったですよね〜・・・バカですよねぇ〜〜〜ｗ

ただ、この経験がなければ、私は今でも「Solが一番賢いなら、全部Solでいい」と考えていたかもしれません。

追加クレジットは戻ってきませんが、モデルの使い分けを覚えるための授業料だったと思うことにします・・・少々高めでしたが

もしCodexの利用制限が思ったより早く来ると感じているなら、「使いすぎた」と考えるだけでなく、普段の作業に対してモデルや推論設定が重すぎないかも確認してみるとよいかもしれません。

すべての人にTerraが合うわけではありませんし、作っているアプリや作業内容によって、必要なモデルは変わります。

それでも、毎回Solの「非常に高い」を選ぶ前に、「この仕事は本当にSolでなければ難しいのか」と一度考えるだけで、クレジットの使い方は変わるはずです。

高性能なモデルは、いつでも使い続けるから頼もしいのではありません。

本当に必要な場面で使えるからこそ、頼もしい。

そして私はようやく、一番賢いモデルを選び続けることが、一番賢い使い方とは限らないと気づきました。

できれば、追加クレジットを3回買う前に気づきたかったところです・・・・・(反省)ｗｗ