医療系の記事には監修が入ります。院長や担当医が原稿に目を通し、事実関係と言い回しを確かめてから公開する。この工程を前提に編集の段取りを組むと、専門用語の説明をどこに書くかという判断が、あとの作業量をかなり左右します。
戻ってくる指摘は、説明の文面に集まりがちです。疾患名の言い換え、検査名の略し方、程度を表す語の選び方。読者に伝わるようにと噛み砕いた一文ほど、監修する側は丁寧に読む。ここまではどの院のブログでも起きることで、分かれ目はその直しをどこへ反映するかにあります。
監修の直しは、記事ではなく語に向いている
赤字が入るのは原稿の一文ですが、指摘されているのは、たいていその語の説明そのものです。同じ疾患名は次の記事にも出てくる。半年前に公開した記事にも出ている。記事単位で直すと、直した一本だけが新しい説明になり、残りは前の言い回しのまま置き去りになります。
これは監修する側から見ると、確認の量として返ってきます。記事ごとに説明を書き直していれば、同じ語の説明が記事の本数だけ存在することになる。10本に同じ語が出ていれば、10通りの言い回しを一つずつ読んでもらう形です。表記が揺れていれば、そこも判断の対象に加わる。
説明を語のほうに1件だけ持たせておけば、監修に出すのはその1件になります。記事が何本あっても変わりません。確認してもらう対象が用語の数になり、記事の本数から切り離される。ここが編集側にとっていちばん大きい差です。
説明の置き場所を、記事から辞書へ移す
用語注釈マネージャーは、サイト共通の用語辞書に用語を1件ずつ登録し、本文にその語が出てきたところへツールチップ・注釈・脚注のいずれかで説明を添える作りです。本文と突き合わせるのは用語名と別名（表記ゆれ）で、AIが文脈を推測して拾うわけではありません。純粋な文字の照合です。
医療の記事では、正式名で書く回と略称で書く回が混ざります。英字の表記が入ることもある。拾わせたい表記を別名に並べておけば、どの書き方でも同じ1件に寄ります。ここで取り違えやすいのが読み方（ふりがな）の欄で、こちらは用語集の50音並べ替えと管理画面の検索のためのもの。本文の検出には使われません。欄ごとの分担は用語辞書を1件ずつ育てるに整理してあります。
監修に出すのは、この辞書の1件です。承認された文面をそこへ入れれば、その語を含む記事はどれも同じ説明を出す。辞書・検出・表示・用語集という一連の流れはWordPressで専門用語に注釈・ツールチップを付ける完全ガイドに地図として書きました。
患者向けにどこまで噛み砕くかは、欄と形式で分かれる
粒度の話をします。同じ疾患名でも、来院を考えている人に向けた一文と、経過を追っている人向けの説明では、要る深さが違う。全部を一つの文に詰め込むと、どちらにも届かない文章になります。
用語注釈マネージャーの辞書には説明の欄が2つあり、出る場所が分かれています。本文の注釈に表示されるのは「短い説明」のほう。ツールチップでも注釈ボックスでも脚注でも、本文に出るのはこの欄です。詳細説明の欄を読むのは用語集ページと構造化データページの内容を、検索エンジンなどの機械が読み取りやすい決まった形式で書いた情報。schema.orgの語彙を使い、JSON-LDで埋め込むのが一般的。詳しく見るで、記事の本文には出てきません。つまり、記事に添える一文と、用語集でまとまった量を書く説明を、同じ用語について別々に持てます。
判断としては、本文側の一文は短いほうがいい。長い説明を吹き出しに詰め込んでも読まれませんし、噛み砕く量が増えるほど監修で見る範囲も広がります。深く知りたい人には、辞書の詳細ページURLから自院の解説ページや公的機関の一次情報へ渡す。「詳しく見る」のリンクは辞書側に持てます。
見せ方は用語ごとに3つから選べます。一言で足りる略語や言い換えはツールチップ。前提やただし書きを1〜2文足したい語は、段落の下に枠が出る注釈。出典や参考を並べたいなら脚注で、本文には連番だけを置いて末尾に一覧を作る。どこまで噛み砕くかを決めるのは監修者と編集の仕事で、そこは仕組みが肩代わりしてくれません。決めた結果を1か所に置けるかどうかが、別の問題として残るだけです。
監修が済んでいない語は、辞書に置いたまま出さない
用語には有効・無効の状態があり、無効にした語は注釈に使われません。これを使うと、登録だけ先に済ませておいて、監修が通ってから有効にする進め方ができます。文面を練っている途中の語が、公開記事の吹き出しに出てしまう事故を避けられる。
ただし、これは承認ワークフローの画面ではありません。有効と無効という2つの状態を、運用ルールの側で使っているだけ。誰が有効化してよいかを先に決めておかないと、下書きのつもりの説明がそのまま読者に出ます。辞書を触れる人を絞るほうが、静かに回ります。
説明文のたたき台には、任意の補助があります。WordPressコアのAI機能が有効な環境でだけ「AI で説明案を作成」のボタンが出て、生成された文は入力欄に流し込まれる。自動保存はされず、AIで作った用語には確認のうえ公開するよう注記が出ます。コネクタが無い環境ではボタンが現れないだけで、検出も注釈もそのまま動く。監修の入る運用では、これはあくまで監修へ出す前の素材どまりです。
直した説明を、公開済みの記事へ回す
クリニックのブログは、たいてい何十本か積み上がった状態から用語を整え始めます。既存記事へまとめて行き渡らせるなら、全記事スキャンを使う経路です。対象を投稿タイプ・カテゴリー・期間などで絞り、まずドライランで候補だけを出す。用語・検出された文字・前後の文脈・表示形式・信頼度・状態が並ぶテーブルを見て、絞り込んでから承認します。
この承認は投稿本文を書き換えません。どの用語をその記事で有効にするかを、投稿のメタ情報として記録するだけです。取り消せるのは直前の1回だけなので、条件の往復はドライランの中で終わらせるのが安全（全記事一括注釈の下準備）。いっぽう、記事を書きながらサイドバーの候補を採用したり、ツールバーから手で注釈を付けたりした箇所には、目印が本文に保存されます。この2つは別物として扱ってください。
監修の戻しが効いてくるのはここから先です。辞書の1件を書き換えれば、その語を含む記事の表示は次に開かれた時点で新しい文面になる。記事を開き直して再保存する必要も、承認をやり直す必要もありません。辞書を先に置いて、見た目はそのつど組み立てる。開発していて順序を動かさないと決めたのがこの一点で、監修の戻しが1件で済むのも元をたどればここから来ています。
ひとつ、医療の用語では引っかかりやすい下限があります。日本語でも英字でも最小文字数の既定は3。「予後」「所見」「寛解」のように、患者向けの言い換えがいちばん要る語ほど2文字に収まっていて、そこが丸ごと検出の外にあります。残るのはエディタのツールバーから手で注釈を付ける経路だけで、これは本文に印が残る側です。監修フローを組む前に、この長さの語をどう扱うかは決めておく価値があります。
辞書に閉じられるのは手間であって、責任ではない
線を引いておきます。説明の正しさを担保するのは書き手と監修者であって、プラグインではありません。仕組みが引き受けるのは、承認された文面を全記事で同じに保つところまで。表現が広告や法令の観点で適切かどうかの判断も、院とその監修者の領域にあります。ここを仕組みの側が代われるとは書けません。変わるのは、判断を通す対象が記事の本数分あるのか、辞書の1件なのかという違いだけです。
もう2点、先に知っておくと詰まりません。リンク・ボタン・コードの中にある語は設定に関係なく対象外で、見出しの中も既定では外れています。それとショートコードが出力したテキストの中の語も捕捉できない。予約フォームや料金表をショートコードで組んでいるページでは、そこに書かれた用語には注釈が付かないと考えておいてください。
監修が入るブログで効いてくるのは、説明を上手に噛み砕く技術そのものより、承認された説明が1か所にあることのほうだと思っています。用語が増えるほど、そして記事が増えるほど差が開く。辞書を軸にした持ち方は用語注釈マネージャーの製品ページにまとめてあります。
