.webp)
レンタルサーバーやWordPressの障害を問い合わせるときは、 契約を特定できるID、対象URL、発生日時、症状、再現手順、直前の変更、確認済み項目 を一通にまとめます。パスワードや認証コードは送らず、エラー文は省略せずに添えるのが基本です。
この記事では、問い合わせ画面へそのまま貼って使えるテンプレートと、500エラー・メール障害など症状別の書き換え例を用意しました。読み終えると、サポートが追加質問を繰り返さず調査へ入りやすい問い合わせを、自分で安全に作れます。
問い合わせ前に集める8項目
文章を考える前に、次の8項目をメモします。推測ではなく、いま確認できる事実を記録してください。分からない箇所は空欄にせず「未確認」と書くと、サポート側も確認の必要性を判断できます。
- 契約・サービスID： 会員IDやサーバーID。パスワードは書かない。
- 対象： ドメイン名だけでなく、症状が出るページの完全なURL。
- 発生日時： 年月日と時刻を分単位で。継続中か、断続的かも書く。
- 見えている症状： 白画面、500、接続タイムアウトなど。表示された文は原文のまま。
- 影響範囲： サイト全体、1ページ、管理画面、メール、自分の端末だけ、など。
- 再現手順： どの画面で何を押すと発生するか。
- 直前の変更： 更新、設定変更、DNS変更、プラグイン追加など。何もしていなければその旨。
- 確認済み項目： 試した操作と、その結果。単に「全部試した」と書かない。
成功状態： 担当者が一読して契約・対象・時刻・症状を特定でき、「まずURLと発生時刻を教えてください」という基本確認を挟まず、次の調査や確認手順を返せる状態です。
なぜ「直りません」だけでは調査が進まないのか
同じ「表示されない」でも、DNSが違う場所を向いている、PHPが停止した、特定ページのコードだけ失敗した、閲覧者側の通信が切れた、といった複数の原因があります。サポートは契約サーバーの記録を調べられますが、どの時刻・どのURLの記録を見るべきかまでは利用者から伝えなければ絞れません。
特に時刻は重要です。「今日の午後」では範囲が広すぎます。画面を再読み込みして症状を再現できたなら、その瞬間の時刻を分単位で記録します。再現できない場合は、最後に正常だった時刻と最初に異常へ気づいた時刻の両方を書きましょう。
発生時刻って「さっき」では足りないんだね。分単位までメモするなんて大げさだと思っていたけど、ログを探す目印になるなら納得できたよ。
そこに気づけたのは大きいね。サーバーには同じ時間帯にたくさんの記録が残るから、「7月31日14時26分ごろ」のような情報が調査の入口になるんだ。
エラー全文も、英語だから恥ずかしくて隠したくなっていたの。でも意味を自分で説明できなくても、そのまま写せば役に立つなら少しほっとしたよ。
読めなくても平気だよ。勝手に言い換えず、画面の文をそのまま添えるのがいちばん親切なんだ。次は、その情報を問い合わせ文の形に並べてみよう。
そのまま使える問い合わせテンプレート
角括弧の中だけ自分の情報へ置き換えます。該当しない項目は削除せず「該当なし」とすると、書き忘れとの区別がつきます。
件名： ［対象ドメイン］で［症状］が発生しています
契約・サーバーID： ［管理画面で確認したID］
対象URL： ［https://から始まるURL］
発生日時： ［年/月/日 時:分］ごろから［継続中／断続的／現在は復旧］
症状： ［利用者から見える状態］
エラー全文： ［画面の文を省略せず転記］
影響範囲： ［全ページ／特定ページ／管理画面／メール／未確認］
再現手順： 1.［開く画面］ 2.［行う操作］ 3.［起きる結果］
最後に正常だった日時： ［年/月/日 時:分／不明］
直前に行った変更： ［具体的な変更／変更していない］
確認済み： ［確認した場所・操作］→［表示された結果］
利用環境： ［端末・OS・ブラウザ。閲覧時の問題なら記載］
お願いしたいこと： サーバー側の記録に異常があるか、次に確認すべき項目をご案内ください。
良い書き方と伝わりにくい書き方
| 伝わりにくい | 調査しやすい |
|---|---|
| さっきから開きません | 2026年7月31日14時26分から、対象URLでHTTP 500が継続しています |
| 何もしていません | 直前24時間に更新・設定変更はしていません |
| いろいろ試しました | 別ブラウザでも再現し、管理画面は表示できます |
| エラーが出ます | 画面には「Internal Server Error」と全文表示されます |
症状別に追加する情報
500・503エラー
画面のステータス、発生URL、発生時刻に加え、サーバーパネルのエラーログで同じ時刻の記録を確認します。エックスサーバーでは「サーバーパネル → エラーログ → 表示／ダウンロード」からドメイン単位のログを確認できます。リソース制限、PHPの記述、必要ファイル、PHPバージョン、Cronの頻度などが原因候補になるため、直前に変更した項目も添えます。
メールを送受信できない
送信か受信かを分け、FROM、TO、発生時刻を分単位で書きます。エラーメールが返った場合は、件名だけでなく本文全体をコピーしてください。ただしメールアドレスを公開掲示板へ載せる場合は伏せ字にします。サーバー会社の認証済み問い合わせフォームでは、フォームの案内に従います。
特定ページ・管理画面だけ開かない
トップページが開くか、管理画面が開くか、ログイン前後のどちらで起きるかを分けます。「投稿一覧は開くが、特定の記事編集だけ500になる」のように、正常な範囲も書くと境界が分かります。プラグイン名やテーマ名は、管理画面で確認できる正式名とバージョンを記載します。
DNS・SSL変更後に開かない
変更したレコードの種類、変更日時、対象ホスト名、変更前後の値を記載します。秘密情報を含まない範囲で管理画面の表示を添えます。「反映待ちだと思う」という推測だけではなく、どの端末・回線で何が表示されるかを書きましょう。
ログと画像で伏せる情報・残す情報
| 情報 | 扱い | 理由 |
|---|---|---|
| ログインパスワード、ワンタイムコード | 絶対に送らない | 本人確認にも調査にも不要で、乗っ取りにつながる |
| 秘密鍵、APIトークン、DBパスワード | 伏せる | 第三者に利用される危険がある |
| カード番号や本人確認書類 | 通常の問い合わせ本文へ貼らない | 指定された安全な提出経路だけを使う |
| 対象URL、正確な時刻、エラー全文 | 残す | ログと症状を結び付ける手掛かりになる |
| ログの時刻周辺 | 必要範囲を残す | 前後関係を保ちながら不要な情報を減らせる |
| 公開掲示板のドメイン・メール | 必要に応じ伏せる | 投稿が一般公開されるため |
伏せ字は黒塗りだけで終わらせず、「［APIトークンを伏せました］」と種類を残します。画像の上に半透明の線を重ねただけでは元情報を取り出せる場合があるため、画像を書き出した後に伏せられていることを見直してください。
エラーログを開いたら、長い行の中にフォルダー名やメールアドレスみたいなものが出てきたの。全部貼ったら早そうだけど、見せてはいけない情報まで混ざりそうで手が止まっちゃった。
その慎重さで合っているよ。発生時刻の前後数十行とエラーの全文は残し、パスワード、秘密鍵、APIトークン、個人情報は伏せよう。伏せた場所は「［メールアドレスを伏せました］」のように印を付けると文脈も伝わるよ。
ログを丸ごと送るのではなく、時刻の近くを選ぶんだね。もし違う部分を選んでしまっても、元のログは消さずに残しておけば追加で聞かれた時に戻れるかな。
それが安全だね。元ファイルは編集せず保存し、送信用のコピーだけを伏せ字にしよう。判断できないときは、まず画面のエラー文と正確な時刻だけ送り、必要なログ範囲をサポートに聞けばいいよ。
問い合わせ窓口の選び方
- 障害情報・診断ページ： 最初に確認。同じ障害が掲載されていれば、個別問い合わせより復旧情報を追う。
- チャット： 見るべき管理画面や適切な窓口を短時間で尋ねたいとき。
- メール・チケット： 長い再現手順、ログ、画像、過去の経緯を残したいとき。技術障害は特に向く。
- 電話： 契約や本人確認など、その場で案内を受けたいとき。技術情報は受付番号とともに文面でも残す。
エックスサーバー公式は、問い合わせ前にWebサイトトラブル診断でURLやドメインを調べ、その結果を添えると案内が正確になりやすいと案内しています。契約者はXServerアカウントIDも手元に用意します。ただし、IDとパスワードは別物です。IDは指定欄へ、パスワードは送らないでください。
サポートが調べられる範囲を理解する
サーバー会社は、サーバー設備、契約、管理ツール、提供機能、サーバー側ログなどを確認できます。一方、利用者が追加したテーマ、プラグイン、独自PHP、外部サービスの仕様まですべて修正できるとは限りません。
だからこそ「サーバー障害です」と断定するのではなく、「この時刻にこのURLでこの症状が出ました。サーバー側の記録に異常があるか、次の確認箇所を教えてください」と依頼します。担当範囲外でも、境界を示す情報が返れば次の相談先を決められます。
送信後にしてはいけないこと
返信を待つ間に設定を次々と変えると、問い合わせ時と調査時で状態が変わります。緊急の安全措置を除き、変更は一度止めましょう。どうしても変更する場合は、変更日時・項目・結果を追記します。
- 受付番号、送信日時、問い合わせ本文を保存する
- 元のログや画像を編集せず保管する
- 同じ内容を複数窓口へ連投しない
- 追加質問には、質問番号ごとに回答する
- 復旧した場合も、復旧時刻と行った操作を返信する
サポート体制でサーバーを比較するなら
いまのサーバーでログを確認でき、問い合わせ履歴が残り、必要な案内を受けられるなら、障害が一度起きただけで移転する必要はありません。一方、ログへ到達できない、問い合わせ範囲が分かりにくい、契約管理者が不明で窓口を使えない状態が続くなら、次回更新前に管理画面とサポート体制を比較する意味があります。
エックスサーバー
向いている人： 障害時にサーバーパネルのログを確認し、問い合わせ履歴も残したい人
利点： エラーログの表示・ダウンロード手順が公式マニュアルで明示され、メール・チャット・電話の窓口を使い分けられる。
注意点： プラグインやテーマなど利用者側のコードは、原因の切り分け情報を自分で添える必要がある。
料金： 料金・キャンペーンは申込前に公式ページで最新条件を確認してください。
ConoHa WING
向いている人： 契約・サーバー・WordPressの情報を一つの管理画面で確認したい人
利点： 問い合わせ前に契約情報と対象サイトを整理しやすく、複数サイト運営でも対象を伝えやすい。
注意点： 問い合わせ可能な時間や対象範囲は窓口ごとに異なるため、公式の案内を確認する。
料金： 料金・特典は契約期間などで変わるため、公式ページで最新条件を確認してください。
ロリポップ！
向いている人： 初めてのサーバーで、管理画面の案内を見ながら問い合わせを進めたい人
利点： 初心者向けの情報が多く、状況を整理してから窓口へ伝える流れを作りやすい。
注意点： 契約プランによって使える機能やサポート条件が違うため、現在のプランを先に確認する。
料金： 料金・キャンペーンは変更されるため、公式ページで最新条件を確認してください。
広告・PRを含みます。料金、特典、サポート条件は各公式ページで最新情報をご確認ください。
公式情報で確認する
- エックスサーバー：サポートへのお問い合わせ
- エックスサーバー：エラーログ
- エックスサーバー：500 Internal Server Error
- WordPress.org：サポートフォーラムガイドライン
よくある質問
画面のスクリーンショットだけでもよいですか？
画像だけでは検索やコピーが難しいため、エラー全文と発生時刻を本文にも書きます。画像は画面全体とURL欄が分かる補助資料として添え、個人情報や開いている別タブが写っていないか確認してください。
原因を推測して書いた方がよいですか？
推測は「可能性として考えたこと」と明記し、事実と分けます。「プラグイン更新直後に発生した」は事実ですが、「そのプラグインが原因」は確認前なら断定しません。
急いでいるので複数回送ってもよいですか？
同じ内容の連投は履歴を分散させることがあります。受付番号へ追記できるなら、発生時刻や新しい結果をまとめて同じ問い合わせへ追加します。
最初は「助けてください」しか書けない気がしていたけど、今なら見たことを順番に伝えられそう。まだログを選ぶところは少し緊張するから、秘密の情報がないか送信前にもう一度見直したいな。
そこまで考えられたら十分だよ。分からないことを無理に断定せず、確認した事実と未確認のことを分けられるのが、いちばん良い問い合わせなんだ。
返事が来るまで慌てて設定を変え続けないことも覚えておくね。受付番号と送った時刻を残して、追加で聞かれた時に同じ状況を説明できるようにしてみる。
うん、それで大丈夫だよ。契約・URL・時刻・症状・再現手順がそろっていれば、サポートとの一往復目から具体的な調査に進みやすくなるからね。
まとめ：事実をそろえると一往復目から調査が進む
良い問い合わせは、難しい専門用語を書く文章ではありません。契約・対象URL・正確な発生時刻・症状・再現手順・直前の変更・確認結果を、推測と分けて並べた文章です。秘密情報は送らず、分からないことは「未確認」と書けば構いません。
まず上のテンプレートをコピーし、8項目を埋めてから送信してください。サポートが次の確認へすぐ進めることが、最短の復旧につながります。