microCMS・Newt・WordPress REST API比較：日本の中小サイト向け現実解

結論から言うと、美容室や店舗ビジネスの中小規模サイトでヘッドレスCMS（コンテンツ管理と画面表示を切り離す構成）を選ぶなら、判断基準は「機能の多さ」ではなく「更新者のITリテラシー」と「既存資産の有無」の2つに絞ってよい。具体的には、すでにWordPressでブログ記事の資産があるなら**WordPress REST API**をそのままAPIサーバーとして使い、店舗情報・メニュー・スタッフ紹介のような構造化データを新規で作るなら**microCMS**、そしてNewtのような新しいサービスは今の時点では小規模サイトの実務導入には慎重であるべき、というのが現実的な結論になる。

この記事では、実際に自社商品としてヘッドレスCMS構成のサロン向けテンプレートを開発した経験と、自社サイト（graciauto.jp）をヘッドレス構成に再構築した経験の2つを一次情報として、なぜその選択に至ったかを実務目線で解説する。

3つの選択肢の位置づけ

まず前提として、3つはそれぞれ役割が違う。

• **WordPress REST API**：既存のWordPressをそのまま「記事データを返すAPIサーバー」として使う方式。画面表示（テーマ）は使わず、AstroやNext.jsなど別のフロントエンドが記事データを取りに行く。ブログ運用者はWordPressの管理画面をそのまま使い続けられるのが最大の利点。
• **microCMS**：日本製のヘッドレスCMS専業サービス。店舗情報・メニュー・スタッフ・求人情報のように、記事本文とは違う「型が決まったデータ」を管理するのに向いている。管理画面もフィールド設計も日本語で完結し、国内の制作会社での採用実績が多い。
• **Newt**：microCMSと同じ国内発のヘッドレスCMSで、GraphQLベースの取得や複数言語対応など機能面では後発の強みを持つ。ただし国内制作会社での採用事例・ノウハウの蓄積はmicroCMSに比べてまだ薄く、外注先やフリーランスに依頼したときに「触ったことがある人」に当たる確率が低い。

この3つを「どれが優れているか」で比べるのは実務上あまり意味がない。実際に手を動かした2つの案件から、判断基準を具体的に見ていく。

実例1：美容室向けテンプレート商品でmicroCMSを選んだ理由

自社で「30〜50万円相当のクオリティを10万円で提供する」という美容室向けホームページテンプレート商品を開発した際、技術構成は次のように決めた。

“`

フロント：Next.js App Router + Tailwind CSS

CMS　　：microCMS（サロン情報・メニュー・スタイリスト・スタイル写真・求人）

ブログ　：WordPress（REST API経由でヘッドレス利用）

画像　　：microCMS Image API

“`

ポイントは、店舗データとブログ記事でCMSを使い分けたことだ。サロンの基本情報・メニュー表・スタイリスト紹介のようなデータは「フィールドの型が決まっている」ため、microCMSのスキーマ機能（siteConfig・menu・stylist・style・recruitなど、項目ごとに型を定義する仕組み）と相性がいい。一方でブログは自由記述の長文コンテンツであり、かつ将来クライアントが自分で更新することを考えると、すでに使い慣れているWordPressの編集画面を変えない方が現場の混乱が少ない。この「データの型ごとにCMSを使い分ける」という発想が、3つのサービスを比較する上で一番実務に効く判断軸になる。

実装段階では、事前検証で気づいた制約も一つあった。WordPressの画像管理プラグインを無料版で使った場合、REST APIが返すのは画像のIDだけで、実際の画像URLは別リクエストで取得し直す必要がある。これは想定外のトラブルというより、無料版プラグインの仕様として最初から想定しておくべき点で、実装時は`/wp/v2/media?include=…`のようなエンドポイントで画像を一括取得してから記事データに解決するという設計を先に組んでおけば、追加の手戻りは発生しない。ヘッドレス構成でWordPressを画像込みで使う場合は、この「画像IDとURLの二段階取得」を最初から設計に入れておくことをおすすめする。

実例2：自社サイトの再構築でWPGraphQLではなくREST APIを選んだ理由

自社サイト（graciauto.jp）自体もヘッドレス構成での再構築を進めているが、そこではWordPress REST APIを選び、WPGraphQL（GraphQL形式で取得する拡張プラグイン）はあえて採用しなかった。理由は次の3点に整理できる。

1. **既存の記事資産がWordPressにある**：新規にCMSへデータを移し替えるコストと、記事が持つ検索評価（被リンク・掲載順位）を維持するリスクを天秤にかけると、既存のWordPressをそのまま使う方が合理的だった。

2. **運用の複雑さを増やさない**：GraphQLはクエリの自由度が高い分、フロントエンド側の実装・デバッグの学習コストも上がる。記事数が数百規模で更新頻度も低い中小サイトでは、その複雑さに見合うメリットが出にくいと判断した。

3. **量産・外注化のしやすさ**：この構成を他社案件にも横展開するテンプレートにする方針があり、学習コストが低い技術ほど外注先に引き継ぎやすい。REST APIは情報量も多く、実装できるエンジニアの母数も多い。

なお、フロントエンドの技術選定でもNext.jsではなくAstro（静的サイト生成に強いフレームワーク）を選んでいる。理由は、既存の運用がビルドしたファイルをFTPで転送する方式であり、Next.jsが得意とする「アクセスのたびにサーバーで生成し直す」構成にすると常時稼働のサーバーが別途必要になり、自社サーバー運用の方針と噛み合わなかったためだ。美容室や店舗のホームページ・LP・ブログは更新頻度が低く動的な機能も薄いため、静的サイト生成（あらかじめHTMLを作っておいて配信するだけの方式）で十分というのも判断材料になっている。

この構成で特に注意したのが、検索エンジンからの見え方だ。ヘッドレス構成をJavaScript側で記事本文を描画する方式（CSR）で組んでしまうと、記事ページの生HTMLに本文が存在せず、検索エンジンが正しく評価できないサイトになるリスクがある。これを避けるための正しいやり方は、ビルド時にWordPressから記事データを取得して、本文入りのHTML・正しいcanonicalタグ・OGP・サイトマップへの個別URL掲載までを一度に静的ファイルとして焼き込んでおくことだ。表示だけモダンで中身が検索に載らない、という状態を防ぐには、この「ビルド時に全部仕込む」設計を最初の段階で決めておく必要がある。

もう一つ想定しておくべきリスクが、更新の反映タイミングだ。静的サイト生成は記事を保存した瞬間にサイトへ反映されるわけではなく、再ビルドが完了するまでのタイムラグが発生する。これを避けるには、WordPress側の保存操作をきっかけに自動で再ビルドを走らせる仕組みと、念のための定期実行（1日1回程度のcron）の両方を用意しておくのが安全だ。片方だけだと、ビルドが失敗したときに記事が反映されないまま気づかない、という事態につながりやすい。

中小サイトの判断基準：3つの質問で決める

これまでの2つの経験から、美容室・店舗ビジネスの現場で使える判断基準を3つの質問に落とし込める。

**1. 更新するのは誰か？**

現場スタッフやオーナー自身が記事を書くなら、すでに使い慣れたWordPressの管理画面を変えない方がいい。制作会社や専任担当者だけが更新するなら、microCMSのような専業サービスの方が管理画面がシンプルで扱いやすい。

**2. 管理したいデータは自由記述か、型が決まったデータか？**

ブログのような長文コンテンツはWordPressのままで十分機能する。店舗情報・メニュー表・スタイリスト紹介・求人情報のように項目が決まっているデータは、microCMSのスキーマ機能で管理する方が入力ミスも減り、複数店舗展開時の横展開もしやすい。

**3. 外注・引き継ぎの可能性はあるか？**

将来的に別の制作会社や担当者に引き継ぐ可能性があるなら、採用実績と情報量が多い技術を選ぶ方がリスクが低い。WordPress REST APIとmicroCMSはどちらも国内での採用事例・解説記事が豊富で、担当者が変わっても引き継ぎやすい。Newtのような新しいサービスは機能面で優れていても、対応できる制作会社・エンジニアの絶対数がまだ少なく、この観点では現時点では慎重な判断が必要になる。

まとめ

microCMS・Newt・WordPress REST APIは「どれが最強か」を比べる関係ではなく、扱うデータの性質と更新者のスキルによって使い分けるものだ。中小規模の店舗サイトであれば、ブログ資産はWordPress REST APIでそのまま活かし、店舗情報のような構造化データが必要な場合だけmicroCMSを追加する、という組み合わせが最も手戻りが少ない。新しいサービスに飛びつく前に、「今のデータと更新者を前提にしたときに、本当に移行コストを払う価値があるか」を先に問うことが、ヘッドレスCMS選定で失敗しないための一番の近道だ。