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 つの選択肢を比較した話
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 キーをひとつの場所で管理できるほうが、明らかに安全側です。最初の動揺は、自分の作業を肯定したい気持ちが先に立っていただけでした。

この記事は、RC3 の段階で Local 環境に入れて Connectors 画面で API キーを設定するところまで実際に触り、そのうえで 2026年5月20日にリリースされた WordPress 7.0 正式版でも同じ手順を再確認した記録です。Make Core の dev notes、WordPress/php-ai-client と WordPress/wp-ai-client の GitHub リポジトリのコードも合わせて読みながら、自作プラグインへの取り込み方を考えました。

先に短くまとめておくと、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月上旬(RC3)、および 2026年5月20日以降(正式版 7.0)
確認環境: Local の WordPress 7.0(RC3 および 5月20日リリースの正式版) / PHP 8.3.21 / Cocoon 2.9.1.1 / 公開サイトは Xserver スタンダードプラン
確認できたこと: Settings > Connectors 画面で AI Provider for Anthropic / Google / OpenAI プラグインを実際にインストールして、API キーを入力するところまで実機で触りました。この 3 プロバイダーについては、RC3 と 5月20日の正式版とで挙動に違いがないことを再確認しています。wp_ai_client_prompt() 関数の挙動や内部設計については、Make WordPress Core の dev notes と GitHub の WordPress/php-ai-client と WordPress/wp-ai-client リポジトリのコードを読んで確認しました。
確認できていないこと: 本番サイトへの大規模適用、トークン課金の実測値、WP CLI 経由の操作、サードパーティの AI プロバイダープラグイン(7.1 で対応予定とのこと)。OpenRouter は現時点で Connectors 側に公式プラグインがないため、正式版での Connectors 経由の挙動は未確認です。
情報ソース: 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 の新機能を全体から見た記事は WordPress 7.0 の主要な新機能まとめにあります。この記事は、そのうち AI まわりだけをプラグイン開発者の目線で掘ったものです。実際に乗せ替えたときに詰まった箇所は 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 画面を触ってみた

まず RC3 の段階で Local に WordPress 7.0 を入れて、Settings > Connectors 画面を開きました。最初は何も表示されません。WordPress Core 自体には AI プロバイダーが含まれていない設計になっているので、まずはプロバイダー用のプラグインをインストールする必要があります。この画面まわりの挙動は、後日 5月20日の正式版でも同じであることを確認しています。

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

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

API キーを入力して保存すると、カードの状態が「Connected」に変わります。キー自体は再表示できないように、マスク表示(sk-ant-***-xxxxの末尾だけ見える形)になります。これは一般的なシークレット管理 UI のパターンで、運用としても妥当でしょう。この Connect から Connected への流れも、Anthropic / Google / OpenAI の 3 プロバイダーについては、正式版でも RC3 と同じでした。

今後は、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月時点(正式版 7.0)では平文保存です。手軽だがセキュリティ的には一番弱い

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

データベース保存(管理画面からの入力)は手軽ですが、正式版 7.0 の時点でも平文で 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 を優先する側にしておく方針です。

ここまでが、実装前に立てた方針です。実際に乗せ替えてみると、いちばん時間を溶かしたのは検出でもフォールバックでもなく、会話の履歴を with_history() に渡すところでした。エラーも出さずに文脈だけが消える、という気味の悪い壊れ方をします。実装してどこで詰まったかは、別記事に記録しました。

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

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

Connectors API は、この先どこまで広がるのか

Make Core ブログの記述を読む限り、Connectors API は「AI プロバイダー専用」から「外部サービス全般の統合接続基盤」へと役割を広げていく設計になっています。dev note で将来の方向として挙げられているのは、次の4点です。

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

(2026年8月7日追記)WordPress 7.1 は8月19日にリリース予定で、8月5日に Field Guide が公開されました。確認した範囲では、上の4点はいずれも 7.1 には含まれていません。7.1 の開発者向けの変更は、クライアントサイドのメディア処理、レスポンシブなブロックスタイル、SVG Icon API、Abilities API の拡張などが中心です。Connectors API まわりは 7.1 以降の課題として残っています。

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

まとめ – 押さえておく 5 つのこと

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

項目	内容
エントリーポイント	`wp_ai_client_prompt()` からメソッドチェーン
プロバイダー指定	`using_model_preference()` で優先順位を渡し、利用できなければ自動フォールバック
事前チェック	`is_supported_*()` で UI 表示前に利用可否を確認
認証管理	環境変数 > PHP 定数 > DB の順で優先。DB は正式版 7.0 時点では平文
後方互換性	既存プラグインは 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 が正式リリースされた今、正式版での挙動も確認できたので、これからはもう少し踏み込んだ関わり方を模索したい、と書いておきます。