WP AI Client完全解説——WordPress 7.0で変わるAI連携の新標準

WP AI Clientとは何か——「プロバイダー非依存」のAI連携標準
Connectors UIで何が変わるのか——APIキーの重複入力からの解放
基本的な使い方——wp_ai_client_prompt()のメソッドチェーン
モデルの優先指定と自動フォールバック——プロバイダー意識からの解放
必須の機能サポート検出——UI表示前にis_supported_*()で確認
プロンプト実行制御フィルター——権限管理とコスト制御の要
Rapls AI Chatbotでの対応方針——ハイブリッド実装を採用する3つの理由
WordPress 7.1以降のロードマップ——AI基盤から統合接続基盤へ
まとめ——開発者視点で押さえるべき5つのポイント

「OpenAIとClaudeとGemini、3つのAPIキーをどのプラグインに登録するかで毎回迷う」——WordPressサイトでAIプラグインを複数使っていると、こんな悩みに直面しませんか。

WordPress 7.0で導入されるWP AI Clientは、この問題を根本から解決する。プラグインはもう独自の認証UIを作る必要がなく、wp_ai_client_prompt()関数ひとつでOpenAI・Claude・Geminiを統一的に扱える。

この記事では、WP AI Clientの基本から、Connectors UIの仕組み、認証管理のベストプラクティス、そして自作プラグイン「Rapls AI Chatbot」でWP AI Clientをどう統合するかの設計判断まで、プラグイン開発者の実務視点で解説する。

この記事の結論

WP AI ClientはWordPress 7.0で導入される「プロバイダー非依存」のAI連携標準です。サイト管理者がSettings > Connectors画面でAPIキーを一度設定すれば、対応するすべてのプラグインがそのプロバイダーを共有できる。開発者はwp_ai_client_prompt()関数のメソッドチェーンだけで、テキスト生成・画像生成・JSON構造化出力を実装でき、モデルの自動フォールバックも標準対応。APIキーの優先順位は「環境変数 > PHP定数 > データベース」で、本番環境では環境変数かPHP定数での管理を強く推奨します（DB保存分は現時点で平文）。

検証環境：WordPress 7.0 RC2 / PHP 8.3.21 / Cocoon 2.9.1.1 / Xserver（xs435215）
情報ソース：Make WordPress Core（AI Client・Connectors API dev notes）/ WordPress/php-ai-client（GitHub）/ WordPress/wp-ai-client（GitHub）/ WordPress AI Team（2026年4月時点の情報）

WordPress 7.0 関連記事

この記事はWordPress 7.0で導入されるWP AI Client APIの仕組みと実装方法を解説しています。WordPress 7.0の他の新機能・技術変更については以下もご覧ください。

WordPress 7.0の新機能を完全ガイド
 WordPress 7.0の技術的変更点を深掘り
 WordPress MCP × Claude Connector完全解説
 DataViews完全ガイド【管理画面刷新】
Interactivity APIとは——jQuery不要の宣言的UI

WP AI Clientとは何か——「プロバイダー非依存」のAI連携標準

WP AI Clientは、WordPress 7.0で導入されたプロバイダー非依存のPHP APIです。プラグインが「何を」「どう」生成したいかを記述するだけで、WordPressが適切なプロバイダー・モデルへのリクエストをルーティングする。従来は各AIプラグインが独自に認証UI・APIキー保存・プロバイダー選択を実装していたが、WP AI ClientはこれをCoreレベルで標準化する。

用語が似ていて混同しやすいので、最初に整理する。

名称	役割
AI Client	プラグインがAIモデルに接続するためのPHP API
Connectors API	外部サービスの接続情報を管理するフレームワーク
Connectors UI	Settings > Connectors の管理画面。AIプロバイダーを一元管理
PHP AI Client	基盤となるプロバイダー非依存のPHP SDK（GitHub: WordPress/php-ai-client）

開発者から見ると、実質的には「wp_ai_client_prompt()関数を使うための仕組み一式」と理解して問題ない。

MCP（Model Context Protocol）によるAI連携とは役割が異なる。MCPは「AIがWordPressを操作する」ためのプロトコル、WP AI Clientは「WordPressがAIを呼び出す」ためのAPIだ。詳細は「WordPress MCP × Claude Connector完全解説」も参照してほしい。

Connectors UIで何が変わるのか——APIキーの重複入力からの解放

Settings > Connectors画面で、サイト管理者はAIプロバイダーを一箇所で設定できる。初期状態ではAnthropic・Google・OpenAIの3つが選択可能で、それぞれ個別の公式プラグインをインストールしてAPIキーを入力するだけで利用開始できる。WordPress Core自体にはAIプロバイダーは含まれず、実際の実装は別途プラグインとして提供される設計だ。

3つの公式プロバイダープラグイン

WordPress Core自体にはAIプロバイダーは含まれない。Coreはあくまで「土台」であり、実際のプロバイダー実装は別途プラグインとして提供される。これはAI分野の変化の速さに対応するための意図的な設計だ。

初期提供される3つの公式プラグインは以下のとおり。

AI Provider for Anthropic（Claude用）
AI Provider for Google（Gemini用）
AI Provider for OpenAI（GPT用）

WordPress 7.1以降は、Mistral・Cohere・ローカルOllama等のサードパーティプロバイダーもConnectors画面に登録できるようになる見込みだ。

APIキーのソース優先順位

APIキーは3つのソースから読み込めるが、優先順位が明確に定義されている。

環境変数（例：ANTHROPIC_API_KEY）
PHP定数（例：define( 'ANTHROPIC_API_KEY', 'sk-...' );）
データベース（管理画面で入力した値）

本番環境では環境変数かPHP定数での管理を推奨する。特にGit管理されているwp-config.phpに直接書くのは避け、.envファイル経由や環境変数で渡すのが安全だ。

セキュリティ上の注意点——DB保存は現時点で未暗号化

現時点ではデータベースに保存されたAPIキーは暗号化されていません。管理画面では一度保存したキーの完全な値を再表示できない（マスク表示になる）仕組みになっているが、データベース自体には平文で保存される。

暗号化対応はTrac #64789で検討されており、将来的に改善される見込みだ。それまでは、本番環境では環境変数かPHP定数での管理を強く推奨する。

WordPressのセキュリティ全般については「WordPressプラグイン31本にバックドア発覚——「転売」が生んだサプライチェーン攻撃の全貌と対策」も併せて参照してほしい。プラグインのサプライチェーン攻撃が現実化した今、APIキー管理の重要性は増している。

基本的な使い方——wp_ai_client_prompt()のメソッドチェーン

すべての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スキーマを指定した構造化出力

$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 );

JSONスキーマを指定すると、モデルは指定された構造に従ったJSON文字列を返す。検索結果のパース処理、バリデーション、データベース登録など、構造化データが必要な場面で非常に使いやすい。

パターン4：画像生成

$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()で、返り値はFileDTOオブジェクトだ。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を使うといった環境差を、プラグイン側で意識せずに済む。

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機能が使えるわけではない。UI表示前に必ずis_supported_*()メソッドで利用可否を確認する必要がある。このチェックはAPI呼び出しを行わないためコストがかからず、「プロバイダー未設定のサイトで『AI機能』ボタンだけ見える」という混乱を防げる。

$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を表示

}

モダリティ別に以下のメソッドが用意されている。

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機能」ボタンだけ表示されていると、ユーザーは混乱する。UI側で利用不可メッセージを出すか、ボタン自体を非表示にする運用が推奨される。

プロンプト実行制御フィルター——権限管理とコスト制御の要

wp_ai_client_prevent_promptフィルターを使うと、特定のプロンプト実行をブロックできる。権限管理やコスト制御、利用状況監査などに利用できる。このフィルターでブロックすると、AI呼び出しは行われず、is_supported_*()メソッドもfalseを返すため、関連UIもクリーンに非表示化できる。

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呼び出しを禁止する
コスト制御：1日の呼び出し回数上限を設け、超過時にブロックする
監査ログ：ブロック前にログテーブルへ記録し、誰がいつ何を呼び出したかを追跡する
メンテナンスモード：特定時間帯だけAI機能を止める

Rapls AI Chatbotでの対応方針——ハイブリッド実装を採用する3つの理由

拙作のAIチャットボットプラグイン「Rapls AI Chatbot」では、WP 7.0未満との後方互換性を保ちつつWP AI Clientを優先使用するハイブリッド実装で対応する予定です。A案（完全移行）・B案（独自UI維持）・C案（ハイブリッド）の3選択肢を比較した結果、既存ユーザーの離脱を防ぎながら新規ユーザーにはConnectors UIの利便性を提供できるC案を選択した。

現状の認証設計

Rapls AI Chatbotは現在、OpenAI・Anthropic・Gemini・OpenRouterの4系統について、独自の認証UIとAES-256-GCMによる暗号化保存を実装している。ユーザーは設定画面で直接APIキーを入力し、WP_Optionsに暗号化した状態で保存される仕組みだ。

WP 7.0対応にあたっての3つの選択肢

選択肢	内容	メリット	デメリット
A案	Connectors API完全移行。独自UIは撤廃	コードがシンプルになる	WP 7.0未満のユーザーが使えなくなる
B案	独自UI維持。WP AI Clientは使わない	既存ユーザーに影響なし	WP 7.0の利便性を享受できない
C案	ハイブリッド（WP 7.0検出時はConnectors優先）	両方のメリットを取れる	コード量は増える

採用はC案（ハイブリッド）。理由は以下の3点だ。

WP 7.0への移行は段階的に進むため、しばらく両バージョンの共存が必要になる
既存ユーザーの設定を引き継ぎたい。強制移行は離脱を生む
Connectors側の暗号化が未実装のため、セキュリティレベルを落とさないための自前暗号化が必要な場面がある

実装方針の概要

// プラグイン側の認証情報取得ロジック（擬似コード）
function rapls_get_ai_credentials( $provider ) {
    // 1. WP 7.0+ なら Connectors API から取得を試みる
    if ( function_exists( 'wp_get_connector' ) ) {
        $connector = wp_get_connector( $provider );
        if ( $connector && ! empty( $connector['authentication'] ) ) {
            // Connectors 経由で取得
            return get_option( $connector['authentication']['setting_name'] );
        }
    }

    // 2. 既存の独自保存から取得（後方互換）
    return rapls_get_legacy_credentials( $provider );
}

// プラグイン側の認証情報取得ロジック（擬似コード）

function rapls_get_ai_credentials( $provider ) {

// 1. WP 7.0+ なら Connectors API から取得を試みる

if ( function_exists( 'wp_get_connector' ) ) {

$connector = wp_get_connector( $provider );

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

// Connectors 経由で取得

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箇所だ。wp_ai_client_prompt()を使えば、OpenAI・Anthropic・Gemini用の個別SDK依存コードをすべて1つのラッパー関数に置き換えられる見込みだ。

OpenRouter対応のみ現時点ではConnectors側で未対応のため、独自実装を維持する。

Rapls AI Chatbotの設計思想やRAG実装の詳細については「Rapls AI Chatbot開発者が解説｜なぜ作ったか・RAGの設計判断」で解説している。

WordPress 7.1以降のロードマップ——AI基盤から統合接続基盤へ

WordPress 7.1（2026年8月予定）では、Connectors APIがさらに拡張される見込みだ。将来的には「AIプロバイダー」だけでなく、WordPressが連携する全ての外部サービスの統一的な接続管理基盤として機能していく計画。つまりConnectors APIは「AI専用」ではなく、WordPressとあらゆる外部サービスを繋ぐ汎用的な接続フレームワークへと進化する。

現時点で確認できている拡張予定は以下のとおりだ。

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

プラグイン開発者にとっては「AI連携を今から始める価値」が明確に高まったといえる。WP AI Client対応をいち早く実装したプラグインは、7.1・7.2でConnectors APIが拡大するにつれ、その恩恵をそのまま受けられるポジションに立てる。

まとめ——開発者視点で押さえるべき5つのポイント

WP AI Clientは、WordPressプラグイン開発者にとって認証まわりの重荷を取り除く重要な基盤機能だ。プラグインは「どのプロバイダー」ではなく「何を生成するか」だけを記述すれば良くなり、サイトオーナーは一度設定したAPIキーを全プラグインで再利用できる。既存プラグインの開発者は、ハイブリッド実装で段階的な移行を検討してほしい。

開発者視点で押さえるべきポイントを整理する。

項目	要点
エントリーポイント	`wp_ai_client_prompt()`からメソッドチェーン
プロバイダー指定	`using_model_preference()`で優先順位、利用できなければ自動フォールバック
必須の事前チェック	`is_supported_*()`でUI表示前に利用可否確認
認証管理	環境変数 > PHP定数 > DB の順で優先。DBは現状未暗号化
後方互換性	既存プラグインはWP 7.0未満への対応も考慮が必要

AI機能をプラグインに組み込みたい開発者は、まずはwp_ai_client_prompt()とis_supported_for_text_generation()の組み合わせから試してみるのがおすすめだ。既存の独自認証UIを持つプラグインは、ハイブリッド実装で段階的に移行することを検討してほしい。

WordPress 7.0全体のアップデート手順については「WordPress 7.0 アップデート完全ガイド」で解説している。