Codex が遅い・重いと感じたときは、まずどこで時間がかかっているかを見分けると、対処がすぐ決まります。AI の返事が遅いならサーバーと設定、起動が遅いなら MCP サーバーや設定のフォルダ、アプリの画面が重いならアプリの版と会話の長さ、コマンドの実行が遅いならファイルの置き場所とパソコンです。この記事では、OpenAI の公式のドキュメントと、Codex の GitHub で OpenAI の担当者が答えた対処（2026年10月25日確認）を、症状ごとに並べます。

症状から、見る場所を決める

症状 A

AI の返事が遅い・進まない

障害・混雑、思考の強さ、モデル、スレッドの長さ → 2章

症状 B

起動が遅い・入力できるまで待たされる

MCP サーバーの起動待ち、設定のフォルダ、古い版 → 3章

症状 C

アプリが重い・固まる

アプリの版、長いスレッド、溜まった実行、Windows の不具合 → 4章

症状 D

コマンドの実行が遅い

WSL のファイルの置き場所、パソコンの性能 → 5章

Codex は、ChatGPT のデスクトップアプリ（Windows・macOS）、CLI（ターミナルで使う版）、VS Code などのエディタの拡張で使えます。1つの作業のやりとりのまとまりを、この記事では「スレッド」と呼びます（アプリの1つのチャット、CLI の1つのセッション）。どの形でも、頭脳にあたるモデルは OpenAI のサーバーで動き、AI が頼んだコマンドはあなたのパソコンで動きます。症状は 返事 起動 アプリ コマンド の色で区別しています。

1. まず切り分ける

遅いと感じたら、画面を見て次の3つを順に確かめます。

  1. 承認を待っていないかCodex がコマンドの実行やファイルの変更の許可を求めたまま止まっていることがあります。公式のトラブルシューティングも、止まって見えるときに最初に確かめることとして挙げています。
  2. いま何をしているか入力できるようになるまで、または MCP サーバーの準備中の表示が続くなら 起動、「考えている」「返事を書いている」表示が続くなら 返事、コマンドの実行中のまま進まないなら コマンド、入力や画面の切り替えそのものがもたつくなら アプリ の問題です。
  3. ほかの人も遅いかOpenAI の稼働状況のページで Codex に障害が出ていないかを見ます。障害なら手元でできることはほとんどありません。

CLI では /status で、いま使っているモデル・使ったトークンの量・残りの文脈（スレッドの記憶の空き）を確かめられます。残りの文脈が少なければ2章の「長いスレッドを使い続けない」へ、思考の強さを High 以上にしているなら2章の表へ進みます。

2. AI の返事が遅いとき 返事

サーバー側の混雑や障害

手元に原因が無い遅さもあります。高速モードが標準と同じくらい遅いという報告に、OpenAI の担当者は「We had a capacity issue last week」（先週は容量の問題があった）と答え、その後に緩和したと説明しています（openai/codex #24422、2026年6月）。このように、サーバー側の容量不足で遅くなった例があります。「モデルが混雑している」と表示されるときの対処は「Codex の「Selected model is at capacity」の対処」にまとめています。

思考の強さ（reasoning effort）を作業に合わせる

Codex では、モデルがどれだけ考えてから答えるかを選べます。強くするほど深く考えるぶん、時間と利用枠の消費が増えます。公式の説明は次のとおりです（OpenAI「Models」）。

強さ公式の説明向く作業（目安）
Light（CLI は Low）素早く、範囲のはっきりした作業向け1か所の修正・質問への回答
Medium速さと深さの釣り合いふだんの実装
High・Extra High手順や資料の多い難しい作業向け（公式の説明は2つで同じ）Extra High のほうが長く考える設計を伴う変更・原因の分からない不具合
Max速さや利用枠より深さを優先して、より長く考えるほかで解けなかった難題
Ultraサブエージェントに分けて、複雑な作業を速める利用枠への影響は公式の記載なしいくつかに分けられる大きな作業

CLI では /model でモデルと一緒に選びます。設定ファイル（config.toml）の model_reasoning_effort で既定を決められます。いちばん軽い段は、アプリでは Light、CLI と設定ファイルでは low と表示されます。

High 以上を常に使っていると、簡単な作業でも待ち時間が長くなります。小さな修正では Light（CLI は low）か Medium に下げると、返事が早く返ってきます。OpenAI のモデルの選び方のページは、細かな編集や範囲のはっきりした作業に、軽いモデルの GPT-6 Luna と Light（Low）の組み合わせを挙げています（OpenAI「Model selection」）。

高速モード（Fast・Ultrafast）

待ち時間を縮めたいときは、利用枠を多く使う代わりに速くする高速モードがあります（OpenAI「Speed」）。

モード対象と使える人速さ利用枠の消費（ChatGPT でサインインした場合）
FastGPT-6.1 Sol・GPT-6 Astra・GPT-6 Sol・GPT-6 Luna を含む対応モデルChatGPT でサインインした、アプリ・CLI・エディタの拡張倍率は公式の記載なしプランの利用枠を標準の2.5倍購入したクレジットは2倍
UltrafastGPT-6 Astra・GPT-6.1 SolPro（月額 $500 の段）と対象の Enterprise・Edu（料金、10月25日確認）GPT-6 Astra で、文字を作る速さが標準の最大8倍利用枠を8倍クレジットは6倍

CLI では /fast で切り替えます。使っているモデルに高速の段が無いときは /fast が出ません。API キーでサインインしているときは API の料金になり、上の倍率はかかりません。

長いスレッドを使い続けない

1つのスレッドでいくつもの作業を続けると、文脈が膨らんで返事も画面も重くなります。長く使い続けたスレッドで重くなるという報告に、OpenAI の担当者は作業ごとに新しいスレッドを作るよう勧めています。

OpenAI の担当者（openai/codex #11984・2026年2月25日）

“We recommend creating a new thread for each task”
（作業ごとに新しいスレッドを作ることを勧める）

担当者は続けて、同じスレッドを使い続けると文脈は圧縮のたびに薄まるので、新しく始めるほうが速く、モデルも過去の作業に気を取られない、と説明しています（openai/codex #11984）。

どうしても同じスレッドを続けたいときは、CLI の /compact でそれまでのやりとりを要約して文脈を空けられます（公式の説明は「Summarize the visible chat to free tokens」）。/new は新しいスレッドを始めます（OpenAI「Slash commands」）。

3. 起動が遅いとき（CLI・MCP） 起動

MCP サーバーの起動待ち

Codex に MCP サーバー（外部のツールをつなぐ仕組み）を登録していると、起動のたびにそのサーバーの準備を待ちます。必須でないサーバーは既定で1秒だけ待って先へ進みますが、required = true にしたサーバーは起動するまで（既定で最大10秒）待ちます。応答の遅いサーバーや、もう使っていないサーバーを登録したままだと、最初の返事までが遅くなります。公式の設定は次のとおりです（OpenAI「Model Context Protocol」）。

必須にしているか確かめたい
required = true のサーバーは起動するまで（startup_timeout_sec、既定10秒）待ち、起動できないと Codex 自体が始まらない必須でなくてよいサーバーは外すのがいちばん効く。必須でないサーバーを待つのは mcp_optional_startup_grace_ms（既定1000ミリ秒）まで
使っていないサーバーを止めたい
config.toml のそのサーバーの欄に enabled = false を書くサーバーの設定を消さずに無効にできる
必須のサーバーを待つ上限を短くしたい
そのサーバーの startup_timeout_sec（既定10秒）を下げる下げすぎると、起動に時間がかかるサーバーが使えなくなる
登録を確かめたい
CLI の /mcp か、ターミナルの codex mcp list で、有効なサーバーを見る
# ~/.codex/config.toml の例：使っていないサーバーを止める
[mcp_servers.old-server]
command = "npx"
args = ["-y", "old-mcp-server"]
enabled = false

設定のフォルダが大きい・壊れている

CLI の起動が遅いという報告に、OpenAI の担当者は、設定と記録を置く ~/.codex フォルダが大きいか壊れている可能性を挙げ、一時的に名前を変えて試すよう案内しています（openai/codex #9290、2026年1月）。名前を変えると Codex は初めて使うときと同じ状態で始まるので、ログインし直しが必要です。過去のスレッドの記録もこのフォルダにあるので、消さずに名前を変えるだけにして、試し終えたら元に戻してください。

# macOS・Linux：名前を変える
mv ~/.codex ~/.codex-backup
# Windows（PowerShell）：名前を変える
Rename-Item $HOME\.codex .codex-backup

元に戻すときは、試しに新しくできた .codex を別の名前（.codex-test など）に変えてから、.codex-backup を .codex に戻します。

古い版を使っていないか

CLI には、起動まわりの改善が入る版があります。たとえば 0.152.0（2026年9月1日）では最初の返事までの遅れを減らし、0.161.0（10月7日）では記録のデータベースの破損を起動時に早く見つけるようになりました（GitHub のリリース）。codex --version で版を確かめ、codex update で更新を確かめて入れます。codex update が使えない入れ方（パッケージ管理のツールで入れた場合など）では、入れたときと同じ方法で更新します。デスクトップアプリに入っている Codex は CLI と版が違うことがあり、アプリは別に更新します（4章）。

4. アプリが重い・固まるとき アプリ

最新版に更新して再起動する

デスクトップアプリのもたつきは、版で直っているものが多くあります。

Windows

Windows でアプリが固まる・カクつくという報告（openai/codex #20214）に、OpenAI の担当者は2026年8月28日、原因の1つを直したと書いています。

OpenAI の担当者（openai/codex #20214・2026年8月28日）

“ChatGPT v26.825.32147 includes a fix for one cause of Windows stuttering and slowdowns during long sessions.”
（ChatGPT v26.825.32147 に、長く使い続けたときに Windows がカクつき遅くなる原因の1つの修正を入れた）

担当者によると、サンドボックスで動くコマンドが、画面を描く Windows の仕組み（dwm.exe）の資源を溜めていたのが原因の1つで、v26.825.32147 以降に更新してアプリを再起動するよう案内しています。

担当者は「原因の1つ」と書いており、この issue は2026年10月25日時点でも未解決で、更新後もほかの原因で固まるという利用者の報告が続いています。Windows のアプリは Microsoft Store で配布されているので、Store の [ライブラリ] で更新を確かめます（OpenAI「ChatGPT desktop app for Windows」）。

macOS

macOS で CPU の使用率が高くなる問題は、2026年4月の版（v26.415.20818）で修正したと担当者が書いています（openai/codex #16231）。一方、補助のプロセスが溜まって入力が遅れるという報告は、10月の時点でも未解決です（#25744）。アプリを最新にして、重くなったら再起動します。

どちらの OS でも、まず最新版にしてアプリを再起動するのが最初の一手です。

公式の「固まったとき」の手順

OpenAI のトラブルシューティングは、止まったときの手順を次のように書いています（OpenAI「Troubleshooting」）。

スレッドが止まって見えるとき
1章の確認に加えて、ターミナルで git status のような簡単なコマンドを実行する → 範囲を絞った小さな依頼で新しいスレッドを始める
アプリのターミナルが固まったとき
ターミナルのパネルを閉じて、Ctrl+` で開き直し、pwd か git status を実行するそれでも固まるなら、動いているスレッドが終わってからアプリを再起動する

スレッドを片付ける

1つのスレッドで長く作業しないこと（2章）は、画面の重さにも効きます。スレッドの数については、スレッドの切り替えが遅い、たくさんのスレッドがあると CPU を使い続ける、という報告が GitHub に未解決のまま残っています（#11011 ほか）。アーカイブで軽くなるとは公式に書かれていませんが、使い終えたスレッドは CLI の /archive（記録は消さずに一覧から外す）や、アプリのアーカイブで片付けておくと、一覧が膨らみません。

定期タスクを使っているなら、こちらは公式のトラブルシューティングに手順があります。頻繁な定期タスクは worktree（作業用のフォルダのコピー）を溜めていくので、要らなくなった実行をアーカイブし、残す必要のない実行はピン留めしません（OpenAI「Troubleshooting」）。

5. コマンドの実行が遅いとき（WSL・ファイルの置き場所） コマンド

AI が頼んだビルドやテスト、検索のコマンドは、あなたのパソコンで動きます。ここが遅いときは、モデルや設定ではなく、ファイルの置き場所とパソコンの性能を見ます。

WSL では Linux 側にファイルを置く

Windows の中の Linux（WSL）で Codex を動かしているなら、作業のフォルダの場所で速さが大きく変わります。公式の説明は、/mnt/c/... のような Windows のドライブの下での作業は遅くなることがあり、リポジトリは Linux のホームフォルダ（~/code/my-app など）に置くよう勧めています。大きなリポジトリで遅いときは、WSL に割り当てるメモリと CPU を増やすことと、WSL の更新も挙げています（OpenAI「WSL」）。

# %UserProfile%\.wslconfig の例：WSL に割り当てるメモリと CPU
[wsl2]
memory=8GB
processors=4
# WSL を最新にして、いったん止める（PowerShell で。設定を反映させるため）
wsl --update
wsl --shutdown

.wslconfig の書き方は Microsoft「Advanced settings configuration in WSL」。wsl --shutdown は動いている WSL をすべて止めるので、作業中のものを閉じてから実行します。値はパソコンのメモリと CPU の数に合わせます。

注意したいのは、Windows のアプリで「Windows のまま」のエージェントを使うときは、逆の置き方が勧められていることです。

エージェントを WSL で動かすとき

Linux 側（~/code など）に置く

/mnt/c の下は遅くなることがある（OpenAI「WSL」）。

Windows のアプリで「Windows のまま」動かすとき

Windows 側のフォルダに置く

エージェントは Windows 側で動くので、/mnt/c の遅さは関係しない。WSL の中のフォルダをアプリで直接開くより確実（OpenAI「ChatGPT desktop app for Windows」）。WSL 側のツールで同じリポジトリを触るときだけ /mnt/<ドライブ>/... 経由になり、その操作は遅くなりうる。

出典：OpenAI「ChatGPT desktop app for Windows」。Windows のアプリの既定は「Windows のまま」のエージェントで、WSL に切り替えたときはアプリの再起動が要ります。WSL のエージェントが極端に遅いという報告（#25715）では、担当者が緩和の見込みとした修正が2026年6月5日に取り込まれましたが、issue は10月25日時点で未解決です。

パソコンの性能が効く所

コマンドの実行時間は、パソコンの CPU・メモリ・ストレージ（とくに HDD か SSD か）で変わります。アプリの画面の動きもパソコンの影響を受けます。一方、AI が考えて返事を書く時間は、パソコンを買い替えても変わりません。どこまでがパソコンで変わるかは「Claude Code・Codex に必要な PC スペック」で、所要時間の内訳の測り方と一緒に説明しています。

6. 直らないときに OpenAI へ報告する

ここまでで直らないときは、OpenAI に報告すると、担当者が記録を見て原因を探せます。

  • CLI から送る：CLI の /feedback で、記録や診断の情報を Codex の担当者へ送れます（案内に沿って、何を含めるかを選ぶ）
  • GitHub で探す：openai/codex の issues で、同じ症状の報告と担当者の返事を探し、報告するときは版の番号と OS を書きます
  • CLI の詳しい記録を取る：平文の記録は既定では作られません。RUST_LOG=debug codex -c log_dir=./.codex-log（Windows の PowerShell では $env:RUST_LOG="debug"; codex -c log_dir=./.codex-log）のように記録の場所を指定して起動すると、codex-tui.log が出ます（OpenAI「Environment variables」）

記録には作業の中身やファイルのパスが入ることがあります。公開の場所に貼るときは、秘密の値や個人の情報を消してから貼ってください。

まとめ

  • まず承認待ちでないか、何をしている最中か、障害が出ていないかを確かめる
  • 返事が遅いなら、思考の強さを作業に合わせて下げる・軽いモデルにする・高速モードを使う（利用枠の消費は増える）
  • 作業ごとに新しいスレッドを作り（OpenAI の担当者が勧める）、続けるなら /compact
  • 起動が遅いなら、必須の MCP サーバーを見直し、使っていないサーバーを enabled = false で止め、CLI を最新にする（だめなら ~/.codex の名前を一時的に変えて試す）
  • アプリが重いなら、まず最新版にして再起動し、要らなくなった定期タスクの実行をアーカイブする
  • WSL では Linux 側にファイルを置く（Windows のまま動かすなら Windows 側）
  • 直らなければ /feedback で記録を送り、GitHub の issue で同じ症状を探す

FAQ

Q. Codex は Claude Code より遅いのですか？

一概には言えません。速さは、思考の強さ、モデル、作業の種類、アプリの不具合、手元のコマンドの時間で大きく変わります。条件をそろえた比較の測定は少なく、モデルも違うので、1つの測定の数字で決めるのは危険です。2つのツールで、どこがパソコンで変わり、どこが変わらないかは「Claude Code・Codex に必要な PC スペック」で並べて説明しています。

Q. 高速モードを使えば必ず速くなりますか？

モデルが文字を作る速さは上がりますが、コマンドの実行の時間や、MCP サーバーの起動待ちは変わりません。サーバーが混んでいる時期には、高速モードでも遅く感じることがあります（2章）。プランの利用枠も早く減るので、急ぐ作業に絞って使うのが無難です。

Q. VS Code の拡張が反応しない・重いときは？

拡張と VS Code を最新にして、VS Code を再起動します。重いときの拡張に固有の手順は公式に見当たりませんが、スレッドの長さ（2章）は拡張でも同じように効きます。Windows で拡張が反応しないときは、OpenAI のドキュメントが、Microsoft の C++ のビルドツールと Visual C++ の再頒布可能パッケージを入れてから VS Code を完全に再起動するよう案内しています（OpenAI「Windows sandbox」）。