用語定義ページの作り方｜定義文の型とDefinedTermの書き方

自社サイトに用語集や用語解説ページを作っても、ChatGPTやGoogleのAI検索がなかなか自社の言葉を拾ってくれない。そう感じている広報・Web担当の方は多いはずです。

この記事は、BtoB企業でオウンドメディアや用語ページを運用していて、AI検索の回答で参照されることも考えて見直したい方に向けて書いています。読み終わる頃には、どんな文構造で書き、どんな構造化データを添え、公開前に何を確認すればいいかが具体的に分かり、明日から1ページ手を動かせる状態を目指します。

なお、用語の探し方やキーワード選定そのものは扱いません。すでに社内にある専門用語・サービス固有語を、読者とAI検索の両方に伝わる定義ページにする設計に絞って解説します。GEO全体の進め方から知りたい方は、先にGEO対策のやり方を7手順で解説した記事を読むと、この記事の位置づけがつかみやすくなります。

Contents / 目次

1. 用語定義ページの基本は冒頭の定義文と自社ならではの説明
2. 用語定義ページの作り方を5ステップで解説
3. 用語定義ページを作ると何が変わるのか
4. 用語定義ページでよくある失敗と回避法
5. 用語定義ページの落とし穴と、現場での妥協点
6. よくある質問

用語定義ページの基本は冒頭の定義文と自社ならではの説明

結論から言うと、用語定義ページでまず書くのは、構造化データではなく本文です。冒頭の1文で「○○とは、〜である」と言い切り、そのあとに自社ならではの説明を書くこと。読者は最初に答えを読めて、他社の解説には無い情報も得られます。

Googleは、生成AI機能向けの最適化もSEOであることに変わりはないと説明しています。Google 検索の生成 AI 機能向けにウェブサイトを最適化する（Google 検索セントラル）では、AIのためにコンテンツを細かく分割する「チャンク化」も、生成AI検索向けの書き方も必要ないとしています。Googleのシステムは、1ページにある複数のトピックを理解し、関連性の高い部分を表示できるためです。冒頭で定義を言い切るのは、AIのためではなく、用語を調べに来た読者が最初に答えを読めるようにするためです。

逆に、背景説明を長々と書いてから最後に定義が出てくるページでは、読者が答えを探してページを下まで読むことになります。

用語定義ページとは、専門用語やサービス固有語について「その語が何を指すのか」を明確に答え、読者が最初の1〜2文で意味をつかめる形にしたページのことです。押さえるべきことは、次の4つに整理できます。

• 定義文の型：冒頭1〜2文で「○○とは、〜である」と結論から答える
• 自己完結性：その段落だけ読んで意味が通る（「これ」「前述の」で始めない）
• 構造化データ：本文にある定義を、機械にも分かる形（schema）で補足する
• エンティティ接続：関連用語や自社サービスへ説明的な内部リンクでつなぐ

この4つを、優先度と「まず何から着手するか」で並べると次のようになります。構造化データから入りたくなりますが、順番はむしろ逆です。

着手順	やること	効き目	難しさ
1番目	本文の定義文を型に沿って書く	大（ページの土台）	低
2番目	段落を自己完結する形に書き換える	大	低
3番目	関連用語・サービスへ内部リンク	中	低
4番目	構造化データ（schema）を添える	補助（Googleの生成AI検索には不要）	中

ポイント。構造化データは、本文にある情報を機械にも分かる形で補足するものです。Googleは、生成AI検索に構造化データは必要なく、追加する必要がある特別なschema.orgのマークアップも無いと説明しています。まず本文、次にschemaの順で進めてください。

用語定義ページの作り方を5ステップで解説

ここからは、実際に1ページ作り上げる手順を順番に見ていきましょう。どのステップも特定のツールに依存しないので、WordPressでもそのまま使えます。

ステップ1。1ページ1用語で構成を決める

まず、1つの用語につき1ページを用意します。「用語集をまとめて1ページに」ではなく、用語ごとにURLを分けるのが基本です。

理由は2つあります。

• 用語ごとにURLが分かれるので、ほかのページや社内外の資料から、その用語の説明へ直接リンクできること
• その用語で検索した人がページに来たとき、余計な情報に埋もれず答えにたどり着けること

ページの骨組みは、次の順番で固定すると迷いません。

1. 用語名（H1・タイトル）
2. 冒頭の定義文（1〜2文で言い切る）
3. もう少し詳しい説明（3〜5文）
4. 具体例・使いどころ
5. よくある誤解・関連用語との違い
6. 関連用語・自社サービスへのリンク

用語集トップ（一覧ページ）は別に用意し、そこから各用語ページへリンクを張る形にします。一覧は索引の役割、個別ページが答えの役割です。

ステップ2。冒頭の定義文を「型」で書く

定義文は、ページの一番上に置きます。型は「○○とは、△△（上位概念）のうち、□□という特徴をもつものである」です。

たとえば架空の用語「ABC分析」を定義するなら、こう書きます。文面例として、そのまま流用できる形にしておきます。

ABC分析とは、在庫管理の手法のひとつで、
商品を売上や重要度の順にA・B・Cの3グループへ分け、
管理の優先順位を決める方法である。

ここで大事なのは、1文目に「背景」や「なぜ重要か」を入れないことです。読者は、まず「それが何か」を知りたいので、答えを先に出します。重要性や背景は2段落目以降に回します。

「近年注目されている〜」「DXが進むなかで〜」のような前置きから始めると、肝心の定義が下に押し込まれ、読者が答えを見つけにくくなります。前置きは削るか、後ろに回してください。

ステップ3。段落を自己完結させる

各段落は、その段落だけを切り出して読んでも意味が通るように書きます。見出しから飛んできた読者や、段落の途中から読み始めた読者にも、何の話かが分かるようにするためです。

具体的には、段落の書き出しを「これは」「その方法は」「前述のとおり」で始めないこと。代わりに主語を毎回明示します。かんたんに言うと、「1段落＝1つの完結した説明」にするということです。

悪い例と良い例を並べます。

• 悪い例：「これを使うと在庫のムダが減ります」（”これ”が何か段落内で不明）
• 良い例：「ABC分析を使うと、優先度の低いC商品の在庫を絞り込め、在庫のムダが減ります」

ステップ4。関連用語と自社情報へ内部リンクをつなぐ

用語ページ同士を、説明的なリンクでつなぎます。関連する用語がリンクでつながっていると、その用語がどんな文脈で使われるのかが、読者にもAIにも伝わりやすくなるからです。

リンクのアンカーテキスト（リンクの文字）は「こちら」「詳細」にしないこと。「在庫回転率の計算方法」のように、リンク先が何かが分かる言葉にします。用語の権威づけの考え方は著者の構造化データでAIに権威を伝える手順もあわせて読むと理解が深まります。

張るリンクの目安は、1ページあたり関連用語2〜4本と、その用語に関係する自社のサービス・事例ページ1本です。数を増やしすぎると、どれが重要か分からなくなるので控えめにします。

ステップ5。構造化データ（schema）を添える

最後に、本文の定義を機械にも分かる形で補足します。用語定義には、schema.orgの「DefinedTerm」「DefinedTermSet」という型が使えます。DefinedTermとは、定義された用語1つを表すための構造化データの型のことです。

WordPressのテキストエディタや、テーマのhead出力部分に、次のようなJSON-LDを埋め込みます。コピーして、値の部分を自社の内容に変えてください。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "DefinedTerm",
  "name": "ABC分析",
  "description": "在庫管理の手法のひとつで、商品を売上や重要度の順にA・B・Cの3グループへ分け、管理の優先順位を決める方法。",
  "inDefinedTermSet": "https://example.com/glossary/"
}
</script>
<!-- name＝用語名、description＝冒頭の定義文とそろえる -->
<!-- inDefinedTermSet＝自社の用語集トップページのURLに変更 -->

ここで守ることは1つだけです。descriptionには、本文に書いた定義文と同じ内容を入れること。本文に見える内容とschemaの中身はそろえます。本文に無いことをschemaにだけ書くのは避けてください。

なお、schemaの正確なプロパティ名や最新の推奨仕様は変わることがあるため、実装前にschema.org公式のDefinedTerm定義で最新の項目を確認してください。JSON-LDの書式が正しいかは、schema.orgのSchema Markup Validatorに貼り付けて構文エラーが出ないかを確認できます。なお、DefinedTermとDefinedTermSetは、Googleのリッチリザルトの対象（Google 検索がサポートする構造化データ マークアップ）に入っていません。Google検索の表示を変えるマークアップではないため、リッチリザルトテストでの検証は前提にしていません。Googleは、生成AI検索にも構造化データは必要ないと説明しているので、DefinedTermは本文を書き終えてから、余力があれば足す順番で問題ありません。

用語定義ページを作ると何が変わるのか

用語定義ページを型どおりに作ると、自社の用語を調べた読者が答えを読めるページができます。AIの回答で参照されれば、そこから指名検索や問い合わせにつながることもあります。ただし、AIの回答に引用されるかどうかは保証されません。すぐに大量流入が起きる施策ではありませんが、じわじわ効く「資産型」の施策です。

読者とAI検索の両方に役立つページにするために押さえておきたいのは、次のような作り方です。

• 定義が言い切り型：「〜と言われています」ではなく「〜である」と断定している
• 一次情報がある：自社の定義・自社の数値・自社の考え方が本文に入っている
• 更新されている：用語の意味が変わったら定義文も直している

逆に、他社の解説をなぞっただけの用語ページは、すでにほかのページで読める情報の言い換えにすぎません。Googleも、AIシステムはさまざまな情報源を確かめるため独自の視点があると役立ち、既存のコンテンツの要約はほかで手に入る情報の言い換えにすぎないと説明しています。ここが分かれ目です。

根拠となる数値や出典を添えた文は、読者がその場で確かめられます。自社の定義と根拠を用語定義ページに書くことは、Googleが勧める「オーディエンスにとって価値があり、独自性のあるコンテンツ」にもつながります。

効果の測り方も決めておきましょう。用語ページ単体でのアクセスだけでなく、AI経由の流入を見ておくと変化に気づけます。測定の具体的な設定はGA4でChatGPT流入を可視化する設定手順で解説しているので、あわせて設定しておくと、施策の手応えを数字で追えるようになります。ただし、GA4の「AI アシスタント」のチャネルに入るのはChatGPT・Gemini・Copilotなどからの訪問で、GoogleのAIによる概要とAIモードからの訪問は「オーガニック検索」に入ります（デフォルト チャネル グループ（アナリティクス ヘルプ））。Googleの生成AI機能での表示回数は、Search Consoleの生成 AI パフォーマンス レポートで、ページごとに確かめられます。

期間の目安。用語ページはインデックスされてAIに認識されるまで時間がかかります。数週間〜数か月かけて増えていくものと考え、公開して終わりにせず、四半期に一度は定義や関連リンクを見直すのがおすすめです。

用語定義ページでよくある失敗と回避法

ここでは、現場で実際にやりがちな失敗を3つ紹介します。どれも「良かれと思ってやったこと」が裏目に出るパターンなので、着手前に目を通しておくと安全です。

失敗1。薄い用語ページを量産してしまう

「用語集は数が命」と考えて、1ページ数十文字の薄い定義ページを何百も作ってしまうケースです。これをやると、どのページも中身が薄くなり、訪問者が知りたい答えにたどり着けません。数だけ増やしても、読者にもAIにも使われないページが積み上がるだけです。Googleも、検索されそうな言葉のバリエーションごとにページを作ることを、主に検索の順位や生成AIの回答を操作する目的で行うと、スパムに関するポリシーの「大量生成されたコンテンツの不正使用」に当たると説明しています（Google 検索の生成 AI 機能向けにウェブサイトを最適化する（Google 検索セントラル））。

回避法は、1ページに「定義＋詳しい説明＋具体例＋関連用語」までしっかり書くこと。最低でも本文で読者の疑問に答えきれる分量を用意します。数を追う前に、1ページの完成度を上げてください。数が必要なら、質を保てるペースで増やします。

失敗2。他社サイトの定義を言い換えただけで作る

忙しいと、既存の解説サイトを読んで言葉を少し変えただけの定義を書いてしまいがちです。この状態だと、AIから見て「同じ情報が他にもたくさんある」ので、自社が引用される理由がありません。

回避法は、自社ならではの一次情報を1つでも足すこと。たとえば「自社の現場ではこう使う」「この業種ではここに注意する」という視点や、自社が実際に扱った例を入れます。他社が書けない一文が、ほかの解説ページとの違いになります。

失敗3。構造化データだけ頑張って本文が空っぽ

schemaを完璧に書けばAIに拾われる、と思い込み、JSON-LDばかり作り込んで本文がスカスカになるケースです。構造化データはあくまで本文の補足なので、本文に定義が無ければ引用のしようがありません。

回避法は、順番を守ること。まず本文の定義文と説明を書き切り、そのあとにschemaを添えます。本文とschemaの内容がズレていないかも必ず確認します。AI向けの特別なマークアップに頼るより、本文の中身を厚くするほうが確実です。

用語定義ページの落とし穴と、現場での妥協点

ここでは、取り組む前に知っておきたい注意点を書きます。用語定義ページは効果的ですが、万能ではありません。向き不向きと、抱えがちなコストを正直にお伝えします。

まず、全部の用語をページ化する必要はありません。ありがちな失敗は、社内で使う用語を片っ端からページにしようとして、運用が回らなくなることです。

優先すべきは、自社サービスに関係が深く、かつ顧客が実際に検索や質問で使う用語です。一般的すぎる用語（例：「マーケティングとは」）は競合が強く、労力に見合いません。

次に、地味に重い作業が「定義の合意」です。同じ用語でも、営業と開発で微妙に意味の捉え方が違うことは珍しくありません。

ページを作る前に、社内で「この用語はこう定義する」と一度そろえる工程が要ります。ここを飛ばすと、部署ごとにバラバラな定義ページが増え、AIにも読者にも混乱を与えます。

内製と外注の切り分けも悩みどころです。定義文を書く部分は、その業務を一番分かっている社内の人が下書きするのが理想です。

一方で、次のような「GEO向けの型に落とす」作業は、慣れていないと時間がかかります。ここは外部の伴走を使うと早い部分です。

• 定義文と段落を、この記事の型に沿って書き換える
• schemaを埋め込む
• 内部リンクを設計する

コストの見落としとしては、「作って終わり」にならない点があります。用語の意味は時間とともに変わり、新しい用語も増えます。年に数回の見直しをする前提で、更新しやすい作りにしておくことが、長く効かせるコツです。逆に言えば、更新できる範囲でしか広げないのが現実的な判断です。

よくある質問

まず今日は、自社サービスに一番近い用語を1つだけ選び、冒頭に「○○とは、〜である」の1文を置けているかを確認してみてください。置けていなければ、その1文を書き足すところから始めます。もう一歩進めたい方は、引用される文章の型をDeep Researchに引用される記事の作り方で確認すると、用語ページ以外にも応用できます。

ここまで読んで、「型は分かったけれど、社内で定義をそろえたり型に落とし込む時間がとれない」と感じた方も多いと思います。コレットラボのGEO（LLMO）対策・AI検索対策では、既存ページの診断から、原稿の制作・修正、公開後の確認まで行います。修正するページの見出しの並び、定義文、FAQ、内部リンク、構造化データの記述内容と設置箇所を指示書に書くので、社内や現在の制作会社で修正することもできます。AI回答での引用と検索順位は保証しません。どのページから修正するか決まっていなくても、ご相談いただけます。GEO（LLMO）対策・AI検索対策について