ヘッドレスCMSのメリットが長年ピンとこなかった理由と、MCPで変わったこと
ヘッドレスCMSという言葉が出てくるたびに、ずっとモヤモヤしていました。
「デザインの自由度が高い」「フロントエンドの選択肢が広がる」「APIベースで柔軟」。どの記事を読んでもこういう説明が並ぶのですが、BtoBのサービスサイトやコーポレートサイトを作っている自分には、正直なところ響かなかったんですよね。
理由がうまく言語化できないまま何年も過ぎて、ようやく最近になって腑に落ちたので書いておきます。
「デザインの自由度が高い」はエンジニアの話だった
ヘッドレスCMSの紹介で必ず出てくる「デザインの自由度が高い」という表現。正確に言い換えると、「CMSがデザインの実装に干渉しない」という意味だったんですよね。
これはWordPressの既製テーマと比較した場合にだけ成立する主張で、WordPressでもゼロベースでテーマを組めばデザイン上の制約はほぼありません。しかもヘッドレスCMSも製品ごとに固有のデータ構造やフィールドの作法があって、制約がゼロになるわけではない。
つまり「デザインの自由度」はデザイナー向けの話ではなく、実装するエンジニアにとっての自由度の話だった。ここがずっと噛み合わなかったんだと思います。
「フロントエンドの選択肢が広がる」の実態
もうひとつよく言われるのが「フロントエンドの選択肢が広がる」。WordPressはPHPで出力するのでPHP＋jQueryの世界に縛られるけれど、ヘッドレスCMSならAPIでデータだけ返すから、Next.jsでもNuxtでもAstroでもモバイルアプリでも自由に選べるという話です。
技術的にはそのとおりなのですが、BtoBのサービスサイトやコーポレートサイトで、フレームワークの選択が案件の成否を左右するケースってどのくらいあるのかと考えると、あまりないんですよね。これもやはりエンジニアの技術的快適さの話であって、発注側のマーケティング担当者が決められる（指定できる）事ではないですね。
MTユーザーにピンとこなかった本当の理由
CMPはWordPressを扱わないわけではありませんが、自分が長年使ってきたMovable Type（MT）の設計思想の視点で考えると、ピンとこなかった理由はもっと根本的なところにありました。
MTは静的サイト生成です。ビルド時にHTMLを吐き出して終わり。一方、ヘッドレスCMSの説明は「APIでデータを返してフロントが受け取る」という動的なやり取りが前提になっている。そもそもの前提としている技術スタックが根本的に違うので、概念自体が噛み合わなかったわけです。ピンとこなかったのは理解力の問題ではなく、前提が違っていたということなんだと思います。
実際、ヘッドレスCMSの公開方式を整理してみると、SSG（静的サイト生成）はまさにMTがやっていることと同じです。コンテンツを更新したらビルドして静的HTMLを配置する。MTの「再構築」と呼ばれていた処理がそれにあたります。独自タグの学習コストや再構築スピードの問題はあったにせよ、やっていること自体はヘッドレスCMS＋SSGの構成と本質的に同じだった。
つまり、MTでBtoBのサービスサイトやコーポレートサイトを構築・運用してきたことは、時代に乗り遅れていたわけではなかった。SEO対策のチューニングやセキュリティの堅さといった、静的生成ならではの強みを活かしてきた実績がある。そのことを、ヘッドレスCMSの構成パターンを改めて整理する中で再確認できたのは、個人的にはかなり大きかったです。
MCPが変えたこと
では、なぜ今になってヘッドレスCMSに注目しているかというと、MCP（Model Context Protocol）の登場が状況を変えたからです。
ヘッドレスCMSのAPIを活用した定型記事の自動生成は、技術的にはMCP以前から可能でした。ただし、それができるのはAPIを叩けるエンジニアで、非エンジニアのマーケターやコンテンツ担当者による運用に乗せるのはかなりハードルが高いと、わたし個人は考えます。
MCPが変えたのは「誰が使えるか」です。技術的にできることは変わっていません。変わったのは、自然言語で指示するというインターフェースが生まれたことで、非エンジニアがAPIの恩恵を受けられるようになったこと。ここが本質的な変化だと感じています。
実際に動かしてみた
理屈だけでは説得力がないので、実際にやってみました。
構成は、Backlog（タスク管理）＋NILTO（ヘッドレスCMS）＋Claude（AIエージェント）＋Googleドライブ（素材格納）。この4つをMCPで接続しています。ただし、Googleドライブについては今回の実験ではMCP経由での素材取得を活用するところまでは至りませんでした。
現時点でできることを正確に言うと、AIからCMSやタスク管理ツールを操作する方向の連携です。少なくとも自分が実験した範囲では、CMS側やBacklog側からAIを呼び出す仕組みは実現できていません。あくまで「人間がAIに指示を出し、AIが複数のツールを横断して作業する」という構成です。
人間がBacklogに課題を起票して、企業名、業界カテゴリ、掲載内容の概要、素材の格納先を記載して、担当者に通知する。ここまでは従来のWeb制作と何も変わりません。この先で何か自動化の一歩を踏み出せないかをClaudeに相談してみました。
その結果、2つの方法を提示されました。そのうち、画像素材を事前にNILTOのメディアライブラリにアップロードしておき、テキスト入稿とBacklogへの完了報告をAIに任せる方法を実験することにしました。現時点では、少なくとも自分が確認した範囲で、MCP経由での画像アップロードに対応しているヘッドレスCMSは見つけられておらず、ここだけは手作業が残ります。
AIに入稿内容を指示します。企業名、カテゴリ、原稿テキスト、画像素材の参照先を伝えると、AIがNILTOに下書きを作成します。タイトル、カテゴリタグ、本文、メディアライブラリ内の画像の紐付け、SEO情報まで一括で入ります。
入稿が完了すると、AIがBacklogの課題にコメントを投稿します。「NILTOに下書き作成済み。管理画面URL：https://…」という報告と、入稿内容に問題があればその懸念点も含めて記載されます。指定したメンバーに通知も飛びます。
実際にテスト投稿をした際、AIがフィールド名のマッピングを間違えて本文が空になったことがありました。ただ、AI自身がその問題を検証段階で検出して、Backlogへの報告に「本文が空です。フィールド名の指定に問題があります」と含めてきた。つまり単なる作業代行ではなく、品質チェック付きの作業報告になっている。ここには正直驚きました。
クライアントから見える景色
この構成のポイントは、クライアントから見るとBacklogしか見えないということです。AIの存在もヘッドレスCMSの存在も、クライアントには意識させる必要がありません。
課題を起票して、進捗をBacklogで確認して、完了報告を受け取る。この体験は従来の制作会社への依頼と何も変わらない。裏側でAIがCMS入稿を担っていることは、作業履歴の投稿者名が違うくらいでしか表に出ません。
将来的には、クライアントがBacklogのコメントに「2段落目の表現を○○に変えて」と書けば、AIがCMSのコンテンツを更新する。公開日時を指示すればCMSの公開予約が設定される。そこまでの自動化が技術的には見えています。ただし現時点では、制作会社によるQA（品質確認）ステップを残しておく方が現実的だと感じています。
ヘッドレスCMSのメリットが「やっと」見えた
振り返ると、ヘッドレスCMSのポテンシャルはずっとそこにあったのだと思います。APIでデータを返すという設計思想の先に、こういう使い方が待っていた。ただ、MCPが登場するまで、その恩恵を受けられるのは限定的だったように思います。
CMPはここ10年ほどはデジタルマーケティング支援に特化してMAとCMSのセットで支援をすることが多かったですが、ヘッドレスCMSの導入をクライアントに提案できる理由が、ようやく自分の中で確立しました。
長年モヤモヤしていた「ヘッドレスCMSのメリット」が、やっと自分の言葉で説明できるようになったという話でした。
P.S. 今回は定型記事生成の自動化でしたが、FigmaやClaude DesignをModel Context Protocol（MCP）で繋ぐことも普通になる日は近いと思います。