はじめに
ヘッドレスCMSを使っていると、コンテンツ更新はしやすい一方で、UIの構成変更はフロントエンド実装が必要になることが多いと感じています。
そのギャップを小さくできるかを見たくて、json-render と microCMS の組み合わせを試しました。この記事は「こうするべき」という話ではなく、あくまで検証してみた中での観察メモです。
公式リポジトリ: json-render (GitHub)
自分なりの理解
今のところ、json-render は「UIをJSONで表現して描画する仕組み」と理解しています。
- コード側: 使える部品（コンポーネント）を用意する
- JSON側: その部品をどう組み合わせるかを定義する
この捉え方だと、「実装をゼロにする」というよりは、UI構成の一部を運用側で触れるようにするための道具、と考えるとしっくりきました。
最小コード例（イメージ）
例えば、部品を定義して、spec で組み合わせると次のような形になります。
import { defineCatalog } from '@json-render/core';
import { schema } from '@json-render/react/schema';
import { z } from 'zod';
const catalog = defineCatalog(schema, {
components: {
Section: { props: z.object({ title: z.string() }) },
Metric: { props: z.object({ label: z.string(), value: z.string() }) },
},
actions: {},
});
const spec = {
root: 'root',
state: { page: { title: 'Example' } },
elements: {
root: {
type: 'Section',
props: { title: { $state: '/page/title' } },
children: ['m1'],
},
m1: {
type: 'Metric',
props: { label: 'STATUS', value: 'ok' },
children: [],
},
},
};実際の運用では、この spec を CMS で管理する形になります。
microCMS と合わせると何が変わるか
microCMS に JSON spec を置き、アプリで読み込んで描画する形にすると、次のような変更は比較的やりやすくなりました。
- ブロックの表示順を変える
- 特定ブロックを一時的に表示/非表示にする
- 見出しや導線文言を差し替える
- 同じデータに対して見せ方を変える
ここは誤解しやすいですが、データを変える話というより、同じデータの見せ方を変えやすくする話に近いです。
試す余地があると感じた場面
以下は「こういう運用要件があるなら」という前提付きです。私の検証では、次のような条件がある場合に検討余地があると感じました。
- UI構成の微調整が継続的に発生する
- 小さな見せ方の検証を短いサイクルで回したい
- 部品実装（開発）と構成変更（運用）を分けたい
逆に、構成変更がほとんどない場合は、従来の固定テンプレート運用の方が素直だと思います。
試してみて一番気になった点
生の JSON spec は、編集者にとってはやはり複雑でした。どこを触ると何が変わるかが分かりにくく、運用負荷が上がりやすいです。
自分の検証では、次の二層に分けると扱いやすくなりそうでした。
- 編集用のシンプルな入力項目（初期表示、見出し、表示ON/OFFなど）
- その入力から実行用 spec を生成する層
この形なら、JSONを直接編集しない運用に寄せやすいと感じています。
いまの時点でのまとめ
json-render × microCMS は、個人的には「必ず使うべきもの」ではなく、要件によって効く場面が分かれる選択肢だと感じました。
「同じデータを状況で見せ分けたい」「UI構成の変更を運用側でも扱いたい」という要望があるなら、試してみる価値はあるかもしれません。逆に、その要望が薄ければ従来構成の方が素直です。