【C#】イベントハンドラの基本と実践的な使い方：メモリリークを防ぐ注意点まで解説

2026年3月16日2026年5月5日

クラス・オブジェクト指向

C#におけるプログラミングにおいて、イベントハンドラはオブジェクト間の疎結合な通信を実現するための極めて重要な仕組みです。

デスクトップアプリケーションのボタンクリック処理から、バックエンドサービスにおけるステートの変化の通知まで、その用途は多岐にわたります。

イベントハンドラを正しく理解し、適切に実装することは、保守性の高い堅牢なアプリケーションを構築する上での第一歩と言えるでしょう。

しかし、その一方で、イベントハンドラの仕組みはガベージコレクション（GC）との兼ね合いから、メモリリークを引き起こしやすい側面も持っています。

本記事では、C#のイベントハンドラの基礎知識から、実戦で役立つ実装パターン、そして多くの開発者が陥りがちなメモリ管理の注意点まで、プロフェッショナルな視点で詳しく解説していきます。

目次 [ close ]

イベントハンドラの基本概念とデリゲートの関係

C#のイベントシステムを理解するためには、まずその土台となるデリゲート（Delegate）について知る必要があります。

デリゲートとは、メソッドを安全にカプセル化する「関数の型」のような存在です。

イベントはこのデリゲートをベースにして、オブジェクトの状態変化を外部に通知するための特別なカプセル化を提供します。

イベントとデリゲートの違い

デリゲートは直接呼び出すことが可能ですが、イベントは定義したクラス内部からしか呼び出せない（発火できない）という制限があります。

これにより、外部のオブジェクトが勝手にイベントを発生させることを防ぎ、オブジェクトの責務を明確に分離できるのです。

一般的に、イベントを発生させる側を「パブリッシャー（Publisher）」、イベントを受け取って処理を行う側を「サブスクライバー（Subscriber）」と呼びます。

パブリッシャーは特定の条件が満たされたときにイベントを「発行」し、サブスクライバーはあらかじめそのイベントにメソッド（ハンドラ）を「登録」しておくことで、実行時に通知を受け取ります。

C#における標準的なイベントの実装方法

C#では、イベントの実装において推奨される標準的なパターンが存在します。

これに従うことで、他の開発者がコードを理解しやすくなり、フレームワークとの親和性も高まります。

EventHandlerデリゲートの活用

C#には標準で System.EventHandler というデリゲートが用意されています。

特別な理由がない限り、独自のデリゲートを定義するのではなく、この標準デリゲート、またはそのジェネリック版である EventHandler<TEventArgs> を使用するのが一般的です。

以下のコードは、シンプルな温度監視クラスを例に、イベントの定義と発行の手順を示したものです。

using System;

namespace EventExample
{
    // カスタムイベント引数の定義
    public class TemperatureChangedEventArgs : EventArgs
    {
        public double NewTemperature { get; }
        public DateTime Timestamp { get; }

        public TemperatureChangedEventArgs(double newTemperature)
        {
            NewTemperature = newTemperature;
            Timestamp = DateTime.Now;
        }
    }

    // パブリッシャー側のクラス
    public class TemperatureSensor
    {
        // イベントの定義 (標準的なジェネリック版を使用)
        public event EventHandler<TemperatureChangedEventArgs> TemperatureChanged;

        public void MonitorTemperature(double currentTemp)
        {
            Console.WriteLine($"[Sensor] 現在の温度を計測: {currentTemp}℃");

            // イベントの発行
            // null条件演算子 (?.) を使用してスレッドセーフに発火させる
            OnTemperatureChanged(new TemperatureChangedEventArgs(currentTemp));
        }

        // イベント発行用のプロテクトメソッド（継承先でのカスタマイズを可能にする）
        protected virtual void OnTemperatureChanged(TemperatureChangedEventArgs e)
        {
            // 登録されているハンドラがある場合のみ実行
            TemperatureChanged?.Invoke(this, e);
        }
    }

    // サブスクライバー側のクラス
    public class DisplayUnit
    {
        public void OnTemperatureReceived(object sender, TemperatureChangedEventArgs e)
        {
            Console.WriteLine($"[Display] 通知を受信: {e.NewTemperature}℃ (時刻: {e.Timestamp})");
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            var sensor = new TemperatureSensor();
            var display = new DisplayUnit();

            // イベントの購読 (登録)
            sensor.TemperatureChanged += display.OnTemperatureReceived;

            // シミュレーション
            sensor.MonitorTemperature(25.5);
            sensor.MonitorTemperature(27.3);

            // イベントの解除 (解除しないとメモリリークの原因になる)
            sensor.TemperatureChanged -= display.OnTemperatureReceived;
        }
    }
}

実行結果

[Sensor] 現在の温度を計測: 25.5℃
[Display] 通知を受信: 25.5℃ (時刻: 202X/XX/XX XX:XX:XX)
[Sensor] 現在の温度を計測: 27.3℃
[Display] 通知を受信: 27.3℃ (時刻: 202X/XX/XX XX:XX:XX)

この例では、TemperatureChangedEventArgs を定義して、イベントと共にデータを渡しています。

sender パラメータにはイベントを発生させたオブジェクト（この場合は TemperatureSensor）が渡されるため、ハンドラ側でどのオブジェクトがイベントを起こしたかを特定することが可能です。

実践的なイベントハンドラの記述パターン

現代的なC#開発では、コードの簡潔さを求めてラムダ式や匿名メソッドが多用されます。

しかし、これらの記述にはメリットとデメリットがあるため、状況に応じた使い分けが必要です。

ラムダ式によるイベント購読

簡単な処理であれば、メソッドを別途定義せずにラムダ式で記述することができます。

sensor.TemperatureChanged += (sender, e) => 
{
    Console.WriteLine($"簡易表示: {e.NewTemperature}度です。");
};

この記述は非常に簡潔ですが、後でイベントの購読を解除することが困難になるという欠点があります。

名前のない匿名関数として登録されるため、-= 演算子で正確に同じインスタンスを指定して解除することができないからです。

そのため、オブジェクトの生存期間が短い場合や、解除が不要な静的イベント以外では、名前付きメソッドの使用を推奨します。

null条件演算子による安全な発火

以前のC#では、イベントを発火させる前に必ず null チェックを行う必要がありました。

// 旧来の書き方
var handler = TemperatureChanged;
if (handler != null)
{
    handler(this, e);
}

現在では、?.Invoke() を使用することで、より安全かつ簡潔に記述できます。

この書き方は、スレッドセーフであるという利点もあります。

変数を一時変数にコピーすることなく、評価時点での null チェックと実行をアトミックに近い形で行えるためです。

イベントハンドラによるメモリリークの仕組みと回避策

C#の学習において最も注意すべき点が、「イベントハンドラによる強い参照」です。

これが原因で、本来破棄されるべきオブジェクトがメモリ上に残り続ける「Lapsed Listener問題」が発生します。

なぜメモリリークが発生するのか

パブリッシャー（イベントを発行する側）の寿命が、サブスクライバー（イベントを受け取る側）の寿命よりも長い場合を考えてみましょう。

サブスクライバーがパブリッシャーのイベントを購読する。
パブリッシャーは、登録されたメソッド（デリゲート）への参照を内部リストに保持する。
このデリゲートはサブスクライバーのインスタンスメソッドであるため、デリゲート自体がサブスクライバーへの参照を保持することになる。
結果として、パブリッシャーが生きている限り、サブスクライバーもガベージコレクションの対象にならない。

特に、画面遷移が発生するGUIアプリケーション（WPFやWinForms）において、画面を閉じた後もイベント購読が残っていると、古い画面オブジェクトがメモリに残り続け、メモリ使用量が肥大化していきます。

メモリリークを防ぐためのベストプラクティス

メモリリークを防ぐための最も確実な方法は、「使い終わったら必ず登録を解除する」ことです。

IDisposableインターフェースの利用

クラスがイベントを購読している場合、IDisposable インターフェースを実装し、Dispose メソッド内で購読を解除するのが定石です。

public class MySubscriber : IDisposable
{
    private readonly TemperatureSensor _sensor;

    public MySubscriber(TemperatureSensor sensor)
    {
        _sensor = sensor;
        _sensor.TemperatureChanged += OnChanged;
    }

    private void OnChanged(object sender, TemperatureChangedEventArgs e) { /* 処理 */ }

    public void Dispose()
    {
        // 確実に解除する
        _sensor.TemperatureChanged -= OnChanged;
    }
}

弱イベントパターン（Weak Event Pattern）の検討

どうしても解除のタイミングを制御できない場合や、解除し忘れを防ぎたい場合には、「弱イベントパターン」を使用します。

これは、パブリッシャーがサブスクライバーへの「弱い参照（WeakReference）」を持つ仕組みです。

.NET Core / .NET 5以降では、WeakReference<T> を自作してラップするか、WPF環境であれば WeakEventManager を利用することが検討されます。

ただし、弱イベントパターンは実装が複雑になり、パフォーマンスにも若干の影響を与えるため、まずは適切な -= による解除を優先すべきです。

非同期イベントハンドラ（async void）の扱い

モダンなC#開発では、非同期処理（async/await）が欠かせません。

イベントハンドラで非同期処理を行いたい場合、メソッドのシグネチャは async void になります。

async void の危険性と対策

通常、非同期メソッドは async Task を返すべきですが、イベントハンドラのデリゲート定義が void を返却するようになっているため、イベントハンドラに限っては async void が許容されます。

しかし、async void には以下の重大なリスクがあります。

例外のキャッチが困難: 呼び出し元が Task を待機できないため、メソッド内で発生した例外が呼び出し元の try-catch をすり抜け、アプリケーションをクラッシュさせる可能性があります。
完了の待機が不可能: ユニットテストなどで処理の完了を待つことができません。

これを防ぐためには、以下のようにハンドラ内部で必ず例外処理を行うようにします。

public async void OnButtonClick(object sender, EventArgs e)
{
    try
    {
        // 非同期処理の実行
        await Task.Delay(1000);
        await DoSomethingAsync();
    }
    catch (Exception ex)
    {
        // async void 内の例外は必ずキャッチしてログ出力やユーザー通知を行う
        LogError(ex);
    }
}

イベントハンドラ設計のチェックリスト

実務でイベントハンドラを実装する際に、確認すべきポイントを以下の表にまとめました。

項目	内容	重要度
標準パターン	`EventHandler<T>` を使用しているか	高
nullチェック	`?.Invoke` で安全に呼び出しているか	高
メモリ管理	`+=` に対する `-=` が適切な場所にあるか	極高
引数設計	必要なデータは `EventArgs` にカプセル化されているか	中
非同期対応	`async void` 内で適切な `try-catch` を行っているか	高
アクセス権限	`On...` メソッドを `protected virtual` にしているか	中