textlint は、日本語の文章に機械的なルールをかける手段として妥当な候補です。ルールの表現力は十分にあり、辞書も揃っている。技術側から名前が挙がるのは自然なことだと思います。
それでも編集部に入らないことがあります。決め手になるのはルールの出来ではなく、そのツールが走る場所に、原稿があるかどうか。CIやエディタの拡張として動かす形が前提なので、書いている本人の画面とは限りません。
この記事は、textlint を勧められたものの、ライターがコマンドラインを開かない編集部向けです。導入するかどうかを、ルールの比較ではなく「誰がいつ走らせるのか」で決めます。
詰まるのは、原稿がどこに置いてあるか
コマンドラインで動くツールが受け取るのはファイルです。リポジトリにMarkdownがあり、コミットのたびにCIが読む。この形なら、走らせる人もタイミングも決まっています。
WordPressで運用しているメディアには、そのファイルがありません。ライターは管理画面のエディタで書き、保存した内容はデータベースに入る。Gitに乗らないので、CIが見に行く先が無い。
ここが最初の分岐点です。ルールを何本書けるかを比べる前に、原稿がどこにあるかを見る。技術ブログをMarkdownで書いてプルリクエストを出しているような運用なら、そのまま噛み合います。管理画面で書いているなら、噛み合う場所のほうが無い。
回避策は3つくらいで、どれも同じところで折れる
原稿がデータベースにあるまま外部のツールを使おうとすると、取れる形は限られます。
まとめて流す。 記事を書き出して、エンジニアが定期的にチェックを走らせる。指摘は出ます。ただし出るのは書き終えたあとで、受け取るのは書いた本人ではありません。直した結果をWordPressへ戻す手間もついてきます。
全員の手元に環境を作る。 ライター各自のPCに実行環境と設定を入れる。動きはします。外注ライターが入れ替わるたびに同じ作業が発生し、設定を変えるたびに配り直しになる。書くこと以外の負担が増えていきます。
貼って走らせる画面を用意する。 原稿をコピーして別画面に貼る。手順としてはいちばん軽い。ただ、貼るかどうかは書き手の裁量に残ります。締切の近い週に飛ばされても、誰も気づけない。
3つとも、走らせる人と書く人が別になるか、書く人の手順が増えるかのどちらかです。ツールを差し替えても、この二択の外には出ません。
移せるもの、書き直しが要るもの、諦めるもの
走らせる場所をWordPressの編集画面へ移すと決めた場合、いま持っているルール資産はどうなるか。日本語校正マネージャーに置き換える前提で並べると、こうなります。
| いま持っているもの | 移した先でどうなるか |
|---|---|
| 表記ゆれ・禁止語の語彙 | 移せる。CSVかJSONに直す。軸になるのは検出表記・推奨表記・一致方法の3列 |
| 一文の長さや読点の数といった閾値 | 移せる。既定は1文80文字・読点4個まで・同じ語尾3文まで・同じ接続詞2回で警告 |
| 品詞や文脈を見て判定するルール | 移せない。形態素解析をしていないので、辞書と正規表現と文分割で決まる範囲まで |
| ルールをコードで書く自由度 | 無い。書けるのは正規表現まで（保存時にコンパイルを検証し、通らないものは拒否する） |
作業として重いのは1行目です。語彙そのものは持ち運べますが、形式は自分で整えることになる。とくに一致方法の列は、日本語なら部分一致が基本とはいえ、固有名詞や短い語では完全一致へ倒す判断が要ります。1件ずつ決める必要があるので、ここが移行作業の本体になります。
同梱の辞書は、この移行を一度通した結果
この作業、同梱の辞書を用意したときに手元で一度やっています。出どころはOSSの日本語校正辞書（prh や textlint 系。いずれもMIT）で、定番項目を抜き出して翻案したものです。ライセンスと出典をドキュメントに残すところまでが1セット。MITのものを翻案して配るなら、そこは省けません。持ち出す側の事情も同じで、社外のサイトへ渡す辞書に他所の語彙が混ざるなら、出典の確認は最初に済ませるほうが安全です。
残ったのは、4種の辞書を合わせて73件。ほかに空の許可語辞書が1冊。取り込めた量ではなく、1件ずつ当てて落としたあとの数です。落とす基準そのものは表記ゆれ辞書の作り方にまとめたので繰り返しませんが、移行の見積もりとしては1つ言えます。件数の多い辞書ほど、そのまま持ってくると確認に時間がかかる。 5,000語を引き継ぐなら、移す作業より選び直す作業のほうが長くなります。
編集画面で走ると、指摘の宛先が変わる
置き場所を移して変わるのは、検出の賢さではなく宛先です。
ブロックエディタのサイドバーに出るので、受け取るのは書いている本人になります。自動チェックをオンにしておけば、入力の手が止まって2秒ほどで一覧が入れ替わる。ボタン1つで直せるのは本文の表記ゆれ・冗長表現・全角半角までで、長文や文体は位置を示すだけです。直し方が1通りに決まらない指摘には、修正ボタンを出していません。
ルールの単位も変わります。設定を1本のファイルで持つと、サイト全体が同じ強さになる。WordPress側に置くと、カテゴリや書き手ごとに強さを変えられます。新人には一文の上限を下げ、ベテランには長文の指摘を出さない、といった重ね方ができる（ルールの重ね合わせ）。
止める側も変わります。Error指摘が残っている記事の公開を、サーバ側で止められる。ただし同梱の既定プロファイルは公開ブロックなしなので、有効化した瞬間に記事が出せなくなることはありません。何をどの順番で置くかは編集フローへの組み込み方にまとめてあります。
全部を移す必要はない
移行というと片方を捨てる話に聞こえますが、そうしなくても構いません。リポジトリで書いているドキュメント、READMEや開発ブログのMarkdownは既存のツールに任せ、WordPressで書く記事だけ編集画面側で見る。書く場所が違うものを、1つのツールへ無理に寄せる理由はないはずです。
ただし辞書を両方に持つと、更新のたびに二重管理になります。どちらを正にするかだけは先に決めておくと楽です。
そのうえで、移す前に確認しておく点が3つ。過去記事の一括スキャンは現行バージョンにありません。対象は編集中の記事なので、「今ある記事を全部洗い直したい」には今のところ応えられない。校正UIはブロックエディタだけで、Classic Editorに指摘は出ません（公開前のゲートはサーバ側なので、経路を問わず効きます）。そしてマルチサイトは非対応で、動作要件はWordPress 6.6以上・PHP 8.1以上です。
判断の順番だけ、最後にもう一度。比べるのはルールの表現力ではなく、原稿がどこにあるかと、誰がいつ走らせるか。ここが決まらないまま高機能な側を選ぶと、走らせる人がいないツールが残ります。
編集画面の中で校正を走らせると何が出るのかは、日本語校正マネージャーの製品ページに機能と動作環境をまとめてあります。
