このブログは、既製のブログサービスではなく、自分たちで作った CMS @nano-cms/core の上で動いています。世の中に CMS はいくらでもあるのに、なぜ作ったのか。便利機能を並べる話ではなく、「どこで、何を選んだか」という設計判断の話をします。エンジニアの方なら、同じ岐路に立ったときの参考になるかもしれません。

欲しかったのは「安心して運用できる」土台

ブログ運用で地味に効いてくるのは、派手な機能よりも足回りの安心感です。書きかけを保存しても本番に漏れない。間違えても前の状態に戻せる。公開する前に「実際どう見えるか」を確かめられる。複数人で回しても事故らない。公開してから反映までが速い ―― こうした性質を、後付けの工夫ではなく土台そのもので持ちたい、というのが出発点でした。これらを満たす既製品を組み合わせて運用でつぎはぎするより、核心の数点を自分たちで設計したほうが、長く使うほど効いてきます。

そこで置いた賭けが、大きく 3 つあります。

賭け その1 ― コンテンツを「Git の上」に置く

ひとつ目は、記事をデータベースの 1 行としてではなく、エンジニアが日々使っている Git の仕組みの上で管理する、という選択です。コンテンツをコードのように扱えると、版管理・差分・巻き戻し・並行編集の統合といった機能が、わざわざ作り込まなくても“標準装備”でついてきます。

編集は本番とは別の作業用の領域で行い、公開済みの版と混ざらないようにします。複数人が同じ資材に手を入れても、大半は自動でひとつにまとまります。「うっかり下書きが本番に出る」「誰かの修正を上書きしてしまう」といった、運用でいちばん怖い事故を、仕組みのレベルで起きにくくしているわけです。

賭け その2 ― 公開は「静的に焼いて、エッジから配る」

ふたつ目は配信の方式です。アクセスのたびにページをその場で組み立てるのではなく、公開のタイミングで HTML を作り置きし、世界中に分散したエッジ（Cloudflare Workers）から配ります。読者には常に作り置きの軽いページが届くので表示が速く、配信側が混んでも落ちにくく、攻撃にも強い。公開ボタンを押してから実際に反映されるまでは、十数秒ほどです。

「速さ」と「安定」と「安全」を同時に取りにいくと、動的に組み立てる方式よりも、静的化＋エッジ配信のほうが素直に効きました。なぜこの 3 つが同時に成り立つのか、その理由と実測値は なぜ速くて、落ちなくて、狙われにくいのか ― ケイズのCMSの静的配信 に、「動くプログラムではなくファイルとして届く」という届け方の仕組みは 記事は「プログラム」ではなく「ファイル」として届く にまとめています。

賭け その3 ― 「汎用コア」と「自社固有」を分ける

みっつ目は、作り方そのものの設計です。CMS のうち、どんなサイトにも共通する普遍的な部分を汎用ライブラリ（コア）として切り出し、ケイズ固有の事情はその上に薄く乗せる構造にしました。コアは「自社のことを何も知らない」状態に保たれ、サイト側がコアに必要なものを渡して動かします。

こうしておくと、将来べつのサイトを作るときにも同じコアを使い回せますし、固有の都合でコアが汚れていくのを防げます。少し手間のかかる分け方ですが、ひとつの製品を長く育てるなら、ここを最初に決めておく価値は大きいと考えました。

既製品の 8 割でなんとなく回すより、自分たちが本当に欲しい 10 割を、土台から積む。手はかかりますが、毎日の運用がそのぶん静かになります。このブログ自体が、その土台の上で書かれ、確かめられ、配られています。ケイズのCMSが「公開した後」でどう違うのか、その全体像は 似ているようで、公開後がまるで違う ― ケイズのCMSの選びどころ にまとめています。