薬機法・景表法のNG表現を、編集者の記憶に頼らず止める

美容・医療・健康食品・金融・不動産。この分野でオウンドメディアを回している編集部には、共通の緊張があります。書いてはいけない表現が、記事の中に一つでも残っていたら困るという緊張です。

「シミが消える」「必ず痩せる」「業界No.1」「絶対に儲かる」。この手の表現は、ライターが悪意で書くわけではありません。効果を伝えようとして踏み込む。あるいは、クライアントから渡された資料にその表現が入っていて、そのまま持ってきてしまう。

そして、チェックしているのはたいてい編集者ひとりの記憶です。

記憶に依存したチェックが崩れる場所

法務レビューを外部に頼んでいる編集部もありますが、記事1本ごとに回すのは現実的ではありません。多くの現場では、編集者が「これは危ない」と気づいた箇所を止めています。

この方式は、うまくいっているうちは安く済みます。崩れるのは決まった場所です。

どれも「気をつける」では防げません。気をつける主体が不在だったり、知らなかったりするケースだからです。

NG表現は辞書に向いている

禁止語のチェックは、機械にいちばん渡しやすい種類の指摘です。

判断材料が文字列の中で完結しているから。「シミが消える」という並びを見つけたら止める。前後の文脈も、記事のテーマも要りません。むしろ文脈で判断しないほうがいい。「〜と言われています」を付けたら通る、といった抜け道を機械が学習してしまうと、チェックの意味がなくなります。

日本語校正マネージャーでは、禁止語・注意語を辞書として登録します。エントリに持たせられるのは次のあたりです。

項目	例
検出表記	シミが消える
一致方法	部分一致
補足（note）	薬機法上、化粧品で「消える」は不可。「メラニンの生成を抑え、シミ・そばかすを防ぐ」の範囲で

補足欄が実務的にいちばん効きます。 「使えません」とだけ出しても、ライターはどう書き直せばいいか分かりません。理由と言い換えの方針を添えると、その場で直せます。指摘のたびに編集者へ質問が飛んでくる状態を減らせるのは、この欄のおかげです。

辞書は用途で分けられます。禁止語・注意語・固有名詞・専門用語・クライアント別・ジャンル別など。「絶対にNG」と「使うなら注意」を別の辞書にして、前者はError、後者はWarningにする、という組み方ができます。

辞書は同梱していない

ここは先に書いておきます。薬機法・景表法のNG表現辞書は、この製品に同梱していません。

同梱しているのはIT系と一般の表記ゆれ、冗長表現、重言だけです。法務系の辞書を最初から入れることは検討しましたが、やめました。

理由は二つあります。ひとつは、業種と商材によってNGの範囲が違うこと。化粧品と医薬部外品と健康食品で、使える表現が違います。医療広告ガイドラインはまた別の体系です。汎用の辞書を入れると、自分の商材には関係ない指摘が大量に出ることになる。

もうひとつは、同梱した辞書が「これを守れば安全」と読まれること。作っている側から見て怖いのはここです。法律の解釈は更新されるし、行政の運用も変わる。プラグインに入っている語のリストが法令遵守の保証になることはありません。

なので、辞書は各社で作ることになります。作るときの元ネタは、自社の法務レビューで過去に指摘された表現、業界団体のガイドライン、所管官庁の公表資料。実務的には、過去に差し戻した表現をそのまま登録していくのがいちばん早い。同じ指摘を二度しなくて済みます。

CSVでまとめて取り込めるので、すでにスプレッドシートでNGリストを持っているなら、それをそのまま入れられます。取り込みは件数とエラー行を確認してから確定する2段階になっていて、辞書のCSV運用は別記事に書きました。

法的な判断はしていない

もう一点、明確にしておきます。この製品は登録された語を拾うだけです。

やっているのは、決めたことが守られているかの照合だけ。法的な判断は人がやることで、機械は「決めたはずのことがすり抜けていないか」を見る係です。

この線引きを曖昧にすると、辞書に引っかからなかった記事を「チェック済み」とみなす運用が生まれます。それがいちばん危ない。

緩められないルールにする

禁止語チェックには、他のルールと違う扱いが必要です。ライターの判断で無効化されては困る。

そのために強制ルールという属性があります。これはルール側に持たせる設定で、有効にすると、ライター単位でもカテゴリ単位でも投稿単位でも無効化できなくなります。

仕組みとしてはこうです。ルールの設定は7つのレイヤー（サイト共通・権限・投稿タイプ・タグ・カテゴリ・ライター・投稿単位）を順に重ねて決まりますが、強制ルールは合成の最後に適用されます。上のレイヤーで何を書いても、最後に上書きされて元に戻る。重要度もパラメータもルール定義の値で固定されます。

会社名の正式表記、法務上使えない表現、PR表記の注記。この3つは強制ルールにしておく想定です。レイヤーの仕組み全体はルール合成の記事に書きました。

本当に止める

警告を出すだけでは足りない場合があります。ここが禁止語チェックの本題です。

日本語校正マネージャーは、条件を満たすと公開そのものを止められます。条件は一つに絞ってあります。

そのプロファイルで公開ブロックが有効で、かつError指摘が1件以上残っている

Warning がいくつ残っていても止まりません。止めたいルールをErrorに上げて、プロファイルの公開ブロックをオンにする。この2ステップを踏んだものだけが止まります。

止めるのはサーバ側です。ブロックエディタに出る警告は事前のお知らせで、実際の強制は保存リクエストを検証して行います。REST以外の経路（プログラムからの投稿、外部連携ツールなど）でも検証が走り、その場合は下書きへ差し戻して管理画面に通知を出します。

UIのガードだけにしなかったのは、法務リスクのある表現を止める用途では、経路を変えれば抜けられる仕組みに意味がないからです。

例外は権限で扱い、記録する

とはいえ、現場には「今日中に出さないといけない」があります。

強制公開は jpl_force_publish という権限で扱います。既定では管理者と編集者に付いていて、この権限があればErrorが残っていても公開できる。ライター（投稿者・寄稿者）には付いていません。

重要なのは、バイパスした事実と、誰がやったかがログに残ることです。急いで出したこと自体を責める必要はありません。ただ、記録が残らないと「Errorは止まらない」という運用が定着してしまう。あとからダッシュボードで、今月何件のブロックが発生して、そのうち何件が強制公開されたかを確認できます。

権限を絞りたい場合は、jpl_force_publish を編集者から外して管理者だけにする、といった調整もできます。権限管理プラグインとの併用を想定した作りです。

導入の順番だけ間違えない

最後に運用の注意を一つ。いきなり公開ブロックをオンにしないほうがいいです。

同梱の既定プロファイルは、すべてWarningで公開ブロックなしにしてあります。まず辞書を入れて、1〜2週間ぶんの指摘を眺める。誤検出が出ていないことを確認して、それから止めるべき語だけをErrorに上げる。

初日から止める設定にすると、想定外の誤検出で公開が詰まり、その週のうちに無効化されます。止める仕組みは、信頼されていないと使われません。

機能の詳細と動作環境は日本語校正マネージャーの製品ページに、編集フロー全体への組み込み方はこちらの記事にまとめてあります。