WordPressのコアに、無効化が必要なAI機能はありますか？

自分で設置したWordPressのコアには、初期状態で動作するAI執筆アシスタント、チャットボット、画像生成ツールは含まれていません。エディターに出てくるAIパネルは、ほぼ確実にインストール済みのプラグイン、サーバー会社が注入したプラグイン、またはホスティング管理画面の連携機能によるものです。コアに存在しないものを削除するコードを書く前に、まずプラグイン一覧を確認してください。

Jetpack AI Assistantをオフにするには？

コードを編集するのではなく、Jetpackの設定画面でAI Assistantモジュールを停止してください。Jetpackは個別に切り替えられるモジュール構成になっているため、そのひとつをオフにすればエディターのパネルだけが消え、他の機能はそのまま動きます。Jetpackの他の機能を一切使っていないなら、プラグインごと停止するほうが単純で軽くなります。

remove_actionでプラグインのAI機能を無効化できますか？

できる場合もありますが、壊れやすい方法です。プラグインが登録したフック名・コールバック・優先度を正確に把握している場合にのみ機能し、プラグインの更新でそれらの名前が変われば何の警告もなく機能が復活します。設定項目が用意されているならそれを使い、フック解除はあくまで最終手段として、更新のたびに再確認してください。

robots.txtでAIクローラーをブロックすると、実際に効果はありますか？

自主的に従うクローラーに対してだけ効果があります。OpenAI、Anthropic、Google、Appleを含む主要な事業者は、遵守すると表明しているユーザーエージェント名を公開しており、それらをブロックする価値はあります。ただしrobotsのルールは強制力ではないため、悪質な相手やユーザー操作による取得は無視できてしまいます。強制力があるのはサーバーレベルのブロックです。

AIクローラーのブロックとAI検索のブロックは何が違うのですか？

事業者によっては、学習用と、その場の質問に答えるための取得用で別々のトークンを使っています。学習用トークンをブロックすればコンテンツはモデルの学習に使われなくなりますが、AIの回答には引き続き登場します。一方で検索用やユーザーエージェント用のトークンをブロックすると、本来なら出典として引用・リンクしてくれるAI回答から外れてしまいます。両方ブロックする前に、どちらを取るか決めてください。

llms.txtは実装すべき標準規格ですか？

いいえ。llms.txtはコミュニティによる提案であって批准された標準ではなく、主要なAI事業者でアクセス制御の仕組みとして尊重すると約束したところはありません。ファイルを置くこと自体は無害で手間もかかりませんが、robots.txtの指示やサーバーレベルのブロックの代わりにはなりません。この領域の標準化はまだ進行中です。

WordPressのAI機能を無効化する方法（コアかプラグインか、正直な話）

WordPressで「消したい」と思われているAI機能は、そのほとんどがプラグイン、サーバー会社、あるいはWordPress.com由来のものです。自分で設置したコア本体のものではありません。functions.phpにremove_actionのスニペットを貼り付ける前に、プラグイン一覧を開いて、そのAIパネルを実際に描画しているものを特定してください。コアに存在しない機能を消そうとするのは、すでに調子の悪いサイトで時間を捨てる行為です。

この区別が重要なのは、対処法がまったく別物だからです。プラグインの機能なら設定に切り替えスイッチがあります。サーバー会社が注入した機能は、WordPressの管理画面ではなくホスティングの管理画面にあります。そして「AIを無効化したい」と言うときに多くの人が本当に意味していること、つまりAI企業に自分の記事を学習させないことは、そもそもWordPressの設定ではありません。robotsとサーバー設定の問題です。

どこまでがコアで、どこからが違うのか

自分で設置したWordPressのコアには、初期状態で動作するAI執筆アシスタントも、AIチャットボットも、AI画像生成も含まれていません。ブロックエディターにAIのきらめきアイコンが見えるなら、何かがそれをインストールしています。

AI機能が実際に来ている場所は次のとおりです。

出どころ	よくある機能	オフにする場所
Jetpack	AI Assistantブロックとエディターパネル	Jetpackの設定、モジュールの切り替え
単体のAIプラグイン	文章生成、チャットボット、代替テキスト生成	そのプラグイン自身の設定画面
SEOプラグイン	タイトル・ディスクリプションのAI提案	プラグイン設定、たいていは機能ごと
ページビルダー	ビルダー画面内のAI文章・画像生成	ビルダーの設定またはアカウント画面
マネージドホスティング	mu-pluginや管理画面経由で注入されるAIアシスタント	サーバー会社のコントロールパネル
WordPress.com	ホスティング側のAI執筆ツール	WordPress.comのアカウント設定（サイト側ではない）

WordPressプロジェクト自体にもAI関連の開発は継続的にあり、将来コアに入るかもしれない実験的な機能プラグインが存在します。新しめのバージョンを使っていて、プラグインに紐づけられないAIらしきものが見えた場合は、コアの初期設定だと決めつけてフィルターで消そうとする前に、まずインストール済みプラグイン一覧、次にそのバージョンの変更履歴を確認してください。この慎重さは意図的なものです。この分野のバージョン固有の記述はすぐ古くなり、間違った情報は無意味なファイル編集を招きます。

何が追加しているのかを突き止める

AIパネルが消えるまで、プラグインをまとめて停止していきます。乱暴ですが、推測ではなくはっきりした答えが得られます。

WP-CLIが使えるなら、まず有効なものを一覧表示します。

wp plugin list --status=active --field=name

次に、通常のプラグイン画面には現れない、サーバー会社が注入したコードを確認します。

ls -la wp-content/mu-plugins/

必ず使用するプラグイン（mu-plugins）は自動で読み込まれ、管理画面から停止できません。サーバー会社がここにAIアシスタントを置いている場合、きれいに取り除く方法はコントロールパネル経由だけです。ファイルを削除しても、次のプラットフォーム更新で復活することがよくあります。

正しいオフにし方

そのプラグイン自身の設定を使う。 面白みのない答えですが、これが正解です。特にJetpackは個別に切り替えられるモジュール構成なので、統計・バックアップなど必要な機能を残したままAI Assistantだけをオフにできます。単体のAIプラグインも、たいていは機能ごとに有効・無効のチェックボックスを用意しています。

そのプラグインを他に使っていないなら、プラグインごと停止する。 インストールしたまま「無効」にしてあるAIプラグインは、リクエストのたびにコードを読み込み続けます。停止するほうが速く、安全で、どんなフィルターより確実に軽くなります。

remove_actionによるフック解除は最終手段。 確かに機能しますが、プラグインが登録したフック名・コールバック・優先度を正確に把握している場合に限られ、しかもプラグインがそれらの名前を変えるまでの間だけです。

// Only if you have verified the exact hook, callback and priority.
// Runs late so the plugin has already registered its own hooks.
add_action( 'init', function () {
    remove_action( 'enqueue_block_editor_assets', array( 'Some_Plugin_Class', 'enqueue_ai_panel' ), 10 );
}, 99 );

正直なコストを書いておきます。この方法は無言で壊れます。プラグインの更新でクラス名が変わり、解除処理が一致しなくなり、AIパネルが戻ってきて、それを知らせるエラーはどこにも出ません。この手段を使うなら、何を消したかを記録し、そのプラグインを更新するたびに再確認してください。

同じ注意が、JavaScriptからエディターパネルの登録を解除する方法にも当てはまります。実在する手法ではありますが、他のプラグインの登録内容に文字列の識別子で手を突っ込んでいるだけで、その識別子は公開された約束事ではありません。

フォーラムの投稿で見つけたwp-config.phpの定数でAI機能を止めようとしないでください。 サードパーティ製プラグインのAIをオフにするコアの定数は存在しません。そう主張するスニペットがあっても、その定数を当該プラグインの公式ドキュメントまで辿れないなら、何の効果もありません。

もうひとつの問題：AI学習への利用を止める

これは別の話であり、実際の不安の大半はここにあります。エディターのパネルをオフにしても、誰が記事をクロールするかは何も変わりません。そこを制御するのはrobots.txtと、強制したいならサーバー側の設定です。

WordPressは、ウェブルートに実ファイルがない限り仮想的なrobots.txtを配信します。物理ファイルが存在する場合、WordPressは完全に手を引き、クローラーが受け取るのはそのファイルです。仮想のほうを編集するには、フィルターを使います。

add_filter( 'robots_txt', function ( $output ) {
    $output .= "\nUser-agent: GPTBot\nDisallow: /\n";
    return $output;
}, 10 );

ミスが起きやすいのは、ルールを手作業で組み立てるところです。トークンをひとつ間違えれば何もブロックできず、対象を間違えたDisallow: /は通常の検索からサイトごと消し去ります。robots.txtジェネレーターは、通常の検索向け指示とAIクローラー向けのブロックをまとめて組み立てるので、公開前にファイル全体を目で確認できます。

主要な事業者が公開し、遵守すると表明しているトークンは次のとおりです。

トークン	事業者	対象範囲
GPTBot	OpenAI	モデル学習のためのクロール
ChatGPT-User	OpenAI	ユーザーの操作によって発生する取得
ClaudeBot	Anthropic	クロール
Google-Extended	Google	Gemini学習でのコンテンツ利用（クロール自体ではない）
Applebot-Extended	Apple	Appleの生成モデル学習での利用
PerplexityBot	Perplexity	クロール
CCBot	Common Crawl	多くのモデルが学習に使う大規模アーカイブ

正直な注意点がふたつ。ひとつめ、robots.txtは任意です。行儀のよい事業者は従いますが、無視したいものは無視します。ふたつめ、ブロックには代償があります。ここに挙げたトークンの一部は、出典として引用・リンクしてくれるAI回答に自分が登場するかどうかを左右します。全部ブロックすれば、学習への露出と一緒にその流入経路も失います。自分が本当に気にしているのはどちらなのかを決めてください。

お願いではなく強制したいなら、サーバー側でブロックします。Apacheの.htaccessならこうです。

<IfModule mod_setenvif.c>
  SetEnvIfNoCase User-Agent "GPTBot|CCBot|ClaudeBot|PerplexityBot" ai_bot
  <RequireAll>
    Require all granted
    Require not env ai_bot
  </RequireAll>
</IfModule>

ユーザーエージェント名は簡単に偽装できるため、これで止まるのは正直だが歓迎したくないアクセスであって、本気のスクレイパーではありません。CDNやファイアウォールで検証済みのIP範囲によりブロックするほうが強力で、最近はほとんどのCDNがワンクリックのAIボット用ルールを用意しています。手書きのリストより保守が楽です。

効果がないもの

llms.txtは提案であって標準ではありません。 サイトの内容を言語モデル向けに説明するマークダウンファイルの提案です。これをアクセス制御として扱うと表明した主要事業者はありません。追加してもコストはゼロで、モデルの読み取りには役立つ可能性もありますが、何もブロックしません。

noaiとnoimageaiのメタタグは、ほぼ誰も尊重していません。 業界横断の合意ではなく、あるプラットフォームの方針から生まれたものです。追加しても害はありませんが、効くと期待するのは間違いです。

「AIをブロックする」と謳うプラグインは、たいていrobotsのルールを書いているだけです。 それ自体は問題ありませんし、10行ほどで自分でもできることです。法的にも技術的にも障壁ではなく、どのプラグインもそれを障壁に変えることはできません。

AIクローラーをブロックしても、すでに学習済みのモデルからコンテンツは消えません。 今日追加した設定が、去年公開されたモデルから記事を遡って取り除くことはありません。robotsのルールは、これから先にしか効きません。

それでもAIパネルが消えない場合

すべてのプラグインを停止してもパネルが残るなら、もう一度wp-content/mu-plugins/を確認し、次にサーバー会社の管理画面、そして自分が使っているのが自前設置ではなくWordPress.comではないかを確認してください。WordPress.comの場合、切り替えはサイトの管理画面ではなくアカウント設定にあります。そして、プラグイン更新のあとに機能が復活したなら、それはコアの初期設定が顔を出したのではなく、フック解除のスニペットが一致しなくなった典型的な症状です。