blog.asterism.xyz

Astro＋オレオレCMSで個人ブログを再構築した

公開日:

[tech] #Cloudflare #Astro #WordPress #Hugo #SSG #CMS

WordPressに疲れた話

前回の記事を軽く振り返ると

https://blog.asterism.xyz/posts/20260603-0000018a/

不満の部分は前回あまり書かなかったので少し補足しておくと、

こんな感じ。

そんな折、仕事や私用でAIしばいてあれこれ作っていた所、この程度のブログならいい感じにワークフロー含めて考えてできそうだなぁ、となった。

そこで一旦試しにAIでブログ自体とその運用手順を作らせ始めた。

既存のブログプラットフォームなんかを選ばなかったのは、DBでもテキストファイルでも何でも、自分でコントロールできる範囲にデータを持っておけば、今後もし仮にAstro死んだりしても、手元に残ったデータから別のシステムにAIしばいて移行しやすそうだなと思った次第。

前回話題に上げたざっくり要件としては以下の5つ

SSGどれにする問題（結局Astro）

Hugoが嫌になった過去がある以上Hugoは無し、Next.jsやNuxt.jsはリッチすぎるように思える(webなんも分らんので10分くらいずつググったイメージ)。

全部AIにコーディングさせる前提なんだから、破壊的変更がどーたらも別に…って感じではあるんだけれども。

JekyllやGatsby、Hexoなんかはちょっと将来性が不安。

となると残りの有名どころは11tyとAstroの二択。

シンプルさ的に継続運用が楽そうなのは11tyだけど、エコシステムに乗っかってAIに馬鹿みたいな指示で作らせるならAstroの方が良さそうと判断してAstroを選択。どうせ運用も自分の手作業じゃなくAI前提だし。

既製CMSを諦めて自作するまで

プロジェクトを始めた当初は既存のgitベースCMS(Sveltia CMSとかDecap、Pagesとか)を使う想定で、とりあえずSveltia CMSを入れてみた。

UIはかなり良かった。decapはかなりしんどい見た目だったけど、こっちなら十分使えるなーという感じ。

ただ実際触っていて増えた要件だとか、実際に触る中でいくつかどうしても譲れない点があるなぁとなり。

下書きは下書きだから、スマホからやるにしろ別のメモアプリなんかで書けばいいんじゃない？って話でもあるんだけど、都度都度コピペもなんだかなぁと思いちょっと受け入れられなかった。

一応ブランチ切るワークフローもできるらしいdecap cmsを久々に触っても見たけど、こっちはUIが非常にしんどい感じだったので無し。

前回記事ではちょっとだるそうだよなぁ、と思った所で止めていたが、あれこれ考えて、フロントエンドだけでなんとかするよりも、SQLiteとかで下書きのデータとか状態を管理した方が楽そうだなぁと判断。

諦めてDB持つようにしちゃえばあとはもう単純な話で、gitコマンドをサーバー側で触る簡易CMSを作る事に決めた。

このローカルファイルシステム上のgitリポジトリをwebuiで外部からいじるっていうやり方、これは正直ちょっと微妙だったかもなぁとも思っている。

これはブログ本体がほぼ完成してからコンテンツ編集操作に不満を持ってCMSに手を付けたので、ほぼ出来上がってるサイト側をまた作り直すのもなぁとなり、gitベース(GitHub APIベースじゃなくてね)なものにしたかったという理由から。

作ったもの：構成と技術スタック

そんなわけで、1日2時間くらい、2週間程度claude codeをしばいて暴言吐きながら作ったのがこちら。

認証やら添付ファイルの扱いやらプレビュー機能やら、前回うだうだ言ってたものはほぼ回収できたはず。

ブログ本体：Astro x Cloudflare Pages

デプロイ先は今回はCloudflare Pagesを選択。

他の用途でも使ってるからまとめた方が今後が楽だろうという判断。

自作CMS：Next.js × Cloudflare Tunnel

これからのメンテ計画（月1・AI任せ）

AIしばいて個人開発、ってのを半年くらいやって思ったことが、作った後のメンテナンスがまぁまぁだるいということ。

いうてそれらはフロントエンド完結のものばかりだから、普段からの定期的なメンテは不要だし自分で使っていて機能面の不満だとかが出てきたらAIしばいてアプデして→XXXな機能作って、って言うだけだから大したことではない気もするんだけれども。

ただあまりに間が空いてしまうと、まぁまぁパッケージのアップグレードが大変そうだなぁというのもなんとなく想像できる。

というわけで今回作ったものについては、月一くらいでメンテナンスしようとは考えている。

とりあえず昨日試してみたのは、適当にこんなプロンプトで指示しつつメジャーアップデートの状況を確認させつつどうするか決める、みたいなやり方。

ブログ本体はAstro6.4.xから7.0.xに上げ、CMS側もNext15から16に上げられたので大きな問題は無さそう。

プロンプトもclaudeに「お前に定期メンテ依頼するときのプロンプト考えてよ」みたいな事を言って出力させた。

今月のパッチ作業の時間です。npm audit + npm outdated を実施して、パッケージを更新してください。

安全のためブランチを分けて作業し、コミットは私が許可するまで行わないでください。

また、ソースコードの編集が必要な破壊的変更が含まれる場合や、メジャーバージョンアップデートなどは、対応方法を考えた上で私に相談してください。

特に、npm audit fix --forceやメジャーバージョンが絡む場合、実際に私の環境(ユーザー私一人でcloudflare tunnel/cloudflare accessで保護、blogはcloudflare pagesでSSG)で攻撃可能かどうかを考慮してください。

一声かけるだけで待ってりゃある程度ちゃんとやってくれる、html/css/jsもnodeも何も分らんけどこの程度なら仕事してない時間にちまちまやるだけで少なくとも動くものができるなんて良い時代だ。(諸説ある)

最後に

あとは冒頭でもちらっと書いたけど、markdownと添付ファイルはgithubにもローカルにもあるから、今後なにか激ヤバ事案があってcloudflareから出ていかなきゃならなくなったりとか、astro使えなくなったとかがあっても、適当なAIエージェントしばき回せばなんとかなる。

これが中々の安心感を生んでる。

こうして、phpの知見を都度都度ググったり、テーマの設定方法調べてバージョンの差で使えないよとか、スキン微妙だなとか、よく分からん謎のプラグインを不安に思いながら使い続ける状態からは一応脱出できた。

ただまぁ依存先がwordpress.orgのSVNにあったのが、githubとnpmレジストリになっただけでもあり。

逆に言えば依存先をちょっと変えるだけで(正直これどっちも外から見てる分にはちょいちょいトラブってるから信頼度に大差無いんだけど)、自由度合いが広がってとてもよろしい。

勿論逆に言えば困った時に直すのは自分だけど、今はAI殴るだけでコード直るし、インフラ部分は自分で判断付けられる。

インフラ知識を持ちつつ、AIしばいてそこそこのものは作れます、みたいなスキルセットだと将来もまだまだIT楽しめそうだなーと思い始めた。

関連記事

← 一覧に戻る

検索Esc で閉じる