Codex CLI 実測：
8GB・16GB・32GB で最後まで終わるプロジェクト

2026年9月9日時点でも、Codex 公式インストール手順は macOS 12+ / Ubuntu 20.04+（Windows は WSL2）、メモリは 最低 4GB、推奨 8GB と書いています。CLI 本体はすでに Rust のネイティブバイナリで、アイドル時は数百 MB 程度です。Claude Code や Cursor と同じで、高いのは「Agent プロセス」ではなく、Agent が手を動かすたびに起動するローカルツールチェーンです。別の Agent の購入スペックを見たいなら、Claude Code 16GB / 24GB / 64GB 実測を対照してください。プライベートな PR レビュー基盤なら別記事です：OpenCode Review 4GB / 8GB / 16GB 選定。本稿が答えるのは一事だけです。Codex CLI は 8 / 16 / 32GB で、どの種類のプロジェクトを最後まで終えられるか。

公式の 4GB / 8GB は起動できることしか保証しない

「推奨 8GB」を「8GB ならどんなプロジェクトでも書ける」と読むのが、いちばん多い誤解です。公式表が解いているのは、OS + Node / ランタイム依存 + Codex プロセス自体が生き残れるかどうかです。次のような実作業は対象外です。

• リポジトリに node_modules、DerivedData、.next、あるいは数万のソースがある。Agent はパスで読み、ツールで検索する；
• 「落ちた CI を直して」と頼むと、npm test、pytest、xcodebuild を実行する；
• Playwright / Chrome DevTools / XcodeBuild MCP を入れていると、セッションごとに Node のプロセスツリーがもう一本立つ；
• ブラウザ、IDE、ローカル dev server も同時に開いている——これらは「最低 4GB」に入っていない。

推論は OpenAI 側で起きるので、GPU を大きくしても助けになりません。ローカルメモリが決めるのは、ツールチェーンが立つ場所があるかどうかです。同じ公式文が、スクリプト用リポジトリと iOS モノリスで真逆の体感になる理由でもあります。

メモリの内訳：CLI、インデックス、子プロセス、MCP

インタラクティブなセッションの常駐メモリは、四枚の請求書に分けられます。分けて見ると、いきなりメモリを足す前に、どこを切るべきかが分かります。

コミュニティには、すでに無視できない報告があります。約 1.2GB のローカルリポジトリで、Codex ネイティブランタイムの匿名 RSS が 18GB、さらには 29GB まで膨れ、cgroup に殺された報告があります（openai/codex#21233）。もう一系統は MCP のライフサイクルです。セッションをサスペンドしたあと、あるいは子 Agent が終わったあと、npx / Playwright / xcodebuildmcp のプロセスツリーが残る。16GB 機は孤児プロセスにスワップへ引きずり込まれます。だから「32GB なら安全」も成立しません——反応できる時間が長くなるだけです。

ここが「何 GB のパソコンを買うか」系の記事との違いです。チップ型番でマシンを勧めるのではなく、プロジェクトのツールチェーンで帳簿を付けます。

実測の進め方：3段階の上限、6つのプロジェクト

同じ Codex CLI（ChatGPT ログイン、デフォルトのコーディングモデル）で、固定した 6 つのタスクを、8 / 16 / 32 GiB の利用可能メモリにそれぞれキャップして回しました。Linux 側は systemd-run --scope -p MemoryMax=、macOS 側はアクティビティモニタのメモリプレッシャーとスワップを対照しました。指標は四つだけです。Codex + 子プロセスのピーク RSS、激しいスワップが始まったか、タスクを終えられたか、ウォールクロック時間。

6 つのプロジェクトは、開発者が本当に Agent へ投げる仕事を意図して選びました。Hello World ではありません。

1. P0 空セッション：codex をコールドスタートし、リポジトリ構造を一問。テストは走らせない。
2. P1 小さな Python CLI：約 180 ソースファイル。パースバグを直し、pytest -q を回す。
3. P2 中規模 Next.js：約 800 ソースファイル。API ルートを一本追加し、npm test（E2E ブラウザなし）。
4. P3 P2 + Docker Compose：Postgres + アプリコンテナ。Codex にマイグレーションを直させ、スタックを再起動させる。
5. P4 iOS App：中規模 UIKit プロジェクト。画面を一箇所直し、xcodebuild を実行（シミュレータ一式は起動しない）。
6. P5 P2 + Playwright MCP：ブラウザ MCP を開き、ページを見ながらコンポーネントを直させる。

数字はピークの区間であり、計測器の校正値ではありません。環境には OS と薄いターミナルを残し、Chrome タブ 40 枚は同時に開いていません。Slack、Figma、dev server 3 本がまだ載っているなら、下表の各グレードをさらに一段上へ見積もってください。

横断結果：成功、停滞、強制終了

この表では二つを掴んでください。第一に、P2 はすでに 8GB の天井に近い——Codex が 8GB を食べたのではなく、node のテストプロセスとファイル読み取りが、残りわずかな空きを食い尽くす。第二に、P4 / P5 の失敗のほとんどは「モデルが Swift を書けない / ページをクリックできない」ではなく、コンパイラとブラウザが先にマシンを押し潰し、Agent が最後の一歩まで届かないことです。

8GB で回せるプロジェクト

8GB は公式の「推奨」帯であり、薄型ノート、入門 VPS、旧世代ユニファイドメモリ Mac の現実でもあります。終えられるプロジェクトの特徴ははっきりしています。ソースが少なく、コンテナがなく、IDE シミュレータがなく、テストはプロセス内で完結する。

8GB に任せてよいプロジェクト

• スクリプト、クローラ、小さなツール、単ファイルのリファクタ；
• ドキュメントサイト（Astro / VitePress / Docusaurus）の文言と設定変更；
• 小型の Flask / Express / FastAPI。pytest か少量の Node 単体テスト。ブラウザは起動しない；
• codex exec で一回限りのパッチ：数ファイル読んで直したら終了。対話 TUI は張らない；
• コードレビューのコメント、コミットメッセージ、エラーログをパッチ草案へ翻訳する。

8GB では最初から捨てるプロジェクト

• Docker Desktop / Compose が必要なフルスタック；
• Xcode、iOS シミュレータ、Android エミュレータ；
• Playwright、Cypress、Chrome DevTools MCP；
• pnpm / npm の大型 monorepo 全量テスト；
• 「VS Code とタブ十数枚を開きながら Codex にリポジトリを直させる」——先にページングが始まり、Agent が遅くなったと思ったら、ディスクがメモリの代わりをしている。

8GB でいちばん効く使い方は「大きなリポジトリを我慢して回す」ことではなく、大きなリポジトリを小さなタスクに割ることです。サブディレクトリだけ開く、MCP を切る、codex exec で終えたら去る。対話の長セッションは 8GB の天敵です。セッションが長いほど、内部状態と子プロセスが残りやすい。

16GB で回せるプロジェクト

16GB は、私たちが勧める日常 Web のデフォルト帯です。P2 のような「中規模フロント / フルスタック + 単体テスト」が、この帯でようやくスワップと時間を奪い合わなくなります。Nuvcloud クラウド Mac mini の入門仕様も 16GB ユニファイドメモリで、この帯に揃えています。手元の薄型ノートが足りないときは、Codex セッションをツールチェーンごと専有ノードへ移した方が、8GB ノートで無理をするより楽です。

16GB が楽なプロジェクト

• 中規模 Next.js / Nuxt / Rails / Django。単体テスト + ローカル dev server；
• データベースコンテナ 1 つ、または非常に薄い docker-compose（Redis + Elasticsearch + ブラウザを重ねない）；
• VS Code / Zed + ターミナルの Codex。システムに 2–3GB を残す；
• 中程度の Python データスクリプト（pandas の中規模表。ローカルの大きなモデルは載せない）；
• 短時間だけ MCP を 1 つ開く（Git やドキュメント検索など）。使い終わったらすぐ閉じる。

16GB でできるが、ルールを守るプロジェクト

P3 は 16GB で「終えられる」——ただしメモリプレッシャーが黄になることを受け入れ、二組目のコンテナを並列しないことが前提です。iOS の小さな変更で、xcodebuild の単一ターゲットだけなら、ときどき押し切れます。シミュレータを開いた瞬間、「スワップ + 固まり」区間に戻ります。Playwright MCP の短いセッション（十数分）は可能です。一度 Ctrl+Z でセッションをサスペンドしたり、連続で spawn_agent したりすると、孤児の Node が 16GB を突き破ります。コミュニティは 16GB + 8GB zram のマシンで、マシン全体が使えなくなる再現をすでに持っています。

一言で言えば、16GB は「メインプロジェクト 1 つ + テスト 1 セット」向け。「メイン + コンテナ一式 + ブラウザ Agent + IDE インデックス」向けではない。

32GB を用意すべきプロジェクト

32GB は見栄のスペックではありません。次のプロジェクトの入場券です。共通点は、Codex は請求書のごく一部で、コンパイラとランタイムが本体であることです。

• モノリス / マルチパッケージリポジトリ：一度の npm test や turbo run test が Node worker を一列立ち上げる；
• iOS / macOS プロジェクト：xcodebuild、DerivedData、コードインデックス。ピークは簡単に十数 GB。画面を見ながらシミュレータも開くなら、32GB で計画する；
• Codex + Docker の複数サービス：アプリ、DB、メッセージキューが同時にあり、Agent にマイグレーションを直させ、スタックを再起動させる；
• ブラウザ MCP / E2E：Playwright や Chrome DevTools がプロセスツリーをもう一本複製する。短いセッションなら 32GB で足りる。長いセッションは、それでも手で回収する；
• 複数セッション並列：2 つの Codex が 2 つのリポジトリを見る、あるいは対話セッション 1 つに codex exec のバッチを足す。

32GB でも、既知の無制限増加は止められません。作業領域そのものが 1GB 級なら、Codex にメモリ上限を付けてください。タスクが失敗する方が、デスクトップごと凍るよりましです。Linux ではこう包めます。

# 32GB マシンで Codex に 20G を残し、残りをシステム / IDE / コンテナへ
systemd-run --user --scope \
  --same-dir \
  --unit="codex-$(date +%H%M%S)" \
  -p MemoryMax=20G \
  -p MemorySwapMax=2G \
  -p CPUQuota=300% \
  codex

macOS には同程度に使いやすいユーザー空間 cgroup がありません。現実的なのは、重い仕事を専有のクラウド Mac へ置くことです。手元はエディタと閲覧だけ。Nuvcloud が現在公開しているベアメタル構成は 16GB と 24GB です。24GB は大半の P3 をカバーします。P4 でシミュレータも同時に開くなら、Xcode と Codex を常時起動のリモート機へ置き、16GB ノートに両端を兼任させない方がよい。Agent ノードを別会計にすると、GitHub Actions macOS Runner のホステッドとセルフホストコストとも対照しやすい。CI は使い捨ての runner、対話 Codex は日貸しの Mac mini。両方の帳簿を、満載のノート 1 台に混ぜないことです。

リポジトリとツールチェーンでメモリ帯を選ぶ

先に「16 を買うか 32 か」と聞かないでください。先に聞くのは、リポジトリが何を起動するかです。下表は意思決定の順です。上から、最初に当たった行で止まってください。

見落とされがちな変数がもう一つあります。ディスクとファイルディスクリプタです。MCP がリークすると、macOS のデフォルトソフトリミット 256 個で先に Too many open files が出ます。「Codex が壊れた」ように見えて、パイプと孤児プロセスが枠を食っています。メモリの前に、ulimit -n と ps の npx / mcp 本数を見てください。

メモリの少ないマシンでの延命設定

当面 8GB、あるいは逼迫した 16GB で働くしかないなら、先に振る舞いを変え、それから増設を語ってください。次のリストは「効果 / 痛み」順です。

1. デフォルトは MCP ゼロ。 ブラウザや Xcode ツールが要るときだけ開き、終わったら ~/.codex/config.toml から外す。xcodebuildmcp や Playwright をグローバルデフォルトに書かない。
2. 対話セッションは短く、バッチは codex exec。 一回限りのパッチに TUI は不要。バッチは UI 状態を一層節約できる。
3. Codex を Ctrl+Z でサスペンドしない。 止めたあとも MCP 子プロセスは生き続けることが多い。終了するか、tmux で detach する。
4. 作業ディレクトリを狭める。 4 万ファイルの monorepo ルートではなく、サブパッケージで起動する。dist、coverage、.next を読み取り範囲から外す。
5. ツール出力を制限する。 コミュニティでは tool_output_token_limit に上限を付け、一度のログ読みでコンテキストとローカルバッファを同時に破裂させない。
6. 「遅い」だけでなくプロセスを見る。 ps aux | egrep 'codex|npx|mcp|node' に MCP ツリーが十数組並んでいたら、孤児を殺してから続ける。

ps aux | egrep 'codex|npx|playwright|mcp-server|xcodebuildmcp' | grep -v egrep
# セッション終了後も残っていたら、先に回収してから次を開く
# macOS はアクティビティモニタで「メモリ」順に並べ、node と Codex を見る

これらの手順は P4 を 8GB フレンドリーにはしません。ただし P1 / P2 を「起動できる」から「終えられる」へは変えられます。メモリ増設が解くのはピーク、設定変更が解くのはリークと並行です。

Codex をクラウド Mac に移すタイミング

次のうち任意の 2 つが当てはまったら、Codex と重いツールチェーンをノートから切り離してください。

• 手元は 8GB か 16GB なのに、仕事はすでに P3 / P4 / P5；
• 通勤中、Windows ホスト、共有 PC で同じセッションを続けたい；
• Xcode の版を手元の日常開発から隔離したい（SDK 週、beta 週は特に顕著）；
• 誰かが MCP をグローバルデフォルトにしており、共有マシンが午後になると孤児で埋まる。

クラウド Mac mini の価値は「高い Codex」ではありません。専有のユニファイドメモリ、ネイティブな Unix ツールチェーン、日単位で捨てられる汚れた環境です。手元の 8GB ノートはメールとドキュメント。16GB または 24GB のリモートノードが Codex、テスト、Xcode を専任する。Apple Silicon は待機電力が低く、一晩タスクを掛けやすい。SSH / VNC は、すでにページングしているノートでぐるぐるを見つめるより正直です。