
WordPress 7.0(開発コードネーム Armstrong)が 2026 年 5 月に正式リリースされ、コアに AI Connectors(Connectors API) と WP AI Client が標準搭載されました。
「WordPress に AI が入った」と話題になりますが、実際に触ってみると最初に感じるのは 「完成品というより、これから育つインフラ」 という印象です。
いきなり「全部 AI が書いてくれる CMS」にはなっていません。
本記事では、AI 連携プラグインに Connectors API 連携を一通り組み込んだうえでソースコードを調査し、実際の仕組み・動作の流れ・プラグイン/テーマとの連携作法、および プラグイン側で API キーを持つ従来方式との比較をまとめます。
1. 用語を整理する — 4 つの名前が出てくる
WordPress 7.0 の AI まわりは、似た名前が並ぶので最初にそれぞれを整理しておくと読み進めやすくなります。
| 名称 | 役割 |
|---|---|
| Connectors API | 外部サービス(まずは AI プロバイダー)の接続情報を管理する 認証・設定の基盤 |
| Connectors UI | 管理画面の 設定 > コネクタ(options-connectors.php) |
| WP AI Client | プラグイン開発者が PHP から AI を呼び出すための 統一 API(wp_ai_client_prompt() など) |
| PHP AI Client | 上記の内部実装(wordpress/php-ai-client パッケージ) |
Connectors API は AI 専用ではありません。
Connectors API は将来的には決済・メール・外部ストレージなど、あらゆる外部サービス接続の共通基盤を目指しています。
2. 全体像 —「3 層 + 公式プラグイン」で動く
Connectors API と WP AI Client の関係を、ざっくりとした流れにすると次のようになります。
- サイト管理者
-
「設定 > コネクタ」で API キーを 1 回入力
▼
- Connectors API(認証・接続状態の管理)
-
- API キーの保存(環境変数 > PHP定数 > DB の優先順位)
- プロバイダー接続状態の確認
▼
- 公式プロバイダープラグイン(別途インストール)
-
- AI Provider for OpenAI
- AI Provider for Anthropic
- AI Provider for Google
▼
- WP AI Client(PHP API)
-
wp_ai_client_prompt('プロンプト')
->using_system_instruction('...')
->using_model_preference('claude-...', 'gpt-...')
->generate_text();▼
- 各種 AI プラグイン・テーマ・コア機能
-
チャット、ライター、SEO 提案、画像生成 などプラグイン・テーマ側の独自機能
WordPress コア本体には AI プロバイダーは含まれていません。
Connectors 画面を開いても最初は空で、公式の 3 プロバイダープラグインをインストールして API キーを登録する必要があります。
3. セットアップの流れ — ユーザーがやること
実際の導入手順は、次の 4 ステップです。
- テップ 1:WordPress 7.0 以上にアップデート
-
PHP バージョン要件や既存プラグインとの互換性により、すぐに移行できないサイトも多いのが現実です。
- ステップ 2:プロバイダープラグインをインストール
-
ダッシュボードの「設定」→「コネクタ」から、使いたいプロバイダーのインストールボタンを押します。

- ステップ 3:API キーを登録して「接続済み」にする
-
各プロバイダーカードの Connect ボタンから API キーを入力し、保存します。キーはマスク表示され、再表示はできません。

- ステップ 4:必要に応じて公式「AI」プラグインを有効化
-
コアの Connectors API は インフラ です。
エディター上でタイトル生成や抜粋提案などを使うには、別途公式の 「AI」プラグイン(旧 AI Experiments)を有効化し、機能トグルを ON にする必要があります。
4. API キーはどこに保存されるか — 優先順位を知っておく
Connectors API 経由の API キーは、次の 3 段階の優先順位 で読み込まれます(上位があれば下位は無視)。
| 優先度 | 保存場所 | 例 | 向いている環境 |
|---|---|---|---|
| 1(最強) | 環境変数 | ANTHROPIC_API_KEY=sk-ant-... | VPS、Docker、本番サーバー |
| 2 | PHP 定数 | wp-config.php に define(...) | 共用レンタルサーバー |
| 3 | データベース | 管理画面から入力した値 | ローカル開発、検証環境 |
2026 年 5 月時点の正式版 7.0 では、管理画面から入力したキーは DB に平文保存 されます。
本番環境では環境変数か PHP 定数の利用を推奨します。暗号化対応は WordPress Core の Trac で議論中です。
また、Connectors 利用時には コネクター承認(tools.php?page=ai-connector-approval)という仕組みもあり、サイト管理者がプロバイダープラグインの利用を明示的に承認する必要がある場合があります。
コネクタを設定したのに機能がグレーアウトする場合は、ここも確認してください。
5. 実際の動作の流れ — 1 回の AI 呼び出しで何が起きるか
Connectors API 連携を実装すると、1 回の AI 呼び出しはおおむね次の流れになります。
5-1. フロントエンド(ブロックエディター)からの呼び出し
JavaScript(React)からは wp_ai_client_prompt() を直接呼べません。PHP 専用 API のため、プラグイン側は通常 REST API エンドポイントを用意 し、そこから WP AI Client を呼び出します。
- エディター UI(React)
-
apiFetch(WordPress REST API)
↓ - プラグインの REST エンドポイント(PHP)
-
権限チェック(
edit_posts等)
↓function_exists('wp_ai_client_prompt')確認
↓wp_supports_ai()確認
↓ - wp_ai_client_prompt
-
wp_ai_client_prompt($message)
->using_system_instruction(…)
->using_model_preference(['google', 'gemini-2.5-flash'])
->using_temperature(0.7)
->generate_text(); - プロバイダーへのリクエスト
-
Connectors API が保存した API キーを使ってプロバイダーへ HTTP リクエスト
- レスポンス
-
結果を JSON でエディターに返却
5-2. PHP から直接呼び出す場合
サーバー側の処理(投稿保存時の自動要約など)なら、PHP から直接呼べます。
if ( ! function_exists( 'wp_ai_client_prompt' ) ) {
return; // WordPress 6.x 等では何もしない
}
$result = wp_ai_client_prompt( '以下の記事を要約してください: ' . $content )
->using_system_instruction( 'あなたは要約の専門家です。' )
->using_temperature( 0.3 )
->using_max_tokens( 200 )
->generate_text();
if ( is_wp_error( $result ) ) {
error_log( $result->get_error_message() );
return;
}
// $result に生成テキストが入る
5-3. 利用可否の事前チェック
AI 呼び出し前に、次のチェックが重要です。
function_exists('wp_ai_client_prompt')— WordPress 7.0 未満では存在しないwp_supports_ai()— サイト全体で AI が無効化されていないかis_supported_for_text_generation()等 — コネクタが接続済みで、要求する機能(テキスト/画像/音声)に対応しているか
3 番目は API を叩かずに確認できる ので、UI 表示前の判定に使えます。「ボタンは出ているのに押すとエラー」という UX を避けられます。
5-4. モデル一覧の取得
Connectors 経由で利用可能なモデル一覧は、内部の モデルレジストリ から取得します。
プロバイダーと機能(テキスト生成、画像生成など)を指定して問い合わせる形です。
実装してみると、レジストリが返す一覧には 用途別の専用モデル(TTS、画像専用、エージェント向けなど)がテキスト生成用としても混ざることがあり、UI のモデル選択肢としてはフィルタリングが必要になるケースがありました。
Connectors API が「使えるモデル一覧」を返すだけで、「用途に適したモデル」まで選んでくれるわけではない点は、プラグイン側の工夫が必要です。
6. プラグイン・テーマとの連携作法 — 実装で学んだ 5 つの原則
Connectors API 連携を実装する際に、実務上効果が大きかった作法をまとめます。
原則 1:ハイブリッド方式を採用する
WordPress 7.0 未満のサイトも多いため、Connectors 完全移行は現実的ではありません。
WordPress 6系 ではプラグイン側で管理するキーを利用するハイブリッド方式 が妥当です。
| モード | 動作 |
|---|---|
| Auto(自動) | プラグイン独自の API キーがあればそちらを優先。なければ Connectors を使う |
| Connectors 優先 | WordPress の Connectors 経由で呼び出す |
| プラグイン API キー | 従来通りプラグイン設定画面のキーを使う |
Auto モードにしておくと、既存ユーザーの設定を壊さず、新規ユーザーは Connectors だけで動かせます。
原則 2:存在チェックでグレースフルデグラデーション
if ( ! function_exists( 'wp_ai_client_prompt' ) ) {
// 従来の API 直接呼び出しにフォールバック
}
WordPress 6.x でも Fatal Error にならないようにするのは必須です。
原則 3:UI から Connectors 設定画面へ誘導する
Connectors モードでは API キーはプラグイン側では管理しません。
設定画面に 「Connectors 設定を開く」 リンクを置き、未接続時は具体的な案内メッセージを出すと、ユーザーの混乱が減ります。
原則 4:モデル指定は using_model_preference() を使う
// プロバイダー + モデル ID を 1 つの配列引数として渡す
$builder->using_model_preference( array( 'google', 'gemini-2.5-flash' ) );
// またはモデル ID だけ(Connectors が利用可能なプロバイダーから自動選択)
$builder->using_model_preference( 'gemini-2.5-flash', 'gpt-4o' );
using_model_preference() は 希望リスト として扱われ、利用できないモデルは次候補にフォールバックします。
サイト A では Claude、サイト B では Gemini だけ、という環境差をプラグイン側で意識しなくて済むのは大きなメリットです。
原則 5:重い処理は同期実行しない
LLM 呼び出しは 1〜10 秒かかることが珍しくありません。save_post フック内で同期的に実行するとページ保存が遅くなります。wp_cron や Action Scheduler で非同期化するのが現実的です。
7. Connectors API vs プラグイン独自 API キー — メリット・デメリット
実装を通して感じた、両方式の比較です。
Connectors API 方式のメリット
| 項目 | 内容 |
|---|---|
| API キーの一元管理 | 同じ OpenAI キーを 3 つのプラグインに重複入力する必要がない |
| プロバイダー切替がコード不要 | 管理画面で Anthropic → OpenAI に変えてもプラグインはそのまま動く |
| 実装コストの削減 | プロバイダーごとの HTTP クライアント・認証 UI を自前で書かなくてよい |
| WordPress 標準のエラー処理 | WP_Error パターンで統一 |
| 将来の拡張性 | WordPress 7.1 以降のサードパーティプロバイダー追加に自動対応しやすい |
Connectors API 方式のデメリット
| 項目 | 内容 |
|---|---|
| WordPress 7.0 以上が必須 | 古いバージョンでは使えない(ハイブリッド実装が必要) |
| 機能の制限 | 後述の「できないこと」が多い |
| API キーの平文 DB 保存 | 2026 年 5 月時点では暗号化なし(環境変数推奨) |
| コスト管理・ログ機能なし | トークン使用量の追跡、レート制限はプラグイン側で実装が必要 |
| 高度な OpenAI 機能に非対応 | Vector Store、Assistants API、File Search 等は Connectors 経由では使えない |
| JavaScript から直接呼べない | REST API ブリッジの実装が別途必要 |
プラグイン独自 API キー方式のメリット
| 項目 | 内容 |
|---|---|
| WordPress バージョン非依存 | 6.x でも動作 |
| 全 API 機能にアクセス可能 | 各プロバイダーの最新 API(ストリーミング、Function Calling、RAG 等)を直接利用 |
| 暗号化保存が可能 | プラグイン側で AES 暗号化等を実装できる |
| 細かい制御 | モデル、パラメータ、エラーハンドリングを完全にカスタマイズ可能 |
プラグイン独自 API キー方式のデメリット
| 項目 | 内容 |
|---|---|
| API キーの重複管理 | プラグインごとにキー入力が必要 |
| プロバイダー差異の吸収コスト | OpenAI / Anthropic / Google で API 形式が異なり、ラッパー実装が必要 |
| メンテナンス負荷 | プロバイダーの API 変更に都度対応 |
| セキュリティリスクの分散 | プラグインごとに認証実装の品質がバラつく |
8. 現時点で「現実的に使える」機能と「まだ実用性が低い」機能
Connectors API 連携を実装・検証した結果、機能ごとの現実的な評価です。
✅ 現実的に使える(今すぐ価値がある)
| 機能 | 評価 | 理由 |
|---|---|---|
| テキスト生成(単発) | ★★★★☆ | 要約、タイトル提案、SEO メタ、分類など。最も安定 |
| JSON 構造化出力 | ★★★★☆ | as_json_response($schema) でパース不要の出力が得られる |
| 画像生成(Google/Gemini) | ★★★☆☆ | Connectors 経由で Gemini 画像モデルが使える。ただしクォータ管理に注意 |
| API キー一元管理 | ★★★★★ | Connectors API の最大の価値。運用面で明確なメリット |
| モデル自動フォールバック | ★★★★☆ | 環境差を吸収できる。マルチテナント向けプラグインに有効 |
| PHP からのバッチ処理 | ★★★★☆ | 投稿保存時の自動要約、コメントモデレーション等。非同期化すれば実用的 |
△ 条件付きで使える(工夫が必要)
| 機能 | 評価 | 課題 |
|---|---|---|
| チャット(会話履歴あり) | ★★☆☆☆ | WP AI Client はマルチターン会話をネイティブサポートしていない。会話履歴をプロンプトにテキストで埋め込む回避策が必要で、長い会話では精度・コスト面で不利 |
| ストリーミング表示 | ★★☆☆☆ | Connectors 経由では SSE ストリーミング非対応。一度に全文取得して擬似ストリーミング(文字を少しずつ表示)する回避策のみ |
| 音声生成(TTS) | ★★★☆☆ | Google コネクター経由で Gemini TTS は動く。OpenAI TTS は Connectors 側の対応状況に依存 |
| マルチプロバイダー切替 UI | ★★★☆☆ | モデル一覧取得・フィルタリングをプラグイン側で実装する必要あり |
チャットのようなストリーミング(リアルタイム応答)表示が求められる場合は、実質対応できません。
❌ 現時点では実用性が低い(Connectors では代替不可)
| 機能 | 理由 |
|---|---|
| RAG / ベクトル検索 | Embeddings 生成・Vector Store 連携はスコープ外。ナレッジベース連携はプロバイダー API 直接呼び出しが必要 |
| Function Calling / Tool Use | エージェント的な動作には非対応 |
| Fine-tuning | モデル微調整は Connectors 経由では不可 |
| OpenAI Assistants / File Search | OpenAI 固有の高度 API は Connectors 抽象化レイヤーの外 |
| リアルタイム音声認識(Whisper 等) | 音声入力系は Connectors 経由の対応が限定的 |
9. 実装で遭遇した「ハマりどころ」— 開発者向けの注意点
Connectors API 連携を実装する際、公式ドキュメントだけでは気づきにくい点を共有します。
① 会話履歴は with_history() ではなくテキスト埋め込み
WP AI Client には会話履歴を渡す API がありますが、すべてのプロバイダー・モデルで期待通りに動作するとは限りません。
実装では 会話履歴をプロンプトの前置きテキストとして連結する 方式がより確実でした。
ただしトークン消費が増え、長い会話ではコストと精度の両面で不利です。
② モデル指定の引数形式に注意
using_model_preference() に ['google', 'gemini-2.5-flash'] を渡す場合、配列を 1 引数として渡す 必要があります。
スプレッド演算子で 2 引数に分解すると、プロバイダー ID がモデル ID として誤解釈されることがあります。
③ method_exists() が効かないケースがある
WP AI Client の Prompt Builder は内部で __call マジックメソッドを使っているため、method_exists($builder, 'using_model_preference') が false を返すことがあります。try〜catch で囲んで実行する方が安全です。
④ モデル一覧に用途外モデルが混在する
Connectors のモデルレジストリは「テキスト生成対応」として TTS モデルや画像専用モデルも返すことがあります。
UI のモデル選択肢として使う場合は、モデル ID パターンによるフィルタリングが実務上必要です。
10. 公式「AI」プラグインの機能 — コア体験としてどこまで使えるか
WordPress 公式の「AI」プラグイン(旧 AI Experiments)が提供する機能は次のとおりです。
- 画像の生成と編集
- コンテンツの分類(タグ・カテゴリー提案)
- コンテンツの長さ調整(短縮・拡張・言い換え)
- 抜粋の生成
- 代替テキスト(alt)の生成
- メタディスクリプションの生成
- 修正案ノート(アクセシビリティ・文法・SEO)
- コンテンツの要約
- タイトルの生成
これらは ブロックエディター前提 で、クラシックエディターでは使えません。
また、Connectors 未接続時はすべてグレーアウトします。
11. 総合評価 — Connectors API は「正しい方向の、まだ未完成の基盤」
Connectors API 連携を一通り実装したうえでの総合評価をまとめます。
評価:★★★☆☆(3.5 / 5) —「インフラとしては優秀、プロダクトとしてはこれから」
| 観点 | 評価 | コメント |
|---|---|---|
| 設計思想 | ★★★★★ | プロバイダー非依存の抽象化、API キー一元管理。WordPress エコシステムに必要な基盤 |
| 認証・設定 UX | ★★★★☆ | Connectors 画面はシンプルで分かりやすい。承認フローはやや冗長 |
| 開発者 API | ★★★☆☆ | wp_ai_client_prompt() は直感的。ただし機能制限が多く、高度な用途には不向き |
| エンドユーザー体験 | ★★☆☆☆ | 公式 AI プラグイン単体では「期待外れ」感がある。サードパーティプラグインの成熟を待つ段階 |
| セキュリティ | ★★★☆☆ | 環境変数対応は良い。DB 平文保存は改善待ち |
| 後方互換性 | ★★☆☆☆ | WordPress 7.0 必須。ハイブリッド実装が現実的 |
| 将来性 | ★★★★★ | Abilities API + MCP、7.1 のプロバイダー拡張、暗号化対応など、拡張ロードマップは明確 |
誰にとって今すぐ価値があるか
- 新規 AI プラグイン開発者 — 認証・プロバイダー切替の実装を省略でき、ビジネスロジックに集中できる
- 複数 AI プラグインを使うサイト運営者 — API キーの重複入力が解消される
- PHP から単発 AI 処理を追加したいテーマ/プラグイン作者 — 要約・分類・SEO 提案など
誰にはまだ物足りないか
- 本格的な AI チャット・RAG・エージェント — ストリーミング、Function Calling、Vector Store が必要
- WordPress 6.x ユーザー — 7.0 未満では Connectors API 自体が存在しない
- クラシックエディター利用者 — ブロックエディター前提の機能しか使えない
- コスト管理を重視する運用者 — ログ・課金追跡は AI Engine 等の追加プラグインが必要
結論
WordPress 7.0 の Connectors API は、「WordPress 全体で AI を使うための共通の電源コンセント」 として正しい方向に進んでいます。
ただし 2026 年 5 月時点では、コンセントは設置されたが、接続できる家電(プラグイン)の種類と性能はまだ限定的 という段階です。
プラグイン開発者にとっての現実的な対応方針は次のとおりです。
- ハイブリッド方式 で Connectors と独自 API キーの両方に対応する
- 単発テキスト生成・JSON 出力・画像生成 は Connectors 経由で十分実用的
- チャット・RAG・ストリーミング は引き続きプロバイダー API 直接呼び出しが必要
function_exists()ガード とis_supported_*()事前チェック を必ず入れる- WordPress 7.1 以降の拡張(プロバイダー追加、暗号化、Abilities API)を継続的にウォッチする
Connectors API は「完成品」ではなく 「WordPress AI エコシステムの起点」 です。
インフラとしての価値は本物であり、プラグインエコシステムがこの基盤の上に乗っかってくる過渡期に、開発者・運用者双方が触っておく価値は十分にあります。
今回の検証を踏まえて AI 連携機能を提供する「DPA AI Assistant」プラグインでは、次のアップデートにて Connectors API を利用した機能の実装を予定しています。

