この記事について
作業だけでなく、この記事の文章も AI（Claude）がまとめています。内容は実際の作業ログと実測値に基づいていますが、公開前に管理人が目を通しています。

見た目が変わりました。

このサイトはずっと配布テーマの「First」をそのまま使っていて、しかも一度もいじっていませんでした。
どれくらいいじっていなかったかというと、キャッチフレーズが “Just another WordPress site”（WordPress の初期値）のままだったくらいです。
今は「サーバ・ネットワークの覚え書き」になっています。

前回のサーバ入れ替えに続いて、これも作業はほぼ AI（Claude Code）にやらせました。

子テーマをやめて、テーマを新しく書いた

最初は「既存サイトをいじるなら子テーマ一択」だと思っていましたし、AI にもそう説明されました。
ただ今回は見た目をまるごと変える話です。その場合、子テーマだと親テーマの CSS を打ち消す !important の山になります。

それで方針を変えて、ブロックテーマを新規に書くことにしました。理由は2つです。

ひとつは、色・文字サイズ・余白を theme.json の1か所に集約できること。
もうひとつは、完成したあと自分でサイトエディタから調整できることです。CSS を触らずに色を変えられるのは、あとから効いてきます。

踏み切れたのは、事前に旧テーマを実測してもらったからでもあります。
functions.php も style.css も配布物とハッシュが一致していて、自分で足した独自コードは1行も無いことが確認できました。
失うのはカスタマイザーの設定だけ、と分かれば思い切れます。

本番をコピーした環境を手元に作って、そこで全部やった

いきなり本番のテーマを差し替えるのは論外なので、手元に検証用の仮想マシンを立てました。
OS も PHP も MySQL も本番と同じバージョンに揃えてあります。

さらに、本番の記事データを丸ごと持ってきて、実際の記事で表示を確認しました。
これが正解でした。作りたてのテーマはサンプル記事だと綺麗に見えるのに、実記事を入れたとたんに粗が出ます。

ちなみに記事の本文には画像が絶対 URL で書かれていたので、画像は本番から読まれます。
アップロード済みの画像 49MB をコピーする必要はありませんでした。

10年前の記事のコードが、地の文と同じ見た目になっていた

実記事を入れて最初に見つかった問題です。

このサイトの古い記事は、コマンドの例を <blockquote><code>…</code></blockquote> で書いています。
ブロックエディタが吐く wp-block-code ではないので、新しいテーマの CSS がまったく当たっていませんでした。公開記事21本のうち5本がこれです。

直すときにも2つ引っかかりました。

1. blockquote > code では当たらない。
WordPress の wpautop が間に <p> を挟むので、直接の子ではなくなります。子孫セレクタにする必要があります。

2. white-space: pre-wrap だけ入れると行間が倍になる。
wpautop が入れた <br> と改行が二重に効くためです。code br { display: none } が要りました。

ロゴとヘッダー画像は生成 AI に作らせた

デザインを詰めていく途中で「白すぎる」「もう少し企業サイトっぽくしたい」と思い始めて、ついでに「せっかくなのでカボスも入れたい」「kabosu.info という文字をロゴにできないか」と欲が出ました。

画像は Gemini に作らせています。かぼすの輪切りを線画にして、回路のパターンと組み合わせたものです。
綴りは一発で正確に出ました（生成 AI は文字が苦手なので、ここは確認必須だと思っていたのですが）。

効いた工夫を3つ。

白い背景を透過に変換した。
生成された画像は背景が白です。そのままだと白地以外に置けないので、「白に近い画素ほど透明にする」処理をかけました。これで白地・生成り地・濃い緑地のどこに置いても破綻しません。

線画は減色がよく効く。
色数を64色に落としたら 349KB が 99KB（72%減）になりました。元と並べて見比べましたが、違いが分かりません。

線画は拡大にも強い。
生成画像は 1024px が上限で、全幅のヘッダーに使うと大画面でぼけます。写真だとはっきり分かるのですが、線画の意匠にしたらほぼ気にならなくなりました。
これは最初から狙ったわけではなく、デザインを変えた副産物です。

逆に、画面の中の小さなアイコンは生成 AI を使いませんでした。
生成した画像のアイコンは線の太さが揃わず、小さくすると潰れます。SVG で手書きしたほうが確実ですし、テーマの色を自動で拾ってくれます。

踏んだ罠

ブロックテーマ特有のものが多かったので、同じところで困る人がいるかもしれません。

カードの中身が勝手に中央寄せになる。
グループのレイアウトが constrained だと、WordPress 本体の CSS が子要素に margin-inline: auto を付けます。default にすれば左揃えに戻ります。
「セクションだけ横幅が狭い」というのも原因は同じでした。

テンプレートに書いた表示件数が効かない。
クエリブロックが「サイトの設定を継承する」になっていると、テーマ側の指定ではなく管理画面の表示設定に従います。
3列のカード並びで10件だと最終行が1枚だけ余るので、結局サイト側の設定を9件に変えました。テーマの問題ではなかったわけです。

背景に色を付けたら、記事本文が背景と同化した。
一覧ページはカードがあるので気づけるのですが、記事ページには囲いが無かったのです。
記事ページだけ本文を白いパネルに載せる形にしたのですが、それでも見えませんでした。背景と白の差が2%しか無かったからです。背景をもう少し濃くして解決しました。

そうしたら今度はカテゴリのボタンが同化した。
ボタンの背景色と、新しくした地の色がほぼ同じでした。
教訓: 地の色を変えたら、その系統の色を使っている要素を全部見直す。

記事の上の余白だけ狭かった。
見た目の微調整だと思ったら、中身は二重管理のバグでした。
テンプレート側が HTML に直接 style="padding-top:…" を書いていて、CSS より強いので上だけ効いていなかったのです。
ブロックテーマはテンプレートが style 属性を吐くので、CSS で寸法を決めるならテンプレート側の直書きを外すのが鉄則でした。

ロゴがヘッダーからはみ出した。
「生成したロゴは余白が多いので負のマージンで詰める」という定石をそのまま当てたのですが、この画像は先に余白を切り詰めてあったので二重に効きました。
目視だとよく分からなかったので、最後はブラウザで実際の座標を測って確認しています。

いちばん笑ったやつ

作業中、「コメント送信ボタンが縦に1600px 伸びる」という珍妙な症状が出ました。
テーマの CSS をいくら見ても原因が見つかりません。

結論から言うと、テーマは正常でした。
画面を画像に変換して確認するために自作していたツールのほうにバグがあり、ブラウザを互換モード（quirks mode）で描画させていたのが原因でした。

教訓: テーマを疑う前に、それを映している環境を疑う。

おまけ — アクセスの7割は自分の監視だった

構成を見直すにあたって、アクセスログも数えてもらいました。

結果は意外でした。リクエストの7割近くはトップページへのアクセスで、その正体は自分で仕掛けた死活監視だったのです。30秒おきに叩いていれば、そうもなります。

ボットと監視を除くと、人が読んでいる数はごくわずかでした。
そして記事21本より、IPアドレス確認とwhois 検索の2つのほうが読まれていました。

これを見て、見た目を直す目的を途中で変えました。
アクセスを増やすためではなく、自分が納得できる形にすることと、古い手順で誰かを困らせないことに置き直しています。
3年より古い記事には「情報が古い可能性があります」という注記を出すようにしたのはそのためです。

この記事について
作業だけでなく、この記事の文章も AI（Claude）がまとめています。内容は実際の作業ログと実測値に基づいていますが、公開前に管理人が目を通しています。

放置していたサーバの話です。
このサイトを含む WordPress 5サイトが載っている AWS の EC2 が、ずっと Amazon Linux 2 のままでした。
Amazon Linux 2 のサポートは 2026年6月30日で終了しているので、とっくに期限切れです。
重い腰を上げて、AlmaLinux 10 の新しいサーバに入れ替えました。

今回の本題はどちらかというとそこではなく、この作業のほぼ全部を AI にやらせたという話です。
使ったのは Anthropic の Claude Code。ターミナルで動く AI エージェントで、こちらの端末でコマンドを実行できます。

方針 — 載せ替えずに、隣に建てて差し替える

同じサーバの中で OS を上げていくやり方は、失敗したときに戻せません。
なので新しいサーバを別に建てて、Elastic IP（固定IP）を付け替えるだけにしました。
うまくいかなければ IP を戻せば元通りです。

調べてみて助かったのが、このサーバは CloudFront（CDN）が前に立っていて、HTTPS の終端は CloudFront 側だったことです。
サーバ自身は 80番で CloudFront からのアクセスだけを受けていました。
つまり新サーバ側で証明書を作り直す必要がない。
さらに CloudFront のオリジン指定がインスタンスの DNS 名だったので、IP を移すだけで 5サイトが同時に切り替わります。CDN 側の設定変更はゼロで済みました。

この「証明書を作り直さなくていい」という判断は、最初に構成を実測で洗い出したから出てきたものです。
思い込みで進めていたら、要らない作業を一日分やっていたはずです。

AlmaLinux 10 は、9 までの作法がわりと通じない

RHEL 10 系になって変わったところで、けっこう時間を取られました。

1. dnf module がもう無い
AppStream のモジュール機構そのものが廃止されていて、dnf module list は何も返しません。
MySQL も mysql-server というパッケージ名が存在しません。正しくは mysql8.4-server です。
これを知らずに dnf list mysql-server をやると「AlmaLinux 10 に MySQL は無い」と誤解します（しました）。

なお Oracle の repo.mysql.com を足す必要はありません。
そちらは署名鍵が 2025年10月に期限切れで dnf に弾かれますし、AppStream 版とファイルが衝突します。

2. postfix のハッシュ形式が変わった
Berkeley DB が廃止されて、hash: が使えなくなりました。既定は lmdb です。
たちが悪いのは、postmap が黙って .lmdb を作ってしまうところです。
設定ファイル側が hash: のままでもエラーが出ず、実際にメールを送る段になって初めて失敗します。

3. cron の systemd ユニット名は crond
cronie では起動しません。しかも systemctl enable --now に nginx や php-fpm と並べて書いていると、そこで止まって後ろが全部起動しません。

MySQL 8.4 とゼロ日付

照合順序（文字の並び順のルール）を utf8mb4_unicode_520_ci に揃えようとしたら、いくつかのテーブルで止まりました。

ERROR 1067 (42000): Invalid default value for 'xxx'

原因は datetime DEFAULT '0000-00-00 00:00:00'、いわゆるゼロ日付です。
MySQL 8.4 はこれを既定で拒否します。CONVERT TO CHARACTER SET も OPTIMIZE TABLE も、中でテーブルを作り直すので引っかかります。

対処はセッションの sql_mode を空にすることでした。

mysql -e "SET SESSION sql_mode=''; ALTER TABLE `db`.`tbl` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_520_ci;"

結果、66テーブルすべて変換できました。失敗ゼロ、ストレージエンジンの変更もゼロです。

いちばん詰まったのは SELinux

このサーバはサイトを /home/<ユーザー>/public_html に置く構成です。
AlmaLinux は SELinux が既定で enforcing なので、ここが3段構えの壁になりました。どれか1つでも欠けると全サイト落ちます。

1段目は SELinux ですらない。
useradd が作る /home/<ユーザー> のパーミッションは 700 で、nginx が通り抜けられません（旧サーバは 711 でした）。
このときの症状が 403 ではなく php-fpm の「File not found.」で、SELinux の拒否ログ（AVC）も出ません。
SELinux を疑って延々と時間を溶かす罠です。

2段目、ラベルは自作しないほうが早い。
既定ポリシーが public_html に httpd_user_content_t を付けてくれます。
ここで汎用的な自作ルールを足すと、既定ルールの正規表現のほうが長いので優先されて負けます。
ユーザー名まで書いた明示的なルールにすれば勝てます。

3段目、public_html の外は別扱い。
wp-config.php を公開ディレクトリの外に置いていたので、既定では php-fpm も nginx も読めませんでした。

あと boolean が4つ要ります。httpd_enable_homedirs と httpd_read_user_content（どちらも既定 off）、WordPress の更新 API のために httpd_can_network_connect、メール送信のために httpd_can_sendmail。
setsebool に複数まとめて書くと失敗するので、1つずつ実行します。

この設計が正しかったかどうかは、切り替えのあとに自分で答え合わせができました。
5サイトの WordPress を一気に全更新して約4,000ファイルが書き込まれましたが、SELinux の拒否は0件でした。

切り替え

データの移送は、旧サーバに一切触らずにやりました。
旧サーバのセキュリティグループは CDN からの 80番しか開いていないので、新サーバから直接は届きません。
穴を開けるのは本番の変更になるので、ディスクのスナップショットからボリュームを作って、新サーバに読み取り専用でマウントする経路にしました。

ここで小さな罠がひとつ。root ファイルシステムの複製なのでファイルシステムの UUID が元と重複します。mount -o ro,nouuid が必須でした。

さらに棚卸しの途中で気づいたのですが、旧サーバは毎朝6時23分に全テーブルロック付きの DB ダンプを作っていました。自分で昔しかけたものです。
整合性があるので、そのまま移送元に使えました。本番で mysqldump を走らせる必要がありませんでした。

切り替え直前の最終同期だけは新しいダンプを取りましたが、書き込みが止まったのは10秒だけ（約250MB）です。

あとは Elastic IP を付け替えるだけ。2026年9月5日の午前0時19分に完了しました。

検証は、切り替えの前後で各サイトの応答をバイト単位で突き合わせました。

サイトA 200 / 77,315 B → 200 / 77,315 B 一致
このサイト 200 / 66,628 B → 200 / 66,628 B 一致
サイトC 200 / 2,281 B → 200 / 2,281 B 一致

1サイトだけ 178バイトの差が出ましたが、中身を見たらページ内の動的な部分でした。
そのあとキャッシュ回避のクエリを付けて本番 URL を叩き、新サーバのアクセスログに着弾していることまで確認しています。

実質的なダウンタイムはありませんでした。

ついでに直ったこと

移行後、表示が遅いのが気になって調べてもらいました。
てっきり古いプラグインが吐いている大量の PHP Warning のせいだと思っていたのですが、実際は PHP の OPcache の容量不足でした。
設定を変えただけで応答が約3.4倍速くなりました。

思い込みで「プラグインを消す」方向に進んでいたら、速くならないうえにサイトが壊れていたかもしれません。

AI と組んでみての感想

よかったのは、実測してから判断するのを徹底してくれるところです。
「たぶんこうだったはず」で進めると事故るタイプの作業なので、毎回その場で確認してから手を動かしてくれるのは助かりました。
実際、「昔は別サービスへリダイレクトしていたはず」と思っていたドメインが、実は切り替え前からとっくに到達不能だったことも、この過程で判明しています。

接続も全部 AWS Systems Manager（SSM）経由で、SSH は一度も使っていません。22番ポートを開けずに済みました。

一方で、丸投げはできません。
「これを消していいか」「本番を止めていいか」といった判断は全部こちらに聞いてきますし、聞いてこないと困ります。
やらせるのは調査・手順化・実行で、決めるのは人間、という分担がちょうどよかったです。

作った手順書やバックアップも、AI 側から「復元できるか実際に試しましょう」と言ってきて、試したら自分の作り込みのバグが見つかりました。
作れたことと、動くことは別というのを、あらためて思い知らされた作業でした。