以前は、WordPressプラグインが生成AIを使う場合、OpenAIやGoogleなど各providerのSDK・認証・エラー処理を個別に実装する必要がありました。AI Clientは、プラグイン側が「テキスト生成」「画像生成」など必要な能力を同じ入口から要求し、WordPress側が設定済みproviderへ橋渡しする方向へ整理したものです。
2026年9月時点では、WordPressのAI周辺は変化が速いので「7.1で何でもAI化された」と理解しない方が安全です。Coreにあるもの、AI pluginで実験されているもの、PHP AI Client側だけにあるものを分けて見る必要があります。
AI Clientが解決するのは「providerごとの違いを各プラグインで抱えない」こと
| 従来の実装 | AI Clientを使う設計 |
|---|---|
| プラグインごとにprovider SDKを組み込む | WordPressの共通prompt builderを使う |
| API key管理を各プラグインが持つ | Connectors経由でprovider credentialを管理 |
| provider変更で実装差分が大きい | 同じ機能コードを維持しやすい |
| エラー形式・result処理がばらつく | WordPress向けの統一的な扱いへ寄せる |
開発者向けの基本入口は`wp_ai_client_prompt()`です。テキスト生成や画像生成などをbuilder形式で設定し、結果にはtoken usage、provider、modelなどのmetadataも含められます。運営者目線ではコードそのものより「AI機能を入れるpluginが、特定providerへベタ書きせずに済む」ことが長期保守に効きます。
7.0でCoreへ入ったもの・入っていないもの
WordPress 7.0でCoreへ入ったが、AIのprovider自体は同梱されない
AI Clientはprovider-agnosticな基盤で、WordPress Coreが特定のAIサービスを固定で抱える設計ではありません。provider接続は別pluginで用意し、Connectorsの仕組みからcredentialを扱います。公式プロジェクトでもAnthropic、Google、OpenAI向けのconnector実装が進められています。
この設計の利点は、AIサービス側のAPI変更やモデル追加の速度と、WordPress Coreのリリース周期を分けられることです。一方で、AI Clientがあるだけでは何も生成できません。利用可能なprovider connectorとcredentialが設定され、要求した能力をそのproviderがサポートしている必要があります。
AI Clientは「WordPressの標準AIチャット画面」ではない
WordPress 7.1時点でも、Coreの標準管理画面に汎用AIチャットのような万能UIが常時表示されるわけではありません。AI Clientは主にplugin開発者が機能を作るための基盤です。記事タイトル生成、ALT案、画像生成、要約などのユーザー向け体験は、AI Clientを利用するplugin側が実装します。
この点を理解せず「WordPress 7ならAIが無料で使える」と考えると期待がずれます。AI ClientはAI料金を無料化する仕組みでもありません。provider契約、API課金、利用制限は接続先の条件に依存します。
他のWordPress AI基盤との組み合わせ
Abilities API・MCPとの役割分担
| 仕組み | 主語 | 役割 |
|---|---|---|
| AI Client | WordPress → AI model | 文章・画像などをAIへ生成/分析させる |
| Abilities API | WordPress内の機能 | できることをschema・権限付きで定義する |
| MCP Adapter | AI agent → WordPress | 公開されたAbilityをAI側から発見・実行する |
| REST API | 外部system ↔ WordPress | 投稿等のresourceをHTTPで扱う |
たとえば「WordPress内で記事の要約を作る」ならAI Clientが中心です。「AIエージェントからWordPressの記事一覧を取得する」ならAbilities/MCPが中心になります。両方を組み合わせ、「AgentがAbilityを呼ぶ→WordPress側のAbilityがAI Clientで分析する」という構成も可能です。
画像生成の公式チュートリアルから分かる実装ポイント
WordPress Developer Blogでは、AI Clientを使ってMedia Libraryへ画像生成機能を追加する例が公開されています。重要なのは「AIへpromptを送る」部分だけでなく、能力サポートを確認し、結果を受け取り、WordPressのメディアとして保存するまでを分けている点です。
運営機能へ応用する場合も同じです。AI Clientが返した文章をそのまま公開するのではなく、sanitize、権限、保存先、preview、公開条件をWordPress側で設計します。生成機能と公開機能を別にすることで、model変更があっても公開安全性を維持しやすくなります。
WordPress 7.1では「予定されていた機能」と「実際に入ったもの」を分ける
7.1の計画段階ではstreamingやembeddingsが大きく取り上げられました。しかし、2026年8月の公式AI Team更新では、embeddingのWordPress Core統合は7.1に入らず7.2以降へ持ち越されたことが確認できます。streamingもWordPress本体で自然に使える状態まで完成したとは扱わない方が正確です。
このような領域では、Roadmap記事だけを見て「搭載済み」と断定しないことが重要です。Release後のField Guide、AI Team summary、Core dev noteまで確認し、予定と実装済みを分けます。TameshiTechでは旧情報と現行情報を混同しないため、この記事も2026年9月30日時点の状態で記載しています。
AI Clientを導入する価値が高いケース
- 独自pluginにAI要約・生成・分類機能を組み込みたい
- 複数providerを切り替えられる設計にしたい
- API key管理をpluginごとに重複させたくない
- WordPress標準のhook・WP_Error・Connectorsと合わせたい
- Abilitiesと組み合わせてAI機能を再利用したい
反対に、外部のAIサービスで文章を作り、完成したdraftをREST APIでWordPressへ入れるだけなら、AI Clientを使わなくても実現できます。AI Clientは「WordPress内部でAI機能を提供する」比率が高いほど価値が出る基盤です。
本番導入前に確認したい6項目
- 対象WordPressが7.0以降か
- 利用したいprovider connectorがあるか
- 必要な生成能力をprovider/modelが持つか
- API費用・rate limit・token usageをどう記録するか
- AI出力を保存する前にsanitize/validationするか
- AIが失敗しても通常のWordPress機能を壊さないfallbackがあるか
AI Clientを使う理由は「最新技術だから」ではなく、provider依存を下げ、AI機能をWordPressの権限・保存・監査設計へ組み込みやすくすることです。サイト運営だけが目的なら無理に導入せず、必要なplugin機能が出た時点で検討すれば十分です。
公式情報・参考資料
仕様確認日：2026年9月30日。実装時はリンク先の最新版も確認してください。
- https://make.wordpress.org/core/2026/03/18/introducing-the-connectors-api-in-wordpress-7-0/
- https://make.wordpress.org/core/2026/03/24/introducing-the-ai-client-in-wordpress-7-0/
- https://developer.wordpress.org/news/2026/05/how-to-build-an-image-generation-plugin-with-the-wordpress-ai-client/
- https://make.wordpress.org/ai/2026/08/27/ai-contributor-weekly-summary-26-august-2026/
- https://make.wordpress.org/core/2026/08/05/wordpress-7-1-field-guide/
コメント