会社名・サービス名の表記を統一する：辞書の検出側と許可側、どちらに置くか

自社の社名とサービス名は、そのメディアにいちばん多く出てくる固有名詞です。記事の締めにも、事例紹介にも、著者プロフィールにも入る。それでいて、表記が決まっていないまま走っていることが多い。

割れ方には型があります。「株式会社ミライ」なのか「ミライ株式会社」なのか。サービス名は MiraiNote か Mirai Note か「ミライノート」か。2回目以降を「ミライ」と略していいのか。書き手の不注意ではなく、決まっていないので毎回その場で選んでいるだけです。

やることは2つ。使う場所ごとにどの表記を使うかを決めることと、決めた表記を辞書の検出側に置くか許可側に置くかを判断すること。2つ目を飛ばすと、正しく書いた社名のほうが指摘される状態になります。

割れるのは、だいたいこの6箇所

自社の固有名詞で候補が2つ以上できるのは、次のあたりです。

もうひとつ、名前の後ろに一般名詞を続けるときの空きも割れます。「Mirai Note アプリ」と「Mirai Noteアプリ」。英字と日本語のあいだに半角スペースを入れるかどうかは、書き手の癖がそのまま出るところ。

全部を一度に決める必要はありません。記事に出てくる頻度が高い順に片付ければ、残りは使われないまま消えていきます。

決めた表記は、使う場所とセットにする

「正式名はこれ」だけでは運用に乗りません。長い正式名を見出しに入れると折り返しますし、本文で毎回フルネームを書くと読みにくい。だから場所ごとに割り当てます。

このサイトでも、自社プラグインの呼び方は1本目を書く前に決めました。記事で使う呼び名を1つに固定して、そのうえで、見出しに置くのか本文の初出だけなのかを先に割り当てた。決めてあると、書いている最中に迷う場面がそもそも来ません。決めずに10本20本と書き進めた場合、最初にやることになるのは執筆ではなく、自分の記事に何通りの綴りが存在するかを数える作業のほうです。

検出側に置くか、許可側に置くかで扱いが変わる

ここが本題です。

日本語校正マネージャーの辞書は種別で分かれていて、表記ゆれ・禁止語・注意語・固有名詞・許可語・専門用語・クライアント別・ジャンル別があります。自社の固有名詞が関わるのは、このうち2方向。

検出側は、誤った綴りを見つけて正しい綴りを出す使い方です。ミライ株式会社 → 株式会社ミライ のように、誤形と正形が1対1で書ける場合に成立します。表記ゆれのルールで拾う形にすれば、ワンクリック修正のボタンも出る。

許可側は逆で、その語句を校正の対象から外します。同梱の許可語辞書は0件の空の器で、中身は各サイトで入れるものです。

どちらに置くかは、次の順で決まります。

2番が見落とされやすい。同梱の一般表記ゆれ辞書30件には 問合せ → 問い合わせ、出来る → できる が入っています。サービス名が「出来るナビ」だったら、名前を書くたびに指摘が出ることになる。正しい社名なのに、辞書のほうがその文字列を誤形として持っている状態です。英字と数字が混じる名前なら、全角・半角のルールにも当たります。

この型の指摘は直せません。書き手は正しく書いているので。許可語辞書に1行入れて、校正の視界から外すのが正解になります。

英字名を検出側に置くときは、登録の仕方でもうひとつ引っかかります。MiraiNote を正しい綴りと決めたとして、混ざるのは Mirainote・mirainote・MiraiNOTE あたり。ここで大文字小文字を区別しない設定にして1件にまとめると、正しい MiraiNote にも当たります。同梱のIT表記ゆれ辞書が誤形1つにつき1行、大小を区別して並べてあるのはこの事故を避けるためで、自社の英字名も同じ作りにします。行数は増えますが、正しく書いた側は素通りする。

辞書に入れてはいけない語の基準は表記ゆれ辞書の作り方に3つ挙げたので、登録の前にそちらを見てください。

略称の統一だけは、辞書に持たせられない

その基準のうち1つが、自社名でそのまま効きます。誤形が正形の部分文字列になる登録は成立しないというもの。

ミライ → 株式会社ミライ を登録したくなりますが、これは置けません。部分一致で探すと、正しく書かれた 株式会社ミライ の中の ミライ にも当たるからです。略称を正式名へ戻す方向は、原理的に持てない。

逆方向の ミライ株式会社 → 株式会社ミライ なら、誤形が正形を含まないので置けます。前株・後株の入れ替わりは辞書で拾えて、略称は拾えない。同じ「社名の統一」でも、割れ方によって機械に渡せるものと渡せないものが混ざります。

なので略称の統一は、機械に渡さず決めごとの側に残します。機械に守らせるのは正式名の綴りだけ。略称をどこから使うかは、さきほどの「使う場所」の割り当てで扱う。ここを混ぜると、社名の一部を含む一般語にまで指摘が飛びます。

社名のルールは、ライター側で外せないようにする

表記のルールには、記事の都合で緩めていいものと、そうでないものがあります。

インタビューの書き起こしで長文チェックを切る、引用の多い記事で表記ゆれを弱める。これは妥当な運用です。一方、社名の正式表記は記事の都合で変わりません。対外的に使う名前なので。

そのための仕組みが強制ルールです。レイヤーの一段ではなく、ルール側に持たせる属性で、下の層で何を設定しても最後に元へ戻ります。社名の正式表記は、この属性のいちばん素直な使いどころ。重ねる仕組みそのものはルールの強さを対象ごとに変える記事にあるので、ここでは使いどころだけ。

ただし、外せなくすることと、Errorに上げて公開を止めることは別の判断になります。同梱ルール9本はすべてWarningで、既定プロファイルに公開ブロックは付いていません。社名の誤記で公開を止めるかどうかは媒体によります。まずWarningのまま強制ルールにして、それでも同じ指摘が出続けるようならErrorへ上げる。この順のほうが安全です。

引用文は既定で校正の対象外になっています。他社の資料が自社名を誤記していて、引用は原文のまま載せたいという場面でも、指摘は出ません。

過去記事の綴りは、別の作業になる

線を引いておきます。現行バージョンに、過去記事の一括スキャンはありません。

校正が走るのは、編集画面で開いている記事と、保存や公開のときです。辞書を整えても、去年の記事に入っている誤形はそのまま残る。ここを期待して入れると、想定と違うことになります。

過去分は、WordPressの検索や記事のエクスポートで綴りを洗い出して、直す価値のあるページだけ開く形になります。全部は開かなくていい。リライト予定のもの、流入がある上位のもの、会社概要や事例のように名前が何度も出るページ。この3種で、読者の目に触れる箇所はだいたい片付きます。

裏を返せば、決めるのが早いほど後から直す本数は減ります。記事が数本のうちに決めておけば、この作業自体が発生しません。

明日やる順番

手順に落とすとこうなります。

1をやると、たいてい想定より候補が多く出ます。それが「決まっていない」の中身です。

5つを編集フローのどこへ挟むかは、編集フローに校正を組み込む記事のほうで扱いました。辞書の登録画面と強制ルールの設定は、日本語校正マネージャーの製品ページ側にまとめてあります。