「原因不明」で終わった復旧から学んだ、事前にすり合わせるべき3つのゴール
「直りました」とお伝えしたのに、依頼された方の期待には届いていなかった。過去にいただいた星5未満の評価を読み返すと、原因は技術ではなく、最初のすり合わせにありました。復旧をどこまでやれば終わりなのかを、先に言葉にする話をします。
WordPressの復旧を依頼するとき、「直った」という言葉が、依頼する側と作業する側で違う意味になっていることがあります。
画面が元どおり表示されれば直ったと考える方もいれば、原因が分かって再発しない状態になって初めて直ったと考える方もいます。
この違いは、作業の途中では表に出てきません。表に出るのは、たいてい最後です。
「直ったと聞いたのに、また同じことが起きた」「結局、何が原因だったのか分からないまま終わった」という形で、あとから食い違いが見つかります。
ココナラでの取引は累計600+件、いただいた評価は500件を超えました（2026年9月時点）。
そのうち星5未満の評価は25件です。この記事は、その中の1件でいただいた「本当に解決したかったことが、解決しきれなかった」というご指摘を出発点に、復旧を依頼する前に決めておきたいゴールの話をまとめたものです。
- 復旧の「直った」には、症状を止める・原因を特定する・再発を防ぐという3つの水準があること
- 症状（白画面・500エラー・ログイン不可・改ざんの疑い）ごとに、どのゴールから入るのが安全か
- 原因を特定できなかったときに、何を報告として受け取るべきか
- 見積もりを受け取ったときに確認したい5つの項目と、依頼前に用意しておくとよい情報
なぜ「直った」がすれ違うのか ― 復旧の相談で最初に起きること
復旧の相談は、たいてい急いでいる状態で始まります。サイトが表示されない、管理画面に入れない、フォームからの連絡が止まっている。
どれも、待っている時間そのものが損失になります。
そのため、最初のやり取りは「早く見てほしい」「すぐ着手します」という会話になりがちです。
ここで抜け落ちるのが、どの状態になったら終わりにするのかという合意です。急いでいるときほど、合意の言語化は後回しになります。
依頼する側の「直った」― 画面が戻れば、ひとまず終わり
依頼する側にとって、いちばん困っているのは「使えないこと」です。
お客様からの予約が入らない、問い合わせが受けられない、名刺に書いたURLが開かない。
だから、画面が戻った時点で困りごとは消えます。
この感覚は自然なものですし、間違ってもいません。ただし、画面が戻ったことと、原因がなくなったことは別です。
表示だけ戻して運用を再開すると、同じ原因がそのまま残ります。
作業する側の「直った」― 原因と再発の可能性まで説明できること
一方、作業する側は「なぜ起きたのか」が分からないままだと、直したと言い切れません。
たとえばプラグインを停止したら表示が戻ったとして、そのプラグインが単独で悪いのか、別の設定と組み合わさって問題になったのかで、その後の運用は変わります。
つまり同じ「直った」でも、片方は状態の話をしていて、もう片方は理由の話をしています。
すり合わせないまま進めると、どちらも誠実に取り組んでいるのに、最後だけ噛み合いません。
解決しきれなかった案件から学んだこと
過去にいただいた評価のなかに、「本当に解決したかったことが、解決しきれなかった」というご指摘があります。
追加でご依頼いただいた部分は解決できたものの、依頼者がいちばん直したかった問題については、原因を特定できないまま取引が終わりました。
振り返ると、自分側の原因ははっきりしています。どこまでできたら完了とするかを、作業に入る前に言葉にしていませんでした（評価の内容からの振り返りで、当時のやり取りの詳細までは確認していません）。原因が分からない可能性があること、その場合に何を成果としてお渡しするのかを、先に共有しておくべきでした。
もう1件、「解決までの時間」についてのご感想もいただいています。こちらも根は同じで、見通しを言葉にしていなかったことが原因です。
時間がかかること自体より、いつまでかかるのか分からない状態のほうが、待つ側には負担になります。
なぜ、事前のすり合わせが後回しになるのか
理由は単純で、急いでいる相談ほど「まず手を動かして状況を確かめたい」という気持ちが先に立つからです。
相手も急いでいるのだから、説明より着手を優先したほうが親切だ、という思い込みもありました。
ところが、あとで食い違うのは、まさにその後回しにした部分です。5分の確認を惜しんだ結果、最後に何時間分かの説明が必要になる。
しかも、その説明は「言い訳」として受け取られやすい状態になっています。
いまは、着手前に次の3点だけは必ず文章で残すようにしています。どれも1〜2行で済みます。
- 今回めざすゴール（症状を止める／原因を特定する／再発を防ぐ のどれか）
- 原因が特定できなかった場合に、何を報告として出すか
- 追加の作業が必要になった場合の、連絡と見積もりの手順
ここからは、実際に相談を受けたときにどう決めているかの話です。3つのゴールは順番に積み上がりますが、全部を一度にやる必要はありません。今回どこまでやるかを決めておくと、費用も時間も見通しが立ちます。
復旧の3つのゴール ― 症状を止める・原因を特定する・再発を防ぐ
復旧の相談を受けるとき、私は次の3つのどれを目指すのかを最初に確認します。
どれが正しいということはなく、状況によって選ぶものです。
| ゴール | 主にすること | 終わりの判断 | 向いている場面 |
|---|---|---|---|
| ① 症状を止める | 状態の保全、優先しての確認、復旧方針の整理 | 画面や受付が使える状態に戻る | 予約・問い合わせが止まっていて、まず止血したい |
| ② 原因を特定する | ログとファイルの変更から切り分け、影響範囲の確認 | 原因と影響範囲を報告できる | 再発を避けたい／関係者に説明する必要がある |
| ③ 再発を防ぐ | 残った仕掛けの除去、更新と運用の見直し | 対策と運用方針に合意できる | 改ざんのあと、または短期間に再発している |
3つは順番に積み上がる関係にありますが、すべてを一度にやる必要はありません。予算にも時間にも限りがあります。
だからこそ、今回はどこまでやるのかを決めておくことに意味があります。
症状ごとに、どのゴールから入るのが安全か
よく相談をいただく症状について、どのゴールから入るのが安全かを整理しました。
実際には現物を見て判断しますが、依頼する前の目安にはなると思います。
| 症状 | 最初に置くゴール | 理由 |
|---|---|---|
| 真っ白な画面（白画面） | ① 症状を止める → ② 原因を特定する | エラー表示を有効にすれば原因の手がかりが出ることが多く、止血と切り分けを同時に進めやすい |
| 500 / 503 エラー | ① 症状を止める | サーバー側の制限や設定が絡むことがあり、まず表示を戻して影響を止めるのが優先 |
| 管理画面にログインできない | ② 原因を特定する | 入れない理由（権限・プラグイン・URL設定）で対処が変わるため、切り分けを先に行う |
| 改ざんの疑い・警告表示 | ③ 再発を防ぐところまで | 表示だけ戻しても、仕掛けが残っていれば必ず再発する |
| フォームのメールが届かない | ② 原因を特定する | 送信側・受信側・DNS のどこで止まっているかを切り分けないと、直したつもりになりやすい |
改ざんの疑いだけは、①で止めても意味がありません。当サイトでも改ざんマルウェア対策のガイドやindex.phpの改ざん事例で触れているとおり、侵入経路と残された仕掛けを取り除くまでが1セットです。
ゴールと料金は連動している ― 「5,000円で全部直る」と読めない書き方に
この3つのゴールは、そのまま料金の分け方にもなっています。当サイトで公開している復旧まわりの料金は、次のように分かれています。
- 原因の切り分け：ログやファイルの変更から原因を絞り込みます。切り分けの範囲ですぐ直せる軽微なものは、その料金内で対応します。
- 緊急対応（初動判断）：優先しての状態確認、保全の指示、復旧方針の整理までを行います。
- 緊急復旧：原因の確認と復旧作業に加えて、残った仕掛けの検出と除去、復旧後の運用提案までを含みます。
以前は、この線引きが読み取りにくい書き方をしていました。金額だけが目に入ると、「この金額を払えば全部直る」と読めてしまいます。
実際には調査の料金なのに、復旧までの料金だと受け取られれば、作業が妥当でも不満は残ります。
いまは各ページに「この料金は何に対する料金か」を先に書き、範囲を超える場合は費用をご案内して承認をいただいてから進める、と明記しています。
表現を変えただけですが、着手前の質問の内容が変わりました。
原因を特定できなかったときに、何を報告するか
調査をしても原因にたどり着けないことはあります。頻繁ではありませんが、ログが残っていない、サーバーの管理権限がない、すでに何度も復旧操作が試されていて痕跡が上書きされている、といった条件が重なるとそうなります。
そのときに何も残らないと、依頼者には「お金だけかかった」という結果になってしまいます。いまは、次の3点を必ず報告に含めています。
| 報告に含めるもの | 具体的に書くこと |
|---|---|
| 分かったこと | いつから、どの画面で、どのファイル・設定に変更があったか。確認できた事実だけを書く |
| 分からなかったこと | 確認できなかった項目と、その理由（ログの保存期間を過ぎている、権限がない、など） |
| 次にできること | 追加で確認するなら何を見るか。その場合の費用と時間の目安 |
管理情報が揃っていないサイトの引き継ぎ診断でも、確認できなかった項目をそのまま報告する形にしています。
分からなかったことを隠さずに書くほうが、次の判断材料になります。
最初の30分で確認すること ― 依頼する前でもできる範囲
ここまでゴールの話をしてきましたが、「そもそも、どのゴールが必要なのかが分からない」という段階もあります。
その場合でも、最初の30分で確認できることがいくつかあります。専門知識がなくてもできる範囲に絞って整理しました。
| 確認すること | 見かた | 分かること |
|---|---|---|
| 別のブラウザ・別の回線で開く | スマートフォンのモバイル回線などで同じURLを開く | 自分の環境だけの問題か、サイト自体の問題かが分かれる |
| エラーの文言をそのまま控える | 画面に出ている英数字を、省略せずスクリーンショットで残す | 500・503・データベース接続確立エラーなど、原因の方向が絞れる |
| 直前に何をしたか思い出す | 更新、プラグインの追加、テーマの編集、サーバーの設定変更 | 変更と発生のタイミングが重なるかどうかで、切り分けが早くなる |
| 管理画面に入れるか試す | /wp-admin/ を開いて、ログイン画面が出るかどうか | 表示側だけの問題か、WordPress全体の問題かが分かれる |
| サーバーの管理画面を開けるか確認する | 契約先のコントロールパネルにログインできるか | ログやバックアップを確認できる範囲が決まる |
この5つが分かっているだけで、相談の初動はかなり短くなります。
逆に、ここが空欄のまま「動きません」とだけ伝わると、まず状況確認のやり取りに時間を使うことになります。
技術的な確認まで自分で進めたい方は、当サイトのWP-CLIシリーズが参考になります。
現状調査の鉄板コマンド、URL設定とDB接続の確認、プラグイン・テーマの状態確認、コアファイルの破損・改ざんの確認の順に見ていくと、状態を壊さずに現状を把握できます。
ただし、確認と復旧操作は別です。状態を見るだけなら安全ですが、直そうとして設定を書き換えると、先ほどの「痕跡が上書きされる」問題が起きます。
判断に迷ったら、見た内容をそのままお知らせいただければ、そこから引き継げます。
制作会社・代理店から相談をいただくときは、報告の形まで決めておく
復旧のご相談は、サイトの持ち主から直接いただくこともあれば、制作会社や広告代理店の担当者を通していただくこともあります。
後者の場合、ゴールの合意が二重になる点に注意が必要です。
担当者と私の間で「まず症状を止める」と決めても、その先のエンドクライアントには「直った」としか伝わらないことがあります。
あとで再発したとき、説明の矢面に立つのは担当者です。
| 立場 | 知りたいこと | 報告に必要な形 |
|---|---|---|
| エンドクライアント | いつ使えるようになるか／同じことが起きないか | 専門用語を使わない現状と、次に起きうることの説明 |
| 制作会社・代理店の担当者 | 何が原因で、どこまで自社の責任範囲か | 事実（確認できたこと）と推測（可能性）を分けた報告 |
| 作業する側（当サイト） | 触ってよい範囲と、判断を仰ぐ相手 | 連絡先と決裁の順序、作業可能な時間帯 |
そのため、担当者を通じたご依頼では、報告をそのまま転送できる形で書くようにしています。
確認できた事実と、可能性として考えられることを分けて書き、専門用語には短い補足を付けます。
転送のたびに書き直しが発生すると、それ自体が担当者の負担になります。
「どこまでが今回の作業か」を、最初のメールに残しておく
口頭やチャットで合意した内容は、担当者が変わった時点で消えます。だからこそ、最初のやり取りに短い文章で残しておく価値があります。
次の3行で十分です。
- 今回の作業のゴール（症状を止める／原因を特定する／再発を防ぐ のどれか）
- 含まれない作業と、追加見積もりになる条件
- 原因が特定できなかった場合に、何を報告として出すか
この3行があると、途中で担当者が交代しても、前提から説明し直す必要がありません。
実務では、この「引き継げる状態」が、技術的な巧拙と同じくらい効いてきます。
よくある3つの誤解
- 「とりあえず安いプランで頼めば、足りなければ足せる」：足せますが、切り分けの前に復旧操作を重ねると、かえって原因が追えなくなります。順番は、止血 → 切り分け → 復旧が基本です。
- 「原因は分からなくても、直ればいい」：改ざんが絡む場合だけは例外です。仕掛けが残っていれば必ず再発し、二度目のほうが復旧に時間がかかります。
- 「専門用語が分からないと相談できない」：不要です。症状・発生した日時・直前の操作の3つだけで、切り分けは始められます。
3つ目については、当サイトの相談窓口でも「専門用語が分からなくても相談できます」「分かる範囲で大丈夫です」とご案内しています。
用語を整理するところから一緒に進めます。
復旧が終わったあとに、何を残すか
復旧は、画面が戻った時点で終わりではありません。むしろ、そこからが次のトラブルの準備期間です。
同じサイトで二度目・三度目の相談をいただくとき、前回の記録が残っているかどうかで、初動の速さがまったく変わります。
作業のあとに残しておきたいのは、次の3つです。どれも、次に担当する人が別の誰かでも読める形にしておくのが要点です。
| 残すもの | 中身 | 次に効くところ |
|---|---|---|
| 作業の報告 | 確認した事実、行った作業、確認できなかった項目 | 再発したときに「前回と同じか違うか」がすぐ分かる |
| 構成の記録 | WordPress・PHPのバージョン、テーマとプラグインの一覧、サーバーの契約先 | 更新の可否を判断できる。引き継ぎのときにそのまま使える |
| 運用の決めごと | 更新のタイミング、バックアップの保存先と保存期間、連絡先 | 「誰が・いつ・何をするか」が決まっていれば、事故そのものが減る |
3つ目が抜けているサイトは、実際とても多いです。復旧の相談をいただいた時点で、バックアップが一度も取られていなかった、あるいは保存先が分からなくなっていた、という状況は珍しくありません。
「直った状態」を保つ費用は、直す費用より小さい
復旧は、壊れた状態から元に戻す作業なので、どうしても調査の時間がかかります。
一方、壊れないように保つ作業は、更新の判断とバックアップの確認が中心です。かかる時間の性質が違います。
当サイトでは、月額の保守プランで更新の判断とバックアップを継続的に見る形をご用意していますが、保守契約だけで過去の不具合や改ざんの復旧がすべて含まれるわけではありません。
まずスポットで現状を切り分け、復旧してから月額保守へ移る、という順序が安全です。
担当者が不在でサイトの状態が分からない場合は、引き継ぎ診断で、安全に更新してよい範囲と注意すべき範囲を整理するところから始められます。
確認できなかった項目も、そのまま報告に含めます。
星5未満の25件を、どう扱っているか
評価は、受け取った瞬間は点数にしか見えません。けれども、書かれている言葉を並べてみると、共通する型が見えてきます。
この記事のもとになったご指摘も、単独で見れば1件ですが、他の低い評価と並べると同じ場所でつまずいていました。
いま意識しているのは、点数そのものより、次の2つを見分けることです。
- 期待と結果の差が書かれている（何を望んでいたか）
- 時間や連絡についての言及がある
- 説明が分かりにくかった、という趣旨の記述
- 「丁寧」「迅速」など短い言葉だけのもの
- 満足の意味で星4を付ける方もいる
- 点数と本文の印象が食い違うもの
後者を「不満」と決めつけて対策を作ると、的外れな改善になります。
逆に前者は、たとえ1件でも、同じ理由で言葉にしなかった方が他にもいると考えたほうが自然です。声に出す人のほうが少ないからです。
この記事でいえば、到達点のすり合わせという1件の指摘に対して、いまは全部の相談で着手前に3行残すという形に変えています。
1件のために全体の手順を変えるのは大げさに見えるかもしれませんが、手順にしないと再現しません。
最後に、依頼する側で準備できることをまとめます。ここが揃っているだけで、初動の精度がはっきり変わります。難しいことはひとつもありません。
依頼する側が、相談の前に用意しておくとよいもの
復旧の初動は、情報がどれだけ揃っているかで進み方が変わります。とはいえ、全部を揃える必要はありません。
分かる範囲で構いません。当サイトの相談ページでも「分かる範囲の情報から相談内容を整理できます」とご案内しています。
| 用意するもの | なぜ役に立つか |
|---|---|
| 症状が出た日時 | 更新・バックアップ・アクセスの記録と突き合わせられる |
| 直前に行った操作 | プラグインの更新、テーマの編集、サーバー設定の変更などが手がかりになる |
| 画面のスクリーンショット | エラーの文言そのものが、原因の絞り込みに直結する |
| 管理情報の有無 | サーバー・ドメインの契約先が分かるかどうかで、確認できる範囲が変わる |
| いつまでに戻す必要があるか | 止血を優先するか、原因の特定から入るかの判断が変わる |
復旧を急ぐときほど、やらないほうがよい3つの操作
善意で行った操作が、結果として調査を難しくすることがあります。次の3つは、状況が分からないうちは避けたほうが安全です。
- 原因を決めつけて操作を繰り返す：プラグインの入れ直しやテーマの切り替えを繰り返すと、変更の履歴が上書きされ、どこから壊れたのかが追えなくなります。
- WordPress本体の再インストール：症状が消えることはありますが、原因ごと消えてしまうため、再発したときに同じところからやり直しになります。
- バックアップの繰り返し復元：改ざんが絡む場合、バックアップ自体に仕掛けが含まれていることがあります。復元前に、いつの時点のものかを確認してください。
どれも「触らないでください」という意味ではありません。触る前に、いまの状態を残しておいてほしいということです。
スクリーンショットとファイルの控えがあるだけで、切り分けの精度は変わります。
当サイトのWP-CLIでの現状調査の記事では、状態を壊さずに確認するコマンドをまとめています。
見積もりを受け取ったら、確認したい5つのこと
これは当サイトに限った話ではなく、どこに依頼する場合でも同じです。
見積もりや出品の説明に、次の5つが書かれているかを見てみてください。
| 確認すること | 曖昧だと何が起きるか |
|---|---|
| 料金に含まれる作業 | 「調査まで」なのか「復旧まで」なのかで、総額が変わる |
| 含まれない作業 | 感染範囲が広い場合や複数サイトなど、追加見積もりになる条件を先に知っておける |
| 原因が分からなかったときの扱い | 報告の内容と料金の考え方が分かっていれば、途中で不安にならない |
| 連絡のタイミング | いつ返事が来るかが分かると、待っている時間の不安が減る |
| 作業後に何が残るか | 報告書や作業メモが残るかどうかで、次に別の人へ引き継ぐときの手間が変わる |
当サイトの場合、ご連絡の受付は24時間、対応は平日10:00–17:00で、営業時間内にいただいたご相談には当日中に一次回答をお返ししています。
時間外のご連絡は翌営業日の返信です。
作業のあとは、確認した内容と結果を報告としてお渡しし、検収をもって完了としています。
よくある質問（FAQ）― WordPressの復旧を依頼する前に
まとめ
- 「直った」には、症状を止める・原因を特定する・再発を防ぐという3つの水準がある
- どこまでを今回のゴールにするかを、着手の前に1〜2行でよいので文章で残しておく
- 料金は、そのゴールに対応して分かれている。「この金額は何に対する料金か」を確認する
- 原因が分からなかった場合も、分かったこと・分からなかったこと・次にできることを報告として受け取る
- 依頼する側は、日時・直前の操作・スクリーンショットを、分かる範囲で残しておく
星5未満の25件は、どれも技術ではなく、こうした前提の共有でつまずいた記録です。
同じことを繰り返さないために、いまは着手前のすり合わせを作業の一部として扱っています。
WordPressの不具合について、どのゴールで進めるか迷っている場合は、状況を伺ったうえでご案内します。
30分程度のヒアリングと通常のお見積もりは無料です。
本記事の取引件数と評価は、ココナラの取引データおよび評価一覧にもとづく 2026 年 9 月時点の数値です。対応の範囲・料金・受付時間は、各サービスページの記載によります。
