先に結論
WordPress 7.0 で大きく変わったのは、AI plugin ごとに provider 接続を抱え込まなくてもよくなり始めたことです。
Vercel AI Gateway plugin を入れると、AI Client 対応 plugin は Settings > Connectors に入れた 1 つの key を共通で使えるようになります。provider outage 時の fallback、モデル追加、請求の集約も connector 側へ寄せやすくなります。
ただし、何でも自動ではありません。前提は WordPress 7.0 + AI Client 対応 plugin + connector 設定 です。ここが揃わないと、公開直後の changelog どおりの恩恵は受けにくいです。
WordPress 7.0 自体の変更点から先に見たいなら、WordPress 7.0公開で何が変わったか を先に読むとつながります。
何が公開されたのか
Vercel は 2026 年 5 月 20 日、WordPress 向け AI Gateway plugin を公開しました。
これは、WordPress 7.0 で入った AI Client の connector として動く plugin です。WordPress 側の説明と plugin directory を合わせて見ると、狙いははっきりしています。AI を使う plugin 側が provider ごとの API key や個別統合を持たずに済むようにすること です。
Vercel の changelog では、1 つの API key で 40 以上の provider、100 以上のモデルに接続できると案内しています。対象には Anthropic、Google、OpenAI などが含まれます。
つまり今回の主語は、新しい生成 plugin を 1 本増やしたことではありません。WordPress の AI 接続面をまとめる connector が正式に出てきたこと が本質です。
何が楽になるのか
一番分かりやすい変化は、接続管理です。
従来は、AI plugin ごとに provider 統合を持つ構成になりやすく、鍵管理や model 追加の追従が散りがちでした。Vercel AI Gateway plugin を使うと、AI Client 対応 plugin は Settings > Connectors の設定を共通で参照できます。
これで楽になるのは主に 4 つです。
- provider ごとの API key 管理を plugin ごとに抱えにくい
- 新しい model が増えたとき、plugin update を待たずに拾いやすい
- provider outage 時の fallback を connector 側へ寄せやすい
- billing と observability を provider 単位ではなく接続面でまとめやすい
とくに WordPress で複数の AI plugin を試すチームには効きます。記事生成、画像生成、要約、社内向け補助機能を別 plugin で持つ場合でも、接続面を 1 つに寄せやすいからです。
逆に、まだ自動ではないこと
ここは期待値を上げすぎないほうが安全です。
まず、効くのは AI Client 対応 plugin に限られます。WordPress 7.0 の AI Client を使っていない既存 plugin や独自実装は、そのままでは自動で AI Gateway につながりません。
次に、WordPress 7.0 へ上げただけでも足りません。plugin directory の案内どおり、Vercel AI Gateway Provider plugin を入れて有効化し、Settings > Connectors に API key を入れる必要があります。
もうひとつ残るのが、plugin 開発側の設計判断です。AI Gateway を必須にしたいなら using_provider( 'ai_gateway' ) を明示する手があります。一方、WordPress の developer note では、互換性を広く保つなら provider を固定せず、using_model_preference() で希望モデルだけ示すやり方を勧めています。
要するに、接続は共通化しやすくなったが、どこまで固定するかは開発者が決める ままです。
開発者はどう実装を分けるべきか
まず候補になるのは、provider 固定が本当に必要かを分けることです。
社内運用で AI Gateway を必須にしたい、コスト監視や fallback をそこへ寄せたい、という事情が強いなら using_provider( 'ai_gateway' ) を使う理由があります。狙った接続面を強制できるからです。
逆に、配布 plugin として広く動かしたいなら、provider 固定は慎重なほうがいいです。plugin directory の説明でも、広い互換性を残すなら provider を固定せず、using_model_preference() で Claude、Gemini、GPT のような希望順だけ渡す方法が勧められています。
この分岐は重要です。前者は運用統制に強く、後者は配布互換性に強いからです。
WordPress 7.0 記事と合わせて何を見るべきか
すでに WordPress 7.0公開で何が変わったか を読んだ人なら、今回の plugin はその続きとして見ると分かりやすいです。
WordPress 7.0 側で入ったのは AI Client と Connectors の土台です。今回の Vercel plugin は、その土台に「実際に複数 provider へつなぐ connector」を乗せた形です。
なので導入順も自然です。
- まず WordPress 7.0 と既存 theme / plugin の互換性を確認する
- 次に AI Client 対応 plugin を使う前提があるかを見る
- そのうえで、接続を個別実装ではなく AI Gateway に寄せる価値があるか判断する
ここを飛ばして plugin だけ先に入れると、AI Client 非対応 plugin が残っていて「あまり変わらない」と感じやすいです。
どんなチームに向いているか
相性がいいのは、WordPress 上で AI 機能を増やす予定があるチームです。
たとえば、記事要約、画像生成、社内向け補助、SEO 補助のような AI 導線を少しずつ足すなら、接続面を毎回作り分けるより connector に寄せたほうが後で整います。
逆に、AI を 1 機能だけ小さく試す段階なら、ここまで整えなくてもよい場合があります。複数 plugin や複数 provider を見据えるかどうかが分かれ目です。
WordPress の外まで含めて、gateway を導入する意味をもう少し広く見たいなら、Edgee AI Gateway vs OpenAI usage tiers vs Gemini spend caps vs Anthropic cost reports も補助になります。こちらは WordPress 専用の話ではなく、接続面とコスト制御をどこで持つかの比較です。
まとめ
Vercel AI Gateway plugin for WordPress で変わったのは、WordPress 7.0 の AI Client を実運用へつなげる道が具体化したことです。
- 前提は WordPress 7.0 と AI Client 対応 plugin
- Settings > Connectors に 1 つの key を入れるだけで接続を共有しやすい
- 40+ providers / 100+ models をまとめて扱える
- fallback、billing、observability を connector 側へ寄せやすい
- provider を固定するか、model preference で広く保つかは実装次第
だから最初の判断は単純です。WordPress 7.0 で AI plugin を広げる予定があり、接続管理を増やしたくないなら、この plugin はかなり有力です。まずは WordPress 7.0 の土台を確認し、その次に AI Gateway へ寄せる価値があるかを見る順がいちばん失敗しにくいです。