AIO-Ready Schema Design
AIO-Ready スキーマ設計
AI検索に引用されるかどうかは、書いた量よりも「事実が単体で取り出せる形になっているか」で決まります。本文を1枚のリッチテキストで持っている限り、後から構造化データを組み立てることはできません。
microCMS公式パートナーとして、定義・FAQ・比較・事実項目を型として持つスキーマを設計し、既存コンテンツの移行までを担当します。
こんな課題をお持ちの方へ
- 記事本文がすべてリッチテキストで、後から構造化データを組み立てられない
- FAQを各ページにHTMLで直接書いていて、更新のたびに探し回っている
- 同じサービスの説明が複数のページに少しずつ違う言い回しで存在している
- 料金や対応範囲が本文に埋もれていて、単体で取り出せない
- サイトリニューアルを機に、AI検索を前提とした持ち方に切り替えたい
型として持つもの
定義（〇〇とは）
AI検索で最も聞かれるのは定義と比較です。用語・サービス・概念の説明を独立した型として持ち、複数ページから同じ定義を参照できるようにします。
- 用語・概念の正本を1箇所に
- 複数ページからの参照
- 定義の更新が全ページに反映
- DefinedTerm への出力
FAQ（質問と回答）
質問と回答をペアの繰り返し項目として持ちます。ページ内の表示・FAQPage 構造化データ・サイト内AIチャットの参照元を、すべて同じデータから作れます。
- 質問・回答のペア管理
- FAQPage 構造化データの自動出力
- サービスページへの部分表示
- AIチャットの参照元と共通化
比較・仕様
プラン比較や仕様一覧を表として持ちます。HTMLの表を本文に貼る運用をやめると、項目の増減や条件変更が管理画面だけで完結します。
- 項目と値の対応を保持
- プラン・仕様の一覧管理
- 条件変更の反映漏れを防ぐ
- 表としての機械可読性
鮮度と出典
初出日と最終更新日を分けて持ち、制度・価格など変わりうる情報には基準時点を添えます。鮮度が判別できないページは、AIに採用されにくくなります。
- 公開日・更新日の分離
- 情報の基準時点の明示
- 改定履歴の保持
- 出典・根拠の項目化
設計を変えると何が変わるか
事実が単体で取り出せる
料金・対応範囲・所要期間といった事実を項目として持つことで、AIがそのまま引用できる形になります。
表示と構造化データがずれない
同じ入力から画面表示とJSON-LDの両方を組み立てるため、片方だけ古くなる事故が原理的に起きません。
追加コンテンツが散らからない
型が決まっていれば、記事が増えても置き場所に迷いません。運用が属人化しにくくなります。
進め方
既存コンテンツの棚卸し
いま何がどこに、どの粒度で書かれているかを洗い出します。重複している説明、正本が決まっていないテーマを特定します。
型の設計
定義・FAQ・比較・事実項目をどう分けるかを決めます。運用担当者が迷わず入力できる粒度に落とし込むところまでを設計に含みます。
microCMS への実装と移行
APIスキーマを構築し、既存コンテンツを新しい型へ移します。件数が多い場合はスクリプトで一括移行します。
運用ルールの引き渡し
新しいコンテンツをどの型で持つか、判断に迷ったときの基準を文書化してお渡しします。
よくある質問
- 既存のmicroCMSサイトでも、後からスキーマを組み直せますか？
- 組み直せます。既存のAPIに新しいフィールドを追加し、本文から必要な要素を切り出して移行する形が一般的です。コンテンツ件数が多い場合は、microCMSのAPI経由でスクリプトによる一括移行を行います。ページの見た目を変えずに、持ち方だけを変えることも可能です。
- スキーマを細かく分けると、記事を書く人の負担が増えませんか？
- 分け方を間違えると増えます。そのため設計では「入力者が迷わない粒度」を基準にしています。すべての記事に全項目を求めるのではなく、定義やFAQのように引用価値の高いものだけを型にし、残りは従来どおり本文で書ける構成にすることが多いです。
- スキーマ設計だけを依頼することはできますか？
- できます。実装やフロントエンドは既存の制作会社が担当し、設計と移行方針だけを当社が担う形にも対応しています。設計書と移行手順をお渡しする形での納品が可能です。
- microCMS以外のヘッドレスCMSでも対応できますか？
- 考え方は共通なので対応できます。ただし当社はmicroCMS公式パートナーであり、microCMSでの実装知見が最も蓄積されています。CMS選定の段階からご相談いただく場合は、要件に対してmicroCMSが適しているかどうかも含めてお話しします。