「校正ならAIでいいのでは」という話に、正面から答えておきます。結論から言うと、AIを主役にすると校正は仕組みになりません。
理由は精度ではありません。同じ原稿を二度投げると、違う指摘が返ってくるからです。1回目で「お問合せ」を拾って、2回目では拾わない。編集部のルールとして「これは必ず直す」と決めたものが、実行のたびに出たり出なかったりする状態では、ライターは「今日は指摘されなかったからOK」と受け取ります。
決めたことを毎回同じように適用するのは、辞書と正規表現の仕事です。AIには別の仕事があります。
AIが向いているのは「登録していないもの」
ルールベースの弱点は、はっきりしています。登録していないものは絶対に見つからない。
辞書に「お問合せ」を入れていれば拾いますが、「お問い合せ」（「い」が1つ足りない）を入れ忘れていたら通ります。誤変換もそうで、「以外」と「意外」、「保証」と「保障」のような、文脈を見ないと判断できないものは照合方式では扱えません。
ここがAIの守備範囲です。登録していない誤字、文脈依存の誤変換、読みにくい言い回し。ルールで網を張ったあとに残った穴を、最後に一度見る。
日本語校正マネージャーのAI最終チェックは、この位置づけで作ってあります。主機能はあくまでルールベースの校正で、AIは任意の追加機能です。AIを設定しなくても、8種類のチェックも公開前ゲートもダッシュボードも全部動きます。
動かすための条件は3つある
期待値は先に下げておきたい。この機能を使うには、次の3つが揃っている必要があります。
1. WordPress 7.0 以上
WordPress本体が7.0で同梱するAIクライアントを使っています。6.x では表示されません（プラグイン本体の動作要件は6.6以上のままで、AI機能だけが7.0以上）。
2. AIプロバイダをサイト側で用意する
ここが誤解されやすいところです。WordPress本体はAIクライアントだけを同梱していて、プロバイダの実装は入っていません。 素の7.0を入れただけでは、AIは使えない状態です。
利用したいAIサービスに対応したプロバイダプラグイン（WordPress.org の「AI Provider for OpenAI」「AI Provider for Anthropic」など）を入れて有効化します。このプラグインは特定のプロバイダに依存しない作りなので、どれを使うかはサイト側の判断です。
3. APIキーを渡す
キーの渡し方は3つ。管理画面の 設定 > コネクター から入力するか、wp-config.php に定数で定義するか、サーバーの環境変数に置くか。定数名はプロバイダごとに {プロバイダ名}_API_KEY の形式です（OpenAIなら OPENAI_API_KEY）。
キーはこのプラグインが持ちません。 いわゆるBYOK（Bring Your Own Key）で、課金は各AIサービスとの契約になります。独自のAPIキー管理も、自社プロキシも用意していません。
管理画面のAI校正ページに、5項目の判定が出ます。WordPressのバージョン / サイトのAI利用設定 / AIプロバイダと認証情報 / このプラグインの設定 / あなたの権限。全部○になって初めて使える状態です。
余談ですが、可用性の判定にはひと手間かかりました。wp_supports_ai() だけを見ると、プロバイダが1つも入っていない環境でも true が返ることがある。テキスト生成が実際に使えるかまで確認しないと、押しても何も起きないボタンを表示することになります。
既定はオフ。同意も要る
有効にするには、2つのスイッチを両方オンにする必要があります。
- AI最終チェックを有効にする
- 本文をAIへ送信することへの同意
どちらも既定はオフです。 実行には jpl_use_ai という権限も要り、これは既定で管理者にしか付いていません。編集者や投稿者に使わせたい場合は、権限を付与します。
厳しめにしてあるのは、この機能が記事の本文を外部へ送るからです。送るのは対象の本文・タイトル・抜粋で、上限は8,000文字。超えた分は送りません。
公開前の原稿を外に出せない案件は普通にあります。デフォルトでオンになっていて、気づかないうちに送信されていた、という状態は避けたかった。だから2段階の同意にしてあります。
実行は手動だけ
AI最終チェックは、押したときだけ動きます。
編集中の自動チェック（デバウンスで走るやつ）からは呼ばれません。保存時にも走りません。校正サイドバーの下部にあるパネルを開いて、「AI最終チェックを実行」を押したときだけ。
結果は編集画面を開いている間は保持されます。パネルを畳んでも、サイドバーを閉じても消えない。「再実行」を押すまでAIは呼ばれないので、うっかりパネルを開き直して二重に課金される、ということがありません。従量課金の機能で自動実行を混ぜると、月末に請求を見て驚くことになるので。
下書きでも公開済みの記事でも実行できます。リライト中の記事に使うことも想定しています。
AIに本文を書き換えさせない
ここが設計のいちばん重要なところです。
AIには、書き換えたあとの本文を返させません。 返させるのは指摘だけ。1件の指摘は「原文からの引用」「置換案」「理由」の3つで構成されます。
AIに「直した全文を出して」と頼むと、指摘していない箇所まで静かに変わります。段落が消える、言い回しが整えられる、事実が微妙にずれる。差分を人が突き合わせない限り気づけません。それを編集フローに入れるのは無理があります。
だから返ってくるのは指摘だけで、本文への適用は既存のワンクリック修正と同じ経路を通ります。人がボタンを押した箇所だけが変わる。
返ってきた指摘をサーバー側で検証する
指摘だけ返させても、それをそのまま信じるわけにはいきません。開発していて分かったのは、AIが引用をわりと平気で微妙に間違えることでした。原文にない文字を足す。前後を勝手に省略する。
そこで、返ってきた指摘はサーバー側の検証ゲートを通します。
- 引用が原文と完全一致するか — 1文字でも違えば破棄
- その引用が原文の中で一意か — 複数箇所にあると、どこを直すか特定できないので破棄
- 置換案の長さが妥当か — 極端に長い、あるいは短すぎるものは破棄
- マークアップが混ざっていないか — HTMLタグを含む置換案は破棄
通らなかった指摘は捨てます。表示もしません。厳しめですが、位置を特定できない修正候補にボタンを出すほうが危ない。
修正ボタンが出たり出なかったりする理由
検証を通っても、全部にボタンが出るわけではありません。
ボタンが出るのは、誤字脱字（typo）と判定され、かつ置換案が安全に適用できると検証できた指摘だけです。
AIが見る観点は3つあります。誤字脱字 / 読みやすさ / 表記の一貫性。このうち後ろの2つは「指摘のみ」になります。読みやすさの改善は置き換え先が一意に決まらないし、表記の一貫性は本来ルールベースで扱うべき領域なので。タイトル・抜粋への指摘も表示だけです。
同じ本文でも、実行ごとにAIの判定は変わります。1回目でボタンが出た指摘に、2回目は出ないこともある。置換案はAIの提案なので、内容を確認してから適用してくださいというのが正直なところです。
公開は止めない。事実確認もしない
2つ、明確に線を引いてあります。
AIの指摘で公開はブロックされません。 AIが返したものはすべて「提案」扱いで、公開前ゲートの判定には一切関与しません。実行のたびに結果が変わるものを公開の可否に使うと、同じ記事が出せたり出せなかったりする。それは編集フローとして成立しません。
ファクトチェックはしません。 書かれている内容が事実かどうかの検証は対象外です。誤字と読みやすさと表記の一貫性、この3つだけを見ます。
使いどころは限定していい
まとめると、位置づけはこうなります。
- 表記ゆれ・冗長表現・全角半角・禁止語 → ルールで確実に拾う（毎回同じ結果になる）
- 登録していない誤字、文脈依存の誤変換 → 公開前に一度だけAIに見せる
- 構成・論理・事実 → 人が見る
AIに全部やらせようとすると、一貫性が失われます。ルールに全部やらせようとすると、登録漏れが通ります。役割を分けたほうが、どちらも機能する。
AI無しで動く部分がどこまでか、編集フロー全体でどう組むかはこちらの記事にまとめました。AI最終チェックの設定手順や動作要件は日本語校正マネージャーの製品ページから確認できます。
