WordPress 7.0 WP AI Clientを実装目線で読み解いた話

これまで、プラグインごとに認証 UI が重複していた
実際に Connectors 画面を触ってみた
用語が紛らわしいので、最初に整理しておきたい
API キーがどこから読み込まれるか
wp_ai_client_prompt() を使ったコード - 4 つのパターン
モデルの優先順位を指定して、自動フォールバックに任せる
UI 表示前にチェックしておく - is_supported_*()
フィルターで実行制御 - wp_ai_client_prevent_prompt
Rapls AI Chatbot をどう対応させるか - 3 つの選択肢を比較した話
WordPress 7.1 以降 - Connectors API はもっと広がる
まとめ - 押さえておく 5 つのポイント
自分への戒め
関連記事

2026年3月24日の朝、いつものように Make WordPress Core ブログを開いたら、その日に公開されたばかりの「Introducing the AI Client in WordPress 7.0」という発表が目に入りました。WordPress 7.0 で、Core 側に AI 連携のための API が入る、という内容です。

読みながら、自作の AI チャットボットプラグイン「Rapls AI Chatbot」のコードベースのことが頭をよぎりました。私のプラグインでは OpenAI・Anthropic・Gemini・OpenRouter の 4 系統に対応していて、それぞれのプロバイダーで API のリクエスト形式が違ったり、レスポンスのスキーマが違ったり、モデル名の命名規則が違ったりするのを、ひとつずつ調べながらラッパー関数を書いてきました。けっこう時間をかけて作った部分です。

それと似たようなことを、これからは WordPress Core 側が引き受けてくれる、と書いてあるわけです。「自分が苦労して作った部分が、これからは Core に取り込まれていくんだな」という、少し複雑な気持ちで読み終えました。

でも一晩寝かせて読み直すと、これは AI プラグインを公開しているどの開発者にとっても、ほぼ同じ重複作業だったはずだ、と気づきました。Core 側がプロバイダー差異を吸収してくれれば、プラグインは本来やるべきこと(応答の精度、UI 体験、RAG 設計、ナレッジベース管理など)に集中できる。セキュリティ面でも、サイト管理者が API キーをひとつの場所で管理できるほうが、明らかに安全側です。最初の動揺は、自分の作業を肯定したい気持ちが先に立っていただけでした。

この記事は、Make Core の dev notes、WordPress/php-ai-client と WordPress/wp-ai-client の GitHub リポジトリのコードを読み、WordPress 7.0 RC3 を Local 環境に入れて Connectors 画面で API キーを設定するところまで実際に触りながら、自作プラグインへの取り込み方を考えた記録です。

この記事で押さえる 5 つの要点

WP AI Client は WordPress 7.0 で導入される、プロバイダー非依存の PHP API
サイト管理者は Settings > Connectors 画面で API キーを一度設定すれば、対応する全プラグインで共有できる
開発者は wp_ai_client_prompt() のメソッドチェーンで、テキスト・画像・JSON 生成を統一的に書ける
API キーは「環境変数 > PHP 定数 > DB」の順で優先される(2026年5月時点で DB は平文)
既存の AI プラグインは、後方互換を考えるとハイブリッド実装で段階移行するのが現実的

確認日と検証範囲

確認日: 2026年4月下旬〜5月上旬
確認環境: Local の WordPress 7.0 RC3 / PHP 8.3.21 / Cocoon 2.9.1.1 / 公開サイトは Xserver スタンダードプラン
確認できたこと: Settings > Connectors 画面で AI Provider for Anthropic / Google / OpenAI プラグインを実際にインストールして、API キーを入力するところまで実機で触りました。wp_ai_client_prompt() 関数の挙動や内部設計については、Make WordPress Core の dev notes と GitHub の WordPress/php-ai-client と WordPress/wp-ai-client リポジトリのコードを読んで確認しました。
確認できていないこと: 本番サイトへの大規模適用、トークン課金の実測値、WP CLI 経由の操作、サードパーティの AI プロバイダープラグイン(7.1 で対応予定とのこと)。WordPress 7.0 正式版(2026年5月20日リリース予定)での最終的な挙動は、正式版が出てから再確認します。
情報ソース: Make WordPress Core(AI Client / Connectors API dev notes)、WordPress/php-ai-client(GitHub)、WordPress/wp-ai-client(GitHub)、WordPress AI Team

WordPress 7.0 シリーズ Part 4

この記事は、WordPress 7.0 シリーズの 4 本目です。全体像、開発者向け、サイト運営者向けの 3 本も合わせて読むと、WordPress 7.0 の全体像が立体的につかめると思います。

Part 1:WordPress 7.0 リリース前の確認メモ
Part 2:WordPress 7.0 で開発者が確認しておきたいこと
Part 3:WordPress 7.0 アップデート前にサイト運営者が確認しておきたいこと
Part 4:この記事(WP AI Client)

これまで、プラグインごとに認証 UI が重複していた

WordPress に AI 連携プラグインを入れたことがある人なら、似たような経験があると思います。プラグイン A の設定画面で OpenAI の API キーを入れて、プラグイン B でも同じキーを入れて、プラグイン C ではまた別のフォーマットでキーを入れて……という、あの感じです。

私自身、Rapls AI Chatbot を作りながら、認証 UI まわりに思った以上に時間がかかりました。OpenAI と Anthropic と Gemini と OpenRouter で、それぞれ API の呼び出し方が違います。リクエストヘッダーの書き方、エンドポイントの構造、レスポンスの JSON スキーマ、ストリーミング応答の形式、モデル名の命名規則、トークン課金の単位、すべて少しずつ異なります。「画面では同じように『AI に質問する』というボタンに見えるのに、裏側のコードは 4 系統分書かないといけない」という状態でした。

これはたぶん、AI プラグインを WordPress.org に公開している開発者全員が、同じ苦労をしていたはずです。世の中には WP-CLI 連携のプラグイン、コメントモデレーション系のプラグイン、SEO 系のプラグイン、画像生成系のプラグインなど、いろんな AI プラグインがあって、それぞれが自分の設定画面で API キーを入力させ、自分のラッパーでプロバイダーを呼んでいたわけです。

サイトオーナー側から見ても、これはあまり気持ちの良い体験ではありません。3 つの AI プラグインを入れたら、同じ OpenAI の API キーを 3 つの場所に入力する必要がある。どこに何のキーを入れたかは、自分で覚えておかないといけない。プラグインを削除しても API キーがどこかに残っているかもしれない不安もあります。

WordPress 7.0 で導入される WP AI Client は、この重複を Core 側で引き受けてくれます。サイトオーナーは Settings > Connectors の画面で、Anthropic / Google / OpenAI の 3 プロバイダーの API キーを一度だけ設定する。あとは対応するプラグインがそれを共有して使う、という流れです。

実際に Connectors 画面を触ってみた

Local に WordPress 7.0 RC3 を入れて、Settings > Connectors 画面を開きました。最初は何も表示されません。WordPress Core 自体には AI プロバイダーが含まれていない設計になっているので、まずはプロバイダー用のプラグインをインストールする必要があります。

公開されている公式プラグインは 3 つです。

3 つともインストールして有効化すると、Connectors 画面にカード形式でプロバイダーが並びます。それぞれに「Connect」のボタンがあって、押すと API キー入力欄が出てきます。

API キーを入力して保存すると、カードの状態が「Connected」に変わります。キー自体は再表示できないように、マスク表示(sk-ant-***-xxxxの末尾だけ見える形)になります。これは一般的なシークレット管理 UI のパターンで、運用としても妥当だと思います。

WordPress 7.1 以降は、Mistral・Cohere・ローカル Ollama などのサードパーティプロバイダーも、同じ Connectors 画面に並ぶようになる予定とのことです。今は Anthropic / Google / OpenAI の 3 つだけですが、これは始まりに過ぎないと考えていいと思います。

用語が紛らわしいので、最初に整理しておきたい

WP AI Client、Connectors API、Connectors UI、PHP AI Client。最初に Make Core の dev notes を読んだとき、似たような名前が複数出てきて、それぞれが何を指しているのか、頭の中で整理するのに少し時間がかかりました。プラグイン開発者として記事を書く立場で、ここを曖昧にしておくと自分も読者も混乱するので、表にまとめます。

名称	役割
AI Client	プラグインが AI モデルに接続するための PHP API。`wp_ai_client_prompt()` で始まる
Connectors API	外部サービスの接続情報を管理するフレームワーク。AI 連携以外にも拡張予定
Connectors UI	Settings > Connectors の管理画面そのもの
PHP AI Client	基盤となるプロバイダー非依存の PHP SDK(GitHub:`WordPress/php-ai-client`)

プラグイン開発者から見ると、実質的には「wp_ai_client_prompt() を使うための仕組み一式」と理解しておけば足ります。

似たような時期に話題になっている MCP(Model Context Protocol)とは、役割の方向が逆です。MCP は「AI 側が WordPress を操作する」ためのプロトコルで、WP AI Client は「WordPress 側が AI を呼び出す」ための API です。同じ AI 連携でも、どちらが主導権を持っているかが違います。

API キーがどこから読み込まれるか

セキュリティに関わる話なので、ここは丁寧に書きます。WP AI Client は API キーを 3 つのソースから読み込めます。優先順位がはっきり決まっていて、上位のソースに値があれば、下位のソースは無視されます。

API キーのソース優先順位(上が強い)

1. 環境変数
例:ANTHROPIC_API_KEY=sk-ant-... をサーバー環境変数で設定。Git に含まれない、もっとも安全な置き場所

2. PHP 定数
例:define( 'ANTHROPIC_API_KEY', 'sk-ant-...' ); を wp-config.php に書く。サーバー設定が触れない環境向き

3. データベース
管理画面で入力した値。2026年5月時点では平文保存です。手軽だがセキュリティ的には一番弱い

本番運用では、できれば環境変数で渡したいところです。Xserver スタンダードプランのような共用レンタル環境では、サーバー側の環境変数を自由に設定できないケースもあるので、その場合は PHP 定数で wp-config.php に書く形になります。ただし wp-config.php を Git で管理している場合は、API キーをコミットに含めないよう、.gitignore で除外するか、require で外部の設定ファイルを読み込む形にしておくと安全です。

データベース保存(管理画面からの入力)は手軽ですが、現時点では平文で wp_options に保存されます。サイトが侵害された場合、API キーが漏洩する可能性があります。Trac #64789 で暗号化対応の議論が進んでいるので、将来的には改善されると見込まれますが、それまでは「テスト環境では DB 保存でいいけれど、本番は環境変数か PHP 定数」という運用方針が無難です。

wp_ai_client_prompt() を使ったコード – 4 つのパターン

ここからは実装の話です。WP AI Client では、すべての AI リクエストが wp_ai_client_prompt() という関数から始まります。この関数は WP_AI_Client_Prompt_Builder オブジェクトを返すので、メソッドチェーンでリクエストを組み立てる形になります。

テキスト生成、画像生成、動画生成、音声生成、テキスト読み上げを、すべて同じ API 体系で扱えるのが特徴です。

パターン 1:シンプルなテキスト生成

もっともシンプルな形がこれです。

$text = wp_ai_client_prompt( 'Write a haiku about WordPress.' )
    ->generate_text();

if ( is_wp_error( $text ) ) {
    // エラーハンドリング
    return;
}

echo wp_kses_post( $text );

$text = wp_ai_client_prompt( 'Write a haiku about WordPress.' )

->generate_text();

if ( is_wp_error( $text ) ) {

// エラーハンドリング

return;

}

echo wp_kses_post( $text );

プロンプトを wp_ai_client_prompt() の引数に直接渡すだけ。返り値はテキストの文字列で、エラー時は WP_Error が返ります。WordPress の他の API と同じく、必ず is_wp_error() でチェックしてから使うのが鉄則です。

パターン 2:温度とシステム命令を指定する

温度パラメータやシステム命令を指定したいときは、メソッドチェーンで足していきます。

$text = wp_ai_client_prompt( 'Explain caching.' )
    ->using_system_instruction( 'You are a WordPress developer writing documentation.' )
    ->using_temperature( 0.7 )
    ->generate_text();

$text = wp_ai_client_prompt( 'Explain caching.' )

->using_system_instruction( 'You are a WordPress developer writing documentation.' )

->using_temperature( 0.7 )

->generate_text();

温度、最大トークン数、Top-p、Top-k、停止シーケンスなど、主要な LLM パラメータはひととおり対応しています。

パターン 3:JSON スキーマで構造化出力を取る

これは個人的に「使いそう」と思った機能です。AI から構造化された JSON を返してほしいとき、スキーマを指定するだけでパース可能な出力になります。

$schema = array(
    'type'  => 'array',
    'items' => array(
        'type'       => 'object',
        'properties' => array(
            'plugin_name' => array( 'type' => 'string' ),
            'category'    => array( 'type' => 'string' ),
        ),
        'required' => array( 'plugin_name', 'category' ),
    ),
);

$json = wp_ai_client_prompt( 'List 5 popular WordPress plugins with their primary category.' )
    ->as_json_response( $schema )
    ->generate_text();

$data = json_decode( $json, true );

$schema = array(

'type' => 'array',

'items' => array(

'type' => 'object',

'properties' => array(

'plugin_name' => array( 'type' => 'string' ),

'category' => array( 'type' => 'string' ),

'required' => array( 'plugin_name', 'category' ),

);

$json = wp_ai_client_prompt( 'List 5 popular WordPress plugins with their primary category.' )

->as_json_response( $schema )

->generate_text();

$data = json_decode( $json, true );

Rapls AI Chatbot のような対話系プラグインでも、ユーザーの入力を分類したり、検索結果をパースしたりする場面で、構造化出力は重宝します。これまでは「JSON で返して」とプロンプトでお願いしても、たまにマークダウンの `json ブロックで包まれて返ってきたり、余計な前置きがついたりして、後処理が必要でした。スキーマ指定なら、その手間がなくなります。

パターン 4:画像生成も同じ API 体系で

$image_file = wp_ai_client_prompt( 'A futuristic WordPress logo in neon style' )
    ->generate_image();

if ( is_wp_error( $image_file ) ) {
    return;
}

echo '<img src="' . esc_url( $image_file->getDataUri() ) . '" alt="">';

$image_file = wp_ai_client_prompt( 'A futuristic WordPress logo in neon style' )

->generate_image();

if ( is_wp_error( $image_file ) ) {

return;

}

echo '<img src="' . esc_url( $image_file->getDataUri() ) . '" alt="">';

画像生成は generate_image() で呼び出すと、File DTO オブジェクトが返ってきます。getDataUri() で Data URI 形式のソースを取得できます。動画、音声、テキスト読み上げも、ほぼ同じパターンです。

モデルの優先順位を指定して、自動フォールバックに任せる

これも便利な仕組みです。using_model_preference() でモデルを指定できるのですが、これは「要求」ではなく「希望」として扱われます。指定したモデルがそのサイトで利用できなければ、互換性のある別のモデルに自動でフォールバックします。

$text_result = wp_ai_client_prompt( 'Summarize the history of the printing press.' )
    ->using_temperature( 0.1 )
    ->using_model_preference(
        'claude-sonnet-4-6',
        'gemini-3.1-pro-preview',
        'gpt-5.4'
    )
    ->generate_text_result();

$text_result = wp_ai_client_prompt( 'Summarize the history of the printing press.' )

->using_temperature( 0.1 )

->using_model_preference(

'claude-sonnet-4-6',

'gemini-3.1-pro-preview',

'gpt-5.4'

)

->generate_text_result();

優先順リストを渡せば、WordPress が利用可能なモデルの中から選んで使ってくれます。サイト A では Claude が設定されている、サイト B では Gemini だけが設定されている、というような環境差を、プラグイン側で意識しなくて良くなります。

私の場合、Rapls AI Chatbot を使っているサイトオーナーが、必ずしも 3 つのプロバイダーすべてに契約しているとは限りません。OpenAI だけ契約している人もいれば、Anthropic だけの人もいる。フォールバックがあれば、プラグイン側で「Anthropic 優先、なければ OpenAI」と指定しておけば、サイトオーナーの設定環境に自動で適応できます。

generate_text_result()(通常の generate_text() ではなく、末尾に _result が付いたほう)を使うと、実際にどのモデルが使われたかをレスポンスから取得できます。

$provider = $text_result->getProviderMetadata();
$model    = $text_result->getModelMetadata();
$tokens   = $text_result->getTokenUsage();

$provider = $text_result->getProviderMetadata();

$model = $text_result->getModelMetadata();

$tokens = $text_result->getTokenUsage();

これはトークン使用量のログを取りたいときや、プロバイダー別の統計を集めたいときに役立ちます。

UI 表示前にチェックしておく – is_supported_*()

ここは、プラグイン開発者として最初に気をつけるべき点だと感じました。WordPress 7.0 がインストールされていても、すべてのサイトで AI 機能が使えるわけではありません。Connectors にプロバイダーが設定されていなかったり、設定されていても接続テストが通っていなかったりすると、プロンプトは実行できません。

UI を表示する前に、is_supported_*() で利用可否を確認しておくのが基本です。

$builder = wp_ai_client_prompt( 'test' )
    ->using_temperature( 0.7 );

if ( $builder->is_supported_for_text_generation() ) {
    // ここで初めて AI UI を表示する
}

$builder = wp_ai_client_prompt( 'test' )

->using_temperature( 0.7 );

if ( $builder->is_supported_for_text_generation() ) {

// ここで初めて AI UI を表示する

}

このチェックは API 呼び出しを伴わないので、コストはかかりません。モダリティ別に以下のメソッドが用意されています。

is_supported_for_text_generation() – テキスト生成
is_supported_for_image_generation() – 画像生成
is_supported_for_text_to_speech_conversion() – テキスト読み上げ
is_supported_for_speech_generation() – 音声生成
is_supported_for_video_generation() – 動画生成

AI が使えない環境で「AI に質問する」ボタンだけが表示されていると、押した瞬間にエラーになって、ユーザーは「壊れているのか?」と思ってしまいます。表示前のチェックで、ボタン自体を非表示にするか、「AI 機能を使うには Connectors の設定が必要です」というメッセージを出すのが、運用としては安心です。

フィルターで実行制御 – wp_ai_client_prevent_prompt

wp_ai_client_prevent_prompt というフィルターがあって、これを使うと特定のプロンプト実行をブロックできます。権限管理やコスト制御に使う想定です。

add_filter(
    'wp_ai_client_prevent_prompt',
    function ( bool $prevent, WP_AI_Client_Prompt_Builder $builder ): bool {
        // 例:管理者以外はブロック
        if ( ! current_user_can( 'manage_options' ) ) {
            return true;
        }
        return $prevent;
    },
    10,
    2
);

add_filter(

'wp_ai_client_prevent_prompt',

function ( bool $prevent, WP_AI_Client_Prompt_Builder $builder ): bool {

// 例:管理者以外はブロック

if ( ! current_user_can( 'manage_options' ) ) {

return true;

}

return $prevent;

10,

);

このフィルターでブロックすると、AI 呼び出しは行われず、is_supported_*() も false を返すようになります。つまり関連 UI もきれいに非表示になる、というわけです。

具体的にどう使うかというと、たとえばこんな運用が考えられます。

権限管理:購読者ロールからの AI 呼び出しを禁止する
コスト制御:1 日の呼び出し回数に上限を設けて、超過したらブロック
監査ログ:ブロックする前にログテーブルに記録して、誰がいつ何を呼び出したかを追跡
メンテナンスモード:特定の時間帯だけ AI 機能を止める

このフィルターは、ホスティング事業者や、複数ユーザーを抱える企業サイトで重宝しそうです。個人ブログレベルだとあまり出番はないかもしれませんが、覚えておいて損はないと思います。

Rapls AI Chatbot をどう対応させるか – 3 つの選択肢を比較した話

ここからは、自作プラグイン側の話です。WP AI Client が登場することで、Rapls AI Chatbot の認証まわりをどう作り直すかを考えました。

現状の認証実装

Rapls AI Chatbot は今、OpenAI・Anthropic・Gemini・OpenRouter の 4 系統に対応していて、プラグイン独自の認証 UI を持っています。API キーは AES-256-GCM で暗号化したうえで、プラグイン専用の独自テーブルに保存しています。暗号化に使う鍵は、wp-config.php の AUTH_KEY 系の WordPress 標準セキュリティキーから派生させる形にしているので、サイトごとに異なる鍵で暗号化されます。

この実装は、セキュリティ的には Connectors API の現状の平文保存より強い状態にあります。ただ、これも完璧ではなくて、暗号鍵が wp-config.php から取れる以上、サーバー全体が侵害されれば復号できてしまいます。「平文保存よりはマシ」というレベルです。

それと、4 系統分の認証 UI を維持するコストは、それなりに大きいです。ユーザーから「API キーの設定が分かりにくい」というフィードバックも、何度かもらっています。

3 つの案を比べた

WP 7.0 対応として、3 つの選択肢を比較しました。

案	内容	良い面	気になる面
A 案	Connectors API へ完全移行。独自 UI は撤廃	プラグイン側のコードがシンプルに	WP 7.0 未満で動かなくなる
B 案	独自 UI を維持。WP AI Client は使わない	既存ユーザーへの影響なし	WP 7.0 の利便性を取りこぼす
C 案	ハイブリッド(WP 7.0 検出時は Connectors 優先、それ未満は独自 UI)	両方のメリットを取れる	コード量は増える

採用したのは C 案(ハイブリッド)です。理由を 3 つ書いておきます。

1 つ目は、WordPress 7.0 への移行が段階的にしか進まないだろうという見込みです。WordPress プラグインのユーザー層を見ていると、新しいバージョンへの追従が早い人もいれば、安定運用を優先して数ヶ月から半年単位で様子を見る人もいます。WordPress.org のレビューで「動かなくなった」と低評価をもらうのは、プラグイン作者としてはとても堪えるので、しばらくは両バージョン対応を維持しておくほうが安全です。

2 つ目は、既存ユーザーの設定を引き継ぎたいということ。Rapls AI Chatbot にすでに API キーを設定しているサイトに対して、「次のアップデートで Connectors 側に入れ直してください」と強制すると、ユーザーにはただの手間です。「アップデートしたら設定が消えた」とレビューが付いたら最悪です。

3 つ目は、現時点でのセキュリティレベルの差です。Connectors 側は平文、Rapls AI Chatbot 側は AES-256-GCM で暗号化、という状態なので、サイトオーナーが「Connectors 経由で便利にしたい」のか「自前の暗号化を維持したい」のかを選べる形にしておきたい、と考えました。Trac #64789 で Connectors の暗号化対応が実装されたら、この理由は弱くなりますが、それまでは選択肢を残しておく価値があります。

採用した C 案の擬似コード

実装方針はこんなイメージです。

// Rapls AI Chatbot 側の認証情報取得ロジック(擬似コード)
function rapls_get_ai_credentials( $provider ) {
    // 1. WP 7.0+ で、サイトオーナーが Connectors を選んでいれば、そちらを優先
    if ( function_exists( 'wp_get_connector' ) && rapls_is_connectors_preferred() ) {
        $connector = wp_get_connector( $provider );
        if ( $connector && ! empty( $connector['authentication'] ) ) {
            return get_option( $connector['authentication']['setting_name'] );
        }
    }

    // 2. 独自テーブルから取得(後方互換 + デフォルト)
    return rapls_get_legacy_credentials( $provider );
}

// Rapls AI Chatbot 側の認証情報取得ロジック(擬似コード)

function rapls_get_ai_credentials( $provider ) {

// 1. WP 7.0+ で、サイトオーナーが Connectors を選んでいれば、そちらを優先

if ( function_exists( 'wp_get_connector' ) && rapls_is_connectors_preferred() ) {

$connector = wp_get_connector( $provider );

if ( $connector && ! empty( $connector['authentication'] ) ) {

return get_option( $connector['authentication']['setting_name'] );

}

// 2. 独自テーブルから取得(後方互換 + デフォルト)

return rapls_get_legacy_credentials( $provider );

}

プラグイン設定画面には「Connectors API に設定済みの API キーを使う」というチェックボックスを追加して、サイトオーナーが明示的に切り替えられる UI を提供します。デフォルトは既存ユーザーを壊さないように、独自 UI を優先する側にしておく予定です。

影響を受ける箇所はどこか

Rapls AI Chatbot 内で、コードを書き換える必要のある場所を洗い出してみました。

認証情報を取得する中核関数 – 1 箇所
プロバイダーごとの API 呼び出しラッパー – 4 箇所(OpenAI / Anthropic / Gemini / OpenRouter)
設定画面の UI – 1 画面(チェックボックスの追加と表示切り替え)
テストコード – WP 7.0 環境用のモック追加

wp_ai_client_prompt() を使えば、OpenAI・Anthropic・Gemini 用の個別 SDK 依存コードは、ひとつのラッパー関数に置き換えられます。OpenRouter だけは現時点で Connectors 側に公式プラグインがないので、独自実装を残します。

Rapls AI Chatbot 全体の設計や RAG 実装の話は、別記事「Rapls AI Chatbot ガイド｜WordPress AI チャットボットの導入から運用まで」に書いています。

WordPress 7.1 以降 – Connectors API はもっと広がる

WordPress 7.1(2026 年 8 月予定)では、Connectors API の機能が拡張される予定とのことです。Make Core ブログの記述を読む限り、ここから「AI プロバイダー専用」から「外部サービス全般の統合接続基盤」へと、役割が広がっていきそうです。

現時点で確認できている拡張予定は、こんな内容です。

サードパーティの AI プロバイダー(Mistral・Cohere・ローカル Ollama など)の Connectors 画面対応
api_key と none 以外の認証方式(OAuth など)のサポート
ai_provider 以外のコネクタータイプの管理画面対応(外部ストレージ、検索サービスなど)
API キーのデータベース暗号化(Trac #64789)

プラグイン開発者から見ると、WP AI Client にいま対応しておけば、その後の拡張にも自動的に乗れる、というのは大きなメリットです。Connectors API は単なる「AI 用の窓口」ではなく、「WordPress がこれから外の世界とどう繋がるか」を司る基盤になっていくのだと思います。

まとめ – 押さえておく 5 つのポイント

長くなったので、最後にざっくりまとめておきます。

項目	要点
エントリーポイント	`wp_ai_client_prompt()` からメソッドチェーン
プロバイダー指定	`using_model_preference()` で優先順位を渡し、利用できなければ自動フォールバック
事前チェック	`is_supported_*()` で UI 表示前に利用可否を確認
認証管理	環境変数 > PHP 定数 > DB の順で優先。DB は 2026年5月時点では平文
後方互換性	既存プラグインは WP 7.0 未満との両対応を、しばらくは考慮

AI 機能を新しく作るプラグインなら、wp_ai_client_prompt() と is_supported_for_text_generation() の組み合わせから入るのが、もっとも素直だと思います。すでに独自認証 UI を持つプラグインは、ハイブリッドで段階移行を検討してみてください。

自分への戒め

WP AI Client の発表を最初に読んだとき、自分が時間をかけて作った認証 UI が「重複した実装」になっていく未来に、正直なところ少し動揺しました。WordPress を 6 年以上やってきていて、Core 側の動きで自分の作業が再評価される、という経験は何度かしてきたはずなのに、毎回同じ感情の動きをしてしまう自分がいます。

ただ、これは AI プラグインのエコシステム全体としては、間違いなく良い方向への変化です。プラグインが本来やるべき価値の高い処理(応答精度、UI 体験、RAG 設計、ナレッジベース管理)に、もっと時間を使えるようになる、ということ。自分の作業を肯定したい気持ちで判断を歪めない、というのは戒めです。

もうひとつ、Make Core の議論や Trac チケットを完全には追いきれていないことも、戒めとして書いておきます。WordPress.org の Japanese locale で PTE をやっている以上、Core 側の動きにはもう少し丁寧にアンテナを張りたい。今回、WP AI Client の用語整理について Polyglots 内での議論を見守る場面はありましたが、「この用語はこう訳すべきだ」と能動的に提案するレベルにはまだ届いていません。WordPress 7.0 が正式リリースされてからは、もう少し踏み込んだ関わり方を模索したいと思います。