専門記事を書いていると、避けて通れない用語が必ず出てきます。士業なら「善管注意義務」、医療なら「寛解」、不動産なら「セットバック」。読者の半分は知っていて、半分は知らない。全員に向けて毎回かっこ書きで補うと本文が重くなり、省けば知らない層が離れていく。この板挟みを、本文の流れを保ったまま解くのが用語への注釈という仕組みです。
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文では足りない、少し腰を据えた説明向け。
- 脚注：本文に連番の参照を置き、記事末尾に一覧をまとめる。参照と脚注は相互リンクで行き来でき、読み終えたら本文へ戻れる。学術的な体裁や出典めいた補足を並べたいときに。
色や文字サイズ、脚注見出しといった見た目は「コンテンツ注釈 > 設定 > 表示テンプレート」でサイト全体をまとめて調整します。用語ごとに既定の表示形式を辞書側で決めておけば、いちいち指定せずに済みます。
用語集ページで索引をつくる
最後の段が用語集です。辞書にためた用語を、読者が引ける一覧ページとして書き出します。ショートコードかブロックで設置できます。
- イメージマップ いめーじまっぷWeb技術・データ形式
1枚の画像の上にクリックできる領域を座標で指定する、古くからあるHTMLの仕組み。画像の縮小に領域が追従しないため、スマホで崩れやすい。
詳しく見る- 医療広告ガイドライン いりょうこうこくがいどらいん法令・ガイドライン
厚生労働省が定める、医療機関のWebサイトや広告に書いてよいこと・いけないことの基準。患者の体験談や治療効果の断定などが制限される。
- ACF えーしーえふWordPressの仕組み
Advanced Custom Fields。投稿に独自の入力欄（カスタムフィールド）を追加するプラグインの定番。無料版と有料のPro版がある。
- SVG えすぶいじーWeb技術・データ形式
図形を点と線の数式で持つ画像形式。拡大しても荒れず、都道府県ごとのようにパーツ単位で色やクリック動作を付けられる。
- オウンドメディア おうんどめでぃあ運用・マーケティング
企業が自社で所有・運営するメディア。広告や外部媒体と違い、自社のサイトやブログとして記事を蓄積していく。
- カスタム投稿タイプ かすたむとうこうたいぷWordPressの仕組み
「投稿」「固定ページ」とは別に用意する独自の投稿の種類。物件・店舗・用語のように同じ形の情報を、通常の記事と混ぜずに管理する。
- カスタムフィールド かすたむふぃーるどWordPressの仕組み
投稿に本文とは別の「項目名と値」を持たせる入力欄。資本金や営業時間のような値を本文の外で管理でき、ACFなどのプラグインで追加するのが一般的。
- キャッシュ きゃっしゅWordPressの仕組み
表示を速くするため、一度作ったページや画像を保存して使い回す仕組み。サーバー・プラグイン・ブラウザ・CDNの各段階にあり、「直したのに反映されない」原因になりやすい。
- Cookie くっきーWeb技術・データ形式
サイトが閲覧者のブラウザに保存する小さなデータ。ログイン状態の維持や、同じ人の再訪問の識別に使われる。
- 景表法 けいひょうほう法令・ガイドライン
不当景品類及び不当表示防止法。「No.1」「最安」のように実際より良く見せる表示や、根拠のない比較表示を規制する。
- 構造化データ こうぞうかでーたWeb技術・データ形式
ページの内容を、検索エンジンなどの機械が読み取りやすい決まった形式で書いた情報。schema.orgの語彙を使い、JSON-LDで埋め込むのが一般的。
詳しく見る- CSV しーえすぶいWeb技術・データ形式
カンマ区切りのテキストファイル。ExcelやGoogleスプレッドシートでそのまま開ける、表データの受け渡し形式。
- CTA しーてぃーえー運用・マーケティング
Call To Action。「お問い合わせ」「資料請求」など、読者に次の行動を促すボタンやリンク、またはその置き場所のこと。
- CDN しーでぃーえぬWeb技術・データ形式
Content Delivery Network。画像やCSSなどのファイルを各地のサーバーに複製して配信する仕組み。独自のキャッシュを持つため、更新が反映されない原因になることがある。
- JSON じぇいそんWeb技術・データ形式
設定やデータを受け渡すためのテキスト形式。メモ帳でも開けるが、Excelで表として開くものではなく、主にツール同士のやり取りやバックアップに使う。
- JSON-LD じぇいそんえるでぃーWeb技術・データ形式
構造化データをページに埋め込む書き方のひとつ。HTMLの中に本文とは別の記述として置かれ、画面の見た目には影響しない。
- 診断コンテンツ しんだんこんてんつ運用・マーケティング
いくつかの質問に答えると結果が返る形式のコンテンツ。おすすめ商品の提案やタイプ分けなど、読者が自分に当てはめた結果を持ち帰れる。
- ステージング すてーじんぐWordPressの仕組み
公開中のサイトと同じ内容で用意する確認用のコピー。プラグインの更新やデザイン変更を、本番のサイトに影響させずに試す場所。
- スラッグ すらっぐWordPressの仕組み
URLの末尾に使う、投稿やカテゴリーごとの英数字の名前。このサイトなら plugear.net/wordpress-japan-map/ の「wordpress-japan-map」の部分。
- タクソノミー たくそのみーWordPressの仕組み
投稿を分類する仕組みの総称。カテゴリーとタグが標準で、プラグインやテーマが「エリア」「業種」のような独自の分類を追加することもある。
- WP-Cron だぶりゅーぴーくろんWordPressの仕組み
WordPressが予約投稿や定期処理を動かす仕組み。サーバーの時計ではなく、誰かがサイトを開いたタイミングで動くため、アクセスの少ないサイトでは遅れることがある。
- ツールチップ つーるちっぷWordPressの仕組み
用語やアイコンにマウスを重ねたとき（スマホではタップ）に出る小さな吹き出し。ホバーで出す前提の表示なので、スマホでの出し方は別に決める必要がある。
- 特定商取引法 とくていしょうとりひきほう法令・ガイドライン
通信販売などで事業者名・所在地・返品条件などの表示を義務づける法律。ネットで物やサービスを売るサイトには「特定商取引法に基づく表記」のページが要る。
- ドライラン どらいらんWeb技術・データ形式
実際には反映せず、「反映したら何がどう変わるか」だけを一覧で確認する試し実行。件数や対象を見てから本番の実行に進む。
- パーマリンク ぱーまりんくWordPressの仕組み
投稿や固定ページごとの固定URL。WordPressでは「設定 > パーマリンク」でURLの形式を決め、個々の末尾（スラッグ）は編集画面で変える。
- BYOK びーわいおーけーWeb技術・データ形式
Bring Your Own Key。AIの利用料を、プラグインの提供者経由ではなく、自分で契約したAPIキーで直接支払う方式。
- ベクター べくたーWeb技術・データ形式
画像を点の集まりではなく、線や面の数式として持つ形式。拡大しても輪郭がぼけない。Web上ではSVGが代表。
- ホバー ほばーWeb技術・データ形式
マウスカーソルを要素の上に重ねること。クリックせずに吹き出しなどを出す操作で、指で触るスマホやタブレットにはこの操作がない。
- マルチサイト まるちさいとWordPressの仕組み
1つのWordPressで複数のサイトをまとめて運営する機能。有効にするとプラグインの動き方が変わり、対応していないプラグインもある。
- メタディスクリプション めたでぃすくりぷしょんWeb技術・データ形式
検索結果でタイトルの下に表示される説明文。本文とは別にページごとに設定し、SEOプラグインの入力欄から書くことが多い。
- 薬機法 やっきほう法令・ガイドライン
医薬品、医療機器等の品質、有効性及び安全性の確保等に関する法律。化粧品・健康食品・医療機器などの広告で、効能効果の言い方を制限する。
- reCAPTCHA りきゃぷちゃWeb技術・データ形式
Googleが提供する、フォームの送信者が人間か自動プログラムかを判定する仕組み。スパム対策としてContact Form 7などと組み合わせて使う。
- リダイレクト りだいれくとWeb技術・データ形式
あるURLを開いたとき、別のURLへ自動で転送すること。ページを消す代わりに関連ページへ送ると、検索エンジンからの流入やブックマークを失いにくい。
- 離脱率 りだつりつ運用・マーケティング
途中でやめて最後まで進まなかった人の割合。診断やフォームでは設問ごとに見ると、どこで止まっているかがわかる。
詳しく見る- リッチリザルト りっちりざるとWeb技術・データ形式
検索結果に、星評価・FAQ・パンくずなど、通常のタイトルと説明文以外の要素が付いて表示される形式。構造化データを付ければ必ず出るものではない。
並び順（読みの50音・カテゴリー・用語名）、説明の粒度（短い説明だけ・詳細も・両方）、カテゴリー絞り込み、列数（1〜4）を指定できます。用語ごとに掲載のオン・オフも切り替えられるので、内部用の用語は伏せておく、といった運用も可能です。
地味な効き目ですが、用語集だけを置いたページはJavaScriptを読み込まず、CSSだけで表示されます。注釈のある記事ページでのみ軽量なバニラJS（jQuery非依存）が動く設計なので、索引ページを増やしても表示は重くなりません。
この地図をどう歩くか
ここまでが用語注釈の全体像でした。辞書に登録し、純ロジックで検出し、3つの形式で見せ、用語集で索引する。この4段が頭に入っていれば、どの詳細記事から読み始めても迷いません。
自分のサイトでどう組むかを考えるなら、まず「サイト全体を非破壊で回したいのか、記事単位で細かく制御したいのか」を先に決めるのがおすすめです。そこが決まれば、検出条件の詰め方も表示形式の選び方も、自ずと絞れてきます。
このサイトでも、同じ仕組みで動かしています
この記事を載せている plugear.net にも、2026年9月に用語注釈マネージャーを入れました。ただし、この記事では「ツールチップ」「ホバー」に吹き出しを出していません。用語注釈そのものを調べに来た人に、本文が説明している語をもう一度吹き出しで説明しても二重になるだけだからです。実物は、たとえばWordPressでクリックできる日本地図を作る方法の「SVG」や「ベクター形式」にマウスを乗せると見られます（スマホはタップ）。
登録した用語は35件。公開済みと予約中を合わせた124本の記事を1回の全記事スキャンにかけ、263か所の候補をまとめて承認しました。反映は記事のメタ情報に記録するだけの経路（上の表の「変えない」側）なので、投稿本文は1文字も変わっていません。説明文を直したくなったら辞書を1か所直せば、承認した記事すべてに同時に効きます。
辞書を作るときに先に決めたのは、用語の候補ではなく「誰に向けた解説か」でした。想定したのは、管理画面は毎日触るがコードは書かない担当者。管理画面から触るけれど自分では作らない仕組み（カスタムフィールド、WP-Cron、ステージング）、記事の表現を縛る法令（薬機法、景表法）、運用の言葉（CTA、離脱率）には付ける。逆に、開発者の話にしか出てこない語（DOM、REST API、フック）や日常操作の語（プラグイン、固定ページ）には付けない。読者を1人に絞ってから選ぶと、「専門用語っぽい語を片っ端から登録する」より迷いがずっと少なくなりました。
承認したあとに、ひとつ手戻りがありました。同じ用語でも、記事によって読者が違います。制作会社向けの記事で「カスタムフィールド」を解説されても邪魔ですし、用語注釈マネージャー自身の記事で「ツールチップ」に吹き出しが出るのは、先に書いたとおり本文と二重になります。そこで承認した263か所のうち71か所を記事単位で外し、いま表示しているのは80記事・192か所です。辞書はサイトに1つでも、効かせる場所は記事ごとに決める。この一段は、入れてみるまで思いつきませんでした。
この一連の仕組みをそのまま形にしたのが用語注釈マネージャーです。辞書での一元管理から検出、3つの表示形式、用語集ページまでを1つのプラグインで通しています。全体像を押さえたうえで細部を検討したい方は、製品ページもあわせてどうぞ。
