【初心者版手順付き】Codexのレート制限を減らすために、実際に見直した使い方

Codexを使って作業していると、途中でレート制限に引っかかることがありました。

最初は正直、「何かエラーが出た」くらいにしか思っていませんでした。

でも、何度か作業しているうちに、ただ待てばいいだけではなく、そもそも自分のCodexの使い方がかなり雑だったことに気づきました。

たとえば、自分は最初の頃、Codexに対してしていたのは
「この機能を作って」
「このエラーを直して」
「全体を確認して」
「いい感じに修正して」

こういう頼み方です。

一見、AIに任せているので効率が良さそうに見えます。

でも実際には、Codex側が毎回たくさんのファイルを読んだり、広い範囲を確認したり、必要以上に長い回答を返したりして、使用量が増えやすくなっていたと思います。

調べてみると、Codexの利用制限はプランや作業内容によって変わり、コードベースが大きい作業、長時間の作業、広い文脈を持たせる作業は、より多く消費されることがわかりました。

つまり、問題は「Codexが悪い」というより、自分が毎回重い作業を投げすぎていた可能性がありました。

そこで今回は、Codexのレート制限に引っかかりにくくするために、実際に使い方を見直しました。

具体的には、

・最初にPlan Modeで作業範囲を整理する
・一度に全部作らせず、小さい単位で依頼する
・関係ないファイルまで読ませない
・AGENTS.mdに作業ルールを書いて、毎回の説明量を減らす
・「修正して」ではなく、対象ファイルと修正内容を絞って伝える
・同じ依頼を連投しない
・長い説明を毎回貼らず、必要な情報だけ渡す

こういった使い方に変えました。

この記事では、Codex初心者の自分が、レート制限で止まったあとに調べたことと、実際に見直して効果があった使い方を整理します。

まだ完璧に使いこなせているわけではありません。

ただ、以前よりは「無駄にCodexの使用量を消費しない頼み方」が少し見えてきました。

同じように、

「Codexを使っていると途中で止まる」
「レート制限の意味がよくわからない」
「Plusに入っているのに、なぜ制限があるのかと思った」
「何を減らせばいいのかわからない」
「初心者でもできる使い方の見直しを知りたい」

という人には、近い内容になると思います。

⓪ まず残りの使用量を確認する

最初にやるべきなのは、残りの使用量を確認することです。

Codexでは、設定のUsageパネルから、利用上限や残りクレジットを確認できると公式で説明されています。

自分の場合も、まずここを見るようにしました。

ここで注意したいのは、
「Plusだから無制限に使える」と思わないことです。

ChatGPT Plusに入っていても、Codexには使用量やクレジットの考え方があります。

最初はここを少し勘違いしていました。

Plusに入っていれば、Codexもずっと使えるような気がしていました。

でも実際には、使い方によって残量は減ります。

なので、作業を始める前に、

今どれくらい残っているか
重い作業を投げてもよさそうか
今日は調査だけにするか
実装まで進めるか

を確認するようにしました。

見方はcodeX左下の設定＞残りのレート制限＞5時間のところのパーセントです。
右の時間はcodeXを開いて5時間経過したときの時間で、この時間より前にレートを使い切ったら時間になるまで開発できなくなります。

初心者ほど、作業に集中していると残量を見ずに進めてしまいます。

でも、途中で止まるとかなり効率が悪いです。

特に、実装の途中でレートがきつくなると、

何を途中までやったのか
どこから再開すればいいのか
次に何を頼めばいいのか

をもう一度整理する必要が出てきます。

なので、最初に残量を見るだけでも、作業の進め方を決めやすくなりました。

① モデルとFast modeを使い分ける

次に見直したのが、モデルやFast modeの使い分けです。

CodexにはFast modeがあります。

Fast modeは処理が速くなる一方で、公式では、対応モデルの速度を1.5倍にする代わりに、GPT-5.5ではStandardの2.5倍、GPT-5.4ではStandardの2倍のクレジットを消費すると説明されています。

ここはかなり重要でした。

codeXの指示入力欄の右下モデル名が書かれている場所をクリックすると展開し、モデルや速度を変更できます。

最初は、速い方が便利だと思っていました。

でも、毎回Fast modeで作業していると、内容によってはかなりもったいないです。

たとえば、

ファイル構成を確認する
関係するファイルを一覧化する
エラー文を読ませる
修正候補を出してもらう
軽い文言修正をする

このくらいの作業なら、毎回重いモデルやFast modeを使う必要はないかもしれません。

また、GPT-5.4-Miniは、公式レート表上ではGPT-5.4と比べて入力・キャッシュ入力・出力の各クレジットが約30%です。単純な同量トークンの軽作業なら、消費をかなり抑えられる可能性があります。

ただし、ここで注意したいのは、何でもminiにすればいいわけではないということです。

設計判断や複雑な実装までminiでやると、逆に手戻りが増える可能性があります。

たとえば、

アプリ全体の設計
Google OAuthやCanva OAuthまわりの修正
Drive保存処理の変更
複数ファイルにまたがる実装
既存機能を壊したくない修正

このあたりは、軽い作業ではありません。

miniで雑に進めて、あとでバグが出て、結局通常モデルで直すことになれば、節約どころか余計に消費します。

なので、自分の中ではこう分けることにしました。

作業内容使うモデル・モードの考え方ファイル構成の確認軽めでよいエラー原因の候補出し軽めから開始単純な文言修正軽めでよい設計判断通常モデル複雑な実装通常モデル既存機能を壊したくない修正通常モデル最終レビュー通常モデル

初心者向けに一言でいうと、
軽作業は軽いモデル、重要な判断は通常モデル
という分け方です。

速さだけで選ぶと、レート消費が増えます。

安さだけで選ぶと、手戻りが増えます。

ここは、作業の重さに合わせて切り替えるのが現実的だと思いました。

② 作業を小さく分割する

次に大きく変えたのが、作業の分け方です。

以前の自分は、かなり大きな単位で頼んでいました。

悪い例はこれです。

バナー生成アプリを完成させてください。

これだと、Codexからすると範囲が広すぎます。

バナー生成アプリといっても、実際にはいろいろな要素があります。

CSV読み込み
画像生成用プロンプト作成
HTML/CSSでのテキスト合成
PNG書き出し
Google Drive保存
Google Sheets連携
Canva OAuth
Google OAuth
UI画面
エラー処理

これを一気に頼むと、Codexは広い文脈を持つ必要があります。

確認するファイルも増えます。

修正範囲も広がります。

結果として、使用量も手戻りも増えやすくなります。

そこで、作業を段階に分けることにしました。

たとえば、こうです。

Step1:
現在のファイル構成だけ確認して、不足しているファイルを一覧化してください。
変更はしないでください。

Step2:
最終PNG生成に関係するファイルだけ確認してください。
変更はしないでください。

Step3:
テキスト合成処理だけ最小実装してください。
対象外のファイルは触らないでください。

Step4:
Drive保存処理だけ、最終PNGのみ保存されるように修正してください。

この分け方にすると、Codexが一度に持つ文脈が小さくなります。

こちらも確認しやすくなります。

特に初心者にとって大事なのは、
Codexが何をしたのか追えることです。

一気に全部やらせると、あとから見ても何が起きたのかわかりません。

でも、Stepごとに分ければ、

今は調査だけ
今はPNG生成だけ
今はテキスト合成だけ
今はDrive保存だけ

というように、作業の目的がはっきりします。

これはレート節約だけでなく、ミスを減らす意味でもかなり重要だと思いました。

③ レート消費を抑える依頼のしかた

次に、Codexへの依頼文そのものを見直しました。

以前は、こういう頼み方をしていました。

全体を確認して直してください。
必要なところを修正してください。
いい感じに整理してください。

これだと、Codexがどこまで作業していいのか曖昧です。

結果として、広い範囲を見に行きます。

そこで、依頼文に制限を入れるようにしました。

たとえば、以下です。

まず既存ファイル構成を確認してください。
いきなり実装しないでください。
原因候補を最大3つに絞ってください。
修正対象ファイルを先に列挙してください。
私が指定した対象以外は変更しないでください。
package.jsonの依存追加は禁止です。
UI全体の作り直しは禁止です。
既存のGoogle OAuth、Canva OAuth、Drive保存処理は壊さないでください。
修正は最小差分にしてください。

このあたりを入れるだけで、無駄な探索や勝手な修正がかなり減ります。

特に、自分のようにコードを全部読めない初心者の場合、
「勝手に大きく変えられないこと」 はかなり大事です。

アプリ制作では、1つの機能を直しているつもりでも、別の機能が壊れることがあります。

たとえば、バナー生成アプリであれば、

画像生成は直ったけど、Google Drive保存が壊れた
テキスト合成は直ったけど、Canva OAuthが動かなくなった
UIを整理されたけど、元の入力項目が消えた

こういうことが起きると、修正にさらに時間がかかります。

そして、その修正にもまたレートを使います。

だから、最初から
触っていい場所と触ってはいけない場所を分けておく
ことが必要だと感じました。

AGENTS.mdに入れておくと毎回の無駄が減る

毎回同じ注意をチャットに書くのも面倒です。

そこで、よく使うルールはAGENTS.mdに入れておくのがよさそうです。

Codex公式でも、AGENTS.mdはCodexが作業前に読むプロジェクト用の指示・文脈として説明されており、制約や「完了とは何か」などを書く場所として使えます。

自分の場合、AGENTS.mdには以下のようなルールを入れておくとよさそうだと思いました。

## 作業ルール

- いきなり実装せず、必要に応じて先に調査・計画を出す
- 修正前に、修正対象ファイルを列挙する
- 指定されたファイル以外は変更しない
- 修正は最小差分にする
- UI全体の作り直しは禁止
- package.jsonへの依存追加は禁止
- Google OAuth、Canva OAuth、Drive保存処理は壊さない
- 既存機能に影響する可能性がある場合は、先に確認する
- 原因候補は最大3つに絞る
- 変更後は、何を変えたかを簡潔に説明する

これを毎回チャットで言うのではなく、AGENTS.mdに入れておく。

それだけでも、毎回の説明量を減らせます。

ただし、AGENTS.mdも長くしすぎると逆に読みにくくなります。

公式のベストプラクティスでも、AGENTS.mdは短く実用的な方が有用で、曖昧なルールを大量に入れるより、実際に繰り返し起きたミスを元に更新する考え方が示されています。

なので、何でもかんでも入れるのではなく、
何度も起きたミスだけをルール化する
くらいが現実的だと思いました。

④ 「調査」と「実装」を分ける

今回、一番効果がありそうだと感じたのが、
調査と実装を分けることです。

初心者の自分は、ついこう頼みたくなります。

原因を調べて、直してください。

でも、この頼み方だと、Codexは調査と実装を一気にやろうとします。

すると、原因がまだはっきりしていないのに、修正まで進むことがあります。

これが危ないです。

なので、まずは調査だけを頼むようにしました。

調査だけを頼むとき

まず調査のみしてください。
ファイル変更は禁止です。

目的は、〇〇が動かない原因候補を特定することです。

出力形式：
- 関係するファイル
- 原因候補
- 修正が必要な箇所
- 変更してはいけない箇所

この指示だと、Codexは勝手に修正できません。

まず、どこが関係しているかを整理してくれます。

こちらも、修正前に内容を確認できます。

そのうえで、次に実装だけを頼みます。

実装だけを頼むとき

前回の調査結果をもとに、〇〇ファイルの〇〇関数だけ修正してください。
他のファイルは変更しないでください。
修正は最小差分にしてください。

このように分けるだけで、余計なファイルの修正が減り、レートの節約につながりました。

Codex公式のベストプラクティスでも、複雑・曖昧なタスクでは、実装前にPlan modeで文脈を集め、確認質問をし、計画を作らせる方法が推奨されています。

自分の場合は、Plan modeまでいかなくても、まずは
調査のみ、変更禁止
と書くだけでかなり違いました。

調査と実装を分けると、次のようなメリットがあります。

分ける理由効果勝手な修正を防げる変更前に原因を確認できる対象ファイルを絞れるCodexが広く見すぎるのを防げる手戻りを減らせる間違った修正を先に防げる確認しやすい初心者でも追いやすいレート消費を抑えやすい無駄な探索や再修正を減らせる

特に、自分のようにコードを全部読めない人にとっては、
「まず調査だけ」
はかなり使いやすい考え方でした。

今回やってみてわかったこと

ここまでやってみて思ったのは、Codexのレート消費を抑える方法は、単に「使う回数を減らす」だけではないということです。

もちろん、使いすぎないことは大事です。

でも、それ以上に大事なのは、
1回あたりの依頼を軽くすること
だと思いました。

重い依頼とは、こういうものです。

範囲が広い
目的が曖昧
対象ファイルが決まっていない
変更してはいけない場所が決まっていない
調査と実装が混ざっている
長い説明を毎回貼っている

逆に、軽い依頼はこうです。

作業範囲が狭い
変更禁止が明確
対象ファイルが決まっている
原因候補を絞っている
調査だけ、実装だけに分けている
AGENTS.mdで共通ルールを固定している

ここを意識すると、Codexの使い方が少し変わりました。

前は、Codexに「全部やってもらう」感覚でした。

今は、
自分が作業範囲を決めて、Codexにその範囲だけ任せる
という感覚に近いです。

この違いは大きいです。

初心者向けに一言でいうと

Codexのレート消費を抑えるには、
一度に大きく頼まず、調査・実装・確認を小さく分けること
が大事だと感じました。

「全部作ってください」は楽です。

でも、そのぶんCodexが広く考える必要があります。

そして、広く考えさせるほど、確認も修正も重くなります。

初心者ほど、AIに丸投げした方が楽に見えます。

でも実際には、丸投げすると後で自分が追えなくなります。

だからこそ、

まず調査だけ
次に対象ファイルだけ修正
最後に差分だけ確認

という流れにした方が、結果的に早いと思いました。

次から使える判断基準

Codexに依頼する前に、以下を確認するとよさそうです。

□ 今回は調査なのか、実装なのか
□ 対象ファイルは決まっているか
□ 変更してはいけないファイルは決まっているか
□ package.jsonの変更が必要か
□ UI全体の作り直しになっていないか
□ 既存のOAuthや保存処理を壊す可能性がないか
□ 原因候補を絞ってから修正しているか
□ AGENTS.mdに毎回使うルールを入れているか
□ Fast modeを本当に使う必要があるか
□ 軽作業を重いモデルでやっていないか

このチェックを入れるだけでも、無駄なレート消費は減らせそうです。

特に重要なのは、
「いきなり実装しない」
ことです。

調査だけで済む場面は、まず調査だけにする。

実装するときは、対象ファイルを絞る。

これだけでも、かなり違うと思います。

今回のメモ

今回の内容をまとめると、以下です。

見直したこと目的残り使用量を確認する作業の進め方を決めるためFast modeを毎回使わない速さと消費量のバランスを取るためminiと通常モデルを使い分ける軽作業と重要判断を分けるため作業をStepごとに分ける一度に持つ文脈を小さくするため対象外ファイルを触らせない勝手な修正と手戻りを防ぐためAGENTS.mdにルールを書く毎回の説明量を減らすため調査と実装を分ける無駄な探索と誤修正を減らすため

レート消費を抑えるというと、最初は「なるべく使わない」ことだと思っていました。

でも実際には、
使わないことより、雑に使わないこと
の方が大事だと思いました。

Codexは便利です。

ただ、便利だからこそ、何でも一気に任せたくなります。

でも、初心者がそれをやると、どこをどう変えたのかわからなくなり、手戻りが増えます。

そして、その手戻りにもまたレートを使います。

だから、最初に作業を小さく分ける。

触っていい場所と触ってはいけない場所を決める。

調査と実装を分ける。

このあたりを意識するだけで、Codexの使い方はかなり変わると思いました。