AWS Lambdaの15分、Vercelの60秒。サーバーレスの「タイムアウト」は、短命なHTTPリクエストを捌く世界では合理的な制約であった。しかし、数時間にわたって外部APIを叩き、ツールを呼び出し、人間のフィードバックを待つAIエージェントの登場が、この前提を根底から覆しつつある。2025年末、AWSはre:Inventで「Lambda Durable Functions」を発表し、サーバーレスの自己変革を宣言した。同時期、API認証プラットフォームUnkeyはサーバーレスを完全に放棄し、Goサーバーへの移行で6倍の性能向上を達成した。本稿では、サーバーレスが直面する構造的限界と、Durable Executionを中心とした新アーキテクチャの台頭をインフラエンジニアの視点で整理する。

サーバーレスの構造的限界 ── タイムアウトという名の設計上の壁

サーバーレスアーキテクチャの根本思想は「ステートレスな短命関数の連鎖」である。AWS Lambdaは最大15分、Vercelのサーバーレス関数はHobbyプランで60秒、Proプランでも最大5分（Fluid Compute有効時で最大約14分）という実行時間制限を課している。この制約は、HTTPリクエストの処理やイベント駆動のデータ変換といった従来のユースケースでは問題にならなかった。

ところが、AIエージェントの処理パターンはこの前提と根本的に衝突する。典型的なエージェントワークフローでは、LLMへの推論リクエスト（数秒〜数十秒）、外部ツールの呼び出し（API応答待ち）、人間によるレビュー・承認（数分〜数時間）、複数ステップの逐次実行とエラーリトライが一つのセッション内で発生する。こうした処理を15分以内に完了させることは、現実的に不可能である。

さらに深刻なのは、サーバーレス関数の「ステートレス性」がキャッシュ効率を著しく低下させる点である。関数インスタンスはリクエストごとに起動・破棄されるため、インメモリキャッシュを保持できない。結果として、すべての状態をRedisやDynamoDBといった外部ストアから毎回取得する必要が生じ、ネットワークレイテンシが累積する。Unkeyの共同創業者Andreas Thomas氏が「ゼロ回のネットワークリクエストは、1回のネットワークリクエストより常に速い」と述べたのは、この本質を突いている。

Unkeyの脱サーバーレス ── Cloudflare WorkersからGoサーバーへ

API認証プラットフォームUnkeyは、2025年12月にサーバーレスアーキテクチャからの完全撤退を公表した。同社はそれまでCloudflare Workers上でサービスを構築していたが、性能面での限界に直面し、AWSのFargate上で動作するGoサーバーへの全面移行を決断した。

移行の最大の動機はレイテンシである。Unkeyのサービスは数千のアプリケーションのリクエストパスに位置しており、「1ミリ秒単位の遅延が重要」（Thomas氏）という環境にあった。サーバーレスではキャッシュデータを外部ストアから取得するオーバーヘッドが不可避であり、長時間稼働するGoプロセスがホットデータをインメモリに保持するアーキテクチャには原理的に勝てなかった。

結果として、Unkeyは移行後に6倍のパフォーマンス向上を達成した。新アーキテクチャではAWS Global Acceleratorをフロントに配置し、グローバルなトラフィック分散を維持しつつ、ステートフルなGoプロセスによるインメモリキャッシュとイベントのバッチ処理を実現している。この事例は、サーバーレスの「スケーラビリティ」が万能ではなく、ワークロードの特性によってはステートフルサーバーが圧倒的に優位であることを示している。

Durable Executionの台頭 ── Temporal、Restate、そしてAWSの自己変革

サーバーレスの限界に対する業界の回答が「Durable Execution（永続的実行）」である。Durable Executionとは、ワークフローの各ステップを自動的にチェックポイントし、障害発生時に最後の保存地点から再開できる実行モデルを指す。この概念を最も早くプロダクション化したのがTemporalである。

Temporalは、ワークフローをコードとして定義し、各外部呼び出し（Activity）を独立したリトライ可能な単位として管理する。すべてのインタラクションはイベント履歴ログに記録され、クラッシュやタイムアウト後も決定論的に状態を復元できる。2025年9月には、OpenAI Agents SDKとの統合をパブリックプレビューとして公開し、AIエージェントの耐障害性を大幅に向上させた。LLMのレート制限、ネットワーク断、予期しないクラッシュを、開発者がエラーハンドリングコードを追加することなく自動的に処理できる。

Restateは、より軽量なアプローチでDurable Executionを提供する。JavaScript/TypeScriptに特化したSDKを通じて「durable async/await」を実現し、既存のサーバーレスプラットフォーム上にデプロイ可能である。Restate自身が「AIエージェントはサーバーレスかつ耐久的であるべき」と主張しており、サーバーレスの利便性とDurable Executionの堅牢性の両立を目指している。

そしてAWS自身も動いた。2025年12月のre:Invent 2025で発表された「Lambda Durable Functions」は、Lambda関数にチェックポイントとウェイト機構を組み込み、非同期呼び出しで最大1年間の実行を可能にするものである。context.step()でビジネスロジックにチェックポイントを挿入し、context.wait()でコンピュート課金なしに実行を一時停止できる。さらにcreate_callback()で外部イベントの完了を待機し、parallel()やmap()で並行処理を実現する。Python 3.13/3.14およびNode.js 22/24ランタイムで利用可能であり、東京リージョンを含む15リージョンで一般提供されている。

アーキテクチャ選択の判断基準 ── いつサーバーレスを捨てるべきか

サーバーレスを維持すべきか、脱却すべきかの判断は、ワークロードの特性に依存する。以下の基準でアーキテクチャを選択すべきである。

サーバーレス（従来型）が適するケース: HTTPリクエストの処理、イベント駆動のデータ変換、スパイクの多いトラフィックパターン、プロトタイピングや初期段階のプロダクトなど、短命でステートレスな処理が中心のワークロードである。

Durable Execution（Lambda Durable Functions / Temporal / Restate）が適するケース: AIエージェントの多段階ワークフロー、人間参加型の承認フロー、外部API連携を伴う長時間バッチ処理など、ステートフルだがサーバーレスの運用利便性を維持したい場合である。Lambda Durable Functionsはインフラ管理不要でAWSエコシステムとの統合が容易であり、Temporalはマルチクラウドや複雑なオーケストレーションに強みを持つ。

ステートフルサーバー（Go / Rust on Fargate等）が適するケース: Unkeyのようにリクエストパスに位置するレイテンシクリティカルなサービス、大量のホットデータをインメモリで保持する必要がある場合、またはサーバーレスのコールドスタートやネットワークオーバーヘッドが許容できない場合である。

重要なのは、「サーバーレスか否か」という二項対立ではなく、ワークロードごとに最適な実行モデルを選択するハイブリッドアプローチが現実解であるという点である。多くの成熟したエンジニアリングチームが、サーバーレスを「一時的な加速レイヤー」として位置づけ、コアとなるステートフル処理には永続的なコンピュート基盤を採用する方向へ舵を切りつつある。

2026年のインフラ展望 ── サーバーレスは死なない、しかし万能でもない

サーバーレスが「死ぬ」わけではない。Lambda Durable Functionsの登場が示すように、サーバーレスプラットフォーム自体がDurable Executionを内包する方向へ進化している。InngestやUpstashといったサードパーティも、Vercel等のサーバーレスプラットフォーム上でDurable Executionを実現するミドルウェアを提供しており、エコシステムは急速に成熟しつつある。

しかし、AIエージェントの普及が突きつけた問いは、より根本的である。「インフラはワークロードに合わせて選択するものであり、ワークロードをインフラの制約に合わせるべきではない」という原則が、改めて確認されたのである。サーバーレスの黄金期を牽引した「すべてをLambdaで」という思想は、AIエージェント時代には通用しない。

インフラエンジニアに求められるのは、サーバーレス、Durable Execution、ステートフルサーバーという3つの実行モデルを状況に応じて使い分ける設計能力である。2026年のクラウドアーキテクチャは、この3層構造を前提として再設計されることになるだろう。

FAQ

Durable Executionとは何か？

ワークフローの各ステップを自動チェックポイントし、障害発生時に最後の保存地点から処理を再開できる実行モデルである。Temporal、Restate、AWS Lambda Durable Functionsなどが代表的な実装である。

AWS Lambda Durable Functionsと従来のStep Functionsの違いは？

Step FunctionsはJSON（ASL）でワークフローを定義するが、Lambda Durable Functionsはプログラミング言語のコード内にチェックポイントを埋め込む。開発者にとってはコードファーストで直感的であり、複雑な分岐ロジックの表現が容易である。

サーバーレスからステートフルサーバーへの移行は常に正しい選択か？

ワークロードに依存する。レイテンシクリティカルかつインメモリキャッシュが必要な場合は有効だが、スパイクトラフィックやプロトタイピングではサーバーレスの方が運用コストが低い。ハイブリッドアプローチが現実的な解である。

Temporalを導入するにはどのような前提条件が必要か？

Temporal Serverのホスティング（セルフホストまたはTemporal Cloud）が必要である。Java、Go、Python、TypeScript向けのSDKが提供されており、既存アプリケーションに段階的に統合可能である。

参考文献