以前の記事を執筆後にいろいろありまして、コンテンツ管理を microCMS から frontmatterCMS へ移行しました。今回は移行の経緯や移行先の選定理由などを書いていきます。
目次
経緯
4 月に当ブログを制作し、約 1 ヶ月間 microCMS を利用させていただきました。microCMS はドキュメントや各フレームワークでの使用・設定方法など資料が豊富で、利用開始当初は利用体験が非常に良かったです。
移行するに至った経緯を簡単にいうと、「直前にやりとりしていたカスタマーエンジニアに私自身のツイートをいいねされた」からです。
移行を決意した日、私はユーザー側で修正不可能な microCMS のバグを引き、その修正をカスタマーチャットで問い合わせていました。対応は私の満足いくものではなく、バグも多いので「microCMS から contentful に移行しようかな」的なツイートをしたところ、先ほどカスタマーチャットに表示されていたアイコンと同じアイコンのユーザーからいいねされました。いいねはすぐに取り消されていましたが、後々調べたところ、同一人物で間違いないことが分かりました。その時点からプライバシー保護の観点で microCMS のことが信用できないと判断し、移行を決意しました。おそらく「microCMS」という単語を自動収集していて、それに引っかかった私のツイートにいいねをしたのだと思うのですが、私が microCMS で管理していたコンテンツから私の Twitter を特定した可能性も捨てきれなくて不快に思いました。また、ユーザーのデータを扱うカスタマーエンジニアが、Twitter 上で所属がわかる形式で活発に活動していること自体が、あまり良いこととは思えませんでした。
という経緯があり、移行先を探し始めました。((((((( ‥)ﾉﾄﾎﾞﾄﾎﾞ
移行先選定
移行先を決めるにあたって以下の点を重要視しました。
- MarkDown を入稿できる
- できれば MDX を使いたい
- 無料もしくは無料枠でできることが多い
- プライバシー保護に関して懸念がない
markdown で入稿できれば今後も気軽に CMS 変更ができますし、何より CMS 側のデータのエクスポート機能がなくても安心です。microCMS は現時点でまともなエクスポート機能を搭載していないので記事の移行は苦労しました。
mdx を使いたいというのは、どうせなら microCMS で記事管理してた際にはできなかった（頑張ればできる）、JS 組込みのコンポーネントを使った記事を書きたいという理由があるためです。日経ビジュアルデータというアニメーション表現を多用して視覚的に分かりやすい記事を配信しているサービスがあるのですが、ああいう記事を書けたらかっこいいなと思い、JS コンポーネントを使える mdx を選定技術に入れました。
無料がいいというのは金欠だからです。
ふぅ( ´･ω･)y─┛~~~oΟ◯
Contentful
真っ先に思い浮かんだのは Contentful です。zenn の記事で microCMS より優秀だって紹介されていたのを見かけたことがあり、ずっと気になっていました。軽く触ってみたところ、機能が多彩で markdown も使えますし、頑張れば mdx も使えることが分かりました。サイト上に英語の記載しかないのでとっつきにくい感じは否めませんが、慣れれば強そうです。今回は mdx の使い勝手で別の CMS に負けているので、パスしました。
TinaCMS
Astro.js のドキュメントに載ってたので触ってみました。ローカルで動かす系で markdown と mdx が普通に使える点はいいなと思いました。チーム開発ができることを売りにしている感じがあるのですが、今回はチーム開発機能は必要としていないですし、GitHub 連携を強いられる感じがめんどくさいなと思い、保留しました。
DatoCMS
ChatGPT におすすめされました。無料プランでできることが他社と比べて厳しい様子だったので採用しませんでした。また機会があれば触ってみたいです。
FrontMatterCMS【採用 🎉】
今回、データの移行先として採用しました。当初は API 経由でデータを取得する、いわゆるヘッドレス CMS を採用する予定で選定を開始しましたが、なかなか良いものがなく、結果的に完全ローカル管理？の FrontMatterCMS に行き着いたって感じです。次項で詳しく解説します。
なかなか使い勝手の良い FrontMatterCMS
FrontMatterCMS は VSCode の拡張機能として提供されています。VSCode さえあればすぐに使い始められますし、逆に VSCode ではないエディタを普段使いされている方には敷居が高いかもしれません。MarkDown で管理でき、もちろん MDX も使用できますし、無料で Saas でもないため、今回の移行対象としては満点でした。
機能も非常に充実しています。
- メディア（title/alt/caption も設定できる）
- スニペット（よく使う html 要素を登録できる）
- タクソノミー（タグやカテゴリなどの管理ができる）
など、他にも git との連携やスクリプトの登録などもありますが、まだ使っていません。個人差はあると思いますが、開発体験は移行前の MicroCMS よりも断然 FrontMatterCMS の方が良いです。FrontMatterCMS はカスタマイズ性が高く、収集付きの私にとってスニペット登録や有益な機能をドキュメントから見つけたりと、細々とした作業ができるので最高です。
移行
MicroCMS はエクスポート機能を実装しておらず、記事の移行作業は手作業でのコピペで行いました。23/5/6 現在、MicroCMS のプロダクトロードマップを確認したところ、今後もエクスポート機能を実装する予定はないようです。そういう事業戦略だと思うと悲しいです。
移行に際して、元々タグは表示日本語/id 英語にしていたのですが、英語で統一しました。FrontMatterCMS デフォルトのタグがオブジェクト形式ではなく、ただのStringで設定してあるので、どうせなら既存のプロパティを使いたいと思い変更しました。カスタムタクソノミーとしてオブジェクトの型も登録できるようなので、使い勝手を考慮しつつどうするか検討したいです。
画像はローカルに残っていたので、それらを public フォルダに上げました。今後記事の増加とともに画像も多くなっていくので、いいタイミングで画像戦略を考えたいと思っています。
それから、markdown 管理に移行するにあたって今までは一意の ID を記事 URL に組み込んでいたのですが、今回から slug での URL 発行に変更しました。その際に記事タイトルを英語に変換後、ケバブケースで繋ぐという作業をだれでも AI メーカーで作った「【変換】日本語 → 英語 slug」で行いました。このサイトを使う前は「正直自分で ChatGPT 打てばええやん」と思う派だったのですが、サービスとして入力・選択欄を設定しプロンプトを保存しておけば、わざわざ毎回手打ちで GPT に質問する手間も省けるので、いいサービスだなと思いました。
終わりに
結果的に FrontMatterCMS という素晴らしいプロダクトに出会えたので、今回の移行は正解でした。今回の件を経て Saas に対する認識も変わりましたし、今後何らかのサービスを使用する際には本当に自分に合ったものなのか、本当に必要なものなのか、しっかり調査し見極めてから使用することを心がけたいです。