2026年6月25日、Vercelは「AI SDK 7」を公開した。公式は本リリースを "a major release for building production agents in TypeScript" と位置づけ、SDKが従来の "model calls and chat primitives" から "a broader agent platform" へ拡張されたと説明している（出典: AI SDK 7 is now available — Vercel）。
これはチャットUI向けライブラリの小幅アップデートではない。generateText / streamText の薄いラッパーとして使ってきたコードベースには、Node.js 22必須・ESM必須・主要オプションの改名という破壊的変更（メジャーバンプ）が入る。一方で、これまで自前で書いていた「ツール実行の承認」「タイムアウト」「OpenTelemetry連携」が標準機能に格上げされた。つまり移行コストと引き換えに、本番エージェントの運用負債が減るリリースだ。本記事はその両面を、移行で壊れる箇所と本番投入チェックの両方から整理する（数値・API名はすべて公式チェンジログ由来。手元で全コードを実行検証したものではないため、各自のリポジトリで codemod 適用後にビルドを通すこと）。
結論
| 確認項目 | AI SDK 7での変化 | 移行時に直すこと |
|---|---|---|
| 実行環境 | Node.js 22 が最低要件 | CI/本番ランタイムを Node 22 系へ。古い LTS のままだと起動しない |
| モジュール形式 | ESM 必須（CommonJS require() 非対応） |
package.json に "type": "module"、require を import へ |
| 主要オプション名 |
system→instructions、onFinish→onEnd、fullStream→stream
|
codemod npx @ai-sdk/codemod v7 で機械置換、差分を目視確認 |
| ツール承認 | tools 側 needsApproval → toolApproval に再設計、承認リプレイを HMAC 署名 |
人間承認フローを toolApproval へ移植。引数改ざん対策が前提に入る |
| 観測 | OpenTelemetry が ai 本体から @ai-sdk/otel へ分離 |
OTel 連携は別パッケージ導入に切り替え |
| 守備範囲 | 耐久実行 WorkflowAgent・タイムアウト・サンドボックスが標準 |
自前で書いていた運用コードを標準機能へ寄せられる |
なぜ「チャット primitive」から「エージェント基盤」へ広げたのか
確認できる事実
公式チェンジログによれば、AI SDK 7 は機能群を Development / Execution / Observability / Multimodal の4領域で再構成している。本番運用に直結する Execution 領域には、次が明記されている（出典: Vercel changelog）。
- ツール承認ポリシー: user-approval / auto-approve / auto-deny と、型付き関数による承認判定。
- 承認リプレイの署名: 承認の再生（replay）を HMAC 署名で保護し、引数の改ざんを防ぐ。
-
WorkflowAgent: ステップ間に状態を永続化する、長時間・耐久実行向けのエージェント。 - 第一級のタイムアウト: total / per-step / per-chunk / デフォルトツール / ツール別バジェット。
- サンドボックス実行: コマンド実行・ストリーミング出力・環境変数をサポート。
-
HarnessAgent: Claude Code・Codex・Deep Agents・OpenCode・Pi など外部エージェントをラップする。
Observability 領域では、OpenTelemetry が ai 本体から切り出され、GenAI セマンティック規約に沿った span を出す専用パッケージ @ai-sdk/otel が用意された。レスポンス時間・ツール実行時間・tokens per second などの統計も取れる。
実務解釈
ここで効くのは「エージェントを本番で動かすと必ず自前実装になっていた3つ」が標準化された点だ。
- 承認（human-in-the-loop）: 「DBを書き換えるツールは人間承認を挟む」をアプリ側で組んでいたチームは多い。これがポリシーとして宣言的に書け、しかも承認リプレイが署名されるので「承認後に引数を差し替える」攻撃面が塞がれる。エージェントに権限を渡すうえで、この署名は地味だが重要だ。
- タイムアウト: LLM呼び出しやツール実行が無限に伸びる事故は、per-step / per-tool バジェットで予算化できる。コスト暴走と応答ハングの両方に効く。
- 観測: OTel が標準規約の span で出るため、既存の APM/トレース基盤にそのまま載る。「なぜこのエージェントは5ステップも回したのか」を後から追える。
裏を返せば、これらをまだ自前で書いていないチームは、v7移行と同時に本番ガードレールを入れ直す好機ということになる。
v6 から壊れるもの：移行で必ず触る破壊的変更
確認できる事実
公式が挙げる移行要件と API 改名は次のとおり（出典: Vercel changelog）。
ランタイム / モジュール要件
| 項目 | 要件 |
|---|---|
| Node.js | 22 以上（native fetch、改善された AsyncLocalStorage のため） |
| モジュール | ESM 必須。import 構文または .mjs。CommonJS require() は非対応 |
| package.json |
"type": "module" を指定 |
API の改名・移動
| v6 | v7 |
|---|---|
system オプション |
instructions |
onFinish |
onEnd |
StreamTextResult.fullStream |
stream |
tools の needsApproval
|
関数/エージェント側の toolApproval
|
ai 内蔵の OpenTelemetry |
@ai-sdk/otel（別パッケージ） |
公式は移行の大半を自動化する codemod とスキルを案内している。
# 破壊的変更の大半を自動置換
npx @ai-sdk/codemod v7
# v6→v7 移行スキル（手順をガイド）
npx skills add vercel/ai --skill migrate-ai-sdk-v6-to-v7
なお 6月29日時点での最新は ai@7.0.6（出典: vercel/ai Releases — GitHub）。メジャー直後はパッチが速いので、移行は最新パッチに合わせる前提で進めたい。
実務解釈
-
codemod は「掛けて終わり」ではない。
system→instructionsのような単純改名は機械置換が効くが、fullStream→streamのようにストリーム消費側のロジックが絡む箇所は、差分を必ず目視レビューする。型エラーが出る場所が実質の移行ToDoリストになる。 -
Node 22 / ESM 必須が一番の地雷。アプリ本体より、Lambda やコンテナのベースイメージ、
require前提の小さなユーティリティ、CommonJS のままの社内パッケージが先に折れる。移行はライブラリ差し替えよりランタイムとモジュール形式の棚卸しから始めるのが安全だ。 - OTel を使っているなら、
ai本体から消えている前提で@ai-sdk/otelの導入を移行PRに必ず含める。「いつの間にかトレースが出なくなっていた」を防ぐ。
実装チェックリスト
移行前（棚卸し）
- 本番・CI のランタイムを Node.js 22 系に上げられるか確認した
-
package.jsonに"type": "module"を入れ、require()依存を洗い出した -
OpenTelemetry を使っているか、使っているなら
@ai-sdk/otel導入を移行スコープに入れた
移行（自動 + 目視）
-
npx @ai-sdk/codemod v7を適用し、生成された差分をレビューした -
system→instructions、onFinish→onEnd、fullStream→streamの置換漏れを型エラーで潰した -
ストリーム消費（
fullStream→stream）周りの挙動を手元で動かして確認した
本番ガードレール（v7で標準化された機能の投入）
-
副作用のあるツールに
toolApprovalポリシーを設定した（人間承認 or auto-deny） - per-step / per-tool のタイムアウト・バジェットを設定し、暴走時の上限を決めた
-
WorkflowAgentで耐久実行が必要な処理（長時間ジョブ）を切り分けた - OTel span が既存のトレース基盤に出ていることを確認した
失敗パターン
パターン1：ライブラリだけ上げてランタイムを放置 → Node 22 / ESM 必須を見落とし、本番デプロイで起動しない。対策：移行PRの最初のコミットを「ランタイムとモジュール形式の更新」にし、アプリコードより先に通す。
パターン2：codemod を信用しきってストリーム周りを壊す → fullStream→stream の改名は機械置換できても、消費側のロジックがズレて出力が欠ける。対策：ストリーミングを使う画面・APIは必ず手動で一度動かして確認する。
パターン3：承認とタイムアウトを「あとで」にする → v7移行を機能改名の置換だけで終わらせ、本番ガードレール（toolApproval・タイムアウト）を入れないと、エージェントの権限・コスト事故は移行前と変わらない。対策：移行と同じPRで、副作用ツールへの承認とタイムアウト設定をセットにする。
パターン4：OTel の消失に気づかない → ai 本体からトレースが外れたことに気づかず、観測だけ静かに欠ける。対策：移行後にトレースが出続けているかをダッシュボードで確認するチェックを入れる。
参考リンク
この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表 / AIアーキテクト
Next.js / TypeScript / n8nを活用した自律型アーキテクチャ設計を専門としています。
日々の自動化の検証結果や、ビジネス側の視点（ROI等）に関するより深い考察は、以下の公式サイトおよびnoteで発信しています。