社内の表記レギュレーションをCSVで持ち回す（複数メディア・制作会社の運用）

制作会社で、クライアントのオウンドメディアを5本受けているとします。

A社は「お客様」、B社は「お客さま」。A社は数字を半角に統一、C社は本文中の数字だけ全角。D社には言ってはいけない競合他社名のリストがある。E社は業界用語の表記が独特で、一般的な表記に直すと怒られる。

このルール群を、どこで管理しているでしょうか。たいていは案件フォルダの中のスプレッドシートです。そして担当者が変わると、その存在ごと引き継がれない。

レギュレーションを「データ」として持つ

表記ルールが文書であるうちは、資産になりません。読まれないし、更新されないし、持ち運べない。

これをデータにすると性質が変わります。行と列に整理されていて、機械が読めて、そのまま別のサイトへ移せる形。

日本語校正マネージャーの辞書は、CSVとJSONで入出力できます。エクスポートすると、辞書セットの中身がそのままファイルになる。インポートすれば、別のサイトに同じ辞書が入る。

これが効くのは、単発の1サイトより複数サイトを回している運用です。

いずれも「同じ内容を2箇所で手入力する」のをやめる話です。

CSVの列は3つ＋α

辞書エントリが持つ項目はこうなっています。

項目	内容
検出表記	見つけたい語
推奨表記	直したい語
許容表記	複数の言い方を許す場合
一致方法	完全一致 / 部分一致 / 正規表現
大文字小文字の区別	する / しない
補足	なぜNGか、どう言い換えるか
有効・無効	一時的に止められる

スプレッドシートで管理しているNGリストがあるなら、列を合わせて書き出せばそのまま取り込めます。「過去に法務レビューで指摘された表現」を蓄積したシートなら、たいていこの形に落とし込めるはず。

辞書は種別で分けられます。表記ゆれ / 禁止語 / 注意語 / 固有名詞 / 許可語 / 専門用語 / クライアント別 / ジャンル別。クライアント別に辞書セットを作っておけば、案件が終わったときにその辞書だけ無効化する、といった運用ができます。

取り込みは2段階にしてある

インポートは一発では確定しません。dry run（プレビュー）→ 確定の2段階です。

ファイルを選ぶと、まず解析だけが走ります。表示されるのは、取り込まれる件数と、エラーになった行の一覧（100件まで）。ここで内容を確認して、問題なければ確定を押す。押すまでデータベースには何も入りません。

2段階にした理由は単純で、辞書のインポートは事故が起きたときに戻しにくいからです。500行のCSVを取り込んで、そのうち列がずれた50行が変な内容で入っていた場合、どれが今回入ったものかを後から特定するのは骨が折れます。

エラー行の表示で拾えるのは、列の数が合わない行、一致方法に不正な値が入っている行、検出表記が空の行あたり。100件で打ち切っているのは、それ以上出るならファイル自体の作り方が間違っているからです。

アップロードの上限は5MBです。辞書としては十分な量で、5,000行程度なら問題なく通ります。

CSVで実際に踏んだ落とし穴

ここは開発中に実測して直した話なので、書いておきます。CSVを扱うシステム全般で起きうる問題です。

PHPの fgetcsv / fputcsv には「エスケープ文字」という引数があって、既定値がバックスラッシュ（\）になっています。RFC 4180 のCSVにはこの概念がありません。

何が起きるかというと、セルの末尾がバックスラッシュで終わっているとき、その行と次の行が黙って連結されます。エラーも警告も出ません。100行のCSVを取り込んだら99行になっていて、しかもどこが消えたか分からない。

日本語の辞書でバックスラッシュが末尾に来ることは滅多にないのですが、正規表現の一致方法を使うエントリでは普通に起こります。\d+\ のようなパターンを書いた瞬間に踏む。

対処は、読み書きのすべての箇所でエスケープ文字を無効化して、RFC 4180 準拠にすることでした。地味な修正ですが、これをやっていないCSV機能は静かにデータを失います。

もう一点、CSVインジェクションの対策も入れています。セルの先頭が = や + で始まっていると、エクスポートしたCSVをExcelで開いたときに数式として実行される問題です。辞書に外部から取り込んだ語が入る以上、エクスポート時にこれを無害化しないと、開いた人の環境で何が起きるか分かりません。無害化と復元が対称になるように、シングルクォートを重ねる可逆な規則にしてあります。

辞書を消すときの安全弁

辞書セットを削除しようとすると、それを参照しているルールがあるかどうかをチェックします。参照中なら警告が出る。

ルールと辞書は分けて持っている設計です。ルールが「何を検出するか（判定ロジックと挙動）」、辞書が「検出に使う語彙」。ルールは参照する辞書を指定する形で、プロファイルが束ねるのはルールだけになっています。

この構造だと、辞書を差し替えるだけでルール設定を触らずに済みます。クライアントAの案件が終わって辞書を入れ替える、といった作業が、ルールやプロファイルに影響しません。代わりに、参照関係を壊す削除を防ぐ仕組みが要る、というわけです。

一括での有効化・無効化もできます。「この辞書セットを一時的に全部止める」が1操作で済むので、繁忙期だけ細かい指摘を切る、といった運用も可能です。

正規表現は保存時に検証される

一致方法に正規表現を選べますが、不正なパターンは保存できません。保存の時点でコンパイルを試して、通らなければ拒否します。

実行時にエラーになる仕組みだと、そのルールが動かないことに誰も気づかないまま「この表現は検出されない」状態が続きます。書いた本人は登録したつもりでいる。入り口で弾くほうが安全です。

正規表現を使う場面は、単位表記のゆれ（10Kg 10 kg 10KG）や、規則的な型番、日付フォーマットあたり。それ以外はだいたい部分一致で足ります。

レギュレーションが資産になるということ

CSVで持ち回せると、副次的に変わることがあります。ルールの更新履歴が残せるようになる。

辞書をエクスポートしてGitやドライブに置いておけば、いつ何を追加したかが差分で見えます。「この表現、いつからNGになったんでしたっけ」に答えられる。文書のガイドラインだと、更新履歴は残っていても該当箇所を探すのが大変です。

そして新しいサイトを立ち上げるとき、ゼロから決め直す必要がなくなります。前の案件の辞書を取り込んで、そのクライアント固有のぶんだけ足す。これが「レギュレーションが資産になる」ということだと考えています。

そもそも辞書に何を入れて何を入れないかは、それだけで別の判断が要ります。誤検出を出さない辞書の作り方は表記ゆれの記事に書きました。

編集フロー全体への組み込みはこちらの記事、辞書の管理画面や動作環境は日本語校正マネージャーの製品ページから。