このページにアクセスするには、承認が必要です。 サインイン または ディレクトリの変更 を試すことができます。 このページにアクセスするには、承認が必要です。 ディレクトリの変更 を試すことができます。 これは、この記事の最新バージョンではありません。 現在のリリースについては、この記事の .NET 10 バージョン を参照してください。 このバージョンの ASP.NET Coreはサポートされなくなりました。 詳細については、 .NETおよびコア サポート ポリシー .NETを参照してください。 現在のリリースについては、この記事の .NET 10 バージョン を参照してください。 この記事では、ASP.NET Core API のエラーを処理する方法について説明します。 最小限の API のドキュメントが選択されています。 コントローラー ベースの API のドキュメントを表示するには、 Controllers タブを選択します。Blazor エラー処理のガイダンスについては、 ASP.NET Core Blazor アプリでのハンドル エラー を参照してください。 この記事では、ASP.NET Core API のエラーを処理する方法について説明します。 コントローラー ベースの API のドキュメントが選択されています。 Minimal API のドキュメントを表示するには、 Minimal API タブを選択します。Blazor エラー処理のガイダンスについては、 ASP.NET Core Blazor アプリでのハンドル エラー を参照してください。 " 開発者例外ページ " には、未処理の要求の例外に関する詳細な情報が表示されます。 DeveloperExceptionPageMiddleware を使用して、HTTP パイプラインから同期および非同期例外をキャプチャし、エラー応答を生成します。 開発者例外ページはミドルウェア パイプラインの早い段階で実行されるため、次のミドルウェアでスローされたハンドルされない例外をキャッチできます。 ASP.NET Coreアプリでは、次の両方の場合に開発者例外ページが既定で有効になります。 Development 環境 で実行されています。 アプリが現在のテンプレート、つまり WebApplication.CreateBuilder を使用して作成された。 以前のテンプレート、つまり WebHost.CreateDefaultBuilder を使用して作成されたアプリは、 app.UseDeveloperExceptionPage を呼び出すことによって開発者例外ページを有効にすることができます。 Development 環境でアプリが実行されている場合を除き 、開発者例外ページを有効にしないでください。 アプリが運用環境で実行されている場合は、詳細な例外情報をパブリックに共有しないでください。 環境の構成の詳細については、「 ASP.NET Core ランタイム環境 」を参照してください。 開発者例外ページには、例外と要求に関する次の情報を含めることができます。 クエリ文字列パラメーター (存在する場合) エンドポイント メタデータ (存在する場合) 開発者例外ページでは、情報が提供されるとは限りません。 完全なエラー情報については、 ログ記録 に関するページを参照してください。 次の図は、タブと表示される情報を示すアニメーションを含むサンプル開発者例外ページを示しています。 Accept: text/plain ヘッダーを含む要求への応答で、開発者例外ページは HTML ではなくプレーン テキストを返します。 例えば次が挙げられます。 最小限の API で開発者例外ページを表示するには: Development 環境 でサンプル アプリを実行します。 /exception エンドポイントに移動します。 このセクションでは、最小 API で例外を処理する方法を示すために、次のサンプル アプリを参照します。 エンドポイント /exception がリクエストされると、例外が発生します。 コントローラー ベースの API で開発者例外ページを表示するには: コントローラー ベースの API に次のコントローラー アクションを追加します。 エンドポイントへの要求があると、アクションによって例外がスローされます。 [HttpGet("Throw")] public IActionResult Throw() => throw new Exception("Sample exception."); コントローラー ベースの API に次のコントローラー アクションを追加します。 エンドポイントへの要求があると、アクションによって例外がスローされます。 開発環境 でアプリを実行します。 開発環境 でアプリを実行します。 コントローラー アクションによって定義されたエンドポイントに移動します。 コントローラー アクションによって定義されたエンドポイントに移動します。 開発環境以外では、 例外ハンドラー ミドルウェア を使用してエラー ペイロードを生成します。 exception handler middleware を構成するには、 UseExceptionHandler を呼び出します。 たとえば、次のコードは、 RFC 7807 準拠のペイロードでクライアントに応答するようにアプリを変更します。 詳細については、この記事の後半の「 問題の詳細 」セクションを参照してください。 Program.cs で、 UseExceptionHandler を呼び出して、例外処理ミドルウェアを追加します。 var app = builder.Build(); app.UseHttpsRedirection(); if (!app.Environment.IsDevelopment()) { app.UseExceptionHandler("/error"); } app.UseAuthorization(); app.MapControllers(); app.Run(); Program.cs で、 UseExceptionHandler を呼び出して、例外処理ミドルウェアを追加します。 /error ルートに応答するようにコントローラー アクションを構成します。 [Route("/error")] public IActionResult HandleError() => Problem(); /error ルートに応答するようにコントローラー アクションを構成します。 上記の HandleError アクションは、 RFC 7807 準拠のペイロードをクライアントに送信します。 HttpGet などの HTTP メソッド属性を使ってエラー ハンドラー アクション メソッドをマークしないでください。 明示的な動詞を使用すると、一部の要求がアクション メソッドに到達できなくなります。 Swagger/OpenAPI を使用する Web API の場合は、[ ApiExplorerSettings] 属性でエラー ハンドラー アクションをマークし、その IgnoreApi プロパティを true に設定します。 この属性構成では、エラー ハンドラー アクションがアプリの OpenAPI 仕様から除外されます。 認証されていないユーザーにエラーが表示される場合は、メソッドへの匿名accessを許可します。 クライアントとサーバーのエラー応答 次の最小 API アプリについて考えてみましょう。 /users エンドポイントは、 200 OK が json より大きい場合、 User の id 表現を持つ 0 を返し、それ以外の場合はレスポンス本文を含まない 400 BAD REQUEST ステータス コードを返します。 応答の作成の詳細については、「 最小限の API アプリで応答を作成する 」を参照してください。 Status Code Pages middleware は、すべての HTTP クライアント ( 400 -) またはサーバー ( 499 500 -) の応答に対して、 599 に共通の本文内容を生成するように構成できます。 ミドルウェアは、 UseStatusCodePages 拡張メソッドを呼び出すことによって構成されます。 たとえば、次の例では、ルーティング エラー ( など) を含むすべてのクライアントとサーバーの応答について、 404 NOT FOUND 準拠のペイロードでクライアントに応答するようにアプリを変更します。 詳細については、「 問題の詳細 」セクションを参照してください。 コントローラー ベースの API の場合、エラー応答は次のいずれかの方法で構成できます。 問題の 詳細サービス を使用する ProblemDetailsFactory を実装する ApiBehaviorOptions.ClientErrorMapping を使用する エラー結果 は、HTTP 状態コードが 400 以上の結果として定義されます。 Web API コントローラーの場合、MVC はエラー結果を変換して ProblemDetails を生成します。 エラー 状態コードの ProblemDetails の自動作成は、既定で有効になっています。 問題の詳細 は、HTTP API エラーを記述する唯一の応答形式ではありませんが、一般的に HTTP API のエラーを報告するために使用されます。 問題の詳細サービスは、ASP.NET Coreでの問題の詳細の作成をサポートする IProblemDetailsService インターフェイスを実装します。 AddProblemDetails(IServiceCollection) の IServiceCollection 拡張メソッドは、既定の IProblemDetailsService 実装を登録します。 ASP.NET Core アプリでは、 AddProblemDetails が呼び出されたときに、次のミドルウェアによって問題の詳細 HTTP 応答が生成されます。ただし、 Accept 要求 HTTP ヘッダー には、登録済みの IProblemDetailsWriter でサポートされているコンテンツ タイプの 1 つが含まれていません (既定値: application/json )。 ExceptionHandlerMiddleware : カスタム ハンドラーが定義されていない場合に、問題の詳細の応答を生成します。 StatusCodePagesMiddleware : 既定で問題の詳細の応答を生成します。 DeveloperExceptionPageMiddleware : 開発中に Accept 要求 HTTP ヘッダーに text/html が含まれていない場合に、問題の詳細応答を生成します。 Minimal API アプリは、 拡張メソッドを使用することで、 すべての HTTP クライアント エラー応答およびサーバー エラー応答に対して、問題の詳細レスポンスを生成するように構成できます。 次のコードは、問題の詳細を生成するようにアプリを構成します。

AddProblemDetails の使用方法の詳細については、「 問題の詳細 」を参照してください。 IProblemDetailsService フォールバック 次のコードでは、 httpContext.Response.WriteAsync("Fallback: An error occurred.") 実装で IProblemDetailsService を生成できない場合、 ProblemDetails はエラーを返します。 problemDetailsService が ProblemDetails を記述できない場合は、フォールバック コードでエラー メッセージを書き込みます。 たとえば、 Accept 要求ヘッダー が、 DefaultProblemDetailsWriter がサポートしていないメディアの種類を指定するエンドポイントです。 例外ハンドラー ミドルウェア を使用します。 DefaultProblemDetailsWriter では、 Accept 要求ヘッダーで次のメディアの種類がサポートされています。 application/json application/problem+json */* や application/* のようなワイルドカード型 application/xml や text/html などの JSON 以外のメディアの種類はサポート されておらず 、フォールバック動作がトリガーされます。 次の例は、 Status Code Pages middleware を呼び出す点を除き、前の例と似ています。 ASP.NET Coreでは、 を使用した HTTP API の IProblemDetailsService の作成がサポートされています。 次のコードは、すべての HTTP クライアント用の " 本文コンテンツがまだ含まれていない " 問題の詳細応答とサーバー エラー応答を生成するようにアプリを構成します。 入力が無効な場合に BadRequest を返す、前のセクションの API コントローラーについて考えてみましょう。 次のいずれかの条件が適用されると、上記のコードで問題の詳細の応答が生成されます。 無効な入力が指定されています。 URI に一致するエンドポイントがありません。 ハンドルされない例外が発生します。 で問題の詳細をカスタマイズする CustomizeProblemDetails 次のコードは ProblemDetailsOptions を使用して CustomizeProblemDetails を設定します。 ProblemDetailsFactory を実装する MVC は Microsoft.AspNetCore.Mvc.Infrastructure.ProblemDetailsFactory を使用して、 ProblemDetails と ValidationProblemDetails のすべてのインスタンスを生成します。 このファクトリは、次の目的で使用されます。 ControllerBase.Problem と ControllerBase.ValidationProblem 問題の詳細の応答をカスタマイズするには、 ProblemDetailsFactory に Program.cs のカスタム実装を登録します。 ApiBehaviorOptions.ClientErrorMapping を使用する ClientErrorMapping 応答の内容を構成するには、 ProblemDetails プロパティを使用します。 たとえば、 Program.cs の次のコードは、404 応答の Link プロパティを更新します。 コントローラーから最小限の API への移行 コントローラー ベースの API から最小 API に移行する場合: アクション フィルターをエンドポイント フィルターまたはミドルウェアに 置き換える モデルの検証を手動検証またはカスタム バインドに 置き換える 例外フィルターを例外処理ミドルウェアに 置き換える を使用して一貫したエラー応答を実現するために、 AddProblemDetails() コントローラー ベースのエラー処理を使用する場合 必要に応じて、コントローラー ベースの API を検討してください。 複数のコントローラー間での一元的な例外処理 エラー応答の書式設定をきめ細かく制御する フィルターや規則などの MVC 機能との統合 検証エラー、問題の詳細のカスタマイズ、例外フィルターなど、コントローラーベースのエラー処理の詳細については、「 コントローラー 」タブのセクションを参照してください。 Web API コントローラーの場合、モデルの検証が失敗すると、MVC は ValidationProblemDetails 応答の種類で応答します。 MVC は、 InvalidModelStateResponseFactory の結果を使用して、検証エラーのエラー応答を構築します。 次の例では、既定のファクトリを、 Program.cs で XML として応答の書式設定もサポートする実装に置き換えます。 応答の内容は、カスタム例外とアクション フィルターを使用して、コントローラーの外部から変更できます。 HttpResponseException という名前の既知の例外の種類を作成します。 public class HttpResponseException : Exception { public HttpResponseException(int statusCode, object? value = null) => (StatusCode, Value) = (statusCode, value); public int StatusCode { get; } public object? Value { get; } } HttpResponseException という名前の既知の例外の種類を作成します。 HttpResponseExceptionFilter という名前のアクション フィルターを作成します。 public class HttpResponseExceptionFilter : IActionFilter, IOrderedFilter { public int Order => int.MaxValue - 10; public void OnActionExecuting(ActionExecutingContext context) { } public void OnActionExecuted(ActionExecutedContext context) { if (context.Exception is HttpResponseException httpResponseException) { context.Result = new ObjectResult(httpResponseException.Value) { StatusCode = httpResponseException.StatusCode }; context.ExceptionHandled = true; } } } 上記のフィルターは、最大整数値から 10 を引いた Order を指定します。 この Order では、パイプラインの最後に他のフィルターを実行できます。 HttpResponseExceptionFilter という名前のアクション フィルターを作成します。 上記のフィルターは、最大整数値から 10 を引いた Order を指定します。 この Order では、パイプラインの最後に他のフィルターを実行できます。 Program.cs で、アクション フィルターをフィルター コレクションに追加します。 builder.Services.AddControllers(options => { options.Filters.Add<HttpResponseExceptionFilter>(); }); Program.cs で、アクション フィルターをフィルター コレクションに追加します。 自動モデル検証 : コントローラーはモデルの状態を自動的に検証し、検証エラーの 400 Bad Request 応答を返します 例外フィルター : 一元化されたエラー処理にアクション フィルターと例外フィルターを使用する 組み込みの問題の詳細 : 標準化されたエラー応答用に ApiBehaviorOptions を構成する カスタム エラー応答 : InvalidModelStateResponseFactory をオーバーライドして、カスタムの検証エラーの書式を設定する ASP.NET Core Web API で ModelState 検証を使用する方法 サンプル コードを表示またはダウンロードします Hellang.Middleware.ProblemDetails このページはお役に立ちましたか? このトピックについてサポートが必要ですか? このトピックの意図を把握したり、理解を深めたりするために Ask Learn を使ってみませんか? Last updated on 2026-07-21