UNIX Cafe 第116回
はじめに：新しい土地への期待と、静かな予感
ブログやウェブサイトを運営していると、いつか必ず訪れるのが「サーバーの環境更新」という一大イベントです。
使い慣れたサーバーから、同じ「Xserver」内での最新環境へのアップデート。案内が届いた「新サーバー簡単移行」ツールを使い、今後数年間の快適な環境を確保するために「新サーバーへの移行」を行うことに決めたのです。
Xserverのアカウントパネルにログインし、サービスメニューの「新サーバー簡単移行」をクリック。対象のサーバーを選択し、「データコピー申請」を行う。マニュアルを見ると、これだけでファイルもデータベースも、すべてが新しい環境へと移行されるようです。
ユーザーは、データコピー申請をして、コピー完了のメールを待つだけです。一見、すべてが順調に進んでいるように見えました。しかし、デジタルな世界には時として、目に見えない「亡霊」が潜んでいるものです。それは、私たちが「公式ツールを使っているから安心だ」と思った瞬間に姿を現します。
エラーの発覚：謎の 「? 」マークが大量出現
申請から数時間が経過し、メールボックスに「データコピー完了」の通知が届きました。
私は楽しみ半分不安半分で、「動作確認」のステップに進みました。この段階ではまだ、世界中の読者が見ているのは旧環境のサイトですが、自分のパソコンのhostsファイルを書き換えることで、公開前に新しいサーバーの中身を確認することができます。
「早速、最新環境のスピードを体感できるかな？」
少しだけ期待して、新環境のサイトをリロードした私の目に飛び込んできたのは、予想だにしない光景でした。
無事に終わったと思った直後、特定のサイトのあちこちに不気味な 「? 」 という記号が大量に現れたのです。
記事のタイトル、本文の隙間、サイドバーのメニュー、そしてサイトマップのリスト…。昨日まで綺麗に整列していた日本語の文章の間に、まるでノイズのように、あるいは誰かのいたずらのように「?」が散らばっていました。
新環境への期待は、一瞬にして落胆へと変わりました。ブラウザのキャッシュを削除し、シークレットモードで開き直しても、その記号は消えません。それどころか、管理画面（ダッシュボード）の設定項目にまで、その「亡霊」は侵食していました。
「文字化け……？ いや、それにしては一部だけだし、公式ツールの移行でこの状態？」
私は一人、静まり返った部屋で、画面に浮かび上がる「?」と対峙することになりました。これが、私と1バイトの亡霊との、長い戦いの始まりでした。
迷走：解決の糸口が見えない、孤独なトライ＆エラー
混乱の中で、私は原因を突き止めるために、考えられるすべての原因を順番に潰していくことにしました。ここからが、終わりの見えない「迷走」の始まりでした。
1. キャッシュという「残像」との戦い
まず最初に疑ったのは、コンピュータの世界では「犯人」の常連であるキャッシュです。 ブラウザのキャッシュを削除し、WordPressテーマのキャッシュもクリア、シークレットモードで何度もリロードします。さらにXserver側のキャッシュをクリアします。 しかし、画面を更新するたびに、「?」たちはあざ笑うかのように同じ場所に現れ続けます。これはキャッシュの問題ではないのは明らかです。
2. 特定プラグイン「WP Sitemap Page」への疑惑
次に目をつけたのは、サイトマップの出力を司る「WP Sitemap Page」というプラグインでした。 なぜなら、今回の「?」というノイズが最も顕著に、そして大量に現れていたのが、このプラグインが生成するサイトマップのページだったからです。「このプラグインの出力処理が、新しい環境で異常を起こしているのではないか？」 試しに、管理画面から「WP Sitemap Page」を停止してみます。しかし、結果は空振りで、記事のタイトルやサイドバーに残った亡霊たちは、依然としてそこに居座り続けたままでした。
偽りの夜明け：テーマ変更で見えた「一瞬の光」
次に私は、 「WordPressのテーマが壊れたのではないか？」と考え、現在使用している「SWELL」というテーマから、WordPressデフォルトの「Twenty Twenty-Four」へと変更してみました。
すると、テーマを変更した瞬間に、あれほど執拗に現れていた「?」マークが、一瞬で消えたのです。
テーマを入れ直すか、設定ファイルを修正すれば解決する。そう考えた私は、一旦休憩に出かけます。
しかし、その期待も長くは続きませんでした。
昼食を終え、管理画面の中を確認すると、新たな問題が発覚しました。ブラウザの表示からは消えたはずの「?」が、ダッシュボードやブログパーツのタイトルの先頭に、依然として居座っていたのです。
テーマ変更で「?」が消えたのは、問題が解決したからではありませんでした。デフォルトテーマは、不適切なデータが潜んでいる特定のデータベース項目を読み込んでいなかったか、あるいは出力する際のフィルター処理が、偶然にもそのノイズを無視していただけだったのです。
根本的な原因は、テーマではなく、データベースの中に残っていたのです。
徹底調査：データの「生」の姿を暴く
エラーの原因は、フロントエンドではなく、データベースの中にある。 諦めた私は、データの状態を直接確認することにしました。
Xserverのファイルマネージャを使い、まずは設定の根幹である「wp-config.php」をダウンロードして覗いてみました。そこで私は、奇妙な記号を目にします。
# catコマンドでファイルの中身を確認
<?php^M
/**^M
* The base configuration for WordPress^M
...
各行の末尾に並ぶ ^M という文字。これは、Windows形式の改行コード（CR）が混入している証拠でした。
さらに、私はサーバーパネルから「phpmyadmin」にログインし、データベース（MySQL）の中身を「16進数（HEX）」で直接表示させてみました。
# タイトルの先頭をバイナリで確認
SELECT post_title, HEX(LEFT(post_title, 5)) FROM wp_2posts WHERE post_title LIKE 'Signal to Noise Ratio%';
そこで、犯人の尻尾を掴みました。0d (CR) という、本来そこにあるはずのないコードです。
コンピュータの世界には、「改行」という一見シンプルでいて、実は非常に厄介なルールが存在します。
- UNIXやLinux（Xserverなどの主流サーバー）: 改行は
0a(LF) ひとつ。 - Windows: 改行は
0d+0a(CR + LF) のセット。
どうやら、Xserverの内部でデータをコピーする過程で、何らかの原因により Windows 式の「余計な1バイト（CR）」が紛れ込んでしまったようです。それが日本語（マルチバイト文字）のすぐ隣に配置されてしまったため、ブラウザやサーバーのシステムが「この1バイトは何？ 読み方がわからないよ！」と混乱し、代わりの文字として「?」を表示していたのです。
マルチバイト文字（日本語）は、複数のバイトが組み合わさって一つの文字を形作っています。そこに本来存在しない
0dが割り込むと、文字の境界線が壊れ、ブラウザが「不正な文字」と判断して置換文字（REPLACEMENT CHARACTER）の?を出してしまうのです。
掃討作戦：11,930件の「はてな」を一掃する
原因はわかりましたが、問題はその規模でした。
この亡霊は、データベースの深層にある「設定項目」から「記事本文」、さらには「プラグインが保存した複雑なデータ」に至るまで、あらゆる場所に潜伏していました。その数 11,930件。
動作確認中に見つけたこの惨状。これをひとつずつ手作業で修正していたら、時間がいくらあっても足りません。
そこで私は、WordPressの管理を強力にサポートしてくれるツール wp-cli を活用することにしました。これは、データベースという広大な森の中から、特定の「雑草」だけを見つけ出して、根っこから引き抜いてくれるようなツールです。
ただし、1万件を超えるデータを一気に書き換えるという「破壊的」な操作を行う前に、まずは現状のデータベースを丸ごとバックアップ（wp db export）し、万が一の際の命綱を確保します。
まずは設定ファイル（options）から、42個の改行コードの亡霊をパージ。そして次に、本丸である記事データ全域に対して、一撃を加えます。
# データベース全域から「? 」を物理的に削除する
wp search-replace '? ' '' --all-tables
この一行を実行した瞬間、画面には次々と「置換完了」のメッセージが流れました。
ブラウザをリロードすると、「?」マークが消えていました。
元のテーマに戻しても、どのページを開いても、「?」たちは、跡形もなく消え去っていました。11,930件の亡霊は、一瞬にしてパージされたのです。
WordPressの
optionsテーブルなどは、データが「シリアル化」という特殊な形式で保存されていることが多いので、ただの SQL（UPDATE ... REPLACE）で書き換えると、文字数がズレてデータが壊れてしまうけど、wp-cliはそこを賢く処理してくれます。
おわりに：一人のユーザーが学んだ「1バイトの重み」
今回の騒動は、改行コードという、普段は意識することすらない「道路の標識」がひとつ狂うだけで、最新のサーバーであっても情報の流通が阻害されてしまうことを教えてくれました。
私はプロのエンジニアではありません。しかし、自分のサイトを守るためにデータの裏側に触れたことで、多くのことを学びました。
- 公式ツールでも「絶対」はない： 便利ですが、今回のように環境の差異でゴミが出ることもあります。
- 「テーマを変えて直った？」： それは単に問題が見えなくなっただけの「偽りの夜明け」かもしれません。
- バイナリ（生のデータ）は嘘をつかない： 目に見える現象に惑わされたら、データの原点に立ち返ること。
「1バイトのズレも許さない」
コンピュータの世界の厳格なルールを守ることは、一見窮屈に見えるかもしれません。でも、そのルールがしっかりしているからこそ、私たちは言葉を、思いを、自由に世界へ届けることができるのです。
無事にサーバー切り替えを終え、以前よりも格段にレスポンスが良くなったサイトを見つめながら、私は思いました。この快適さは、目に見えない無数のルールと、それらを正しく整えようとする意志の上に成り立っているのだと。
もし、あなたの新しいサーバーに「?」という名の亡霊が現れたら、思い出してください。それは、最新の環境があなたに送った「データを綺麗にするチャンスだよ」という、静かなサインかもしれません。
今回の対応ログ：2026-04-03
状況: Xserver「新サーバー簡単移行」利用後、動作確認中にサイト全域で「? 」が発生。
経過: キャッシュ削除、プラグイン「WP Sitemap Page」の停止を試みるも効果なし。テーマ変更で一時的に「?」
が消失するが、根本原因はDB内のデータ汚染（11,930件）と判明。
原因: データのコピー工程で Windows 式の改行コード（CR）が混入。これが日本語の表示を汚染。
解決: wp-cli を用い、データベース内のシリアル化された構造を維持しつつ、11,930 件の不要データを一括削除。
教訓: 公式ツールであっても、最後は自分の目で、そしてデータの裏側まで確認することの大切さを、この
11,930件の亡霊たちが教えてくれました。＊P.S. Xserver の簡単移行は、Linux からLinuxへの移行のため、Windows環境を跨いている訳ではありません。
P.S. なぜ Linux 同士の移転で Windows の影が忍び込んだのか？
最後に、１人の UNIX ユーザーとしての技術的な好奇心から、今回の「亡霊」の正体について少し考えてみます。
Xserver の移行は Linux から Linux への環境移動であり、本来 Windows を跨いでいるわけではありません。それなのに、なぜ 0d (CR) という Windows 特有のコードが紛れ込んだのか。
可能性として高いのは、過去に利用していたWindows10の環境で、テキストエディタを使ってファイルを編集したり、プラグインの設定を保存したりした際、何らかの拍子にこの「1バイト」が混入し、それがデータベースの奥底で静かに眠っていたというシナリオです。
それが今回、移行ツールの「厳格なデータコピー」という工程を通ったことで、これまで表面化していなかった潜在的なゴミが、新しい環境の光に照らされて一気に可視化されたというのが真相かもしれません。
これはツールの不備というより、「長年隅っこで眠っていた小さな埃が、最新の高性能な掃除機（新サーバー）によって一気に舞い上がった」ようなもの。デジタルな引越しで見つかった、少しだけ厄介で、どこか不思議な「忘れ物」だったというわけです。
