専門記事を書いていると、避けて通れない用語が必ず出てきます。士業なら「善管注意義務」、医療なら「寛解」、不動産なら「セットバック」。読者の半分は知っていて、半分は知らない。全員に向けて毎回かっこ書きで補うと本文が重くなり、省けば知らない層が離れていく。この板挟みを、本文の流れを保ったまま解くのが用語への注釈という仕組みです。
WordPressで実現する道具はいくつかありますが、単発のツールチップを貼るだけでは記事が増えたときに破綻します。個別のやり方に入る前に、辞書に用語を登録し、本文から自動で見つけ、ツールチップや注釈で見せ、最後に用語集ページへまとめる——この一連の流れを地図として先に描いておきましょう。細部は各詳細記事に譲り、ここでは全体像とつまずきやすい設計判断を押さえます。
4つの段が1つの辞書でつながる
用語注釈の仕組みは、大きく4つの段に分かれます。
- 辞書に登録する：用語名・短い説明・詳しい説明・別名などをサイト共通の一箇所にためる。
- 本文から検出する：登録した用語が記事のどこに出てくるかを照合して見つける。
- 表示形式を選ぶ：見つけた箇所をツールチップ・注釈・脚注のどれで見せるか決める。
- 用語集にまとめる：辞書の中身を一覧ページとして書き出し、サイト全体の索引にする。
肝は、この4段が別々の道具ではなく一つの辞書でつながっている点です。用語を1回登録すれば、サイト内のどの記事に出ても同じ説明が使い回せる。説明を直したいときも、辞書を1箇所直せば全記事に反映される。記事ごとに手で補足を書いていた頃とは、更新のコストがまるで違います。
検出はAIではなく、地道な文字の照合
先に思想として伝えておきたいことがあります。用語の検出にAIは使いません。
「本文を賢く読んで用語を拾ってくれる」と期待されがちですが、実際に動いているのは、辞書に登録した用語名と別名を本文の文字列と突き合わせる純粋なロジックです。DOMのテキストノードだけを走査し、最長一致を優先し、既定では各記事で初出の1回だけに印を付ける。日本語の助詞（を・が・は・に…）をまたぐ照合や英数字の単語境界といった細かな条件は設定で調整できますが、根っこは「登録した文字が本文にあるか」を見ているだけ。
この割り切りには理由があります。辞書に載っている用語は必ず拾われ、載っていない用語は拾われない。この予測可能性が、専門メディアの一貫性を支えます。もし判定が記事ごとに揺れれば、同じ用語がある記事では注釈付き、別の記事では素通り、という不整合が起きてしまう。文字照合はそこを断ち切ります。
補足すると、検出に使うのは用語名と別名（表記ゆれ）まで。読み方（ふりがな）は検索や50音並べ替えのためのもので、検出には使いません。この線引きを先に知っておくと、あとで「なぜこの表記が拾われないのか」と悩まずにすみます。
なお、説明文の下書きをAIに手伝わせる補助機能は別に用意されています（WPコアのAIコネクタが有効なときだけ現れる任意のボタンで、生成案は欄に流し込まれるだけ。無くても検出も注釈も普通に動きます）。検出のAI不使用と混同しないよう、ここも分けておきます。
「本文を書き換えるか」は経路で変わる——一番の分かれ道
導入を検討する人がまず気にするのが「プラグインを入れると投稿本文が改変されるのか」という点です。ここは経路で分けて説明します。ひとまとめに「一切書き換えません」と言い切るのは、事実に反するからです。
全経路に共通する事実がひとつ。吹き出しや注釈枠、脚注リストといった見た目そのものは表示時に組み立てられ、投稿本文には保存されません。ここは安心してよい部分です。
分かれるのは、用語の印（span）を本文に書き込むかどうか。付け方で変わります。
| 付け方 | 本文（post_content）への影響 |
|---|---|
| 全記事スキャンでまとめて承認 | 変えない。メタ情報に記録するだけの非破壊 |
| 個別記事エディタで「採用」・手動で注釈 | 本文にマーク（span）が残る |
全記事をまとめてスキャンして承認する経路は、どの用語をどこに効かせるかをメタ情報として記録するだけで、post_contentには手を入れません。何百記事あってもここは非破壊です。逆に、個別記事のエディタで候補を1つずつ「採用」したり手作業で注釈を付けたりすると、その箇所には印が本文に挿入されて保存される。「本文へ適用」という操作も、承認済みでまだ本文に反映していない分を書き出すブリッジで、これは本文に印を残す側です。
どちらが良いという話ではありません。サイト全体を触りたくないなら全記事スキャン、記事単位で細かく制御したいなら個別採用と、目的で選べばいい。ただ「どんな付け方でも本文は無傷」ではないことは、最初に知っておくと後で困りません。
3つの見せ方を用語の性格で選ぶ
検出した用語をどう見せるかは、用語の性格で決めます。表示形式は3つ。
- ツールチップ：短い説明・略語・読みを、ホバー（スマホはタップ）で吹き出し表示。「詳しく見る」で詳細URLへ飛ばすこともできる。さらっと補足したい語に向く。
- 注釈（注釈ボックス）：用語を含む段落の下に、補足の枠を出す。1〜2文では足りない、少し腰を据えた説明向け。
- 脚注：本文に連番の参照を置き、記事末尾に一覧をまとめる。参照と脚注は相互リンクで行き来でき、読み終えたら本文へ戻れる。学術的な体裁や出典めいた補足を並べたいときに。
色や文字サイズ、脚注見出しといった見た目は「コンテンツ注釈 > 設定 > 表示テンプレート」でサイト全体をまとめて調整します。用語ごとに既定の表示形式を辞書側で決めておけば、いちいち指定せずに済みます。
用語集ページで索引をつくる
最後の段が用語集です。辞書にためた用語を、読者が引ける一覧ページとして書き出します。ショートコードかブロックで設置できます。
[cam_glossary]並び順（読みの50音・カテゴリー・用語名）、説明の粒度（短い説明だけ・詳細も・両方）、カテゴリー絞り込み、列数（1〜4）を指定できます。用語ごとに掲載のオン・オフも切り替えられるので、内部用の用語は伏せておく、といった運用も可能です。
地味な効き目ですが、用語集だけを置いたページはJavaScriptを読み込まず、CSSだけで表示されます。注釈のある記事ページでのみ軽量なバニラJS（jQuery非依存）が動く設計なので、索引ページを増やしても表示は重くなりません。
この地図をどう歩くか
ここまでが用語注釈の全体像でした。辞書に登録し、純ロジックで検出し、3つの形式で見せ、用語集で索引する。この4段が頭に入っていれば、どの詳細記事から読み始めても迷いません。
自分のサイトでどう組むかを考えるなら、まず「サイト全体を非破壊で回したいのか、記事単位で細かく制御したいのか」を先に決めるのがおすすめです。そこが決まれば、検出条件の詰め方も表示形式の選び方も、自ずと絞れてきます。
この一連の仕組みをそのまま形にしたのが用語注釈マネージャーです。辞書での一元管理から検出、3つの表示形式、用語集ページまでを1つのプラグインで通しています。全体像を押さえたうえで細部を検討したい方は、製品ページもあわせてどうぞ。
