vercel/ai とは何ですか？

AI SDK は TypeScript 向けのプロバイダ非依存ツールキットで、テキスト生成からツール呼び出し型エージェント、UI フックまでを一つの API にまとめる。判断の分かれ目は抽象化の便利さではなく、ai@5、ai@6、ai@7 が同時にリリースされている運用コストのほうにある。

vercel/ai は商用利用できますか？

まず確認が必要です。このリポジトリのライセンスは自動分類の対象外なので、商用利用の前に LICENSE ファイルを読んでください。

vercel/ai は今もメンテナンスされていますか？

されています。直近 1 日以内に新しいコミットがあります。

vercel/ai はどのプログラミング言語で書かれていますか？

主に TypeScript です（GitHub の言語統計による）。

vercel/ai (AI SDK) レビュー: 抽象化の範囲とバージョン並行運用のコスト

ひと目でわかる

これは何？: AI SDK は TypeScript 向けのプロバイダ非依存ツールキットで、テキスト生成からツール呼び出し型エージェント、UI フックまでを一つの API にまとめる。判断の分かれ目は抽象化の便利さではなく、ai@5、ai@6、ai@7 が同時にリリースされている運用コストのほうにある。
誰に向いている？: すでに Next.js か React、Svelte、Vue のいずれかで画面を持ち、複数プロバイダを切り替えながらテキスト生成とツール呼び出しを同じ書き味で扱いたいチームには向く。逆に、単一プロバイダしか使わず、その SDK の新機能を最速で追いたい場合や、Node.js 22 未満の実行環境しか用意できない場合は選ぶ理由が薄い。
商用利用できる？: まず確認が必要です。このリポジトリのライセンスは自動分類の対象外なので、商用利用の前に LICENSE ファイルを読んでください。
今もメンテナンスされている？: されています。直近 1 日以内に新しいコミットがあります。
何の言語で書かれている？: 主に TypeScript です（GitHub の言語統計による）。

回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。

オープンソース詳細解説

Hysen Labs 編集部 · 2026年9月10日 · vercel/ai

誰のためのライブラリか、README が想定する利用者像

README は AI SDK を「provider-agnostic TypeScript toolkit」と説明し、Next.js、React、Svelte、Vue、Angular といった UI フレームワークと、Node.js のようなランタイムを対象に挙げている。つまり対象は、モデル呼び出しのコードをサーバー側に書き、その結果を画面に流し込むところまでを一人で、あるいは小さなチームで担当する開発者だ。CLI ツールやバッチ処理だけを書きたい人に向けたものではない。

問題設定は「プロバイダごとに SDK の呼び出し方が違う」ことに集約される。OpenAI、Anthropic、Google それぞれのパッケージを直接使えば、モデル名、メッセージ形式、ツール定義、ストリーミングの扱いが別々になる。AI SDK はそこを generateText や ToolLoopAgent という共通の入口に寄せる。README が示す例では、model に 'anthropic/claude-opus-4.6' のような文字列を渡すだけでよく、プロバイダ固有の import は不要とされている。

モデル文字列と @ai-sdk/* パッケージ、二つの接続経路

接続経路は README 上で二つに分かれている。一つは Vercel AI Gateway 経由で、これは既定の動作だと書かれている。model に 'openai/gpt-5.4' や 'anthropic/claude-opus-4.6' のようなプロバイダ名つきの文字列を渡すだけで、主要プロバイダに到達できる。もう一つは @ai-sdk/openai、@ai-sdk/anthropic、@ai-sdk/google といったパッケージを個別にインストールし、anthropic('claude-opus-4-6') のようにプロバイダ関数へモデル ID を渡す経路だ。

この二経路の違いは抽象化の層がどこにあるかである。文字列方式ではモデルの解決とルーティングがゲートウェイ側に寄り、アプリケーションコードはモデル名の文字列だけを知る。パッケージ方式ではプロバイダの SDK が依存ツリーに入り、認証情報も自分の環境で管理する。README はどちらが推奨かを明示していない。既定がゲートウェイである点だけが事実として書かれている。ここは設計上のトレードオフで、ゲートウェイを挟めば切り替えは楽になるが、経路にもう一段の依存が増える。

Output.object によるスキーマ拘束と、Zod 依存の意味

構造化データの生成は Output.object と Zod スキーマの組み合わせで示されている。generateText の戻り値から output を取り出し、recipe.name、recipe.ingredients、recipe.steps といった形へ型がつく。README の例ではレシピ生成が使われているが、要点はモデルの自由文をアプリケーションが扱える形へ落とす部分をライブラリ側が担うことにある。

注意したいのは、スキーマを渡してもモデルが必ずその形を守る保証は README からは読み取れない点だ。Zod は TypeScript の型と実行時の検証を与えるが、モデル側の出力がスキーマに合わなかったときに何が起きるかは、この資料には書かれていない。構造化出力を業務データの登録に使うなら、そこは公式ドキュメントの該当ページを自分で確認する必要がある。

ToolLoopAgent とエージェント UI メッセージの型推論

エージェントは ToolLoopAgent クラスで表現される。README の例では model、system、tools を渡し、tools の中に openai.tools.localShell のようなプロバイダ提供のツールを置く。execute の中では action.command を分解し、サンドボックス上でコマンドを実行して stdout を返す、という流れが示されている。つまりツールの実体は開発者が書き、ループの制御をライブラリが持つ構造だ。

UI 側との接続も型でつながる。InferAgentUIMessage でエージェントからメッセージ型を導出し、useChat にその型引数を与える。サーバー側は createAgentUIStreamResponse に agent と messages を渡すだけで、ストリームの整形はライブラリが担う。UI コンポーネント側は UIToolInvocation を受け取り、invocation.state が 'input-available' か 'output-available' かで表示を分岐させる。ツール呼び出しの進行状態がメッセージの part として届くため、画面側は状態機械を自前で持たなくてよい。

ここは README の構成の中で最も具体的な部分であり、同時に最も結合が強い部分でもある。メッセージの part 構造に UI が依存するため、この形が変わればコンポーネントの switch 文も書き換えになる。

セットアップ手順と、Node.js 22 という前提

導入は npm install ai から始まる。UI フックを使う場合はフレームワーク別のパッケージが必要で、React なら npm install @ai-sdk/react を追加する。プロバイダを直接叩くなら @ai-sdk/openai、@ai-sdk/anthropic、@ai-sdk/google を個別に入れる。README が前提として挙げるのは Node.js 22 以上と npm または同等のパッケージマネージャで、これは他の条件より先に確認すべき制約だ。

もう一つ、README はコーディングエージェント向けのスキル追加として npx skills add vercel/ai を挙げ、Claude Code や Cursor を使う場合に推奨すると書いている。プロジェクトの API をエージェントに把握させるための手順で、ライブラリ本体の動作には関係しない。設定キーという形のものは README にはほとんど現れず、モデル名の文字列、Output.object に渡す schema、ToolLoopAgent の system と tools が実質的な設定面である。

ai@5、ai@6、ai@7 が同日にリリースされている事実

リポジトリ情報で目を引くのは、2026-09-09 に ai@7.0.95、ai@6.0.279、ai@5.0.254 の三つが同じ日にリリースされている点だ。パッチ番号だけが違うのではなく、メジャーが三つ並行して更新され続けている。これは長期サポートの姿勢を示す一方で、利用側にとっては「どのメジャーに乗るか」を最初に決める必要があることを意味する。

抽象化ライブラリでは、メジャー間で API の形が変わることがある。README のコード例がどのメジャーを前提にしているかは、この資料からは判別できない。generateText や ToolLoopAgent の例がそのまま動くとは限らないので、導入時は自分の package.json が解決する ai のバージョンを確認し、それに対応するドキュメントを読む必要がある。プロバイダパッケージ側の対応バージョンも別途確認が要る。ここは見落としやすい。

抽象化が邪魔になる場面と、直接 SDK を使う選択

比較対象として素直なのは、プロバイダ公式の SDK を直接使う構成だ。例えば @ai-sdk/openai ではなく OpenAI の公式 Node ライブラリを直接呼べば、そのプロバイダが追加した新機能、新しいパラメータ、実験的な API を待たずに使える。AI SDK の統一インターフェースは、複数プロバイダの差分を吸収する代わりに、各プロバイダ固有の機能を共通の形へ写す作業を挟む。

したがって、単一プロバイダしか使わず、その最新機能を追いかけることが競争力になるプロダクトでは、抽象化の利得より追随の遅れが上回りうる。逆に、開発中は安いモデルで試し、本番は別のプロバイダに切り替える、という運用を想定するなら、model の文字列を差し替えるだけで済む構成は保守の手数を減らす。判断はプロバイダをまたぐ予定があるかどうかで決まる。

ライセンス表記とメンテナンス費用の見積もり方

リポジトリのライセンスは NOASSERTION と記録されており、これは自動判定が標準的な SPDX 識別子に落ちなかったことを示す。具体的な条件はリポジトリのライセンスファイルを直接読む必要がある。ここから先は法務判断ではなく、確認手順の話として、依存を固定する前にライセンス本文と、プロバイダパッケージ側のライセンスを並べて確認しておきたい。

メンテナンス費用で最大の変数は、先に触れたメジャー並行運用だ。ai のメジャーを上げる際は、generateText の戻り値、Output.object の扱い、ToolLoopAgent と UI メッセージの part 構造という、アプリケーションの中心に触れる箇所をまとめて見直すことになる。逆にパッチ更新は頻繁に出ているが、これは修正が継続しているという事実であって、互換性が保証されているという意味ではない。バージョン範囲の指定は慎重に決めるべきで、^ で自動追随させるか、メジャーを固定するかは、エージェント UI を本番に出しているかどうかで変わる。

編集部の結論

すでに Next.js か React、Svelte、Vue のいずれかで画面を持ち、複数プロバイダを切り替えながらテキスト生成とツール呼び出しを同じ書き味で扱いたいチームには向く。逆に、単一プロバイダしか使わず、その SDK の新機能を最速で追いたい場合や、Node.js 22 未満の実行環境しか用意できない場合は選ぶ理由が薄い。導入前に確認すべきは、自分の依存ツリーが ai@5、ai@6、ai@7 のどれを解決するかと、採用するプロバイダパッケージ側がそのメジャーに対応しているかどうかの2点。

公式情報源

コミュニティノート