202 Accepted は、サーバーがリクエストを受け付けたものの、まだ処理を完了しておらず、最後まで完了しない可能性もあることを示します。HTTP には、バックグラウンド処理の結果を後から通知する仕組みがありません。そのため 202 は、あえて結果を約束しない表現になっています。
バッチジョブ、エクスポート、動画のトランスコード、メッセージキューなど、バックグラウンドで実行される処理に使われます。適切な 202 レスポンスは、クライアントがその後どうすればよいかを伝えます。具体的には、状態を確認できる URL（ボディまたは Location ヘッダーで示します）と、ジョブが完了するまでの見込み時間です。見込み時間には Retry-After が使われることもあります。
クライアントは 202 を成功として扱います。たとえば Webhook の送信側は、ほかの 2xx コードと同じく、イベントが受信されたことの確認として 202 を受け入れます。
レスポンス例
HTTP
HTTP/1.1 202 Accepted
Date: Fri, 06 Nov 2026 10:15:32 GMT
Location: https://api.example.com/v1/exports/3f9c
Retry-After: 30
Content-Type: application/json
Content-Length: 31
{"id":"3f9c","status":"queued"}SEO とリダイレクトチェック
検索エンジン向けのページで 202 を使う場面はありません。クローラーは成功として扱いますが、通常はインデックスする内容がありません。アクセス解析のビーコンやトラッキング用のエンドポイントは 202 や 204 を返すことがよくありますが、ページとしてクロールされるものではないため問題ありません。
よくある原因と主な用途
- API が時間のかかるジョブをキューに入れ、状態をポーリングできる URL を返している場合。
- Webhook の受信側がイベントをすぐに受領し、処理は後で行う場合。
- ログやアクセス解析のエンドポイントが、保存の完了を確認せずにデータを受け付けている場合。