Lambda Durable Functions についての調査

はじめに

AWS Lambda に 2025 年 12 月、Durable Functions という機能が加わりました（出典: AWS What’s New、2026-09-15 確認）。

以前 Qiitaにて AWS StepFunctions入門 サーバーレスワークフロー ハンズオンという記事を執筆しましたが、これまで Step Functions などで組んでいたような多段のワークフローを、Lambda 関数1つの中にコードとして記述・状態維持できるようになりました。

本記事では、単なる書き方ではなく「Lambda 側にどのような API や実行モデルの変更・追加が行われたことで、この耐久性（Durable）のあるワークフローが実現したのか」について、実行フローや内部挙動の観点から整理したいと思います。

これまでの Lambda 関数について

これまでの Lambda 関数は「イベントを1つ受け取り、処理して結果を返したら終了する」という単発の実行モデルでした。また、1回の呼び出しにつき最長15分という実行時間制限があり、実行環境の状態を次回に持ち越すこともできません。

そのため、複数のステップに分かれる一連の処理を作る場合は、関数を分割した上で「関数同士をつなぐ役割（オーケストレーション）」が不可欠でした。

これまで、このつなぎ役を担ってきたのが AWS Step Functions です。 Step Functions では、どの関数をどの順番で呼び出すか、エラー時に何回再試行するかなどを Amazon States Language（ASL） という JSON 形式で「ステートマシン」として定義します。

各 Lambda 関数はこのステートマシンから呼び出され、ステップ間の「状態（State）」は Step Functions 側が保持・管理する仕組みになっていました。

今回登場した Durable Functions は、このつなぎ役や状態管理を Step Functions のステートマシンではなく、Lambda 関数のコードそのものの中に記述できるようにした機能です。

（出典: Durable functions or Step Functions、2026-09-15 確認）

Lambda の構成要素について

Durable Functions では、ワークフローの定義や状態管理をコード内に閉じるため、Lambda のインフラストラクチャに対して「Lambda API（呼び出し・管理の窓口）」と「実行環境（コードが動くサンドボックス）」の両面に新たな仕組みが追加されています。

コンポーネント図

一言で Lambda といっていますが、その内部は大きく2つに分けられます。

1つ目は外部からのアクセスを受け付けるコントロールプレーンである「Lambda API（呼び出し・管理の窓口）」と、2つ目は「実行環境（コードが動くサンドボックス）」というもので、それぞれの関係性を以下図にまとめました。

（出典: NSDI ’20 Firecracker 論文「4.1 AWS Lambda」、Understanding the Lambda execution environment lifecycle、2026-09-17 確認）

1. Lambda API（呼び出し・管理の窓口）

上記の図のように、Lambda API は、外部からの関数呼び出し（Invoke）や、関数の作成・設定変更を受け付けるコントロールプレーン側の窓口となります。

呼び出しリクエストを受け取ると、設定（メモリやタイムアウト時間など）に基づいて後述の「実行環境」を準備し、イベントデータを渡します。

※なお、API の裏側で動くオーケストレーションの詳細は非公開のため、本記事ではこのコントロールプレーン一式をまとめて「Lambda API」と表現します。

（出典: AWS Lambda API Reference、Understanding the Lambda execution environment lifecycle、2026-09-17 確認）

2. 実行環境（コードが動くサンドボックス）

実行環境は、ユーザーの関数コードが実際に動作する場所です。

Firecracker による MicroVM 上で分離・実行されています（詳細は過去記事『Lambda MicroVMs についての調査』を参照）。

この MicroVM 内部では言語に応じた「ランタイム(実行管理プログラム)」が常駐しています。このランタイムが Runtime API を介して Lambda API からイベントを取得し、ハンドラ関数へ渡して実行・結果返却を仲介しています。

実行環境は効率化のために次の呼び出しで使い回される（ウォームスタートする）こともありますが、それらは制御することができません。 これらは環境の使い捨て（ステートレス）が前提となっているため、これまでの Lambda 単体では処理の状態を次回に引き継ぐことはできませんでした。

（出典: Understanding the Lambda execution environment lifecycle、2026-09-17 確認）

Durable Functions で追加された仕組み

これまでの Lambda には、「処理がどこまで進んだか」という実行状態を記録する仕組みがありませんでした。

Durable Functions では、まず Lambda API（呼び出し・管理の窓口） に、実行 1 回ごとに作られ、その状態と履歴を持つ「台帳（Durable Execution）」と、処理を一時停止・再開させる「スケジューリング機能」が追加されました。

さらに 実行環境（コードが動くサンドボックス） 側にも、専用 SDK を介してチェックポイントの保存や待機処理、進捗の追跡（リプレイ制御）を行うための拡張機能が組み込まれています。

Durable Functions における コンポーネント図

以下は、先ほどの図に Durable Functions で追加された仕組みを追加したものです。

（出典: AWS News Blog、2026-09-16 確認）

1.Lambda API（呼び出し・管理の窓口）での変更

台帳（Durable Execution）について

Durable Functions を有効にした関数が呼び出されると、Lambda API 側に 「台帳（Durable Execution）」 と呼ばれる実行記録が 1 冊ずつ作成されます。 この台帳は、大きく分けて以下の 2 種類のデータで構成されています。

• メタデータの行： 呼び出し時の入力値、現在のステータス、全体の制限時間など
• 操作履歴の行： コード内で step や待機（wait / waitForCallback）が実行されるたびに追記される実行ログ

例え：オンラインショップの注文処理の流れ

台帳にどのように記録が進んでいくのか、オンラインショップの注文処理を例に挙げて見てみます。

想定されているフローは、以下の5つのステップです。

• 1.注文を受け付ける(関数を呼び出し)
• 2.在庫を押さえる(step：結果を台帳に保存する処理の区切り)
• 3.上長に承認依頼して待つ(waitForCallback：承認の通知が届くまでシステムが一時停止して待機)
• 4.承認通知を受け取る(待機の終了：外部イベント(承認)を受信してシステムが再開)
• 5.出荷して完了する(step: 最後の処理を実行して全体を終了)

この一連の流れを Durable Functions で実行すると、コードの進行に合わせて Lambda API 側の台帳に以下のように操作履歴が追記されていきます。

図に出ていないものも含めると、台帳の仕様は以下のとおりです。

項目	内容
実行状態（Status）	図の RUNNING と SUCCEEDED のほか、FAILED / TIMED_OUT / STOPPED がある
一覧・検索	関数のバージョン単位で一覧取得。名前・状態・開始時刻でフィルタリング
操作履歴の取得	連番つきの時系列データとして GetDurableExecutionHistory API から確認。イベントの種類は 24 種類あり、図に出したのはそのうち 5 つ（ほかに StepStarted・WaitStarted・InvocationCompleted など）
保護	保存時に暗号化
保持期間	実行終了後 1 日〜 90 日間（デフォルト 14 日間）

※なお、この台帳が内部的にどのデータストアで保持されているか、また Step Functions の実行エンジンと基盤を共有しているかといった実装の詳細は公開されていません。

（出典: ListDurableExecutionsByFunction API、Basic concepts「Retention period」、GetDurableExecutionHistory API、Security and permissions for Lambda durable functions、2026-09-16 確認）

スケジューリング機能

スケジューリング機能は 一時停止（サスペンド）した処理を、後から自動で再開（リプレイ）させるために Lambda API 側に備わった仕組みです。

処理が再開（再呼び出し）されるトリガーは主に以下の 3 つあり、いずれも最新の台帳データを引き継いだ状態で関数を呼び出し直します（待機中に 1 台の Lambda がずっと起動し続けているわけではありません）。

• wait で指定した時間が経過したとき
• waitForCallback に対して、外部から承認や処理結果の通知が届いたとき
• invoke(他の子ワークフローや関数) で呼び出した処理が完了した時

一時停止（待機）している間は関数の実行自体が行われていないため、コンピュート課金（実行時間への課金）は発生しません。 また、スケジューリング機能には 「実行タイムアウト」 という設定があり、台帳が作成されてから全体の処理が終わるまでの制限時間をデフォルト 24 時間（最大 1 年）で指定できます。

従来の Lambda 関数にある「最長 15 分」の制限は 1 回の呼び出しにかかるものですが、待機中は関数が動作していないため、この 15 分枠を消費せずに長時間のワークフローを実現できます。

※なお、この呼び直し（再開）が内部的にタイマーやSQSのようなキューイングサービスなど、どの経路で行われているかの実装詳細は公開されていません。

（出典: AWS News Blog、Basic concepts「Execution timeout」、2026-09-18 確認）

2.実行環境（コードが動くサンドボックス）での変更

専用 SDK（リプレイとチェックポイントの制御）

Durable Functions を利用する際は、コードに専用 SDK を組み込み、ハンドラ全体をラップする形で記述します。

• チェックポイントの保存： step の実行結果や進捗を Lambda API（台帳）へ書き込む
• リプレイ（Replay）制御： 処理が再開された際、台帳を参照して実行済みの step の処理をスキップし、前回の戻り値だけを即座に返す
• 一時停止の制御： wait 実行時に、Lambda API 側へスケジューリング登録を行い処理を一時停止する

利用するうえでの条件は以下のとおりです。

項目	内容
対応言語	JavaScript / TypeScript、Python、Java、.NET
有効化	関数の作成時のみ設定可能（既存関数への後付けは不可）
対応ランタイム	Node.js 22・24、Python 3.13・3.14、Java 17・21・25、C#(.NET) dotnet8・dotnet10（コンテナイメージを使えば、これ以外のバージョンも利用可能）
コード	オープンソース（OSS）として公開

（出典: Supported runtimes for durable functions、Configure Lambda durable functions、aws/aws-durable-execution-sdk-python、AWS Durable Execution SDK for .NET now Generally Available、AWS What’s New、2026-09-18 確認）

※なお、公式ドキュメントで説明されているのは「実行環境内に状態保持や進捗追跡を行う拡張メカニズムが追加された」という点までであり、そのコンポーネントが MicroVM 内部（Extension レイヤー等）の具体的にどこに常駐しているかの実装詳細は非公開です。 （出典: Understanding the Lambda execution environment lifecycle、2026-09-18 確認）

まとめ

本記事では、AWS Lambda の新機能「Durable Functions」について、内部でどのような仕組みが追加・変更されたのかを整理・調査しました。

結論として、関数や MicroVM 自体の基本的な実行モデルが変わったわけではなく、以下の 3 つの要素が追加されたことで耐久性のあるワークフローが実現されています。

• Lambda API 側の「台帳（Durable Execution）」
• Lambda API 側の「スケジューリング機能」
• 実行環境側の「専用 SDK（リプレイ＆チェックポイント制御）」

これまでは Step Functions という「外部のサービス」が保持していたステート（どこまで進んだかの状態管理）を、Lambda API（コントロールプレーン）側が直接引き受けるようになったといえます。

このような内部挙動や API の役割を押さえておくことで、今後の障害調査や設計時に活用できるようになったかと思います。