社内用語集で最初に決めるべきなのは、ツールではありません。誰が読むか、どこから引くか、誰が直すか。この三つです。
入社したばかりの人にとって、社内文書の「BCP」「稼働」「一次請け」は初見の暗号です。書いた側には空気のような語なので、そのズレは書いた側からは見えない。そこで用語集を作ろう、という話になる。表計算に一覧を組み、共有フォルダに置き、そこで止まります。公開ブログに置く用語集と社内向けの用語集は、読み手・引き方・更新者の三つがそろって違うのに、同じ作り方をしてしまうからです。WordPressで社内ポータルを運用しているなら、辞書を作り始める前にこの三つを決めたほうが結果的に早い。
誰が読むかを決めると、載せる語が決まる
社内の用語一覧には、社外に出せない語がかならず混ざります。案件のコードネーム、内製システムの名前、取引先を指す社内だけの略称。全員に配りたい語と、一覧には並べたくない語が、同じ辞書に同居することになる。
用語注釈マネージャーの用語辞書は、用語ごとに「用語集に掲載する」のオン／オフを持っています。オフにした語は用語集ページの一覧から外れるだけで、辞書には残り、文書中の注釈には使われ続ける。伏せるのは一覧への露出であって、説明そのものではありません。
有効・無効のスイッチと掲載のスイッチを分けてあるのは、この二つが別の判断だからです。使うのをやめた語と、使うけれど一覧には出さない語では、状態が違う。ひとつのスイッチで兼ねると、目立たせたくない語を無効にした瞬間に文書側の注釈まで消えます。この仕様にしたのは、その取り違えを構造のほうで防ぎたかったからでした。
ここで線を引いておきます。掲載オフは閲覧制限ではありません。一覧に出ないだけで、その語を含む文書を開けば注釈は表示される。誰にサイトを見せるかはWordPress側——サイトそのものをどう閉じるか、認証をどう挟むか——の担当で、辞書側は権限を一切持ちません。読ませたくない情報は、辞書ではなくサイトの入口で止める。
引きに行かせるより、説明を文書へ寄せる
用語集ページを作り、周知メールを流し、そのあと誰も開かない。社員が普段読んでいるのは規程・手順書・議事録・引き継ぎメモであって、用語集そのものではないからです。
用語集を「引きに行く場所」として設計すると、そこが弱点になります。読んでいる文書からいったん手を離させる前提だからです。だから設計を裏返す。用語集へ人を呼ぶのではなく、説明のほうを文書に寄せる。本文の語にその場で説明が出れば、読む手が止まりません。社内文書なら、割り当てとしては次の形が噛み合います。
| 社内文書に出てくるもの | 向いている見せ方 |
|---|---|
| 略語・内製システム名 | ツールチップ（一文で足りる。ホバー、スマホはタップ） |
| 前提・注意・運用上のただし書き | 注釈（その段落の下に補足の枠） |
| 規程番号・参照先・出典 | 脚注（本文に連番、末尾に一覧、相互リンク） |
一覧ページが不要になるわけではなく、用途が変わります。引くための場所ではなく、棚卸しのための一枚。固定ページにショートコードを置けば辞書から生成されるので、並び順や列数の指定は用語集ページを辞書ひとつで自動生成するのほうを見てください。
誰が直すかで、登録する語の粒度が決まる
辞書はサイト共通のマスターで、説明の実体は一つの用語に一つ。社内で最初に揉むのはここです。同じ語の意味が部署ごとに違う、という状況が普通にあるから。「稼働」が製造では設備の運転を指し、開発では人の工数を指す、というたぐいの衝突。
一用語＝一説明である以上、定義が割れる語は辞書に向きません。登録するのは全社で一意に決まる語だけ、と割り切る。判断がつかない語を無理に入れると、どちらの部署が読んでも半分だけ間違っている説明が、全文書に配られてしまいます。
更新者は絞ったほうが静かに回ります。決裁の済んでいない語は有効にしなければ注釈に使われないので、登録だけ先に済ませ、話が固まってから有効化する進め方ができる。ただし承認ワークフローの画面が用意されているわけではありません。有効・無効という二つの状態を、運用ルールの側で使うだけ。カテゴリーは階層で持てるので、部署や業務で切っておくと、有効化・カテゴリー付与・表示形式の適用といった一括操作でまとめて処理できます。
表計算の用語一覧を、辞書に移す
社内用語集は、たいてい手元にリストがある状態から始まります。ゼロから作るのではなく、すでにある一覧を移す作業。
残すのは全社で一意に決まる語だけ、というのが前節の判断でした。そのうえで効いてくるのが、どの表記を用語名に置くかです。本文との照合に使われるのは用語名と別名（表記ゆれ）の二つなので、社内文書に実際に書かれている表記を用語名にする。文書に「BCP」とあるなら用語名も「BCP」で、正式名称・英字表記・カタカナ・旧称のほうを別名に並べます。正式名称だけを登録すると、文書中の略語は拾われません。読み方の欄は五十音の並べ替えと管理画面の検索に使うもので、検出には関わらない。
説明の欄は二つありますが、文書の中に出るのは片方だけです。ツールチップでも注釈でも脚注でも、本文に表示されるのは「短い説明」に書いた文。詳細説明の欄を読むのは用語集ページと構造化データページの内容を、検索エンジンなどの機械が読み取りやすい決まった形式で書いた情報。schema.orgの語彙を使い、JSON-LDで埋め込むのが一般的。詳しく見るのほうなので、文書側に説明を出したいなら短い説明を必ず埋めます。フィールドごとの役割は用語辞書を1件ずつ育てるに整理してあります。
辞書とカテゴリーはJSON設定やデータを受け渡すためのテキスト形式。メモ帳でも開けるが、Excelで表として開くものではなく、主にツール同士のやり取りやバックアップに使う。で書き出し・読み込みができ、取り込み時は差分プレビューで中身を確かめてから本適用に進む。同名の語があるときは、スキップ／マージ／上書き＋追加のどれで扱うかを選びます。
すでに書かれた文書へ行き渡らせる
社内ポータルは、たいてい文書がそれなりに積み上がった状態です。全記事スキャンで対象を投稿タイプ・カテゴリー・期間などで絞り、まずドライランで候補だけを出す。候補テーブルに用語・検出された文字・前後の文脈・表示形式・信頼度・状態が並ぶので、そこで絞り込んでから承認します。
社内文書で効いてくるのは、この経路が本文を書き換えない点です。規程や手順書は改訂履歴を残す運用になっていることが多く、用語注釈を入れたいだけで全文書の更新日が動くのは避けたい。全記事スキャンの承認は投稿メタに記録するだけで、本文には触れません。いっぽう個別記事のエディタで候補を採用した注釈は本文に印が残るので、この二つは別物として扱ってください（本文が書き換わらない仕組み）。
社内用語集ならではのつまずきも一つ。前の節で定義を揉んだ「稼働」のような2文字の語は、既定の検出から外れます。定義が割れやすい語ほど短い、というのがややこしいところです。承認の取り消しが効くのは直前の一回だけなので、調整の往復はドライランの中で終わらせるのが安全です。
外に出ない環境でも動く。ただしマルチサイトは前提の外
注釈・用語集・構造化データの表示に、外部サービスは要りません。外向きの通信が絞られたイントラでも、辞書と本文の照合はサーバーの中で完結する。検出はAIを使わない純粋なロジック照合なので、APIキーも従量課金も発生しません。説明文のAI下書きだけは任意機能で、WordPressコアのAI機能が有効な環境にボタンが出るだけ。無効な環境ではボタンが現れないまま、ほかの機能はそのまま動きます。
動作条件はWordPress 6.0以上・PHP 8.1以上。マルチサイト1つのWordPressで複数のサイトをまとめて運営する機能。有効にするとプラグインの動き方が変わり、対応していないプラグインもある。には対応していないので、社内ポータルが一つのサイトで完結している構成が前提になります。
社内用語集は、作り終えた時点ではまだ価値が出ていません。次に入ってきた人が最初の一本を止まらずに読み切れたか、そこだけが判定材料。辞書を一つ置いて文書の側から引けるようにする形は、用語注釈マネージャーの製品ページにまとめてあります。
