Vercel AI GatewayでResponses APIを安全運用する方法

Vercel AI Gatewayを試したいけど、「障害時に止まらないか」「監査ログをどこまで残せるか」「OpenAI依存が強くならないか」で手が止まっている人は多いですよね。この記事は、OpenAI Responses APIを使いながらマルチLLM運用に広げたい人に向けて書いています。読むと、今日から実装できる最低限の設計、運用監査、レート制限対策まで一気に組めます。僕は福祉事業のIT全般を担当しつつ、AI×SaaS開発を複業で回しているので、実務で止めない前提でまとめます。

なぜ今、Vercel AI GatewayとOpenAI Responses APIなのか

今このテーマを押さえる理由は、更新日がはっきりしているからです。2026年3月6日のVercel公式更新で、AI GatewayがOpenAI Responses APIに直接対応しました。つまり、既存のOpenAI SDK利用コードは大きく崩さず、接続先をGatewayに寄せるだけでマルチLLM化の入口に立てます。

• 移行期限が明確 — OpenAIはResponses API移行を推奨し、Assistants APIの終了予定日は2026年8月26日です
• 実装差分が小さい — baseURL変更で始められるので、段階導入しやすいです
• 将来の切替が楽 — provider/model形式でベンダーを横断できます

OpenAIの移行ガイドでは、同条件比較でSWE-benchが3%改善したと案内されています。もちろん数値だけで全案件を判断するのは早いですが、少なくとも「移行すると不利になる」という状況ではありません。結論として、2026年はResponses APIを中心に据えて、Gatewayで運用面を強化するのが現実的です。開発スピードだけでなく、監査と継続性を同時に取りにいけるからです。

最小実装：baseURL差し替えでマルチLLM化する手順

実装は想像よりシンプルです。まずOpenAI SDKの接続先をhttps://ai-gateway.vercel.sh/v1へ変更します。次にモデル指定をopenai/gpt-5.4のようなprovider/model形式へ寄せます。これでOpenAI Responses APIの書き方を維持したまま、ルーティング対象を増やせます。

1. キーを分離する — AI_GATEWAY_API_KEYと各ベンダー鍵を分けて管理します
2. 接続先をGateway化する — SDK初期化のbaseURLだけ先に変更します
3. モデル名を統一する — provider/model形式へ寄せます
4. 許可プロバイダーを絞る — まずはonlyで実行先を限定します

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.AI_GATEWAY_API_KEY,
  baseURL: "https://ai-gateway.vercel.sh/v1"
});

const res = await client.responses.create({
  model: "openai/gpt-5.4",
  input: "監査可能な要約を作成してください",
  providerOptions: {
    gateway: {
      order: ["openai", "anthropic"],
      only: ["openai", "anthropic"]
    }
  }
});

運用メモとして、外部導線ではなく、実測ログ・設定差分・再現手順を同じ場所に残してチーム内で確認できる形にしてください。

安全運用設計① マルチLLM監査ログを残す方法

マルチLLM運用で最初にやるべきことは、モデル変更よりログ設計です。AI Gateway Observabilityでは、モデル別リクエスト数、P75 TTFT、平均トークン、コストを同じ画面で見られます。これだけでも「遅いのはどこか」「高いのはどこか」がかなり見えます。

GET /v1/usage/generation?id=gen_xxx

# 代表的な確認項目
# provider_name / is_byok / latency / generation_time
# tokens_prompt / tokens_completion / total_cost

Usage APIは、1件ごとの生成を追跡できるのが強みです。たとえばtotal_cost: 0.00123やlatency: 200msのように、数字で会話できます。「なんとなく高い」を「この生成IDが高い」に変えると、改善の速度が一気に上がります。非ITメンバーへの説明もかなり楽になります。

安全運用設計② 429対策と予算管理を先に決める

実務で詰まりやすいのは、モデル精度より429対応です。OpenAI系の制限軸はRPM、RPD、TPM、TPD、IPMで管理されるので、単純なリトライだけでは再失敗しやすいです。実運用では「429検知 + ヘッダ監視 + 指数バックオフ」をセットで入れるのが安定します。

const sleep = (ms: number) => new Promise(r => setTimeout(r, ms));

async function withRetry(task: () => Promise<any>, max = 4) {
  for (let i = 0; i < max; i++) {
    try {
      return await task();
    } catch (e: any) {
      if (e?.status !== 429 || i  max - 1) throw e;
      const wait = 500 * Math.pow(2, i);
      await sleep(wait);
    }
  }
}

OpenAIのレート制限仕様と、Usage APIを同時に見ながら運用すると、障害の予兆を先に拾えます。固定の正解はありませんが、しきい値を先に決めておく運用は再現性が高いです。

安全運用設計③ 障害時も止めないフォールバック構成

次に、障害時の継続性です。Model Fallbacksでモデルチェーンを作り、Provider Timeoutsで遅い経路を切り上げます。特にBYOK運用では、タイムアウト発生時に次の候補へ流せる設計が重要です。設定範囲は1,000ms〜789,000msなので、用途別に調整できます。

const res = await client.responses.create({
  model: "openai/gpt-5.4",
  input: userInput,
  providerOptions: {
    gateway: {
      models: [
        "anthropic/claude-sonnet-4.6",
        "google/gemini-3-flash"
      ],
      providerTimeouts: {
        byok: { openai: 15000 }
      }
    }
  }
});

Provider Timeoutsの公式仕様では、タイムアウト時にconfiguredTimeoutMsやerror: PROVIDER_TIMEOUTがメタデータに残ります。この証跡があると、後から「なぜ切り替わったか」を説明できます。BYOKは追加マークアップなしで使えますが、資格情報失敗時にシステム資格情報へ切替わるため、Gatewayクレジット残高も同時監視したほうが安心です。

ベンダーロックを避ける実践チェックリスト

最後に、ロックイン回避の運用手順です。ポイントは「いつでも他モデルへ逃げられる設計を、平常時から維持すること」です。障害が起きた日だけ切替テストをしても、実際には間に合わないことが多いです。切替手順は“非常時の手順書”ではなく“毎週の運用作業”として回すのがおすすめです。

1. 毎週月曜 — 代表プロンプト10本を3モデルで回し、品質差を記録します
2. 毎週木曜 — Fallback順序を1回だけ入れ替えて、復旧時間を測定します
3. 毎月末 — 生成ID上位20件のコストと遅延を棚卸しします
4. 四半期 — BYOK鍵管理とOIDC運用を監査し、不要権限を削減します

関連する運用記事として、Mac mini運用コストの実測まとめと、主要AIモデル比較も置いておきます。つまり、技術の切替だけでなく、事業側の意思決定までつなげると、異世界転生の価値が出ます。

監査ログを持たないまま1年運用すると何が起きるか

監査ログがない状態でマルチLLM運用を続けると、障害時に「どのモデルが」「どのリクエストで」「いくら使ったか」を追えなくなります。知らないままだと、再発防止より先に責任の所在探しが始まってしまい、改善速度が落ちる可能性があります。コスト増加も発見が遅れやすいので、気づいたときには予算超過というケースが起きやすいです。

この記事を書いている理由

僕自身、Mac mini M4 Pro（24GB）を24時間回して、Node.js + TypeScriptモノレポをtmux運用してきました。福祉事業のIT全般とAI×SaaS開発を並行していると、単発デモより「止めない運用」が重要だと毎回感じます。さらに、2025年に作った結婚式Web招待状サービスで90日以上の継続利用を作れた経験から、リリース後の監視と改善が成果を左右すると実感しました。僕自身がこの遠回りを経験したからこそ、同じところで詰まる人を減らしたいんです。

次のアクション

まずは今週中に、1つのAPIだけGateway化してGET /generationで監査ログを確認してみてください。結果をコメントで共有してもらえれば、次回はあなたのケースに合わせた切替順序まで具体化します。