いまや時代はAIが左右しています。その活用は趣味分野にも及ぶでしょう。その一例として、趣味サイトの運営に活用した部分をお伝えします。(コンテンツ本体にはAIは使いません！)
写真1. 着実にスピードアップと増発を積み重ねている東海道新幹線(2026年GWに東京で撮影)
情報実際にAIにコードを書いてもらいました。あえて本記事ではコードを示しません。これは本記事では「観点」の紹介であり、実際のコードはサーバーやWordPressのテーマに依存するためです。このような内容こそAIの得意分野です。実際に「○○のコードを書いて」と指示することが良いでしょう。
サイト運営のAIの活用場面とその成果
サイト運営の以下の場面でAI(Copilot)を取り入れました。
- 鉄道関連の調べものや記事執筆ではAIを使用せずに、従来通り自分の知識と頭を活用を維持した(なのでこの記事も私が頭で文章を考えています)
- サイト運営の技術的なこと、とりわけ高速化についてAIに頼り改善した
- サイト表示速度は鉄道系サイトや旅行系サイトでは大手サイトに近いものになった
詳細は以下にまとめます。
復習：AIとその限界
写真2. 人手を介したサービスに終わりはない(25年夏に欧州で撮影)
「時代はAI」と言っても、AIは万能ではありません。例えば、現段階でのAIでは家族にはなりませんし、創造的な仕事はできません。大規模な計算モデルと考えることができ、計算できることの限界があるためです。
私の理解ではAIが得意とすることは以下の通りです。
- 既存の知見を見つけること
- その知見を素早く言語処理すること
- 人間の言語を理解すること
非常にたやすくいうと、真に新しいことはできないけど、そのサポートはできる道具です。また、知見が多い分野は強く、知見が少ない分野では弱いとも表現できます。弊サイトの運営では既存の知見の多少を1つの軸としました。
鉄道系サイトを運営するなかでは、鉄道の細かなことは(信ぴょうさの検証を含めて)頼りなく、運営のバックアップに有用でしょう。
鉄道系サイト運営でのネックとその解決法
写真3. 大量の情報処理はAIの得意分野だと思う(2025年夏に成田空港で撮影)
鉄道系サイトを運営するうえでのネックは何でしょうか？究極は時間と金銭なのですが、それ以外を考えます。鉄道系サイトを運営するくらいなら、鉄道の知識は人並み以上でしょう。各自の主観的/客観的な評価で詳しい内容と疎い内容があるものの、その点は致命的な弱点になりにくいです。
では、何がネックでしょうか？私は鉄道について詳しくとも、サイト運営についてはそこまで詳しくないはずです。サーバー、ドメイン、PHP、HTML、CSS、JavaScript。自己流でサイトを8年以上運営しても、いまだにこのあたりの単語はよくわかりません(WordPressはよくできたシステムで直感である程度操作できますが)。
一方、サイト運営という意味では、鉄道系サイトもスポーツ系サイトもアダルトサイトも根幹は共通です。同じようなシステムを使い、同じコンピュータ言語を使い、同じ技術を使います。そして、AIはこのような分野では強いでしょう。私の理解ですが、コンピュータのことをコンピュータ(AI)に聞くのは、きっとスムーズです。
そこで私は鉄道のことでなく、サイト運営の技術的なことをAIに頼ろうと考えました。弊サイトではサイト表示の高速化を目指してきました(その割にはサーバーは最も安いプランですが)。しかし、高速化は専門の知見が必要であり、素人がおいそれと手を出せる領域ではありません。この弱点をAIによって補うこととしました。
私はAIにCopilotを使っていますが、単にMicrosoftのものだからという理由です。きっと他のAIでも変わらないでしょう。
その都度PageSpeed Insightsのメッセージを解読いただき、多くの対処をしましたが、ここでは対応内容ごとに記すことにします(必ずしも時系列になっていません)。ただし、それぞれの内容は独立しているので、対応する順番が前後しても問題ないでしょう。
プラグインの削減
写真4. 昔の鉄道車両は重い(2024年GWに唐津で撮影)
一般に機能と動作は相反します。すなわち、多くの機能を盛り込むと動作が遅くなります。WordPressサイトでは、「プラグイン」で特定の機能を付与します。一般にプラグインが多いと動作は遅くなり、表示速度も遅くなります。そこで、プラグインの削減が重要でしょう。2022年にプラグインをある程度削減した後は、以下の陣営でした。
Advanced Editor Tools：編集画面の高機能化- Akismet Anti-Spam：セキュリティ対策
All in One SEO：SEO対策のための多くの設定- Autoptimize：適切なキャッシュ
bbpress：掲示板機能を付与Classic Editor：編集画面の最適化Classic Widgets：設定画面の最適化- Contact Form 7：メールフォーラム
- Google XML Sitemaps：構造化データをgoogleに送信するため
- Kattene：外部サービスの適切な表示
- List category posts：カテゴリとタグで記事を絞り込む
PS Auto Sitemap：HTMLでのサイトマップを表示Shortcodes Ultimate：多くの装飾のため- SiteGuard WP Plugin：セキュリティ対策
Table of Contents Plus：記事内目次を表示TablePress：表を作成- WebP Converter for Media：新しい画像形式に対応
- WP Multibyte Patch：日本語対応のために導入(WordPressはもともと英語)
WP-Optimize：サイト内データを適宜整理(自動動作はしない)- (2026年追加)WP Super Cache
2022年初に導入していたプラグインから削除したものを取り消し線で示しています。2022年に大幅に削減した後は徐々にプラグインを削除していました。例えば、記事内の表をHTMLの表やWordPress標準機能の表に置き換え、TablePressを削除するなどです。
2026年には4つのプラグインをAIの助けを得て、見直しました(4つの削減、2つの追加)。これらの見直しについて記します。プラグインが8つというのはかなり少ないほうと思います。
Contact Form 7(メールフォーラムのプラグイン)の削除
サイトを運営する上で、問い合わせページは重要でしょう。それを取り入れる1つの方法がContact Form 7です。しかし、Contact Form 7は速度向上を阻害します。この点は2022年段階で明らかになっていました。
- プラグインロード時間：0.207秒
- ロード時間におけるプラグインの割合：54.7%
- WebP Converter for Media：32%
- Contact Form7：25%
- Autoptimize：15%
- TablePress：7%
- SiteGuard WP Plugin：5%
- WP Multibyte Patch：5%
サイト高速化のために：一部のプラグインからの脱却を目指してに記載の内容より
ここで、Contact Form7が重いことに気づきます。したがって、これを削除したいと考えていました。しかし、自作のフォーラムを作成することも不安でした。
そこでAIに聞いたところ、Googleフォームを提言いただきました。メールフォーラムを導入することにこだわっていましたが、既存のものを使えば良いわけです。これは目からうろこでした。
Google XML Sitemaps(構造化データをgoogleに送信)
検索エンジン(とりわけgoogle)には構造化データが必要といいます。
構造化データとは、Webページの内容を検索エンジンが正確に読み解けるよう、決められたルールに従って記述した「意味付きのタグ情報」です。
私の解釈では、機械にとってわかりやすい表現方法で記述しましょう、ということです。そして、その機械語の翻訳をするためにGoogle XML Sitemapsというプラグインを入れていました。しかし、WordPressには標準的な機能でXMLデータを出力する機能があります。よって、特別なこだわりがなければ、プラグインが不要なのです。
このことも知りませんでした。このプラグインを削除することによる効果は小さいでしょう。しかし、プラグインを削除すること自体が軽量化やサイト安定化に寄与するのです。
WebP Converter for Media(新しい表示形式)
WebPというのは画像の形式です。簡単にいうと軽量な画像形式です。サイト速度を高速にするには画像の容量がネックです。それを解決するのがWebPです。しかし、WebP Converter for Mediaでは(私の設定が下手だったのか)WebP形式で配信されていませんでした。
その点は現状把握(FireFoxの調査ツールを使用)によるJpg形式での配信が継続されていることを把握しました。そして、WebP Expressという別のプラグインに変更しました。
さらに圧縮率を考慮し、1536pxという良質な画像(2025年7月以降に投稿または更新の記事)でありながら、410KBという比較的低容量を実現できました。サイト速度診断ツールを使うと、「画像配信を改善する 推定される削減サイズ 428 KiB(数値は毎回異なります)」と表示されますが、428KBというデータ量は4G(平均 20Mbps = 2.5MB/s)で換算すると0.17秒です。多く見積もっても0.4秒でしょう。そのために画像の質を低下させることは望ましくないと感じ、ここまでとしています。
WP Super Cache(新規導入)
私はキャッシュというものにはあまり重きを置いていません。多くのキャッシュは訪問済の読者さんに効果のあるものです。しかし、Web高速化の対象を新規の検索ユーザーに絞っている(これは結果として訪問済の読者さんにも効果がある)ため、一般的なキャッシュは弊サイトでは無意味と判断しています。
一方、WP Super CacheはPHPファイルをHTMLに書き出し、読者さんが訪問した際にそのHTMLを活用するというものです。(正しい例えかわかりませんが)PHPコードは考えるコード、HTMLは考えないコードです。その「考える手間」を削減し、「考える時間」を削減し、表示を少しでも高速にするというものです。
高速化に効いたそのほかの施策
写真5. 情報は必要に応じて提供しないと混乱してしまう(次の名古屋から普通、2024年に栄生で撮影)
高速化に対し、このほかの施策は次のものです。
復習：遅延読み込みという概念
ページを表示する際に最も「遅い」と感じるのは、ページを最初に開いた瞬間でしょう。なぜ、ページを開いた瞬間に遅いと感じるかというと、100ある処理を最初にすべて処理しようとするためです。最初の処理を100から10に減らすと、処理時間は1/10に減少します。残りの90については後から処理します。実際に記事を読み始めたら、処理に時間がかかっても構いません。読者さんはその間に弊サイトの高尚な記事を読んでいます。例えば、読者さんが特定の箇所で3秒読んでいる間に、弊サイトのコンテンツ表示を2秒ぶん実施すれば、読者さんの実質的な待ち時間は0です。
このように、必ずしも最初に読み込まなくとも良い内容を後から読み込むことを、遅延読み込みといいます。プラグイン削減が読み込みべき全体量を減らす取り組みとすれば、この章の取り組みは、最初に表示させるためのデータ処理を減らすための取り組みとも表現できます。
Googleマップの遅延読み込み
Googleマップは優秀ですが、何も設定していないとページを読み込む際に、地図データも読み込みます。ページの下部に地図があるレイアウトだとしても、ページを開く際に地図のデータを読み込むのを待つということです。
実際にはページを開く「多くの処理が重なる」段階で地図まで読み込む必要はありません。そこで、読者さんが地図に達する際に地図を読み込むように変更しました。これもAIにコードを聞き、そのまま実装しただけです。確かに実装後はページ表示速度がやや速くなった気がします。
画像の遅延読み込みとその対象外の指定
弊サイトでは多くの画像を入れています。例えば、25年夏中欧･イタリア旅行のまとめでは59枚の写真と7枚の図表を入れています。1つが100KBとかなり軽量としても、合計は6.6MBにもなります。これを最初に読み込むと(平均 20Mbps = 2.5MB/sとして)2.64秒もかかります。ページを表示開始してから2.64秒読み込むと、表示に2.64秒余計にかかります。
これはかなりのストレスです。それを軽減させるのが遅延読み込み(Lazy Load)です。具体的には、スクロールした瞬間に画像を読み込みます。例えば、25年夏中欧･イタリア旅行のまとめでは写真と図表を合わせた66枚は一括で必要になりません。当該の写真が必要なタイミングで表示させれば良いわけです。仮に10枚の写真を同時に表示し、かつどれも500KBあったとしてもかかる時間は2秒です。実際には写真の容量はもう少し小さく、実際には1.5秒でしょう。これは時間がかかる気もしますが、(計算上は)0.15秒間隔で写真が随時表示され、読者さんのストレスが小さいでしょう。
この遅延読み込みのタイミングをAIに改めて助言を受け、再設定しました。他方、最初に表示する画像まで遅延読み込みすると逆効果です。すなわち、画像を表示しない段階でのレイアウトと画像を表示した段階でのレイアウトが異なり、表示速度という観点は逆効果です。したがって、「最初の画像だけ Lazy Load を無効」のためのコードを導入しました。
さらに、「記事の最初の画像に fetchpriority=high を付与（LCP 改善）」を施しました。こうすることで最初の画像が表示されるタイミングも考慮しました。
広告の遅延読み込み
画像とともに表示のネックとなるのは広告です。これについては遅延読み込みを有効にし(テーマ側に設定はないのでコードを書いた)、LCP 完了後に初めて読み込むようにしています。
これでサイト表示速度が上がったという実感はあまりありませんが、表示されにくいケースが減った気がします。最高のパフォーマンスを上げることも重要でしょうが、それ以上にパフォーマンスの「最低点」の底上げが重要に感じます。特に広告は外部環境に影響されますので、その影響を最小限にとどめることが重要なのです。
SNSボタンの遅延読み込み
弊サイトでは記事末尾にSNSボタンを配置しています(マイナーなサイトゆえにどこまで活用されているのかは別問題ですが)。これも記事末尾をご覧いただいた際に表示されれば問題ありません。そこで、SNSのJSを遅延読み込みしました。同時に、(わずかでも処理量そのものを減らすために)内部CSSを無効化しました。
AIによる表示速度底上げした成果
写真6. ホームにホームドアが付いたことも輸送の底上げかもしれない(分倍河原で撮影)
ここまで多くの取り組みをしましたが、重要なのは結果です。弊サイトのように写真が多めかつgoogleマップを採用しているサイトは表示速度という意味ではハンディキャップがあります。そんなハンディキャップのある弊サイトの実測データを示します。
表1. 弊サイトの実測データのまとめ
| モバイル | PC | |
| Largest Contentful Paint (LCP) | 1.6s | 1.5s |
| Interaction to Next Paint (INP) | 112ms | 47ms |
| Cumulative Layout Shift (CLS) | 0.08 | 0.07 |
| First Contentful Paint (FCP) | 1.5s | 1.3s |
| Time to First Byte (TTFB) | 1.1s | 0.9s |
図1. 7/19測定の弊サイトの過去28日実測データ
図2. 7/19測定の弊サイトの過去28日実測データ
表2. 弊サイトのベンチマークのサイトとの比較
| 鉄道ラボ | サイトA | サイトB | サイトC | サイトD | |
| Largest Contentful Paint (LCP) | 1.6s | 0.8s | 1.4s | 2.9s | 1.6s |
| Interaction to Next Paint (INP) | 112ms | 119ms | 123ms | 208ms | 114ms |
| Cumulative Layout Shift (CLS) | 0.08 | 0.00 | 0.00 | 0.16 | 0.03 |
| First Contentful Paint (FCP) | 1.5s | 0.7s | 1.2s | 2.4s | 1.6s |
| Time to First Byte (TTFB) | 1.1s | 0.4s | 0.4s | 1.8s | 1.0s |
| (参考)FCP-TTTB | 0.4s | 0.3s | 0.8s | 0.6s | 0.6s |
| (参考)LCP-FCP | 0.1s | 0.1s | 0.2s | 0.5s | 0.0s |
単に実測データだけ示されてもよくわからないでしょう。そこで、弊サイトがベンチマークにしているサイトをいくつか比べました。
- サイトA、サイトB：鉄道コムランキング上位の個人ブログ
- サイトC：旅行系の大手サイト
- サイトD：鉄道系の大規模ポータルサイト
なお、各指標については以下のように解説できます。
- LCP：Webページのメインコンテンツが表示されるまでの時間を測る指標(2.5s以内が良好)
- INP：「操作したのに反応しない」体験を数値化したもの(200ms以内が良好)
- CLS：ページ表示中に意図せずレイアウトが動く現象(0.10以内が良好)
- FCP：最初に「ページが表示され始めた」と感じる瞬間を数値化した指標(1.8s以内が良好)
- TTTB：サイトのURLをクリックしたり、リンクをタップしたりしてから、ブラウザがサーバーから「最初のデータ（1バイト）」を受け取るまでにかかる時間(0.8s以内が良好)
図3. TTTB、FCP、LCPの大まかな関係性
最終的にはLCPが重要ですが、それに至るまでのTTTBとFCPが別に指標になっているという理解です。これまでの取り組みはサイト側の改善項目でした。LCPとTTTBの時間差は鉄道ラボが0.6sと鉄道コムランキング上位のサイトBの1.0sの約半分と、鉄道ラボのサイト側の改善が進んでいることがわかります。
逆に弊サイトはベンチマークにしているサイトA、サイトBよりTTTBが長いことがわかります。これは、(私の想像ですが)サイトAはX-serverを使用、サイトBはロリポップハイスピードプランを契約しており、サーバーの性能が高いためでしょう(弊サイトはロリポップのライトプランです)。ロリポップちゃんの爆速化宣言はなされていますが、リーズナブルなライトプランなので、どうしても限界があります。
今後の課題はサーバー性能の強化です。ただし、ロリポップのライトプランは330円/月、ハイスピードプランは660円/月(いずれも36か月契約)で、次の支払いに11,880円の差額を支払うことになります。細々と続けることにより、より自由なサイト運営を実現しているので、このような拡大志向は弊サイトや私の考えにそぐわない面があります。
別の表現をすると、「AIの助力を得て、安価なサーバー環境でありながら、高価なサーバー環境の他サイトさんに近い速度を実現できた」と結論付けることも可能です。(弊サイトは商売ではありませんが)商売の基本の1つが損益分岐点を下げることにあります。大手サイトさんより損益分岐点が低いまま、大手サイトさん並みの表示速度を得られました。これからも金銭に頼らないイノベーションを細々と生み出すこととします。
AIの助力を得てサイトを高速化してきて
写真7. ベルギーは国全体に高速電車(客車列車もあるが)が網羅している印象(2024年にブルッヘ(ブルージュ)で撮影)
弊サイトでは、2018年2月の開設当初から「フォント指定なし」という(人によっては乱暴な)高速化志向がありました。これは私が高速電車を好む面があるかもしれません。ともかく、技術的に素人ながら技術的な挑戦を続けてきました。例えば、これまで2022年にプラグインを大幅に整理し、2024年に一部のプラグインを整理しました。しかし、それからは特に高速化はしておらず、足踏み状態が続いてきました(ある程度の高速化が完了していたという気持ちもありました)。
2025年ごろから急激にAIが台頭し、人間の先入観を超えることもできます。そこで、2026年春から物は試しとサイト高速化についてAIに聞いてみました(コンピュータ関係であってもけっこう的外れな回答があり苦労した部分もありますが)。その結果が安いサーバーであっても高価なサーバーを使用している大手サイトさん並みの速度を実現したことです。
AIやコンピュータはあくまでも道具です(弊サイトも道具としてご活用いただいて構いません)。その道具を活用する1つの例を示しました。
他方、個人サイトの最適化についてここまで親切かつ詳細に書かれた記事はないと思います。このような取り組みは大物ブロガーさんでもやっている人は少ないでしょう。では、他の人たちがこの記事を読んだら？大丈夫です。こんなマイナーなサイトのこの記事がそう多くの人に読まれません。そのため、この記事を読んだあなたは、他のサイトさんと差をつけることに成功します。やったね！