WordPressの編集フローに校正を組み込む：書いている場所でルールを出し、公開前で止める

日本語校正のプラグインを開発していて、最初に決めたのは検出精度の話ではありませんでした。ルールを一つにしない、という設計方針です。

理由は単純で、メディアの現場では「新人ライターとベテランに同じ強さの指摘を出す」ことが役に立たないからです。ベテランに一文80文字の警告を出し続けても無視されるだけだし、新人に重大な指摘だけ見せても育たない。サイトに1つのルールを持つ設計だと、この差を表現できません。

この記事では、WordPressの編集フローに校正を組み込むときに何をどこへ置くのか、そしてこの製品（日本語校正マネージャー）がそれをどう実装しているかを一通り書きます。

置き場所に求められる三つの条件

校正を仕組みにするなら、置き場所に求められる条件は三つ。

3つ目が抜けている仕組みは、結局「見なくてもいい警告」になります。逆に3つ目だけ強すぎると、導入初日に全記事が公開できなくなって、その週のうちに外される。

書いている画面に出す

WordPressの場合、置き場所はブロックエディタ（Gutenberg）のサイドバーになります。

編集中に校正を実行すると、指摘が一覧で出ます。重要度別の件数、該当箇所へのジャンプ、修正候補。自動チェックをオンにしておけば、入力が止まってから1.5〜3秒ほどのデバウンスを挟んで走ります。毎打鍵でチェックすると重いので、間隔を空けて差分を見る作りです。

検出しているのは8種類。

種別	何を見るか
表記ゆれ	辞書に登録した表記（Wordpress → WordPress、お問合せ → お問い合わせ）
禁止語・注意語	使ってはいけない語、注意が要る語。理由を添えて出せる
冗長表現	「することができます」「まず最初に」など
全角・半角	１００％、全角スペース、括弧内の余白
句読点	句点の抜け、読点の数、、。 と ，． の混在
文体	です・ます調とだ・である調の混在、同じ語尾の連続
長文	1文の文字数、1文内の読点の数、同じ接続詞の連続
SEO項目	タイトル・スラッグ・抜粋、およびSEOプラグインのSEOタイトル・メタディスクリプション

修正候補があるものは、ボタン一つで置き換えられます。ここで一つ制約を書いておくと、ワンクリック修正が効くのは本文（RichText）だけです。カスタムHTMLブロックや対応外のブロックは指摘だけ。タイトルやメタディスクリプションへの指摘も、場所を示すところまでで、ボタンは出ません。

本文の生HTMLを文字列置換すればタイトル以外は全部直せるのですが、それをやるとブロック構造が壊れます。壊れ方が編集者から見えないのが最悪で、後から気づいたときには履歴も追えない。だから置換の対象をテキストノードに限りました。直せる範囲は狭くなりましたが、原稿が壊れるより良いという判断です。

相手によって強さを変える

ここがこの製品の中心です。

ルールは1枚の設定ではなく、7つのレイヤーの合成結果として決まります。弱い順に、サイト共通・ユーザー権限・投稿タイプ・タグ・カテゴリ・ライター・投稿単位。

上のレイヤーは、下の結果を丸ごと置き換えるのではなく、そのレイヤーが言及したルールの設定だけを上書きします。上書きできるのは3つ。有効か無効か、重要度、そしてルール固有のパラメータ（一文の上限文字数など）。

たとえばこう組めます。

Aさんがニュースカテゴリの記事を書くと、この3つが順に重なった状態が適用されます。どのルールがどのレイヤー由来で効いているかは、割り当て画面のプレビューで確認できます。合成の結果を人が説明できないと運用に乗らないので、この画面は最初から仕様に入れました。

例外として、強制ルールという属性があります。これはレイヤーではなくルール側の設定で、合成の最後に適用されて、どのレイヤーからも無効化できません。会社名の正式表記、法務上使えない表現、PR表記の注記といった「ライターの裁量で外させたくないもの」に使います。

ルール別の設計の詳しいところはレイヤー合成の記事で書きました。

公開前で止める

止める条件は一本化してあります。そのプロファイルで公開ブロックが有効で、かつError指摘が1件以上残っているとき。それ以外では止まりません。Warning がいくつ残っていても公開できます。

止めるのはサーバ側です。ブロックエディタの警告表示はあくまで事前のお知らせで、強制はREST経由の保存時に行います。REST以外の経路（プログラムからの投稿など）でも wp_insert_post_data の側で検証して、下書きへ差し戻します。UIのガードだけにすると、経路を変えれば抜けられてしまうので。

抜け道は用意してあります。jpl_force_publish という権限を持っていれば、Errorが残っていても公開できる。既定では管理者と編集者に付いています。ただしバイパスした事実と、誰がやったかはログに残ります。急ぎで出したこと自体は責めなくていい。ただ、記録が残らないと運用が崩れます。

導入直後の話も書いておきます。同梱の既定プロファイル「標準メディア文体」は、すべてWarningで、公開ブロックなしです。有効化した瞬間に記事が公開できなくなる、ということは起きません。まず指摘を眺めて、止めるべきルールが決まってからErrorに上げる。この順番でないと、初日で外されます。

何が起きているかを見る

指摘は記録されます。記録するのは手動チェック・保存時・公開前チェックのときだけで、編集中のデバウンス自動チェックは記録しません（記録が指摘の山になって集計が意味を持たなくなるため）。

ダッシュボードで見られるのは、当月の指摘数と重要度別の内訳、ライター別・ルール別・投稿タイプ別・カテゴリ別の件数、よく出る表記ゆれと禁止語、そして公開前ブロックの件数（強制公開でバイパスされた分を含む）。

これが効くのは、ルールを見直すときです。特定のルールばかり大量に出ているなら、それはライターの問題ではなくルール設定が現場と合っていないサインかもしれない。逆に、ある指摘が特定の書き手に集中しているなら、そこは個別に話したほうが早い。

ログは本文の全文を保存しません。残すのは対象テキストの断片（100文字以内）まで。保持期間は既定90日で、日次のcronで自動的に消えます。

できないこと

正直に書いておきます。

動作要件はWordPress 6.6以上・PHP 8.1以上・シングルサイト。既定の対象は投稿と固定ページで、カスタム投稿タイプは設定で追加します。

どこから手を付けるか

導入の順番としては、いきなり全ルールを有効にするより、次のように進めるほうが摩擦が少ないはずです。

2と3を飛ばして4から始めると、たいてい設定だけ立派で誰も使っていない状態になります。

機能の一覧と動作環境は日本語校正マネージャーの製品ページにまとめてあります。