Azure環境でメンテナンス画面を表示する：緊急時の最適な構成方法

2026年10月21日に公表された、PHPにおける極めて深刻な脆弱性（通称「PHP2Shell」）。
多くのWebサイト管理者が対応に追われていることと存じます。

Azure
App Service

自社内で即座にパッチを当てられない場合や、保守を外部ベンダーに委託している場合、対応完了まで「順番待ち」となってしまうことも珍しくありません。
しかし、被害を防ぐために既存のPHP環境（VMなど）は一刻も早く停止しなければならず、かといってアクセスしてくれたユーザーに「ページが見つかりません」といったエラーをそのまま見せるわけにもいきません。

そこで今回は、Azure環境において安全にVMを停止しつつ、適切なメンテナンス画面を表示するための構成手順を解説します。

静的HTMLを表示すればよいというだけではない
- SEO対策（「503」ステータスコードの返却）
- 独自ドメインとSSL証明書（HTTPS）
選択肢の比較： Static Web Apps か App Service か
App Serviceで構成する具体的な手順

静的HTMLを表示すればよいというだけではない

「とりあえずVMを止めて、どこか別のサーバーに『現在メンテナンス中です』と書いた静的なHTMLを置けばよいのでは？」と考えるかもしれません。
しかし、実稼働しているWebサイトにおいてメンテナンス画面を表示する際には、考慮すべき重要なポイントがいくつかあります。

SEO対策（「503」ステータスコードの返却）

Webサイトの運営において、これが最も重要と言っても過言ではありません。
単に静的HTMLを表示して「200 OK」を返してしまうと、Googleなどの検索エンジンのクローラーが巡回してきた際、「このサイトの全ページが『メンテナンス中』というテキストに書き換わった」と誤認してしまい、これまでに築き上げた検索順位が急落する恐れがあります。

検索エンジンに対して「今は一時的にお休みしているだけで、後で必ず復活します」と正しく伝えるためには、HTTPステータスコード「503 Service Unavailable」を返す必要があります。

独自ドメインとSSL証明書（HTTPS）

現在のWebブラウザは、SSL化されていない（HTTPの）サイトにアクセスすると「保護されていない通信」という強い警告画面を出します。
いくら一時的なメンテナンス画面であっても、ユーザーに不安を与えないよう、これまで通りの独自ドメインを使用し、かつSSL証明書（HTTPS）を維持することは必須条件です。

選択肢の比較： Static Web Apps か App Service か

危険な状態のVMは完全にシャットダウンすることを前提として、Azure内でメンテナンス画面をホスティングする場合、主に2つの選択肢が考えられます。

Azure Static Web Apps (SWA)
Azure App Service

結論から申し上げますと、今回はAzure App Serviceの利用を推奨します。

Static Web Appsは無料で独自ドメインとSSLが利用できる素晴らしいサービスですが、仕様上、すべてのアクセスに対して意図的に「503エラー」を返すことができません（302リダイレクト等は可能ですが、SEOの観点では503に劣ります）。
一方、App Serviceであれば、設定ファイルを少し記述するだけで確実かつ完璧に503エラーとメンテナンス画面を返すことができます。

Microsoftのサービスなので先にCopilotに確認したのですが、SWAは案内されませんでした。
結果的には使わないからよいのですが、釈然としません。。

App Serviceで構成する具体的な手順

App Serviceを利用して、すべてのアクセスに「503」を返しつつメンテナンス画面（HTML）を表示させる手順を解説します。
なお、独自ドメインとSSLを利用するため、無料プランではなくBasicプラン（B1）以上を使用します。
数日〜1週間の利用であれば、数千円程度のコストで収まります。

ビジネス用途であれば、SEOを優先することになるはずです。

1. App Serviceの作成

Azureポータルから「App Service」を新規作成します。

Webアプリの作成を選択
公開の項目は「コード」を選択
ランタイムスタックは「ASP.NET V4.8」を選択
オペレーティングシステムは「Windows」を選択します。（IISの web.config を使って簡単に503設定を行うためです）。
価格プランは「Basic B1」を選択してリソースを作成します。

今回はPHPを使わず、静的HTMLとWindows(IIS)の設定ファイルのみを使用するため、ランタイム自体はどれを選んでも正常に動作しますが、標準的な.NET系を選んでおくのが無難です。

2. 独自ドメインとSSL証明書の設定

作成したApp Serviceのメニューから「カスタムドメイン」を選択し、既存のドメインを追加します。
画面の指示に従い、DNS側（Azure DNS等）に所有権確認のレコードを追加します。
「TLS/SSL 設定」またはカスタムドメインの画面から、「App Service マネージド証明書」を無料で発行し、ドメインにバインドします。

DNSを手動で変更できる場合には、すぐにでもやってしまえます。
浸透に24時間かかるとか言われますが、そこまで時間はいらないでしょう。
DNS変更も外注している場合は、これがまた待ちになるわけです。。

3. 設定ファイル（web.config）とHTMLの準備

ローカルPCに以下の2つのファイルを作成します。

maintenance.html
ユーザーに表示する案内文です。デザインは自由ですが、再開予定の目処などを記載すると親切です。
web.config
すべてのアクセスを503エラーにし、maintenance.html を表示するための設定ファイルです。以下のコードをそのままコピーして作成してください。XMLです。文字コードもご注意ください。

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="MaintenanceMode" stopProcessing="true">
          <match url=".*" />
          <action type="CustomResponse" statusCode="503" statusReason="Service Unavailable" statusDescription="Site is currently under maintenance." />
        </rule>
      </rules>
    </rewrite>
    <httpErrors errorMode="Custom" existingResponse="Replace">
      <remove statusCode="503" subStatusCode="-1" />
      <error statusCode="503" path="maintenance.html" responseMode="File" />
    </httpErrors>
  </system.webServer>
</configuration>

4. ファイルのデプロイとDNSの切り替え

AzureポータルのApp Serviceメニューから「高度なツール (Kudu)」を開き、「Go」（使用するだったか）をクリックします。
上部メニューの「Debug console」から「CMD」を選び、site\wwwroot フォルダを開きます。
デフォルトの不要なファイル（hostingstart.html など）を削除し、先ほど作成した maintenance.html と web.config をドラッグ＆ドロップでアップロードします。
最後に、DNSのAレコード（またはCNAME）の向き先を、旧VMのIPアドレスから、今回のApp ServiceのIPアドレスへ変更します。

DNSの浸透が完了すれば、安全に保護されたHTTPS環境で、SEOへの悪影響を防ぐ503ステータスとともにメンテナンス画面が表示されるようになります。

脆弱性対応は時間との勝負ですが、一時的な措置であってもユーザー体験とSEOを守る構成を取ることが大切です。
復旧までの間、この記事が少しでもお役に立てば幸いです。

Azure