普通のTypeScriptが「落ちない処理」になる — Vercel Workflows正式リリースの衝撃

バックエンドを書いていて、一番つらい瞬間は何か。

個人的には「処理の途中で落ちたとき」だと思う。外部APIを3つ呼んで、2つ目まで成功して、3つ目でタイムアウト。リトライしたいが、最初の2つはもう実行済みだから二重処理になる。結局、ステート管理テーブルを作り、各ステップの完了フラグを記録し、途中再開のロジックを手書きする。誰もがやったことがある、あの不毛な作業だ。

Vercelが4月16日に正式リリースしたWorkflowsは、この問題に対する回答として設計されている。

「use workflow」と「use step」だけ

Workflowsの設計思想は驚くほどシンプルだ。普通のasync/await関数の先頭に"use workflow"と書く。各処理ステップの先頭に"use step"と書く。それだけで、その関数は耐久実行（durable execution）に変わる。

キュー、リトライ、ステップの分離、状態の永続化、オブザーバビリティ——これまで開発者が手動で構築していたものを、Vercelが裏側で全部やる。TypeScriptとPythonの両方をサポートしている。

正直、最初は「ディレクティブ2つで耐久実行？」と半信半疑だった。だが、コアの抽象化を見ると、よく考えられていることがわかる。

4つの抽象化

Workflowsは4つの概念で成り立っている。

Workflowは、複数ステップを跨いで状態を管理するステートフルな関数。通常の関数と違い、デプロイやクラッシュを超えて生き残る。決定論的リプレイ（deterministic replay）によって、中断された地点から正確に再開する。

Stepは、Workflow内で実行される個々の作業単位。ステートレスで、自動リトライと永続化が付いてくる。失敗しても他のStepに影響しない。

Sleepは、指定した時間だけWorkflowを停止する。数分でも数ヶ月でもいい。重要なのは、停止中にコンピュートリソースを消費しないこと。「3日後にフォローアップメールを送る」のような処理が、setTimeoutではなくインフラレベルで保証される。

Hookは、外部イベントを待つ仕組み。ユーザーの承認待ち、Webhookの受信、別システムからのコールバック——Workflowを一時停止させ、イベントが届いたら再開する。

この4つだけ。TemporalやInngestのような既存の耐久実行フレームワークと比べると、概念の数が圧倒的に少ない。Temporalは強力だがKubernetesクラスタの運用が前提になるし、独自のSDKやワーカーの概念を理解する必要がある。Workflowsは「Vercelにデプロイするだけ」で動く。このゼロインフラのアプローチが、最大の差別化ポイントだろう。

ベータの実績が物語る

Workflowsは2025年10月にベータ版としてローンチされ、正式リリースまでの約6ヶ月間で1億回以上のワークフロー実行と5億以上のステップ処理を記録した。利用企業は1,500社超、npm週間ダウンロード数は20万以上。

ベータでこの規模が回ったという事実は、プロダクション耐性を示す強力な証拠だ。耐久実行の仕組みは、小規模では問題なくても大規模になると壊れやすい。1億回を処理して正式リリースに踏み切ったのは、相当の自信があるということだろう。

エージェント時代のインフラ

Workflowsが本当に面白いのは、AIエージェントとの統合だ。

Vercelは以前から「Agentic Infrastructure」というコンセプトを掲げてきた。Vercel上のデプロイの30%以上がAIエージェント経由という現実がある中で、Workflowsはエージェントの「信頼性」という根本課題に取り組んでいる。

AI SDK v7で導入されたWorkflowAgentは、Workflowsとの深い統合を持つ。エージェントのツール呼び出し、状態管理、外部イベントへの応答——これらすべてが耐久実行の上で動く。つまり、エージェントが10個のツールを順番に呼び出す途中で何かが落ちても、完了したステップからやり直せる。

これは地味に大きい。現状のAIエージェントが抱える最大の課題のひとつは「途中で失敗したときの回復」だ。Claude CodeやDevinのようなコーディングエージェントが長時間タスクを実行する場面を想像すればわかる。30分かけた作業が途中で消えたら、ユーザーの信頼は一瞬で崩れる。

Workflowsの耐久実行は、この問題にインフラレベルで対処する。個々のエージェント開発者がリトライロジックを自作する必要がなくなる。

可能性と懸念

Workflowsが本格普及すれば、いくつかの変化が起きるかもしれない。

まず、バックエンドの書き方が変わる。メール送信、決済処理、データ集計のような非同期ワークフローを、専用のキューシステムやワーカープロセスなしで実装できるようになる。スタートアップにとっては、BullMQやCeleryのようなジョブキューを設定する手間がまるごと消える。

次に、エージェントの信頼性が底上げされる。AIエージェントを「動くけど不安定」から「インフラレベルで保証される」に引き上げる基盤になり得る。特に、ユーザーの承認を待って再開するHookの仕組みは、human-in-the-loopのエージェントワークフローと相性がいい。

一方で気になる点もある。ベンダーロックインだ。"use workflow"と"use step"はVercelのプラットフォームに密結合している。Workflow SDKはオープンソースだが、フルマネージドの耐久実行はVercelでしか動かない。Temporalなら自前クラスタに移行できるが、Workflowsにはその選択肢がない。

もうひとつ、料金の予測しにくさ。WorkflowsはイベントベースのUsage-based Pricingで、各ステップが3つのイベント（作成・開始・完了）を生む。複雑なワークフローになるほど、請求額の見積もりが難しくなる可能性がある。

正直な評価

Vercel Workflowsは「耐久実行を民主化した」と言っていい。Temporalの強力さに惹かれつつも、Kubernetesの運用コストで二の足を踏んでいた開発者にとって、これは現実的な選択肢だ。

ただし、すでにVercelを使っているチーム向けの機能であることは否定できない。AWSやGCPを中心にインフラを組んでいるなら、TemporalやInngestの方が選択肢として自然だろう。

エージェント開発の文脈では、AI SDK v7との統合が最大の武器。「壊れないエージェント」をインフラ側で担保するというアプローチは、2026年のAI開発において確実に需要がある方向性だ。

Vercel Workflows 公式ドキュメント