WordPressプラグインの外部送信を洗い出す — 記事本文は出ない、では何が出るのか

WordPressプラグインが外部と通信する理由は、そう多くありません。おおよそ4つに分けられます。

医療・金融・自治体のサイトで選定する側が見ているのは、ほぼ1つ目です。記事の中身そのものが社外のサーバーへ渡るなら、それは委託先の話になり、機能が便利かどうかとは別の判断が要る。用語の自動抽出という機能名は、この点でいちばん疑われやすい部類に入ります。辞書と本文を突き合わせる、と説明されても、その突き合わせがどこで行われるのかは名前からは分かりません。

用語注釈マネージャーの場合、記事本文が外へ出る経路はありません。ただし「一切外部と通信しない」とも書けない。何が出て何が出ないのかを、順に並べます。

用語の検出は、サーバーの中の照合で終わる

自動抽出という語から外部APIを連想する人は多いのですが、ここでやっているのは辞書との文字列照合です。登録した用語名と別名（表記ゆれ）を本文の文字列と突き合わせ、DOMのテキストノードだけを走査して、長い用語を優先して拾う。AIも外部サービスも関わりません。この設計を選んだ理由と、AI下書き機能との切り分けは用語検出をAIに頼らないという設計判断のほうに書きました。

全記事スキャンも、同じ処理を対象記事の数だけサーバー上で回すだけです。何百本を一括でかけても、本文がどこかへ渡ることはない。承認した結果は投稿のメタ情報に記録され、本文そのものには手を触れません（本文が書き換わらない仕組み）。ページを表示するたびの組み立ても同様で、その瞬間にPHPが辞書と本文を照合しています。

管理画面には通信があります。用語辞書の2ペイン画面も、記事編集画面の候補パネルも、JavaScriptがREST APIを叩いて動く作り。ただし宛先は自分のサイトです。ブラウザとサーバーの間を往復しているだけで、サイトの外には出ません。

外へ出る口は、コードの上では3か所

外向きのHTTPリクエストを出しているコードは、プラグイン全体で3ファイルです。ライセンスと更新を扱うもの、バグ報告のもの、AI下書きのもの。場面に分けると4つになります。

場面	出るタイミング	送られるもの
ライセンスの有効化・解除・状態確認	キーを入れたとき、外したとき、1日1回の自動確認	ライセンスキー、サイトのURL、製品スラッグ（有効化時のみプラグイン・WordPress・PHPのバージョンも）
更新の確認と取得	更新チェックのとき、更新を実行したとき	確認は製品スラッグと現在のバージョンだけ。更新版を取りに行く段でライセンスキー
バグ報告の送信	管理画面のフォームで人が送信を押したとき	件名と本文（報告者が書いた文章）、任意の連絡先、サイトのURL、ライセンスキー、チェックを外さなければ環境情報
AI下書きの生成（任意）	「AI で説明案を作成」を押したとき	用語名と、説明文の作り方を指示する文だけ

利用状況の送信、いわゆるテレメトリの行はありません。どの記事が何回読まれたかも、どの用語が何件登録されているかも、外へは出ていきません。

記事の本文も、このどれにも乗りません。バグ報告の行にある「本文」は投稿本文ではなく、報告者が入力欄に書いた文章のこと。環境情報のほうは、WordPressとPHPのバージョン、テーマ名、有効なプラグインの一覧（スラッグとバージョン）、ロケール、マルチサイトかどうかです。同送するかはフォームのチェックボックスで外せます。この既定値をどちらへ倒すかは、いまだに気持ちが片付いていません。報告を受ける側は環境情報があるほど原因に早く辿り着けますが、送る側から見れば有効プラグインの一覧は社内の構成情報そのもの。既定はオンのまま、外す操作をチェックひとつに置くところで折り合いをつけています。

AI下書きは注意して読んでください。押したときに渡されるのは用語名と、短い説明あるいは詳しい説明を作らせる指示文だけです。記事本文はプロンプトに入りません。宛先は経路で変わります。WordPressコアのAI機能を使う場合、リクエストを出すのはコア側で、届く先は「設定 > コネクタ」で自分が選んだAI事業者。プラグイン自身が外へ投げるのは、開発者向けに定数でキーを設定したときのフォールバック経路のほうで、こちらの既定の宛先はこちらのAPIです。どちらの経路も、コネクタも定数も無い環境ではボタン自体が現れず、他の機能はそのまま動きます。生成された文章は入力欄に流し込まれるだけで、自動保存もされない。

表示側にも外部は挟まらない

フロントに読み込まれるCSSとJavaScriptは、プラグインのフォルダにあるファイルを自分のサイトのURLで読ませています。CDNもWebフォントの配信元も挟んでいません。外向きの通信が絞られたネットワークに置いても、注釈の見た目が崩れる心配はない。注釈が1件も無いページではJavaScript自体が読み込まれません。

構造化データページの内容を、検索エンジンなどの機械が読み取りやすい決まった形式で書いた情報。schema.orgの語彙を使い、JSON-LDで埋め込むのが一般的。詳しく見るも同じです。用語の意味づけを表すJSON-LDは自サイトの <head> に出力されるだけで、どこかへ送信しているわけではありません。ここは検索結果の見た目を変えるものではないので、期待の線引きは構造化データを付けても、検索結果の見た目は変わらないのほうを見てください。

「一切通信しない」とは書けない

そのうえで、線を引いておきます。ライセンスの認証と更新の確認は、外部と通信します。

有料プラグインで、ライセンスが1サイト単位で、更新版を管理画面から受け取れる。この3つを成り立たせている以上、この経路は消せません。有効化と解除、それに状態の確認では、ライセンスキーとサイトのURLが出ていきます。しかもこの状態確認は人が押したときだけでなく、WP-Cronで1日1回、自動でも走ります。更新があるかを見に行くほうは製品スラッグと現在のバージョンだけですが、更新版を実際に取りに行く段ではキーを添える。ここを伏せたまま「外部送信なし」と書くのは、選定担当をだますのと同じです。

裏返すと、キーをまだ入れていない状態ではこの経路も動きません。評価用に入れて触っているあいだは、外向きの通信そのものが起きない状態から始められます。

だから閉じたネットワークに置くなら、この宛先だけは通す設計が要ります。到達できないと認証が完了せず、更新の通知も届かない。注釈の表示と用語の検出はそれでも動きますが、機能の一部が止まる前提での運用になります。

稟議に貼れる形にして、自分の環境で裏を取る

選定シートの項目に落とすと、こうなります。

とはいえ、この一覧はこちらの申告にすぎません。裏を取る手はあります。WordPressの外向きHTTPリクエストはすべてコアのHTTP APIを通るので、それを記録するプラグインを一つ入れ、記事を保存し、全記事スキャンを流し、フロントで注釈の付いたページを開く。そこで記録に残るのがライセンスまわりの往復だけで、記事の中身がどこにも乗っていなければ、手元の環境で裏が取れたことになります。ドキュメントを信じてもらうより、こちらのほうが早い。

導入の可否を判断する側にとって、機能一覧より先に要るのはこの手の情報のはずです。用語辞書や注釈の仕様は用語注釈マネージャーの製品ページにまとめてあります。