GMOのサーバー障害を機に、20年近く蓄積したWordPressブログをXserverへ移転した顛末

―― 5,255件の記事を取り戻すまでに、何がうまくいき、何がうまくいかなかったのか

2026年10月下旬、長年利用してきたGMO系のレンタルサーバーで問題が発生した。

私が運営している個人サイトは、手作りのHTMLによるホームページと、WordPressによるブログから構成されている。ブログには長年書き続けた記事が5,000件以上ある。日常の雑談から、クルマ、オートバイ、アマチュア無線、食品安全、製品安全、海外生活まで、内容は雑多である。

こうした個人サイトにとって、サーバーは単にホームページを表示するための設備ではない。長年の記録を預けている保管場所でもある。

今回の問題をきっかけに、私はGMOのレンタルサーバーからXserverへの移転を決断した。

結論から言えば、ブログの記事は5,255件まで復旧でき、従来のURLを使って公開することにも成功した。

ただし、そこに至るまでの道のりは、想像していたよりはるかに厄介だった。

1．最初の問題は、ホームページが表示されないことだけではなかった

2026年10月下旬、GMO側のサーバーで障害が発生し、ホームページやブログの正常な利用に支障が出た。

私が特に困ったのは、単に閲覧できないだけでなく、復旧に必要な管理機能にも正常にアクセスできなくなったことである。

旧レンタルサーバーのコントロールパネルにログインできず、WordPressの管理画面も正常に使えない。

サーバーの設定やデータベースを確認したくても、通常の管理経路が機能しない。サポートにも問い合わせたが、必要な回答を速やかに得られない状況が続いた。

利用者からすると、これは非常に困る。

障害そのものは、どの事業者にも起こり得る。しかし、障害発生時に利用者が自分のデータを取り出せるか、代替手段が案内されるか、問い合わせに適切な回答があるかは、サービスを評価するうえで重要な問題である。

私は企業で長年、品質保証、製品安全、法規制対応、危機管理に携わってきた。その経験から、今回の対応には強い疑問を感じた。

もちろん、外部の利用者である私には、GMO社内の危機管理体制や訓練の実施状況までは分からない。

しかし、少なくとも今回、私が利用者として経験した復旧支援は、安心して事業者にデータを預け続けられると感じられるものではなかった。

そこで、復旧を待ち続けるのではなく、別の事業者へ移転することにした。

2．移転先にXserverを選んだ理由

移転先の候補として、さくらインターネットとXserverを比較した。

比較したのは、料金だけではない。

• 国内事業者であること
• 日本語による技術サポートを受けられること
• ホームページ、WordPress、メール、DNSを扱えること
• 将来的にはドメイン管理まで含めて一社に集約できること
• 年間の費用をおおむね3万円以内に収められること
• 障害発生時の影響範囲や復旧体制を重視すること

最終的に、Xserverのスタンダードプランを選び、3年契約を結んだ。

これはXserverに障害が起きないと判断したからではない。どの事業者にも障害の可能性はある。

むしろ、今回の経験から、障害の有無だけでなく、障害が発生したときに利用者が自分のデータを保全し、他社へ移転できることを重視するようになった。

3．最初に移転できたのは、手作りのHTMLホームページだった

私のホームページは、WordPressではなく、ホームページ・ビルダーや手作業で編集してきたHTMLファイルを中心に構成している。

こちらは比較的簡単だった。

必要なHTML、CSS、画像などのファイルをXserverに転送し、公開先を切り替えることで、従来のホームページを表示できるようになった。

10月末には、新しいサーバーからホームページが正常に配信されていることを確認できた。

この段階で分かったのは、静的なホームページとWordPressでは、移転の難しさがまったく違うということだ。

HTMLサイトは、基本的にファイル一式があれば再現できる。

一方、WordPressはファイルだけでは復旧できない。

記事本文、カテゴリー、タグ、投稿日時、画像との関連付け、各種設定などがデータベースに保存されているからである。

WordPressの復旧には、プログラムや画像だけでなく、対応するデータベースが必要だった。

4．WordPressのファイルはあった。しかし記事が足りなかった

旧サーバーからは、FTPを利用してWordPress関連のファイルを確保できた。

テーマ、プラグイン、アップロード画像など、復旧に必要なファイルの相当部分は手元に残っていた。

また、2024年12月に作成したUpdraftPlusのデータベースバックアップも存在した。

これは非常に重要だった。

古いとはいえ、データベースのバックアップがあったことで、WordPressの基本構成を復元する手掛かりを得られた。

XserverにWordPressを用意し、データベースを復元して、サイトのURLや接続設定を調整した。

その結果、2024年12月までのブログ記事については、表示できる状態まで復旧できた。

ところが、大きな問題が残った。

2025年から2026年に投稿した記事が、古いバックアップには含まれていなかったのである。

これは当然のことだ。2024年12月のバックアップに、それ以降の記事が入っているはずはない。

つまり、この時点ではブログの一部が復旧しただけだった。

5．旧GMOサーバー上での復旧作業は難航した

新しいサーバーへの移転と並行して、旧GMOサーバー上のWordPressも復旧できないか試した。

WordPressの設定ファイル、データベースの接続情報、サイトURL、ログイン情報、アクセス制御ファイルなどを確認し、必要な修正を行った。

一時的にはログイン画面が表示され、管理画面へのログインに成功したこともあった。

しかし、その先で404エラーや403エラーが発生し、正常な管理・閲覧状態には戻らなかった。

HTTPSへの強制転送やSSL証明書の不整合も問題を複雑にした。

HTTPで確認したいページがHTTPSへ転送され、転送先ではページが見つからない。設定を直しても別の場所でエラーが出る。

このような状態では、原因を一つずつ切り分けるのが難しい。

しかも、旧サーバーの管理画面そのものが正常に利用できないため、通常の復旧手順を踏むことも困難だった。

結局、旧サーバー上でWordPressを完全復旧する方法には見切りをつけ、新しいサーバー側でデータを再構成する方針に切り替えた。

6．最大の難関は、新旧データベースの統合だった

その後、GMO側から取得できたデータを利用して、2024年のバックアップでは不足していた記事の復旧を進めた。

ここで新たな問題が発生した。

古いバックアップを復元したWordPressと、後から回収したデータベースでは、投稿を識別する番号が必ずしも一致しない。

WordPressでは、投稿、固定ページ、添付画像などに固有のIDが割り当てられる。

二つのデータベースを単純に結合すると、同じIDを持つ別のデータが衝突する可能性がある。

記事本文だけを移せばよいわけでもない。

画像の関連付け、投稿のメタデータ、カテゴリーとの対応、アイキャッチ画像なども整合させる必要がある。

今回の統合作業では、次のようなデータを扱った。

これらは復旧作業で処理したデータの内訳であり、すべてが新しいブログ記事という意味ではない。

この段階では、SQLによるデータ確認と統合を繰り返した。

特に注意したのは、既に復旧できている記事を壊さず、不足している記事を追加することである。

作業中のデータベースを直接上書きしてしまうと、失敗したときに元へ戻せなくなる。

そこで、復旧元のデータ、作業途中のデータ、統合後のデータを分けて管理した。

統合後も、元データをすぐには削除せず、比較や再確認ができる状態を残している。

結果として、公開記事は5,255件まで復旧できた。

7．記事が復旧しても、ブログの外観は元に戻らなかった

記事の復旧に成功しても、作業は終わらなかった。

次に問題になったのは、ブログの外観である。

私のブログでは、従来から次のような表示を使っていた。

• ページを開くたびに切り替わる、自分で撮影した横長のヘッダー写真
• 写真に重ねて表示するブログのタイトル
• 本体ホームページへのナビゲーション
• 特定カテゴリーの記事を流すニュースティッカー
• 中央の大きな記事スライダーと、その左右に配置する記事
• 過去記事を並べる2列表示
• 右側のカレンダー、カテゴリー、人気記事などのウィジェット

これらの設定は、WordPressの記事データを復元するだけでは完全には再現できなかった。

そこで、保存されていたテーマや新たにインストールしたテーマを、一つずつ確認した。

NewsBlogger、Newscrunch、Newsup、NewsGoal、Newsxo、News Magazine X、Newspaperlyなど、複数のテーマを比較した。

中央のスライダーと左右の記事配置を再現できるテーマはあっても、ヘッダー写真を希望する高さで表示できない。

反対に、ヘッダー写真をランダムに切り替えられるテーマでは、記事の配置が希望どおりにならない。

一つのテーマで、従来の外観を完全に再現するのは簡単ではなかった。

最終的にはNewsGoalを採用した。

このテーマでは、標準機能を使って次の構成を再現できた。

• アップロードした写真のランダムなヘッダー表示
• ブログタイトルとロゴの表示
• 従来のナビゲーション
• カテゴリー別の記事ティッカー
• 中央の大型スライダーと左右の記事表示
• 過去記事の2列表示
• 右サイドバーのウィジェット

ヘッダーの高さは特に苦労した部分である。

タイトルの文字を大きくするとヘッダーも高くなるが、今度はタイトルが不自然に改行される。改行を解消すると写真の表示領域が薄くなる。

別のテーマでは、写真の表示方法を調整できても、記事一覧の配置が合わなかった。

最終的には、テーマの標準設定の範囲で、実用上納得できる外観に近づけることができた。

ただし、2026年10月末の状態と完全に同一になったわけではない。

8．プラグインも、昔のまま全部使えばよいわけではなかった

旧サーバーから移したWordPressには、多数のプラグインが残っていた。

中には、以前使っていたテーマ専用のものや、過去の移行作業に必要だったもの、旧レンタルサーバー向けのものも含まれていた。

プラグインは多ければよいというものではない。

更新が止まったものや不要なものを残しておくと、管理が煩雑になる。機能が重複するプラグインもある。

一方で、名前だけを見て不要と判断するのも危険である。

例えば、現在のテーマとは別系列のプラグインであっても、サイドバーの人気記事表示に使っている場合がある。

そこで、現在のブログで実際に使用している機能を確認しながら整理することにした。

特に、記事投稿時のSNS向けタイトルや画像の設定機能は、従来の運用に必要なものであり、復旧できた。

人気記事表示についても、過去の累計アクセス数だけではなく、一定期間のアクセスを集計する方法を検討した。

なお、プラグインの整理は一度に全部行うのではなく、表示や投稿機能への影響を確認しながら進めている。

9．ChatGPTは役に立った。しかし、間違いも少なくなかった

今回の復旧作業では、ChatGPTをかなり使った。

WordPressの構成確認、SQLの作成、データベースの統合、テーマの機能調査、プラグインの整理などである。

特に、データベースを比較し、不足している記事や関連情報を統合する作業では、AIの支援が役立った。

従来であれば、SQLの仕様を調べながら相当な時間を費やしたであろう作業を、対話形式で進められたことは大きい。

しかし、良いことばかりではなかった。

ChatGPTが提示した手順の中には、実際の画面と一致しないものがあった。

存在しない設定項目を探させられたり、既に確認済みの内容を再度調べるよう求められたり、テーマの機能について十分な根拠のない推測が示されたこともあった。

特にテーマ選定では、似たような候補を繰り返し調べることになり、かなりの時間を浪費した。

また、ある設定を変更すると別の表示が崩れるという問題についても、原因の切り分けより先に対処方法を提示されることがあった。

AIは非常に便利だが、AIが自信を持って説明したことが、必ずしも正しいとは限らない。

今回の経験では、画面やデータベースの実際の状態を自分で確認し、AIの説明と一致するかを判断することが不可欠だった。

それでも、5,000件以上の記事を扱う復旧作業を個人で進められたことを考えると、AIの支援には十分な価値があった。

大切なのは、AIを万能の技術者として扱うのではなく、検証が必要な作業支援者として利用することだと思う。

10．何が成功し、何が失敗したのか

今回の作業結果を整理すると、次のようになる。

重要なのは、今回の「成功」が、すべてを以前と寸分違わず元に戻したという意味ではないことである。

記事とブログの主要機能を復旧し、再び運用できる状態にしたことが、今回の最大の成果だった。

11．バックアップは「ある」だけでは不十分だった

今回、最も痛感したのはバックアップの重要性である。

2024年12月のバックアップがあったことは幸運だった。

しかし、それだけでは2025年以降の記事を復旧できなかった。

また、WordPressでは記事本文だけでなく、画像、テーマ、プラグイン、設定、データベースが互いに関係している。

バックアップが存在していても、実際に復元できるかどうかは別問題である。

そこで、復旧後はUpdraftPlusを利用し、Google Driveへのバックアップを設定した。

バックアップの実行と保存が成功することも確認した。

今回の経験から得た教訓は、次の三つである。

第一に、バックアップはサーバー事業者とは別の場所にも保存すること。

第二に、記事のデータベースと画像などのファイルを両方保管すること。

第三に、バックアップの存在だけで安心せず、実際に復旧できることを確認すること。

特に長年運営しているブログでは、過去記事の蓄積そのものが財産である。

サーバーの契約先が変わっても、自分の記録を失わない仕組みを作っておく必要がある。

12．今回の障害で、サーバー事業者に求めるものが変わった

以前は、レンタルサーバーを選ぶ際、料金、容量、転送速度、WordPressの使いやすさなどを重視していた。

今回の経験で、それに加えて重要だと感じたのが、障害時の対応とデータの可搬性である。

サーバー障害そのものをゼロにすることは難しい。

しかし、障害が発生したときに、利用者がどの程度の情報を得られるか、データを取り出せるか、他社へ移れるかは、事業者のサービス品質を評価する重要な要素だと思う。

私の場合、管理画面に入れず、WordPressの復旧も進まず、必要な情報を得るのに苦労したことが、移転を決断する大きな理由になった。

企業の危機管理では、事故が起きないことだけを目標にはしない。

事故が起きることを前提に、被害を限定し、復旧し、関係者に適切な情報を提供できるかが問われる。

レンタルサーバーの運営にも、同じ考え方が必要ではないだろうか。

13．そして、まだ移転作業は終わっていない

2026年11月7日現在、ホームページとWordPressブログはXserver上で運用できるようになった。

公開記事5,255件を復旧できたことは、ひとまず大きな区切りである。

しかし、メールサービスはまだGMO側に残っている。

ドメイン管理についても、移管はこれからである。

次の作業は、従来のメールアドレスを変更せずに、メールサーバーをXserverへ移すことだ。

既存メールの保全、送受信の確認、DNSの切替を順序よく進める必要がある。

その後、ドメイン管理も含めた移転を完了させ、GMOのサービスから離れる予定である。

今回のWordPress復旧には予想以上の時間がかかった。

しかし、長年書き続けた記事を再び公開できたことには大きな意味がある。

サーバーは借り物でも、そこに蓄積した文章や写真は自分の記録である。

今回の経験を通じて、事業者に依存しすぎず、自分のデータを自分で守ることの重要性を改めて認識した。

そして、ChatGPTのようなAIは、使い方次第では個人でも大規模なデータ復旧に取り組める強力な道具になる一方、利用者自身が検証し、判断する責任を手放してはいけないことも実感した。

ブログは復旧した。

次はメールである。

まだまだ作業は続く。