OpenAI Responses API移行とClaude/Gemini切替手順

「OpenAIの実装を新APIへ切り替えたいけど、本番を止めるのが怖い」「ClaudeやGeminiにも逃がせる構成にしたい」。そんなチームに向けて、2026年3月時点の実装手順を1本にまとめました。この記事を読むと、OpenAI Responses API移行の最短ルートと、Vercel AI Gatewayを使った安全なモデル切り替え設計がそのまま再現できます。福祉事業のIT全般とAI×SaaSの両方で運用設計を担当する僕が、本番寄りの観点で解説します。

OpenAI Responses API移行が2026年3月に現実的な優先課題になった理由

2026年3月12日時点で、OpenAI公式の移行ガイドは、新規開発の中心をResponses APIに置く方針をはっきり示しています。Chat Completionsがすぐ消えるわけではないですが、今後の機能追加はResponses側に集約される流れです。つまり「動いているから放置」だと、あとで一気に改修コストが跳ねる可能性が高いです。

判断材料として数字も出ています。OpenAIの案内では、reasoning modelsを含むResponses利用でSWE-benchが同条件比で+3%改善、さらに内部テストでキャッシュ効率が40%〜80%改善したとされています。派手な宣伝として受け取るより、同じプロンプト資産でも運用設計しだいで改善余地がある、と捉えるのが実務的です。

非エンジニア向けに例えると、古い券売機のまま駅を運営する状態に近いです。今日の乗客はさばけても、新しい決済手段が増えるたびに現場で困りますよね。API移行も同じで、早めに土台を替えるほど現場がラクになります。

最短移行手順｜chat.completionsからresponsesへ差し替えるチェックリスト

ここは実装の最短ルートです。マルチモーダルや複雑なFunction Callingをまだ使っていないチームなら、段階移行で十分進められます。まずはエンドポイント置換とレスポンスの受け取り方だけを変えるのがおすすめです。

1. SDK更新 — OpenAI SDKをResponses対応版へ上げます
2. 呼び出し変更 — chat.completions.create を responses.create に置換します
3. 出力参照変更 — 文字列参照を output_text 中心に寄せます
4. 構造化出力修正 — response_format から text.format.json_schema に寄せます
5. ログ拡張 — model/provider/latency/costを同時記録します
6. 段階リリース — 一部トラフィックから切り替えて検証します

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.OPENAI_API_KEY,
});

const res = await client.responses.create({
  model: "gpt-4.1-mini",
  input: "要点を3行でまとめて",
});

console.log(res.output_text);

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

const res = await client.responses.create({
  model: "gpt-4.1-mini",
  input: "ユーザー情報をJSONで返して",
  text: { format: { type: "json_schema", name: "user_profile", schema } }
});

Vercel AI Gateway 使い方｜baseURL変更だけでClaude/Geminiへ切り替える

2026年3月6日にVercelがResponses API直接対応を公開して、同じOpenAI SDKのままGateway経由に乗せやすくなりました。Vercel公式ドキュメント（最終更新2026-03-12）でも、StreamingやTool、Structured Outputをprovider/model形式で統一的に扱えます。

実装のコアはbaseURLとmodelだけです。この2点を環境変数で外出ししておくと、OpenAI固定構成からマルチLLM構成へほぼノーリスクで広げられます。利用者体験を変えずに、裏側の運用柔軟性だけ上げられます。

import OpenAI from "openai";

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

const model = process.env.LLM_MODEL ?? "anthropic/claude-sonnet-4.6";

const res = await client.responses.create({
  model,
  input: "障害報告を150文字で要約して",
});

console.log({ model, text: res.output_text });

Claude Gemini モデル切り替えの安全設計｜FallbackとProvider Order

モデル切り替えは「切り替えられる」だけだと不十分です。本番で必要なのは、失敗時にどの順番で逃がすかを事前に決めておくことです。Vercel AI GatewayはproviderOptions.gateway.modelsでフォールバック順序を指定でき、orderで同一モデル内のプロバイダ優先度も制御できます。障害対応を人力オペレーションにしないことが、運用の分かれ目です。

const res = await client.responses.create({
  model: "anthropic/claude-sonnet-4.6",
  input: "問い合わせ文を分類して",
  providerOptions: {
    gateway: {
      models: [
        "anthropic/claude-sonnet-4.6",
        "google/gemini-3-flash"
      ],
      order: ["azure", "openai"]
    }
  }
});

さらにタイムアウトを短めに切って再試行回数を管理すると、体感遅延を抑えやすいです。僕の現場では「1回目2〜3秒、2回目は別モデルで即再実行」で運用しています。

セキュリティとガバナンス実装｜API Key/OIDC、ZDR、BYOK境界

ここは見落としやすいですが、実務では最重要です。まず認証はAPIキーとOIDCの2系統があります。OIDCトークンは12時間で期限切れになるので、ローカル開発ではvercel env pullの更新運用が必要です。しかもOpenResponses互換APIでは、APIキーとOIDCを同時指定するとAPIキーが優先されます。無効なAPIキーでも優先される仕様なので、併用運用は事故の温床になります。

• 認証方針 — 環境ごとにAPIキーかOIDCのどちらか1つに固定します
• ZDR方針 — 個人情報を扱う経路はzeroDataRetention: trueを必須化します
• 失敗時挙動 — ZDR適合先がない場合、400 / no_providers_availableで失敗する前提でUIを設計します

const res = await client.responses.create({
  model: "anthropic/claude-sonnet-4.6",
  input: "この文章の個人情報をマスクして",
  providerOptions: {
    gateway: {
      zeroDataRetention: true,
      models: [
        "anthropic/claude-sonnet-4.6",
        "google/gemini-3-flash"
      ]
    }
  }
});

この章は地味ですが、非IT業界と連携する案件ほど重要です。監査説明で詰まらないように、仕様を先に文章化しておくと後工程が助かります。

運用で失敗しない監視とコスト最適化｜provider metadata設計

移行後に成果を出せるかは、監視設計でほぼ決まります。最低限、provider model latency_ms input_tokens output_tokens estimated_costを1リクエスト単位で残してください。これだけで「どのモデルが速くて安定しているか」が見えます。切り替え機能より、切り替え判断の根拠を作るほうが価値が高いです。

2026年3月時点のVercel Modelsカタログでは、anthropic/claude-sonnet-4.6は0.7s・54tps・入力$3.00/M・出力$15.00/M、google/gemini-3-flashは1.0s・172tps・入力$0.50/M・出力$3.00/Mです。大量処理はGemini、難しい推論はClaudeという使い分けが現実的でした。

品質面はPromptfooなどで回帰評価を自動化すると安全です。評価セットで週次チェックするだけでも事故は減ります。運用テンプレートが必要なら、XのDM相談で監視項目の設計例を共有しています。

移行設計を先送りしたまま半年進むと起きること

移行を後回しにすると、最初は困らなくても半年後に一気にしんどくなります。理由はシンプルで、機能追加と障害対応が旧実装に積み上がって、切替時の差分が読めなくなるからです。特に認証とFallbackを未整備のまま運用すると、障害時に「どの鍵で、どのモデルに、なぜ切り替わったか」が追えません。この情報を知らないままだと、止められない夜間対応が増える可能性があります。今のうちに小さく移行しておくのが結果的にラクです。

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

僕はMac mini M4 Proを24時間動かしながら、Node.js+TypeScriptのモノレポで複数LLMの切替検証を回しています。2026年3月11日にも、Gatewayとローカル運用を組み合わせた冗長化手順を検証しました。さらに、ITを非IT領域へ持ち込む異世界転生の実務として、福祉事業のIT全般とAI×SaaS実務を並行しているので、認証・権限・監査を無視した「動けばOK」の設計が本番でどれだけ危ないかを何度も見てきました。僕自身がその失敗と改善を経験してきたからこそ、今日から使える形で共有したいんです。

次のアクション

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