田尻町でホームページが表示されないときの初動

自社のホームページを開いたら真っ白になった、警告が出た、違うサイトへ移動した。こうしたときは、慌てて設定を変更する前に「誰の端末で、どのURLを、いつ開き、何が表示されたか」を残します。同じ「表示されない」でも、自分のスマートフォンだけの問題と、すべての利用者がサイトへ到達できない問題では、連絡先も復旧方法も違います。

最初の目標は原因を断定することではありません。影響範囲を確認し、証拠を残し、ドメイン、DNS、SSL証明書、サーバー、CMSのどこを管理する相手へ連絡するかを決めることです。仕組みが分からない担当者でも、変更せずに確認できる範囲があります。

この記事では、田尻町の事業者がホームページ表示障害に気づいた直後の行動を、確認、記録、連絡、復旧、再発防止の順で整理します。改ざんや情報漏えいが疑われる場合は、通常の不具合とは分け、社内責任者、保守会社、必要に応じて公的な相談窓口や専門家へ早めに相談してください。

最初の10分で行うこと

まずサイトを何度も再読み込みしたり、管理画面で更新や削除を始めたりせず、次を記録します。

開こうとした正確なURL
発生を確認した日時
利用した端末、ブラウザー、回線
画面全体のスクリーンショット
表示されたエラー文と番号
トップページだけか、他のページも同じか
管理画面、メール、予約等への影響
直前に行った更新、契約変更、DNS変更等

エラー文は要約せず、そのまま残します。「404」「500」「502」「503」「接続がタイムアウトしました」「この接続ではプライバシーが保護されません」等は、原因候補を分ける手掛かりになります。ただし、番号だけで原因を断定しません。途中にCDNやセキュリティサービスがあると、同じ番号でも問題箇所が異なることがあります。

顧客や社員から連絡を受けた場合は、相手の端末で設定変更を頼む前に、日時、URL、スクリーンショットを受け取ります。個人情報やパスワードが写っている場合は、安全な社内手段で共有し、公開チャットやSNSへ貼りません。

影響範囲を変更せずに確認する

一台だけで表示されない場合は、端末、ブラウザー、保存済みデータ、社内回線等の問題も考えられます。複数の条件で確認すると、全体障害か局所的な問題かを分けられます。

確認	結果から考えられる範囲	注意
同じ端末で別ブラウザー	ブラウザー固有か	拡張機能を一度に削除しない
スマホのWi-Fiを切り携帯回線	社内・店舗回線固有か	通信量と社内ルールに注意
別の端末	一台だけか複数か	古い端末だけの証明書問題もある
トップと下層ページ	全体か一部ページか	URLを正確に記録する
管理画面	公開側と管理側の差	不明な場合はログインを連打しない
会社メール	DNS変更の影響範囲	メール設定を先に変更しない

同僚や信頼できる関係者に、別の場所・別回線から開いてもらう方法もあります。検索結果の説明文やSNSのプレビューが見えることは、現在のページが正常という証拠にはなりません。保存済み情報が表示されている場合があります。実際のURLへアクセスした結果を確認します。

一方、身に覚えのない転送、知らない広告、外国語のページ、管理者アカウントの追加、ファイルの改変、セキュリティ警告が見つかった場合は、通常の表示確認を続けず、後述するインシデント対応へ切り替えます。

「表示されない」を構成要素ごとに分ける

ブラウザーでURLを入力してページが表示されるまでには、複数のサービスが関わります。

ドメイン名の契約が有効である
DNSがドメイン名と接続先を対応付ける
ネットワーク・CDN等を経由してサーバーへ到達する
SSL証明書により安全な接続を確認する
WebサーバーとCMSがページを生成する
ブラウザーがHTML、画像、CSS、JavaScript等を表示する

JPRSは、ドメイン名とIPアドレス等を対応付ける仕組みをDNSと説明しています。ドメインの契約先、DNSの管理先、サーバー会社、CMS保守会社が別々の場合もあります。そのため、制作会社へ「直してください」と連絡するだけでは、変更権限がなく進められないことがあります。

見え方・エラー	主な確認先の候補	最初に伝えること
ドメインが見つからない・名前解決できない	ドメイン、DNS	対象URL、期限、NS・A・CNAME変更の有無
接続タイムアウト・リセット	サーバー、ネットワーク、CDN	発生範囲、時間、回線差、監視結果
安全な接続の警告	SSL証明書、サーバー、端末	警告全文、端末差、証明書更新の有無
404 Not Found	ページURL、CMS、転送	消えたURL、移動・公開変更の有無
500・502・503等	サーバー、CMS、外部連携	エラー番号、発生直前の変更、全体・一部
真っ白・一部だけ欠ける	CMS、テーマ、JavaScript、画像	該当ページ、ブラウザー、開発者ログの有無
別サイト・知らない広告	DNS、サーバー、改ざん	画面、転送先、権限変更、管理者通知

Googleの技術資料でも、DNSエラー、ネットワークタイムアウト、接続リセット、5xx等は分けて確認し、A・CNAME・NS等のDNSレコード、ファイアウォール、サーバーやCDNの状況を確認するよう案内されています。これらの変更はメールや他サービスにも影響するため、仕組みが分からない状態で値を書き換えません。

先にやってはいけないこと

障害中に複数人が別々の変更をすると、原因と影響が追えなくなります。次の操作は、担当と戻し方を決めるまで待ちます。

DNSの値を検索結果の例へ置き換える
サーバー、CMS、プラグインを一斉に更新する
バックアップを確認せず復元する
エラーログやアクセスログを削除する
問題のファイルを上書き・削除する
共通パスワードをチャットやメールへ貼る
何度も管理者ログインを試す
ドメインやサーバーを新規契約して同じ名前を作り直す

キャッシュ削除は一台だけの表示確認では役立つ場合がありますが、全社の端末、CDN、CMS、サーバーのキャッシュを同時に消すと、比較材料を失います。何を、誰が、いつ削除したかを記録し、戻せない変更は避けます。

バックアップも「ある」だけでは足りません。取得日時、対象、復元方法、現在のデータとの差、マルウェア混入の可能性を確認します。予約や注文等のデータが更新されるサイトでは、古いバックアップへ戻すと障害発生後の受付が失われる可能性があります。

復旧依頼に必要な情報を一つにまとめる

管理会社へ連絡するときは、「表示されないので急いで」だけでなく、次の情報を一件の記録へまとめます。

会社名、連絡責任者、連絡可能な時間
対象ドメインと正確なURL
発見日時と、最後に正常だった日時
画面のスクリーンショットとエラー全文
影響する端末、回線、地域、ページ
管理画面・メール・予約・決済等の影響
直前の公開、更新、契約、DNS、サーバー作業
ドメイン、DNS、サーバー、CMS、CDNの契約先
緊急度と、優先して復旧したい機能
変更を止めた時刻と、それまでに行った操作

管理画面のパスワードや認証コードを本文へ書かず、相手を確認したうえで承認済みの方法により共有します。委託先へ一時的な権限を渡す場合は、作業対象と期限を限定し、完了後に停止します。

連絡先が分からなければ、契約書、請求書、カード明細、更新通知メール、社内パスワード管理、過去の制作資料を探します。ドメイン、サーバー、保守の請求元が同じとは限りません。契約更新の通知を受けるメールが退職者個人のアドレスになっていないかも確認します。

田尻町の来訪・予約型事業は代替案内を優先する

田尻町の公式交通案内では、吉見ノ里駅に加え、目的地によりりんくうタウン駅、関西空港駅、バス等が案内されています。また、関西国際空港の中央部も田尻町域に含まれます。来訪者、観光客、空港関連の利用者が見るサイトでは、表示障害により所在地、交通、営業日時、予約変更の案内が失われると、現地で迷う可能性があります。

障害中は、別の公式窓口で次を案内します。

営業・受付を継続しているか
予約済みの内容は有効か
変更・キャンセルの連絡先
所在地、入口、最寄り駅・停留所
当日対応できる時間
復旧状況を更新する次の時刻

代替案内は、会社がすでに管理しているSNS、Googleビジネスプロフィール、予約サービス、電話音声等から、実際に更新できるものを選びます。新しい非公式アカウントを慌てて作らず、なりすましと区別できる既存の窓口を使います。利用者の個人情報や障害の技術詳細を公開せず、営業上必要な事実だけを伝えます。

改ざん・不正アクセスが疑われる場合は別の手順にする

表示障害の原因が単なる設定ミスとは限りません。次があれば、セキュリティインシデントとして扱います。

身に覚えのないページ、広告、転送がある
管理者、メール転送、DNSレコードが勝手に増えている
不審なファイルや大量の送信履歴がある
顧客・従業員の情報が外部へ出た可能性がある
パスワードや秘密鍵を誤って公開した
セキュリティ会社、サーバー会社、第三者から警告が来た

この場合、復旧を急ぐために証拠を消すと、影響範囲を調べにくくなります。社内責任者と保守・セキュリティ担当へ連絡し、ログ、ファイル、通知、時刻、変更履歴を保全します。必要に応じてネットワークからの隔離や一時停止を行いますが、独断で実行せず、影響と手順を確認します。

IPAは、企業・組織のウェブサイト改ざん等について、初動や再発防止を相談できる窓口を案内しています。個人情報漏えい等が疑われる場合は、契約先、保険、法務、公的機関への報告要否を専門家と確認します。この記事だけで法的判断や侵害調査を完結させないでください。

復旧作業は変更・確認・戻し方を記録する

復旧担当者は、原因の仮説、変更内容、作業時刻、結果、戻し方を一つずつ記録します。複数箇所を同時に変えると、何が効いたか分かりません。

段階	作業	完了条件
影響抑制	公開停止、代替案内、変更停止等	被害や誤案内が広がらない
証拠保全	ログ、画面、設定、ファイル、時刻を保存	調査に必要な情報が残る
原因特定	ドメイン、DNS、SSL、サーバー、CMSを確認	問題箇所と変更理由が説明できる
修正	最小限の変更または安全な復元	対象機能が戻り、他機能を壊さない
検証	複数端末・回線、主要ページ、フォーム等	利用者の主要行動が完了する
監視	エラー、負荷、ログ、通知を一定期間確認	再発や残存異常がない

「トップページが開いた」だけで復旧完了にしません。画像・CSSが欠けていないか、問い合わせ・予約・購入・応募が完了するか、管理者通知と自動返信が届くか、メールが送受信できるかを確認します。DNSや証明書の変更後は、端末や回線によって見え方が異なる時間があり得るため、確認した条件と時刻を残します。

復旧後に検索と外部サービスを確認する

表示障害が長引くと、検索エンジンのクロールや外部サービスの連携にも影響することがあります。Googleは、DNS・ネットワークエラーや5xx等がクロールに影響すると説明しています。ただし、障害時間だけから検索順位や復帰時期を断定することはできません。

復旧後は次を確認します。

主要URLが意図したHTTP応答を返す
存在しないページは適切な404になっている
移動したページは正しい転送先になっている
検索を止める設定や認証が残っていない
robots.txt、サイトマップ、canonical等が意図どおりである
Search Console等でホスト可用性・クロール状況を確認する
広告、予約、決済、地図、SNS等のリンク先が戻っている

エラーページの見た目を通常ページに似せても、HTTP応答が誤っていれば検索側と利用者側の確認がずれます。Google Search Centralは、存在しない内容なのに200を返すsoft 404や、移動時の不適切な転送を区別しています。復旧担当者へ「見た目」だけでなく応答と設定の確認を依頼します。