Codexのタスクが遅くなるのはなぜ？長い会話を分ける基準と引き継ぎ方法

2026年7月30日AIコラム

Codexを使い続けていると、最初は軽快だったタスクが、いつの間にか返答に時間がかかるようになることがあります。

コマンド自体はすぐ終わっているのに、Codexが次の行動を決めるまでが長い。以前の判断を忘れたり、同じ調査を繰り返したりすることもあります。

僕自身、ひとつのタスクを長く使うことが多く、設計・実装・修正・追加調査まで、そのまま同じ場所で続けがちです。履歴が残っている安心感がある一方で、長くなったタスクをどこで分けるべきかは、あまり意識していませんでした。

そんな中、8日間継続したCodexタスクを調査し、遅さの原因と対策をまとめた投稿をXで見かけました。

この記事では、長いタスクがなぜ重くなるのか、/compactやfork、新しいタスクへの引き継ぎをどう使い分けるかを、AIじてんの制作環境に当てはめながら整理します。情報は2026年7月29日時点のものです。

今回の話題はこちらです

今回の発端は、智见AI-大鹏氏によるXの投稿です。

投稿者によると、調査対象は8日間継続して動かしていたCodexタスクでした。記録ファイルは1.3GBまで増え、圧縮後も1回あたり約98,000〜117,000トークンを処理していたといいます。

そのタスクで実行されたGitコマンドの合計時間は11秒未満でしたが、一連の処理が完了するまでには43分かかりました。

つまり、遅かったのはGitやシェルコマンドではなく、その前後でCodexが行う判断だった可能性が高い、という切り分けです。

Codexは、コマンドを実行するたびに次の行動を考える

Codexの作業は、ひとつの命令を最後まで一気に実行するものではありません。おおまかには、次の流れを繰り返します。

現在の状態を確認する
モデルが次の行動を決める
ファイルを読む・編集する・コマンドを実行する
実行結果をタスクへ追加する
モデルが次の行動を決める

たとえば、関連ファイルを探し、設定を読み、コードを修正し、テストを実行して、失敗したテストを直す場合、モデルによる判断は何度も発生します。

タスクが短ければ、扱う情報も比較的小さく済みます。しかし、過去の会話・調査ログ・コマンド出力・エラー・変更理由などが積み重なると、各判断で参照するコンテキストが大きくなります。

100,000トークン級のコンテキストを抱えた状態でモデル呼び出しが何度も行われれば、コマンド自体が数秒でも、全体では長い待ち時間になることがあります。

1.3GBの履歴すべてがモデルへ送られたわけではない

ここは数字を分けて考える必要があります。

投稿にある1.3GBは、保存されていたタスクの記録ファイルです。1.3GBすべてが、そのままモデルへの入力になったという意味ではありません。

実際にモデルが扱っていたとされるのは、自動圧縮後の約98,000〜117,000トークンです。それでもかなり大きい数字ですが、「1.3GBのテキストを毎回読み直していた」と解釈するのは正確ではありません。

また、OpenAIには、同じプロンプトの先頭部分を再利用して処理を速くするPrompt Cachingがあります。

そのため、モデルが毎回すべてをゼロから処理しているとは限りません。それでも、巨大なコンテキストを維持・圧縮し、そこから必要な情報を探しながら判断する負荷は残ります。

43分のすべてがコンテキストだけに使われたと断定することもできません。サーバーの待ち時間・ネットワーク・再試行・推論の深さなどが含まれる可能性があります。

今回の事例は、「Codex全体が遅くなった唯一の原因を発見した」というより、極端に大きくなった長期タスクで、ツール実行以外が主要なボトルネックになっていたと考えるのが自然です。

長いタスクは、速度だけでなく判断にも影響する

コンテキストが増えたときに起きるのは、速度低下だけではありません。

OpenAIのドキュメントでは、長いタスクに大量の調査メモ・テストログ・スタックトレース・コマンド出力を入れ続けると、重要な情報が埋もれて信頼性が落ちると説明されています。

この状態は、次のように呼ばれます。

Context pollution：重要な情報が大量のノイズに埋もれる
Context rot：関連性の低い履歴が増え、モデルの判断品質が落ちる

長いタスクでCodexが以前の決定を忘れたり、却下した案を再び提案したりするのは、履歴が完全に消えたからとは限りません。

情報は残っていても、必要な情報を安定して拾いにくくなっている可能性があります。

同じタスクを長く使うこと自体が悪いわけではない

ここまで読むと、タスクを短く分けたほうがよいように見えます。しかし、細かく分けすぎると、判断の経緯や現在地を毎回説明し直す必要があります。

判断基準は、タスクの期間やメッセージ数ではなく、「ひとつの成果としてまとまっているか」です。

同じタスクを続けやすい場合	新しいタスクへ分けたい場合
同じ不具合を調査・修正している	当初の問題が解決し、別の改善に移る
同じ機能を設計・実装・検証している	調査ログやエラー出力が大量に残っている
直前の判断が次の作業に必要	過去の試行錯誤の大半が不要になった
応答速度や認識に問題がない	応答が遅く、同じ調査を繰り返す
完成条件を一文で説明できる	何を完成させるタスクなのか曖昧になった

「何日使ったか」よりも、「このタスクは何を完成させるものか」を一文で言えるかのほうが、実用的な判断基準になります。

1プロジェクト1タスクではなく、1つの成果につき1タスク

ひとつのWebサイトに関する作業を、すべて同じタスクへ入れる必要はありません。

たとえば、AIじてんのようなWordPressサイトであれば、次のように分けられます。

AIじてん
├─ 記事ページの表示崩れを修正する
├─ 検索機能を改善する
├─ 表示速度を調査する
├─ 自作プラグインの脆弱性を確認する
└─ 公開前の変更をレビューする

「記事ページの表示崩れを調査し、CSSを修正してスマートフォンで確認する」までは、同じ成果に向かう作業なので、ひとつのタスクで進めやすいでしょう。

表示崩れが直った後に、同じタスクで検索機能の改修やサーバーの速度調査まで始めると、過去のCSS調査やスクリーンショットが次の仕事ではノイズになります。このタイミングは、新しいタスクへ分ける候補です。

/compact・fork・新しいタスクを使い分ける

長くなったタスクを整理する方法は、ひとつではありません。

/compactは、同じ問題を続けたいとき

Codex CLIの/compactは、過去の会話を短い要約へ置き換え、コンテキストの空きを増やす機能です。

/compact

同じ機能の実装や同じ不具合の調査を続けたいが、会話が長くなってきた場合に向いています。Codexは自動的に圧縮することもありますが、CLIでは手動で実行できます。

ただし、圧縮は要約なので、細かい判断や一時的な情報が抜ける可能性があります。圧縮後に重要な制約が守られているかは確認したほうが安全です。

forkは、別案を試したいとき

forkは、現在のタスクやチャットを複製し、別の方針を試すための機能です。

元の履歴を残したまま、「案Aを続けるタスク」と「案Bを試すタスク」を分けられます。一方で、履歴も引き継ぐため、巨大なコンテキストを軽くする目的には向きません。

新しいタスクは、古い試行錯誤を持ち込みたくないとき

同じプロジェクトを続けながら、過去の大量ログや失敗した案を切り離したい場合は、必要な状態だけをまとめて新しいタスクを作ります。

今回紹介されたcodex-handoffは、この作業を「コンテキストの船室を乗り換える」と表現しています。古いタスクは履歴として残し、新しいタスクには、次に必要な情報だけを渡します。

新しいタスクには、現在地と次の一手を渡す

手動で引き継ぐ場合は、次のようなテンプレートを使えます。

目的：
このタスクで完成させるものを書く。

現在の状態：
現在どこまで動いているかを書く。

完了済み：
調査・実装・検証が終わった内容を書く。

重要な決定：
採用した方針・守るべき制約・却下した案を書く。

変更したファイル：
確認すべきファイルやディレクトリを書く。

検証済みの内容：
実行したテスト・表示確認・確認できなかった内容を書く。

未コミットの変更：
作業ツリーに残っている変更と注意点を書く。

残作業：
まだ終わっていないことを書く。

最初に行うこと：
新しいタスクで最初に確認・実行することを書く。

最後に、次の一文を加えておくと、引き継ぎ内容と現在のファイル状態がずれていた場合に気づきやすくなります。

上記の内容だけを前提にせず、最初に現在のGit差分と対象ファイルを確認してから作業を続けてください。

新しいタスクでも同じ作業フォルダを開いていれば、現在のファイルや未コミットの変更は確認できます。ただし、なぜその変更を行ったのかまではファイルだけで分からないことがあります。

引き継ぎには、変更内容の全文ではなく、判断理由と確認先を残すのがポイントです。

codex-handoffは、引き継ぎタスクの作成を自動化する

今回公開されたcodex-handoffは、現在のタスクから次の情報を抽出し、コンパクトな引き継ぎプロンプトを作ります。

目的と、新しいタスクで最初に行うこと
完了済みの作業と現在の状態
重要な決定・制約・採用しなかった案
参照すべきファイル・Issue・リポジトリ・URL
実施済みの検証と失敗内容
残作業・ブロッカー・不安定な一時ファイル
次のタスクでも必要になるSkill

そのうえで、新しいユーザー可視タスクを作成し、古いタスクでの作業を終了します。full-historyのfork、サブエージェントへの委任、Git環境の移動とは区別されています。

投稿では、次のインストールコマンドが案内されています。

npx skills add zjp1997720/zhijian-skills \
  --skill codex-handoff \
  --agent codex \
  --global \
  --copy \
  --yes

ただし、これはOpenAI公式ではない第三者製Skillです。インストール前にGitHub上のSKILL.mdと更新履歴を読み、何を作成し、どのツールを呼び出すか確認してください。

Codexの環境によっては、Skillが必要とするタスク作成機能を利用できない場合もあります。Skillを入れなくても、同じ考え方は手動の引き継ぎプロンプトで実践できます。

長期間残すルールは、タスクの履歴へ置かない

新しいタスクへ分ける運用では、「前のタスクに書いたルールが消えるのではないか」という心配があります。

毎回必要になるルールは、タスクの会話ではなく、用途に合った場所へ残します。

コーディング規約や禁止事項：AGENTS.md
仕様や設計上の決定：READMEや設計書
現在の進捗と残作業：引き継ぎプロンプト
詳細な試行錯誤や過去のログ：古いタスク
元に戻すための変更履歴：Git

AIじてんの制作環境であれば、「本番への反映は勝手に行わない」「WordPressテーマ変更後はスマートフォン表示も確認する」といった継続的なルールはAGENTS.mdへ置きます。

一方、「今回の検索フォーム修正では、このCSSを残すとSafariだけ幅が崩れる」といった作業固有の情報は、引き継ぎプロンプトへ残します。

すべてをタスクの記憶へ任せるのではなく、ルール・仕様・進捗・履歴を分けて保管するほうが、新しいタスクでも安定して再開できます。

Codex側の改善後も、タスクを整理する意味は残る

2026年7月21日に公開されたCodex CLI 0.145.0では、長い会話の表示応答・コマンド出力の制限・巨大コンテキストのオーバーヘッド・リモート圧縮などが改善されました。

Codex Changelog（OpenAI公式）

現在のCodexが、以前とまったく同じ方法で巨大な履歴を処理しているとは限りません。アプリ・CLI・モデル・バージョンによっても動作は変わります。

それでも、無関係なログや終了済みの試行錯誤を同じタスクに残し続ければ、必要な情報が埋もれる問題は残ります。

最新版へ更新することと、タスクを成果単位で整理することは、どちらか一方ではなく両方行うのが現実的です。

まとめ

Codexのタスクが長くなると、コマンドの実行時間より、モデルが巨大なコンテキストを扱って次の行動を決める時間のほうが長くなることがあります。

ただし、長いタスクをすべて細かく分割すればよいわけではありません。同じ不具合や同じ機能を完成させる途中なら、履歴を保ったまま続ける価値があります。

判断基準は、「ひとつの成果として説明できるか」です。

同じ問題を続けるなら/compact、別案を試すならfork、古い試行錯誤を切り離して次の成果へ移るなら、新しいタスクへの引き継ぎが向いています。

僕自身の運用でも、今後は1プロジェクトをひとつのタスクへ詰め込むのではなく、ひとつの成果につきひとつのタスクを基本にしたいと思います。

まずは、明らかに重くなったタスクをひとつ選び、目的・現在地・重要な決定・残作業だけを新しいタスクへ渡してみるのがよさそうです。速度だけでなく、Codexが何を完成させようとしているのかも整理しやすくなります。

参考資料

公式情報と公開リポジトリは2026年7月29日に確認しました。投稿内の処理時間やトークン数は、投稿者が調査した個別のタスクに基づくものであり、すべてのCodex環境で同じ結果になるとは限りません。