CMSと手動編集を併用して詰んだ話

ブログを運用し始めたとき、最初はDecap CMS（旧Netlify CMS）を使っていました。管理画面から記事を書くと、裏側でGitHubにMarkdownファイルがコミットされる仕組みです。ノーコードで記事が書けて便利だったのですが、しばらくして別の方法（VS Codeで直接編集する、GitHub上でファイルを編集する）も並行して使うようになったところで、地味なトラブルにぶつかりました。

起きたこと

具体的に起きた問題は2つです。

• スラッグの衝突: CMS経由で作った記事と、ローカルで作った記事のファイル名（URLになる部分）が被ってしまい、ビルドエラーが発生しました。CMSは自動でスラッグを生成するため、手動で作ったファイルと名前が重複していることに気づきにくいのです。
• Gitのマージコンフリクト: CMS経由で保存した変更と、ローカルで編集した変更のタイミングが重なり、GitHubのプルリクエストでコンフリクトが発生しました。CMSが裏で自動コミットしていることを忘れて、同じファイルをローカルでも編集してしまったのが原因です。

どちらも「複数の入り口から同じリポジトリを触っている」ことが根本的な原因でした。

「下書き保存」の落とし穴

このタイプのCMSでよくある誤解として、「下書き保存」の仕様があります。

Decap CMSの「下書き保存」ボタンを押すと、非公開の領域に一時保存されるように見えますが、実際にはその時点でGitHubにMarkdownファイルとしてコミットされています。つまり、リポジトリには下書きの内容がすでに存在していて、サイト上で非公開になっているかどうかは、記事のフロントマターに持たせたdraft: trueフラグだけで制御されているのです。

「保存＝まだ表に出ていない」と思い込んでいると、実はもうGit履歴に残っている、ということになりかねません。この仕組みは最初に確認しておくべきでした。

microCMSへの移行

最終的に、CMSをDecap CMSからmicroCMSに移行しました。microCMSはGitベースではなく、API経由でコンテンツを取得する仕組みなので、ローカルのファイル編集と競合する心配がありません。

現在はmicroCMSとMarkdownファイルのハイブリッド構成で運用しています。microCMSで書いた記事とMarkdownで書いた記事を、ビルド時にマージして表示する仕組みです。「書きやすさ」と「事故りにくさ」のバランスが、今のところ一番いいと感じています。

学んだこと

この経験から学んだのは、コンテンツの入り口は一本化するか、競合しない仕組みにするということです。

複数の環境から同じファイルを触る運用は、個人ブログの規模でも簡単に破綻します。CMSを導入する際は、裏側でどういう仕組みで保存されているのかを理解した上で、他の編集方法と干渉しないかを確認しておくことをおすすめします。