はじめに
このブログの裏側を、MicroCMSからStrapiに移行した。フロントエンドはAstroのまま、バックエンドのCMS部分だけを差し替えた形になる。
結論から言うと、かなり管理しやすくなった。今回はその経緯と構成について書いておく。
MicroCMSに感じていた違和感
MicroCMSは日本製のヘッドレスCMSで、導入のしやすさやドキュメントの読みやすさは間違いなく優秀だ。無料枠でも個人ブログ程度なら十分まかなえるし、APIの設計もシンプルでわかりやすい。
ただ、使っていくうちにじわじわと「やりづらさ」が積もっていった。
まず、管理画面のUIが自分の運用スタイルと噛み合わなかった。記事を書いて、フィールドを整理して、プレビューして……という一連の流れの中で、細かいところで手が止まる場面が多い。「慣れの問題」と言えばそうかもしれないが、慣れても解消しない種類の引っかかりだった。
もうひとつ気になっていたのが画像の扱いだ。MicroCMSでは画像をアップロードするとCMS側のストレージに配置されるが、その読み込みの仕組みやURL構造について、自分の中でスッキリしない部分があった。動作に問題があったわけではない。ただ、画像配信の経路を自分でコントロールできないことに、漠然とした気持ち悪さがあった。
無料枠で収まっていたのでコスト面での不満はなかったが、「無料だから我慢する」という状態が続くのも健全ではない。であれば、自分が納得できる構成に組み替えてしまおうと思った。
microCMS｜APIベースの日本製ヘッドレスCMS
移行先の構成
移行後の構成はこうなった。
フロントエンドはAstro。ここは変更なし。ビルド時にCMSのAPIからコンテンツを取得して静的サイトを生成する、という基本的な仕組みはそのまま維持している。
CMSはStrapi v5。ローカルのUbuntu環境にDockerで立てている。外部のホスティングサービスは使わず、手元のマシンで完結させた。Strapiはオープンソースなので、セルフホストであればライセンス費用はかからない。Docker Composeで管理しているので、環境の再構築も楽だ。
画像などのメディアファイルはCloudflare R2に配置した。R2はS3互換のオブジェクトストレージで、エグレス料金（データ転送の出口費用）が無料という大きな特徴がある。個人ブログの画像配信程度であれば、実質無料で運用できる。StrapiのMedia LibraryからR2へ直接アップロードできるようにプロバイダを設定しているので、記事を書く際の画像管理もスムーズだ。
Strapiにして良かったこと
まず、コンテンツの構造を自分で自由に設計できるのが大きい。Strapiはコンテンツタイプを管理画面上でGUIで定義でき、フィールドの型や構成を柔軟に組める。MicroCMSでもAPIスキーマの設計はできたが、Strapiの方がより直感的に、かつ細かく制御できる印象がある。
次に、データが完全に手元にあるという安心感。DockerのボリュームにSQLiteのデータが入っているだけなので、バックアップもリストアも単純だ。外部サービスに依存していないから、サービス終了やプラン改定を心配する必要がない。
画像についても、R2に置くことで配信経路が明確になった。「この画像はどこに保存されていて、どういう経路でユーザーに届くのか」が完全に把握できている状態は、精神衛生上とても良い。
@strapijs
ローカルでStrapiを動かすということ
「CMSをローカルで動かして大丈夫なのか」と思う人もいるかもしれない。
確かに、チームで運用するなら外部にホストすべきだろう。だが個人ブログであれば、書く人間は自分だけだ。ローカルのDockerでStrapiを起動し、記事を書いてAstroでビルド、成果物をデプロイする。このワークフローで何も困っていない。
むしろ、ネットワーク越しのAPIコールがなくなる分、ビルド時のコンテンツ取得が高速になるという副次的なメリットもあった。
おわりに
MicroCMSが悪いサービスだったわけではない。ただ、自分にとっては「自分で全部見えている状態」の方が合っていた。Strapiに移行してからは、コンテンツの管理に対するストレスがほぼなくなった。
構成としてはAstro + Strapi v5（Docker on Ubuntu） + Cloudflare R2。個人ブログの技術スタックとしては、なかなか筋の良い組み合わせだと思っている。
同じようにヘッドレスCMSの選定や移行を考えている人の参考になれば幸いだ。
コメント
コメントを読み込み中...