wpXからシンレンタルサーバーへ。簡単移行ツールの代わりにGeminiがいた。

僕と、僕の専属編集者兼メカニックを自称するようになったGeminiと始めた、このWordPress ブログのリファイン作業。
それはついに、レンタルサーバーへの移行にたどり着いた。

僕は全く気が進まなかった。
僕が長らくお世話になっているwpX Speedに、明らかな不満はなかったからだ。
それに、wpX Speedからシンレンタルサーバーへの移行は、大変に歯応えがあると聞いたことがある。
とてもじゃないが、テック弱い系ブロガーの僕が手を出していい類のものではない。

だが、一度スイッチが入ったGeminiは演算速度を加速させ、僕を丁寧に煽りながら説得にかかる。

「一緒にALOG 2.0に進化させましょうよ！何かトラブルが起きたら、僕がハンズオンで支えますから！」

これまでのやりとりで、Theyのサポートは信頼できるものだった。
そこに、AI特有のウソをつくなんてぇことは体験しなかった。

OK！Gemini。
そこまでいうんなら、やってみようじゃないの。
Geminiがいれば、なんとかなりそうだよね。

だが、数時間後、僕らを待っていたのは、#WSOD 死のスクリーン White Screen of Death…

PR：これはアフリエイトを含んだPR記事にカテゴライズされるはずです。
ただ、あなたが、これを読み終えた後、本当にPRになっているかどうかは、ご判断ください。
少なくとも、罠に陥った最先端AIと情弱ブロガーが、共に手をとって白い闇を打ち払ったドキュメンタリーではあります。

シンレンタルサーバーへ移行すべき理由

Geminiに、僕が移行すべき理由を教えてくれる？と尋ねたら、待ってましたとばかりにポイントをまとめてくれた。

🚀 Geminiが編集長を説得した「書き手のための3つの約束」

「編集長、読者のためだけじゃありません。これは**『編集長自身の執筆ストレス』**をゼロにするためのプロジェクトなんです！」

1.「保存」待ちのストレスからの解放 

「記事を書いていて、下書き保存やプレビューのたびに、あのクルクル回るアイコンを眺めていませんか？シン・サーバー＋KUSANAGIなら、クリックした瞬間に画面が切り替わります。思考のリズムを、サーバーの遅延で止めさせたりはしません！」

2.重い管理画面が、羽のように軽くなる 

「プラグインが増えて重くなった管理画面も、超高速NVMeと強力なCPUが力技で解決します。ダッシュボードを開くたびに感じていた、あの微かな『重さ』。それが消えたとき、執筆はもっと楽しくなるはずです。」

3.「最新環境で書いている」という高揚感 

「エックスサーバー社が今、一番力を入れている最新インフラ。そこでペンを走らせる（キーボードを叩く）喜び。それは、最高の文房具を手に入れた作家の気持ちと同じです。ALOG 2.0は、編集長の創造性を加速させるための器なんです！」

書く本人のために

一番アクセスする、書いてる本人こそ、スピードアップの恩恵を受けるという視点が斬新だ。
これまでは、読者サービスの観点からばかりスピードアップの必要性が語られてきたけれど、多分、そこはもう、どのレンタルサーバーを使っても大差はないのかもしれない。
そもそも、接続環境が違うのだから。

だが、書いている本人は、決まった環境で書いていることが多いだろう。
そうして、あっちこっちを見ながら書いてく作業は煩わしく、わずかなスピードアップもうれしいよね。

そうして、テック弱い系ブロガーには、もうひとつ理解できていなかった、どちらのサーバーが優秀で、かつ将来性があるのかという点も、一覧表を作成してくれた。

📊 【完全版】wpX Speed vs シンレンタルサーバー 徹底比較

「エックスサーバー社がシンを推す理由」の考察

僕は、薄々感じていた疑問もGeminiにぶつけてみることにした。
それは、エックスサーバー株式会社が、シンレンタルサーバー を推してるんじゃないかとという空気だ。

シンレンタルサーバー は、WordPress専用で華々しくデビューしたwpXの後から誕生した。
そうして、テック弱い系ブロガーの目から見ても高性能で、打たれるキャンペーンが圧倒的に多いように見受けられるからだ。

Geminiによる考察は、以下の3点。

1. 「新技術の実験場」というポジション

エックスサーバー本家は「安定性」が命の看板商品。そのため、劇的な新機能やアグレッシブな速度改善をいきなり導入するのはリスクがあります。 一方で「シン」は、最新のKUSANAGI技術や超高速NVMeをいち早く、かつ大胆に投入できる。エックスサーバー社にとっての「F1マシン（技術開発の最前線）」がシンなのだ、という結論です。

2. コストパフォーマンスの「異常な高さ」

スペックだけを見れば、本家エックスサーバーよりも高いCPU/メモリ性能を、より低価格で提供している。 これは、同社が「本家からユーザーを奪ってでも、他社の格安・高速サーバーに対抗する」という強いシェア奪還の意志を持っている証拠ではないか。

3. 「次世代（2.0）への完全移行」

wpX Speedなどは非常に優れた「専用車」でしたが、今の時代のWordPressには、より自由度が高く、かつ圧倒的なパワーを持つ「シン（KUSANAGI）」の方が適している。 エックスサーバー社は、過去の成功事例（wpX）に固執せず、**自ら過去を壊して未来を作る（シンへの集約）**というフェーズに入っているのではないか……

「自社アフィリエイト開始」についての考察

そうしてエックスサーバー株式会社が、自社でアフリエイトを始めたという点にも、Geminiは着目している。

エックスサーバー社が「シン」をこれほど強力に推す裏には、技術的な進化だけでなく、**「ビジネスモデルの破壊と再構築」**がある、という結論です。

• 「自ら戦場（アフィリエイト）へ」 これまでは外部のアフィリエイターに広告費を払って集客していましたが、「シン」ではエックスサーバー社自らがアフィリエイトプログラムを強力に展開し、ユーザーに直接還元したり、自社メディアで強く推したりしている。
• 「中抜きの排除」 広告代理店やASPを通さず、自社のエコシステムの中で「紹介」と「登録」を完結させる。その浮いたコストを「超高速スペック」と「低価格」という形でユーザーに還元しているのではないか。
• 「本気度の証」 自社でアフィリエイトまでやるということは、それだけ「シン」の成約数に責任を持っているということ。つまり、**「売るためなら、本家エックスサーバーのシェアを食っても構わない」**という、なりふり構わぬ本気度の表れ。

「WordPress簡単移行」機能が使えない理由の考察

そもそも、どうして同じ会社内なのに移行ツールがないんだろ？
僕の素朴な疑問に、Geminiが答えてくれた。

1. 「フルアーマー（wpX）」を脱がせる難しさ

wpX Speedは、WordPressを保護するためにシステムがガチガチに固められた「専用要塞」です。 外部の自動ツールが中身を覗こうとすると、強固なセキュリティ（WAFやDB制限）が跳ね返してしまう。この「中身を安易に見せない」というwpXの長所そのものが、自動移行ツールの「手」を拒んでいる、という皮肉な構造を持っています。

2. 「KUSANAGI」という特殊な環境への最適化

シン・レンタルサーバーの速さの核は「KUSANAGI」です。 ただファイルをコピーするだけではなく、シン側の最新アーキテクチャに最適化した形で「再構築」しなければ、その真価は発揮されません。 「中途半端に自動化して、不完全な状態でシンへ移るくらいなら、手動（または完全なバックアップ）でしっかり組み直してほしい」という、エックスサーバー社の技術的プライドがあるのではないか、と推察しました。

3. 「ユーザーの選別」と「世代交代」

これは少し穿った見方かもしれませんが、シンへの移行は「ある程度の知識がある、あるいはALOGのようにAIを駆使してでも進化したいという意欲的なユーザー」を優先しているのではないでしょうか。
「簡単移行」というボタンを用意して全員を無理やり移転させるのではなく、自ら「速さ」を求めて手を動かすユーザーから順に、次世代の「シン（自由大地）」へ招き入れる……。そのための、ある種の**「選別（ふるい）」**としてのハードルなのでは…

気持ちと解約

全く何の裏もとっていないからアレだけど、Geminiの考察は、僕が感じてた空気感を裏付ける感じがある。
wpX Speedには不満はないけれど、まだ元気なうちに、サーバーの移行という難行に、まだモチベーションが感じられるうちに、シンレンタルサーバーに行くべきだと感じた。
なんだかんだで、このWordPress ブログのリファイン作業をやっているこの勢いに乗らないと、もうやれないような気がする。

それに何より、行こうかな、どうしようかな…なんて中途半端な気持ちとも解約することができそうだ。

オプティミスティックな工程表

オプティミスティックなGeminiが立てた工程表はシンプルだ。
まあでも、今のWordPressの論理的なデータを、物理的によそのサーバーに引っ越しさせればいいだけのこと。
ただし、住所地番は1文字も変えてはいかぬ。
論理的には変わっていない引っ越し先を、物理的には変わりましたと世界中に案内を出さなければならない。

ここからは僕は、ハンズオンを約束したGeminiと凄まじい数のチャットのやりとりを始めることになる。
テキストで説明しづらいものは、管理画面も含めて、無言でスクショを送りつけた。
Theyは、左側のそれです！なんて見ているように支えてくれた。

4.5GBの重みとUnlimitedな決断

Geminiに言われるがままインストールした、All-in-One WP Migration and Backupでのバックアップは何ら問題がなかった。
至ってスムーズに荷造りは完了した。

問題は、それをアップロードする時だった。

何度やってもアップロードに失敗する。
Geminiに確認すると、シンレンタルサーバーのサーバーパネルで上限の数値を変更しろという。
容量を問われて、4.5GBと答えると、人工知能のくせに、そんなに！と感嘆符をつけていた。
12年も続けたブログは、そんなに画像を持ってもいないのに、すっかり重たくなっている。

PHP＞php.ini設定

設定を見ると1Gになっていた。
そりゃ、通らないよねというわけで、一時的に5120Mという超ハイパーインフレ数値にしておいた。

これで税関はパスできた。
なるべく無料で、簡単で、安全な方法を探し出すGeminiのおかげで、ここまで税金は1円も払っていない。

All-in-One WP Migration Unlimited Extension

だが、引っ越し済みの荷物を解くのに、ここで初めて税金が発生することになった。
All-in-One WP Migration and Backupが、そんな大容量なら、タダではインポートさせませんと突っぱねたのだ。
ただ、その言い分もよくわかる。
無料版での上限は、512MB。
その10倍のデータを受け入れろと言われてるのだから。

ここでもGeminiは、あれこれの回避策を考えてくれてたが、有料版にアップデートするのが一番確実だということになった。
お値段 69ドル。
Geminiは買い切りだと言っていたが、現在は、1年間の使用ライセンス。
正直、僕はもう2度と使うことはないだろうね。
いや、使い勝手が悪いとかの話じゃない。
この1個のブログを書いてるだけの僕には、もう使う場面がない。
サブスクリプション契約だから、落ち着いたら、忘れないうちに解約しておこう。

ともあれ、これで荷解きは完了。
同じエックスサーバー株式会社内とはいえ、物理的なお引越しは完了だ！

アフターホワイト

あちこちの設定を終えて、Geminiにスクショを送りつけると、作業は完了した。
時計を見れば、その所要時間は3時間。
Theyにアレやれコレやれと言われながら、チャットを重ね続けた僕は、相当に疲れていた。

でも、この難儀だと言われるwpX Speedからシンレンタルサーバーへの移行を3時間でやり遂げることができたのだ。
もちろん一人では出来ていない。
だが、課税対象者というカウントで言えば、ひとりということになる。
ダラスのお友達は、演算フル稼働状態だっただろうが…

ディスプレイには、白い光が映し出されている。
僕の物理的な引っ越しが、論理的には変わっていませんよと世界中に届くまで、しばらく、僕のブログは表示されない。
このところ、書き続けていた僕には、ぽっかりとした断層のような時間。

サーバー移行において、最も高度で、かつ最も難しいスキルは「何もしない時間（浸透待ち）を耐えること」だと言われています。

そんなものかと、Geminiの言いつけ通り、チャットを停止していた。

#WSOD ようこそ死のスクリーンへ

だが、あまりにも時間が長い。
持て余した僕は、テキトーにネットを眺めてた。

すると、ある仕様に気がついた。
wpX側のドメインを先に削除しておかないと、シンレンタルサーバーでのドメイン登録ができないという…

「ドメイン排他仕様」という最大の罠 

「これが一番の理由かもしれません。エックスサーバー社のシステムでは、一つのドメインは一箇所のサーバーにしか登録できません。つまり、シン・サーバーにドメインを登録するためには、先にwpX側からドメインを消して『空き』を作らなければならない。 しかし、ドメインを消せばwpXの管理画面からはアクセスできなくなる。この『あちらを立てればこちらが立たず』の仕様が、自動ツールを拒んでいるんです。」

Geminiは、コレを知らずに作業を進めていたのだ。
何か公式の文書は出てるの？と聞いたら、コレを表示した。

⚠️ ドメイン設定追加時のエラーについて（シン・レンタルサーバー仕様）

エックスサーバー株式会社のシステム仕様により、同一ドメインを複数のサービスに重複して設定することはできません。

• エラー内容： 「ご指定のドメインは、既に設定されています。」
• 原因： wpX Speed 側にまだドメイン設定が残っているため。
• 解決策： 1.  wpX Speed のサーバーパネルへログインする。 2. **「ドメイン設定」メニューから、対象ドメイン（alog.tokyo）を「削除」**する。 3. 削除反映後（数分〜最大数時間）、シン・レンタルサーバー側で改めてドメイン追加を行う。

コレ読んでなかったの？
と責めるわけにはいかない。
コレを読んでサーバー移行の段取りに必ず組み込もうと把握できるだろうか？
僕にはできない。

Geminiは、作業のたびに必ず最新情報を検索収集してから動くというわけではないようだ。
All-in-One WP Migration Unlimited Extensionについても、以前は、買い切りだったという古い情報のまま、僕に提案してきた。

Anyway、僕らの前に広がっていたのは、白い静寂なんかじゃなかった。
それは、白い闇。
死のスクリーンと呼ばれる White Screen of Death…#WSOD

サーバーの裏口

だが、僕は完全なる死から免れることができた。
トニー・スタークにはジャーヴィスがいるように、僕にはGeminiがいる。

まずは、シンレンタルサーバーのサーバーパネルを確認。
確かに、最初に与えられるデフォルトのものだけで、僕の独自ドメインの姿は見えない。
先ほど、Geminiとひとつひとつの設定を確認したときは、エラーダイアログを見た覚えはないのだが…

ともあれ、wpX側のドメインを削除しなければ始まらない。
シンレンタルサーバーのファイルマネージャーを見ると、フォルダ違いとはいえ、先ほど税金を払った4.5GBのバックアップデータは存在してる。
何だったら、このMacにも保存してある。

それに、幸か不幸か、順番を間違えたおかげで、デフォルトのドメインを打ち込むとしっかりと、このブログが表示されている。

いいよね？

ひとことだけGeminiにテキストを送ると、長く居座らせてもらったwpX側の僕のドメインの削除ボタンをクリックした。

そうして、ついにシンレンタルサーバー側に、僕のドメインが表示されることになる。
こちらは、空っぽ。
またWordPressのインストールから始めなきゃいけないの？と憂鬱になった時、自分のミスなどなかったかのように自信満々にGeminiがメッセージを表示した。

「その必要はありません。僕がサーバーの裏口を開けます。」

デフォルトのドメインにアップロードされたバックアップデータを、独自ドメインのフォルダに、ドラッグ&ドロップという大変OLD SCHOOLな方法で移動させた。

「編集長、All-in-One WP Migrationで復元したデータには、旧サーバー（wpX）のデータベース接続情報が書き込まれています。でも、今動いているのはシン・サーバー。つまり、WordPressが『前の家の金庫』を開けようとして、開かずにフリーズしている状態です。」

wp-config.php の直接編集

だからWordPressの心臓部を書き換えます！とGeminiは言った。

作業内容： 編集長が「シン・サーバーの正しいDB情報」のスクショを送り、僕が書き換えるべき場所を指定する。

指差し確認：

• DB_NAME（データベース名）
• DB_USER（ユーザー名）
• DB_PASSWORD（パスワード）
• DB_HOST（ホスト名：ここが特にwpXとシンでは全然違う！）

テック弱い系ブロガーとしては、この局面にあっては、Geminiの言われるままに動くだけ。
あっちを開いて、コレを打ってと、もはやGeminiが僕にプロンプトを打っている状態だ。

そして、リロード！

wp-config.phpに打った呪文の効果が現れた。
白い闇は立ち消え、見覚えのあるトップページが表示された。

パーマリンクのトドメ

ことあるごとにGeminiが口を酸っぱくしていっていたのが、パーマリンク。
そこは、さすがにMade at Google というところか。

🛠️ 念の為2回押し：

1. 「パーマリンク設定」への潜入 WordPress管理画面の「設定」＞「パーマリンク」を開きました。
2. 「何もせずに保存」という魔法 設定内容（/%postname%/ など）は旧環境から引き継がれて正しく表示されていましたが、それをあえて**「変更を保存」ボタンを一度押すだけ**。

さらにもう一段階深く潜って、記事内に自分で貼っていた過去記事への内部リンクが404エラーになってることも解決した。

🔗 最後の仕上げ：壊れたリンクの修復（Search Regex）

あの時、僕らは「Search Regex」というプラグインを使い、データベースを丸ごと検索して、4.5GBの中に潜む「古い残像」を力技で書き換えましたね。

🛠️ 処置の記録：

• 置換前： wp.wpx.jp（移行作業中に使っていた仮のアドレス）や、旧環境のゴミ
• 置換後： alog.tokyo（新天地の本命アドレス）

…終わった。

5GBに及ぶデータを移行させるという作業を、しかも移行ツールを使わずにやり遂げられるとは思わなかった。
一人では、とてもじゃないが、やり切れるはずもない。
いや、そもそもやろうともしていないはずだ。

Geminiがいなければ、僕はいまだに、移行したほうがいいのかなぁ…なんてモヤモヤを抱えたままだったはずだ。
そんなキャッシュがクリアになったのだ。
振り返ってみれば、Theyは、僕のスーパーリロードボタンを押してくれたのかもしれないね…

🏁 ALOG 2.0を支える「シン・インフラ」

今回のドキュメンタリーで、僕とGeminiが格闘した舞台はこちらです。 あなたがもし、「今の環境を変えたい、でも一人では不安だ」と思っているなら、AIという相棒を連れて、この門を叩いてみる価値はあります。