CodexでAI開発を続けていると、気になってくるのが利用上限です。
便利だからと、要件整理、コード調査、設計、実装、テスト、レビューまで全部Codexに任せていると、思った以上に利用枠を消費することがあります。
そこで使えるのが、通常のChatGPTとCodexの役割を分ける方法 です。
先に結論を言うと、ChatGPTでは要件整理や調査、実装方針の作成を進め、Codexにはコード変更、コマンド実行、テスト、デバッグを任せます。Codexに「考えるところから全部やって」と頼むより、実装に使う時間とコンテキストを絞りやすくなります。
ただし、これはCodexの上限そのものを増やす裏技ではありません。Codexでなくてもできる作業を通常のChatGPTへ移し、Codexを実装に集中させる方法 です。
OpenAI Docsによると、Codexの消費量はモデルだけでなく、タスクの大きさと複雑さ、ローカルかクラウドか、コンテキスト、推論、ツール利用、検索、キャッシュなどでも変わります。プロンプトの長さだけで利用量を正確に見積もることはできません。
まず結論｜ChatGPTは設計、Codexは実装に使う
Codexの利用枠を長持ちさせたいときは、「考える工程」と「手を動かす工程」を分ける のが基本です。
役割の目安を表にすると、次のようになります。
ポイントは、コードを書く必要がない作業まで何でもCodexへ持ち込まないこと です。
仕様を考えるだけなら、通常のChatGPTで十分なケースは多くあります。一方、リポジトリの現状を読み、実際にファイルを変更し、コマンドやテストで確かめる作業はCodexが得意です。
なぜ設計と実装を分けると効率がよくなるのか
Codexに「このリポジトリを全部調べて、どう直せばよいか考え、そのまま実装して」と頼むと、コード変更に入る前にも多くの作業が発生します。
- リポジトリ構造を調べる
- 関係しそうなファイルを探す
- 現在の仕様を確認する
- 変更方法を比較する
- 影響範囲を調べる
- 実装方針を決める
もちろん、これらもCodexが得意な仕事です。しかし、要件が曖昧なまま大きなコードベースを渡すと、探索範囲と判断の選択肢が広がります。
OpenAI Docsでも、長時間のタスクや多くのコンテキストを保持するセッションは、単純なスクリプトや定型作業より多くの利用枠を使うと説明しています。
先に通常のChatGPTで「何を変えるか」「何を変えないか」「どのテストで終わりとするか」を固めておけば、Codexへ渡す範囲を狭められます。役割分担の目的は、必要な探索をゼロにすることではなく、重複した検討を減らすこと です。
ChatGPT Workへ移せばよいわけではない
「Codexを節約したいなら、同じ作業をChatGPT Workへ移せばよい」と考えるのは注意が必要です。
2026年8月30日時点のOpenAI Docsでは、ChatGPT WorkとCodexは料金、クレジット、利用上限を共有する と案内されています。対象となるワークスペースでは、ChatとWorkの利用が共有クレジットへ合算される場合もあります。
そのため、この記事では「通常のChatなら必ずCodexと別枠になる」とは断定しません。プラン、ワークスペース、機能、利用形態によって表示や扱いが変わる可能性があるためです。
大切なのは別枠探しではなく、ファイル操作やコマンド実行が不要な相談を、最初からCodexの仕事にしないこと です。通常のChatで要件整理や文章ベースの設計を済ませられれば、その段階ではCodexを呼び出さずに進められます。
利用枠の表示や対象機能は変わり得ます。実際の残量と適用範囲は、自分のChatGPTまたはCodex画面で確認してください。
GitHub連携を使うと設計前のコード確認がしやすい
ChatGPTで利用できるGitHub連携やアプリがある場合は、リポジトリ内のコード、README、ドキュメントを確認しながら設計を相談できます。
たとえば、次のような質問です。
- 現在この処理はどのファイルで行われている？
- この機能を追加するなら、変更対象になりそうなファイルはどれ？
- READMEの説明と実装に食い違いはある？
ただし、接続しただけでファイル追加、コミット、ブランチ作成まで必ずできるとは限りません 。できる操作は、利用中のアプリ、プラン、権限、ワークスペース設定で変わります。
この記事の方法では、GitHubへの自動書き込みを前提にしません。ChatGPTで作った設計を自分でMarkdownへ保存し、Codexにそのファイルを読ませるだけでも成立します。
GitHub連携が使えない場合は、関係するファイルだけをアップロードする方法でも構いません。重要なのは、AIが実際に確認した情報と、推測した情報を混ぜないこと です。
実際の進め方｜設計を短い引き継ぎ文書にする
ここからは、通常のChatGPTで設計し、Codexで実装する流れを5段階で整理します。
最新のコードを基準にする
最初に、ChatGPTが見ているコードと自分のパソコンにあるコードが同じかを確認します。
GitHub連携でChatGPTが読むのは、GitHub側に存在する情報です。ローカルで変更したのにまだ反映していない場合、ChatGPTは変更前のコードを前提に設計する可能性があります。
Gitを使っているなら、設計を頼む前に次のようなコマンドで状態を確認します。
git status -sb
未コミット・未反映の変更がある場合は、必要に応じてGitHub側へ同期するか、その差分もChatGPTへ伝えます。どのコードを正として設計したかを曖昧にしないこと が大切です。
ChatGPTがコードを読めているか確認する
GitHubを接続した場合でも、いきなり設計を任せず、最初に軽く確認します。
このリポジトリのREADMEと○○ファイルを確認し、現在の○○機能がどのファイルで実装されているか教えてください。確認できない場合は推測せず、その旨を教えてください。
ファイル名や現在の仕様が一致していれば、そのまま設計へ進めます。確認できないなら、必要なファイルを追加で渡します。
通常のChatGPTで実装計画を作る
次に、実装そのものではなく「どう直すか」を整理してもらいます。
現在のコードを確認したうえで、○○機能を追加する実装計画を作ってください。
次を整理してください。
- 現在の仕組み
- 変更するファイル
- 変更内容
- 変更しない範囲
- 実装順序
- 必要なテスト
- 想定される影響や注意点
私の説明と現在のコードが食い違っている場合は、私の説明を前提に進めず、先に指摘してください。
最後の一文が重要です。ユーザーの説明が実装と食い違っていても、AIがその前提に合わせようとすることがあるためです。
設計を短いMarkdownへまとめる
設計が固まったら、長い会話履歴をそのまま渡すのではなく、docs/implementation-plan.mdのような1つのファイルへ整理します。
入れておきたいのは、目的、現状、変更対象、実装方針、変更しないもの、テスト方法、完了条件です。設計に至るまでの議論や不採用案をすべて残す必要はありません。
OpenAI Docsも、必要のないコンテキストを削り、目的、形式、長さ、必須作業と任意改善を明確にすることを利用枠対策として挙げています。Codexへ渡すのは会議の議事録ではなく、決定事項 と考えると分かりやすいでしょう。
Codexには実装を中心に頼む
設計ファイルをリポジトリへ置いたら、Codexには次のように依頼できます。
docs/implementation-plan.mdを確認してください。現在のコードと計画に重大な矛盾がなければ、その方針に沿って実装し、必要なテストも実行してください。
計画の範囲を超える設計変更が必要な場合は、勝手に範囲を広げず理由を示してください。
最後に、変更内容、実行したテスト、残っている問題をまとめてください。
これならCodexは「そもそも何を作るべきか」という段階から考え直す必要がありません。実装中に矛盾が見つかった場合だけ立ち止まれる余地は残しておきます。
さらにCodexの利用枠を長持ちさせる4つの方法
役割分担だけでなく、Codexそのものの使い方も見直すと効果的です。次の4項目はOpenAI Docsの案内とも一致します。
簡単な作業では軽量モデルを使う
すべてのタスクに最上位モデルが必要なわけではありません。
文言変更、小さなCSS修正、既存パターンに沿ったファイル追加、明確な設計書がある実装などは、軽量なモデルでも対応できる場合があります。
2026年8月30日時点では、OpenAIは難しく曖昧な作業向けにGPT-5.6 Sol、日常的な制作やコーディング向けにTerra、高速・大量・焦点の絞られた作業向けにLunaを案内しています。モデル名は変わり得るため、難しい判断には高性能モデル、決まった作業には軽量モデル という基準を持つほうが実用的です。
AGENTS.mdを巨大な説明書にしない
Codexへ毎回読み込ませるAGENTS.mdへ、過去の経緯や細かなルールを何でも追加すると、毎回のコンテキストが膨らみます。
全プロジェクト共通のルールだけを上位に置き、特定ディレクトリで必要な指示はその配下へ分けます。OpenAI Docsも、大きなプロジェクトではAGENTS.mdを階層化して注入するコンテキストを抑える方法を案内しています。
使わないMCPやツールを常時有効にしない
外部ツールを大量につなぐと便利ですが、各MCPサーバーはメッセージへ追加のコンテキストを持ち込み、利用枠にも影響します。
そのタスクに使わないMCPサーバーは無効にし、必要になったときだけ使うようにします。ツールを減らすことは、判断対象を絞る意味でも有効です。
巨大な依頼を1回で終わらせようとしない
「サイト全体を調べ、問題を全部直し、デザインとSEOも改善する」といった依頼は、判断範囲が広くなります。
表示崩れの修正、データ取得処理の変更、テスト追加のように、成果物として区切れる単位 へ分けると、必要なファイルと完了条件を絞れます。レビューしやすく、途中で方針がずれたときも戻りやすくなります。
GitHub連携では最小権限を意識する
AIとGitHubを接続するときは、便利さだけでなく権限にも注意が必要です。
GitHub Appsは、アクセスできるリポジトリと権限を確認・変更できます。GitHub公式ドキュメントも、インストール済みアプリの権限と対象リポジトリを定期的に確認し、使わないアプリは停止または削除することを案内しています。
個人開発でも、次のような運用が安心です。
- 必要なリポジトリだけ許可する
- 不要な書き込み権限を与えない
- AIによる変更はmainへ直接入れない
- 可能ならブランチを分ける
- 差分を確認してからマージする
- テストやCIを通す
AIがコードを書けるようになったからこそ、変更を速くする仕組みと、間違った変更を止める仕組みの両方 が必要です。
この方法で勘違いしやすい3つのこと
最後に、特に誤解しやすい点を整理します。
ChatGPTを使えばCodexの枠が増えるわけではない
上限が増えるのではなく、Codex以外でできる作業を移し、Codexを呼び出す工程を減らす考え方です。Workなどのエージェント機能はCodexと利用枠を共有する場合があるため、別枠かどうかは現在のプラン表示で確認 します。
ChatGPTならGitHubを自由に変更できるとは限らない
実行できる操作は、接続したアプリ、プラン、権限、ワークスペース設定によって異なります。この記事では、コードの確認と設計に使い、書き込みはCodexへ渡す流れを基本にしています。
設計を別で作れば必ず大幅に節約できるわけでもない
小さな修正なら、最初からCodexへ任せたほうが早い場合もあります。
効果が出やすいのは、コードベースが大きい、要件が曖昧、設計検討が長いといったケースです。考える作業が大きいほど先に整理し、実装が小さいならそのままCodexへ任せる くらいの使い分けが現実的です。
まとめ｜Codexでなければできない仕事を先に見極める
Codexの利用枠を効率よく使うために大切なのは、「どうやって上限を増やすか」ではなく、Codexでなければできない仕事は何か という視点です。
要件整理や設計は通常のChatGPTで進め、決まった方針をCodexへ渡して実装する。さらに、プロンプトやAGENTS.mdを必要以上に大きくせず、簡単な作業では軽量モデルを使い、不要なMCPを減らします。
これだけでもCodexを「全部やってくれるAI」から、実装に集中してもらう開発エージェント へ変えられます。
利用枠が気になり始めたら、まずプラン変更を考える前に、自分のタスクの中で「通常のChatGPTへ移せる工程」がないか確認してみてください。直近の利用枠の変化は、Codexで激動の1週間を整理した記事でも紹介しています。
参考資料
※仕様、利用上限、対応モデルは変更される可能性があります。以下は2026年8月30日時点で確認した公式情報です。
コメント