Skip to content
Published on

Vercel AI SDK 6とAI Gatewayで作るマルチモデルアプリ: 2026実践ガイド

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

Vercel AI SDK 6とAI Gatewayで作るマルチモデルアプリ

2025年12月22日、Vercelは AI SDK 6 を公開した。このリリースは単なる更新ではない。2026年のエージェントアプリをどう設計するか、その前提を大きく変える内容だからだ。Agents、ToolLoopAgent、tool execution approval、human-in-the-loop approval、DevTools、full MCP support、reranking、image editing、stable structured outputs with tool callingが一つのリリースにまとまった意味は大きい。

同時に、AI Gatewayのモデル fallback ドキュメント は運用面の重要な動作を明文化している。ゲートウェイはまず primary model にリクエストを送り、そのモデルに対して provider routing のルールを適用する。もしそのモデルに使える provider がすべて失敗した場合は、models 配列の次のモデルを試す。最終的なレスポンスは、最初に成功した model と provider の組み合わせから返される。

つまり2026年のAIアプリでは、モデル単体の性能よりも、モデル選択と運用制御をどう設計するかが重要になる。

なぜ2026年はマルチモデル前提なのか

2026年に単一モデルだけで本番運用を支えるのは難しい場面が増えている。

  • モデルごとに推論品質、速度、コスト、マルチモーダル対応、tool calling の強みが違う
  • 同じようなユースケースでも provider ごとに可用性や遅延の差が出る
  • structured output、長いコンテキスト、ツール利用で capability mismatch が起きやすい
  • AIが主要導線に入ると、信頼性の問題がそのままプロダクトの問題になる

そのため本当に必要なのは「最高の1モデル」を選ぶことではなく、「リクエストの種類に応じて最適な経路を用意し、失敗時にきれいに切り替える」ことになる。

AI SDK 6がエージェント設計をどう変えたか

AI SDK 6では、エージェント型アプリに必要だった要素がかなり整理された。

  • Agents により再利用可能なエージェント定義を持ちやすくなった
  • ToolLoopAgent によりツール実行ループをより一貫して設計しやすくなった
  • tool execution approval と human-in-the-loop approval により危険な操作へ承認境界を置ける
  • DevTools によりツール実行やフローの観察がしやすくなった
  • stable な @ai-sdk/mcp パッケージで OAuth authentication、resources、prompts、elicitation を含む MCP が利用できる
  • tool calling と stable structured outputs を組み合わせやすくなり、UI とバックエンドの契約を強く保ちやすい
  • reranking と image editing により検索型やマルチモーダル体験の設計幅が広がった

要するに、中心は単なるモデル呼び出しではなく、エージェント境界とツール制御へ移っている。

実装しやすい基本アーキテクチャ

Next.js チームにとって現実的な出発点は次の3層だ。

  1. UI とストリーミングは Route Handler か Server Action で扱う
  2. アプリ側のモデル呼び出しは AI SDK 6 で統一する
  3. 可用性とルーティングは AI Gateway に任せる

こうしておくと、プロダクト固有のロジックはアプリに残しつつ、運用ポリシーをインフラ側へ段階的に寄せられる。

import { streamText } from 'ai';

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

  const result = streamText({
    model: 'openai/gpt-5.4',
    prompt,
    providerOptions: {
      gateway: {
        order: ['azure', 'openai'],
        models: [
          'anthropic/claude-sonnet-4.6',
          'google/gemini-3-flash',
        ],
      },
    },
  });

  return result.toUIMessageStreamResponse();
}

この構成のポイントは明快だ。

  • primary model は model に置く
  • backup model は providerOptions.gateway.models に置く
  • provider preference は order で管理する

fallback と provider routing は実際にどう動くのか

Vercel の公式ドキュメントに沿うと流れは次の通りだ。

  1. ゲートウェイはまず primary model にリクエストを送る
  2. そのモデルに対して provider routing ルールを適用する
  3. そのモデルで使える provider がすべて失敗したら次の fallback model を試す
  4. 最初に成功した model と provider の組み合わせのレスポンスを返す

ここで重要なのは、失敗の種類を一括りにしないことだ。provider outage、timeout、model capability mismatch は同じ failover を引き起こしても、設計上の意味は同じではない。

良い fallback 設計

  • 主モデルは品質重視
  • 第1 fallback は tool calling が安定したモデル
  • 第2 fallback は速度とコスト重視のモデル

避けたい設計

  • 機能前提が違うモデルを無造作に同じチェーンへ入れる
  • structured output の検証なしで結果を信用する
  • provider 障害と model 不一致をまったく同じ扱いにする

本番では、ベンチマーク評価より capability 単位で fallback チェーンを組む方が安全だ。

どんなときに human approval を必須にすべきか

AI SDK 6 の human-in-the-loop approval は、デモ用の安全機能ではなく運用上の境界線として考えるべきだ。

承認を基本にすべき操作は次のようなものだ。

  • 決済、返金、注文変更
  • データ削除、権限変更、本番デプロイ
  • CRM、ERP、チケット、会計システムへの書き込み
  • 顧客向けメールや通知の送信
  • セキュリティ上重要な内部ツール操作

逆に自動実行しやすいのは次のような作業だ。

  • 読み取り専用検索
  • 要約や下書き作成
  • low-risk な分類
  • キャッシュ可能な内部参照

実務では「誤実行されたときの後処理コストが高いか」で判断すると分かりやすい。

承認境界はモデルではなくツール側に置く

モデルが強くなったから承認を減らしてよい、という考え方は危険だ。むしろモデル品質が上がるほど、より強い権限を与えたくなるので、ツール層のポリシーがさらに重要になる。

実装しやすい定番パターンは次の通りだ。

  • read tool は自動承認
  • write tool は承認必須
  • high-risk tool はより厳格な承認
  • すべての承認イベントを監査ログに残す
const toolPolicy = {
  searchDocs: 'auto',
  readTicket: 'auto',
  updateTicketStatus: 'requires-approval',
  refundPayment: 'requires-approval',
  deployProduction: 'requires-approval',
} as const;

こうしたポリシーはプロンプトより長持ちする。モデルを入れ替えても運用原則を保てるからだ。

マルチモデル時代に MCP が重要な理由

AI SDK 6 で @ai-sdk/mcp が stable になったことで、MCP は試験的な接続方式ではなく、本番統合レイヤとして見る価値が高まった。OAuth authentication、resources、prompts、elicitation のサポートは特に大きい。

意味があるのは次の2点だ。

  • ツールやコンテキスト供給をモデル固有コードから分離しやすい
  • モデル選択が変わってもツール統合を安定させやすい

マルチモデル環境ではモデル入れ替えは普通に起きる。だからこそツール統合を安定させることが重要になる。

Next.js チーム向け導入チェックリスト

実運用を前提にするなら、まず次を確認したい。

1. リクエスト種別を早めに分ける

汎用チャット API に全部載せない方がよい。最低でも次の分類はほしい。

  • 一般的なアシスタント応答
  • 検索ベース回答
  • ツール実行タスク
  • 承認付き内部ワークフロー

2. structured output を先に決める

UI とサービスが期待する JSON 形状を先に定義すると、モデル差し替えコストが下がる。

3. fallback チェーンは capability 単位で組む

コストと速度だけでなく、次も見るべきだ。

  • tool calling の安定性
  • structured output の一貫性
  • image input 対応
  • コンテキスト長
  • provider availability

4. 承認ポリシーはサーバー側コードで管理する

承認判定をプロンプトの文章だけに任せない方が安全だ。

5. DevTools と本番テレメトリを両方使う

開発中は DevTools が役に立つ。本番では model、provider、failover、approval event をログとメトリクスに残したい。

6. 最適化の順番を間違えない

多くのチームでは次の順が安定しやすい。

  1. まず失敗せず応答できるようにする
  2. 次にツール利用を安全にする
  3. 次に structured output を安定させる
  4. 次にコストを予算内へ収める
  5. 最後に遅延を改善する

おすすめの導入パターン

現実的でバランスが良いのは次のような構成だ。

  • 顧客向けの読み取り系ワークフローでは自動 fallback と provider routing を使う
  • 内部の書き込み系ワークフローでは human approval を必須にする
  • 複雑なオーケストレーションは AI SDK 6 の agent 抽象で管理する
  • 外部システム統合ではまず MCP を検討する

この組み合わせは実装速度を落としすぎず、運用統制も保ちやすい。

まとめ

2026年のAIアプリで差がつくのは、最も派手なモデルを選ぶことではない。モデルや provider や実行条件が変わっても、プロダクト品質と運用統制を保てる構造を先に作れるかどうかだ。

AI SDK 6 はエージェント設計、ツール承認、MCP 統合をより実用的にし、AI Gateway はマルチモデル運用を明示的な runtime policy として扱いやすくしてくれる。Next.js アプリで長く運用するなら、この2つをセットで考える価値は大きい。

References

Discuss on Twitter • View on GitHub