Macが夜中に止まった犯人は、ChatGPT.appの14GBだった｜Codexのメモリ暴走を突き止めて「自動で治る」ようにするまで【2026年7月】

1. 朝起きたら、Macが止まっていた

結論から書く。macOS版ChatGPT.app(Codex)は、使い方によってはメモリを14GBまで喰い、16GBのMacを一晩で止める。 原因は「アプリ側の既知バグ」と「こちら側の使い方」の合わせ技で、アプリのバグは自分では直せないが、使い方側に3つの手を打てば、16GBのMacBook Airでも安定して回り続ける。この記事はその実測と対策の全記録だ。

ある朝、うちのM4 MacBook Air(メモリ16GB)がほぼ応答しなくなっていた。macOSが「アプリケーションのメモリが不足しています」を出し、いくつかのアプリを強制的に一時停止。アクティビティモニタを見ると、ChatGPT.appが14GBを占有していた。夜間も動かしている自動処理群(定時のデータ収集や監視ジョブ)はすべて巻き添えで停止。実害が出た。

「一度に重い処理をした」のではない。時間経過とともに累積差分が溜まっていく、典型的なリークの挙動だった。swapも同じペースで膨らんでいく。再起動すれば直るが、数日でまた同じ状態になる。つまりこれは事故ではなく、構造だ。

2. まず疑うべきは誰か：既知バグの確認

自分の環境を疑う前に、世界で同じことが起きていないかを確認した。結果、openai/codexリポジトリには同種のissueが多数、しかも未解決のまま積まれていた^[1]。

Issue	症状	規模
#29510	巨大なローカル履歴(rollout)でapp-serverが肥大	30〜40GB
#21134	長時間スレッドでapp-server/rendererが高CPU・高メモリ、SQLiteログ膨張	4.4GB+CPU64%
#26015	長いスレッドを開いた後、ターン終了後もメモリを解放しない	再起動まで保持
#27164	M4/16GB MacでComputer Use使用時にメモリ・swap暴走	システム不安定化
#20740	通常セッション中に75GB超まで成長	75GB+
#26738	Computer Use復元でメモリ暴走	172GB

共通する構図はこうだ。Codexは会話の全履歴をrolloutと呼ばれるJSONLファイルとしてローカルに保存する。そしてapp-server(アプリ内部の常駐プロセス)は、スレッドを開いたり再開したりするときに、このrolloutをサイズ上限なしでメモリへ読み込み、ターンが終わっても解放しない。つまり「巨大な履歴ファイル」がある限り、アプリを何度再起動してもいずれ同じ場所へ戻ってくる。

ここまでなら「OpenAIが直すまで耐えるしかない」で終わる話だ。だが実測してみると、巨大な履歴ファイルを毎日せっせと育てていたのは、他ならぬ自分の設定だった。

3. 本当の犯人：Automationsの「単一スレッド運用」

ChatGPT.appのAutomations(定時実行)で、監視系のジョブを数分間隔で回していた。問題はその設計で、Automationには書き込み先スレッドを固定する設定(target_thread_id)があり、うちの主力ジョブは1つのスレッドに追記し続ける構成になっていた。

実測した数字を並べる。

単一スレッドの継続日数: 11日間
そのrolloutファイル: 399MB(1日あたり約35MB成長)
積まれたターン数: 7,643ターン
1ターンあたりの入力: 約18万トークン(大半はキャッシュだが、履歴全体を毎回引き回す)
累計入力トークン: 38億トークン

単一スレッドへの追記がrolloutを肥大させ、app-serverが全量をメモリに読み込む構図の図解

図1: メモリ暴走の構図。数分間隔のAutomationが単一スレッドに追記し続け、rolloutが無限成長。app-serverはそれを全量ロードして解放しない。

しかも皮肉なことに、スレッド肥大対策として「定期的に新しいスレッドへ切り替える」ローテーション用Automationを自分で用意していたのに、「業務が進行中なら切り替えを見送る」という安全条件を付けていたせいで、11日間一度も発動していなかった。安全のためのブロック条件が、より大きな危険(メモリ枯渇によるMac全体の停止)を育てていた。設計あるあるとして胸に刻みたい。

このrolloutをapp-serverが読み込むと何が起きるか。調査中の30分間だけでも、app-serverのRSS(実メモリ)は1.5GB→3.5GBへ成長し、CPUは100%に張り付いた。夜間8時間なら14GBに届く計算で、実際に届いた。

4. 自分の環境で確かめる方法

同じ症状を疑っている人向けに、確認コマンドをそのまま置いておく。すべて読み取り専用だ。

まずapp-serverの実メモリ使用量。

bash

ps axo pid,rss,command | grep 'ChatGPT.app/Contents/Resources/codex' | grep app-server
# RSS列(KB)が数GBあれば黄信号。数十万KB(数百MB)なら正常圏

次に、育ちすぎたrolloutがないか。

bash

du -sh ~/.codex/sessions
# 直近で追記され続けている巨大ファイルを探す
find ~/.codex/sessions -name 'rollout-*.jsonl' -size +50M -mtime -2 -exec ls -lh {} \;

最後に、ログDBの肥大(issue #21134の症状)。

bash

ls -lh ~/.codex/logs_2.sqlite
# うちの環境では2.2GBまで成長していた

図2: 観測ポイントは3つ。プロセスの実メモリ、rollout履歴の総量と「現役の巨大ファイル」、そしてログDBのサイズ。

判定の目安はシンプルで、「50MBを超えて今も追記され続けているrolloutが1つでもあれば、それが爆弾」だ。アプリを再起動しても、そのスレッドが動き出した瞬間からまた膨らみ始める。

5. 対策1：スレッドを「サイズで」強制回転する

根本対策は、爆弾を作らないこと。つまりrolloutが一定サイズを超えたら、業務状態に関係なくスレッドを新しいものに切り替えることだ。

うちではローテーション判定スクリプトに「rolloutサイズの実測」を追加し、閾値(32MB)を超えたら業務都合のブロック条件を上書きして回転を許可するようにした。ポイントは閾値の根拠で、1日の成長量(約35MB)より少し小さく設定すると、最悪でも1日分ちょっとの履歴サイズで頭打ちになる。ローテーション自体は既存の定時ジョブ(1日2回)がやってくれる。

bash

# 判定の考え方(擬似コード)
size_mb=$(du -m "$rollout_file" | cut -f1)
if [ "$size_mb" -ge 32 ]; then
  rotate_allowed=true   # 業務系のブロック理由より優先
fi

なお、監視系ジョブのプロンプトが「毎回ローカルの最新状態を読み直す」自己完結型なら、スレッドが変わっても文脈の損失は実質ゼロだ。逆に言うと、Automationのプロンプトは履歴依存にせず自己完結に書くのが、この運用の前提になる。

回転なしでは399MBまで直線的に成長した履歴が、32MB閾値の回転でノコギリ状に頭打ちになることを示すグラフ

図3: サイズ回転の効果。放置すれば399MBまで一直線だった履歴が、閾値32MBのノコギリ波で頭打ちになる。

6. 対策2：メモリ番犬——そして「AppleScriptでquit」の罠

回転で爆弾は作られなくなるが、アプリ側のバグそのものは残る。そこで2層目として、launchdで10分ごとにapp-serverのRSSを監視する「番犬」を置いた。警告水準(5GB)でログと通知、危険水準(8GB)でChatGPT.appを自動で再起動する。

ここで一つ、無人運用ならではの罠を踏んだので共有したい。行儀よく osascript でquitさせようとすると——

applescript

tell application "ChatGPT" to quit

——ChatGPT.appは「終了するとオートメーションが停止します」という確認ダイアログを出して、そこで止まる。深夜、ダイアログのボタンを押せる人間はいない。さらにlaunchd文脈ではmacOSの権限制御(TCC)がAppleEventsの送信自体をブロックすることもある^[2]。つまり丁寧なquitは無人時にはほぼ機能しない。

答えはシンプルで、最初からSIGTERMを送る。

bash

pkill -TERM -f 'ChatGPT.app/Contents/MacOS/ChatGPT'
sleep 60   # シャットダウン処理を待つ
open -a ChatGPT

SIGTERMならダイアログは出ず、アプリのシャットダウン処理は走り、Automationsは再起動後にスケジュール通り再開する。実発火テストで、AppleScript経路が確認ダイアログで停止→SIGTERMで完走、という挙動を確認済みだ。無人の自動再起動を設計するなら、AppleScriptのquitを当てにしてはいけない。

図4: 3層防御。爆弾を作らない(回転)、育っても殺す(番犬)、死骸を残さない(退避)。どれか1つではなく全部やる。

7. 対策3：休眠rolloutの退避

3層目は掃除だ。issue #29510が示す通り、app-serverは過去の巨大rolloutを開き直すだけでも数十GBまで膨らみうる。うちの ~/.codex/sessions には、1.8GBや895MBといった「化石rollout」が転がっていて、合計7.2GBあった。

45日以上未使用、または100MB超かつ数日未使用のrolloutを ~/.codex の外へ移動(削除ではなくmv、いつでも戻せる)するスクリプトを書き、週1回の定時実行にした。初回実行で7.2GB→2.1GB。アプリのUIから古いスレッドを開けなくなるトレードオフはあるが、数週間前の監視ログスレッドを開き直すことは実際にはない。

8. 結果と、そのまま使える運用ランブック

3層を入れて以降の実測はこうだ。

app-serverのRSS: 常時1GB前後(以前は放置で数GB→夜間14GB)
CPU100%張り付き: 解消(巨大スレッドの再処理が消えたため)
人間がやること: ゼロ(回転・監視・再起動・退避・週次レポートまで全部launchdとAutomationsが回す)

図5: ビフォーアフター。夜間14GBだったapp-serverは常時1GB前後に、7.2GBだった履歴フォルダは2.1GBに。

運用チェックリストとしてまとめる。

いつ	何を	目安
導入時	Automationsの書き込み先スレッドが固定されていないか確認	固定なら回転設計を足す
導入時	番犬(launchd)を設置、再起動はSIGTERMで	警告5GB/再起動8GB
週次(自動)	休眠rolloutを退避	sessionsを数GB以内に
週次(自動)	RSS推移・再起動回数のレポート	「静かな週」が正常
随時	`ps`でapp-server RSSを見る癖	数百MBなら健康

9. まとめ：バグは直せないが、入力は小さくできる

今回の教訓は3つある。

第一に、「アプリのバグ」と「自分の使い方」は独立に検証すること。既知バグを見つけた時点で「OpenAIが直すまで待つしかない」と結論していたら、毎晩Macが止まり続けていた。バグの引き金(巨大rollout)を作っていたのは自分の設定で、そちらは今日直せた。

第二に、安全条件は「何を守っているか」を定期的に疑うこと。「業務中はスレッドを切り替えない」という慎重な設計が、結果的にMac全体を止める爆弾を育てていた。ローカルの安全とシステム全体の安全は、ときどき衝突する。

第三に、無人の自動化は「人間がいる前提のUI」を信用しないこと。確認ダイアログ、AppleScriptの権限、行儀のよいquit——どれも深夜3時には機能しない。SIGTERMのような、OSレベルで確実に完走する経路を選ぶ。

ChatGPT.appのメモリ問題そのものは、OpenAIのissueトラッカーで今も未解決のままだ^[3]。それでも、入力を小さく保ち、育ったら殺し、死骸を掃除する——この3層があれば、16GBのMacでも安心して夜を越せる。

参考文献 / References

参考文献・出典

[1]2026年7月時点。いずれのissueもオープンのままで、OpenAIからの根本修正やワークアラウンドの公式案内は確認できていない。バージョンや環境により再現条件は異なるため、自分の環境での実測(第4章)を推奨する。 ↩
[2]TCC(Transparency, Consent, and Control)はmacOSのプライバシー保護機構。他アプリへのAppleEvents送信には「オートメーション」権限の承認が必要で、launchdなどGUIを持たない文脈から実行すると承認ダイアログ自体が出せず、権限がないまま黙って失敗することがある。 ↩
[3]rolloutの全量ロード、ターン終了後のメモリ非解放、TRACEログによるSQLite肥大は、いずれもアプリ内部の実装に起因するため利用者側では根治できない。本記事の3層対策は「バグの引き金を最小化する」アプローチである。 ↩