Next.js16.2でVercel AI Gateway自動切替実装

「マルチLLM フォールバックを入れたいけど、設定が多くて止まる」という人に向けて書きました。この記事では、Next.js 16.2環境でVercel AI Gatewayを使い、MiniMax M2.7とClaudeを自動切替する実装を、今日そのまま試せる粒度でまとめます。品質とコストのバランスを崩さずにAI API コスト最適化したい人には、かなり実務寄りの内容です。

2026年3月時点で押さえる前提：Next.js 16.2とAI Gatewayの組み合わせ

Next.js 16.2の公式リリース（2026年3月18日）では、next dev起動の高速化やレンダリング改善、next start --inspect対応など、開発と運用の両方で効く改善が入っています。さらにVersion 16アップグレードガイドでは、Node.js 20.9.0以上が前提になっているので、まずここを揃えるのが第一歩です。

Vercel AI Gateway公式ドキュメントでは、単一エンドポイントで多数モデルを扱え、予算管理・利用監視・負荷分散・フォールバック管理ができると明記されています。つまり、アプリ側で「毎回どのプロバイダを叩くか」を細かく書かなくても、運用の重心をGatewayに寄せられるということです。

結論として、Next.js 16.2の開発体験向上と、AI Gatewayのルーティング機能は相性がかなり良いです。 1つのRoute Handlerで品質と可用性を同時に取りにいけるからです。

• 実装コスト — providerOptions.gatewayでフォールバックを宣言できます
• 運用コスト — どのモデル/プロバイダが使われたかをメタデータで追跡できます
• 障害耐性 — 主モデル失敗時にバックアップへ自動遷移できます

MiniMax M2.7とClaudeをどう分担するか：数字で決める

モデル選定は、好みより先に数字で決めるほうが早いです。AI Gateway Models一覧（2026年3月末時点）を見ると、minimax/minimax-m2.7とanthropic/claude-sonnet-4.6は、価格と速度の性格がはっきり違います。

コスト優先ならMiniMax M2.7、応答速度と長文コンテキスト重視ならClaudeという分担が組みやすいです。なので実務では「M2.7を主系、Claudeを品質バックアップ」にする設計が扱いやすいです。ここは公式仕様というより、僕の運用経験ベースの判断ですが、非IT業界向けのチャット導入でもこの分け方が説明しやすく、チーム合意が取りやすいです。

• 一次応答 — M2.7でコストを抑えながら広くさばきます
• 失敗時フォールバック — Claudeで可用性と品質を担保します
• 高難度処理 — 要件に応じて最初からClaude固定ルートを用意します

Next.js 16.2でマルチLLM フォールバックを実装する手順

ここからは実装です。AI SDKのmodelに主モデル、providerOptions.gateway.modelsにバックアップモデルを入れると、自動切替が動きます。Model Fallbacks公式でも同じ構成が案内されています。

1. 環境変数を設定 — AI_GATEWAY_API_KEYを.env.localに入れます
2. Route Handlerを作成 — 主モデルとフォールバックを宣言します
3. プロバイダ順を指定 — orderでClaude側の優先接続先を決めます

# .env.local
AI_GATEWAY_API_KEY=your_api_key_here

// app/api/chat/route.ts
import { streamText } from 'ai';

export const maxDuration = 30;

export async function POST(request: Request) {
  const { prompt }: { prompt: string } = await request.json();

  const result = streamText({
    model: 'minimax/minimax-m2.7',
    prompt,
    providerOptions: {
      gateway: {
        models: ['anthropic/claude-sonnet-4.6'],
        order: ['anthropic', 'vertex'],
        caching: 'auto',
      },
    },
  });

  return result.toUIMessageStreamResponse();
}

このコードのポイントは、主系モデルはmodel、バックアップはmodelsに分けることです。 フォールバックの評価順は、公式どおり「主モデル→models配列の先頭から順番」です。さらにorderで各モデルの接続先プロバイダ優先順位をコントロールできます。

AI API コスト最適化：フォールバック込みで月額を先に見積もる

AI API コスト最適化は、導入後に悩むより、導入前にざっくり計算したほうが安定します。ここでは「1リクエストあたり入力700トークン、出力300トークン、1日10,000リクエスト」で試算します。価格は先ほどのモデル一覧を使います。

1. M2.7単独 — 約$0.00057/req → 約$5.7/日 → 約$171/月
2. Claude単独 — 約$0.0066/req → 約$66/日 → 約$1,980/月
3. M2.7 90% + Claude 10% — 約$0.001173/req → 約$11.73/日 → 約$351.9/月

// 単純試算（USD）
const reqPerDay = 10000;
const m27 = 0.00057;   // M2.7
const claude = 0.0066; // Claude Sonnet 4.6
const mixed = m27 * 0.9 + claude * 0.1;

console.log({
  m27Month: reqPerDay * m27 * 30,
  claudeMonth: reqPerDay * claude * 30,
  mixedMonth: reqPerDay * mixed * 30,
});

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

「まず概算を置く→実測で補正する」の順にすると、コスト事故が起きにくいです。

運用でハマりやすいポイントとデバッグ手順

実装より運用で詰まることが多いので、僕が最初に確認する項目を共有します。特にマルチLLM フォールバックでは、挙動を「感覚」ではなく「ログ」で見るのが大事です。

• Provider Metadata確認 — どのモデル/プロバイダで成功したかを毎回追跡します
• フォールバック順確認 — modelとmodelsの順が意図どおりかをテストします
• プロバイダ順確認 — orderとonlyの組み合わせを見直します
• 遅延確認 — P95/P99でM2.7とClaudeを比較して閾値を決めます
• 本番デバッグ — Next.js 16.2のnext start --inspectでCPU/メモリを確認します

// デバッグ時のみ
console.log(JSON.stringify(await result.providerMetadata, null, 2));

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

参考にした公式ドキュメント

• Next.js 16.2 リリースノート
• Next.js Version 16 アップグレードガイド
• Vercel AI Gateway 概要
• Model Fallbacks
• Provider Options
• Provider Filtering & Ordering
• AI Gateway Models 一覧
• AI SDK: Choosing a Provider

マルチLLM設計を後回しにしたときに起きやすいこと

単一モデルのまま運用すると、平常時は問題なくても障害時に一気に止まる可能性があります。特に社内業務や顧客対応フローにAIを組み込んでいる場合、止まる時間そのものが機会損失になります。 「あとで入れよう」と思っているうちに、データ量と依存先が増えて、切替導入の難易度が上がりやすいです。

• 可用性リスク — 1プロバイダ障害がそのままサービス停止につながります
• コストリスク — 高単価モデル固定で、気づいたら月額が膨らみます
• 運用リスク — ログ設計がないまま障害対応に入って、原因特定が遅れます

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

僕自身、SESで開発だけをしていた時期から、人材育成で550名以上と対話する時期、そして今の福祉事業のIT全般を担う立場まで経験してきました。その中で痛感したのは、「いい技術」だけでは現場は回らず、「説明できる設計」が必要ということです。

AI導入は特にその傾向が強いです。だからこそ、実装コードだけで終わらず、コスト・運用・説明までつながる形で共有したいと思ってこの記事を書いています。僕自身が現場で何度も遠回りしたので、その遠回りを減らしてほしいんです。

次のアクション

実装したら、次は「計測」と「改善」です。 もし詰まったらコメントやDMで教えてください。次回は、onlyとBYOKを使った組織向け構成も解説します。