ヘッドレスCMSか従来型か｜AIに記事を渡す前の判断

「制作会社からヘッドレスCMSへの移行を勧められたが、今のCMSで何が困っているのかを社内で説明できない」「生成AIで記事を増やし始めたら、CMSの入れ物が合っていない気がする」。オウンドメディアやコーポレートサイトの担当者から、この1年でよく届くようになった声です。どちらも、仕組みの名前が先に立ち、何のために型を選ぶのかが決まっていないところから来ています。ヘッドレスか従来型かは、新しい仕組みか古い仕組みかの選択ではありません。本当は、記事を「ページ」として持つか、「部品」として持つかの選択です。AIが記事を読む・作る・配る場面が増えたことで、その違いが表に出やすくなりました。この記事では、2つの型の違い、AIが関わることで変わった点、部品で持つ利点と負担、従来型のままで足りる条件、移る判断の物差しを整理します。

ヘッドレスCMSとは：中身を持つ仕組みと見せる仕組みを切り離した型

従来型のCMSは、記事を入力して保存する仕組みと、その記事をページとして表示する仕組みが1つにまとまっています。管理画面で本文を書き、テーマやテンプレートを選べば、そのままサイトのページになります。書いた人が、公開前に読者と同じ見た目を確かめられるのが強みです。

ヘッドレスCMSは、この表示の部分（頭）を持ちません。記事を見出し・要約・本文・画像・公開日といった項目ごとに保存し、外からの求めに応じて、APIという窓口を通して中身だけを渡します。サイトの見た目は、受け取る側のサイトやアプリが別に作ります。名前の「頭が無い」は、この表示の部分を持たないことを指しています。

観点	従来型のCMS	ヘッドレスCMS
中身の持ち方	ページ単位。本文は1つの欄にまとめて書くことが多い	項目単位。見出し・要約・本文・注意書きなどを別の欄に持つ
表示	CMSのテーマ・テンプレートが作る	受け取る側（サイト・アプリなど）が別に作る
配り先	主に自社サイト	サイト・アプリ・メール・社内の仕組みなど複数を前提にする
公開前の見た目の確認	管理画面でそのまま確かめられる	確認用の画面を別に用意する必要がある
運用に要る人	編集者が中心	編集者に加え、表示側を作って保守する開発者

この記事では、型の違いを「AIに記事を渡すかどうか」の1点に絞って比べます。CMSの型を全体で並べた分類や、要件の棚卸し・費用・移行計画は、オウンドメディアのCMSの選び方を扱った別の記事で整理しています。製品ごとの機能比較もここでは行いません。

記事を読む相手が、人だけではなくなった

型の違いが改めて問われるのは、自社の記事を読む相手が増えたからです。いまの記事は、少なくとも4種類のAIに読まれます。社内の生成AI（社員の質問に、自社の記事や資料を根拠に答える仕組み）、問い合わせ対応のAI（顧客の質問に、サイトの記事から答える仕組み）、検索結果の上に要約を出すAI検索、そして利用者の代わりにページを読んで操作するAIエージェントです。

人の読者は、ページを上から読み、見出しの大きさや囲みの装飾で「ここは注意書き」「ここは要約」と判断します。AIの読み手は、その判断を文字の並びと構造から行います。いつ更新された記事か、誰に向けた記事か、どこまでが本文でどこからが宣伝の枠かが、ページの見た目にしか表れていないと、読み手のAIが切り出し方を取り違える余地が残ります。

項目で持っていれば、渡す側が「この相手には要約と更新日と本文だけ」と選べます。ページで持っていると、受け取る側が丸ごと受け取ってから切り出すしかありません。違いは、切り出しの責任を渡す側が持つか、受け取る側に任せるかです。なお、AIの巡回をどこまで受け入れるかといった入口の判断は、AIクローラーを扱った別の記事に譲ります。

4種類の読み手は、求める項目も違います。社内の生成AIには、社員が誤って古い情報を使わないよう更新日と対象読者が欠かせません。問い合わせ対応のAIには、答えてよい範囲を示す注意書きが要ります。AIエージェントには、申し込みや資料請求の手順のように、操作の順番が読み取れる中身が要ります。誰に何を渡すかを並べてみると、自社の記事に足りない項目が具体的に見えてきます。

AIで作った記事を入れる側でも、型の違いが出る

AIは記事を読む側だけでなく、作る側にも入ってきました。生成AIで下書きを作ると、たいていは見出しと本文が続いた1つの長い文章として出てきます。従来型のCMSでは、その文章を本文の欄にまとめて貼るのが自然な流れです。ヘッドレスCMSでは、同じ下書きを見出し・要約・対象読者・本文・注意書き・出典といった項目に分けて入れることになります。

この違いは、人が確かめる単位に効いてきます。項目に分かれていれば、「要約が本文の結論と食い違っていないか」「出典の欄が空になっていないか」「注意書きが決められた文言になっているか」を、欄ごとに点検できます。本文の欄1つにまとまっていると、これらはすべて人が全文を読んで探すしかありません。生成AIで本数が増えるほど、この差は担当者の時間として積み上がります。

一方で、AIに項目分けを任せると、決めていない項目を勝手に作ったり、要約の欄に本文の一部をそのまま入れたりすることがあります。項目の名前と中身の定義は人が先に決めて固定し、AIにはその枠に入れることだけをさせるのが前提です。枠が無いままAIに分けさせると、記事ごとに項目の切り方が変わり、部品で持つ意味が失われます。

生成AIを使った記事が増えると、記事そのものとは別に「どう作られたか」の情報も持ちたくなります。下書きにAIを使ったか、誰が事実を確かめたか、いつ確かめたかを項目にしておけば、後から誤りが見つかったときに、同じ作り方の記事をまとめて洗い直せます。本文欄1つの記事では、この情報は担当者の記憶か別の管理表にしか残りません。

ページで持つか、部品で持つか：境目は本文欄1つに詰めるかどうか

部品で持つとはどういうことかを、ヘッドレスCMSを提供するサニティ社の公式ドキュメントが具体的に書いています。中身の型は、ページでどう見せるかではなく、その中身が何についてのものかを軸に作る。すべての情報を、装飾付きの本文欄1つに閉じ込めない。特定のページの配置に合わせて型を作らない。同じ情報を複数の場所に貼り写さない。どれも、配り先が増えたときに作り直さずに済ませるための注意です。

同じドキュメントは、意図して設計していなくても、どのCMSにも中身の型はあるとも書いています。従来型のCMSでも、カテゴリやタグ、抜粋の欄、独自に足した入力欄を使えば、部品に近い持ち方はできます。つまり2つの型の差は、有るか無いかではなく、どこまで部品に分けることを前提に作られているかの程度です。

例として、導入事例の記事を部品で持つ場合を考えます。顧客の業種、抱えていた課題、行った施策、結果の数字、担当者の言葉、公開日と更新日を、それぞれ別の項目にします。こうしておけば、サイトの事例ページ、営業資料の一覧、社内の生成AIへの回答の材料に、同じ中身から必要な項目だけを出せます。本文欄1つに書いた事例では、結果の数字だけを取り出すにも人が記事を開いて探すことになります。

項目の名前の付け方にも、同じドキュメントは注意を書いています。「画像」「動画」のような汎用の名前ではなく、何の画像か、何を見せる動画かが分かる名前にする。「見出し部分」「区画」「中身」のような、意味を持たない名前を避ける。名前が意味を表していれば、受け取る側の人にもAIにも、その欄を何に使ってよいかが伝わります。

部品で持つ利点1：配り先ごとに要る項目だけを渡せる

部品で持つ1つ目の利点は、同じ中身を配り先ごとの形で出せることです。サイトには全項目を、メールには見出しと要約と記事への導線を、社内の生成AIには要約・対象読者・本文・更新日を、という出し分けを、元の中身を1つに保ったまま行えます。

直しの手間にも効きます。製品の価格や仕様が変わったとき、同じ文言をサイト・資料・社内の回答集に貼り写していると、直し漏れが起きます。部品で持っていれば、元の項目を1か所直すと、それを使っている配り先すべてに反映されます。社内の生成AIが古い価格で答え続ける、といった食い違いの芽を減らせます。

渡さない線も引けます。社内の生成AIに記事を渡すとき、宣伝の文句が入った欄や、公開前の欄は外したい場合があります。項目で持っていれば「この欄は渡さない」「更新日が一定より古い記事は渡さない」といった線を、仕組みの側で決めておけます。どの線を引くかは、AIではなく担当部署が決めることです。

部品で持つ利点2：生成AIの下書きを、項目ごとに確かめられる

2つ目の利点は、生成AIで作った下書きの点検を、項目ごとの決まりにできることです。たとえば、要約の欄は決めた字数に収める、出典の欄は空では公開できない、注意書きの欄は法務が確認した文言から選ぶ、といった決まりを欄ごとに置けます。点検の一部を、人の目から仕組みの検査に移せます。

承認の分担もしやすくなります。数字の欄は製品の担当者、注意書きの欄は法務、全体の読みやすさは編集者、というように、誰がどの欄に責任を持つかを項目で決められるからです。本文欄1つの記事では、全員が全文を読むか、誰も読まない欄が出るかのどちらかになりがちです。

さらに、生成AIに下書きを作らせるとき、項目ごとに「根拠にした資料の箇所」を書かせる欄を足しておくと、確認する人がどこを見ればよいかが決まります。AIには根拠を書かせ、人はその根拠を確かめるという分担を、型の側で固定できるわけです。ただし、どの欄を人が必ず読むかは、型を作る前に人が決めておく必要があります。

部品で持つ負担：見た目の確認と、項目を守る仕事が増える

利点の裏側には負担があります。1つ目は見た目の確認です。ヘッドレスCMSは表示を持たないので、編集者が公開前に「読者からどう見えるか」を確かめる画面を、別に用意しなければなりません。製品によっては確認用の画面の仕組みを備えていますが、どこまで実際のページに近い見た目を出せるかは、表示側の作りに左右されます。

2つ目は表示側の開発と保守です。サイトの見た目を変えたいとき、従来型ならテーマの設定で済んだことが、表示側のプログラムを直す開発者の作業になります。編集者が自分で直せる範囲が狭くなり、小さな直しにも依頼と待ち時間が発生します。社内にも外部にも表示側を任せられる人がいない状態で移ると、運用が止まります。

3つ目は、項目の定義を守る仕事です。部品の持ち方は、使ううちに崩れます。誰も使わない項目が残る、同じ意味の項目が別の名前で増える、ある記事だけ要約の欄に本文が入っている、といった崩れです。項目の定義の持ち主を決めて、定期的に見直す人がいないと、部品で持つ利点は数か月で薄れます。

• 項目の崩れの洗い出し（使われていない欄、空の欄、定義と違う中身が入った欄の一覧）はAIに任せやすい作業です
• ただし、どの項目を残し、どれを統合するかの決定は、定義の持ち主が行います

従来型でも、中身をAPIで渡すことはできる

「AIに記事を渡すにはヘッドレスCMSが要る」と考えるのは早計です。従来型の代表であるワードプレスも、中身を外へ渡す窓口を持っています。公式の開発者向けハンドブックによれば、ワードプレスのREST APIは、投稿・固定ページ・分類などのデータをJSONという形式で返す窓口で、ブロックエディターの土台にもなっています。同じハンドブックは、この窓口を使えば中身を別のアプリケーションに持ち込み、新しい表示を作れるとも書いています。

つまり、配り先を増やすこと自体は、従来型のままでも始められます。問題は窓口の有無ではなく、窓口から出てくる中身の形です。本文を1つの欄にまとめて書いていれば、APIで渡しても本文はひと塊のまま届きます。受け取る側は、その中から要約や注意書きを探すことになり、ページで持っている状態と大きくは変わりません。

ですから、移るかどうかを決める前に、いまのCMSに入力欄を足して、項目で持つ運用に寄せられるかを確かめる価値があります。足した欄で足りるなら、表示側を作り直す負担を負わずに、部品で持つ利点の一部を得られます。足りないと分かれば、それが移る理由の具体的な中身になります。

AI検索のためだけに移る必要はない

移る理由として「AI検索に引用されやすくなるから」が挙げられることがあります。グーグルは検索セントラルの公式ページで、検索の要約や対話型の検索に表示されるために、追加の要件や特別な最適化は必要ないと書いています。新しい機械向けのファイルやAI向けの文書、特別な構造化データを用意する必要もない、という立場です。

同じページが求めているのは、通常の検索と同じ土台です。ページがインデックスされ、抜粋付きで表示できる状態であること。重要な中身を文字で出すこと。構造化データを使うなら、ページに見えている文字と一致させること。どれもCMSの型ではなく、中身の書き方と公開の仕方の話です。

したがって、移る理由がグーグルのAI検索だけなら、それは根拠として弱いと言えます。移る理由になるのは、検索以外の配り先、つまり社内の生成AI、問い合わせ対応のAI、アプリやメールといった、自社が中身を渡す相手が増えることです。検索向けのマークアップの書き方そのものは、この記事では扱いません。

ただし、同じページには型を選ぶときに見落としやすい注意も1つあります。検索エンジンの巡回が、サイトの設定だけでなく、配信網や置き場所の側でも妨げられていないことを確かめる、という点です。ヘッドレスCMSでは、中身の置き場所と表示を出すサーバーが分かれることが多く、確かめる場所が増えます。移る場合は、この確認を表示側の担い手の仕事に入れておきます。

従来型のままで足りる条件

ここまでを裏返すと、従来型のCMSのままで足りる条件が見えてきます。次のうち多くに当てはまるなら、移るより、いまのCMSで項目を足す運用を先に試すほうが筋が通ります。

• 中身を出す先が、当面は自社サイト1つに限られる
• 社内の生成AIや問い合わせ対応のAIに記事を渡す予定が無いか、ファイルの書き出しで足りる
• 同じ文言を、サイト以外の複数の場所で人が直している状態が無い
• 編集者が自分で見た目を確かめ、自分で直せることを最も重く見ている
• 表示側を作って保守する開発者を、社内にも外部にも継続して確保できない
• 記事の種別が少なく、必要な項目を入力欄の追加でまかなえる

とくに5つ目は重い条件です。ヘッドレスCMSは表示を別に作る前提なので、表示側の担い手が続かない体制では、移った後に直しが止まります。体制が整うまで待つか、表示まで含めて請け負う外部と長く組めるかを先に確かめます。

「足りる」は「ずっとそのままでよい」という意味ではありません。配り先が増える予定が具体的に決まった時点で、改めて判断し直す前提で、いまの型を続けると決めておくのが現実的です。いつ判断し直すかの合図も、このとき一緒に決めておきます。

移る判断の物差し：配り先・直しの回数・渡す相手・体制

移るかどうかは、製品の評判ではなく、自社の記事の使われ方で測ります。物差しは4つあります。中身を出す先がいくつあるか、同じ文言を人が何か所で直しているか、項目ごとに渡したいAIの相手がいるか、表示側を支える体制があるか、です。

物差し	従来型のままでよい目安	ヘッドレスCMSを検討する目安
中身を出す先	自社サイトが中心	サイトに加え、アプリ・メール・社内の仕組みなどに同じ中身を出す
同じ文言の直し	直すのはサイトの中だけ	価格や仕様の変更のたびに、複数の場所を人が直している
AIに渡す相手	渡さない、またはファイルの書き出しで足りる	社内の生成AIや問い合わせのAIに、欄を選んで渡したい
生成AIの下書き	本数が少なく、全文を人が読める	本数が多く、欄ごとに点検と承認を分けたい
体制	表示側を保守する人がいない	表示側を作り、直し続ける開発の担い手がいる

上の目安は、この記事での整理です。どれか1つが右側に寄ったから移る、ではなく、複数が右に寄り、しかも体制の行が右側にあるときに、検討の段に進むのが安全です。

また、全部を移すか移さないかの二択でもありません。事例や製品情報のように、配り先が多い記事の種別だけを部品で持つという分け方もあります。コラムのように主にサイトで読まれる記事は、従来型のまま残す、という線の引き方です。

判断の前に、既存の記事を項目に分けて試す

型を決める前に、手元の記事で小さく試すと、机上の比較では見えない負担が見えます。サニティ社のドキュメントも、最初は1つか2つの型の意味のある構造を決めるところから始めてよいと書いています。次の順で、1つの記事の種別だけを対象に試します。

この試行は、いまのCMSに入力欄を足す形でも、ヘッドレスCMSの試用環境でも行えます。どちらで試しても、項目の定義は次の判断にそのまま使える資産として残ります。試す期間と、終わったら判断する日を先に決めておくと、試行がいつの間にか移行の既成事実にすり替わるのを防げます。

AIに任せること、人が決めること

この判断の中でAIに任せやすいのは、量の多い下ごしらえです。既存の記事を見出し・要約・対象読者・更新日などの項目に分ける下書き、決めた定義に照らした抜けの洗い出し、配り先ごとの出し分けの下書き、表記の揺れの一覧がそれに当たります。どれも、根拠にした箇所を一緒に出させれば、人が短い時間で確かめられます。

反対に、AIに決めさせてはいけないのは次の4つです。どちらの型を選ぶか、移るかどうか、項目の名前と定義、記事を公開するかどうかです。AIは手元の記事から項目を作ることはできても、来年増える配り先や、表示側を任せられる人がいるかといった、記事の外の事情を知りません。型の選択は、その記事の外の事情で決まります。

人が確かめる範囲も先に決めておきます。たとえば、AIが分けた下書きのうち、数字と注意書きの欄は必ず担当者が原文と突き合わせる、要約の欄は編集者が本文と読み比べる、といった決め方です。確かめる欄を決めずにAIの下書きを流し込むと、部品にした分だけ点検の漏れも部品ごとに散らばります。

項目分けの下書きを確かめるときは、全件を読む前に抜き取りで始めます。たとえば10本のうち2本を人が原文と突き合わせ、取り違えが多い欄が見つかったら、その欄だけ全件を確かめる、という順です。取り違えが特定の欄に集中しているなら、AIの腕前より、その欄の定義があいまいなことを疑います。定義を直すのは人の仕事です。

判断を誤る進め方

型の判断でつまずく進め方には、決まった形があります。多くは、型の名前を先に決め、記事の使われ方を後から合わせようとしたときに起きます。

• AI検索のためと言って移る：グーグルは特別な対応は要らないとしており、検索以外の配り先が無いまま負担だけが増える
• ページの見た目に合わせて項目を作る：「左の枠」「下の囲み」のような項目名にすると、配り先が変わった時点で作り直しになる
• 項目分けをAIの案のまま確定する：記事ごとに項目の切り方が変わり、定義の持ち主もいないまま崩れていく
• 表示側の担い手を決めずに移る：小さな直しに開発の依頼が要るようになり、更新の頻度が落ちる
• 全種別を一度に移す：配り先が少ない記事まで部品にし、項目を守る手間が効果を上回る

どの失敗も、「何をどこへ渡したいか」を決める前に型を決めたことから起きています。順番を守れば、移る判断も移らない判断も、社内で説明できる形になります。説明できないまま移ると、移った後の負担を誰が負うのかも決まらないまま進みます。

よくある質問

ヘッドレスCMSにすれば、AI検索に引用されやすくなりますか？

グーグルの公式の説明では、検索の要約などに表示されるための追加の要件は無く、通常の検索と同じ土台が求められています。CMSの型を変えたこと自体が引用のされやすさを上げる、という根拠は確認できません。中身を文字で出しているか、記事がインデックスされているかを先に確かめるのが近道です。

生成AIで作った記事は、ヘッドレスCMSのほうが入れやすいですか？

入れやすさより、確かめやすさの差が大きいと言えます。項目に分けて入れれば、欄ごとに点検と承認を分けられます。ただし、項目の定義を人が決めておかないと、AIの分け方が記事ごとに揺れます。本数が少なく全文を人が読めるうちは、従来型の本文欄でも困らないことが多いでしょう。

一部の記事だけをヘッドレスにすることはできますか？

できます。従来型のCMSの窓口を使って一部の中身だけを外へ出す方法も、配り先の多い種別だけをヘッドレスCMSで持つ方法もあります。どこまで混ぜられるかは製品と表示側の作りによるため、試行の段階で、混ぜた場合の見た目の確認と直しの流れまで確かめておくと安全です。

まとめ

ヘッドレスCMSか従来型かは、記事をページで持つか、項目ごとの部品で持つかの選択です。社内の生成AI、問い合わせ対応のAI、AI検索、AIエージェントが記事を読み、生成AIが記事を作るようになって、部品で持つ利点（配り先ごとの出し分け、1か所の直し、欄ごとの点検）と負担（見た目の確認、表示側の保守、項目の定義の維持）が表に出ました。ただし、グーグルのAI検索のためだけに移る必要はなく、従来型でもAPIで中身は渡せます。移る理由になるのは、検索以外の配り先が増えることと、表示側を支える体制があることです。判断の前に、1つの記事の種別で項目分けを試してください。項目分けの下書きと抜けの洗い出しはAIに任せ、根拠の箇所を書かせ、型の選択・移るかどうか・項目の定義・公開の判断は人が決めます。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。