KUSANAGIありのConoHaVPSからXサーバーへ移行しました。
このパターンの情報があまりなく、トラブルも多くかなり大変だったのでConohaVPS＋KUSANAGI環境から、Xサーバーへを移行し、最終的にConohaVPS 解約までに見えた流れを、体験談多めでまとめます。
同様な方の参考になれば幸いです。
なぜConoHaVPSからXサーバーへ乗り換えたのか
まずは前提状況からお話しましょう。
ConohaVPSに乗り換えたのは、下記の記事を書いた2019年ですから6年前。
かなり速度も早く快適だったんですよ。
ただ、次のようなモヤモヤがたまってきました。
KUSANAGI8のサポート終了
まず大きかったのが、KUSANAGI8のサポートが終了したことです。
サポートが終了するとセキュリティ面でも不安です。
新バージョンのKUSANAGI9に乗り換えればよいのですが、乗り換えはかなり面倒そう。
>>KUSANAGIのバージョン8⇒9のアップデートが地獄だった件
>>kusanagi 8から9への移行方法（KUSANAGIユーザーフォーラム便り）
WEXALが使えなく
KUSANAGI8のサポートの終了に伴ってなのか、うちの環境ではKUSANAGIの高速化ツールWEXALがいつの間にか使えなくなり・・・
最大のメリットであった速度面にも疑問がでるようになってしまったのです。
WEXALが急に使えなくなったことで、サーチコンソールのウェブに関する主な指標でCLSが指摘されるように。
CLSの問題は自力でなんとか改善しましたが、それならWEXALいらないじゃんってなってKUSANAGI9に乗り換える気がなくなってしまったのです。
トドメはGMOの株主優待改悪とサービス維持調整費
次にいつの間にかサービス維持調整費というわけわからない費用が毎月10%加算されるようになっていたのも不満でした。
こんな費用を取るなら素直に値上げしてくれた方が気持ち良い感じです。
さらに最後の決め手になったのはGMOインターネットグループの株主優待の改悪です。
元々、グループ企業のサービス割引券が半年に1回5,000円分もらえてたんですが、それがなくなったんですよ。
※Conohaやお名前ドットコムなどがグループ企業
それならもうConoHaを使う意味もあまりないな・・・と変更を決意したのです。
Xサーバーを選んだのは、元々別件で契約し続けていて安定しているのを知っていたのもあり、そちらに一本化すればよいかって感じですね。
ConoHaVPS解約までのロードマップ
それではロードマップから見ていきましょう。
テスト環境を準備
今回の移行で意識したのは、
いきなり本番ドメインを動かさない
という点です。
具体的には、Xサーバー側で作れるチェック用サブドメイン「動作確認URL」を使い、そこにConohaVPSからWordPressをコピーしました。
この段階では、DNSもConohaVPSも一切触りません。
Xサーバーの「WordPress簡単移行」や「バックアッププラグイン」を使って、Xサーバー側に“コピーサイト”を作るイメージです。
それを使うと良いでしょう。
最終的に目指した構成
ゴールの構成はシンプルにそろえました。
- Web：Xサーバー
- DNS＋CDN：Cloudflare
- メール：Google Workspace（Gmail）へ移行
- URLは
https://www.ドメイン名に統一
この「www＋https 統一」を最初に決めておくと、
後で .htaccess や検索置換の方針がブレずに済みました。
ステップ1：Xサーバーにコピーサイトを作る
まずはConoHaVPSにあるデータをXサーバーにコピーする話を見ていきましょう。
簡単に言えばConohaVPSにあるサイトをコピーして、そのコピーをXサーバーで復元するイメージです。
WordPress簡単移行は使えず
まずはXサーバーについている「WordPress簡単移行」をつかってみました。
これで完結すればかなり楽ですからね。
これは必要な情報を入力して、ボタンを押せば自動的に移行ができてしまうというスグレモノです。
しかし、これは使えませんでした。
VPSだからなのか、KUSANAGIだからなのか、容量の問題なのかはわかりませんが、何度やってもエラーがでてだめでしたね。
All-in-One WP Migration
次に移行プラグインで有名な「All-in-One WP Migration」を使ってみました。
これは既存のサイトでバックアップをとり、新しいサイトで復元すれば移行が完了するというものです。
こちらは1つのサイトを除いて利用ができました。
かなり簡単に使えますので、「WordPress簡単移行」がつかないならこちらをまず試してみると良いでしょう。
私は以前、移行したときに有料版を買っていましたのでそちらを使いましたが、容量の小さいサイトの場合は無料版でも利用が可能です。
ただし、有料版をもっていてもそれなりに容量の大きいサイトは、これだとエラーが出てしまう時が多いようです。
うちの場合は1つのサイトが駄目でしたね。
UpdraftPlusは重いサイトでもOK
エラーが出てしまったサイトはバックアッププラグインで有名なUpdraftPlusを使いました。
こちらはバックアップファイルを小さく分けてくれるので大きいサイトでもエラーが出にくいんですよ。
旧サーバーでバックアップを取り、新サーバーで復元という形ですね。
ステップ2：コピー後の調整：KUSANAGIの削除
次はかなり苦労したところです。
Xサーバーにコピーした後の調整の話ですね。
URL周りの調整
管理画面にアクセスしようとするとHTTPSに飛ばされてしまうなど、URL周りの不具合が出ました。
そこで wp-config.php の内容を少し調整するなどしても
無効なURLです。プログラム設定の反映待ちである可能性があります。
というXサーバー独自のメッセージに悩まされましたが、多くは「Xサーバー側のSSL設定の反映待ち」や「ブラウザキャッシュ」が原因で、時間経過とキャッシュ削除で解決しました。
慌ててやると気づかないと混乱すると思われますので、時間に余裕があるときにやるべきですね。
KUSANAGIの亡霊？
次にテスト環境側でKUSANAGI削除を進めました。
KUSANAGI系のファイルはXサーバーでは使わないのに、丸々コピーしているのでついてきちゃうんですよ。
具体的に削除したのは以下の通り
wp-content/mu-pluginsからkusanagi〜系のmuプラグインを削除.htaccessなどからNgx_Cache系の行を削除
ここまでやって、「きれいになった」と思っていたのですが、管理画面のダッシュボードにしばらくしたらKUSANAGIメニューが復活してしまったのです。
KUSANAGI関連のファイルを消したら一旦は管理画面のKUSANAGIの項目も消えたのにも関わらず。
これは正直、ヒヤッとしました。
結論から言うと、これもキャッシュを見ていた亡霊でした。
ブラウザのキャッシュを消したら解決。
前述のURL周りもそうですが、ブラウザキャッシュはこまけに消しながらやるのをおすすめします。
ステップ3：ConohaVPSからXサーバーへ本番ドメインを移す
テスト環境で問題がすべてなくなったら、Xサーバーへ完全に移していきます。
これはネームサーバーの設定を変更するだけです。
変更すると今までテスト環境だったコピーサイトが本番環境になります。
ただし、ネームサーバーを変更してから実際にそれが浸透するまでそこそこ時間がかかりますので、待ちましょう。
Cloudflareの場合
うちのサイトはCloudFlareを間にいれていますので、CloudFlareの場合で見ていきます。
CloudFlareのDNSレコード設定からドメインと、www.ドメインの2つのコンテンツをXサーバーのアドレスにするだけ。
元はConohaVPSのアドレスになっています。
あとはひたすら待つ形ですね。
Xサーバーを直接表示させる場合は、XサーバーのDNSレコード設定などで同様にできます。
NS相違：無料SSLの設定
ちょっと苦労したのはXサーバーの無料SSLの設定です。
こちらが「NS相違」と出て利用できなかったんですよ。
おそらくCloudFlareを使っている弊害ですね。
それに伴い、httpでは見れるけどhttpsになると表示されないという現象が。
これはXサーバー側でSSLの設定からDNS認証をすることで解決しました。
CloudFlare側にXサーバーが指定するTXTレコードを追加する形ですね。
これも反映までそこそこ時間がかかりましたので、待ちましょう・・・・
私の場合には、全然通らなかったので、入力ミスかと思い何度も試してしまいました。
URLの統一
SSLが有効になったら次にやりたいのはURLの統一です。
URLの統一とはhttpsなのかhttpなのか、wwwがつくのか、つかないのかというやつです。
統一しなくても問題はないのですが、SEOなどへの影響が少なからずあると言われていますので、やっておいた方がよいでしょう。
Xサーバーの場合、URLの統一は.htaccessなどをいじらなくてもボタンひとつ（ドメイン設定）で可能となっていますから楽ですね。
画像が消えたのは動作確認URLに変わっていたため
そこまでやったら一つの不具合に気づきます。
かなりの画像が表示されてないのです。
DNSの浸透の問題かと思いましたが、画像のURLを確認すると、テストのために使っていた「動作確認URL」なんですよ。
テスト環境では表示されるけど、本番環境だと当然ながらそれだと表示されません。
そこで、「Better Search Replace」というプラグインを使い、
「動作確認URL」を正常なURLに置き換えを行いました。
このとき難物だったのが、wp_site_cashe という巨大テーブルです。
KUSANAGIなのか、プラグインが作ったと思われるこのテーブルが大きすぎて、置換処理がエラーに。
最終的には、
wp_site_casheはBetter Search Replaceの対象から外す- URL修正が終わってから、必要に応じてテーブルを空にする（TRUNCATE）
という対応で落ち着きました。
ここまで終えると完全に元の環境がXサーバー＋CloudFlareで見れる形になっていました。
WEBサイトの移行は終了ですね。
ステップ4：メールをGoogle Workspaceに寄せる
次はメールの移行です。
GmailのPOP3サポートは2026年1月に終了
もともとメールは
- Gmail利用
- サーバーメールで受けてGmailでPOPで取りに行く
という状況でした。
今回の移行だけを考えればConohaのメール設定をXサーバー用にかえるだけでもよいのですが、実はGmailのPOP3サポートは2026年1月に終了してしまうんですよ。
そのためこの機会に Google Workspace に寄せて一本化しました。
Google Workspaceとは、メール、カレンダー、ドキュメント作成、ストレージ、ビデオ会議など、ビジネスに必要なツールを統合したクラウド型のグループウェアです。
Google Workspaceのメール設定は本当に簡単でドメインの認証などをするだけで、ほぼ自動でやってくれます。
DNSレベルでは、
- CloudflareのMXレコードを
mx*.conoha.ne.jpなどからASPMX.L.GOOGLE.COM系に変更
- SPFも
v=spf1 include:_spf.google.com a mx ~allのように整理
し、メールサーバーに依存しない状態をつくりました。
「認証情報のドメインとFromアドレスのドメインが一致していません」
Workspaceへ寄せてから、一部のメールで
このメールは認証情報のドメインとFromアドレスのドメインが一致していません
という警告が出ることがありました。
原因は、「認証のドメインのズレ」です。
対応としては、
- DKIMを設定
- Gmailの「別のアドレスから送信」で、極力Workspace経由で送る
- WordPressからのメールも、
WP Mail SMTPでWorkspaceのSMTPを使う
という形に寄せていくことで、警告はほぼ見なくなりました。
ステップ5：ConohaVPS 解約前にやったチェック
最後はConohaVPSの解約です。
digでA・MX・NSをすべて確認
最終的にConohaVPS 解約に踏み切る前に、全ドメインで次の確認しました。
dig ドメイン名 @1.1.1.1dig www.ドメイン名 @1.1.1.1dig MX ドメイン名 @1.1.1.1
digとはネームサーバに対して問い合わせを行い、その応答結果を表示するコマンドでConohaVPSの設定が残っていないかを確認したのです。
結果として、
- A / wwwA：CloudflareのIP（= フロントはCloudflare、裏はXサーバー）
- MX：Google WorkspaceのMXのみ
- NS：レジストラ側もCloudflare（またはXサーバー）
となっていることを確認し、ConohaVPSのIPやMXがDNS上から完全に消えていることを確認しました。
「Offline」エラーの正体はキャッシュだった
Cloudflareの不要なレコードやTXTを整理していたタイミングで、
Offline
The server appears to be down...
というオフラインエラー画面が出たことが何度かありました。
最初はDNS設定を疑いましたが、実際にはブラウザキャッシュやCloudflareのキャッシュが原因で、キャッシュ削除後はあっさり解消。
この経験からも、
「何か変な表示が出たら、まずはキャッシュを疑う」
という癖がつきました。
今回の移転トラブルかも。。。って思ったのはほとんどキャッシュが原因だったんですよ。
具体的な解約方法
ConohaVPS は解約も一癖あります。
サーバーを消さないといけないんですよ。
「あ、このデータConohaにしかない」ということが出てきてもサーバーを消してしまうと確認もできないので、タイミングは慎重に。
1ヶ月くらい余裕を見ておくと安心でしょう。
また、割引きっぷを使っているとその有効期間が終わるまでは解約できないようになってます。
更新しないなら忘れないうちに自動更新を切っておきましょう。
まとめ
今回、ConohaVPS＋KUSANAGIで動かしていたサイトを、Xサーバー＋Cloudflare＋Google Workspaceにまとめ、最終的にConohaVPS 解約まで来ました
やってみて強く感じたのは、
- いきなり解約しないこと
- DNS（A・MX・NS）をdigで必ず確認すること
- KUSANAGI削除は「プラグイン＋mu-plugins＋.htaccess＋キャッシュ」の4点セットで見ること
- メールを先に整理しておくこと（Google Workspaceなどに寄せると楽）
- こまめにキャッシュを削除すること
この5つさえ意識すれば、「ConohaVPSの解約」「ConohaVPSからXサーバーへの移行」は、決して特別な知識が必要なものではないです。
これから同じようにConohaVPSからの移行を考えている方の、不安を少しでも減らせる記事になっていれば嬉しいです。
ちなみにConohaVPSからXサーバーへの移行しても速度はそれほど変わっていません笑
価格差とKUSANAGI8が更新終了したセキュリティリスクを考えると移行して正解でしたね。
