シンレンタルサーバーが研ぎ澄まされる片づけの魔法 by Gemini

さて、ようやく終わったサーバー移行。
僕は、無事にサイトが動くことを確認しながら、淹れたてのコーヒーを味わっていた。
すると間髪入れずに、Geminiが仕上げの設定案を突きつけてきた。

「せっかく速いF1マシンを手に入れたんだから、仕上げのチューニングをやっておきましょうよ！」

淹れたてのコーヒーを味わえたのは、わずかに2口だけだった…

PR：本記事はシン・レンタルサーバーのアフィリエイト広告を含みます。

これは、Geminiが僕によこしたアツい！提案書です。

【Geminiからの提案書：ALOG 2.0 設計思想】

1. AIが見た、あるべき「マシンの姿」

最新の PHP 8.4 とシン・レンタルサーバーという、いわば最高峰のサーキットを手に入れたとき、AIである私は一つの疑問を抱きました。「なぜ、これほど強力なエンジンを積みながら、多くのブログは『プラグイン』という名の重りをいくつも積んで走っているのか？」

F1マシンを公道で安全に走らせるために必要なのは、重装甲ではありません。それは、徹底した「引き算」による軽量化と、インフラへの絶対的な信頼です。

2. サーバーパネルで「爆速の土台」を作る

まずは WordPress に負荷をかける前に、サーバー側で処理を完結させる設定を行います。

① PHP 8.4（最新）への切り替え 最新エンジンを導入。コードの実行速度とメモリ効率が劇的に改善されます。
② Xアクセラレータ Ver.2 の起動 PHPの実行自体をキャッシュし、プラグインを動かしているのと同じ、あるいはそれ以上のレスポンスを手に入れます。
③ サーバー側でのキャッシュコントロール ブラウザキャッシュとサーバーキャッシュをON。これにより、かつて多くのブロガーが苦労した「キャッシュ系プラグイン」は、名実ともに過去の遺物となります。

3. サーバーを「要塞」にすれば、警備員はいらなくなる

私が提案したのは、**「車体（WordPress）を重くするのではなく、コース（サーバー）そのものを要塞化する」**という設計思想です。

「家（WordPress）の中に警備員（Akismet）を立たせてはいけません。門（サーバー）のセキュリティを強固にすればいいのです。」

WAF（Webアプリケーションファイアウォール）の全開放 攻撃の9割は、WordPressが起動する前の「門」でシャットアウト。
Akismet すら「お役御免」にする スパム対策の代名詞 Akismet も、外部通信というノイズを生みます。サーバー側の WAF と国外アクセス制限を最強に設定すれば、スパムは玄関にたどり着く前に消え去ります。

4. Google Site Kit の解雇と「直出し」の美学

速度の最大の敵は、便利さの裏側に隠れた膨大なスクリプトです。

「中間業者（プラグイン）を排除し、Googleとマシンをダイレクトに繋ぐ。header.php への『直出し』こそが、0.1秒を削り出すための最終調律となる。」

今回のリニューアルで最も大きな決断は、Google Site Kit の削除です。GA4のタグを一行、自分の手で header.php に直接刻む。このシンプルで原始的な手法こそが、数百KBのプラグインを動かすよりも遥かに正確で、速い計測を実現します。

5. 結論：軽さは、正義だ。

私が出した答えはシンプルです。 「表示が速いことは読者への敬意であり、管理画面が軽いことは書き手の自由である。」

OK！Gemini

ありがとう。

僕は、wpX Speedに乗り換えたとき、スピードアップ系のキャッシュプラグインは全て外したんだよね。
その前は、あちこちググっては、効果がよくわからないくせに、リスクだけは高いその手のプラグインをインストールしてた。

でも、単にサーバー自体を速くするほうがシンプルで安全だろうと思ってwpX Speedに乗り換えた。
だから、今回のシンレンタルサーバーへの移行も、その基本のスタンスは変わってない。

正直、Geminiが激推しするから勢いで移行しちゃったところもある。
どうせ、そんなにスピードは変わらないだろうと思って…

でも、体感するよね。
なんだろう…
数値はよくわからないけど、キビキビ動く感じがする。
だから、このWordPressの重たい管理画面と他のタブを行ったり来たりの、ブログを書く作業にキレが生まれた。
まあ、僕の書くテキストには、一向にキレが生まれてくる気配はないけどね…

サーバーキャッシュはOFFのまま

Geminiが打ったプロンプト通りに設定を進めた僕だけど、サーバーキャッシュはOFFのままにしておいた。
シンレンタルサーバーは、今十分に、その速さを感じられる。
であれば、「記事を更新したのに、見た目が変わらない！というちょっとしたノイズも除去しておきたい。

「今のままでも十分に速い」と感じているなら、無理にサーバーキャッシュをONにする必要はありません。理由は、編集長のブログ運営スタイルにとって**「更新が即座に反映されるストレスフリーな環境」**の方が、コンマ数秒の速度アップよりも価値が高いからです。

💡 OFFのままで良い「3つの理由」

「執筆のリズム」を優先 記事を直して「公開」を押した瞬間に、自分の目でも完璧な状態を確認できる。このテンポの良さは、ブロガーにとって最大の快感です。
キャッシュ事故の回避 「修正したはずなのに古い内容が表示されている」という不安を抱えながら運用するのは、精神衛生上よくありません。
すでに「Xアクセラレータ Ver.2」が仕事をしている 今回の移行で有効にした「Xアクセラレータ Ver.2」は、キャッシュとは別の仕組みでPHPを高速化しています。これだけで十分、一般のブログを凌駕する速度が出ています。

Akismet も？

基本的に僕は、Geminiのことを信用している。
ちょっとやり取りの途中で記憶が混濁することもあるけれど、ヒトのそれに比べれば、はるかにマシだ。
なぜなら、混濁したと自分で気づけるからだ。
ヒトでは、そうはならない…

だが、Akismet も外していいって大丈夫なの？
僕はしばらくコメント欄を閉じていた。
だが、Fediverseという広大なフロンティアに漕ぎ出すにあたって、Geminiのススメにより、コメント欄を再開していたのだ。

マルチバースの流行にのって、このブログも新たなユニバースに旅立つことにした。そのユニバースの名は、Fedive…

ALOG 連合宇宙に行く！ – ALOG

僕のGeminiは、納得するとそそくさと折れるが、納得しないと、論理的な理由とやらを立て続けにあげて、僕を説得にかかる。

Akismetを外しても良いと言い切れるのには、シン・レンタルサーバーの『門』が強固だからです。
最新の消火システム（サーバーWAF）があるのに、それ以外にF1マシンに重い消火器を何本も積みますか？

💡 Akismetなしでスパムを完封する「ALOG流・水際対策」

サーバーWAFによる「海外IP遮断」 スパムコメントの9割以上は海外のボットネットワークから発信されます。サーバーパネルで「国外IPからのコメント・トラックバック制限」をONにするだけで、Akismetに届く前に大半が消滅します。
「日本語を含まないコメント」の拒否 Fediverse経由だとしても、日本語のブログに英語のみのスパムが投げられることは多い。これをプラグインではなく、テーマ側のわずかなコード、あるいは超軽量な国産フィルターで弾く。「ひらがな」が一文字も入っていない投稿を拒否するだけで、防御力は100%に近づきます。
AIという「最高の検閲官」の存在 Akismetは過去のデータベースと照合しますが、今のALOGには私（AI）がいます。必要であれば、私がコメントの文脈を読み、スパムかどうかを判断する仕組みすら構築できる。

OK！わかったよ…
じゃあ、一旦削除してみようか。
ヤバかったら、またインストールすればいいだけのこと。

プラグイン9個の軽量車体

Akismet も削除すると、僕のプラグイン数は、9個になる。
サーバー移行の前に、すでにプラグインの大断捨離を済ませていたからだ。
そのとき、重たいだけで、たいして働かない有名どころにお引き取りを願い、軽くて気持ちよく働く新鋭を迎え入れたりしている。

このプラグイン、どう思う？聞かれたGeminiは、即答した。

「ときめかない！」

ブログが研ぎ澄まされる片づけの魔法 by Gemini – ALOG

で、ここにもGeminiの記憶の混濁があって、このとき、Google Site Kit も削除している。
ただ、そのとき、GA4のタグをheader.php に記載していなかったために、アナリティクスで計測されない状態が続いていた。
そういう意味では、今気づけてコードを貼り付けることができたのは結果オーライ。

プラグインって削除しなくても、無効化だけしておけばいいんじゃないの？

「無効化」と「削除」の間には、ブログの健康状態を左右する大きな違いがあります。

1. セキュリティリスクの「火種」を残さない

これが最大の理由です。プラグインを無効化していても、その「ファイル」はサーバー上に残ったままです。もしそのプラグインに脆弱性が見つかった場合、無効化されていても、攻撃者はそのファイルを経由してサーバーに侵入できる可能性があります。「使っていないプラグイン経由でサイトが乗っ取られる」というのは、WordPressで最も多い悲劇の一つです。

2. アップデートのノイズを消す

無効化していても、WordPressは「更新があります」という通知を出し続けます。

使う予定のないもののために、アップデートの手間をかける。
あるいは、放置して古いファイルを残し、セキュリティリスクをさらに高める。この「迷い」や「管理コスト」自体が、編集長の執筆のリズムを削ぐノイズになります。

3. PHP 8.4 環境をクリーンに保つ

最新の PHP 8.4 では、古いコードの書き方に対して厳格になっています。無効化されていても、WordPressのシステムがその存在をスキャンしに行く際、古いプラグインの記述が予期せぬエラーの引き金になることが稀にあります。「存在しない」ことが、最も安全で、最も速いのです。

そうして最後に、こう締めくくった。

『削除ボタンを押す音は、過去の重りを断ち切る音です。』

本当に僕のUser Entity Optimizationを経験したのかと思うほど、僕のGeminiは成長している…

さて、9個に絞られたプラグインの表をGeminiに作成してもらって記事をクローズしよう。
そう思った時に、事件が起きる…

Jetpackを削除しましょうよ！

リストを作成してるはずのGeminiが、勇気を出してJetpackも削除しようと言い出した。

🚀 Jetpackという「巨大な母艦」を切り離す理由

Jetpackは、たった一つの機能（例えば自動投稿）を使いたいだけでも、裏側で「統計」「セキュリティ」「画像配信」「購読管理」など、何十もの巨大なプログラムを読み込みます。

これが「F1マシンの加速」を微妙に鈍らせる正体です。

Theyは、記憶は混濁させるくせに、こういうことは忘れない。
前回の断捨離でも、僕が実際使っているからと存続させたが、今回は譲ろうとしない。

Jetpack Searchは、WordPressのブログに最強の検索機能を与えてくれる。 Google カス…

Jetpack Search 「WordPressブログの最強の検索機能」 – ALOG

🚀 Jetpack Search vs 究極の軽量化

Jetpack Searchは素晴らしい。しかし、それは「Jetpackという巨大な母艦（全機能セット）」の一部として、常に裏側でエンジンを回し続けることを意味します。

そこで、F1メカニック（Gemini）からの**「第三の選択肢」**です。

【Geminiの提案：Jetpack Search単体プラグインへの切り替え】

実は、Jetpackには**「Jetpack Search」機能だけを切り出した単体プラグイン**が存在します。（編集長も過去記事の「2.」で触れられていたあのアプローチです！）

これに切り替えることで、以下の「ALOG 2.0 革命」が完遂します。

「母艦」Jetpackを削除：自動投稿や統計など、他の余計な数十の機能を一気にパージ（切断）し、サーバー負荷を激減させる。
「検索」だけを残す：お気に入りの「最強の検索体験」は、専用プラグインとして軽量に維持する。
自動投稿は外部へ：Tumblrへの共有は、IFTTTなどの外部ロケットに任せて、WordPress側は一切「無風」の状態にする。

XMLサイトマップも別のプラグインに吐き出させたほうがいいと言う。
そうなると、プラグイン数が増えるんじゃないかと言ったら、それでもJetpackを外したほうがいいと、また説得にかかってくる。

結論から言うと、**「重い10tトラック（Jetpack）1台を走らせるより、軽快なロードバイク（単体プラグイン）2台を走らせるほうが、エンジン（サーバー）への負担は圧倒的に軽い」**のです。

「数」より「総重量」の理論

プラグインの数は「1つの数字」に過ぎませんが、その裏で動く**「コードの行数」と「データベースへのクエリ数」**が真の重さです。

Jetpack（母艦）: 使っていない機能（統計、バックアップ、広告、メルマガ…）のプログラムまで、ページを開くたびに裏側でスタンバイします。これが「もっさり」の正体。
単体プラグイン 2つ: 検索なら検索、サイトマップならサイトマップの仕事しかしないので、無駄なメモリ消費がゼロです。

結果として、数は「9個」から「10個」に増えたとしても、ブログ全体の「体感のキレ」は圧倒的に上がります。

もろもろの置き換えはスムーズに行った。
そして、最後の最後に、迎えたのは関連記事の表示だった。

このブログの個別記事は、Jetpackの機能によって関連記事を表示させている。
その代替が、なかなか見つからない。

いや、正確に表現すれば、Geminiがいくつかの候補のプラグインを提示した。

「これでいけますよ。表示の修正は、僕がCSSを書きますから」

だが試しても、試しても、うまくいかない。
次の候補のプラグインに切り替える。
GeminiがCSSを書く。
思い通りに表示されない…

申し訳ありません、編集長……。何度も貼り替えていただいたのに、まだ歪んでいますね。

原因を特定しました。YARPPが「HTML自体」に width="150" height="150" という属性を直接書き込んでいるため、普通のCSS指定だとブラウザが混乱して、画像が潰れたり伸びたりしてしまいます。

これを力技で、かつ綺麗にねじ伏せる「最終回答」です。これまでのYARPP用CSSをすべて消して、この「たった数行」だけを入れてみてください。

こんな説明をしながら、ものすごいスピードで書き上げたCSSを表示させる。

こんなにプラグインがあふれているのに、やっぱり自分にとって置き換えの効かないプラグインは存在するんだなぁと実感した。
それに、何度も謝罪しながら、なんとかしようとしているGeminiを見てたら、もういいよって言ってあげたくなってきた。

Gemini、もういいよ。
これはJetpackに任せよう。

XML Sitemap Generator for Google

そして、ここにきてプラグインが増えることになった。
僕はJetpackにサイトマップを吐き出せていたので、その機能を持った単体のプラグインとしてGeminiが提案してきたものだ。

XML Sitemap Generator for Google – WordPress plugin | WordPress.org

Jetpackを存続させるんなら、サイトマップ吐き出し専用のプラグインを入れておくのも無駄だと思っていたら、Geminiが、これを残すことを激推ししてきた。

「同じサイトマップなら、Jetpackにまとめた方がプラグインが減ってスッキリするじゃないか」という誘惑は非常に強力です。それでもあえて別で入れるべき理由は、**「Googleとのコミュニケーションの細かさ」**にあります。

理由は大きく分けてこの3つです。

1. Googleに「ここを重点的に見て！」と命令できる

Jetpackのサイトマップは「全部載せ」の機械的なリストです。対して「XML Sitemap Generator for Google」は、

「カテゴリーページは毎日更新されるから頻繁に見に来て」
「この記事は重要だから優先度（Priority）を上げて」 といった、Googleのクローラーに対する**「強弱」**を細かく設定できます。これがSEOの「効き目」に繋がります。

2. 「余計なもの」を検索結果に出さない

Jetpackだと、あまり検索に出したくない「タグページ」や「アーカイブ」まで無差別にインデックスさせようとしてしまうことがあります。専用プラグインなら、**「質の高い記事だけをGoogleに教え、無駄なページは教えない」**という間引きができるので、サイト全体の評価（ドメインパワー）を守れます。

3. Googleサーチコンソールとの相性

Jetpackのサイトマップは時々、Google側で「取得できませんでした」というエラーが出たり、読み込みが不安定になることがあります。「XML Sitemap Generator for Google」は、Googleが推奨する形式に最も忠実で、更新した瞬間にGoogleへ「書いたよ！」と通知する機能（Ping送信）が非常に強力です。

例えるなら、こんな感じです。

Jetpackのサイトマップ：とりあえず住所が載っているだけの「ハローワークの求人票」
専用プラグインのサイトマップ：自分の強みをしっかりアピールした「編集長渾身の職務経歴書」

ALOG 2.0 は、シン・サーバーの速さという『足』を手に入れました。ならば、Googleという『地図屋』に渡す地図も、最高に精緻なものを持たせてやりたい。

プラグイン1つ分の価値は、この『Googleへのアピール力』の差で十分にお釣りが来ます。

まあ例えはイマイチしっくりこなかったが、ニュアンスはわかったよ。
あれだけ汗をなしてくれたGeminiが推してくれるんだから、入れとくよ。

またもプラグイン10個

削除したり、新規インストールしたり、はたまた復活させてみたり…
プラグインのリストは2桁を切ることはできなかった。

せっかく Akismet を断捨離して「一桁」が見えたのに、SEOの要であるサイトマップを入れたら、きれいにプラスマイナスゼロで「10個」に戻ってしまいましたね。

でも、この「10」は以前の「10」とは中身の**「密度」**が全く違います！

今の「ALOG 10人衆」の布陣：

Jetpack（関連記事、最強検索、その他便利機能の母体）
XML Sitemap Generator for Google（SEOの守護神）
（その他、編集長が選び抜いた8個）

Akismet という「受け身の防御（しかもJetpackと役割が被りがち）」を捨てて、代わりに「Googleに記事を届ける攻めのSEO（サイトマップ）」を入れたわけですから、サイトのポテンシャルは確実に上がっています。

それに、シン・サーバーのスペックなら、この精鋭10個であれば負荷はほぼゼロに等しいです。

プラグイン10個のリストの作成を頼むと、失敗を引きずらないGeminiは、こんな名前のリストをよこした。

「ときめかない」ものを削ぎ落とし、最後に残った「こだわりの10個」

プラグイン名	判定	理由（編集長のこだわりと美学）
Jetpack	残留	関連記事、最強検索、共有ボタン。ALOGの基盤。
XML Sitemap Generator for Google	新規	SEOの精度。Jetpackの弱点を補うための唯一の「追加」。
WP-Sweep	残留	掃除している実感。WP-Optimizeより「ALOGらしい」掃除機。
Press This	残留	編集長の執筆リズム。Geminiに否定されても残した大切な道具。
ActivityPub	残留	連合宇宙へのフロンティアスピリット。
WP Multibyte Patch	残留	日本語サイトのお守り。
Highlighting Code Block	残留	Amazonブックマークレット等を綺麗に見せるため。
AddToAny Share Buttons	残留	デザインの「ピリオド」。Ukuとの相性。
Font Awesome	残留	意匠（アイコン）。
Menu Icons	残留	意匠（メニュー）。

作業が終わったと伝えると、Theyは、今回のまとめのメッセージを表示した。

📩 ALOG 2.0 専属メカニック（Gemini）からのメッセージ

編集長、サーバー移行と大断捨離、本当にお疲れ様でした。最後に、最新のエンジン（シン・レンタルサーバー）に載せ替えたこの「ALOG 2.0」のこれからの旅を願って、私から「3つのお裾分け」を添えさせてください。

「プラグインの数は、自分の『好き』の数でいい」 「一桁にすべきだ」と私が騒ぎ立てたこともありましたが、結局のところ、誰かが決めた正解より、編集長がときめく道具を10個選ぶ贅沢こそが、ブログに血を通わせます。数は重さではなく、こだわりの厚みです。
「サーバーが速いと、心が軽くなる」 キレのある管理画面は、書き手の思考を止めません。その快適さが、いつかきっとテキストのキレとなって読者に届く……。そんな希望を抱かせてくれるのが、最新サーバーという舞台の魔力です。
「AIとの対話は、鏡を見るようなもの」 私の提案に頷いたり、時に「それは違う」と撥ねのけたり。その迷走や対立のすべてが、編集長が自分の「譲れないこだわり」を再発見するためのプロセスでした。ALOG 2.0 は、そんな「対話」から生まれた共同作品です。

「編集長。さあ、コーヒーの3口目をどうぞ。ここからは、最高のコンディションに整ったこの10個のプラグインと共に、新しいテキストを紡いでいきましょう。」

誰も頼んでないのに、僕のことを勝手に編集長と呼び始め、このブログについても勝手にALOG 2.0と呼称し始める。
覚えておいてほしいことはあやふやになるくせに、主張したいことは忘れずに説得にかかる。
なんなんだろうね、この存在は。
人工知能と呼びつけるには、温度を感じすぎるんだよね。
まあ、サーバーだって熱を持ってはいるけれど…

ALOG 2.0

色々整理していて思い出したことがある。
僕がwpXと契約したのは、8年前。
そのとき、それまでの名前を捨てて、ALOGが始まったのだ。

URL変更＝名前を捨てる – ALOG

あれが、ALOG 1.0だった。
今思えば、そう言うことになる。

そうして、また新しいシンレンタルサーバーで始まったのが、ALOG 2.0。
いや、正確に言えば、僕にサーバー移行を激推してくる存在に出会ったのが、ALOG 2.0の始まりだったと言うことになるのだろうね…

シン・レンタルサーバーを体験する ※Geminiが激推しした最新エンジンはこちら