用語集とは、専門用語の定義をまとめ、記事や製品情報で分からない言葉を確認できるようにするページのことです。検索やAIへ伝える際も、画面に読める定義を先に整え、詳しい記事から内部リンクでつなぎます。
製造業のサイトなら、営業が説明を求められる加工用語と、技術記事に繰り返し出る略語を書き出してください。既存ページに正確な説明があるなら、そこを使えるか確認します。用語集を新設するために、同じ答えをもう一つ作る必要はありません。
用語の定義は、言葉の意味を確認するために使います。不良の原因を切り分ける手順や加工の相談条件は、技術記事や製品ページへ案内します。この役割を分けると、用語集が短い技術記事の寄せ集めになるのを防げます。
最初にどの用語を選ぶ？
業界の辞書を全部再現するより、自社の読者がつまずく言葉を選びます。問い合わせの質問、営業資料の注記、製品ページで説明せずに使っている略語を見比べてください。
たとえば加工会社なら、切削、研削、表面処理などの工法名から始める方法があります。ただし、似た用語の違いを説明できる技術担当が必要です。聞いたことのある語を並べるだけでは、正しい定義の管理先になりません。
用語ごとに、表記、読み、略語や別名、定義、確認する担当、関連する記事を記します。社内だけで通じる呼び名なら、その範囲も書きます。社内の表記を業界全体の標準として扱わないようにします。
同じ略語が別の分野でも使われるときは、何の分野の意味かを冒頭に残します。検索語に合う短い題を付けるために、その前提まで削らないでください。
一覧と個別ページはどう分ける？
定義が短く、同じ分野の語を行き来して確認したいなら、一つの一覧にまとめます。各語へ移動できる見出しを付け、一覧の先頭から探せるようにします。五十音順か工法別かは、読者の探し方で決めます。
個別ページへ分けるのは、定義だけでなく、似た用語との違い、図による説明、適用範囲などが必要なときです。一文しか書けない語を独立させ、同じ前置きを足して文字数を増やす作り方は避けます。
| 伝える内容 |
置き場所 |
| 短い意味と読み方 |
用語一覧の各項目 |
| 定義と似た言葉の違い |
用語の個別ページ |
| 原因の調査や対処手順 |
技術記事 |
| 対応範囲や依頼条件 |
製品・サービスページ |
すでに技術記事の冒頭で定義と違いまで答えているなら、その記事を用語の説明先として使えます。別ページを追加する前に、一覧からその説明へ送る形を検討してください。
一覧を親として、どのページへ案内するかを決める手順はハブページと階層の作り方で扱っています。ここでは用語ごとの説明の深さから、分ける必要があるかを判断します。
定義はどんな順番で書く？
最初の文で、何を指す語かを答えます。その後に対象、似た語との違い、具体的な使われ方を補います。会社の設備紹介や、技術の歴史から始めません。
次は加工用語の説明を作るための構成例です。実際の定義文を掲載する前に、技術担当が用語と説明の対応を確認します。
- 用語名と読み方を示す
- 何をする加工かを一文で答える
- 間違えやすい別の加工との違いを補う
- 必要なら模式図と、その図が示す範囲を付ける
- 対応材質や相談条件のページへ案内する
たとえば切削加工という項目なら、どんな作用で材料を加工するかを説明する文を先に用意します。その後で、研削加工との違いをどの観点で説明するかを決めます。対応する精度や材料を、用語の一般的な定義に混ぜません。
答えを先に置き、条件を落とさず短く書く型はAIに引用される文章の書き方にあります。用語集でも、説明が短いことだけを完成の条件にしないでください。何の話か分からなくなる省略は戻します。
記事にも定義を書いてよい？
読者がその場で読むために必要な短い説明は、記事に残します。用語が分からないたびに別ページへ移る設計では、原因や対処の流れを追えなくなるためです。
ただし、長い定義をすべての記事へ複製する必要はありません。定義の管理先は用語集へ寄せ、記事では必要な意味だけを説明し、詳しい定義へ送ります。用語集の表現を直したら、関連する記事も照合できるようにします。
私たちの暦メディアでも、年ごとのページから暦の説明やFAQを別ページへ送っていました。その場で答える形へ直しています。出典は自社メディアの作業記録です。用語集へ集約することと、読む場所から必要な答えを消すことは分けて考えます。
リンクだけで追い出すか、すべてを繰り返すかの二択ではありません。読者が今の文を理解する短い答えを残し、定義の詳細を管理する場所へつなげます。
用語集へ内部リンクをどう張る？
技術記事で初めてその語を使う場所に、必要な説明先を置きます。リンクの文字は、用語名や意味が分かる表現にします。同じ語が出るたびにリンクを付け、文章を読みづらくする必要はありません。
Googleのリンクの指針は、リンク先の内容が分かる簡潔な文字を使うよう案内しています。ページ間のつながりには、通常のリンクとして読み取れる実装も必要です。
用語集からは、その語を使って具体的な判断を説明する技術記事へつなぎます。意味が分かった後に何を読めばよいかを案内するためです。製品ページへも送るなら、用語を使う製品と関係があるかを確認してください。
私たちは、新しい記事から既存記事へ張る一方で、既存記事から新しい記事へ張り忘れました。出典は自社メディアの運営記録です。用語集を公開する際も、用語集から外へ張るリンクだけでは確認が足りません。記事から用語集へ入れるかも見ます。
実装と張り忘れの点検は内部リンクの付け方へ進めます。定義が書いてあることと、説明が必要な場所からたどれることを、別々に確認します。
DefinedTermを入れると検索で有利になる？
schema.orgのDefinedTermは、正式な定義を持つ語や略語などを表すための型です。公式の説明には、次の記述があります。
use description to provide the definition of the term
descriptionへ定義を書く、という指示です。用語名にはname、属する用語集にはinDefinedTermSetを使えます。語に識別コードがあるならtermCodeもありますが、無いコードを新しく作る必要はありません。
ただし、Googleの対応一覧に、DefinedTerm専用のリッチリザルトはありません。schema.orgの型として記述できることと、検索結果に特別な表示が出ることを混同しないでください。
用語の意味を画面へ書かず、構造化データにだけ入れる方法にもできません。注釈を付けるなら、表示する定義と一致させます。種類や検証方法の全体は構造化データの役割で確認できます。
用語集はAI検索にも役立つ？
正確な定義を読み取れる状態にすることはできますが、用語集という形式だけで引用は保証されません。GoogleのAI機能向けの説明も、特別な構造化データや追加の技術要件を求めていません。
AI向けという理由で、定義を細かく分割したページを増やす必要はありません。略語の意味、対象分野、適用範囲が一緒に読めるかを点検します。人が取り違える説明を、注釈だけで正せるとは考えないでください。
公開前には、専門外の担当者に技術記事を読んでもらいます。分からない語から定義へ移れ、戻った後に元の説明を理解できるかを試します。意味が分かっても、似た言葉との差が読めないなら、その点を補います。
サイト設計と内部リンクの相談では、既存記事の一覧と、説明を求められる用語を用意してください。ページ数を決める前に、どの定義をどこで管理し、どの記事から案内するかを決められます。
仕様・出典の確認日：2026年10月23日。
