サイト大改造

Wed, 04 Nov 2026 23:26:03 +0000

2012年10月にLivedoorブログから始まった当サイトは、2016年7月にWordPressに移行しました。そしてそれから10年、おおよそ二回目のサイト大改造となる、Hugoへの移行を実施しました。

きっかけはサイバー攻撃の激化です。WordPressだとメンテナンスがたいへんだなぁと思いました。それだけだと大仰なことをしたなという感じですが、まぁ元々、うちのサイトでWordPressの機能は大して使っていなかったので、やめたいなぁという気持ちもありましたので。ちょうどよかったかなと思います。何よりせっかくのAIがWordPressだと手足を縛られている感じになりますし。

逆に言うと、機能をあまり使っていなかったので比較的すんなり移行できた、とも言えます。まぁ意識はしていて、少しずつプラグイン依存を減らしていたんですよね。カスタムフィールドの利用もやめましたし。その積み重ねがあったから出来た、のはあったな。

サブブログの邪悪なAI記事サイトを先行で試すことができたのも良かったです。なんでも作っておくものだな。ただあのサイトはメディアファイルの扱いがなかったので、それについては新たに改修が必要で、アーキテクチャはまた少し複雑になってしまいましたが…。ま、仕方ないですね。AIの力を借りつつWordPressサイトをHugoに移行見ると無駄な複雑さがわかるかと思います。

まーまだ予約投稿機能作ってないとか、コメント機能がないとか（過去コメントの閲覧はできます）、色々ありますけどね。一応一通りは動いている、はずです。動いてないところは随時改修していく所存です。

今後とも、当サイトをよろしくお願いいたします。

AIの力を借りつつWordPressサイトをHugoに移行

Sun, 01 Nov 2026 00:00:00 +0900

久しぶりのセルフホストな記事。

このブログはまだWordPressなんですが、サブブログをWordPressからHugoに移行しました。理由は主に昨今のサイバー攻撃の激化のためです。WordPressが悪いというわけではないのですが、アタックサーフェスの大きさやPHPの特性を考えると、正直これからの時代厳しいように思われました。毎日のように「プラグインの更新してないぞ」「このIPアドレスから阿呆みたいなブルートフォースアタックきてるぞ」という通知がくるのも疲れましたし。

なので、昔に戻ってスタティックなコンテンツ配信に徹しよう、というような感じです。

WordPressからHugoへ

今回手始めに移行したのは、AIに記事を書かせている邪悪なサイトです。こんな感じに変わりました。

before

after

なんだかんだで移行まで3日くらいかな。正直AIなかったらしんどすぎて無理ってなったと思います。でも移行を決めたのはAIによるサイバー攻撃の激化のためなので、AIのおかげで言っていいのかどうかは微妙なところです。

ここからまた色々と手を加えつつ運用をして、課題を洗い出しながら、本ブログであるこのサイトの移行の準備を進めます。このサイトは14年続いているだけあって色々な歴史が不思議なHTMLタグとなって残っているため、すんなりとはいかないでしょう。AIにめっちゃ調査させながら進めていくことになるでしょうね。かなり時間がかかると思います。仕方無い。来月中にできるといいな。

全体の構成

さて、構成ですが、元々の構成は極めてシンプルでした。

graph TD
cf(Cloudflare)
wp(WordPressコンテナ)
cf --->|トンネル| wp

これが今回、ちょっと複雑になりました。というのも、私は自作の管理アプリケーションがあり、そこで記事の執筆などもしたいためです。こんな感じのアプリでやってます。

記事執筆と管理系のがずらずらと。ちなみにサイトトップの古のアクセスカウンタもこのアプリケーション上でウィジェットを作っています（アクセス解析自体はOSSのUmamiを使わせていただいております）。ウィジェットのみグローバルに公開して、内部のアプリケーションはLAN内限定です。

執筆機能は重要です。そもそもWordPressを使っていたのも、ぶっちゃけWYSIWYGで編集してその場で公開できなきゃいやだいという運用上の理由が大きかったです。デザインはどうでもよい。なので、Hugoに移行するとしてもエディタを用意できることはマストでした。このへんはAIのおかげでやれるようになったと言っていいでしょう。

ただこういうややこしいことをする以上、Hugo側の管理と衝突するために、アーキテクチャはどうしても考えるところが生じます。今回は以下の構成に行き着きました。

flowchart TD
subgraph Internet["インターネット"]
User["閲覧者ブラウザ"]
end
subgraph Cloudflare["Cloudflare Edge"]
CDN["Cloudflare DNS / CDN"]
CFTunnel["Cloudflare Tunnel Edge"]
end
subgraph Server["自宅・ホストサーバー（完全閉域）"]
subgraph Delivery["配信基盤 (Docker)"]
TunnelApp["cloudflared コンテナ"]
Caddy["Caddy Webサーバー (ポート開放なし)"]
StaticFiles["静的ファイル (HTML / CSS / 画像)"]
end
subgraph Management["執筆・ビルド基盤"]
Dashboard["Web管理画面 (Blog Dashboard)"]
Hugo["Hugo (静的サイト生成)"]
Source["Markdown記事"]
end
end
%% 閲覧フロー
User -->|HTTPS| CDN
CDN --> CFTunnel
CFTunnel -.->|アウトバウンド常時接続| TunnelApp
TunnelApp --> Caddy
Caddy -->|読み取り専用| StaticFiles
%% 執筆フロー
Dashboard -->|記事保存| Source
Dashboard -->|ビルド実行| Hugo
Source -.-> Hugo
Hugo -->|HTML出力| StaticFiles

Hugo環境はコンテナに隔離して、cloudflaredよりトンネル経由で外からアクセスする感じです。Cloudflare依存になってるやんと見えますが、まぁそうなんですが、別に使えなくなったらVPSからfrpなりなんなり使った構成に切り替えればいいだけなので、まぁいいかなと。さらに言えばサイト公開するマシンはそれ専用にする予定です（まだ徹底はできていない）。

そんで、記事の生成とかビルドの実行とかは、全部管理アプリケーション上でやる構成ですね。一言で言えば管理アプリケーションが正本となる構成です。Hugoリポジトリは中継地点ないしバックアップの役割になります。なのでCI/CDによるホスティングではないです。これによる制約はいくつかあります。主に運用上の制約は以下になるでしょうか。

管理アプリケーションとHugoのホスティング環境が同一のマシン上にあること（変えてもいいんだがややこしくなり思想から外れる）
普段は管理アプリケーションからHugoリポジトリのpush/pullを実行するが、Hugo側のデザイン変更時（特に記事データに特殊な記法を挿入する時）はローカルのHugoリポジトリでpushする、2つのワークフローが存在すること
CI/CDでブランチごとにホスティングしてステージング環境作るとかはできない（できないことはないが構成と運用がややこしくなり、設計思想から外れる）

この制約は受け入れることになります。

別の考え方としてリポジトリを正本とする考え方もあり、まぁそちらのほうがアーキテクチャは綺麗になると思うんですが、なんか無駄に複雑な運用になりそうだったのでやめました。どうせ運用者も僕だし。

再び個人サイト激動の時代に…

とまぁこんな感じでやっていて思ったんですが、AIで楽になったと言っていいんですかねぇ…。25年前は専門じゃなくてもやる気があれば頑張ってサイトを持つことができたと思うんですけれど、今はこれちょっとどうなんでしょう…。

トンネル技術とコンテナが揃った時には、個人サイトやセルフホストがまたやりやすい時代になった！と思ったのですけれど、サイバー攻撃がヤバいから守備を固めよう、WordPressはよくない、でも運用が不便になって更新しなくなったら元も子もないから利便性も高めよう、みたいなことを考え始めると、AIによる効率化以上に、トータルの難易度自体は上がり続けているような気がします…。

いやまぁ、僕がややこしくしているだけか。

これはまぁ結局、何をどこまで信じるか、という話です。少し前までだとVPSやクラウド基盤そのものを疑うのはキチガイ扱いだったかもしれないのですが、最近お名前.comデスクトップクラウドが基盤ごとやられて顧客の資産がハッカーの攻撃により消失し、さらにGMOが顧客の端末を回収するため物理的に全国を駆けずり回ったという事件は、クラウドは絶対安全ではないという当たり前の技術的な真実を曝け出しました。ま…それでAWSをはじめメガクラウドが陥落するかと言えば別にそういうわけではないですけれど、でもメガクラウドだから安全だ、は技術ではなく信仰でしょう。

結局個人サイトって自分の城です。城をどこにたてますか、どうなったらその城はぶち壊れますか、あなたはそれに納得できますかと、そういう話なんだと思います。絶対防御は無理なので、そのうえで何を賭けるのか。それを考え始めると、やりたいことに対して、本気でぶち壊そうとする勢力、さらにその被害が大きくなりすぎて、それが多分根本的な問題なのだと思います。

僕の構成がややこしくなっているのは、それだけ僕が納得するのに必要になってしまったということはあります。別にもっとシンプルな構成は可能です。元々のようにCloudflareトンネルでWordPressコンテナ直通でも良いといえばそうなので。ちゃんと更新し続けて、今回のPHP事件みたいなのがあったらキャッチアップして…ってやっても、基本は大丈夫でしょう。心配なら物理的にサイト専用のマシン作って切り離すくらいで、ほぼほぼ問題ないと言って思います（まぁそれも普通からするとややこしいわけですが…）。

まぁ結局どうしたいかは人それぞれということになるんですが、その構成に至る道筋や、またその構成における必要な運用はなにか、普通の人がそれを理解して辿り着くのが難しくなっているのかなぁと、そんな風に思いました。

<関連記事>

Hugo on 或る阿呆の記

サイト大改造

AIの力を借りつつWordPressサイトをHugoに移行

WordPressからHugoへ

全体の構成

再び個人サイト激動の時代に…