TypeScriptのメモリリークを解決！Chrome DevToolsを使った原因特定と効果的な対策5選

TypeScriptで開発を進めていると、メモリリークは避けて通れない課題です。
特に長時間稼働するアプリケーションや、大規模なSPAでは、見落としがちなメモリリークが最終的に重大なパフォーマンス低下を招くことがあります。
本記事では、Chrome DevToolsの強力なプロファイリング機能を活用して、TypeScriptアプリケーションにおけるメモリリークの原因を特定し、効果的に解決する方法を解説します。

メモリリークの原因は多岐にわたりますが、大きく分けて以下のパターンが挙げられます。

• イベントリスナーの解除漏れ
• クロージャによる意図しない参照保持
• setIntervalやsetTimeoutのクリーンアップ漏れ
• DOM要素への参照が残ったままの状態
• グローバル変数やシングルトンによる永続的なメモリ占有

これらの問題を解決するため、Chrome DevToolsの Performance タブと Memory タブを組み合わせて使うことで、リークの発生箇所を数ステップで特定できるようになります。
以下では、実際のプロジェクトで役立つ5つの対策を、具体的なコード例とともにご紹介します。

TypeScriptのメモリリークとは？発生メカニズムと影響範囲を理解する

メモリリークとは、アプリケーションが使用しなくなったメモリ領域を適切に解放できず、使用可能なメモリが徐々に減少していく現象です。
TypeScriptはJavaScriptにコンパイルされて実行されるため、基本的にはJavaScriptのガベージコレクション（GC）機構に依存します。
しかし、GCが自動でメモリを回収するからといって、開発者がメモリ管理を完全に無視できるわけではありません。
むしろ、GCの動作原理を理解した上で、意図しない参照保持を防ぐ設計が求められます。

メモリリークが発生する根本的なメカニズムは、到達可能なオブジェクトグラフに不要なオブジェクトが残り続けることにあります。
JavaScriptのGCはマークアンドスイープ方式を採用しており、グローバルオブジェクトから辿れる参照チェーンに含まれるオブジェクトは「生きている」と判断され、回収の対象外となります。
このため、開発者が気づかないうちに不要なオブジェクトへの参照を保持してしまうと、そのオブジェクトとそこから参照されるすべてのオブジェクトがメモリ上に留まり続けます。

TypeScriptアプリケーションで特に注意すべきメモリリークの発生パターンには、以下のようなものがあります。

• イベントリスナーを登録したまま解除せず、DOM要素やコンポーネントが破棄された後も参照を保持し続ける
• クロージャのスコープ内で外部変数をキャプチャし、意図せず大きなオブジェクトを長期間保持する
• setIntervalやsetTimeoutのコールバック内でオブジェクトを参照し、タイマーがクリアされないまま動作し続ける
• DOM要素をJavaScriptの変数に直接参照し、DOMツリーから切り離された後もメモリ上に残す
• シングルトンパターンやグローバルな状態管理オブジェクトに大量のデータを蓄積し、適切なクリーンアップを行わない

これらのパターンは、小規模なアプリケーションでは顕在化しにくいものの、長時間稼働するSPAや大規模なバックエンドサービスでは致命的な影響を及ぼします。
具体的には、ブラウザのタブがクラッシュする、Node.jsプロセスがOOM（Out of Memory）で強制終了する、レスポンスタイムが悪化するといった症状が現れます。

メモリリークの影響範囲は、発生箇所によって大きく異なります。
以下の表に、主要な発生箇所とその影響をまとめます。

発生箇所	影響の対象	典型的な症状
フロントエンド（ブラウザ）	エンドユーザーの端末	タブのクラッシュ、UIの重さ、フリーズ
バックエンド（Node.js）	サーバー全体	プロセスの再起動、レスポンス遅延、503エラー
共有ライブラリ	複数のサービス	横展開による全サービスへの影響

特にNode.js環境では、1つのプロセスが複数のリクエストを処理するため、メモリリークが発生するとすべての接続ユーザに影響が及びます。
これはブラウザ環境と比較して影響範囲が広く、早期発見と対策が不可欠です。

TypeScriptの型システムは、実行時のメモリ管理には直接関与しません。
しかし、適切な型設計とインターフェース定義は、メモリリークを防ぐ上で間接的に大きな役割を果たします。
例えば、ライフサイクルを持つオブジェクトに対してDisposableパターンを型レベルで表現することで、リソースの解放責任を明確にし、解放漏れを減らすことができます。

interface Disposable {
    dispose(): void;
}

class DataCache implements Disposable {
    private data: Map<string, object> = new Map();

    add(key: string, value: object): void {
        this.data.set(key, value);
    }

    dispose(): void {
        this.data.clear();
    }
}

このように、型システムを活用してリソース管理の責務をコードに反映させることは、メモリリーク対策の第一歩となります。
次の章では、Chrome DevToolsを使って実際にメモリリークを可視化し、具体的な原因を特定する方法を解説します。

Chrome DevToolsのMemoryパネルの使い方：Heap Snapshotでリークを可視化する

メモリリークの調査において、定性的な推測に頼るのではなく定量的なデータに基づいて原因を特定することが最も重要です。
Chrome DevToolsのMemoryパネルは、まさにそのための強力なツールであり、特にHeap Snapshot機能はメモリリークの可視化に不可欠です。
本章では、Heap Snapshotの取得方法から、取得したデータの読み解き方までを体系的に解説します。

Heap Snapshotを取得する手順は以下の通りです。

• Chromeで対象のページを開き、F12キーまたは右クリックメニューから「検証」を選択してDevToolsを起動する
• 上部タブから「Memory」を選択し、「Heap snapshot」ラジオボタンを選択する
• 左上の丸いボタンをクリックしてスナップショットを取得する
• 操作を行った後、再度スナップショットを取得して比較する

この比較こそがリーク検出の核心です。
1回目のスナップショットを取得した後、疑わしい操作を繰り返し実行し、2回目のスナップショットを取得することで、メモリが増加しているオブジェクトを特定できます。
例えば、モーダルダイアログを開閉する処理にリークがあると疑う場合は、その開閉を10回程度繰り返してから2回目のスナップショットを取得します。

Heap Snapshotの結果画面は、主に以下の3つのビューで構成されています。

ビュー名	表示内容	用途
Summary	コンストラクタ名ごとにオブジェクトを集計	どのクラスがメモリを消費しているか把握
Comparison	2つのスナップショット間の差分を表示	メモリ増加の原因を特定
Containment	オブジェクトの参照ツリーを表示	どのオブジェクトから参照されているか追跡

Summaryビューでは、コンストラクタ名、オブジェクト数、シャローサイズ、保持サイズが一覧表示されます。
ここで重要なのは「保持サイズ（Retained Size）」です。
これは、あるオブジェクトがガベージコレクションによって回収された場合に解放されるメモリの合計量を示しており、保持サイズが大きいオブジェクトほどメモリリークの影響が大きいと判断できます。

Comparisonビューの使い方を具体的に見ていきましょう。
2つのスナップショットを取得した後、Comparisonを選択し、比較対象の1回目のスナップショットを選択します。
すると、各コンストラクタごとに「# New」「# Deleted」「# Delta」が表示されます。
# Deltaの値がプラスで大きくなっているコンストラクタが、メモリリークの主要な原因候補となります。

特にTypeScriptで開発する際は、トランスパイル後のJavaScriptコードがどのようにメモリ上に展開されるかを意識する必要があります。
例えば、クラスベースの設計では、インスタンスが適切に解放されていない場合、# Deltaにそのクラス名が大きな値で表示されます。
以下は、Comparisonビューで検出したリークの原因を特定するための調査フローです。

// リークの原因となりやすいパターン：イベントリスナーの登録
class ModalManager {
    private modals: HTMLElement[] = [];

    openModal(element: HTMLElement): void {
        this.modals.push(element);
        // 解放処理がないため、modals配列が無限に増加する
    }
}

このようなコードでは、ComparisonビューでArrayやHTMLElementの# Deltaが増加していることが確認できます。
次に、該当コンストラクタをクリックして詳細を開き、下部のRetainersセクションで「Distance」列を確認します。
Distanceの値が小さいオブジェクトほど、ルートに近い位置で参照を保持していることを意味し、解放すべき参照の起点を特定しやすくなります。

Heap Snapshotの取得には注意点もあります。
スナップショット取得中はメインスレッドがブロックされるため、大規模なアプリケーションでは数秒間UIがフリーズする可能性があります。
また、開発環境のソースマップが有効になっている場合、トランスパイル前のTypeScriptファイル名と行番号が表示されるため、デバッグが容易になります。
ソースマップが無効な場合は、コンパイル後のJavaScriptコードの行番号が表示されるため、対応関係を把握しておく必要があります。

さらに、「Allocation instrumentation on timeline」という機能も活用すると効果的です。
これは、時間軸に沿ってメモリの割り当てを記録する機能で、特定の操作を実行したタイミングでどのオブジェクトが割り当てられたかを可視化できます。
Heap Snapshotが「ある時点のメモリ状態のスナップショット」であるのに対し、Allocation Timelineは「時間経過に伴うメモリ割り当ての履歴」を捉えるため、リークの発生タイミングを特定する際に補完的に使用します。

Memoryパネルを使いこなすことで、これまで暗黙的であったメモリの動きを可視化でき、TypeScriptアプリケーションの品質を根本的に向上させることができます。
次章では、Allocation SamplingとTimeline Recordingを組み合わせた、より高度な追跡手法について解説します。

Allocation SamplingとTimeline Recordingでリアルタイムにメモリ変動を追跡する

Heap Snapshotはある時点のメモリ状態を捉えるのに優れていますが、メモリリークが発生するタイミングやその経過をリアルタイムに追跡したい場合には、Allocation SamplingとTimeline Recordingの組み合わせが極めて有効です。
これらの機能を使いこなすことで、特定のユーザー操作や非同期処理の実行中にどの関数がメモリを消費しているかを、コードレベルで特定できます。

まず、Timeline Recordingの基本的な使い方から解説します。
Memoryパネルで「Timeline」ラジオボタンを選択し、赤い丸の録画ボタンをクリックすると記録が開始されます。
記録中にアプリケーションを操作し、停止ボタンを押すと、その間のメモリ使用量の推移がグラフとして表示されます。
このグラフの縦軸は使用メモリ量を示し、鋸歯状に上昇し続けるパターンはメモリリークの典型的な兆候です。
一方、上昇と下降を繰り返す鋸歯状のグラフは、GCが正常に動作している状態を示しており、健全なメモリ使用パターンと判断できます。

Timeline Recordingの結果画面では、メモリ使用量のグラフの下に、各時点で割り当てられたオブジェクトのコンストラクタが一覧表示されます。
ここで重要なのは、グラフ上の特定の時点をクリックすると、その時点で割り当てられたオブジェクトの詳細が表示されるという点です。
これにより、メモリ使用量が急増したタイミングでどのようなオブジェクトが生成されたかを正確に把握できます。

次に、Allocation Samplingについて見ていきましょう。
これは、一定間隔でメモリの割り当てスタックをサンプリングする機能であり、パフォーマンスへの影響を最小限に抑えながら長時間の記録が可能です。
Memoryパネルで「Allocation sampling」を選択し記録を開始すると、どの関数呼び出しでどれだけのメモリが割り当てられたかが、関数ごとに集計されて表示されます。

Allocation Samplingの結果は、以下のような構造で表示されます。

列名	内容	活用方法
Function	メモリを割り当てた関数	リークの起点となる関数を特定
Size	割り当てられたメモリサイズ	影響の大きさを定量化
File	関数が定義されているファイル	ソースコードへの遡り
Line	行番号	正確なコード位置の特定

この結果を読み解く際のポイントは、「Top Down」ビューと「Heavy」ビューを切り替えて確認することです。
Top Downビューでは、呼び出し元から呼び出し先へとツリー状に展開され、どの処理フローでメモリが消費されているかが把握しやすくなります。
一方、Heavyビューでは、個別の関数ごとにメモリ割り当て量が集計され、どの関数が最も多くのメモリを消費しているかが一目でわかります。

実際の調査シナリオを考えてみましょう。
ユーザーがリストをスクロールするたびにメモリが増加していくという問題があったとします。
この場合、以下の手順で原因を特定します。

• Timeline Recordingでスクロール操作を記録し、メモリ使用量の上昇パターンを確認する
• 上昇が確認されたタイムレンジを選択し、Allocation Samplingを開始する
• スクロール操作を繰り返しながらサンプリングを実行する
• Heavyビューで上位に表示された関数を確認し、該当コードを調査する

このフローを踏むことで、「スクロールイベントハンドラ内でDOM要素を生成しているが、参照が解放されていない」といった原因に到達できます。

Timeline RecordingとAllocation Samplingを組み合わせる際の実践的なテクニックとして、「メモリ使用量のピーク前後でスナップショットを取得する」方法があります。
Timeline上でメモリが急増した直後にHeap Snapshotを取得し、Comparisonビューで直前のスナップショットと比較することで、増加したオブジェクトの詳細を把握できます。
このハイブリッドなアプローチは、リアルタイムの追跡と詳細なオブジェクト分析の両方の強みを活かすことができます。

なお、Allocation Samplingはサンプリングベースの計測であるため、頻繁に実行される短い関数のメモリ割り当ては正確に捉えられない場合があります。
逆に、長時間実行される処理や大量のメモリを割り当てる処理は高い精度で検出できます。
この特性を理解した上で、必要に応じてHeap SnapshotやAllocation Timelineと使い分けることが重要です。

TypeScriptの型情報は実行時には消去されるため、DevTools上ではコンパイル後のJavaScript関数名が表示されます。
ソースマップが正しく設定されていれば、元のTypeScriptファイル名と行番号が表示されますが、アロー関数や匿名関数が多いコードベースでは、関数名が推論されにくく調査が困難になることがあります。
このような場合は、パフォーマンスクリティカルな関数には明示的な名前付き関数を使用するか、displayNameプロパティを設定しておくと、DevTools上での特定が容易になります。

// 名前付き関数にすることでDevToolsでの特定を容易にする
function processDataChunk(chunk: DataChunk): void {
    // 処理内容
}

// アロー関数の場合は変数に代入して名前を付ける
const handleScroll = (event: Event): void => {
    // スクロール処理
};

これらのリアルタイム追跡手法を習得することで、メモリリークの発生タイミングと原因関数を数分で特定できるようになります。
次章からは、具体的な対策パターンを5つに分けて解説し、それぞれの実装例とベストプラクティスを紹介します。

対策その1：イベントリスナーの適切な解除とWeakRefの活用

イベントリスナーは、TypeScriptアプリケーションで最も頻繁に発生するメモリリークの原因の一つです。
addEventListenerで登録したリスナーを解除せずにDOM要素を破棄すると、その要素はガベージコレクションの対象にならず、メモリ上に残り続けます。
特にSPAでは、コンポーネントのマウントとアンマウントが繰り返されるため、この問題が顕在化しやすいです。

まず、基本的なイベントリスナーの解除パターンを確認します。
最もシンプルな方法は、removeEventListenerを対で呼び出すことです。

class ScrollHandler {
    private element: HTMLElement;
    private boundOnScroll: EventListener;

    constructor(element: HTMLElement) {
        this.element = element;
        this.boundOnScroll = this.onScroll.bind(this);
        this.element.addEventListener('scroll', this.boundOnScroll);
    }

    destroy(): void {
        this.element.removeEventListener('scroll', this.boundOnScroll);
    }

    private onScroll(event: Event): void {
        // スクロール処理
    }
}

このコードの重要なポイントは、リスナー関数への参照をインスタンス変数として保持していることです。
アロー関数や無名関数をその場で渡すと、removeEventListenerで同じ関数参照を指定できなくなるため、必ず名前付きの関数またはbindした関数を保持する必要があります。

しかし、実際の開発ではイベントリスナーの管理が複雑化し、解除漏れが発生しやすくなります。
そこで、AbortControllerを活用した一括解除パターンが有効です。
これは比較的新しいAPIですが、モダンブラウザでは広くサポートされています。

class EventManager {
    private controller: AbortController;

    constructor(element: HTMLElement) {
        this.controller = new AbortController();
        const { signal } = this.controller;

        element.addEventListener('click', this.onClick, { signal });
        element.addEventListener('mousemove', this.onMouseMove, { signal });
        window.addEventListener('resize', this.onResize, { signal });
    }

    dispose(): void {
        this.controller.abort();
    }

    private onClick = (event: MouseEvent): void => { /* ... */ };
    private onMouseMove = (event: MouseEvent): void => { /* ... */ };
    private onResize = (event: Event): void => { /* ... */ };
}

AbortControllerを使うことで、複数のイベントリスナーを一つのdispose呼び出しでまとめて解除できるため、コードの見通しが良くなり、解除漏れのリスクも大幅に減少します。

次に、より高度な手法としてWeakRefの活用を解説します。
WeakRefはES2021で導入された機能で、オブジェクトへの「弱い参照」を作成することができます。
弱い参照は、ガベージコレクションの対象から除外されないため、参照先のオブジェクトが他に強い参照を持っていない場合にGCによって回収されます。

class WeakEventCache {
    private cache: Map<string, WeakRef<HTMLElement>> = new Map();

    register(id: string, element: HTMLElement): void {
        this.cache.set(id, new WeakRef(element));
    }

    getElement(id: string): HTMLElement | undefined {
        const ref = this.cache.get(id);
        if (ref) {
            const element = ref.deref();
            if (element) {
                return element;
            }
            // 要素がGCされた場合はマップから削除
            this.cache.delete(id);
        }
        return undefined;
    }
}

このパターンは、キャッシュやマップ構造でDOM要素を保持する際に特に有効です。
通常のMapやWeakMapとの使い分けを理解しておくことが重要です。
以下にそれぞれの特性をまとめます。

構造	キーの型	値のGC対象性	主な用途
Map	任意	値はGCされない	永続的なデータ保持
WeakMap	オブジェクトのみ	キーがGCされると値もGC対象	プライベートデータの紐付け
Map + WeakRef	任意	値が弱参照のためGC対象	キャッシュのような一時的な保持

WeakRefを使う際の注意点として、deref()メソッドは必ずundefinedを返す可能性があることを考慮する必要があります。
これは、参照先のオブジェクトがGCによって回収された後にderef()を呼び出した場合に発生します。
したがって、deref()の戻り値を常にnullチェックし、回収済みの場合は適切なフォールバック処理を行う必要があります。

さらに、TypeScriptの型システムを活用して、イベントリスナーのライフサイクルを型レベルで保証する方法も考えられます。
例えば、以下のようにDisposableインターフェースを実装し、必ずdisposeメソッドを呼び出すことを強制する設計にできます。

interface Disposable {
    dispose(): void;
}

class ModalComponent implements Disposable {
    private listeners: Array<{ element: HTMLElement; type: string; handler: EventListener }> = [];

    attachListener(element: HTMLElement, type: string, handler: EventListener): void {
        element.addEventListener(type, handler);
        this.listeners.push({ element, type, handler });
    }

    dispose(): void {
        for (const { element, type, handler } of this.listeners) {
            element.removeEventListener(type, handler);
        }
        this.listeners = [];
    }
}

このように、イベントリスナーの登録と解除を対称的な構造で管理し、型システムで解放責任を明確にすることで、メモリリークを根本的に防ぐことができます。
最終的には、フレームワーク側のライフサイクルフック（ReactならuseEffectのクリーンアップ関数、VueならonUnmountedなど）と組み合わせて、コンポーネント破棄時に必ずdisposeが呼ばれるように実装すると、堅牢なメモリ管理が実現できます。

イベントリスナー周りのメモリリークは、一度習得したパターンを徹底することでほぼ完全に防ぐことができます。
次章では、クロージャによる意図しない参照保持という、より巧妙なメモリリークのパターンについて解説します。

対策その2：クロージャによる意図しない参照保持を防ぐ設計パターン

クロージャはJavaScriptおよびTypeScriptの強力な機能の一つですが、その仕組みを正しく理解しないと、意図しない参照保持を引き起こし、深刻なメモリリークの原因となります。
クロージャは、関数が定義されたスコープ内の変数へのアクセス権を保持する仕組みですが、この「保持」がメモリ上での参照保持を意味することを常に意識する必要があります。

まず、典型的なクロージャによるメモリリークのパターンを確認しましょう。
以下のコードは、よく見かける実装パターンですが、実は重大なメモリリークを内包しています。

function createHeavyDataProcessor() {
    const hugeData = new Array(1000000).fill('x'); // 大量のデータ

    return {
        process: (index: number): string => {
            return hugeData[index] ?? '';
        },
        getMetadata: (): { count: number } => {
            return { count: hugeData.length };
        }
    };
}

const processor = createHeavyDataProcessor();
// processor.getMetadata() だけを使い続ける場合でも、hugeData全体がメモリに残る

このコードでは、getMetadataメソッドはhugeDataの長さ情報だけを返しますが、クロージャの性質上、hugeData全体への参照を保持し続けるため、100万件のデータがメモリに残ります。
processメソッドを一度も呼ばなくても、getMetadataを使い続ける限りhugeDataは解放されません。

この問題を解決するための設計パターンとして、必要なデータだけをクロージャに閉じ込める「最小化クロージャ」パターンが有効です。

function createOptimizedProcessor() {
    const hugeData = new Array(1000000).fill('x');

    const count = hugeData.length; // 必要な値だけを抽出

    return {
        process: (() => {
            const dataRef = hugeData; // process専用のクロージャ
            return (index: number): string => {
                return dataRef[index] ?? '';
            };
        })(),
        getMetadata: ((): (() => { count: number }) => {
            const capturedCount = count; // メタデータ専用のクロージャ
            return (): { count: number } => {
                return { count: capturedCount };
            };
        })()
    };
}

この実装では、IIFE（即時実行関数式）を使って各メソッドごとに独立したクロージャを作成し、不要な変数のキャプチャを防いでいます。
getMetadataのクロージャはcount（数値）だけをキャプチャするため、hugeData配列本体への参照は保持しません。

次に、イベントハンドラ内でクロージャを使う際の注意点を解説します。
以下のパターンは、コールバック関数内で外部スコープの大きなオブジェクトを参照することで、メモリリークを引き起こします。

class DataFetcher {
    private cache: Map<string, object> = new Map();

    setupPeriodicFetch(url: string): void {
        setInterval(() => {
            fetch(url).then(response => response.json()).then(data => {
                this.cache.set(url, data);
            });
        }, 5000);
    }
}

このコードでは、setIntervalのコールバックがthis（すなわちDataFetcherインスタンス）をキャプチャします。
さらに、そのインスタンスはcache（Map）を保持しているため、タイマーがクリアされるまでDataFetcherインスタンスとcacheのすべてのエントリがメモリに留まり続けます。
対策としては、必要なデータだけをコールバックに渡すか、クラスメソッドを適切にバインドして不要な参照を切る方法があります。

class DataFetcher {
    private cache: Map<string, object> = new Map();
    private timerId: ReturnType<typeof setInterval> | null = null;

    setupPeriodicFetch(url: string): void {
        const cacheRef = this.cache; // 必要な参照だけを抽出

        this.timerId = setInterval(() => {
            fetch(url).then(response => response.json()).then(data => {
                cacheRef.set(url, data);
            });
        }, 5000);
    }

    stop(): void {
        if (this.timerId !== null) {
            clearInterval(this.timerId);
            this.timerId = null;
        }
    }
}

この改善版では、stopメソッドでタイマーを確実にクリアし、さらにコールバック内でthis全体ではなくcacheだけを参照することで、インスタンスの他のプロパティへの不要な参照を防いでいます。

クロージャのメモリ影響を理解する上で、以下の表に示すスコープキャプチャのパターンとその影響を整理しておきます。

パターン	キャプチャ内容	メモリ影響	推奨度
関数全体のthisをキャプチャ	インスタンスすべて	最大	低
必要なプロパティのみを局所変数に代入してキャプチャ	指定したプロパティのみ	中	中
IIFEで独立したスコープを作成	最小限の変数のみ	最小	高
WeakRefで弱参照を使用	参照先がGC可能	最小	高（特定用途）

さらに、TypeScriptの型システムを活用して、クロージャのキャプチャ範囲を明示的に制限する方法も考えられます。
例えば、ファクトリ関数の引数として必要なデータだけを受け取るインターフェースを定義することで、実装者が不要なデータをクロージャに閉じ込めることを防ぐことができます。

interface FetchConfig {
    url: string;
    intervalMs: number;
}

interface CacheOperations {
    set(key: string, value: object): void;
}

function createFetchTask(config: FetchConfig, cache: CacheOperations): () => void {
    const { url, intervalMs } = config;

    const timerId = setInterval(() => {
        fetch(url).then(response => response.json()).then(data => {
            cache.set(url, data);
        });
    }, intervalMs);

    return () => {
        clearInterval(timerId);
    };
}

この設計では、createFetchTask関数はCacheOperationsインターフェースを通じて必要最小限の操作だけを受け取ります。
呼び出し元の大きなオブジェクト全体を渡すのではなく、インターフェースに適合した最小限の実装だけを渡すことで、クロージャによる意図しない参照保持を防ぐことができます。

クロージャによるメモリリークは、コードレビューでは見落とされやすいものです。
開発時には、関数がどのスコープの変数をキャプチャしているかを常に意識し、DevToolsのHeap Snapshotで実際にどのオブジェクトが保持されているかを検証する習慣を身につけることが重要です。
次章では、タイマー関数のクリーンアップについて解説します。

対策その3：setIntervalとsetTimeoutのクリーンアップを徹底する

setIntervalとsetTimeoutは、非同期処理を実現するための基本的なAPIですが、タイマーIDを適切に管理し解除しないと、コールバック関数とそこから参照されるすべてのオブジェクトがメモリに残り続けるという重大なメモリリークを引き起こします。
特にSPAや長時間稼働するNode.jsアプリケーションでは、この問題が顕在化しやすいです。

まず、最も基本的なクリーンアップ漏れのパターンを確認しましょう。
以下のコードは、見た目には問題なく動作しますが、コンポーネントやクラスが不要になった後もタイマーが動作し続けます。

class NotificationService {
    startPolling(): void {
        setInterval(() => {
            this.fetchNotifications();
        }, 3000);
    }

    private fetchNotifications(): void {
        // 通知を取得する処理
    }
}

このコードでは、setIntervalの戻り値であるタイマーIDをどこにも保持していないため、外部からタイマーを停止する手段が完全に失われます。
結果として、インスタンスが不要になった後も3秒ごとにfetchNotificationsが実行され続け、インスタンスとその参照先のオブジェクトがすべてメモリに留まります。

対策としては、タイマーIDをインスタンス変数として保持し、適切なタイミングでclearIntervalまたはclearTimeoutを呼び出すことが不可欠です。

class NotificationService {
    private timerId: ReturnType<typeof setInterval> | null = null;

    startPolling(): void {
        this.stopPolling(); // 二重登録を防ぐ
        this.timerId = setInterval(() => {
            this.fetchNotifications();
        }, 3000);
    }

    stopPolling(): void {
        if (this.timerId !== null) {
            clearInterval(this.timerId);
            this.timerId = null;
        }
    }

    destroy(): void {
        this.stopPolling();
    }

    private fetchNotifications(): void {
        // 通知を取得する処理
    }
}

この改善版では、以下の点に注意しています。

• タイマーIDをprivateなインスタンス変数として保持する
• startPollingの先頭で既存のタイマーを停止し、二重登録を防ぐ
• destroyメソッドで確実にクリーンアップを行う
• タイマー停止後にnullを代入し、二重解放を防ぐ

次に、ReactやVueなどのフレームワークを使用する場合の実装パターンを解説します。
フレームワークではコンポーネントのライフサイクルに紐づけてタイマーを管理する必要があります。
Reactの場合は、useEffectのクリーンアップ関数を活用します。

import { useEffect, useRef } from 'react';

function usePolling(callback: () => void, intervalMs: number): void {
    const savedCallback = useRef<() => void>(callback);
    const timerIdRef = useRef<ReturnType<typeof setInterval> | null>(null);

    useEffect(() => {
        savedCallback.current = callback;
    }, [callback]);

    useEffect(() => {
        timerIdRef.current = setInterval(() => {
            savedCallback.current();
        }, intervalMs);

        return () => {
            if (timerIdRef.current !== null) {
                clearInterval(timerIdRef.current);
                timerIdRef.current = null;
            }
        };
    }, [intervalMs]);
}

このカスタムフックでは、useEffectの戻り値としてクリーンアップ関数を返すことで、コンポーネントのアンマウント時や依存配列が変更された際に自動的にタイマーが停止されます。
また、useRefを使ってタイマーIDを保持することで、レンダリング間で値が保持されつつも再レンダリングを引き起こさない設計になっています。

Node.js環境では、setTimeoutやsetIntervalのコールバック内で例外が発生した場合の挙動にも注意が必要です。
以下のコードは、例外が発生するとタイマーが停止してしまうため、エラーハンドリングとタイマーの継続実行を両立させる必要があります。

class RetryableTask {
    private timerId: ReturnType<typeof setTimeout> | null = null;
    private readonly maxRetries: number;
    private retryCount = 0;

    constructor(maxRetries: number = 3) {
        this.maxRetries = maxRetries;
    }

    schedule(delayMs: number): void {
        this.cancel();
        this.timerId = setTimeout(() => {
            this.execute();
        }, delayMs);
    }

    private execute(): void {
        try {
            this.retryCount = 0;
            this.runTask();
        } catch (error) {
            if (this.retryCount < this.maxRetries) {
                this.retryCount++;
                this.schedule(1000 * this.retryCount);
            }
        }
    }

    private runTask(): void {
        // 実際の処理
    }

    cancel(): void {
        if (this.timerId !== null) {
            clearTimeout(this.timerId);
            this.timerId = null;
        }
    }
}

この実装では、executeメソッド内で例外をキャッチし、リトライ回数の範囲内であれば新しいタイマーを再スケジュールします。
これにより、一時的なエラーでタイマーが完全に停止するのを防ぎつつ、メモリリークも防ぐことができます。

タイマー管理におけるベストプラクティスを以下の表にまとめます。

項目	悪い実装	良い実装
タイマーIDの管理	変数に代入しない	インスタンス変数またはrefで保持
二重登録	チェックなしで複数回start	start時に既存タイマーを停止
クリーンアップ	呼び出し元に委ねる	destroy/disposeメソッドで一元管理
フレームワーク連携	ライフサイクルを無視	useEffectのクリーンアップ関数を活用
エラーハンドリング	例外でタイマー停止	try-catchで継続制御

さらに、タイマーのコールバック内でthisを参照する際の注意点も解説しておきます。
TypeScriptでは、クラスメソッドをコールバックとして渡す際にthisのコンテキストが失われるため、以下のようにbindするかアロー関数でラップする必要があります。

class TimerManager {
    private count = 0;
    private timerId: ReturnType<typeof setInterval> | null = null;

    start(): void {
        this.timerId = setInterval(() => {
            this.increment(); // アロー関数でthisを保持
        }, 1000);
    }

    private increment(): void {
        this.count++;
    }

    stop(): void {
        if (this.timerId !== null) {
            clearInterval(this.timerId);
            this.timerId = null;
        }
    }
}

アロー関数を使うことで、定義時のthis（すなわちTimerManagerインスタンス）がクロージャとして保持されるため、コールバック内でも正しくインスタンスメソッドにアクセスできます。

タイマーのクリーンアップは、一見単純な実装に見えますが、エッジケース（二重登録、例外発生、フレームワーク連携など）を考慮しないと確実にメモリリークを引き起こします。
コードレビューでは、必ずタイマーIDの保持場所と解除箇所を確認する習慣を定着させることが重要です。
次章では、DOM要素の参照管理について解説します。

対策その4：DOM要素の参照管理とDetached DOM Treeの排除

DOM要素への参照管理は、フロントエンド開発におけるメモリリーク対策の中でも特に重要なテーマです。
JavaScriptの変数からDOM要素への参照が残ったまま、その要素がDOMツリーから切り離されると、Detached DOM Treeが生成され、ガベージコレクションの対象にならなくなります。
Chrome DevToolsのMemoryパネルでは、このDetached DOM Treeが「Detached HTMLDivElement」などの形で検出できるため、原因特定の手がかりとなります。

まず、Detached DOM Treeが発生する典型的なパターンを確認しましょう。
以下のコードは、リストアイテムを動的に追加・削除する機能を持つクラスですが、削除後も参照が残るためメモリリークを引き起こします。

class TodoList {
    private container: HTMLElement;
    private items: HTMLElement[] = [];

    constructor(container: HTMLElement) {
        this.container = container;
    }

    addItem(text: string): void {
        const li = document.createElement('li');
        li.textContent = text;
        this.container.appendChild(li);
        this.items.push(li);
    }

    clearItems(): void {
        this.container.innerHTML = '';
        // items配列からの削除を忘れている
    }
}

このコードの問題点は、clearItemsメソッドでcontainer.innerHTML = ''によりDOMツリーから要素を削除しているものの、items配列への参照が残っているため、要素はメモリ上に留まり続ける点にあります。
Heap SnapshotのComparisonビューで確認すると、HTMLLIElementの# Deltaが増加していることが確認できます。

対策としては、DOM要素を削除する際に、JavaScript側の参照も確実に解放する必要があります。

class TodoList {
    private container: HTMLElement;
    private items: HTMLElement[] = [];

    constructor(container: HTMLElement) {
        this.container = container;
    }

    addItem(text: string): void {
        const li = document.createElement('li');
        li.textContent = text;
        this.container.appendChild(li);
        this.items.push(li);
    }

    clearItems(): void {
        this.container.innerHTML = '';
        this.items = []; // 参照を完全に解放
    }

    removeItem(index: number): void {
        const item = this.items[index];
        if (item && item.parentNode) {
            item.parentNode.removeChild(item);
        }
        this.items.splice(index, 1);
    }
}

この改善版では、clearItemsでitems配列を空にすることで、DOM要素へのJavaScript側の参照を完全に切っています。
removeItemメソッドでは、DOMツリーからの削除と配列からの削除を両方行うことで、参照の整合性を保っています。

次に、より高度なパターンとして、イベントリスナーとDOM要素の参照が絡み合うケースを解説します。
以下のコードは、ツールチップ機能を実装したものですが、イベントリスナーとDOM要素の参照が循環しているため、メモリリークが発生します。

class TooltipManager {
    private tooltips: Map<HTMLElement, HTMLElement> = new Map();

    attach(target: HTMLElement, content: string): void {
        const tooltip = document.createElement('div');
        tooltip.className = 'tooltip';
        tooltip.textContent = content;
        document.body.appendChild(tooltip);

        const showTooltip = (): void => {
            tooltip.style.display = 'block';
        };

        const hideTooltip = (): void => {
            tooltip.style.display = 'none';
        };

        target.addEventListener('mouseenter', showTooltip);
        target.addEventListener('mouseleave', hideTooltip);

        this.tooltips.set(target, tooltip);
    }

    detach(target: HTMLElement): void {
        const tooltip = this.tooltips.get(target);
        if (tooltip) {
            tooltip.remove();
            this.tooltips.delete(target);
            // イベントリスナーの解除を忘れている
        }
    }
}

このコードでは、detachメソッドでツールチップ要素をDOMツリーから削除し、Mapからも削除していますが、target要素に登録したイベントリスナーが解除されていないため、target要素とtooltip要素の両方がメモリに残り続けます。
さらに、showTooltipとhideTooltipのクロージャがtooltipをキャプチャしているため、参照の循環が生じています。

改善版では、イベントリスナーの解除とAbortControllerの活用を組み合わせます。

class TooltipManager {
    private tooltips: Map<HTMLElement, { element: HTMLElement; controller: AbortController }> = new Map();

    attach(target: HTMLElement, content: string): void {
        const tooltip = document.createElement('div');
        tooltip.className = 'tooltip';
        tooltip.textContent = content;
        document.body.appendChild(tooltip);

        const controller = new AbortController();
        const { signal } = controller;

        target.addEventListener('mouseenter', () => {
            tooltip.style.display = 'block';
        }, { signal });

        target.addEventListener('mouseleave', () => {
            tooltip.style.display = 'none';
        }, { signal });

        this.tooltips.set(target, { element: tooltip, controller });
    }

    detach(target: HTMLElement): void {
        const entry = this.tooltips.get(target);
        if (entry) {
            entry.controller.abort();
            entry.element.remove();
            this.tooltips.delete(target);
        }
    }

    destroy(): void {
        for (const [target, entry] of this.tooltips) {
            entry.controller.abort();
            entry.element.remove();
        }
        this.tooltips.clear();
    }
}

この改善版では、AbortControllerを使ってイベントリスナーを一括解除し、DOM要素の削除とJavaScript側の参照削除を対称的に行うことで、Detached DOM Treeの生成を完全に防いでいます。

Detached DOM Treeの検出と対策の流れを以下の表にまとめます。

手順	操作内容	確認ポイント
1. スナップショット取得	操作前にHeap Snapshotを取得	ベースラインの確立
2. 操作実行	要素の追加・削除を繰り返す	実際のユースケースを再現
3. GC実行	DevToolsのゴミ箱アイコンで強制GC	不要なオブジェクトの回収を促す
4. 再スナップショット	操作後にHeap Snapshotを取得	差分の比較対象
5. 比較分析	ComparisonビューでDetachedを検索	増加している要素を特定

さらに、DOM要素の参照をWeakRefで管理する手法も有効です。
これは、要素がDOMツリーから切り離された後にJavaScript側の参照も自動的に弱くなるため、GCの対象にしやすくなります。

class WeakElementCache {
    private cache: Map<string, WeakRef<HTMLElement>> = new Map();

    register(id: string, element: HTMLElement): void {
        this.cache.set(id, new WeakRef(element));
    }

    getElement(id: string): HTMLElement | null {
        const ref = this.cache.get(id);
        const element = ref?.deref();
        if (!element) {
            this.cache.delete(id);
        }
        return element ?? null;
    }
}

ただし、WeakRefは必ずしも即座にGCされるわけではなく、deref()の戻り値がundefinedになった場合のフォールバック処理を必ず実装する必要があります。
これは、GCのタイミングが実装依存であるためです。

DOM要素の参照管理は、フロントエンド開発の基礎中の基礎でありながら、見落とされやすいポイントです。
DOMツリーからの削除とJavaScript側参照の解放を常にセットで行うことを徹底し、DevToolsで定期的にDetached DOM Treeが発生していないか確認する習慣を定着させることが重要です。
次章では、シングルトンとグローバル変数のメモリ管理について解説します。

対策その5：シングルトンとグローバル変数のメモリ管理を見直す

シングルトンパターンとグローバル変数は、アプリケーション全体で共有すべき状態やリソースを一元管理する上で便利な手法ですが、その性質上、メモリリークが発生すると影響範囲が広く、長期的にメモリ使用量が増大し続けるという特徴があります。
本章では、シングルトンとグローバル変数を安全に設計・運用するためのメモリ管理戦略を解説します。

まず、シングルトンにおける典型的なメモリリークのパターンを確認しましょう。
以下のコードは、ユーザーの操作履歴を永続的に蓄積するシングルトンですが、データの上限を設けていないため、メモリ使用量が無限に増大します。

class HistoryManager {
    private static instance: HistoryManager;
    private logs: string[] = [];

    private constructor() {}

    static getInstance(): HistoryManager {
        if (!HistoryManager.instance) {
            HistoryManager.instance = new HistoryManager();
        }
        return HistoryManager.instance;
    }

    addLog(message: string): void {
        this.logs.push(message);
    }

    getLogs(): string[] {
        return this.logs;
    }
}

このコードでは、addLogメソッドが呼ばれるたびにlogs配列が増加し、アプリケーションのライフタイム中に蓄積されたすべてのログがメモリに残り続けます。
特にログメッセージが大きい場合や、高頻度でログが追加される場合は、短期間で深刻なメモリ不足に陥る可能性があります。

対策としては、データの上限を設け、古いデータを自動的に破棄するLRU（Least Recently Used）キャッシュの仕組みを導入することが有効です。

class BoundedHistoryManager {
    private static instance: BoundedHistoryManager;
    private logs: string[] = [];
    private readonly maxSize: number;

    private constructor(maxSize: number = 1000) {
        this.maxSize = maxSize;
    }

    static getInstance(maxSize?: number): BoundedHistoryManager {
        if (!BoundedHistoryManager.instance) {
            BoundedHistoryManager.instance = new BoundedHistoryManager(maxSize);
        }
        return BoundedHistoryManager.instance;
    }

    addLog(message: string): void {
        if (this.logs.length >= this.maxSize) {
            this.logs.shift(); // 最も古いログを破棄
        }
        this.logs.push(message);
    }

    clearLogs(): void {
        this.logs = [];
    }

    getLogs(): readonly string[] {
        return this.logs;
    }
}

この改善版では、maxSizeを設定し、上限に達した場合はshift()メソッドで最も古いログを破棄してから新しいログを追加します。
また、clearLogsメソッドを提供することで、明示的なメモリ解放の手段を確保しています。

次に、グローバル変数を使う際の注意点を解説します。
TypeScriptではwindowオブジェクトやglobalThisを通じてグローバルな変数を定義できますが、これらの変数はアプリケーションの終了までGCの対象にならないため、特に注意が必要です。

// グローバル変数によるメモリリークの例
(window as any).temporaryCache = new Map<string, object>();

// 処理が完了しても、グローバル変数は解放されない
function processLargeData(data: object): void {
    (window as any).temporaryCache.set('lastResult', data);
}

このコードでは、temporaryCacheがグローバルスコープに定義されているため、明示的に削除しない限り永続的にメモリを占有します。
対策としては、グローバル変数の使用を最小限に抑え、代わりにスコープを限定した変数や依存性注入（DI）パターンを使用することが推奨されます。

class ScopedCache {
    private cache: Map<string, object> = new Map();
    private readonly maxEntries: number;

    constructor(maxEntries: number = 100) {
        this.maxEntries = maxEntries;
    }

    set(key: string, value: object): void {
        if (this.cache.size >= this.maxEntries) {
            const firstKey = this.cache.keys().next().value;
            this.cache.delete(firstKey);
        }
        this.cache.set(key, value);
    }

    get(key: string): object | undefined {
        return this.cache.get(key);
    }

    clear(): void {
        this.cache.clear();
    }

    dispose(): void {
        this.clear();
    }
}

// 使用側でスコープを管理
function executeTask(): void {
    const cache = new ScopedCache(50);
    // 処理を実行
    cache.dispose(); // 確実に解放
}

この実装では、ScopedCacheクラスは使用側の関数スコープ内でインスタンス化され、関数終了時にdisposeメソッドで確実に解放されます。
これにより、グローバルスコープへの依存を排除し、メモリリスクを大幅に低減できます。

シングルトンとグローバル変数のメモリ管理戦略を以下の表にまとめます。

戦略	適用対象	効果	実装コスト
上限付きデータ構造	シングルトンの内部状態	メモリ使用量の天井を設定	低
明示的なクリアメソッド	キャッシュ・ログ・一時データ	不要になった時点で即座に解放	低
スコープ限定のインスタンス	グローバル変数の代替	ライフタイムを自動的に管理	中
WeakMap/WeakRefの活用	オブジェクト間の関連付け	キーがGCされると自動的に解放	中
定期的なメトリクス監視	すべての長寿命オブジェクト	異常な増加を早期に検知	高

さらに、シングルトン内部で大きなオブジェクトを遅延初期化（Lazy Initialization）する手法も有効です。
これは、必要になるまでオブジェクトを生成せず、メモリ使用量を抑えるための一般的な最適化パターンです。

class LazyResourceManager {
    private static instance: LazyResourceManager;
    private heavyResource: HeavyResource | null = null;

    private constructor() {}

    static getInstance(): LazyResourceManager {
        if (!LazyResourceManager.instance) {
            LazyResourceManager.instance = new LazyResourceManager();
        }
        return LazyResourceManager.instance;
    }

    getResource(): HeavyResource {
        if (!this.heavyResource) {
            this.heavyResource = new HeavyResource();
        }
        return this.heavyResource;
    }

    releaseResource(): void {
        this.heavyResource = null;
    }
}

このパターンでは、heavyResourceは初めてgetResourceが呼ばれた時点で生成されます。
しかし、生成後はシングルトンインスタンスが参照を保持し続けるため、releaseResourceメソッドで明示的に解放する必要があります。
これは、リソースの使用が一時的な場合に特に有効です。

最後に、シングルトンとグローバル変数のメモリ使用量を監視するための仕組みを紹介します。
Node.js環境では、process.memoryUsage()を使って定期的にメモリ使用量をログ出力し、異常な増加を検知できます。

class MemoryMonitor {
    private intervalId: ReturnType<typeof setInterval> | null = null;

    startMonitoring(intervalMs: number = 60000): void {
        this.stopMonitoring();
        this.intervalId = setInterval(() => {
            const usage = process.memoryUsage();
            console.log(`Heap Used: ${(usage.heapUsed / 1024 / 1024).toFixed(2)} MB`);
        }, intervalMs);
    }

    stopMonitoring(): void {
        if (this.intervalId !== null) {
            clearInterval(this.intervalId);
            this.intervalId = null;
        }
    }
}

このモニタリング機能をシングルトンクラスと組み合わせることで、内部データ構造の増加とメモリ使用量の相関を把握し、上限設定の妥当性を検証することができます。

シングルトンとグローバル変数は便利な反面、メモリ管理の責任が開発者に大きく依存します。
データの上限を設け、明示的な解放手段を提供し、スコープを適切に限定することで、安全で持続可能な設計を実現できます。
次章では、これまで解説した内容を総括し、実践的なワークフローを提示します。

まとめ：Chrome DevToolsとTypeScriptの組み合わせでメモリリークを確実に防ぐ

本記事では、TypeScriptアプリケーションにおけるメモリリークの原因特定と対策について、Chrome DevToolsのプロファイリング機能を中心に解説してきました。
ここまでの内容を整理し、実践的なワークフローとしてまとめます。

メモリリーク対策の本質は、「発見から修正、そして再発防止までのサイクルを高速化する」ことにあります。
Chrome DevToolsのMemoryパネルとPerformanceパネルを使いこなすことで、これまで暗黙的であったメモリの動きを可視化し、定量的な根拠に基づいて問題を解決できるようになります。

まず、メモリリークの調査フローとして、以下のステップを推奨します。

• 症状の確認：ブラウザのタブが重くなる、Node.jsプロセスが再起動するなどの症状からメモリリークを疑う
• ベースラインの取得：MemoryパネルでHeap Snapshotを取得し、正常時のメモリ状態を記録する
• 操作の再現：疑わしい操作を繰り返し実行し、メモリ使用量の変化をTimeline Recordingで追跡する
• 差分の分析：操作後に再度Heap Snapshotを取得し、Comparisonビューで増加したオブジェクトを特定する
• 原因の特定：Retainersツリーを遡り、どの変数やクロージャが不要なオブジェクトを保持しているかを調査する
• 修正の実装：特定した原因に対して、本章で解説した5つの対策パターンのいずれかを適用する
• 検証の繰り返し：修正後に再度スナップショットを取得し、リークが解消されたことを確認する

このフローの中で最も重要なのは、「推測に頼らず、データに基づいて原因を特定する」という点です。
メモリリークの原因は一見すると複雑に見えますが、DevToolsの機能を使えば、どのオブジェクトが増加しているか、どの関数から参照されているかを数分で特定できます。

本章で解説した5つの対策を再度整理すると、以下の通りです。

対策	対象となるリークパターン	核心となる手法
イベントリスナーの解除	addEventListenerの解除漏れ	removeEventListenerまたはAbortController
クロージャの設計見直し	意図しない参照保持	スコープの最小化とIIFEの活用
タイマーのクリーンアップ	setInterval/setTimeoutの停止漏れ	タイマーIDの管理とライフサイクル連携
DOM要素の参照管理	Detached DOM Treeの生成	DOM削除とJS参照解放の対称性確保
シングルトンの上限設定	グローバル状態の無限増加	上限付きデータ構造と明示的なクリア

これらの対策は個別に適用することもできますが、複数のパターンが同時に発生しているケースが少なくありません。
例えば、シングルトンがDOM要素への参照を保持し、その要素にイベントリスナーが登録されているような場合は、各層で適切な解放処理を実装する必要があります。

TypeScriptの型システムは、実行時のメモリ管理には直接関与しませんが、インターフェース設計とクラス構造を通じて、リソース管理の責務をコードに反映させる強力な手段となります。
Disposableパターンやファクトリ関数の引数設計など、型レベルでライフサイクルを表現することで、チーム全体で一貫したメモリ管理の慣習を確立できます。

最後に、メモリリーク対策を継続的に実践するための心構えとして、以下の点を強調しておきます。

• メモリリークは「一度直せば終わり」ではなく、機能追加のたびに再発する可能性がある
• コードレビューでは、イベントリスナーの登録・解除の対称性、タイマーのライフサイクル、DOM操作後の参照解放を必ず確認する
• 本番環境では、メモリ使用量のメトリクスを収集し、異常な増加をアラートで検知する仕組みを導入する
• 開発環境では、定期的にDevToolsでHeap Snapshotを取得し、リグレッションがないか確認する習慣を定着させる

Chrome DevToolsとTypeScriptの組み合わせは、メモリリークという見えにくい問題を、論理的かつ定量的に解決するための強力なツールセットです。
本記事で解説した手法を日常的に活用し、堅牢で持続可能なアプリケーションの開発に役立てていただければ幸いです。