503エラーの原因と対処法｜Service Unavailableが出たときに最初に確認すること
「503 Service Unavailable」——サイトにアクセスしたときや、自分のサイトが返してしまったときに見るエラーです。
503は「サーバーが一時的に処理できない」という意味で、404（見つからない）や500（内部エラー）とは性格が違います。多くの場合、時間が経てば直りますが、原因を放置すると繰り返します。
この記事では、立場別の対処（見ている側／運営している側）と、原因の切り分け方を整理します。
まず結論：立場によって対処が違う
| 立場 | やること |
|---|---|
| 訪問者として見た | 数分〜数十分待って再読み込み。自分側で直せることはほぼない |
| 自分のサイトが返している | 原因の切り分けが必要。下記を順に確認 |
| 開発中に出た | 書き込み処理を止めてから原因を調べる |
503とは何を意味するのか
503は5xx（サーバー側のエラー）に分類されます。「リクエストは届いたが、サーバーが今は応答できない」という状態です。
似たコードとの違いを押さえておくと、切り分けが速くなります。
- 500 Internal Server Error：プログラムの中でエラーが起きた。コードの問題である可能性が高い
- 502 Bad Gateway：手前のサーバー（プロキシやロードバランサ）が、奥のサーバーから正しい応答を受け取れなかった
- 503 Service Unavailable：サーバーが一時的に処理できない。過負荷やメンテナンスが典型
- 504 Gateway Timeout：手前のサーバーが、奥のサーバーからの応答を待ちきれなかった
502・503・504は「奥で何かが起きている」点が共通しています。500だけは性格が違い、アプリケーションのコードを疑う場面です。ステータスコード全体はHTTPステータスコード一覧にまとめています。
訪問者として503を見た場合
基本的に待つ以外にできることはありません。それでも次を試す価値はあります。
- 数分待って再読み込み：アクセス集中なら、これで解決することが多くなります
- 別の端末・回線で試す：自分の環境の問題かを切り分けられます
- サービスの障害情報を見る：公式のSNSや障害情報ページで告知されていることがあります
何度も連打で再読み込みしないでください。過負荷が原因の場合、状況を悪化させます。
自分のサイトが503を返している場合
ここからが本題です。原因は大きく5つに分かれます。上から順に確認してください。
1. アクセス集中（最も多い）
テレビ放映、SNSでの拡散、セール開始——同時アクセスがサーバーの処理能力を超えると503になります。
確認方法：アクセスログを見て、503が出た時間帯のリクエスト数が普段より多いかを確認します。
対処：一時的ならプランの増強、恒久的にはキャッシュの導入やCDNの利用が効きます。Cloudflareのようなサービスは無料枠から始められます。
2. メンテナンスモードのまま
見落とされがちな原因です。WordPressでは、更新中に自動でメンテナンスモードに入り、途中で失敗するとそのまま解除されないことがあります。
確認方法：サイトのルートに .maintenance というファイルが残っていないか確認します。
対処：そのファイルを削除すれば復旧します。
3. データベースの接続数が上限に達している
切り分けが難しく、見落とされやすい原因です。データベースへの同時接続が上限を超えると、新しい接続が拒否されて503になります。
特徴的な症状があります。
- 一部のリクエストだけが失敗する：全部が落ちるわけではなく、成功と失敗が混ざる
- 失敗が異常に速い：接続を待たずに拒否されるため、エラーが0.2秒程度で返る
- 成功したリクエストは遅い：順番待ちが発生し、数秒かかる
「エラーは速く返り、成功は遅い」という組み合わせを見たら、接続数を疑ってください。これは負荷そのものより、接続の使い方に問題があるサインです。
対処：バッチ処理やAPIの連続実行を止めます。処理の間隔を空け、同時に複数の書き込み処理を走らせないようにしてください。
4. プロセス数・メモリの上限
レンタルサーバーには、同時に動かせるプロセス数やメモリの上限が設定されています。超えると503が返ります。
確認方法：サーバーの管理画面でリソースの使用状況を確認します。多くのレンタルサーバーには制限値の表示があります。
対処：重いプラグインの停止、不要なcron処理の整理、プランの見直し。
5. プログラムやプラグインの不具合
特定の更新の直後に発生した場合、これを疑います。
確認方法：エラーログを見ます。直前に何を変更したかを思い出してください。
対処：更新したプラグインを無効化する、変更を戻す。
開発・運用中に503を見たときの鉄則
実務で最も重要な点を書きます。
書き込み処理の503を「一時的なもの」と判断して続行しないでください。
よくある誤判断があります。APIへの書き込みが503を返したが、ブラウザでサイトを開くと正常に表示される——このとき「ページは見えているから大丈夫」と考えて処理を続けてしまうケースです。
これは危険です。読み取りが生きていても、書き込み側の接続やリソースが枯渇している可能性があります。そのまま続けると、サイト全体が落ちます。
鉄則は次の3つです。
- 書き込みで503が1回でも出たら、即座に停止する
- 読み取りの200は、安全である証拠にならない
- 復旧を確認してから再開する（成功率が戻っているかを実際に測る）
一括処理を書く場合は、連続エラーが数回続いたら自動で中断する仕組み（サーキットブレーカー）を入れておくと、被害を最小限にできます。
原因を切り分ける順序
- いつから出ているか：直前に何を変更したか。更新・デプロイ・設定変更
- 全部か、一部か：すべてのページが503か、特定のページだけか
- 時間帯に偏りがあるか：特定の時間に集中しているならアクセス集中やcron処理
- エラーログに何が出ているか：サーバーのエラーログが最も確実な情報源です
- リソースの使用状況：CPU、メモリ、プロセス数、データベース接続数
Webの仕組みそのものはAPIとは？Web通信の仕組み、サーバーやネットワークの全体像はインフラ・ネットワークの基礎で扱っています。
503が続く場合の恒久対策
- キャッシュの導入：同じ内容を毎回生成しないようにする。最も効果が大きい対策です
- CDNの利用：画像やCSSなどを手前で配信し、サーバーの負荷を下げます
- 処理の非同期化：重い処理をリクエストの中で完結させず、後回しにする
- プランの見直し：根本的にリソースが足りない場合
- 監視の導入：落ちてから気づくのでは遅いため、死活監視を入れる
SEOへの影響
短時間の503であれば、検索順位への影響は限定的です。Googleは503を「一時的な状態」として扱うためです。
ただし長期間続くと、インデックスから削除される可能性があります。計画的なメンテナンスであれば、Retry-After ヘッダーで復旧予定を伝えるのが適切な方法です。
よくある質問
503と500はどちらが深刻ですか
性格が違います。500はコードの不具合で、放置しても直りません。503は一時的な過負荷やメンテナンスで、待てば直ることが多くなります。ただし503が頻発する場合は、構造的な問題があるサインです。
レンタルサーバーで503が出ます
共有サーバーでは、同居している他のサイトの影響を受けることもあります。まず自分のサイトのリソース使用量を確認し、問題がなければサーバー会社に問い合わせてください。
WordPressで503が出ました
更新直後ならメンテナンスモードの残骸（.maintenance ファイル）、プラグイン追加後ならそのプラグインの不具合、それ以外ならリソース不足を順に疑ってください。
自分でプログラムを書いていて503が出ます
リクエストの間隔が短すぎる可能性が高くなります。APIを連続で叩く処理では、意識的に待機を入れてください。相手のサーバーに負荷をかけている状態です。
Retry-Afterとは何ですか
503と一緒に返すヘッダーで、「いつ再試行すればよいか」を伝えるものです。計画メンテナンスではこれを設定すると、クローラーや利用者に親切な挙動になります。
まとめ
503は「サーバーが一時的に処理できない」状態です。訪問者としてできるのは待つことだけですが、運営側なら原因の切り分けができます。
確認の順序は、アクセス集中 → メンテナンスモードの残骸 → データベースの接続数 → プロセス・メモリの上限 → プログラムの不具合。エラーログが最も確実な情報源です。
そして最も重要なのは、書き込み処理で503を見たら即座に止めることです。ページが表示されていても安全とは限りません。読み取りの200は、書き込み側が健全である証拠にはなりません。
