Claude DesignがMacでメモリ増加・クラッシュし真っ白になる原因と対策

Design画面が生成中に真っ白になりクラッシュする

Claude Designで画面が真っ白になって落ちる原因は、Macの搭載メモリ不足だけではありません。空きメモリに余裕があっても、Design画面のレンダラーがV8エンジンの4GB上限に達して自分で落ちるケースが報告されています。

空きメモリに余裕があるのに4GB前後で落ちるなら、この上限に当たった可能性が高いです。

Claude Designで生成中に画面が突然真っ白になり、操作を受け付けなくなる不具合が報告されています。GitHub issue #93679によると、生成が進むにつれてDesign画面のレンダラープロセスが1分ほどで数GBまで膨らみ、その直後に強制終了されます。

チャット側のCmd+Rは効かず、Design画面を再読み込みする手段がありません。開き直すと「作業が中断されました(We got interrupted — the work paused before finishing)」という表示とともに、再開か破棄かの選択を求められます。

アップデート後にキャンバスが白くなる既知のGPU描画バグとは別物で、GPUプロセスのログは正常でした。クラッシュの瞬間に残るのは、メッセージもスタックトレースも空のSentryログだけです。

この症状は1人の環境に限りません。issueのコメント欄には、Apple Silicon Mac(M4・16GB)、Intel iMac(32GB)、Linux上のBrave(Chromium 152)という、ハードウェア・OS・ブラウザーが重ならない3つの環境から同じ症状が集まりました。Claude Desktopアプリとブラウザー版のclaude.ai/design、両方で再現しており、Desktopアプリに固有の不具合ではありません。Claude Designの基本操作はチャットとキャンバスの2ペイン構成で、この不具合はまさにその生成中に起きます。

4GBの壁かメモリ圧迫かは空きメモリで見分けられる

同じ「真っ白になる」でも、原因は2通りあります。最初の投稿の報告者自身、4GB付近で消えた2回と、2.2GB前後で消えた2回を別物として見ていました。

見分けはログでつきます。issueの報告者は、macOSのDesktopアプリが書く ~/Library/Logs/Claude/main.log の [process-memory] 行(レンダラーごとのメモリを1分おきに記録)と、レンダラーが消えた瞬間の Sentry caught 行を突き合わせていました。Linuxでは、BraveのレンダラーOOMが journalctl --user に残ります。

# macOS: レンダラーのメモリ推移と、消えた瞬間の記録を拾う
grep -E "process-memory|Sentry caught" ~/Library/Logs/Claude/main.log
 
# Linux: ブラウザー版でV8がメモリ確保に失敗した記録を拾う
journalctl --user | grep "V8 javascript OOM"

Sentryの行は type: 'Unknown'・value: 'No message' というメッセージなしの形です。ログ上は、process-memory の値が4GB前後で途切れていれば4GBの壁側の消え方です。

原因は搭載RAMではなくV8エンジンの4GB上限

あるユーザーがChromeのクラッシュダンプを解析したところ、レンダラーはOSに外部から強制終了されたのではなく、V8エンジン自身が「メモリ確保に失敗した」と判断して自らアボートしていました。もっとRAMを積めば解決する話ではありません。

V8にはpointer-compression cageと呼ばれる、1つのレンダラーが使える上限を機械的に区切る仕組みがあります。ダンプでは、このケージの容量が4096.00MB、確保済みサイズが4089.76MBとほぼ満杯でした。一方でオブジェクトが実際に積まれるヒープ領域(old-space・new-space・code-space・lo-spaceの合計)は400MB未満にとどまっています。つまりケージ内の約3.7GBは、通常のJavaScriptオブジェクトではない何かに占められていたことになります。

Apple Silicon Mac(16GB)の2回のピークは4,037MBと4,219MBで、32GBのIntel MacのChromeダンプでもケージは4096MBで満杯でした。搭載RAMの量に関係なく同じ天井にぶつかっています。

常駐メモリ(RSS)が4GBを超えただけでは落ちない点も報告されています。あるIntel Macでは、書き込み3回で4.1GBを超えるピークを3回やり過ごしたあと、次の5.6GBで落ちました。死因になるのは、そのうちケージの内側にある分です。

また、別の報告者(Apple Silicon Mac)が取った2つのダンプでは、17.4時間動いたレンダラーと、起動から4分41秒の新しいレンダラーが、同じ4096MBの壁で止まっていました。時間をかけて少しずつ漏れる型ではなく、短時間で一気に埋まる型です。

生成イベントのたびにプロジェクト全体を再構築する処理が正体

ケージを埋めていた正体は、CDP(Chrome DevTools Protocol)によるヒープサンプリングで特定されました。サンプリングされた195MBのライブ割り当てのうち192MBが、単一の関数updateProjectDataに集中していたと報告されています。

呼び出し元を遡ると、この関数はストリーミングで届くイベント全般から呼ばれていました。生成中のツール呼び出しの差分(自己割り当て100MB)、テキストトークン(41MB)、ツールブロックの開始・完了(それぞれ12MB)に加え、Composer(入力欄)へのペーストや入力すら同じ経路(handlePaste → dispatchTransaction → onChange → updateProjectData)を通って14MBを消費していました。トークンが届くたびに、プロジェクトのスナップショット全体を作り直している格好です。

なお、キャンバス自体を描画するプレビューiframeは別プロセスで動作し、アイドル時16MB・書き換え中も112MB以下と小さいままでした。膨らんでいたのはキャンバスではなく、チャットを含むホストページ側です。

コストは、編集の大きさではなく書き換え対象のカードの大きさに比例します。Intel Macの報告者は、264KBのデザインカード1枚に小さな書き込みを繰り返し、デスクトップアプリのレンダラーの常駐メモリを5秒おきに測りました。

待機時の底がほぼ動いていないので、ターンをまたいで漏れ続ける型ではありません。書き込みのたびに出る一時的な確保が、最後の1回だけ解放されなかったという形です。

プロジェクトの規模も効きます。別の報告者は、702ファイル・47.6MB(主にPNGスクリーンショット)のプロジェクトから130枚のスクリーンショットを削除し、572ファイル・12MBまで減らしました。同程度の作業のピークは2347MBから867MBまで下がっています。ただし、91KBの.jsxファイルを書き換える作業は、軽くした後でも約3970MBまで達してタブを落としました。

逆に、小さなプロジェクトでは起きていません。新規の空プロジェクトでは、1ターン1書き込みで22バイトから8.4KBのファイルを書いても落ちず、39ファイルのデザインシステムも3ターン持ちこたえました。大きなプロジェクトを開いてファイルを眺めるだけなら、約417MBで頭打ちです。

Composerへの入力単体でも同じ経路を踏みます。Apple Siliconでの再現実験では、アイドル時900MB前後だったレンダラーが、90秒間の入力継続中は最大3414MBまで上下動を繰り返し、入力をやめると10秒以内にアイドル値へ戻りました。生成を送信していなくても、入力を続けている間はレンダラーのメモリが大きく上下し続けます。

9月11日に始まった退行と、9月12日に観測された改善

複数の報告者が、ハードウェア・OS・ブラウザーが異なるにもかかわらず同じ日にクラッシュし始めたと述べています。それ以前は、数GB規模のDesignプロジェクトが何時間も落ちずに動くのが普通でした。ある環境では、9月10日に4GB超のレンダラーが20時間動き続けたログが残っています。この値はケージ外のメモリを含むRSSなので、ケージが満杯だったとは限りません。

9月12日の変化は数字にも出ています。同じプロジェクト・同じ196ターンのチャットで、16:44より前は約1KBの書き込みでも4〜5.5GBまで跳ね、書き込みのサイズに比例していました。開き直した後は、同種の書き込みが2,582MB、22,473バイトの書き込みが2,381MB、90,191バイトの1回の書き込みでも1,504MBにとどまっています。

サイズに依存しなくなった点から、報告者はイベントごとの再構築がまとめられたか、サーバーが送る差分が減ったかのどちらかと見ています。ただし、これはAnthropicによる説明ではなく、1人の観測に基づく推測です。

issueはopenのままで、最後のコメントは9月12日です。主なラベルは has repro・perf:memory・area:desktop で、このissueにはAnthropicからの返信が付いていません。CLIのプロセスがメモリを使い切るClaude Codeのメモリリークとは別の話で、こちらはDesign画面のレンダラー1つの内側で起きます。

手元でできる回避策

issueに集まった回避策は、いずれも症状を抑える緩和策であり、レンダラーの天井そのものをなくすものではありません。効き方の見立てを、大きい順に並べます。

履歴の代わりに、公式ガイドは「Save what we have and try a completely different approach」と頼めば現在のプロジェクトが保存されると案内しています。画面右上の「Export」からは.zipやPDFで書き出せます。どちらも別方向を試すための保存と書き出しの案内で、クラッシュ後の復旧手順としては書かれていません。重い生成の前に控えを取る選択肢として使えます。

起きている変化をどう見るか

ハードウェア・OS・ブラウザーが異なる複数の利用者が、同じ日に一斉にクラッシュし始めたという事実は、個々の環境のメモリ不足ではなく配信されたコードの変化を示している、と報告者らは見ています。

もう一つ目を引くのは、ここまでの切り分けのほとんどがAnthropicの対応ではなく、複数の利用者による手弁当の調査で進んだ点です。クラッシュダンプの解析、ヒーププロファイリング、ビルド配信時刻の突き合わせまで、原因の特定に必要な作業のかなりの部分を報告者自身が担っています。9月12日の改善も、issue上では利用者の観測にとどまります。

まとめ

落ちたときは、端末のメモリを疑う前に空きメモリと process-memory の値を見る価値があります。空きに余裕があるのに4GB前後で途切れているなら、原因はDesign画面の側です。

今回の報告はいずれもclaude.ai/designの画面(Claude Codeの/design経由の生成は含みません)が対象です。