先日、こんな趣旨の意見を目にしました。
そもそもCMSは要らないのではないか。
WordPressからヘッドレスCMSへ、という進化の方向ではなく、原稿そのものをGitで管理して静的生成すればいい。
Gitには履歴も差分もレビューもロールバックも権限管理も揃っている。
検索は静的なライブラリで実現でき、規模が大きくなったら検索部分だけ別に逃がせばいい。
編集画面が必要なら、Gitをバックエンドにした画面だけ載せればいい。
読んで、面白い視点だと思いました。そして技術的には正しいと考えています。
ただ、私の見方は少し違います。
CMSが不要になったのではなく、CMSを分解して、つなぎ目の保守を自分で引き受けているのだと思っています。
CMSがやっている6つの仕事
Gitで管理する構成では、これらを1つのCMSにまとめるのではなく、複数の道具に分けて実現します。
そもそもCMSとは何をしている道具なのか。
分解すると、次の5つです。
- 保存 … 原稿をどこかに保持する
- 構造の定義 … タイトル、本文、カテゴリといった項目を決める
- 生成 … 原稿をHTMLとして出力する
- 編集画面 … 書き手が触る場所
- 検索 … 訪問者が記事を探す手段
- 権限 … 誰が何を触れるかを決める
保存はGit、構造はファイル冒頭の設定、生成は静的サイトジェネレーター、編集画面はGit連携のツール、検索は静的な検索ライブラリ。
仕事がなくなったわけではありません。
仕事を担当する道具が分かれただけです。
そして、それぞれをつなぐ部分は自分で面倒を見ることになります。ここが評価の分かれ目です。
この構成が明確に強い点
まず、良いところから。ここは本当に良いです。
変更の履歴が本物になる
「誰が、いつ、どこを、どう直したか」が全部残ります。
CMSにも履歴機能はありますが、Gitの差分表示にはかないません。
1年前の修正理由が追えることの価値は、運用が長くなるほど効いてきます。
公開前のレビューが仕組みになる
原稿を直接公開せず、いったん提案として出し、確認を経てから反映する。
この流れが標準機能として備わっています。
複数人で書くメディアなら、これは相当な強みです。
CMSで同じことをやろうとすると、ワークフロー系の拡張が必要になり、たいてい使いにくいものになります。
戻せる安心感
おかしくなったら、確実に前の状態に戻せます。データベースのバックアップから復元するのとは、心理的な負担がまるで違います。
検索も、実際に成立する
静的サイトの検索は弱点とされてきましたが、状況は変わりました。
ビルド後のHTMLからインデックスを作り、必要な部分だけを読み込む方式のライブラリが実用段階にあります。
日本語についても、単語の区切りに対応しています。
これは使用する検索ライブラリによります。
また、「静的だからサイト内検索ができない」という問題は、現在では必ずしも成立しません。
ビルド後のHTMLからインデックスを作り、必要な部分だけを読み込む方式のライブラリも実用的に使えます。
それでも弱いところ
一方で、正直に書いておきたい点が3つあります。
非技術者が書くとき、壊れ方が厳しい
Git連携の編集画面はよくできています。
使っている間は、普通のCMSと変わらない感覚で書けます。
問題は壊れたときです。 同じ箇所を同時に編集して衝突したとき。
ビルドが失敗したとき。原稿冒頭の設定を書き間違えたとき。
このとき、画面の裏にあるGitの存在が表に出てきます。
書き手は自力で復帰できず、必ず技術者を呼ぶことになります。
CMSは、この点で壊れ方が優しい。保存できないだけで済み、サイトは動き続けます。
画像の置き場所が悩ましい
Gitはテキストの差分管理に特に強く、画像などのバイナリファイルはテキストほど効率よく差分管理できません。
更新のたびに履歴として蓄積され、リポジトリが膨らんでいきます。
専用の仕組みを使うか、外部のストレージに逃がすことになりますが、そこはGitの外側です。
結局、管理する場所が2つになります。
権限を細かく分けられない
CMSのように「このユーザーはこのカテゴリの記事だけ編集できる」といったコンテンツ単位の権限管理は、Gitベースの構成では設計が複雑になります。
「この人は、このカテゴリの記事だけ編集できる」といった指定は表現しにくい。
近いことは実現できますが、あれは確認を求める仕組みであって、編集を制限する仕組みではありません。
書き手が増えて、役割が分かれてくると、ここが効いてきます。
Git管理が向くかどうかは「誰が書くか」で決まる
結局、ここに戻ります。
書き手が全員この仕組みを扱えるなら、Gitで管理する構成は強い。
履歴もレビューも手に入り、余計な保守もなくなります。
技術文書や開発者向けのメディアで採用例が多いのは、条件が完全に噛み合っているからです。
一方、書き手が技術者でないなら、話は変わります。
ドメインの取得でつまずく方に、この構成は渡せません。
渡した瞬間に、更新のたびに誰かがサポートに入ることになり、結果として運用コストは上がります。
同じ問いへの答えが、書き手によって反転する。それだけの話だと思っています。
「不要になった」ではなく、「選べるようになった」
数年前まで、Web上で更新のある仕組みを作るならCMSがほぼ唯一の答えでした。
今は違います。
静的サイトの生成は速くなり、配信の仕組みも安く手に入るようになり、検索の弱点も埋まりました。
選択肢が本当に増えました。
ただ、増えたのは選択肢であって、正解が入れ替わったわけではありません。
「CMSはもう古い」も「やはりCMSが必要だ」も、どちらも「条件」を見ずに結論を出している点では同じです。
条件を見ずに結論を出している点です。
道具に関係なく、正しいこと
この議論で、私が一番大事だと思った部分を書きます。
「CMSを原稿の正本にしなくていい」という指摘です。
ここは、どの道具を使っていても正しい。
原稿がプレーンテキストで手元にあり、変更履歴が残っていて、CMSを捨てても持ち出せる状態にある。
これは移行耐性そのものです。
WordPressを使いながらでも、この状態は作れます。原稿を手元のファイルで書き、それを投稿する運用にしておけば、道具を替えるときの負担は劇的に下がります。
逆に、CMSの中にしか原稿がない状態は、その道具に人質を取られているのと同じです。
ここでいう「正本」とは、元になる原稿データのことです。
ここが一番、真似する価値のある考え方だと思いました。
そして、WordPressを使いながらでも、この状態は作れます。
原稿データと公開システムを分離して考えましょう。
CMSとGit管理、どちらを選ぶかの判断基準
実際に選ぶときは、次の順で確認しています。
- 誰が書くのか … 技術者だけか、そうでない人も含むか
- 何人で書くのか … 1人なら権限の話は不要です
- どれくらいの頻度か … 毎日更新するなら、公開までの手数が効きます
- 画像をどれだけ使うか … 多いなら置き場所を先に決めます
- 3年後、誰が保守するか … ここが一番見落とされます
最後の項目を補足します。
独自に組んだ構成は、組んだ本人がいなくなったときに引き継ぎが難しくなります。
「WordPressです」と言えば通じることの価値は、技術的な優劣とは別の次元で存在します。
この観点も含めた判断については、サイト設計とSEO・AEO｜検索とAIの両方に見つけてもらう構造の作り方にもまとめています。
まとめ
Gitで原稿を管理して静的生成する。
条件が合えば、これは優れた構成です。
私自身、案件によっては積極的に選びます。
ただ、CMSが不要になったわけではありません。
CMSが不要になったのではありません。
CMSという一つの道具にまとめていた仕事を、別々の道具で構成できるようになったのです。
CMSが担っていた仕事は残っていて、それを別の道具の組み合わせで実現しているだけです。
つなぎ目を自分で持てるかどうかが、採用できるかどうかの境目になります。
そして、道具の選択より大事なことがあります。
原稿を、どこにでも持ち出せる形で持っておくこと。
これができていれば、道具はいつでも替えられます。
逆にこれができていないと、どんな構成を選んでも身動きが取れなくなります。
重要なのは、CMSを選ぶことでも、Gitを選ぶことでもありません。
原稿を誰が管理し、誰が公開し、誰が3年後に保守するのかを先に決めることです。