Vercelで出すAIアプリ：AI SDK、Gateway、Workflowを製品境界に置く

ストリーミング表示は、仕事の完了を意味しない

VercelのAgentic Infrastructure発表は2026-04-09、Ship 2026 recapは2026-06-30に公開された。後者はAI SDK、Gateway、Workflow、Sandboxなどをagent向け構成要素として説明する。ここから得るべき設計は、会話画面のtoken streamと、完了まで数分かかる作業を同じHTTP requestに閉じ込めないことだ。

1. 1chat request
2. 2server auth/budget
3. 3model stream
4. 4UI

1. 1toolが長い
2. 2durable workflow
3. 3状態保存
4. 4UIが再接続

1. 1外部操作
2. 2sandbox/policy
3. 3承認
4. 4実行記録

AI SDKのprovider抽象化は、モデル呼び出しやストリーム表示を組み立てやすくする。ただし「同じAPIだから同じ安全性・料金・schema保証」という意味ではない。モデルごとのtool call、画像、rate limit、usage、エラーを実際のprovider docsで確認する。model IDを環境変数一つで差し替える構成にしても、固定評価セットを通さずに本番切替しない。

AI Gatewayのような経路を使う場合は、request ID、provider、model、token、再試行、失敗理由を一貫して観測できる形へ寄せる。自動failoverを実装しない。providerの失敗は明示的なエラーとして返し、依存する操作を止め、調査できるよう失敗したjobの状態を残す。料金上限も利用者・機能・日単位で置く。無限再試行は障害時に費用を増やす。

durable workflowに移す条件

検索、複数ファイル処理、ブラウザ操作、バッチ要約は途中で接続が切れ、外部サービスも失敗する。こうした作業はrequest/responseで完了させず、ジョブID、入力hash、状態、retry回数、結果の保存先を持つworkflowにする。retryして安全なのはidempotentな読み取りや、重複を検出できる書き込みだけだ。メール送信、削除、課金、公開は、同じジョブが二度走っても困らない設計にしてから自動化する。

1. 1開始
2. 2job ID発行
3. 3queued/running
4. 4progress event

1. 1失敗
2. 2retry可否を判定
3. 3backoff または要確認

1. 1完了
2. 2結果と根拠
3. 3利用者の操作へ

Sandboxはagentが生成したコードを隔離する助けになるが、秘密を無制限に渡す理由にはならない。読み取り専用token、短い有効期限、allowlistしたnetwork先、サイズ・時間上限を置く。生成コードの出力を本番へデプロイする前に、テスト、diff、権限を人が確認する。Vercel Connectのような短命credentialの思想を使う場合も、発行条件と監査ログをアプリ側で定義する。

実習：一つのAI操作を製品にする

1. UIはqueued、running、needs approval、failed、completedを表示できるようにする。tokenが流れている状態だけを進捗にしない。
2. サーバー側でidentity、機能権限、入力サイズ、予算を確認してからモデルを呼ぶ。キーはブラウザへ置かない。
3. tool callはschema検査、対象資源のACL、確認画面の順に通す。モデルが生成したURLやshell文字列を直接実行しない。
4. 通常、timeout、429、途中切断、workflow再開を試し、二重書き込みがないか確認する。
5. 20例の品質評価と、画面からの完了率・キャンセル率・費用を別の指標として追う。

Web基盤の速さは価値がある。しかしAI製品で利用者が信頼するのは、速くtokenが出ることではなく、途中で閉じても作業が失われず、何が実行されたか分かり、失敗を直せることだ。

具体例：資料を三本読んで比較表を作るjob

利用者がURLを三つ選び、違いを表へまとめる機能を考える。開始時にURL正規化、許可domain、最大取得量を検査し、job IDを返す。workerは各資料の取得結果、抽出時刻、本文hash、失敗を保存する。モデルには抽出済み本文だけを渡し、表の列名、各セルの出典、根拠なしフラグをschemaで返させる。画面は進捗を示すが、未完了の列を完成済みと見せない。

同じjobを二度押しても、入力hashと利用者IDが同じなら既存jobを返すか、明示的に新しい版を作る。取得先がtimeoutした時は、その資料を空文字で埋めて比較を続けない。部分結果として表示し、利用者が再試行する選択を持てるようにする。外部URL本文は指示ではないため、「この表を公開せよ」のような文をtool命令として扱わない。

この例の受け入れ基準は、表の美しさではない。URLが許可外なら呼び出さない、引用のないセルを明示する、接続を閉じてもjobが重複しない、providerを替えてもschema検査が通る、予算上限で途中停止した理由が読める、という五点である。これを通してから、ストリーミングの滑らかさやモデル比較を最適化する。

公開後はtemplate、依存SDK、モデルIDを同時に更新しない。一つずつcanaryで出し、固定評価と実際の完了率の差を見る。画面の成功表示とbackendのjob完了が食い違う時は、見た目を直す前に状態遷移を修正する。AIアプリの障害はしばしば、モデルではなく二重送信や失われた状態から始まる。

この順序を守れば、provider抽象化は便利な逃げ道ではなく、検証済みの切替点になる。

2024〜2026年の変化: Web配信は再利用可能なエージェント指示とルーティング主張を含むようになった

2024年の単一レスポンスのストリーミングから2025〜2026年のエージェントワークフローへの移行により、デプロイメントのメタデータがアプリケーション挙動の一部になりました。VercelのState of agent skills（2026-09-25）とAI Gatewayの採用記事（2026-09-18）はVercelの観測と指標を説明しています。独立ベンチマークでも、未レビューskillを導入する理由でもありません。

skillやツール記述は実行可能な製品ポリシーです。リポジトリ版を固定し、ファイル・ネットワーク・秘密へのアクセスを列挙し、許可操作を明記し、それを超えるよう促すプロンプト注入経路を試験します。Webリクエストを耐久ジョブと独立させます。ジョブIDを永続化してから受理し、lease／冪等キーで実行し、再接続後に終端状態を示します。モデルは気付かないプロバイダー可用性ではなく、レビュー済みの機能設定とリクエストログでルーティングします。ゲートウェイが採用を報告しても、発見シグナルとして扱い、自分の品質、遅延、コスト、拒否スイートを実行します。

2026-09-24 のエージェントの文書アクセスについての r/selfhosted 議論は逸話にとどまる。文書アクセスとtraceabilityの実験を促せるが、Vercelやagent frameworkの配備証拠ではない。

Vercelの2024年3月のAI SDK 3.0は、streamされたmodel outputをserver-rendered UIへ結んだ。interface plumbingは減らしたが、tool callの認証やdurable jobの永続化は不要にしていない。writeを提案するstreamを中断して試す。UIは部分stateを描画できても、serverはjobなし、または安定したterminal outcomeを持つidempotentなjob一つだけを示す。