Wordpress。この綴りが記事に混ざっていても、たいていの人は読み飛ばします。意味は通じるので。
ただ、公式表記は WordPress で、P は大文字です。メディアとして出す記事に小文字の p が混ざっていると、分かる人には分かる。同じように Javascript（正しくは JavaScript）、Github（GitHub）、Mysql（MySQL）あたりは、書いている本人がまず気づきません。変換候補として自然に出てくるからです。
表記ゆれの検出は、校正の中でいちばん機械に向いた仕事です。判断材料が文字列の中で完結していて、正解が一つに決まる。ただし辞書の作り方を間違えると、正しい箇所を壊します。この記事はそこの話です。
辞書に入るのは3つの情報
表記ゆれの辞書は、最低限これだけあれば動きます。
| 項目 | 例 | 役割 |
|---|---|---|
| 検出表記 | お問合せ | 見つけたい側 |
| 推奨表記 | お問い合わせ | 直したい側 |
| 一致方法 | 部分一致 | どう探すか |
これに「大文字小文字を区別するか」「複数の許容表記」「なぜNGなのかの補足」が足せると、運用が楽になります。補足欄は軽視されがちですが、これがあると指摘のときに理由を出せるので、ライターが納得して直します。「なぜダメなのか分からないまま直す」状態は長続きしません。
一致方法は3種類あります。
- 完全一致：その語だけにマッチ。固有名詞や短い語に向く
- 部分一致：文中のどこにあってもマッチ。日本語ではこれが基本
- 正規表現：パターンで書く。単位表記や連番のような規則的なゆれに使う
日本語は単語の区切りに空白を入れないので、英語のような単語境界の概念が使えません。だから部分一致が主役になります。そしてこれが、後述する落とし穴の原因でもある。
何を入れるかより、何を入れないか
自社のレギュレーションを辞書にするとき、最初は「思いつく限り入れる」でやりがちです。これがうまくいきません。
日本語校正マネージャーには同梱の辞書が5セット入っています。IT系の表記ゆれ20件、一般的な表記ゆれ30件、冗長表現9件、重言14件、それと空の許可語辞書。件数を見ると少なく感じるはずです。OSSの日本語校正辞書（prh や textlint 系。いずれもMIT）には何百件も定番項目があるので、まとめて取り込むこともできました。
作っている側としては件数が多いほうが見栄えがするのですが、やらなかったのは誤検出を1件出すコストが高いからです。ライターは、間違った指摘を2〜3回見た時点でそのツールを信用しなくなります。信用を失った警告は、正しい指摘まで無視されるようになる。だから同梱ぶんは手作業で選びました。
選ぶときに使った基準は4つです。自分で辞書を作るときにもそのまま使えます。
基準1：誤形が正形の部分文字列になるものは入れない
いちばん重要です。
ユーザ → ユーザー を登録したくなります。長音を省く表記は読みにくいので、統一したい気持ちは分かる。でもこれは危険です。
ユーザー という正しい文字列の中に、ユーザ が含まれているからです。部分一致で探すと、正しく書かれた ユーザー にもマッチします。修正を適用すると ユーザーー になる。1回のクリックで正しい箇所が壊れます。
長音を付ける方向の登録は、原則として成立しません。 逆に サーバー → サーバ のように長音を削る方向なら、誤形が正形を含まないので安全です。どちらに統一したいかとは無関係に、方向によって登録できるかが決まる。ここは直感に反するところです。
基準2：単漢字は入れない
事 → こと、時 → とき、為 → ため。公用文の書き換えとしては正しいのですが、辞書に入れると 仕事・時間・行為 に当たります。
漢字1文字は、ほぼ必ず他の熟語の一部になっています。除外リストを作れば回避できなくもないですが、日本語の熟語を網羅する作業になるので現実的ではありません。単漢字は諦めて、レビューで拾うほうが早い。
基準3：品詞で判別が必要な語は入れない
正しく・最も・従って・是非・一杯。これらは文脈によって、ひらがなにすべき場合と漢字のままでよい場合が分かれます。
「従って作業する」の 従って は動詞なので漢字のまま。「したがって、結論は」の接続詞はひらがな。この区別は品詞を見ないとできません。形態素解析を使っていない照合方式では原理的に無理なので、入れない判断になります。
基準4：正しい表記そのものが誤検出されないようにする
IT系の表記ゆれは、大文字小文字だけが違うケースが多い。Wordpress と WordPress のように。
このとき大文字小文字を区別せずに登録すると、正しい WordPress にもマッチしてしまいます。だから同梱のIT辞書は、Wordpress と wordpress の両方を大文字小文字を区別する設定で個別に登録してあります。20件のうち半分は、同じ語の大小違いです。件数は倍になりますが、誤検出はゼロになる。
実際に入っているもの
参考までに、同梱の一般表記ゆれ（30件）はこういう並びです。
- 補助動詞・敬語のひらがな化：
下さい→ください、頂きます→いただきます、有難う→ありがとう - 副詞・接続語：
予め→あらかじめ、概ね→おおむね、殆ど→ほとんど、何故→なぜ、但し→ただし - 送り仮名：
行なう→行う、出来る→できる - 複合名詞：
問合せ→問い合わせ、申込み→申し込み、打合せ→打ち合わせ、取扱い→取り扱い
どれも「誤形が正形の部分文字列になっていない」ことを確認してあります。下さい は ください を含まない。出来る は できる を含まない。この確認を1件ずつやったので、30件で止まっています。
除外の仕組みを先に用意しておく
辞書を運用し始めると、必ず「これは直してほしくない」が出てきます。商品名に Wordpress という綴りが含まれている、引用文の中の表記は原文のままにしたい、といったケース。
対応は2種類あります。
許可語辞書に登録すると、その語句は校正の対象から外れます。商品名・サービス名・固有名詞はここへ入れます。同梱の許可語辞書は空の器として用意してあって、中身は各サイトで入れるものです。
もうひとつは除外設定で、コードブロック・HTMLタグ・URL・メールアドレス・ショートコード・埋め込みブロック・iframe は最初から校正対象外です。引用文は設定でオンオフできて、既定では除外されています。引用は原文を変えられないので、指摘が出ても直せないからです。
指摘が出てしまった場合も、その場で無視できます。この指摘だけ／この投稿だけ／このライターだけ／このカテゴリだけ／このルール自体を一時停止、の5段階。ライター（投稿者・寄稿者）が使えるのは前の2つだけで、サイト全体に効く無視は編集者以上に限っています。ライターが自分の判断でルールを止められると、統一の意味がなくなるので。
直すのは人がボタンを押したとき
検出した表記ゆれには、修正候補としてボタンが出ます。押すと本文のその箇所が置き換わります。
自動では直りません。保存時に勝手に置換する仕組みも入れていない。理由は基準1と同じで、置換は取り返しがつかない操作だからです。1件ずつ人が見て押すぶんには、間違った置換に気づける。全自動にすると、気づけないまま100箇所書き換わります。
なお、ボタンが出るのは本文（RichText）に対してだけです。タイトル・スラッグ・抜粋・メタディスクリプションの指摘は、場所を示すところまで。カスタムHTMLブロックの中も指摘のみになります。
語彙の話と、文の話は別
表記ゆれは「語をどう書くか」の統一です。同じ辞書の仕組みで扱えるものに、もう一つ「文をどう縮めるか」があります。することができます を できます にするような、冗長表現と重言のチェック。仕組みは同じでも、辞書の作り方の勘所が違うので分けて書きました。
表記ゆれを含む8種類のチェックを、WordPressの編集画面の中でどう回すかは編集フローの記事にまとめてあります。辞書とルールの管理画面は日本語校正マネージャーの製品ページから。
