コンテンツアーキテクチャは、Webサイトやアプリに載せるコンテンツを「どんな型に分け、各型にどの項目を持たせ、型どうしをどうつなぎ、どう分類するか」を決める設計です。StoryblokやBCMSなどのCMSベンダーが解説していますが、そこで示される範囲や情報アーキテクチャとの関係は一致していません。この記事では、ベンダー各社の定義を並べて違いを確かめ、情報アーキテクチャとの境界、コンテンツモデルの作り方、記事1本の見出し構成への落とし込みまでを順に扱います。
まとめ：コンテンツアーキテクチャの要点
- 中身は、コンテンツモデル（型とフィールド）、型どうしの関係、タクソノミー（分類）、メタデータの4つの設計判断です。
- 情報アーキテクチャ（IA）は「利用者がどう探し、どうたどるか」、コンテンツアーキテクチャは「CMSの中で何をどの単位で持つか」を主に扱います。ただし包含関係はベンダーによって逆に書かれています。
- 複数の出し先で共有する記事や製品の型は、画面の見た目ではなく意味で切ります。「トップページ用の記事」のような型にすると、別の画面やチャネルで使い回せなくなります。
- 記事1本の内側では、見出し階層が構造そのものです。HTML Living Standardは、見出しのレベルを直前の見出しより2つ以上深くしないことを求めています。
- ページ数が少なく、更新者が1人で、配信先がWebサイト1つだけなら、凝ったモデル設計は見送ってかまいません。
コンテンツアーキテクチャの定義と4つの設計対象
ベンダーごとに逆になる定義と共通する中身
Storyblokの解説は「Content architecture refers to the organization and structure of content.」と定義し、情報アーキテクチャを「コンテンツを含む、システム内のすべての情報の組織化と構造化」と説明しています。こちらは情報アーキテクチャの方が広い書き方です。
BCMSの解説（2025年12月29日付）は逆で、「content architecture encompasses both information architecture and CMSs」と書いています。コンテンツアーキテクチャが情報アーキテクチャを含む、という整理です。
本記事では、各社の説明を踏まえ、CMSの設計で扱う内容を次の節の4つに整理します。社内やベンダーとの打ち合わせでこの言葉を使うときは、包含関係の議論に時間を使わず、4つのうちどれを決めたいのかを先に言葉にしてください。
コンテンツモデル・関係・タクソノミー・メタデータの役割分担
| 設計対象 | 決めること | 技術ブログでの例 |
|---|---|---|
| コンテンツモデル | 型とフィールド | 記事・著者・用語 |
| 関係（リレーション） | 型どうしの参照 | 記事→著者、記事→関連記事 |
| タクソノミー | 分類の軸と語彙 | カテゴリ・タグ |
| メタデータ | 本文の外の属性 | 公開日・更新日・対象バージョン |
4つは独立していません。著者を記事のテキスト項目に書く場合も一覧ページは作れますが、別の型にして参照させると、同姓同名の区別やプロフィールの一括更新がしやすくなります。分類も同じで、カテゴリを自由入力にすると表記ゆれで同じ分類が2つに割れます。Contentfulの記事型なら、記事・人物などの型、著者への参照、カテゴリの語彙、公開日などの項目の順に検討し、実データを入れて見直します。
情報アーキテクチャ・コンテンツ戦略との違いと担当範囲
| 領域 | 主な問い | 主な成果物 |
|---|---|---|
| コンテンツ戦略 | 何を誰のために作るか | 目的・読者・編集方針 |
| コンテンツアーキテクチャ | 何をどの単位で持つか | コンテンツモデル図・分類語彙 |
| 情報アーキテクチャ | どう探し、どうたどるか | サイトマップ・ナビゲーション |
Jahiaの解説はIAを「フロントエンド、つまり情報がどう提示され、どうナビゲートされるか」に焦点を当てるものと説明し、例として、ブログの分類語彙を決めるのはコンテンツアーキテクチャ、その分類を利用者が迷わずたどれるようにするのはIA、と分けています。実務での線引きとしてはこれが一番使いやすい分け方です。
IAの4つの構成要素（組織化・ラベリング・ナビゲーション・検索）や設計手順はインフォメーションアーキテクチャ（IA）の4要素と設計手順で扱っています。本記事では、IAと連携しながらCMSの型・フィールド・参照関係を具体化する工程を、コンテンツアーキテクチャの担当範囲として扱います。
コンテンツモデルの設計手順と型の切り方
棚卸しから型を抽出する5つの工程
- 既存ページを一覧にし、URL・種類・更新者・更新頻度を書き出す（コンテンツインベントリ）。
- 同じ項目の組み合わせを持つページをまとめ、型の候補にする。
- 型ごとにフィールドを決め、必須かどうかと文字数などの制約を付ける。
- 別の型として切り出すもの（著者・製品・用語など）を決め、参照でつなぐ。
- 試行件数は本記事の目安として10〜20件とし、長文・短文・複数著者など条件の異なる記事を入れて、空欄が多いフィールドや複数の情報を詰めた項目を直す。
5番目は省かないでください。図の上では整って見えるモデルも、実際の記事を流し込むと「本文の冒頭に必ず手書きしている注意書き」のような、フィールドにすべき情報が見つかります。分類の語彙を利用者の感覚に合わせたいときは、2番目の工程でカードソートのオープン・クローズド・ハイブリッドの進め方を挟むと、作り手の都合だけで型や分類を決めずに済みます。
見た目ではなく意味で型を切る基準
複数の配信先で共有する記事や製品の型は、表示位置や見た目から分離します。同じ記事を一覧カード、記事ページ、メールマガジン、アプリへ出すとき、見た目で切った型は出し先ごとに複製が必要になるからです。一方、ページ配置を管理するコンポーネントには、表示上の役割に応じた型を設ける場合があります。
この考え方を早くから実装したのが米国の公共ラジオNPRです。NPRのアプリケーション開発ディレクターだったDaniel Jacobsonは、2009年10月13日にProgrammableWebへ寄稿した「COPE: Create Once, Publish Everywhere」（米国政府系ウェブアーカイブの保存版）で、COPEを支える原則として「Separate content from display」「Ensure content modularity」「Ensure content portability」などを挙げ、Webページを出すための道具（web publishing tools）ではなくCMSを作るべきだと書いています。実務上の判断基準に直すと、表示に関わる指定（特定の画面向けのマークアップや改行位置）を本文フィールドに混ぜないことです。
Contentful形式でのコンテンツタイプ定義例
ヘッドレスCMSでは、コンテンツモデルをJSONで定義できます。次はContentfulのContent Management APIに渡す記事型の定義例です。参照先には、コンテンツタイプIDがpersonとcategoryの型を別途用意します。フィールドの型名（Symbol・Text・RichText・Linkなど）と検証ルール（unique・linkContentType・size）は、公式SDK contentful-management.js の型定義に合わせています。
{
"name": "Article",
"displayField": "title",
"fields": [
{ "id": "title", "name": "Title", "type": "Symbol",
"required": true, "localized": false,
"validations": [{ "size": { "max": 60 } }] },
{ "id": "slug", "name": "Slug", "type": "Symbol",
"required": true, "localized": false,
"validations": [{ "unique": true }] },
{ "id": "summary", "name": "Summary", "type": "Text",
"required": true, "localized": false },
{ "id": "body", "name": "Body", "type": "RichText",
"required": true, "localized": false },
{ "id": "author", "name": "Author", "type": "Link", "linkType": "Entry",
"required": true, "localized": false,
"validations": [{ "linkContentType": ["person"] }] },
{ "id": "category", "name": "Category", "type": "Link", "linkType": "Entry",
"required": true, "localized": false,
"validations": [{ "linkContentType": ["category"] }] },
{ "id": "tags", "name": "Tags", "type": "Array", "required": false,
"localized": false, "items": { "type": "Symbol" } },
{ "id": "targetVersion", "name": "Target version", "type": "Symbol",
"required": false, "localized": false }
]
}著者とカテゴリをLinkで別の型へ参照させているのは、前の節で書いた、同姓同名の区別やプロフィールの一括更新、カテゴリの表記ゆれ防止のためです。タグは自由入力のSymbol配列にしてあるので、運用が進むと表記ゆれが起きます。タグも統制したい場合は、カテゴリと同じく別の型にして参照させます。ContentfulのAPI構成や料金の増え方はContentfulの解説記事にまとめています。
Web記事1本の構成への落とし込み
見出し階層とHTML Living Standardの規定
記事の内側では、h1〜h6の見出しがそのまま構造になります。HTML Living Standardの「Headings and outlines」節は、見出しの後に続く見出しのレベルを「同じか浅いか、1つだけ深い」ものに限り、少なくとも1つはレベル1にすべきだとしています。h2の直後にh4を置く飛び越しは、仕様上の不適合です。
現行の規定は、2022年7月1日にマージされたWHATWGのPR #7829で入りました。それまで仕様に載っていた、section要素の入れ子からh1を自動で格下げする「アウトラインアルゴリズム」は、PRの説明にあるとおりブラウザが10年以上実装しないままで、このPRで削除されています。sectionの中を全部h1で書いても階層は伝わらないので、h1〜h6の数字そのもので階層を示してください。2025年9月には子孫の見出しレベルをずらすheadingoffset属性も仕様に加わりましたが（PR #11086）、ブラウザの対応状況は実装ごとに確認が必要です。
Google検索とアクセシビリティで扱いが違う見出し順
見出し順の重みは、誰に向けた話かで変わります。Google検索セントラルのSEOスターターガイドは「見出しの数や順序」の項で、意味的な順番はスクリーンリーダーにとっては素晴らしいが、Google検索にとっては順番どおりでなくても問題ない、と書いています。理想的な見出し数もない、という立場です。
一方、スクリーンリーダーの利用者は見出し一覧で記事を飛び読みします。WCAG 2.2の達成基準1.3.1（情報及び関係性・レベルA）は、見た目で表した構造をプログラムでも読み取れるようにすることを求め、2.4.6（見出し及びラベル・レベルAA）は見出しが主題や目的を説明していることを求めます。見出し階層を守る理由は、検索順位ではなく読み手と支援技術のためです。SEOの古い通説と実際のGoogleの記述の差はSEO内部対策でよくある失敗と直し方で詳しく扱っています。
見出し階層の飛び越しを点検するPythonスクリプト
公開前の原稿で階層の飛び越しを見つけるには、標準ライブラリだけで書ける次のスクリプトで足ります。Python 3のhtml.parserで見出しを順に拾い、レベル1が無い場合と、直前より2つ以上深い見出しを報告します。
import sys
from html.parser import HTMLParser
class Headings(HTMLParser):
def __init__(self):
super().__init__()
self.items = [] # (level, text)
self._level = None
self._buf = []
def handle_starttag(self, tag, attrs):
if len(tag) == 2 and tag[0] == "h" and tag[1] in "123456":
self._level = int(tag[1])
self._buf = []
def handle_data(self, data):
if self._level:
self._buf.append(data)
def handle_endtag(self, tag):
if self._level and tag == f"h{self._level}":
self.items.append((self._level, "".join(self._buf).strip()))
self._level = None
def check(html):
p = Headings()
p.feed(html)
problems = []
levels = [lv for lv, _ in p.items]
if 1 not in levels:
problems.append("h1 が1本もない")
for (prev, _), (cur, text) in zip(p.items, p.items[1:]):
if cur > prev + 1:
problems.append(f"h{prev} の次に h{cur}: {text}")
return p.items, problems
if __name__ == "__main__":
items, problems = check(open(sys.argv[1], encoding="utf-8").read())
for lv, text in items:
print(" " * (lv - 1) + f"h{lv} {text}")
print("\n".join(problems) or "階層の飛び越しなし")h1→h2→h4→h2→h3と並べたHTMLを渡すと、次のように出力されます。
h1 コンテンツモデル入門
h2 型の切り方
h4 フィールドの粒度
h2 タクソノミー
h3 カテゴリとタグ
h2 の次に h4: フィールドの粒度このスクリプトはheadingoffsetやaria-levelを考慮しません。また、CMSがタイトルをテンプレート側でh1として出力する構成では、本文だけを渡すと「h1が1本もない」と出ます。その場合はh1の判定を無視し、飛び越しの行だけを見てください。
コンテンツモデルのフィールドと構造化データの対応
型とフィールドを決めておくと、構造化データの出力も機械的になります。Google検索セントラルのArticle構造化データの説明（2026年9月12日更新）は「必須プロパティはありません」とし、当てはまる推奨プロパティをできるだけ多く設定するよう求めています。
| モデルのフィールド | Articleのプロパティ |
|---|---|
| title | headline |
| author（参照先のperson） | author |
| 公開日（システム項目） | datePublished |
| 更新日（システム項目） | dateModified |
| アイキャッチ画像 | image |
著者名を自由入力にする場合でも、別途管理した人物のURLをauthorのurlに出力できます。ただし、著者名とURLの対応を一元管理するには、人物型への参照が適しています。構造化データを出す予定があるなら、著者を別の型にするかどうかはモデル設計の段階で決めておくと、後から著者URLの対応表を作らずに済みます。
タクソノミーとURL・内部リンクへの反映
分類の軸は2本までに絞るのが扱いやすい構成です。主題で1つだけ付けるカテゴリと、横断的な観点で複数付けるタグに分け、カテゴリは階層を持たせ、タグは平らに保ちます。複数カテゴリを許可する場合は、パンくずに使う主カテゴリと記事URLの生成規則を別途決めます。Googleの構造化データでは、1ページに複数のパンくず経路を指定することもできます。パンくずの階層と構造化データの実装はパンくずリストのSEO効果と構造化データの実装で扱っています。
分類語の意味がぶれると、同じ主題の記事が別カテゴリに散ります。語ごとに「何を含め、何を含めないか」を1〜2文で書き残す注記は、図書館のシソーラスでスコープノートと呼ばれる方法です（スコープノート（SN）の役割と書き方）。分類がずれた結果、同じ検索語を複数の記事で取り合う状態になったら、キーワードカニバリゼーションの発見手順と統合・分離の判断基準で統合か分離かを決めます。
コンテンツアーキテクチャを作り込みすぎる失敗と見送る条件
モデル設計は、やりすぎると更新が止まります。典型は次の3つです。
- フィールドを細かく割りすぎる：導入文・本文1・本文2・補足……と段落単位でフィールドを作ると、記事ごとに構成を変えられず、空欄が増えます。Contentfulはデータモデルの説明で、1つのコンテンツタイプに置けるフィールドを最大50個としていますが、上限に近づくほど入力画面は縦に長くなります。本文はリッチテキスト1つにまとめ、繰り返し使う部品だけを別の型にします。
- 型を画面ごとに作る：前述のとおり、出し先が増えるたびに型が増えます。
- 将来の多チャネル配信を前提に作る：アプリもメールも予定がないのに、すべてを部品化するとCMSの入力画面が複雑になり、書き手の入力ミスが増えます。
判断の目安として、公開ページが数十本程度、更新者が1〜2人、出し先がWebサイト1つという条件がそろっているなら、WordPressの投稿・カテゴリ・タグという既定の構成で十分です。ヘッドレスCMSへの移行や独自のコンテンツモデル設計に着手するのは、同じ情報を2つ以上の出し先で使う予定が具体的に決まったときか、型ごとに入力項目を強制しないと品質がそろわない人数で更新するようになったときです。
コンテンツアーキテクチャに関するよくある質問
コンテンツアーキテクチャとは何ですか？
Webサイトやアプリのコンテンツを、どんな型に分け、各型にどの項目を持たせ、型どうしをどうつなぎ、どう分類するかを決める設計です。具体的には、コンテンツモデル（型とフィールド）、型どうしの関係、タクソノミー、メタデータの4つを決めます。ベンダーによって説明する範囲が異なるため、使う場面ではこの4つのどれを指しているかを明確にすると話が噛み合います。
情報アーキテクチャ（IA）との違いは何ですか？
IAは利用者がどう探し、どうたどるかを扱い、成果物はサイトマップやナビゲーションです。コンテンツアーキテクチャはCMSの中で何をどの単位で持つかを扱い、成果物はコンテンツモデル図や分類語彙です。ただしStoryblokはIAの方が広い、BCMSはコンテンツアーキテクチャの方が広い、と包含関係を逆に説明しています。
コンテンツモデルとは何ですか？
コンテンツの型と、その型が持つフィールド（項目）の定義です。たとえば「記事」型にタイトル・スラッグ・要約・本文・著者・カテゴリを持たせ、著者は「人物」型への参照にする、といった設計を指します。ContentfulなどのヘッドレスCMSでは、フィールドごとに型（短いテキスト、リッチテキスト、参照など）と検証ルール（必須、一意、文字数）をJSONで定義できます。
コンテンツアーキテクチャのためにヘッドレスCMSは必要ですか？
必須ではありません。WordPressでも投稿タイプ・カスタムフィールド・カテゴリ・タグで型と分類は表現できます。ヘッドレスCMSが効くのは、同じコンテンツをWebサイト以外（アプリ、メール、提携先）にも配るとき、または入力項目を型ごとに強制しないと品質がそろわない規模のときです。公開ページが数十本程度でWebサイトだけなら、既定の構成で始めて構いません。
見出しをh2からh4へ飛ばしてもよいですか？
HTML Living Standardでは不適合です。見出しの後に続く見出しは、同じレベルか浅いレベル、または1つだけ深いレベルでなければならないと定めています。Google検索は見出しの順番を順位の条件にしていないと説明していますが、スクリーンリーダーの利用者は見出し一覧で記事をたどるため、飛び越しがあると構造を正しく把握できません。見た目の大きさを変えたいだけならCSSで調整します。
