こんにちは。ようこそ、技術の深淵へ。

私は世界中の大規模システムを支える開発環境のアーキテクトとして、これまで数え切れないほどの「動かない」「重い」「落ちる」という現場を救ってきました。

今日、君に伝授するのは、Webアプリケーション開発において最も恐ろしく、かつ最も見落とされがちな「メモリリーク」というサイレントキラーの仕留め方です。

JavaScriptは、ガベージコレクション（GC）があるからメモリ管理は不要だと思っていませんか？それは大きな誤解です。ブラウザの裏側では、君が書いたコードの「消し忘れ」が、ユーザーのデバイスをじわじわと蝕んでいることがあります。

この記事では、Chrome DevToolsの「Memory」タブを使いこなし、ブラウザの内部で何が起きているのかを可視化する、プロフェッショナル直伝の解析フローを解説します。これをマスターすれば、君は「ただコードを書く人」から「システムの安定性を保証するエンジニア」へと進化できるはずです。

準備はいいですか？さあ、深呼吸して、ブラウザの心臓部を覗きに行きましょう。

—

1. なぜ「Memory」タブが必要なのか？

現代のフロントエンド開発（React, Vue, Angularなど）では、コンポーネントの生成と破棄が激しく繰り返されます。

メモリリークが発生するとどうなるか？
最初はサクサク動いていても、数分使うと動作がカクつく。
スマホブラウザでページが突然リロードされる（OSによるメモリ強制解放）。
最終的にブラウザがクラッシュする。

「Memory」タブは、ブラウザが確保しているメモリ（Heap）の「スナップショット」を撮り、どのオブジェクトが、なぜ、誰に掴まれたまま解放されないのかを突き止めるためのX線写真のようなものです。

—

2. 実践：メモリリークを再現する「練習用コード」

まずは、あえてメモリリークを起こすコードを準備しましょう。これが今回の「動作確認」のためのセットアップです。以下のHTMLファイルをローカルで作成し、Chromeで開いてください。

メモリリーク解析ラボ

Memory Leak Simulator

—

3. 秘伝：Heap Snapshotの「3回撮影法」

メモリリークを特定する最も確実な方法は、「何もしない状態」「アクション後」「解消を試みた後」の3つの状態を比較することです。

ステップ1：初期状態の記録

1. Chromeで上記のHTMLを開き、`F12`（または右クリック > 検査）でDevToolsを開きます。
2. 「Memory」タブを選択します。
3. 左上のゴミ箱アイコン（Collect garbage）をクリックしてください。

プロの知見：解析を始める前に手動でGCを走らせ、ノイズ（掃除されるべきゴミ）を消すのが鉄則です。

4. 「Heap snapshot」にチェックが入っていることを確認し、「Take snapshot」をクリックします。これがSnapshot 1（基準点）になります。

ステップ2：リーク操作の実行

1. 画面上の「リークを発生させる」ボタンを5〜10回ほど連打してください。
2. 再び「Take snapshot」をクリックします。これがSnapshot 2（増殖後）です。

ステップ3：解消操作（または待機）

1. 本来ならメモリが解放されるはずの操作（今回の場合は「クリア」ボタンを押すなど）を行います。
2. 再度ゴミ箱アイコンをクリックしてGCを強制し、もう一度「Take snapshot」を撮ります。これがSnapshot 3（最終状態）です。

—

4. 運命の解析：Detached DOMを見つけ出す

Snapshotが3つ並んだら、ここからがアーキテクトの仕事です。

「Comparison（比較）」モードの活用

Snapshot 3を選択した状態で、上部のプルダウン（初期値はSummary）を「Comparison」に変更し、比較対象を「Snapshot 1」にします。

ここで注目すべきは、「New」（新しく増えたもの）と「Deleted」（消えたもの）の差分です。

Detached DOM（切り離されたDOM要素）の特定

検索ボックスに `Detached` と入力してみてください。

Detached HTMLDivElement が赤く表示されていませんか？
これは、「DOMツリーからは切り離されている（画面には映っていない）のに、JavaScriptの変数が参照を握っているためにメモリから消せない要素」です。

「Retainers（保持者）」を読み解く

見つけた `Detached HTMLDivElement` をクリックすると、下側に「Retainers」というパネルが表示されます。ここには「なぜこの要素はメモリに残っているのか？」の家系図が表示されます。

リストを辿っていくと、`leakyStorage in Window` という表示が見つかるはずです。
これは「Windowオブジェクトにある `leakyStorage` という配列が、このDOM要素を掴んでいるから解放できないんだよ」というブラウザからの告白です。

—

5. アーキテクトが教える「現場の知見」

Shallow Size と Retained Size の違い

Memoryタブで最も重要な指標がこの2つです。

Shallow Size（自己サイズ）:

そのオブジェクト自体が消費しているメモリ量です。DOM要素単体なら微々たるものです。

Retained Size（保持サイズ）:

そのオブジェクトを削除したときに、芋づる式に解放されるメモリの総量です。
大きな配列が1つのDOMを掴んでいる場合、そのDOMを解放すれば配列も消えるなら、Retained Sizeは巨大になります。私たちが真っ先に削るべきは、この数値が大きい項目です。

ガベージコレクションを信じすぎない

「関数が終われば変数は消えるはず」というのは理想論です。

イベントリスナーの解除忘れ (`removeEventListener`)
`setInterval` の止め忘れ
クロージャによる意図しない変数の保持

これらはすべて、今回の実験と同じように「参照の鎖」となってメモリを食いつぶします。

—

終わりに：君のコードが、より美しくなるために

メモリ管理を意識し始めると、君の書くコードは劇的に変わります。「使い終わった参照は null を代入して切っておこう」「このイベントリスナーはコンポーネントの破棄時に消しているかな？」という視点が、アプリケーションの品質を極限まで高めるのです。

今日、君はブラウザの裏側にある「見えない資産」を管理する術を学びました。これは、ライブラリの使い方を覚えるよりもずっと価値のある、一生モノの技術です。

ぜひ、今作っているプロジェクトでも `Take snapshot` を実行してみてください。そこには、君の助けを待っている「迷子のオブジェクト」たちが、きっとたくさん眠っているはずですから。

また次の講義でお会いしましょう。素晴らしいエンジニアライフを！