C#のNotImplementedExceptionを適切に扱うためのベストプラクティス

2026年5月23日

例外処理・デバッグ・テスト

C#の開発において、インターフェースを定義した直後や、設計段階でメソッドの枠組みだけを作成した際、仮の処理として例外を投げることがよくあります。

その際、最も頻繁に利用されるのが NotImplementedException です。

しかし、この例外は「開発中の一時的なマーカー」として非常に便利である一方、本番環境に残ってしまうと思わぬトラブルの原因となります。

本記事では、2026年現在のモダンなC#開発における NotImplementedException の適切な扱い方と、保守性の高いコードを書くためのベストプラクティスを検討します。

目次 [ close ]

NotImplementedExceptionの基本的な役割と意味

NotImplementedException は、その名の通り「機能がまだ実装されていないこと」を示すための標準的な例外クラスです。

主に System 名前空間に含まれており、抽象メソッドやインターフェースのメンバを具体的に実装する前のプレースホルダーとして使用されます。

Visual StudioやJetBrains RiderといったIDEにおいて、インターフェースを自動生成した際、デフォルトでこの例外を投げるコードが挿入されることも多いでしょう。

この例外の主な目的は、「実装が完了していないメソッドが誤って呼び出された際に、即座に実行を停止して開発者に知らせる」ことにあります。

以下に、基本的な使用例を示します。

public class PaymentProcessor : IPaymentProcessor
{
    public void ProcessPayment(decimal amount)
    {
        // 2026年度の新しい決済ロジックをここに記述する予定
        throw new NotImplementedException("決済処理は現在開発中です。");
    }
}

NotSupportedExceptionとの決定的な違い

C#には NotImplementedException と似た役割を持つ例外として、NotSupportedException が存在します。

これら二つを混同して使用すると、APIを利用する側のエンジニアが混乱する原因となるため、明確な使い分けが必要です。

NotImplementedException は、「将来的に実装される予定があるが、現時点では未完成である」場合に使用します。

一方で、NotSupportedException は、「設計上の理由により、そのメソッドや機能はそのクラスでは意図的にサポートしていない」場合に使用します。

例えば、読み取り専用のストリームクラスにおいて、Write メソッドを実装する場合、将来も実装する予定がないのであれば NotSupportedException を投げるのが適切です。

この違いを理解しておくことは、オブジェクト指向設計の整合性を保つ上で極めて重要です。

例外クラス名	主な発生理由	想定される状況
NotImplementedException	実装作業が未完了	開発中の機能、プロトタイプ製作時
NotSupportedException	機能が意図的に非対応	読み取り専用クラスでの書き込み試行など
PlatformNotSupportedException	実行環境が非対応	OSやハードウェアの制約による制限

実務におけるベストプラクティス

NotImplementedException を実務で扱う際には、いくつか守るべきルールがあります。

1. メッセージを具体的に記述する

引数なしの new NotImplementedException() を使用すると、デバッグ時にどの機能が欠落しているのかを把握するのに時間がかかる場合があります。

例外をスローする際は、「なぜ未実装なのか」「いつ実装予定なのか」などのコンテキストをメッセージに含めることが推奨されます。

2. 本番環境（Production）への流出を防ぐ

最も重要なルールは、この例外を含むコードを本番環境にデプロイしないことです。

未実装の例外がユーザーの操作によって発生した場合、アプリケーションはクラッシュし、ユーザーエクスペリエンスを著しく低下させます。

CI/CDパイプラインにおいて、静的解析ツール（Roslyn Analyzersなど）を活用し、ソースコード内に NotImplementedException が残っていないかをチェックする仕組みを導入しましょう。

3. インターフェース分離の原則（ISP）を遵守する

もし、あるインターフェースを実装した際に特定のメソッドを「実装する必要がない（常に例外を投げる）」状態になった場合、それは設計の不備である可能性が高いです。

SOLID原則の一つである「インターフェース分離の原則（ISP）」に従い、インターフェースをより小さな単位に分割することを検討してください。

クライアントが利用しないメソッドへの依存を強制させないことが、例外を投げなくて済むクリーンな設計への近道です。

モダンな代替手段：デフォルトインターフェースメソッド

近年のC#（C# 8.0以降）では、「デフォルトインターフェースメソッド」という機能が利用可能です。

これにより、インターフェース側でデフォルトの実装を提供できるようになったため、すべての実装クラスで NotImplementedException を書く手間を減らせる場合があります。

public interface ILogger
{
    void Log(string message);

    // デフォルト実装を提供することで、実装クラスでの強制を回避
    void LogError(string message) => Log($"[Error] {message}");
}

この機能を活用することで、共通の振る舞いを提供しつつ、特定のクラスでのみ詳細な実装を上書きするという柔軟な設計が可能になります。

ただし、ビジネスロジックの本質的な部分をデフォルト実装に頼りすぎると、意図しない挙動を招く恐れがあるため注意が必要です。

静的解析による未実装コードの検出

開発プロジェクトが大規模になると、どこに NotImplementedException が残っているかを把握するのは困難です。

2026年の開発環境においては、カスタムアナライザーを使用して、ビルド時に警告を出す設定が一般的です。

例えば、#if DEBUG プリプロセッサディレクティブを使用して、デバッグビルド時のみ例外を許容し、リリースビルドではコンパイルエラーにする手法も有効です。

public void AdvancedFeature()
{
#if DEBUG
    throw new NotImplementedException("デバッグ中のみ許容される未実装メソッドです。");
#else
    // リリースビルドではコンパイルエラーを誘発させるか、代替処理を記述する
    throw new InvalidOperationException("この機能は現在のバージョンでは利用できません。");
#endif
}

単体テストでの振る舞い確認

未実装のメソッドが含まれるクラスに対して単体テスト（Unit Test）を書く場合、そのメソッドが正しく NotImplementedException を投げることをテストコードで検証しておくことも一つの手法です。

xUnitなどのテスティングフレームワークでは、特定の例外がスローされることをアサートする機能があります。

[Fact]
public void ProcessPayment_ThrowsNotImplementedException()
{
    var processor = new PaymentProcessor();
    Assert.Throws<NotImplementedException>(() => processor.ProcessPayment(100));
}

実行結果

Test Passed: ProcessPayment_ThrowsNotImplementedException

このようにテストを記述しておくことで、将来的に実装が完了した際にテストを更新するリマインダーとしての役割も果たします。

まとめ

NotImplementedException は、C#プログラミングにおいて開発スピードを向上させる便利な道具ですが、その扱いには慎重さが求められます。

単なる「書き忘れ」の言い訳にするのではなく、設計の意図を明確にするために使用しましょう。

また、不適切な例外の使用は、技術負債を蓄積させる原因となります。

「インターフェース分離の原則」や「デフォルトインターフェースメソッド」といった言語機能を組み合わせることで、より堅牢なソフトウェアを構築できます。

適切な例外処理の知識を身につけ、実行時エラーに強い高品質なコードを目指してください。