「Kurocoを触ってみてくれ」と言われたので、microCMSと真っ向比較してみた

はじめに

社長から「Kurocoというヘッドレスエンタープライズ向けCMSを触ってみてくれ」と言われました。用途は決まっていません。とにかく触ってみて、活用イメージを掴んで報告してくれ、という案件です。

私はこれまでヘッドレスCMSを本格的に触った経験がほぼありません。普段の仕事ではFramerのCMS機能で完結することが多く、API経由でコンテンツを引っ張る系の知見はゼロに近い状態でした。

ただ「Kurocoだけ触っても比較対象がないと評価しづらいよな」と思って、知名度の高いmicroCMSも同じ条件で並走させて触ることにしました。せっかくなのでブログのネタにもしようと。

本記事は、その実機検証の記録です。実際に触り倒した結果と、途中で詰まったエピソードを正直に書いてます。

検証の進め方

検証方針はシンプルに3つだけ決めました。

1. 同じ「articles（記事）」コンテンツ定義を両方で作る

2. 同じNext.js（App Router）から両方のAPIを叩いて並べる

3. 詰まった箇所はそのまま記録する

3番目が大事で、誰かの整った手順書を再現するんじゃなくて、初見で触って何でつまずいたかをそのまま残すのが目的です。

検証範囲はこんな感じ。

ちなみに検証中の課金は両サービスとも0円で完走しました。Kurocoは1,100円/月の無料枠、microCMSはHobbyプランで対応できる範囲でした。

【実験1】Kurocoのアカウント開設〜APIで記事取得まで

サイトキーは後から変更できない

アカウント作成画面で「サイトキー」を入力します。これがエンドポイントURLの一部になります。

https://[サイトキー]

説明文に小さく書かれていたのが「登録後の変更はできません」。これは後で触ったmicroCMSと真逆の仕様で、本番運用前に名前変えたくなったときの柔軟性で差が出るポイントでした。

私は visk-sandbox で登録しました。

管理画面の機能数がエグい

ログインして最初に驚いたのは、左サイドバーの機能の多さでした。

「ECもある」「キャンペーン機能もある」「メンバー管理もある」。ヘッドレスCMSの皮を被ったBaaS（Backend as a Service）、という印象です。

ダッシュボード上部には警告バナーが出ています。

「1,100円/月の無料枠を超えるとAPIが自動的に停止します」

無料枠を超えたら自動停止してくれる。意図しない請求が積み上がる心配がない設計で、これは安心できました。

コンテンツ定義「articles」を作成

サイドバーの「コンテンツ定義」から articles を新規作成。「項目設定」タブを開くと、プリセットで5つのフィールドが既に入っていました。

注目すべきはSlug名の独特さです。title ではなく subject、date ではなく ymd、category ではなく contents_type。これはKurocoの前身であるRCMS（2006年リリース）由来の伝統的な命名で、APIの設計思想がレガシーCMSの延長にあることが透けて見えます。

フィールド型のラインナップ

「項目設定」モーダルでフィールド型のドロップダウンを開くと、ざっと21種類くらい並んでいました。カテゴリ別にこんな構成。

「マスタ形式」「APIフィールド」「地図」あたりはエンタープライズ用途を強く想定した独特なラインナップです。

APIエンドポイントは「自分で設計する」

Kurocoでハッキリ違うと感じたのがAPI設計の思想でした。

microCMSや他のヘッドレスCMSは「コンテンツ定義を作ったら自動でAPIエンドポイントが生える」のですが、Kurocoはそうじゃない。コンテンツ定義とAPIエンドポイントは別物として管理されていて、/rcms-api/1/articles みたいなエンドポイントを自分で設計して追加する必要があります。

エンドポイント追加画面のモデル選択肢にはこんなものが並んでいました。

「EC」「Payments」「承認ワークフロー」「非同期タスク」が標準で並んでいるのを見て、これはコンテンツ管理ツールというより、APIプラットフォームだなと認識を改めました。

コンテンツモデルの内部抽象化

articles 用の一覧APIを作ろうとして、モデル選択で混乱しました。「コンテンツ」を選ぶと、その下の選択肢は Topics / TopicsCategory / TopicsGroup の3種類しかない。

articles という名前で作ったのに、なぜ Topics？

これもRCMS由来で、Kuroco内部ではすべてのコンテンツが Topics という統一モデルで扱われているようです。articles はパスとしての名前であって、内部モデルとしては Topics の1グループ（topics_group_id）として扱われる、という構造でした。

オペレーション一覧で見える「下書き＋承認ワークフロー」

オペレーション選択肢を見て驚きました。1モデルに対して20個近い操作が用意されています。

下書き機能、承認ワークフロー、変更履歴がすべての標準コンテンツに付いてくる。microCMSでは下書きはありますが承認ワークフローはBusinessプラン以上の機能で、Kurocoは無料枠で使えます。

JSON取得は普通にブラウザで叩けた

エンドポイントを /rcms-api/1/articles で作って、ブラウザで叩いたら普通にJSONが返ってきました。

{
  "errors": [],
  "messages": [],
  "list": [
    {
      "topics_id": 3,
      "subject": "Kurocoを触ってみた",
      "ymd": "2026-04-28",
      "thumbnail": {
        "url": "https://visk-sandbox.g.kuroco-img.app/v=1777349709/files/topics/3_ext_1_0.png"
      },
      ...
    }
  ],
  "pageInfo": {
    "totalCnt": 1,
    "perPage": 20,
    ...
  }
}

ここまでで実験1は終了。コンテンツ定義とAPIエンドポイントが別物っていう設計思想だけでも、ヘッドレスCMSとしてはかなり独特な世界観でした。

【実験2】Kurocoの会員管理＋認証API

社長からの「Kurocoはバックエンドみたいなことができるらしい」という言葉の意味を確かめたくて、会員機能を試してみました。

メンバーを作って /login を叩く

メンバー管理から「テスト 太郎」さん（メアド：test@co.jp、グループ：User）を作成。プリセットの /rcms-api/1/login をcurlで叩いてみます。

curl -X POST https://visk-sandbox.g.kuroco.app/rcms-api/1/login \
  -H "Content-Type: application/json" \
  -d '{"email":"test@co.jp","password":"Test1234!"}'

レスポンス：

{
  "grant_token": "29c74243a6...",
  "status": 0,
  "member_id": 4,
  "info": { "validUntil": 1777362924 }
}

grant_token という見慣れないトークンが返ってきました。これは何に使うのか？

Bearer認証で叩く → 失敗

普通のWeb APIの感覚で Authorization: Bearer xxx で叩いてみました。

curl -X GET https://visk-sandbox.g.kuroco.app/rcms-api/1/profile \
  -H "Authorization: Bearer 29c74243a6..."

{"errors":[{"code":"unauthorized","message":"Unauthorized"}]}

弾かれました。

Cookie認証で叩く → 失敗

「もしかしてCookie方式か？」と疑って、-c cookies.txt でCookie保存を試みました。

curl -X POST .../login -c cookies.txt -d '...'
cat

Set-Cookieヘッダ自体が返ってきていない。Cookie方式でもなかった。

公式ドキュメントで判明：3段階認証フローだった

ドキュメントを読み直してわかったのは、Kurocoは3段階の認証フローだということ。

[1] POST /login    → grant_token を取得（ワンタイムトークン）
[2] POST /token    → grant_token を access_token に交換
[3]

しかも、/token エンドポイントはプリセットには含まれていないんです。自分でAPI設定画面から追加する必要がありました。

/token エンドポイントを追加してリトライ

/rcms-api/1/token（モデル：Login、オペレーション：token）を追加して、3段階フローを実行。

GRANT_TOKEN=$(curl -s -X POST .../login \
  -d '{"email":"test@co.jp","password":"Test1234!"}' | jq -r '.grant_token')

ACCESS_TOKEN=$(curl -s -X POST .../token \
  -d "{\"grant_token\":\"$GRANT_TOKEN\"}" | jq -r '.access_token.value')

curl -X GET .../profile \
  -H "X-RCMS-API-ACCESS-TOKEN: $ACCESS_TOKEN"

{"errors":[{"code":"unauthorized","message":"Unauthorized"}]}

まだ通らない。

API構造のセキュリティ設定が「Cookie」のままだった

API管理画面の「セキュリティ」設定を確認すると、デフォルトで Cookie になっていました。KurocoはAPI構造（API Group）単位で認証方式を1つ選ぶ仕組みで、エンドポイントごとに別方式を併用することはできない設計のようです。

選択肢は5種類ありました。

動的アクセストークンに変更して再実行。

{
  "name1": "テスト",
  "name2": "太郎",
  "member_id": 4,
  "group_ids": { "104": "User" },
  "geo_country_code": "JP",
  "geo_region": "27",
  "geo_conn_speed": "broadband"
}

通った。

ちなみに geo_region: "27" は大阪府のISO 3166-2コード。会員のGeoIP情報まで標準で取得できるのはちょっと驚きでした。

この実験で得た最大の教訓

Kurocoの認証フローには、3つのつまずきポイントがありました。

1. 3段階認証（grant_token → access_token → ヘッダ送信）

2. access_token はオブジェクト構造（.value を取り出さないと使えない）

3. API構造単位でセキュリティ方式を1つ選ぶ設計

このどれかを知らずに踏むと401が返ってきますが、エラーメッセージは Unauthorized の一文だけで、何が悪いのか手がかりがない。ドキュメントを読まずに進めると確実にハマります。

寄り道：ECサイトを作る機能まで標準装備

会員機能を触り終わった後、サイドバーの「EC」をクリックしてみたら、完全にECサイト管理ツールの画面が出てきました。

並んでいる項目を見て言葉を失います。

• 商品：SKU設定

• 注文：注文一覧 / 売上・配送管理 / 定期購入管理 / かご落ちリスト

• レポート：売上集計 / 売上ランキング / ポイント履歴 / 定期購入者数集計

• 設定：店舗情報 / 支払い方法 / 販売方法 / 有料会員 / ポイント / クーポンコード

「定期購入管理」「かご落ちリスト」「ポイント履歴」あたりは、本気のECサービスでしか使わない機能群です。これがヘッドレスCMSのおまけで付いてきている。

今回は実機検証していないので深くは触れませんが、コンテンツ管理 + 会員管理 + EC + 認証 が1つの管理画面で完結するっていう構造は、microCMSや他のヘッドレスCMSとは設計思想が完全に違うところでした。「Kurocoはバックエンドみたいなことができる」という社長の言葉の意味は、ここまで含めての話だったんだな、と納得しました。

【実験3】microCMSのアカウント開設〜APIで記事取得まで

Kurocoの後、microCMSに移りました。Kurocoとの違いがいくつも見えて面白かったです。

サインアップ〜サービス作成は数分

メアドとパスワードでサインアップ → サービス作成画面 → 「一から作成する」を選択。

サービス名 VISK検証用、サービスID n5z4aeiu0f(自動生成のまま)で作成。

ここでKurocoとの違いを2つ発見しました。

1. サービスIDは後から変更可能（Kurocoは変更不可）

2. サービスIDが自動生成されている（Kurocoは自分で考えて入力）

API作成は3ステップウィザード形式

「自分で決める」を選ぶと、3ステップのウィザードでAPI作成が進みます。

「リスト形式」と「オブジェクト形式」の選択肢があるのが面白い。Kurocoは全コンテンツを統一の Topics モデルで扱いますが、microCMSは用途で型を分ける思想です。

フィールド型はシンプル路線

ステップ3でフィールド型のドロップダウンを開くと、14種類が並んでいました。

注目点：

• 「旧リッチエディタ」が非推奨マーク付きで残っている（後方互換への配慮）

• 「ファイル」がHobbyプランでロックされている

• 全体的に**「コンテンツ管理に必要な機能に絞った」シンプルさ**

プリセットフィールドはゼロ

スキーマ定義画面の説明文：

「コンテンツID（id）や各種日時（createdAt, updatedAt, publishedAt, revisedAt）は自動的に作成されます」

つまりシステム的に必要なメタデータは自動生成、それ以外のフィールドは全部自分で定義。Kurocoのプリセット5項目とは対照的でした。

私は最低限のフィールドだけ作りました。

英語ID（API用）と日本語表示名（UI用）が完全に二重構造で必須になっているのも、Kurocoとの違い（KurocoはSlugが任意）。

APIキー1個で取得完了

記事を1本入稿してAPIキーを取得 → curlで叩く。

curl -X GET https://n5z4aeiu0f.microcms.io/api/v1/articles \
  -H "X-MICROCMS-API-KEY: xxxx"

{
  "contents": [
    {
      "id": "oazr5-l20mz5",
      "createdAt": "2026-04-28T07:14:33.246Z",
      "updatedAt": "2026-04-28T07:14:33.246Z",
      "publishedAt": "2026-04-28T07:14:33.246Z",
      "revisedAt": "2026-04-28T07:14:33.246Z",
      "title": "<p>microCMSを触ってみた</p>",
      "body": "<p>microCMSを触ってみた本文</p>",
      "thumbnail": {
        "url": "https://images.microcms-assets.io/...",
        "height": 1536,
        "width": 2816
      }
    }
  ],
  "totalCount": 1,
  "offset": 0,
  "limit": 10
}

APIキー1個で完結。Kurocoの3段階認証と比べると、シンプルさが際立ちます。

【実験4】Next.jsで両者を並べてみた

両方の存在感を直接比較するため、Next.js（App Router）で2カラムの比較画面を作りました。Claude Codeに実装を任せて、サーバーサイドで認証情報を扱うシンプルな構成にしています。

実装中の発見：Kurocoのaccess_tokenはオブジェクト構造

実装直後、Kurocoだけ401エラーが返ってきました。

Kuroco fetch failed: 401 Unauthorized -
{"errors":[["[GW]

curlでは通っているのに、Next.jsから叩くと通らない。原因はレスポンス構造の解釈にありました。

/token のレスポンスはこうなっています。

{
  "access_token": {
    "value": "実際のトークン文字列",
    ...
  }
}

access_token がオブジェクトで、.value を取り出さないと使えない。最初の実装では access_token を文字列として扱っていたため、ヘッダに渡すときに [object Object] という文字列に変換されて認証エラーになっていました。

// 修正前
const accessToken = json.access_token  // ← オブジェクトのまま

// 修正後
const accessToken = json.access_token?.value  // ← .value を取り出す

この1行の差で動くようになりました。Kuroco固有のレスポンス構造を踏まえれば、回避自体は単純です。

完成画面

最終的にこうなりました。

[microCMS]                          [Kuroco]
status: 200                         status: 200
duration: 41.2 ms                   duration (total): 620.3 ms
                                    duration (list only): 572.3 ms
GET /api/v1/articles?limit=10       login → token → GET /articles?cnt=10

[microCMSの生JSON]                  [Kurocoの生JSON]
{                                   {
  "contents": [...],                  "errors": [],
  "totalCount": 1,                    "messages": [],
  "offset": 0,                        "list": [{...}]

数値で比較するとこんな感じ。

速度差は約15倍。ただしKurocoは認証付きなので、単純比較はフェアじゃないです。

比較まとめ

検証で見えた両者の特徴を整理します。

レスポンス構造の違い

両者で返ってくるJSONを見比べると、設計思想の違いが鮮明でした。

microCMS：表示に必要な最小限のフィールドのみ

{
  "id": "...",
  "title": "...",
  "body": "...",
  "thumbnail": { "url": "...", "height": ..., "width": ... },
  "createdAt": "...",
  "publishedAt": "...",
  "revisedAt": "..."
}

Kuroco：管理画面で扱うすべてのフィールドをそのまま返却

{
  "topics_id": ...,
  "subject": "...",
  "contents": "...",
  "topics_flg": ..., "open_flg": ..., "regular_flg": ...,
  "inst_ymdhi": "...", "update_ymdhi": "...",
  "topics_group_id": ..., "member_id": ...,
  "group_nm": "...", "group_description": "...",
  "contents_type_cnt": ..., "contents_type_nm": "...",
  "contents_type_ext_col_01": null,
  "contents_type_ext_col_02": null,
  ... (拡張フィールド01〜05、すべてnull)
  "thumbnail": { "id": "...", "url": "...", "desc": "...", "url_org": "..." }
}

microCMSはJavaScriptエコシステム的、KurocoはRDB/レガシー命名っていう対比が鮮明でした。

機能の有無

KurocoはヘッドレスCMSというよりBaaSに近い。microCMSはコンテンツ管理に特化してます。

用途別の判断軸

検証の結果、以下のような判断軸が見えてきました。

microCMSが向いてそうなケース

• お知らせ・ブログ・事例ページの更新がメイン

• 編集者が非エンジニア中心

• 月額が定額で予算組みやすい方が良い

• 学習コストを最小化したい

• フロントエンドはチームで作る前提

Kurocoが向いてそうなケース

• 会員制サイトや顧客ポータルを作る

• パーソナライズ配信が必要

• 業務システムや会員DBと連携したい

• 監査ログ・SAML認証など堅いセキュリティ要件がある

• アクセス少ない時期は無料枠で運用したい

• バックエンド構築コストを削減したい

料金感の違い

Kurocoは完全従量課金、microCMSは定額制という根本的な違いがあります。

Kuroco：1,100円/月の無料枠あり、超過すると自動停止。<br> microCMS（2025年6月改定）：Hobby無料 / Team 4,900円〜 / Business 75,000円〜

シンプルなブログだけならmicroCMS Hobbyで十分、会員機能と承認ワークフローまで使うならKurocoの無料枠の方が機能的に勝る、っていう逆転現象が起きます。用途次第で安いサービスが入れ替わるのが面白いところ。

残った疑問・未検証事項

検証した範囲は限定的なので、未確認のまま残った疑問を正直に書いておきます。

• Kurocoの静的アクセストークン方式は試していません。検証では「動的アクセストークン方式」を選んだので、静的方式の使い勝手・セキュリティ特性は不明

• KurocoのEC機能・フォーム機能・承認ワークフローは管理画面で項目があるのを見ただけで、実機検証してません

• microCMSのカスタムフィールド・繰り返しフィールドは今回触ってません（API作成後に追加可能ですが時間切れ）

• 本番運用での課金額シミュレーションは別途必要。検証のJSON取得程度では両者とも0円のままでした

• Framer連携は今回見送りました。Kurocoの動的アクセストークン方式はサーバーサイド前提で、Framerのクライアントコードコンポーネントから直接叩くと認証情報がブラウザに露出する問題があります。BFF（Backend for Frontend）を別途構築すれば連携可能ですが、そこは別記事で扱いたい

• MCPサーバー化機能（KurocoがAPIをMCPサーバーとして公開できる機能）も未検証。Claude Code等のAIから直接Kurocoを叩く未来形のフローで、興味深いポイントですが今回は時間が取れませんでした

おわりに

「Kurocoを触ってみてくれ」から始まった検証でしたが、結果として**「KurocoとmicroCMSは比較するもののジャンルが違う」**っていうのが正直な感想です。

microCMSはコンテンツ管理ツールとしてシンプルかつ完成度が高く、KurocoはAPIプラットフォームとして応用力が高い。「どちらが優れているか」じゃなくて**「何を作りたいか」で選ぶ**サービスでした。

具体的にどこで使うかは、これから案件ベースで考えていきます。本記事が同じく検証中の方の参考になれば幸いです。

検証日：2026年4月28日<br> 課金額：0円（両サービスとも無料枠内）