Claude DesignでMacのメモリが増えクラッシュする原因と回避策

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

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

チャット側の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ブラウザーという、ハードウェア・OS・ブラウザーが重ならない3つの環境から同じ症状が集まりました。Claude Desktopアプリとブラウザー版のclaude.ai/design、両方で再現しており、Desktopアプリに固有の不具合ではありません。Claude Designの基本操作はチャットとキャンバスの2ペイン構成で、この不具合はまさにその生成中に起きます。

原因はメモリ不足ではなくV8エンジンの4GB上限

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

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

16GBのApple Silicon MacでもRAM32GBのIntel Macでも、クラッシュ直前のピークはそろって4.0GB前後でした。搭載RAMの量に関係なく同じ天井にぶつかっているという事実が、原因がシステムメモリの不足ではなくレンダラー内部の上限であることを裏づけています。

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

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

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

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

コストはプロジェクトの規模と、書き換え対象ファイルのサイズの両方に比例します。あるユーザーが702ファイル・47.6MB(主にPNGスクリーンショット)のプロジェクトから130枚のスクリーンショットを削除し572ファイル・12MBまで減らしたところ、同程度の作業のピークが2347MBから867MBまで下がりました。ただし、91KBの.jsxファイルを書き換える作業は、プロジェクトを軽くした後でも約3970MBまで達してタブを落としています。プロジェクトを軽くすることはピークを下げますが、大きな単一ファイルへの書き込みそのものは避けられません。

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

9月11日ごろに始まった退行、翌日に観測された改善

複数の報告者が、ハードウェア・OS・ブラウザーが異なるにもかかわらず同じ日にクラッシュし始めたと述べています。2026年9月11日です。それ以前は、数GB規模のDesignプロジェクトが何時間も落ちずに動くのが普通でした。あるユーザーの環境では、9月10日に4GB超のレンダラーが20時間動き続け、アプリの終了によってのみ止まっていたログが残っています。

クライアント側のキャッシュを調べた報告によると、アプリが読み込むバンドルファイル(desktop-auth-wait-*.js)の新しいビルドが、2026年9月10日14:12(EDT)から翌11日02:22(EDT)の間に配信されていました。観測されたクラッシュはすべてこの新ビルド以降を読み込んだ状態で発生しており、それより前のビルドでの報告は8月31日までさかのぼっても見つかっていません。

9月12日16:44(UTC)ごろには、1人の報告者が部分的な改善を観測しています。同じクライアントバンドル・同じプロジェクトのまま、Design画面を閉じて開き直しただけで、それまで4.7〜5.6GBに達していたピークが2.4GB以下に下がり、送信データ量に比例して重くなる傾向も弱まりました。新しいクライアントバンドルは読み込まれていないため、報告者はサーバー側で何らかの変更があったと推測しています。ただし、これはAnthropicによる公式な説明ではなく、1人の観測に基づく推測です。

issueは2026年9月12日の投稿を最後に動きが止まっており、原因の確定や修正完了を伝えるAnthropicからのコメントはまだ付いていません。Claude Codeのメモリリークと同様、公式のchangelogにもこの不具合に対応する記載は見当たりません。

手元でできる回避策

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

この不具合をどう見るか

ハードウェア・OS・ブラウザーが異なる複数の利用者が、同じ日に一斉にクラッシュし始めたという事実は、個々の環境のメモリ不足ではなく配信されたコードの退行であることを強く示しています。「メモリを増設すれば直る」という発想は成立しません。天井はOSのメモリではなく、レンダラーが内部に持つ4GBのケージにあるからです。

もう一つ目を引くのは、ここまでの切り分けのほとんどがAnthropicの公式対応ではなく、複数の利用者による手弁当の調査で進んだ点です。クラッシュダンプの解析、ヒーププロファイリング、ビルド配信時刻の突き合わせまで、原因の特定に必要な作業のかなりの部分を報告者自身が担っています。9月12日の改善観測も、issue上ではまだ利用者の推測にとどまっており、修正が完了したと判断するのは早計です。大きなプロジェクトでDesignを使っている場合、しばらくは上の回避策を組み合わせて運用し、issueの動きを追うのが安全です。

まとめ

Claude Designで数GB規模のプロジェクトを扱っている、または生成中にComposerへ長文を打ち込む使い方をしている人は、この不具合に遭遇しやすい状況にあります。原因はOSのメモリ不足ではなく、レンダラーが持つV8の4GBケージと、ストリーミングイベントのたびにプロジェクト全体を再構築する実装です。issue上でAnthropicによる修正完了の報告はまだ確認できておらず、長文は外部で書いて貼り付ける、大きなファイルは分割する、未使用の大きな画像は削除するといった回避策を組み合わせて使うのが現実的です。今回集まった報告はいずれもclaude.ai/designの画面(Claude Codeの/design経由の生成は含みません)を対象にしており、それ以外の入り口での挙動は今後の報告を待つ必要があります。