私がやったこと
上限に達しても数分で作業を再開できるように、次の3つを用意しました。
- 残量を常時表示して、切り替えの時期を自分で判断できるようにする
- 作業状態をワークログ（目標と進捗を書き残したファイル）に書かせて、会話履歴に依存しないようにする
- ルールと設定の置き場を1つにまとめ、両方のツールから参照させる
まだ動くうちに引き継ぎ用のファイルを書かせておくのが要点です。上限に達したあとでは、この操作自体ができません。
対応方針
コーディングツールを主に使うという前提
私は資料作成や調べものも含めて、普段の作業の多くを Claude Code で進めています。作業の内容に応じてモデルを使い分けられますし、手順や決めごとをファイルに書いておいて毎回読ませられるからです。チャット画面ではこの設定を持ち回れません。
この記事の仕組みも、そこから来ています。設定をファイルで持っているので、別の会社のツールに同じものを渡せます。チャット画面だけで作業している場合、引き継げるものが会話しかないため、この方法は取れません。
Claude の定額プランにある5時間枠と週次枠
2026年8月8日時点で、約5時間で回復するローリングの枠と、曜日と時刻が固定の週次の枠があります。チャットもデスクトップアプリもコーディングツールも、すべて同じ枠から消費されます。資料作成に時間を使った日に開発が動かなくなるのはこのためです。
何メッセージまで使えるという固定値は公開されていません。コスト管理のドキュメントによると、毎回のやりとりで会話全体がまとめて送信されるためです。難しい作業をしたから減るというより、扱う情報量が多く、やりとりの回数が多いと減ります。
私の実測にもとづくと、消費が重いのはこの順でした。公式の数値ではありません。
短いチャットでの質疑
< 小さなコード修正
< スライド数枚 / 小さな表計算ファイルの要約
< 長時間のコーディング
< プレゼン資料を何度も修正する作業
< リポジトリ全体を読ませて長文ドキュメントを作成する作業
上限に達する原因は、たいてい下の2つの作業です。2026年5月6日の発表で5時間枠は2倍になりましたが、この2つを続ければ達します。
作業状態をファイルに残す理由
会話の履歴はツールごとに閉じているため、別のツールからは読めません。そこで、作業状態をファイルとして書かせることにしました。コードの変更自体は変更状況と差分を見せればおおよそ伝わるので、書かせるのは意図の部分です。着手前に課題管理システムに項目を立てておくと、そこにも意図が残ります。
書かせる内容は状態だけにして、時系列の日記にはしません。項目は、目標、完了したこと、現在地、次にやること、決めたこと、変更したファイル、検証の状況です。作業が完全に終わったらファイルを削除します。
設定とルールの正本を1か所に置く理由
Codex CLI には /import という機能があり、Claude Code の設定をまとめて取り込めます。公式ドキュメントによると、指示ファイル、設定ファイル、拡張機能、外部サービス連携の設定、直近30日のチャット履歴まで移せます。
ただしこれは移行のための機能で、実行した時点のコピーになります。そのあと片方の設定を変更すると、もう片方は古いままです。2つのツールを行き来する運用には合いませんでした。
そこで、ルールと技能の置き場を1つ作り、両方のツールからシンボリックリンク（別の場所にあるファイルを、そこにあるかのように見せる仕組み）で参照させています。片方を直せば両方に反映されます。
具体的な使い方
上限が近づいた日の切り替え方
始業時に残量表示を見て、その日に入れる作業を決めます。週次枠が4割を超えている日は、リポジトリ全体を読ませる作業を入れません。午前は開発に使い、機能を1つ、テストまで書かせます。
昼に資料作成をデスクトップアプリで行うと、開発と同じ枠を消費するため、5時間枠が6割を超えます。午後の作業中に8割を超えた時点で、Claude Code にワークログを書かせ、そこでいったん閉じます。直後に Codex CLI を起動し、ワークログと変更状況を読ませて実装を続けます。ここまでで数分です。
夕方まではそちらで作業し、翌朝、5時間枠が回復していれば Claude Code に戻します。戻すときの指示は手で打っています。戻る頻度が低いためです。
残量表示は画面下部に常時出しています。モデル名、5時間枠、週次枠、作業中の情報量、作業ブランチが並びます。
Opus 5 | 5h 72% | 7d 41% | ctx 28% | main
この形にして、上限に達する時点が事前に分かるようになりました。以前は作業の途中で上限に達し、その日の残り時間が使えませんでした。引き継ぎのために人が書く量もゼロになっています。以前は目標と進捗と設計判断を、担当者が思い出して書き直していました。
消費の大きい作業を入れる時間帯
原則は、枠に余裕があるほうのツールで作業することです。そのうえで、リポジトリ全体を読ませるような情報量の多い作業は、始業直後か週次枠が戻った直後に回します。消費が大きいうえ、途中で止まると再開の手間も大きくなるためです。
ワークログの項目を固定する理由
書く側も読む側も毎回同じ場所を見るので、探す手間がありません。
自由に書かせると、その日の会話の要約になってしまい、次に何をするかが書かれていないことがありました。項目を決めてからは、そこが抜けなくなりました。
決めごとを変えるときの修正箇所
ルールの正本を1か所に置いているので、決めごとを変えるときは1つのファイルを直すだけで両方のツールに反映されます。
以前は、片方に書いた決めごとがもう片方に無く、同じ指摘を2回することになっていました。
手順
ここから先は、実際に構築する方向けの内容です。
1. 切り替え先のツールを入れる
パッケージ管理ツールから導入し、契約しているアカウントでログインします。手元の版は codex-cli 0.147.0 です。
brew install --cask codex
codex --version
codex login
2. 共通の設定を書く
ユーザー設定は ~/.codex/config.toml に置きます。運用で必要になった項目です。
# 意図せず従量課金側へ切り替わるのを防ぐ
forced_login_method = "chatgpt"
# リポジトリの中は書かせる。パソコン全体は触らせない
approval_policy = "on-request"
sandbox_mode = "workspace-write"
# 専用のルールファイルが無い既存プロジェクトでは、もう一方のルールを読ませる
project_doc_fallback_filenames = ["CLAUDE.md"]
実務で重要なのは approval_policy と sandbox_mode の2行です。サンドボックスは、ツールが触ってよい範囲をあらかじめ限定しておく仕組みで、書き換えてよい範囲をリポジトリの中に限っておかないと想定外のファイルに手が入ります。
3. 引き継ぎ前提のルールを決める
ルールの正本を AGENTS.md に置き、Claude Code 側のファイルからは参照するだけにします。
そのうえで、ワークログを書かせる指示を設定ファイルに入れます。この設定はデスクトップアプリと共有されてしまうので、プロファイルという機能を使い、CLI でだけ読まれるファイル（~/.codex/cli.config.toml）に分けています。指示の全文は原典に載せています。
ワークログはリポジトリに登録しない設定にします。作業中の一時ファイルなので、履歴に残す必要がありません。
4. 残量表示を出す
Claude Code には表示を作るコマンドがあり、日本語で内容を伝えると、スクリプトの生成から設定ファイルへの登録までが自動で行われます。
/statusline モデル名、5時間の利用率、週次の利用率、コンテキスト使用率、gitブランチを出して
まとめ
生成AIの定額プランは、重い作業を続けると上限に達し、回復までの待ち時間が出ます。困るのは上限そのものより、止まったときに引き継ぐ情報が担当者の記憶とチャット画面にしかないことです。
用意したのは、残量の常時表示、作業状態を書き出すワークログ、両方のツールから読む設定の正本です。どれも上限に達する前に整えておく必要があります。あわせて、普段の作業をコーディングツールに寄せておくことが前提になります。設定と手順をファイルで持っていないと、別のツールに渡せるものが会話しか残りません。
AIに任せきりにして成果物を確認しない進め方は勧めません。引き継ぎの仕組みは、把握の一部を人の記憶からファイルへ移すためのものです。
記載した設定と数値は2026年8月8日時点の私の環境にもとづくもので、会社共通の仕組みでも、公式の推奨構成でもありません。利用上限の条件は変わります。
参考リンク
- Use Claude Code with your Pro or Max plan（2026年8月28日確認）
- Manage costs effectively（2026年8月28日確認）
- Customize your status line（2026年8月28日確認）
- Import from another agent（2026年8月28日確認）
- Codex quickstart（2026年8月28日確認）
- 設定ファイルの全文とコマンドの対応表は Zenn に掲載しています。
