「サイトが見られない」と連絡が来たら｜一次確認と調査依頼メモの記入例

「サイトが見られない」と連絡を受けたら、まず対象URL・発生時刻・表示された内容を記録し、別の端末や回線でも同じかを確認します。窓口で原因を決めつけず、確認できた事実をWeb担当へ渡すことが、調査の出発点です。

顧客の販促・採用・ブランド発信を支援する制作会社・広告会社・代理店では、公開後の相談も窓口へ届きます。「全部止まった」のか「一つの画面だけ崩れた」のかで、確認する相手と影響範囲が変わります。復旧を急ぐときほど、更新や設定変更を重ねる前に、現状を残して担当を分けます。

「見られない」を四つの状況に分ける

顧客の言葉を否定せず、「どの画面で、何が起きていますか」と具体化します。次の表は確認を始めるための整理例であり、これだけで原因を確定するものではありません。

接続や証明書の警告があるときは、警告を無視して先へ進んだり、個人情報や管理者情報を入力したりしません。フォームの完了画面が出ても、通知メールの到着まで証明できるわけではありません。再送信を繰り返すと受付が重複する場合があるため、テストの担当と方法を先に決めます。

設定を変えずに確認できること

1. 対象をそろえる：顧客が開いたURLを確認し、トップと問題のページで違いがあるか記録します。推測したURLへ置き換えないようにします。
2. 条件を比べる：許可された範囲で別端末・別ブラウザー・別回線から表示だけを確認します。注文やフォーム送信は、確認のために無断で実行しません。
3. 直前の作業を聞く：原稿更新、プラグイン更新、移行、ドメイン変更などの時刻と担当を残します。変更との前後関係は手掛かりであり、原因の断定ではありません。

MDNのHTTPステータスコードの説明では、応答を成功、転送、クライアントエラー、サーバーエラーなどに分類しています。404や500が表示された場合は番号も記録しますが、番号だけで原因や責任の所在を決めません。200という応答も、画面の内容やフォームの動作全体が正常という保証ではありません。

架空例：Web担当へ渡す調査依頼メモ

以下は架空の採用サイトで表示崩れが起きた想定です。GreenCodingの実績や実際の障害ではなく、情報の渡し方の見本です。分からない項目は「未確認」と書き、回答を待ってから埋めます。

架空の調査依頼メモ
対象：採用サイトの募集要項ページ（実案件では正確なURLを添える）
発生確認：2026年10月8日 9:10
症状：スマートフォンで応募ボタンが説明文に重なる
影響：募集要項1ページ。他のページは未確認
確認環境：iPhoneのSafari。OS・ブラウザーの版は未確認
比較：PCでは重ならない。別回線は未確認
直前作業：8:50に募集要項の原稿を更新
添付：個人情報を隠した画面の写し1点
依頼：表示崩れの原因調査と修正範囲の確認。応募送信テストは未実施

このメモなら、まず表示の再現を調べる案件だと分かります。反対に「サーバー障害だと思います」だけでは、問題の場所や条件が伝わりません。確認時刻と、いつから起きていたかは別に書きます。顧客への途中報告も「確認できたこと」「調査中のこと」「次の報告予定」に分け、確約していない復旧時刻を伝えないようにします。

WordPressの情報は必要な項目だけ共有する

WordPress公式のサイトヘルス画面の案内では、状態のチェックと、WordPress・テーマ・プラグイン・サーバーなどの情報表示を説明しています。管理画面に入れる場合も、権限を持つ担当が必要な版情報や指摘を確認する使い方にとどめます。サイトヘルスの結果だけで原因を確定したり、解決のために本番設定を変更したりするものではありません。

画面の写しやログには氏名、メールアドレス、内部パス、認証用の値などが含まれる場合があります。共有前に伏せ、必要な部分だけを承認された連絡手段で渡します。パスワード、Cookie、認証コードを調査メモへ書かず、サイトヘルスの全情報を公開の場所へ貼らないようにします。

GreenCodingへ相談するときに分けておく範囲

GreenCodingでは、運用中サイトの表示崩れ、フォーム、SSL、移行後の不具合などの原因調査と修正を相談できます。対象URLと上のメモをもとに、Web側で調べる範囲、サーバーや外部サービスの契約担当へ確認すること、修正後の検証を整理します。

調査の相談は、復旧時間の保証や外部サービスの障害そのものを解消する約束ではありません。本番変更は対象と戻し方、担当者の承認をそろえてから行い、変更後は同じURL・条件で読み戻します。顧客窓口と実装担当の役割を分けたい段階から、対応範囲を相談してください。