Next.js on KnightLiブログ

Vercel AI SDK とは？TypeScript 開発者が AI アプリを構築するための統一ツールキット

Sun, 17 May 2026 23:07:38 +0800

vercel/ai は、Vercel がメンテナンスしているオープンソースの AI SDK です。

位置づけは明確です。TypeScript 開発者が AI アプリケーションや AI Agent を構築するための統一ツールを提供します。Next.js の背後にいるチームから生まれたものですが、Next.js 専用ではありません。React、Svelte、Vue、Angular などの UI フレームワークや、Node.js などのランタイムにも対応しています。

プロジェクト URL：https://github.com/vercel/ai

チャットアプリ、AI ライティングツール、RAG アプリ、ツール呼び出しを伴う Agent、ストリーミング出力 UI、複数のモデルプロバイダーをひとつのアプリに接続したいプロダクトを作っているなら、Vercel AI SDK は注目に値する基盤ライブラリです。

解決しようとしている中心課題

現在 AI アプリを作るとき、最大の悩みの一つは「モデルを呼べるか」ではありません。モデルプロバイダーごとに API、ストリーミング出力、ツール呼び出し、エラー処理、フロントエンドの状態管理が違うことです。

たとえば：

OpenAI には独自の SDK とレスポンス形式があります。
Anthropic には独自のメッセージ構造があります。
Google、xAI、Mistral、DeepSeek、Groq などもそれぞれ異なります。
ストリーミング出力では chunk の処理が必要です。
ツール呼び出しでは、モデルが発行する構造化リクエストを処理します。
チャット UI では、メッセージ、読み込み状態、キャンセル、再試行、エラー表示も管理する必要があります。

プロバイダーごとに手書きのアダプターを作ると、プロジェクトはすぐに複雑になります。

Vercel AI SDK の考え方は、こうした差異を統一 API の背後に収めることです。開発者はひとつのインターフェースでアプリを書き、Provider を通じて異なるモデルへ接続します。

統一 Provider アーキテクチャ

Vercel AI SDK の重要な特徴の一つは provider-agnostic、つまり特定のモデルベンダーに縛られないことです。

統一 API を通じて OpenAI、Anthropic、Google などのモデルプロバイダーにアクセスできます。プロジェクト README では、デフォルトで AI SDK が Vercel AI Gateway を使い、複数の主要 provider へアクセスしやすくすると説明されています。

これは実際の開発で役に立ちます。

多くの AI プロダクトは、最終的に一つのモデルだけには依存しません。

強い推論モデルが向くタスクがあります。
安価で高速なモデルが向くタスクがあります。
マルチモーダルが必要なタスクがあります。
長いコンテキストが必要なタスクがあります。
ローカルまたはプライベートなモデル展開が必要なタスクがあります。

統一 Provider アーキテクチャにより、モデル切り替え、段階的リリース、コスト制御、フォールバック戦略を作りやすくなります。

ストリーミング出力はフロントエンド体験の鍵

AI アプリと従来の API の大きな体験差の一つは、レスポンスが長くなりやすいことです。

ユーザーが完全な回答を待たなければならないと、チャットツール、ライティングツール、コードアシスタントは遅く感じられます。ストリーミング出力なら、テキストが少しずつ表示され、ユーザーは早く結果を確認できます。

Vercel AI SDK はストリーミング生成を比較的しっかり抽象化しています。開発者は低レベルのイベントストリームをゼロから処理する必要がなく、SDK の生成 API とストリーミング API を使ってモデル出力をフロントエンド UI に接続できます。

Next.js / React アプリでは特に便利です。

AI チャット UI は一見シンプルですが、実際には次のような処理が必要です。

メッセージ一覧。
ユーザー入力。
サーバーリクエスト。
ストリーミング token 表示。
読み込み状態。
エラー状態。
生成の中止。
再生成。

これらは AI SDK が開発者の反復作業を減らそうとしている領域です。

ツール呼び出しと Agent シナリオ

AI アプリが「会話」から「実行」へ進むにつれて、ツール呼び出しは重要になります。

モデルは自然言語を返すだけでなく、外部関数を呼ぶ必要があるかもしれません。

データベースを検索する。
ドキュメントを検索する。
業務 API を呼ぶ。
注文状態を読む。
グラフを生成する。
カレンダー予定を作成する。
プロジェクトファイルを変更する。

Vercel AI SDK はツール呼び出し関連の機能を提供し、開発者がツール、パラメータ、実行ロジックを定義し、モデルが適切なタイミングで呼び出しを要求できるようにします。

これが「チャット UI SDK」から「AI アプリと Agent のツールキット」へ広がっている理由の一つです。

ただし、ツール呼び出しを追加すれば終わりではありません。実際のプロジェクトでは次も考える必要があります。

パラメータ検証。
権限境界。
ツール呼び出しログ。
冪等性。
タイムアウトと再試行。
人間による確認。
センシティブ操作の制限。

AI SDK はインターフェースと流れを助けますが、安全境界は開発者が設計する必要があります。

UI 統合

Vercel AI SDK はフロントエンドフレームワークと相性がよい SDK です。

コアの生成 API だけでなく、チャット、補完、メッセージ状態、ストリーミング UI の抽象化も提供しています。Next.js と React を使うチームにとっては、多くのボイラープレートを減らせます。

ただし、Vercel へのデプロイ専用ではありません。

プロジェクトが TypeScript 技術スタックで構成されている場合、またはバックエンドが Node.js 環境で動いている場合、AI SDK はモデル呼び出しとストリーミング処理の層として使えます。Vercel にデプロイするかどうかは、アプリの構成、チームの習慣、インフラ選択によります。

Skill for Coding Agents

vercel/ai の README には興味深い提案もあります。Claude Code や Cursor などの coding agent を使っている場合、AI SDK skill をリポジトリに追加できます。

例のコマンドは次のとおりです。

`1`	`npx skills add vercel/ai`

これは、Vercel が AI SDK の利用者を人間の開発者だけでなく coding agent も含めて考えていることを示しています。

agent が AI SDK を使うプロジェクトを変更する場合、リポジトリ内に専用 skill があると、SDK の約束事、よく使う API、プロジェクト構造、ベストプラクティスをより理解しやすくなり、雑なコード変更を減らせます。

この方向性は注目に値します。

将来、オープンソースプロジェクトは README や docs だけでなく、AI coding agent 向けの構造化された skill 説明も提供するようになるかもしれません。複雑な SDK では、それが新しい開発者体験の入口になる可能性があります。

向いているプロジェクト

Vercel AI SDK は次のような場面に向いています。

Next.js / React ベースの AI チャットアプリ。
ストリーミング出力が必要なライティング、Q&A、サポート、コードアシスタント。
複数の model provider を接続する AI プロダクト。
RAG やドキュメント Q&A のプロトタイプを素早く作りたいチーム。
ツール呼び出し、関数呼び出し、軽量 Agent 機能が必要なアプリ。
TypeScript / Node.js 技術スタックを使っているチーム。

特にフロントエンド開発者とフルスタック開発者に向いています。多くの AI アプリで難しいのはモデル呼び出しだけではなく、モデル出力を安定し、滑らかで、対話的なプロダクト体験にすることだからです。

向いていない場面

プロジェクトの中心が Python バックエンド、深層学習の訓練、モデル微調整、低レベル推論サービスである場合、Vercel AI SDK は中心的なツールではないかもしれません。

これはアプリケーション層の SDK であり、モデル訓練フレームワークではありません。

必要なものが次のような場合は：

独自モデルを訓練する。
GPU 推論クラスターを管理する。
低レベルの batch inference を行う。
tokenizer、KV cache、量子化、推論エンジンを深く制御する。

PyTorch、vLLM、SGLang、TensorRT-LLM、llama.cpp、またはクラウド推論サービスを見るほうがよいでしょう。

Vercel AI SDK は「モデル能力をプロダクトへ接続する」ためのアプリケーション開発層に近い存在です。

使うときの注意点

第一に、統一 API を「完全に差異がない」と理解しないことです。

モデル provider ごとに、能力、コンテキスト長、ツール呼び出し形式、ストリーミングの細部、エラー型、課金方式は依然として異なります。統一 SDK は開発上の摩擦を減らしますが、モデル差を消すわけではありません。

第二に、コストを制御することです。

AI アプリが本番に出ると、ストリーミングチャット、再試行、ツール呼び出し、RAG 検索、複数モデルの fallback はすべて呼び出しコストを増やす可能性があります。レート制限、キャッシュ、ログ、予算監視が必要です。

第三に、安全境界を扱うことです。

モデルがツールを呼べるなら、そのツールが何をできるかを制限する必要があります。高リスク操作をモデルに直接実行させたり、秘密情報、データベース書き込み権限、本番操作をそのまま露出させたりしてはいけません。

第四に、可観測性を残すことです。

AI アプリで問題が起きたとき、フロントエンドのエラーだけでは足りません。ユーザー入力、選択されたモデル、ツール呼び出し、応答時間、token 消費、エラー種別、最終出力を把握する必要があります。

まとめ

vercel/ai は新しいモデルではなく、単なるチャットコンポーネントでもありません。

TypeScript AI アプリ開発のための基盤に近いものです。統一 Provider、ストリーミング出力、ツール呼び出し、フロントエンド状態管理、agent シナリオが一つのオープンソース SDK にまとまっています。

Next.js、React、TypeScript、Node.js をすでに使っているチームにとっては、「モデル API が動く」状態から「プロダクト体験として使える」状態までの開発コストを大きく下げられます。

ただし万能ではありません。モデル選択、権限設計、コスト制御、ログ監視、業務上の安全性は、依然として開発者が責任を持つ領域です。

モデルを訓練するのではなく AI アプリを作りたいなら、Vercel AI SDK は早めに試す価値のあるツールキットです。

参考資料

Next.js の高危険度 SSRF 脆弱性 CVE-2026-44578：影響範囲とアップグレード方針

Sun, 17 May 2026 17:27:13 +0800

Next.js は 2026 年 5 月、高危険度の SSRF 脆弱性 CVE-2026-44578 を公開しました。

GitHub / Vercel のセキュリティアドバイザリ GHSA-c4j6-fc7j-m34r と NVD の記録によると、この脆弱性は、内蔵 Node.js server を使い、悪意ある WebSocket upgrade リクエストを受け取れる状態にある自己ホスト型 Next.js アプリケーションに影響します。攻撃者はサーバーに任意の内部または外部宛先へリクエストを代理送信させ、内部サービスやクラウド metadata エンドポイントを露出させる可能性があります。

Vercel 上でホストされているデプロイは影響を受けません。修正バージョンは 15.5.16 と 16.2.5 です。

先に結論

自前サーバー、コンテナ、Kubernetes、ECS、VPS、ベアメタル、または自己管理 PaaS で Next.js を自己ホストしている場合は、優先的に確認してください。

影響を受ける範囲：

next >= 13.4.13 < 15.5.16
next >= 16.0.0 < 16.2.5

影響を受けない、またはリスクが低いケース：

Vercel にデプロイしているアプリケーション。
15.5.16、16.2.5、またはそれ以降へアップグレード済み。
内蔵 Node.js server を外部に公開していない構成。
リバースプロキシやロードバランサーで不要な WebSocket upgrade をすでに遮断し、アウトバウンドアクセスも制限している環境。

推奨対応順：

本番環境で実際に動いている next バージョンを確認する。
自己ホスト型アプリをできるだけ早く修正版へアップグレードする。
すぐにアップグレードできない場合は、リバースプロキシまたはロードバランサーで不要な WebSocket upgrade を遮断する。
アプリケーションサーバーからクラウド metadata、内部管理画面、機密性の高い内部サービスへのアクセスを制限する。
直近の異常な WebSocket upgrade リクエストと内部アクセスログを確認する。

脆弱性の内容

CVE-2026-44578 は Server-Side Request Forgery、つまり SSRF の脆弱性です。

SSRF の本質的なリスクは、攻撃者が内部システムへ直接アクセスするのではなく、あなたのサーバーに代理でリクエストを送らせる点にあります。サーバーは通常、内部ネットワーク、クラウド基盤、内部サービスに近い場所にあるため、代理として使われると、攻撃者が本来アクセスできないリソースに届く可能性があります。

今回の Next.js の問題は WebSocket upgrade の処理経路にあります。アドバイザリによると、内蔵 Node.js server を使う自己ホスト型アプリケーションでは、細工された WebSocket upgrade リクエストにより、サーバーが任意の内部または外部宛先へ代理アクセスする可能性があります。

リスクのある対象は次のようなものです。

内部 HTTP サービス。
管理画面。
クラウド metadata アドレス。
コンテナまたはクラスタ内部のサービス。
サーバーからのみアクセスできる内部 API。

この脆弱性の CVSS v3.1 スコアは 8.6 High で、ベクトルは次の通りです。

`1`	`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N`

これは、ネットワーク経由で攻撃可能、攻撃複雑度は低く、権限もユーザー操作も不要で、主に機密性に影響することを意味します。

自己ホストが危険になりやすい理由

今回のアドバイザリは、Vercel-hosted deployments are not affected と明記しています。

重点的に見るべきなのは自己ホスト型デプロイです。理由は単純で、自己ホスト環境のネットワーク構成はさまざまだからです。origin server を直接公開しているものもあれば、Nginx、Traefik、Ingress、Cloudflare、ALB、自前ゲートウェイの背後にあるものもあります。クラウド VM、コンテナネットワーク、Kubernetes クラスタで動く場合もあります。

これらの環境でアウトバウンドアクセスが制限されていない場合、Next.js プロセスは次のものに到達できる可能性があります。

169.254.169.254 のようなクラウド metadata アドレス。
プライベート IP 範囲。
VPC 内だけで公開されているサービス。
Redis、Elasticsearch、Prometheus、Grafana などの内部コンポーネント。
Kubernetes Service、Pod、管理エンドポイント。

つまり SSRF の危険性は Next.js だけで決まるものではありません。その Next.js サーバーがいるネットワークから何にアクセスできるかで決まります。

影響を受けるか確認する方法

最初に next のバージョンを確認します。

プロジェクトディレクトリで実行します。

`1`	`npm ls next`

または：

`1`	`pnpm why next`

直接確認することもできます。

cat package.json
cat package-lock.json
cat pnpm-lock.yaml
cat yarn.lock

バージョンが次の範囲に入る場合は対応が必要です。

1
2

>= 13.4.13 < 15.5.16
>= 16.0.0 < 16.2.5

次に、デプロイ方式を確認します。

特に注意すべき構成：

next start で本番サービスを起動している。
カスタム Node.js server で Next.js をホストしている。
Docker イメージ内で Next.js server を直接起動している。
Kubernetes / ECS / VPS / ベアメタルで自己ホストしている。
リバースプロキシの背後にある Next.js origin がなお到達可能。
アプリケーションのネットワークから内部サービスやクラウド metadata にアクセスできる。

アプリケーションが Vercel にデプロイされている場合、この脆弱性の影響は受けないと公式アドバイザリは述べています。ただし、同じリリース群に他の修正が含まれる可能性があるため、Next.js は常に更新しておくべきです。

どのバージョンへ上げるべきか

公式の修正バージョンは次の通りです。

15.5.16
16.2.5

アップグレード例：

`1`	`npm install next@15.5.16`

16.x を使っている場合：

`1`	`npm install next@16.2.5`

pnpm：

`1`	`pnpm add next@15.5.16`

または：

`1`	`pnpm add next@16.2.5`

アップグレード後、再ビルドしてリリースします。

1
2

npm run build
npm run start

または、CI/CD に沿って Docker イメージを再ビルドし、再デプロイしてください。

プロジェクトが 14.x または 15.x に固定されている場合、この修正のためだけに慌てて 16.x へメジャーアップグレードする必要はありません。まず 15.5.16 の修正ラインへ上げ、テストとリリースを完了し、その後でメジャーバージョン移行を計画するほうが安全です。

一時的な緩和策

すぐにアップグレードできない場合、アドバイザリの中心的な方針は次の通りです。origin server を信頼できないネットワークに直接公開しないこと。WebSocket upgrade が不要ならリバースプロキシまたはロードバランサーで遮断すること。そして可能な限り origin のアウトバウンドアクセスを制限することです。

検討できる緩和策：

Next.js origin server を直接公開しない。
Nginx、Ingress、ALB、Cloudflare などの入口層で不要な WebSocket upgrade をフィルタする。
業務で WebSocket を使っていない場合、upgrade セマンティクスを持つリクエストを拒否する。
アプリケーションサーバーに egress 制限をかけ、クラウド metadata アドレスと機密性の高い内部ネットワークへのアクセスを禁止する。
クラウド基盤が提供するより安全な metadata アクセス方式、たとえば token 必須の metadata サービスを有効化する。
管理画面、データベース、キャッシュ、監視システムに認証とネットワーク分離を追加する。

リバースプロキシ規則は一時的な緩和策であり、アップグレードの代替ではありません。フレームワークの脆弱性は最終的に修正版で解決すべきです。

運用上の確認ポイント

この脆弱性は主に機密性に影響するため、確認の中心は「内部リソースへのアクセスに使われたか」です。

確認すべきもの：

Web アクセスログ中の異常な Upgrade、Connection、Host、パス、送信元 IP。
リバースプロキシまたはロードバランサーの異常な WebSocket upgrade ログ。
Next.js サービス周辺の異常なアウトバウンド接続。
クラウド metadata サービスへのアクセスログや認証情報の使用記録。
内部管理サービス、監視システム、キャッシュ、検索サービスへの異常アクセス。
IAM 一時認証情報、アクセスキー、token の異常使用。
コンテナまたはホスト上の不審なプロセス、ダウンロード、横展開の痕跡。

悪用が疑われる場合：

ログと証跡を保全する。
露出した可能性のあるクラウド認証情報、API key、データベースパスワード、session secret をローテーションする。
クラウドアカウントの直近 API 呼び出しを確認する。
内部サービスのアクセス記録を確認する。
影響を受けたコンテナまたはホストを再構築する。
egress 制御と metadata 保護を再確認する。

React/Next.js RCE とは別の問題

混同しやすい点として、CVE-2026-44578 は Next.js WebSocket upgrade SSRF であり、以前の React Server Components 関連 RCE ではありません。

この問題の中心は、攻撃者が指定した内部または外部アドレスへサーバーにリクエストを送らせることです。主なリスクは情報漏えいと内部リソースの探索です。

一方、React Server Components 関連の RCE はコード実行リスクであり、影響や修正範囲が異なります。

そのため「Next.js に脆弱性がある」という大見出しだけで判断せず、具体的な CVE、影響バージョン、デプロイ方式、修正バージョンを対応させる必要があります。

優先対応すべきチーム

最優先で対応すべき環境：

自己ホスト型 Next.js 本番サイト。
クラウド VM、コンテナ、Kubernetes、内部ネットワークで動作する環境。
アプリケーションサーバーがクラウド metadata サービスへアクセスできる環境。
アプリケーションサーバーが内部管理画面、データベース、キャッシュ、監視システムへアクセスできる環境。
next start origin server を直接公開している環境。
古い next を使っており、アップグレード担当が明確でない環境。

相対的に優先度が低い環境：

完全に Vercel へデプロイされているアプリケーション。
すでに修正版へアップグレード済みのアプリケーション。
origin server が直接公開されておらず、入口層で不要な WebSocket upgrade を遮断している環境。
アウトバウンドネットワークが厳格に制御され、機密性の高い内部リソースへ到達できない環境。

ただし「優先度が低い」は「アップグレード不要」という意味ではありません。Next.js は露出度の高いフレームワークであり、古いバージョンを長く使うほどリスクは積み上がります。

開発チーム向けチェックリスト

次のチェックリストで対応できます。

すべてのリポジトリの next バージョンを確認する。
Vercel プロジェクトだけでなく、すべての自己ホスト型デプロイを洗い出す。
next start または内蔵 Node.js server を使うサービスを特定する。
15.5.16、16.2.5、またはそれ以降へアップグレードする。
本番イメージを再ビルドして公開する。
入口層で不要な WebSocket upgrade を遮断する。
アプリケーションサーバーからクラウド metadata と機密性の高い内部ネットワークへのアクセスを制限する。
直近の異常な upgrade リクエストとアウトバウンドアクセスを確認する。
露出した疑いのある認証情報をローテーションする。
Next.js のセキュリティ更新を依存関係更新プロセスに組み込む。

まとめ

CVE-2026-44578 は、真剣に対応すべき Next.js の高危険度 SSRF 脆弱性です。

Vercel ホストのデプロイには影響しませんが、自己ホスト型 Next.js アプリには広く影響します。対象は 13.4.13 から 15.5.16 未満、そして 16.0.0 から 16.2.5 未満です。トリガーは WebSocket upgrade の処理経路であり、攻撃者はサーバーに内部または外部アドレスへ代理アクセスさせ、内部サービスやクラウド metadata エンドポイントを露出させる可能性があります。

直接的な修正は 15.5.16 または 16.2.5 へのアップグレードです。一時緩和としては、origin server を直接公開しないこと、不要な WebSocket upgrade を遮断すること、アプリケーションサーバーのアウトバウンドアクセスを制限することが挙げられます。

運用チームにとって重要なのは CVE スコアだけではありません。あなたの Next.js サーバーが、そのネットワーク位置から何にアクセスできるかです。SSRF の実際の影響は、サーバーの背後にある内部リソースとクラウド権限に左右されます。

参考リンク：