Codexが重い原因と対処｜0.147.0・Windows・長い会話の確認

「Codexが重い」は四つの症状に分ける

Codexが重いと感じたとき、最初からモデルの能力や回線のせいにすると、対処が逆になることがあります。入力した文字が画面に出るまで遅いなら端末UI、入力はすぐ届くのに回答が返るまで長いならモデルや会話の文脈、特定のフォルダーだけで待たされるならファイル探索、会話を変えると直るなら履歴の蓄積を疑います。似た「遅い」でも、観測する場所が違います。

切り分けでは、同じ短い依頼を新しい会話と現在の会話で比べます。短い依頼でもキー入力が引っかかるなら、文脈を削る前に表示や端末を確認します。入力は軽いのに長い依頼だけが遅いなら、対象ファイルの範囲と会話の長さを見ます。原因を一つに決めつけず、症状、再現する条件、直った条件の三つを残すと、更新後の比較もしやすくなります。

Step 1: 表示の遅さと返答の遅さを分ける

まず、Codexの入力欄へ短い文字列を入力し、表示が追いつくかを見ます。文字が数秒遅れて現れる、カーソルが飛ぶ、変換中の日本語が崩れるという場合は、モデルが回答を考えている時間ではありません。ターミナルの描画、フォント、入力方式、表示領域を切り分けるため、同じ端末で別の軽い入力を試すと比較しやすくなります。

反対に、入力はすぐ表示され、送信後の待ち時間だけが長いなら、次に確認するのは会話の長さとモデルです。空の会話で「現在の作業場所を確認して」といった短い依頼を送り、すぐ返るかを見ます。新しい会話では速く、長い会話だけで遅いなら、端末の交換や再インストールより文脈の整理が先です。

Step 2: ファイル範囲と会話履歴を分ける

同じ会話で大きなリポジトリ全体を調べる依頼を続けていると、Codexが参照するファイルと、それまでの指示が増えます。そこで、対象を一つのフォルダーや一つのエラーに絞った短い依頼を送り、待ち時間が変わるかを確かめます。対象を狭めたときだけ改善するなら、Codex自体が壊れているのではなく、読み込ませる範囲が広すぎる可能性があります。

会話履歴の影響を見るには、同じ作業を新しい会話で最小限の前提だけ伝えて試します。新しい会話でも同じフォルダーだけ遅いならファイル数、シンボリックリンク、外部ドライブ、権限を確認します。新しい会話で軽くなるなら、直前の依頼をすべて持ち越さず、決定事項と再現手順だけを短くまとめてから続けるのが有効です。

0.147.0で確認したい長い会話と端末の更新

Codex CLI 0.147.0は2026年8月7日に公開されました。この版では、会話を永続的なセクションに分けて手動で並べ、長い履歴を少しずつ閲覧できるようになっています。長い会話の全履歴を一度に眺める負担を減らす方向の変更ですが、セクション機能がモデルの推論時間そのものを短くするとは限りません。表示の重さと回答の重さを分けて評価する必要があります（出典: https://github.com/openai/codex/releases/tag/rust-v0.147.0 ）。

同じリリースには、端末入力が失われたり停止したりする場面、日本語や絵文字などの描画、Windowsの裏で動くプロセスとファイルパスの扱いに関する修正も含まれます。更新後に「重い」と感じた場合、機能が増えたからと決める前に、表示が止まるのか、入力だけが止まるのか、処理の完了を待っているのかを分けます。版番号と症状を一緒に記録することが、変更の影響を見誤らない近道です。

Step 3: 版番号を確認する

Codex CLIでは、まず次のコマンドで手元の版番号を確認します。

codex --version

表示された番号が0.147.0より前なら、0.147.0の修正をまだ利用していない可能性があります。ただし、更新すれば必ず速くなるわけではありません。更新前の症状を「入力が遅い」「回答が遅い」「特定のフォルダーだけ遅い」のように記録してから比較します。公式リリースページには版番号と変更内容が掲載されているため、番号だけでなく変更の説明まで確認します（出典: https://github.com/openai/codex/releases ）。

Step 4: 会話のセクションを整理する

0.147.0以降でセクション機能が表示される場合は、調査、修正、検証のように話題を分けます。これは会話を削除する操作ではなく、長い履歴を見つけやすくするための整理です。古い指示が現在の依頼に不要なら、重要な前提だけを新しい会話へ移し、履歴を増やし続けないようにします。

セクションを作っても回答の待ち時間が変わらない場合、それは不具合とは限りません。セクションは見通しを良くする機能であり、モデル、推論の深さ、読み込むファイルの量を直接変える機能ではないからです。表示は軽くなったが返答は遅い、またはその逆という結果もあり得るため、二つの時間を別々に測ります。

まず測るCodex重さの切り分け手順

原因を推測する前に、同じ依頼を条件だけ変えて比べます。測るといっても厳密なベンチマークを作る必要はありません。会話名、版番号、選択モデル、対象フォルダー、送信から最初の返答までの体感、完了までの体感を短く残せば、再現条件が見えてきます。条件を一度に複数変えると何が効いたか分からなくなるため、最初は一つだけ変えます。

Step 5: /status で状態を記録する

長い会話で重いときは、まず /status を開き、現在のモデル、文脈の使用状況、作業場所などを確認します。表示される項目はクライアントの版や利用面によって異なる可能性があるため、数値を絶対的な基準にせず、同じ会話の前後を比べるための記録として使います。文脈の余裕が少ない状態なら、依頼を短くするか、区切りのよい場所で会話を整理します。

公式のスラッシュコマンド一覧では、/status は現在の状態を確認するコマンドとして案内されています。画面が重くてメニューを開きにくい場合は、入力の遅さ自体を症状として残します。状態表示が出るまでの時間と、表示された後に依頼へ答える時間を混同しないことが大切です（出典: https://developers.openai.com/codex/cli/slash-commands ）。

Step 6: 文脈を整理して同じ依頼を再試行する

話題が一区切りしたら /compact を使い、これまでのやり取りを要約してから同じ短い依頼を試します。圧縮後に速くなったなら履歴の長さが影響していた可能性があります。ただし要約では細部が省かれることがあるため、ファイル名、再現コマンド、未解決のエラー、採用した判断を先に短く残しておきます。重要な情報を要約に任せきりにしないことがポイントです。

圧縮しても変化がないなら、別の会話を開いて同じ依頼を試します。新しい会話で速くなった場合は、必要な前提だけを短く移します。新しい会話でも遅い場合は、対象ファイルを一つに限定し、モデルや端末表示へ進みます。順番を飛ばさず、どの段階で変化したかを記録すると、無関係な設定を大量に変更せずに済みます。

Step 7: モデルと推論の負荷を分けて見る

難しい設計判断や大規模な変更では、回答の正確さを優先する設定ほど待ち時間が長くなることがあります。軽い名前変更や一つのテスト確認で同じ設定を使う必要はありません。まず小さな依頼で、モデルを変えずに対象範囲だけを狭めます。それでも遅いときは、現在のモデルと推論設定を記録したうえで、選択肢にある軽い設定との違いを一件の依頼で比べます。

Codex CLIのコマンドリファレンスでは、--model や -m でその起動時のモデルを指定でき、設定ファイルやプロフィールの既定値を上書きできると説明されています。毎回設定を大きく変えるのではなく、同じ短い依頼で一つの条件だけ比較してください。速さだけでなく、出力の修正回数や確認に要した時間も合わせて見ると、単純な秒数だけではない判断ができます（出典: https://developers.openai.com/codex/cli/slash-commands ）。

Step 8: ファイル探索を狭める

「プロジェクト全体を調べて」と頼む前に、エラーが出るファイル、呼び出し元、関連テストの三つ程度から始めます。対象を明示し、変更してよい範囲と読んでよい範囲を分けると、Codexが確認する場所を絞りやすくなります。大きな生成物、依存ライブラリ、ログ、ビルド出力が同じ場所にある場合は、必要なものだけを指定して比較します。

探索範囲を狭めて速くなったなら、次の依頼で少しずつ範囲を広げます。最初から全体を渡して結論を急ぐより、狭い事実を確認しながら広げる方が、待ち時間と読み違いの両方を抑えられます。ファイル数が少ないのに特定の場所だけ遅い場合は、保存先が外部ドライブか、パスに日本語や長い階層が含まれるかも確認します。

WindowsでCodexが重いときの確認点

0.147.0の公式リリースには、Windowsの裏で動くプロセスを適切に止める修正と、Windowsのファイルパスを一貫して扱う修正が記載されています。Windowsでだけ処理が終わらない、閉じたはずの作業が残る、特定のパスで待たされるという場合は、モデルを変える前に版番号とパスを確認します。MacやLinuxで同じ依頼を試せるなら、環境差の確認にもなります。

一方、入力中の日本語が遅い、カーソルだけが乱れる場合は、回答生成とは別の表示問題です。0.147.0には日本語文字や絵文字、画面端付近の描画とカーソル位置に関する修正もあります。ターミナルを変えると直るのか、短い会話でも起きるのか、英数字だけでは起きないのかを分けて記録すると、依頼内容の問題と端末の問題を混ぜずに済みます（出典: https://github.com/openai/codex/releases/tag/rust-v0.147.0 ）。

Step 9: パスとプロセスを確認する

作業フォルダーを短いローカルパスへ移し、同じ短い依頼を試します。移動が難しい場合は、実際に開いているフォルダーの場所、ドライブの種類、シンボリックリンクの有無を記録します。Windowsのパス区切りや大文字・小文字の違いが、ツールやテストの呼び出し先を変えることもあります。処理が終わらないときは、画面に見える最後の操作と、裏で残っているプロセスの有無を確認します。

パスを短くしても変わらないなら、ファイルの量と依頼の範囲を戻します。問題が解消した状態から、一つずつ元の条件を加えると原因を絞れます。設定を一度に初期化するより、作業場所、入力、モデル、文脈の順に比較した方が、元の使いやすい状態へ戻しやすくなります。

Step 10: 日本語入力と表示を切り分ける

短い日本語を入力し、変換確定前だけ遅いのか、確定後の英数字入力も遅いのかを見ます。確定前だけなら入力方式や端末表示、確定後も遅いならCodexの入力処理や画面全体を疑います。0.147.0の修正対象には日本語文字、絵文字、リンク、画面端近くの文字が含まれるため、特定の文字だけ崩れるときは文字列を残して公式リリースの変更と照合します。

表示の問題と処理の問題を区別するため、同じ依頼を別の端末アプリから送り、回答が返るまでの時間を比べます。別の端末では速いなら、依頼やモデルより表示経路の差が大きい可能性があります。どの端末でも遅いなら、会話、ファイル、モデルの順に戻って確認します。

Step 11: 版更新後は以前の設定を比較する

版を更新した直後に重くなった場合は、config.toml のモデル、推論設定、サンドボックス、端末表示の項目を更新前と比較します。設定ファイルに書かれた値と、その場だけ指定した値が違うこともあるため、codex --version と一緒に起動方法を残します。公式リファレンスでも、コマンドラインの -c key=value はその起動に対する上書きとして説明されています。

比較のために権限を広くする設定へ変更するのは、速度問題の確認として適切とは限りません。ファイル処理が遅いからといって確認範囲を無制限に広げると、原因が分からないまま別のリスクを増やします。まずは同じ権限と同じフォルダーで、版、会話、モデルだけを比較してください（出典: https://developers.openai.com/codex/config-reference ）。

重さを減らす依頼の書き方

Codexの待ち時間を減らすには、設定を変える前に依頼の境界をはっきりさせます。「全部見て直して」では、どのファイルを読むか、どこまで変更するか、何をもって完了とするかが広すぎます。対象ファイル、再現条件、変更してよい範囲、実行してほしい確認、完了時に返してほしい内容を一つの依頼にまとめると、探索と往復を小さくできます。

Step 12: 一度の依頼を小さくする

最初の依頼では、原因の仮説を確定させるより、事実を集めます。たとえば「src/auth/session.ts で発生する例外の呼び出し元を調べ、変更はせず、関係するテスト名と原因候補を三つ以内で示して」と指定します。読み取りだけの確認が終われば、次の依頼で変更範囲を一つに絞れます。調査と変更を分けると、長い返答や不要なファイル確認を減らしやすくなります。

完了条件も短く書きます。「関連テストを一つ実行し、失敗した場合は原因を説明する」「変更ファイルを三つ以内にする」のように、確認できる形にします。結果を短く返してもらえば、次の判断に必要な情報だけが会話に残ります。これが文脈の膨張を抑え、Codexが重いと感じる状況の再発を減らします。

Step 13: 期待する出力と確認範囲を先に書く

依頼文の末尾に、返してほしい項目を明記します。変更したファイル、実行した確認、未確認の点、次に人が見るべき点の四つを指定すれば、長い説明を読み続ける必要が減ります。必要な差分だけを返すよう求めることは、精度を下げることではなく、判断に使う情報を整えることです。

また、無関係なファイルや生成物を対象から外す理由も書きます。Codexに渡す情報が少なすぎると原因を見落としますが、多すぎると文脈と待ち時間が膨らみます。最初は狭く、足りない事実が見つかったら追加するという順番を守ると、速さと正確さのバランスを調整できます。

改善しない場合の判断

ここまで確認してもCodexが重いなら、症状を「どの環境でも起きる」「特定の会話だけで起きる」「特定のフォルダーだけで起きる」「入力表示だけで起きる」に分類します。どの環境でも短い依頼が遅いなら、利用中のサービス状態や版の既知の問題を公式情報で確認します。特定の会話だけなら履歴の整理、特定のフォルダーだけならパスとファイル量、入力表示だけなら端末の確認が中心です。

更新や設定変更を試すときは、一度に一つだけ変え、元へ戻せるよう変更前の値を残します。問題が消えたとしても、どの変更が効いたか分からなければ次に同じ症状が出たとき再現できません。公式のリリースノート、CLIリファレンス、設定リファレンスを見ながら、版番号と条件をセットで記録します。

Step 14: 再現条件を残す

再現条件には、日付、Codexの版番号、OS、端末アプリ、モデル、会話が新規か継続か、対象フォルダー、送った依頼の要約を含めます。本文をそのまま保存できない場合でも、入力が遅いのか、送信後が遅いのか、特定のファイル操作で止まるのかを書きます。これだけで、別の環境や別の版と比べるための材料になります。

画面が固まった場合は、最後に見えた表示、最後に入力した文字、待ち始めた時刻を残します。再起動して症状が消えても、原因が解消したとは限りません。次に同じ条件を一つずつ再現し、どの時点で重くなるかを確かめることで、偶然の回復と本当の改善を区別できます。

Step 15: 更新と切り戻しを分ける

更新には、既知の修正を取り込む利点があります。一方、更新した直後に挙動が変わったなら、更新前の版番号と設定を参照できる状態にしておきます。公式の変更内容に自分の症状と近い項目があるかを確認し、該当する場合は新しい版で再現するかを見ます。該当しない場合は、すぐ版だけを疑わず、会話、モデル、ファイル、端末を順に戻します。

切り戻しを検討するときも、利用できる版や手順は公式の配布元で確認します。設定を消して最初からやり直す前に、現在の config.toml と再現条件を保存しておくと、復旧後の比較ができます。Codexが重いという感覚を、版番号と条件のある記録へ変えることが、次の修正を早くする一番確かな方法です。

まとめ

Codexが重いときは、まず入力表示、回答待ち、会話履歴、ファイル探索のどこが遅いのかを分けます。2026年8月7日公開の0.147.0には、長い会話をセクションで整理して段階的に閲覧する機能、端末入力や日本語表示、Windowsのプロセスとパス処理に関する修正が含まれます。版番号を確認したうえで、症状と変更内容を照合してください。

実際の切り分けは、/statusで状態を残し、/compactや新しい会話で文脈を整理し、モデルと対象ファイルを一つずつ比較する順番が基本です。Windowsではパスと表示を別に見て、依頼は対象、変更範囲、確認方法、返してほしい内容を短く書きます。速さだけを追わず、再現条件と確認結果を残せば、Codexを重くしている層を見つけやすくなります。