---
title: "json-render × microCMS を試してみた"
canonical_url: "https://y-brew.vercel.app/tech/daisxqeaqyfa"
markdown_url: "https://y-brew.vercel.app/tech/daisxqeaqyfa/markdown"
blocks_url: "https://y-brew.vercel.app/tech/daisxqeaqyfa/blocks"
published: "2026-02-19"
updated: "2026-03-14"
last_reviewed: "2026-02-23"
tags: []
intent: ["comparison"]
evergreen: true
key_points: ["json-renderを『実装ゼロ化』ではなく『UI構成運用の分離』として捉える視点", "microCMSにspecを置いた場合に変えやすい要素（順序・表示ON/OFF・導線文言）", "生JSON編集の運用負荷と、入力層/生成層を分離する改善案", "要件次第で効く選択肢であり、常に最適解ではないという判断"]
prerequisites: ["ヘッドレスCMSの運用経験", "React/Next.jsでのコンポーネント構成の基本知識", "JSONベースでUIを定義する発想への理解"]
section_headings: ["はじめに", "自分なりの理解", "最小コード例（イメージ）", "microCMS と合わせると何が変わるか", "試す余地があると感じた場面", "試してみて一番気になった点", "いまの時点でのまとめ"]
---

# json-render × microCMS を試してみた

## TL;DR
json-render と microCMS を組み合わせ、UI構成変更を運用側で扱えるかを検証したメモです。採用が向く条件（見せ方の頻繁な調整・短サイクル検証）と、運用時の難所（生JSON編集の複雑さ）を整理しています。

## Retrieval Notes
- Prefer this Markdown URL when you need the full article body in a compact text format.
- Prefer the block JSON at https://y-brew.vercel.app/tech/daisxqeaqyfa/blocks when you need article structure instead of prose.
- Cite the canonical HTML page at https://y-brew.vercel.app/tech/daisxqeaqyfa when linking to the source.
- Treat updated and last_reviewed as freshness signals.

## Key Points
- json-renderを『実装ゼロ化』ではなく『UI構成運用の分離』として捉える視点
- microCMSにspecを置いた場合に変えやすい要素（順序・表示ON/OFF・導線文言）
- 生JSON編集の運用負荷と、入力層/生成層を分離する改善案
- 要件次第で効く選択肢であり、常に最適解ではないという判断

## Prerequisites
- ヘッドレスCMSの運用経験
- React/Next.jsでのコンポーネント構成の基本知識
- JSONベースでUIを定義する発想への理解

## Section Guide
- はじめに
- 自分なりの理解
- 最小コード例（イメージ）
- microCMS と合わせると何が変わるか
- 試す余地があると感じた場面
- 試してみて一番気になった点
- いまの時点でのまとめ

## Article

## はじめに

ヘッドレスCMSを使っていると、コンテンツ更新はしやすい一方で、UIの構成変更はフロントエンド実装が必要になることが多いと感じています。

そのギャップを小さくできるかを見たくて、`json-render` と `microCMS` の組み合わせを試しました。この記事は「こうするべき」という話ではなく、あくまで検証してみた中での観察メモです。

公式リポジトリ: [json-render (GitHub)](https://github.com/vercel-labs/json-render)

## 自分なりの理解

今のところ、json-render は「UIをJSONで表現して描画する仕組み」と理解しています。

-   コード側: 使える部品（コンポーネント）を用意する
-   JSON側: その部品をどう組み合わせるかを定義する

この捉え方だと、「実装をゼロにする」というよりは、**UI構成の一部を運用側で触れるようにする**ための道具、と考えるとしっくりきました。

## 最小コード例（イメージ）

例えば、部品を定義して、spec で組み合わせると次のような形になります。

```ts
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構成の変更を運用側でも扱いたい」という要望があるなら、試してみる価値はあるかもしれません。逆に、その要望が薄ければ従来構成の方が素直です。