校正と校閲は、同じ作業の丁寧な言い換えではありません。見ている対象が別で、片方は機械に渡せますが、もう片方は渡せない。この区別を曖昧にしたまま校正ツールを選ぶと、入れたあとで「思ったほど編集の手が空かない」という感想になります。
定義から始めます。
校正は表記を見る、校閲は中身を確かめる
校正は、書かれた文字と表記が、決めたとおりになっているかを確認する作業です。 誤字脱字、表記のゆれ、文体の混在、全角と半角、句読点、一文の長さ。突き合わせる相手は辞書や表記ガイドラインで、どれも手元にあります。
校閲は、書かれている内容が事実として正しいか、記事の内と外で矛盾していないかを確認する作業です。 数字の出どころ、社名と商品名、日付、引用の原典、過去記事との食い違い、その表現を自社として出せるかどうか。突き合わせる相手は、記事の外にあります。
校正という語はもともと、印刷の校正刷り（ゲラ）を原稿と突き合わせる工程を指すとされます。正解の側が手元にあって、そこからのズレを探す。この構図は、辞書を持った校正ツールが今やっていることとほとんど変わりません。
Webメディアでは、二つが一人の頭の中で同時に起きる
出版の現場では、校正と校閲で担当者が分かれていることがあります。Webメディアでそこまで分けている編集部は、そう多くないはずです。編集者が原稿を1回開いて、表記の直しと事実の確認をまとめて片づける。
分業が消えると、区別も消えます。差し戻しのコメント欄には「『お問合せ』は『お問い合わせ』に」と「この数字の出典は？」が並んで書かれ、どちらも同じ「赤入れ」として数えられる。工数の内訳は誰も持っていません。
ツールの検討がこの状態から始まると、期待の掛け方がずれます。赤入れが半分になるつもりで入れて、実務で減るのは片方だけ。
手元で照合できるものと、確かめに行くもの
二つを分ける線は、突き合わせる相手がどこにあるかです。手元の辞書と照合すれば終わるものと、外へ照会しないと決まらないもの。
機械に渡せるのは照合の側だけです。日本語校正マネージャーの判定も照合で組んであります。形態素解析は使っておらず、正規表現と辞書と文分割のヒューリスティクスで見ている。照会が要る指摘に届かないのは、判定が甘いからではありません。照らす相手を製品の中に持っていないからです。
一文で見たほうが早いはずです。
2024年の調査によると、利用率は63%でした。
校正側がこの文について見るのは、% が全角か半角か、数字の表記が記事の中で揃っているか、文が長すぎないか、読点の数、文末が本文の基調から外れていないか。63%という値が正しいのか、その調査が存在するのか、2024年が最新なのかは、一文字も見ていません。見ていないというより、確かめに行く先が製品の中にない。
校閲の一部は、語のリストに落ちる
とはいえ、校閲だと思われている項目の一部は、校正側へ移せます。
「業界No.1」「絶対に儲かる」「シミが消える」。この種の表現は、出していいかどうかという意味では校閲の担当ですが、語として固定できるので、辞書に登録して機械に拾わせられます。禁止語の辞書をどう作るかは別の記事に書きました。
移せるのは「その語を使ったか」までです。「業界No.1」に根拠となる調査があるか、いつ時点の話か、調査の範囲が記事に書いてあるか。この確認は残ります。禁止語の辞書を厚くして消えるのは検出漏れであって、確認そのものではない。
線を引いておくと、日本語校正マネージャーがやっているのは登録された語の照合だけで、その表現が法令に違反するかどうかは判定しません。
AIを足しても、伸びるのは校正の側
「AIに読ませれば校閲までできるのでは」という話は当然出ます。
この製品にもAI最終チェックという任意機能があり、WordPress 7.0以上でサイト側にAIプロバイダを用意した環境でだけ使えます。ただし観点は3つに絞ってあります。誤字脱字、読みやすさ、表記の一貫性。ファクトチェックはしません。
観点を3つに決めるとき、事実確認は候補から落としました。開発していて引っかかったのは、返ってきた指摘をこちらで検証できるかどうかです。この機能はAIに本文の書き換え版を返させず、返るのは引用・置換案・理由の3点だけ。引用が原文と1文字でも違えばサーバ側で破棄します。つまり検証にかけられるのは文字列の一致まで。「この数字は誤りです」と返ってきても、その当否を確かめる手段がこちらに無いので、通せば「AIが見た」という感触だけが残ります。BYOKBring Your Own Key。AIの利用料を、プラグインの提供者経由ではなく、自分で契約したAPIキーで直接支払う方式。や権限まわりを含めた設計はAI最終チェックの記事にまとめました。
AIの指摘で公開が止まることもありません。
「校閲は減らない」を先に決めておく
導入の見積もりは、校正側だけに立てるのが安全です。表記の直しは編集者の手から外れます。出典の確認、整合の確認、法務まわりの判断は1件も減りません。
公開前ゲートにも同じ線が引かれています。日本語校正マネージャーはError指摘が残った記事の公開をサーバ側で止められますが、根拠になるのはルールが検出した指摘だけ。「出典の確認がまだ終わっていない」という状態はシステムから見えないので、止めようがない。止められる範囲を、公開の条件そのものと読み替えないほうがいいと思います。
もう一つ、指摘ゼロの原稿はきれいに見えます。きれいに見える原稿ほど、事実の確認は飛ばされやすい。校正を機械に渡すなら、校閲の項目は人が持つリストとして別に書き出しておかないと、機械が拾わない項目ごと運用から抜け落ちます。
つまり、この手の導入で変わるのはレビューの総量ではなく、レビューの議題のほうです。差し戻しの理由が表記から事実と構成へ寄る。空いた時間の行き先を先に決めていないと、「以前より楽になった気がしない」で終わります。
判断の目安もひとつ。ひとりで書いてひとりで公開しているなら、校正のルールはすでに頭の中で統一されているので、効果は薄いはずです。書き手が複数いて、同じ表記の指摘が毎回同じところで出ているなら、そこは渡す価値があります。機械側をワークフローのどこへ挟むかは編集フローに校正を組み込む記事にあります。
チェックの8種別が何を見て、何を見ないかは、日本語校正マネージャーの製品ページ側に置いてあります。
