先に結論
Vercel AI Gateway の provider allowlist は、request-level の provider 指定を厳しくした機能 ではありません。組織が承認していない provider へ流れないことを gateway 側で保証する更新 です。
特に効くのは次の3点です。
- BYOK でも未承認 provider を止められる
- coding agent が request 側を書き換えても gateway で止められる
- new provider が自動で許可されず、owner が明示判断できる
Vercel AI Gateway を gateway、cost control、observability の層として使っているなら、今回の更新は小さくありません。provider を毎回コードで縛る運用から、team-wide の governance へ一段上げられるからです。
何が変わったのか
Vercel は 2026年5月28日の changelog で、AI Gateway に team-wide provider allowlist を追加しました。
これは team owner が承認した provider だけを AI Gateway の routing 候補に残す設定です。開発者や agent が request 側で別 provider を選ぼうとしても、team 側で無効なら通りません。
重要なのは、制御の場所が request ではなく gateway に移った ことです。ここが、従来の providerOptions.gateway.only と一番違います。
request-level only filter との違い
only は今でも便利です。特定ジョブだけ OpenAI に固定したい、ある処理だけ Anthropic を避けたい、といった絞り込みには向いています。
ただし only だけでは、team 全体の保証にはなりません。別の request で指定を変えれば、未承認 provider に流せてしまうからです。
provider allowlist を有効にすると、判断は次の順でシンプルになります。
- team の allowlist に入っているか
- その request の only 条件を満たすか
両方を満たした provider だけが候補です。どちらかで候補がゼロになると、AI Gateway は 403 no_providers_available を返します。
BYOK と coding agents への影響
今回いちばん実務で効くのはここです。
Vercel は changelog と docs の両方で、BYOK traffic にも allowlist が適用される と明記しています。つまり、自前キーなら抜け道になる、という設計ではありません。
coding agents についても同じです。agent が request 側の provider filter を消したり、別 provider に切り替えたりしても、team 側で許可していない provider には AI Gateway から出られません。
agent 導入を進めるほど、各リクエストの細かいガードを人が追うのは難しくなります。そういうチームほど、request ごとの善意に頼らず gateway で止める 価値があります。Vercel 上の agent 運用全体を見直したいなら、Vercel plugin と MCP の役割分担 や、継続実行系の agent 運用比較 も合わせて見ると整理しやすいです。
料金と利用条件
provider allowlist は無料ではありません。
Vercel docs では、team-wide provider allowlist は 1,000 successful requests ごとに 0.10ドル の追加料金です。課金対象は成功レスポンスだけで、allowlist で弾かれた 403 や他の失敗リクエストは課金されません。
使えるのは Pro と Enterprise です。しかも設定変更できるのは owner ロールだけ です。member は現在の設定を見られても、変更はできません。
request-level の only filter は全プランで追加料金なしです。組織統制までは不要で、単発の routing 条件だけ欲しいなら、まずこちらで十分です。
403 no_providers_available はどこで起きるか
代表例は、request と team 設定がぶつかるケースです。
たとえば request 側で DeepSeek のみを許可しつつ、team の allowlist では DeepSeek を無効化していると、候補 provider がなくなります。この時に返るのが 403 no_providers_available です。
もう1つ見落としやすいのは、provider 単位の制御 だという点です。同じ model を複数 provider が配信している場合、1社だけ止めても model 全体は止まりません。docs では openai/gpt-5-mini のような model が openai と azure の両方から提供される例が示されています。
つまり、特定 model を完全に止めたいなら、その model を出している provider を全部止める 必要があります。
new provider default disabled が意味すること
allowlist を有効にした後で Vercel が新しい provider を追加した場合、その provider は default で disabled です。
ここは地味ですが重要です。provider catalog が増えても、承認済みセットが勝手に広がりません。regulated team や vendor review 前提の組織では、この挙動がそのまま運用ルールになります。
一方で、便利さは少し落ちます。新 provider を使いたい時は、owner が確認して保存しない限り有効になりません。新 provider の検証フローを owner 依存のままにすると詰まりやすいので、誰が判断し、どの基準で許可するかは先に決めておいた方が安全です。
いま確認しておきたい導入チェック
今すぐ見るなら、確認点は5つで足ります。
- 自分たちの plan は Pro か Enterprise か
- owner が AI Gateway Settings を触れるか
- 今使っている model がどの provider から配信されているか
- 1,000 successful requests ごとの追加料金を許容できるか
- new provider を default disabled のまま運用できるか
すでに provider ごとのコストや制御面を見直しているなら、AI Gateway と他社のコスト統制比較 も参考になります。
どう使い分けるべきか
単発ジョブを絞るだけなら、まず only で十分です。無料で始められますし、導入も軽いです。
一方で、team 全体の provider policy を監査しやすくしたい、BYOK や coding agents を含めて抜け道を減らしたい、という段階なら provider allowlist の方が噛み合います。
要するに、request-level filter は局所最適、team-wide allowlist は組織統制 です。今回の更新で Vercel AI Gateway は、単なる routing レイヤーから governance レイヤーにも踏み込みました。