個人ブログでヘッドレスCMSとMarkdownファイルのどちらを使うか

個人ブログのシステムを自作してみようと思い立ったとき、記事データの管理にヘッドレス CMS を使うか、Markdown ファイルとして保存するかを決める必要があります。それぞれのメリット・デメリットを検討した結果、私はヘッドレス CMS を使わずに Next.js + MDX でブログを作ることにしました。

この記事では、なぜヘッドレス CMS を使わず Markdown ファイルにしたのか、検討の経緯についてご説明します。

システム構成

ブログのコンテンツ管理をヘッドレス CMS で行い、ヘッドレス CMS からのデータ取得を静的サイトジェネレータで行えば、一般的な JAMStack（JavaScript/APIs/Markup）になります。

ブログのコンテンツ管理を Markdown ファイルで行い、Markdown ファイルからの HTML/JavaScript 生成を静的サイトジェネレータで行なう場合、API を使用しないため JAMStack の定義から外れます。JMMStack（JavaScript/Markdown/Markup）とでも呼べるかもしれません。

システム構成について整理したところで、まずは Markdown ファイルのメリデメを考えてみます。

Markdown ファイルを使うメリット

記事を気軽に書ける

エンジニアや、Markdown 形式を普段から使っている人にとっては、記事を気軽に書けるようになることが最大のメリットになると思います。私は以前 WordPress でブログを書いていましたが、少しずつ書くのが億劫になっていく自分がいました。文字の装飾までテキストベースで VSCode で書けるのは快適です。

記事データを改善する機能の追加がカンタン

Markdown はテキストファイルです。なので、textlint を導入して文章の校正を自動化したり、Prettier で自動整形することが手軽にできます。

ヘッドレス CMS では、このような機能が搭載されるのをひたすら待たなくてはなりません。また、textlint の振る舞いの調整をしたいなど細かな調整をするのも難しそうです。

Markdown ファイルを使うデメリット

バグ対応や機能追加はすべて自分でやる

ヘッドレス CMS を使えば、インターフェースとなる API の内側については他人に任せることができます。しかし、Markdown ファイルを自分で保持して処理する場合は、自分一人ですべて対応しなければなりません。バグがないかテストして、バグを修正して、新たな機能が欲しくなったら機能追加する。すべてを自分だけでやります。

記事が増えてきたときにちょっと面倒かも

それほど心配する必要はないかもしれませんが、記事数が増えてくると Markdown ファイル数がそのまま増えていくことになります。数千には届かないと思うので動作速度は心配していません。でも、ひとつのディレクトリに Markdown ファイルが数百入ってくるようになると扱いが少し面倒になる可能性があります。

Markdown ファイルのメリデメを整理したところで、次にヘッドレス CMS を使うメリットを考えてみます。

ヘッドレス CMS を使うメリット

国産ヘッドレス CMS として有名な microCMS の公式ブログに、一般的な CMS（WordPress）に対するヘッドレス CMS のメリットがまとめられていました。

なぜヘッドレス CMS を選ぶのか？ヘッドレス CMS が選定される 7 つの理由

 複数チャネルへの最適なコンテンツ配信
 フロントエンド技術の自由度の高さによるチーム構成の柔軟性
 構造化されたコンテンツ
 セキュリティの担保、スケーラビリティ
 業務の適材適所化
 開発速度の向上
 コンテンツの集約

ヘッドレス CMS のメリットとして挙げられていた上記の点を、以下の 3 点に切り分けてみました。

• 個人ブログでは消滅するメリット
• 静的サイトジェネレータのメリット
• ヘッドレス CMS のメリット

結果、個人ブログにおいてはヘッドレス CMS のメリットはそれほど大きくありませんでした。

個人ブログでは消滅するメリット

個人ブログでは関係者が一人だけです。規模が小さくなるため、Web 以外へのデータ活用や、組織・チームに関連するメリットが消滅します。

• 複数チャネルへの最適なコンテンツ配信：「ウェブ、Android / iOS アプリ、店舗や会社エントランスに配置したサイネージなどさまざまなチャネルにてご利用」可能というメリットです。個人ブログの場合は Web でのコンテンツ配信以外は必要ありません。
• フロントエンド技術の自由度の高さによるチーム構成の柔軟性：ヘッドレス CMS は API がインタフェースになるので、API を叩くフロントエンド側はどんな技術でも採用可能というメリットです。個人ブログなので、そもそもチーム自体が存在しません。ひとりです。

静的サイトジェネレータのメリット

ヘッドレス CMS と Markdown ファイルのどちらにも共通な、静的サイトジェネレータのメリットです。

• セキュリティの担保：WordPress のような動的なシステムは、脆弱性をゼロにできません。静的サイトジェネレータを使った静的なシステムは、プログラムが動作しないため脆弱性が発生しにくいことがメリットです。例え個人ブログに機密情報はなくても、ハッキング(クラッキング)の踏み台にされるリスクがあります。セキュリティリスクを低減するに越したことはありません。
• スケーラビリティ：静的コンテンツのみを扱うため、アクセス数が増えてもサーバーに大きな負荷がかかることなく処理できるというメリットです。また、プログラムの動作環境が不要なため、ホスティングにかかる費用も安いです。
• 開発速度の向上：「チームや個人に慣れ親しんだ技術でそのまま CMS を使ったウェブやアプリを構築でき」るというメリットです。フロントエンド部分を Next.js(React)や Nuxt.js(Vue)で構築する際に発生します。
• 業務の適材適所化(サイトの一部分のみを CMS 化できる)：プログラムの動作環境が不要なので、サイトの一部に静的サイトジェネレータの生成物を配置することで、サイトの一部分を簡単に差し替えられるというメリットです。個人ブログになると、適材適所は関係ないですけど。

ヘッドレス CMS のメリット

• 構造化されたコンテンツ：ヘッドレス CMS では保持するフィールドを自由に定義でき、フィールドの追加や削除も管理画面から簡単に行えるというメリットです。個人ブログでも何かしらの機能拡張をしたい場面は出てくると思いますが、ソースコードの修正が必要になり時間を消費します。しかし、一般的なブログに求められるフィールド（タイトル、本文、タグ、公開/非公開フラグ、作成日、更新日など）以外を追加したくなる場面は少なそうなので、大きなメリットにはならないと思います。

ヘッドレス CMS のメリットは上で挙げた以外にも色々ありそうですが、検討はいったんここまでとしました。

結論

Markdown ファイルを使うメリデメと、ヘッドレス CMS のメリットを考慮した結果、Markdown ファイルを使うことにしました。私にとっては、Markdown ファイルのメリットである記事を気軽に書けることと、記事データの改善機能を自由に追加できることが大きなポイントです。個人ブログを JAMStack にしようとしている方は、ヘッドレス CMS と Markdown ファイルのどちらを採用するか検討してみてください。