バリデーション実装の種類と使い分け【C# MVC】

「DataAnnotations だけで十分なのか？」「ModelState はどこでエラー追加すべき？」「複雑な入力チェックはどこで処理する？」

ASP.NET Core MVCでバリデーションを実装する際、このような疑問に直面する開発者は少なくありません。

この記事では、ASP.NET Core MVCで代表的な4つのバリデーション実装手法を整理し、実務での使い分けパターンや選定指針までを詳しく解説します。

DataAnnotations：属性ベースのバリデーション

ASP.NET Core MVCで最も基本的なバリデーション手法が DataAnnotations を用いたものです。これはモデルのプロパティに属性（アノテーション）を付与することで、バリデーションルールを定義する方式です。シンプルな入力チェックに非常に適しており、MVCの標準機能と密に統合されています。

特徴とメリット

✅ 記述が簡単で読みやすい

バリデーションルールをモデルクラスのプロパティに直接記述できるため、コードの見通しが良くなります。[Required] や [StringLength] など、基本的な検証はこの方法でカバーできます。

✅ クライアントサイド検証と連携可能

ASP.NET Coreのビュー（Razor）で TagHelpers を使えば、DataAnnotationsに基づいたクライアントサイド（JavaScript）の自動検証も有効になります。これにより、入力ミスを早期にユーザーへ通知でき、UXも向上します。

✅ 小規模〜中規模のフォームで効果的

フィールドごとの単純なバリデーションには十分な柔軟性があり、特に複雑なロジックを必要としないフォームでは、実装負担を大きく軽減できます。

ASP.NET Core MVCの例

public class UserViewModel
{
    [Required(ErrorMessage = "メールアドレスは必須です")]
    [EmailAddress(ErrorMessage = "正しいメールアドレス形式で入力してください")]
    public string Email { get; set; }

    [Required(ErrorMessage = "パスワードを入力してください")]
    [StringLength(20, MinimumLength = 6, ErrorMessage = "パスワードは6～20文字で入力してください")]
    public string Password { get; set; }
}

このように、属性を通じて明確かつ簡潔に検証ルールを定義できます。

注意点と制約

• フィールド単位の検証に限定されるため、複数フィールドの整合性チェック（例：パスワードと確認用パスワードの一致など）には不向きです。
• 条件付きのバリデーション（例：「他の項目がある値の場合のみ必須」など）を表現するには、カスタム属性を定義する必要があります。

このような特性から、DataAnnotations は「まず使ってみる」手段として非常に有効です。ただし、フォームの複雑さや業務ロジックの複雑度が増すにつれて、他のバリデーション手段との組み合わせが必要になる場面も出てきます。

IValidatableObject：複数項目の整合性チェック

入力バリデーションの中には、単一のフィールドだけではなく、複数の項目を組み合わせて整合性を確認する必要があるケースがあります。そうした要件に対応するのが、IValidatableObject インターフェースを用いた手法です。

特徴と注意点

✅ クロスフィールド検証に最適

たとえば「終了日は開始日より後である必要がある」といったチェックは、開始日と終了日の両方を同時に見なければなりません。IValidatableObject を使えば、このような複数プロパティ間の関係性をチェックできます。

✅ ロジックをモデルに閉じ込められる（凝集度が高い）

バリデーションのロジックをモデル内に保持できるため、バリデーションルールがどこにあるのか明確です。保守性の観点でも優れています。

❗ 外部依存（サービスやDB）を必要とするバリデーションには不向き

Validate() メソッド内ではDI（依存性注入）を利用できないため、たとえば「DBと照合して重複チェックする」といった処理は行えません。その場合は他の手法（後述）を検討する必要があります。

ASP.NET Core MVCの例

public class ReservationViewModel : IValidatableObject
{
    public DateTime StartDate { get; set; }
    public DateTime EndDate { get; set; }

    public IEnumerable<ValidationResult> Validate(ValidationContext validationContext)
    {
        if (StartDate > EndDate)
        {
            yield return new ValidationResult(
                "開始日は終了日より前に設定してください。",
                new[] { nameof(StartDate), nameof(EndDate) });
        }
    }
}

このように、モデル自身が整合性チェックのロジックを持つ形になっています。

活用のポイント

• 入力された値の相互依存性を確認したいとき
• モデルにロジックを集中させ、明確な責任分離を保ちたいとき
• テストコードでモデル単体のバリデーションを検証したいとき

こうした用途において、IValidatableObject はシンプルかつ強力な選択肢となります。ただし、ロジックが複雑化したり、外部データとの整合性を取りたい場合は、他の手段と組み合わせることが重要です。

TryValidateModel：動的な検証処理

ASP.NET Core MVCでは、通常モデルバインディング時に自動でバリデーションが行われます。しかし、実行時に任意のオブジェクトに対して検証を行いたい場合や、フォームの一部だけを検証したいケースでは TryValidateModel メソッドが役立ちます。

利用シーンとメリット

✅ 部分的な検証が可能

一つのViewModelに複数のセクション（たとえば「住所情報」「クレジットカード情報」など）が含まれている場合、画面遷移やタブごとに段階的なバリデーションが必要になることがあります。TryValidateModel を使えば、特定のプロパティセットだけを検証できます。

✅ 動的に生成されたオブジェクトへの適用が可能

コントローラー内で新たに生成・取得したオブジェクトに対して、その場でバリデーションを適用できます。たとえば、外部APIから取得したデータに対してMVCのバリデーションを使う場合などに便利です。

✅ 既存の DataAnnotations や IValidatableObject を活用可能

TryValidateModel は、モデルに定義された既存のバリデーションルールを利用するため、ルールの重複定義が不要です。

ASP.NET Core MVCの例

if (!TryValidateModel(viewModel.AddressPart, "AddressPart"))
{
    // バリデーションに失敗した場合、ModelStateにエラーが追加される
    return View(viewModel); // エラー表示を含む画面に戻る
}

このコードでは、viewModel に含まれる AddressPart プロパティ（部分モデル）のみを対象にバリデーションを実施しています。

補足ポイント

• モデルのルートに対する検証パスを第二引数として指定することで、エラーメッセージの表示位置やModelStateへのマッピングが正しく行われます。
• TryValidateModel は戻り値として bool を返すため、バリデーションの成否を即時に判定可能です。

主な利用ケース

• ステップフォームやマルチタブ入力の段階的検証
• 部分ビューやコンポーネントでの個別検証
• 外部ソースから動的に生成されるデータの検証

このように、TryValidateModel は動的UIや複雑な入力フローを伴うアプリケーションで特に威力を発揮します。

ModelState.AddModelError：手動でのエラー登録

ASP.NET Core MVCのバリデーション機能は非常に強力ですが、DataAnnotations や IValidatableObject だけでは表現できない複雑なチェックや、外部リソースとの整合性確認なども実務ではよく発生します。こうしたケースでは、ModelState.AddModelError を使って明示的にエラーを追加することで、柔軟に対応可能です。

適用タイミングと使い方

✅ 外部サービスとの照合チェック

たとえば「ユーザーが入力したメールアドレスが既存ユーザーとして登録済みか？」といった検証は、データベースや外部APIへの照会が必要です。これは DataAnnotations や IValidatableObject では扱えないため、バリデーションロジックをコントローラーやサービス層で記述し、ModelState に手動でエラーを追加します。

✅ 複雑な業務ルールに対応

「ある条件に該当する場合だけ必須入力にする」など、入力値の状態や組み合わせによって検証条件が変わるケースにも対応できます。

✅ フィールド指定あり／なし両方に対応可能

特定フィールドに紐付いたエラーはもちろん、string.Empty をキーとして渡せば**全体エラー（グローバルエラー）**として画面上に表示することも可能です。

ASP.NET Core MVCの例

if (!db.UserExists(model.Email))
{
    ModelState.AddModelError("Email", "このメールアドレスは登録されていません。");
}

// システム的な全体エラーを追加する場合
if (externalService.HasIssue())
{
    ModelState.AddModelError(string.Empty, "現在、システムで一時的な問題が発生しています。");
}

このように、任意のタイミング・条件で ModelState にエラーを追加できるため、MVCフレームワークのバリデーション機構と柔軟に組み合わせられます。

活用のコツ

• エラー内容を ViewData や TempData に格納するのではなく、ModelState に登録することで、Html.ValidationMessageFor() などのタグヘルパーによる自動表示が有効になります。
• 複雑なルールはサービス層に分離し、バリデーション結果だけをコントローラーで処理する設計にすると、可読性・テスト性も向上します。

この手法は、業務要件や外部連携が絡む場面で必要不可欠です。標準のバリデーションで賄えない部分を補完するための「最後の砦」として活用すると良いでしょう。

実務での使い分けパターン【早見表】

ASP.NET Core MVCでは、複数のバリデーション手法が提供されていますが、実務での「使いどころ」を見誤ると、過剰な実装や保守性の低下を招くことがあります。このセクションでは、代表的なユースケースに応じた最適なバリデーション手法の選び方を、早見表形式で整理します。

シーン別：おすすめバリデーション手法

補足：複数手法の併用が基本

✅ 単一の手法に依存しない設計が重要

たとえば「基本チェックは DataAnnotations、クロスフィールドは IValidatableObject、API照合は ModelState.AddModelError」というように、用途に応じて複数の手法を併用するのが実務では一般的です。

✅ ViewModelの粒度とUI構成に応じて選定

ViewModelが大規模化している場合、部分検証可能な TryValidateModel の活用や、入力ブロックごとに小さなViewModelへ分割する工夫も効果的です。

このように、それぞれの手法には得意・不得意があり、適材適所で使い分けることが成功のカギとなります。次のセクションでは、実際の選定をサポートする「フローチャート」を紹介します。

バリデーション手法の選定フロー

複数のバリデーション手段がある中で、「どれを使うべきか？」という判断は状況により異なります。実務では、UIの構成やバリデーションロジックの複雑さ、外部連携の有無などを踏まえて選定する必要があります。

このセクションでは、判断をスムーズに行うための簡易フローチャートを用意しました。

フローチャート：最適なバリデーション手法の選び方

以下のチャートに従って、自身のシナリオに合ったバリデーション方式を選択してみましょう。

シンプルな1項目ごとの検証で十分？
├─ YES → DataAnnotations
└─ NO
   └─ モデル内で自己完結できる？
       ├─ YES → IValidatableObject
       └─ NO
           ├─ 動的な検証が必要？ → TryValidateModel()
           └─ 外部チェックや独自ルール → ModelState.AddModelError

このチャートを使うことで、以下のような判断ができます：

• UIが単純で1項目ずつ検証可能な場合：DataAnnotations で迅速に実装
• 複数項目の整合性を検証したい場合：IValidatableObject で完結型に設計
• フォーム構成が複雑またはステップ制入力などの場合：TryValidateModel() で柔軟な検証
• ビジネスロジックや外部システムに依存する検証がある場合：ModelState.AddModelError で明示的にエラー追加

選定時のアドバイス

✅ ルールが増えたら、早めにViewModelを分割すること

1つのモデルにすべての検証を詰め込みすぎると保守が困難になります。責務に応じて分割し、必要なバリデーション手法を適用するとよいでしょう。

✅ ModelStateのチェックは常に必須

ModelState.IsValid のチェックを怠ると、バリデーションエラーが無視されてしまうため、アクションメソッドの先頭で常に確認しましょう。

このような選定プロセスを設けることで、実装時の迷いを減らし、バリデーションにおける設計品質を安定させることができます。

まとめ

ASP.NET Core MVCでは、さまざまなバリデーション手法が用意されており、それぞれに特化した用途があります。今回紹介した4つの代表的な手段を理解し、適切に使い分けることは、品質の高いフォーム入力処理を実現するうえで不可欠です。

以下は、各手法の特徴と適用場面を整理した一覧です：

✅ ポイントは「併用」と「責務分離」

実務では、これらの手法を単独で使うことは稀です。シンプルなチェックには DataAnnotations、複雑な整合性は IValidatableObject、API連携や条件付きの検証は ModelState.AddModelError で補完するなど、状況に応じた組み合わせが基本になります。

✅ 設計段階での検証設計が重要

後からバリデーションを追加・変更するのは大きな負荷となりがちです。プロジェクトの初期段階で、どのレイヤーでどのようにバリデーションを行うかを設計しておくと、保守性が格段に向上します。