Lambda Durable Functionsとは何か？その基本概念と特徴を詳しく解説【入門編】

Lambda Durable Functionsとは何か？その基本概念と特徴を詳しく解説【入門編】

AWS Lambdaの新機能「Durable Functions」とは、サーバーレス環境で長時間にわたる複数ステップの処理を実現する仕組みです。従来のLambda関数では最大実行時間が15分に制限されていましたが、Durable Functionsを利用すれば処理を一時中断・再開しながら最長1年間に及ぶワークフローを実行できます。これはLambdaにチェックポイント機能を組み込み、途中経過を保存しつつ処理を続行できるようにすることで、バッチ処理やワークフローのような長時間実行が求められるユースケースをコード内で完結できるようにしたものです。

Durable Functionsの基本概念は「イベント駆動のワークフローをコードで記述し、その進行状態をAWSが自動管理する」点にあります。開発者は通常のLambda関数と同じようにコードを書きますが、途中でステップ（step）や待機（wait）といった操作を挟むことで、処理の進捗を保存（チェックポイント）し、必要に応じて関数を一時停止できます。万一途中でエラーやタイムアウトが発生しても、最後に成功したチェックポイント以降の処理のみを再実行するリプレイ機構によって自動復旧するため、複雑なエラー処理や再試行ロジックを自前で実装する負担が軽減されます。これにより、たとえば決済プロセスや承認待ち業務など、人の介在や長い待ち時間を含むフローでも、ひとつのLambda関数内で信頼性高く完結できるようになりました。

Lambda Durable Functionsの定義と概要 – サーバーレスワークフローをコードで実現

Lambda Durable Functionsは、サーバーレスアーキテクチャ上で長時間実行されるワークフローをコードのみで実現するためのAWS Lambdaの新機能です。これは従来Step Functionsなど外部サービスに頼って実装していたワークフロー制御を、Lambda関数自体のプログラミングモデルに取り込み、開発者が普段使い慣れたコード上で順次処理や待機処理を表現できるようにしたものです。Durable Functionsを利用すると、従来別サービスや複雑な状態管理コードが必要だったマルチステップ処理を1つのLambda関数で記述し、AWSが裏側で状態保持と再開処理を行ってくれるため、サーバーレスでより高度な処理フローを簡潔に実装できます。

従来のLambda関数との違い – 15分間の実行時間制限を突破し最大1年の長期間実行を可能に

Durable Functions最大の特徴は、通常のLambda関数が抱えていた15分の実行時間制限を事実上取り払った点です。通常のLambdaではタイムアウトにかかる処理はStep Functionsなどで分割する必要がありましたが、Durable Functionsでは関数実行を途中で停止・再開できるため、単一の関数で長時間（最長365日間）の処理を継続できます。具体的には、関数内に待機ポイントを設けて一時終了し、所定の時間経過後やイベント発生時に再び呼び出すことで、累積すれば1年近い長時間のワークフローを実現します。これにより、大量データのバッチ処理や数日がかりの処理フローでも、15分以内に終わらせるための工夫なしに実装できるようになりました。

Durable Functionsが解決する課題 – 複雑な状態管理やエラー処理の簡素化と信頼性向上

Durable Functionsは、従来サーバーレスで課題だった長時間にわたる状態管理を大きく簡素化します。複数のサービス間をまたぐ処理や人の承認を待つフローを実装する場合、これまでは状態を外部データストアに保存したり、一時停止用に別途ロジックを書く必要がありました。Durable Functionsではそうした状態管理がフレームワークに組み込まれており、進捗や戻り値を自動で保存・復元してくれるため、開発者はビジネスロジックに集中できます。また自動チェックポイントとリトライ機能により、一時的な失敗時には処理を途中から再実行してくれるため、ワークフロー全体の信頼性が向上します。これらの仕組みにより、複雑なエラー処理やリカバリ処理を自前で実装する手間が減り、システム全体の堅牢性も高まります。

Durable Functionsの仕組み – チェックポイント方式による実行の中断と再開で長時間実行を実現

Durable Functionsは、Lambda関数の実行を複数のステップに区切り、各ステップ完了時にチェックポイント（実行結果と進捗状態）を保存することで機能します。関数内で待機ポイントに到達すると、その時点で関数はいったん終了し、状態が保存されます。そして待機時間経過後や次のトリガー発火時に関数が再起動すると、Durable Execution機構が直前までのチェックポイントを読み込み、完了済みの処理をスキップして残りの処理から再開します。このリプレイ方式により、関数全体を長時間動かし続けなくても区切りごとに安全に停止・再実行でき、アイドル中は計算リソースを使わないためコストも発生しません。こうしたチェックポイント&リプレイの仕組みが、Lambda単体での長期間実行を可能にする核心となっています。

Lambda Durable Functions誕生の背景 – AWSが長時間ワークフロー機能を導入した理由

Durable Functionsが導入された背景には、ユーザーニーズと他社サービス動向の両面があります。まずユーザー側では、従来から「Lambdaで長時間バッチ処理を実行したい」「Step Functionsを使うほどではないが15分以上のワークフローを簡単に書きたい」といった要望がありました。こうした要望に応えるため、AWSはLambdaの使い勝手を維持しつつ長時間ワークフローを可能にするDurable Functionsを開発しました。また他クラウドにはAzure Durable Functionsのようにコードベースでワークフローを記述できる機能が既に存在しており、AWSとしても同等以上の柔軟性を持つ機能を提供する意図がありました。つまりDurable Functions誕生の背景には、サーバーレスでより高度なシナリオを実現したいという開発者コミュニティの声と、AWSがサーバーレス開発の可能性をさらに広げる狙いがあったと言えます。

Lambda Durable Functionsでできること・主な特徴のまとめとメリットを徹底解説

Lambda Durable Functionsによって実現できることは多岐にわたります。ここではDurable Functionsの主な機能と特徴をまとめ、それぞれがもたらすメリットについて解説します。Durable Functionsは、コード内でフロー制御を記述するためのSDK（Durable Execution SDK）を提供し、通常のLambdaでは難しかった長期間の順次処理・並列処理・待機処理などを簡潔に実装できます。また、実行中の状態管理やエラー時の自動リトライなども含め、サーバーレスアプリケーションの信頼性と効率性を高めるさまざまな機能が統合されています。以下に、Durable Functionsの主要な機能とそれがもたらすメリットを見ていきましょう。

ステップ実行と自動チェックポイント – 処理の区切りごとに進捗を保存し、障害時は未完了部分のみ再実行

Durable Functionsでは、処理を複数のステップに分割し、各ステップ終了時に自動でチェックポイントを作成します。context.step()メソッドを使ってステップを実行すると、そのステップの結果が永続化されるため、もし後続の処理でエラーが発生した場合でも、完了済みのステップは再実行されません。これにより、長い処理の途中で失敗が起きても、エラー発生前の作業は無駄にならずに済みます。チェックポイントのおかげで関数実行が部分的に中断・再開できるため、システム全体の堅牢性と効率性が向上します。つまりDurable Functionsでは、大きな処理を安全に区切りながら進め、障害時には未完了の部分だけを自動再実行することで、全体の成功率を高めているのです。

待機（Wait）機能 – 関数を一時停止して後から再開、待ち時間中は課金なし（最大1年まで待機可能）

Durable Functionsの待機機能（context.wait()）を使うと、関数を任意の時間だけ一時停止し、後で再開することができます。例えば「5分待ってから次の処理へ進む」「外部イベントが完了するまで一時停止する」といったことがコード一行で実現できます。待機中はLambda関数が終了している状態になるため、その間のリソース課金は発生しません。長時間のスリープや人の入力待ちなどもコストを気にせず挟めるのが大きなメリットです。待機可能な期間は最大で365日（約1年）にも及ぶため、日単位・週単位のバッチ処理や人間の承認を含むプロセスでも問題なく扱えます。必要なときに関数を止めて、タイミングが来れば自動で再開できる柔軟性は、サーバーレスでは画期的と言えるでしょう。

自動リトライとエラー処理 – 一時的な失敗に対する自動再試行とバックオフで堅牢性を向上（リトライ戦略のカスタマイズも可能）

Durable Functionsでは、ステップ内で例外が発生した場合に自動リトライする仕組みが組み込まれています。デフォルトでは数回の再試行が行われ、逐次バックオフ（待機時間を徐々に伸ばす）しながら安定するまで処理を試みます。例えば一時的なネットワーク障害やAPIの一時的な不調であれば、自動リトライによって問題が解消するまで再度実行を繰り返すため、ワークフロー全体が失敗するリスクを下げられます。リトライの戦略（回数や待ち時間）は開発者がカスタマイズ可能で、リトライすべきでないエラーを除外したり、最大試行回数や待機間隔を細かく指定できます。一方、ステップ以外の箇所（ステップの外側の処理）で例外が起きた場合は即座に実行失敗とみなされます。このようにDurable Functionsでは、エラー発生時の挙動がフレームワークで標準化されており、適切な自動再試行によってシステム全体の堅牢性が大きく向上します。

外部イベントや人による承認待ち – コールバックトークンで通知を受けてフローを再開（人の承認完了を待って処理続行）

Durable Functionsは、長時間のワークフロー中に外部イベントや人間の承認を待つ処理にも対応しています。例えば上司の承認が下りるまで処理を停止するようなケースでは、context.create_callback()でコールバック用の一意なトークンを発行し、そのトークンを外部システム（承認UIなど）に渡します。承認完了時には外部からAWSの指定APIにそのトークンを使って通知（コールバック）することで、待機中のDurable Functionが再開されます。これにより、「人の操作完了を待って後続処理へ進む」というフローをLambda内で完結可能です。コールバックを利用した承認待ち実装では、関数は承認が降りるまで停止しており無駄なリソース消費はありません。承認が行われ次第ただちにフローが再開し処理が続行されるため、外部システムとシームレスに連携した人間参加型のワークフローもDurable Functionsで容易に実現できます。

並列実行とマップ処理 – 複数タスクの並行処理や一括処理をシンプルに記述（コード上でループや並列処理を実現）

Durable Functionsは順次処理だけでなく、並列処理やリストに対するマップ処理にも対応しています。例えば複数の独立したタスクを同時に実行したい場合、DurableContext.parallel()またはmap()を使うことで、複数のステップを並列に走らせ、その全てが完了するのを待ってから次の処理に進む、という並行フローを簡潔に書けます。これにより、従来はStep Functionsの並列ステートを使ったり、自前でPromiseやスレッド管理をしていたようなケースも、数行のコードで実装可能です。また、配列データに対して各要素ごとに同じ処理を実行するマップ処理もサポートされており、ループ処理を並列化して高速化することもできます。Durable Functionsではこれらの並列・マップ処理がLambda関数内のコードとして記述できるため、複雑な並行フローを分かりやすく実装できるというメリットがあります。

実行状態の自動保存と引き継ぎ – 永続ストレージに状態を記録し、途中から再開してもデータを保持（明示的なデータ保存が不要）

Durable Functionsでは、各関数実行の状態（ステップの結果や進行状況など）がAWS側で自動的に永続ストレージに保存されます。チェックポイント情報や一時的な戻り値データはAWSが内部的に保持しており、開発者が明示的にDynamoDBやS3に状態を書き出す必要はありません。関数再開時にはその保存された状態がDurable Execution SDKによって読み込まれ、前回の続きから処理を再開できるようになります。例えば途中まで集計したデータやAPI呼び出し結果も、次の再実行時に自動復元されるため、自前で状態を引き継ぐコードを書く必要がありません。この状態引き継ぎはAWSによって暗号化され安全に管理されており、他の実行からデータが漏れたり競合したりしないようになっています。結果として、Durable Functionsでは長期間にわたる実行でも必要なデータが常に保存・引き継がれるため、途中で関数が停止・再開してもデータの整合性が保たれます。

サーバーレスのスケーラビリティと低コスト – 必要時に自動スケールし、待機中はリソース消費ゼロで経済的なメリット

Durable Functionsは、基本がAWS Lambdaの枠組みの中で動作するため、Lambdaの自動スケーリングや高い可用性といったメリットをそのまま享受できます。需要に応じて複数のDurable Function実行が並行して動けばLambdaが自動でスケールアウトし、処理が終わればスケールインして無駄なリソースを抱えません。また前述の通り、待機中は関数が停止している扱いになるためリソース使用量ゼロ＝課金ゼロで非常にコスト効率が良いです。長時間のワークフローを扱う場合でも、実際に計算している時間に対してのみ従量課金され、待ち時間には課金されないため、従来の常時稼働型サーバーでバッチ処理を走らせるのに比べ大幅なコスト削減が期待できます。Durable Functionsはサーバーレスのスケーラブルな特性と「使った分だけ払う」料金モデルをさらに長時間ワークロードまで拡大した形であり、性能とコスト両面で大きなメリットを提供します。

AWS Lambdaの新機能「Durable Functions」をその利点も含めてわかりやすく丁寧に解説

ここでは、AWS Lambda Durable Functionsという新機能が具体的に開発体験やアーキテクチャにどのような変化をもたらすのかを、例を交えながらわかりやすく解説します。Durable Functionsは新しい概念ですが、実際には開発者に馴染みのあるコードベースでワークフローを記述できるため、使いこなせばサーバーレス開発を一段と強力にする利点があります。このセクションでは、従来の方法との比較や簡単なコード例、典型的なユースケースを通じて、Durable Functionsの実像に迫ります。初めてDurable Functionsに触れるエンジニアの方でもイメージが掴みやすいよう、ポイントを丁寧に説明していきます。

従来のワークフロー実装方法との比較 – Step Functionsや手動状態管理に比べたDurable Functionsの簡便さ

Durable Functionsが登場する以前、サーバーレスで長い処理フローを実現するには主に2つの方法が取られていました。1つはAWS Step Functionsを使って状態遷移を定義し、Lambdaを複数呼び出すワークフローを構築する方法、もう1つは各Lambda関数内で状態を外部に保存しつつ分割実行する、いわば手動での状態管理です。Step Functionsは視覚的な状態マシン定義で複雑なフローを組めますが、JSON/YAMLによる定義の学習コストや利用料金（状態遷移ごとの課金）が発生します。一方、手動状態管理は柔軟ですが実装が煩雑になりがちでした。Durable Functionsはこれらの中間に位置し、Lambda関数のコード内で直接ワークフローを記述できるため、開発のシンプルさと柔軟性を両立しています。Step Functionsほど大掛かりではないが単一のLambdaでは収まらない処理を、Durable Functionsならコードを書く感覚で手軽に実装できる点で、従来手段に比べ圧倒的に簡便だと言えます。

シンプルなコード例で理解するDurable Functions – 順次処理のワークフローをコードで記述するイメージ

Durable Functionsの挙動を理解するには、実際のコード例を見るのが早道です。例えば「3つのステップを順番に実行し、途中で5分待機する」というワークフローを考えてみます。Durable Functionsを使わない場合、Step Functionsの状態機械で各ステップとWaitステートを定義するか、あるいは複数のLambdaを連携させる必要があります。しかしDurable Functionsを用いると、1つのLambdaハンドラ内で次のように記述できます：

await context.step(async () => {...});（ステップ1実行）
await context.wait(Duration.seconds(300));（5分待機）
await context.step(async () => {...});（ステップ2実行）
...（以下略）

このように、普通にJavaScript/TypeScriptやPythonのコードを書きながら、途中でcontext.wait()やcontext.step()を差し込むだけで、順次処理＋待機からなるワークフローを表現できます。視覚的な定義ファイルを書く必要もなく、開発者にとって直感的なコードとして実装できるのがDurable Functionsの大きな魅力です。

具体的ユースケース：注文処理フロー – Durable Functionsで複数ステップを順序どおり実行する例

Durable Functionsの典型的なユースケースとして、ECサイトの注文処理フローを考えてみましょう。例えば注文を受け付けた後、「在庫確認 -> 支払い処理 -> 出荷準備 -> 配送通知」といった一連のステップを順に行う必要があります。この場合、それぞれのステップをcontext.step()で実装し、必要に応じて外部システムの完了待ちにcontext.wait()やcontext.wait_for_condition()を使うことで、注文処理全体を単一のDurable Functionで表現できます。

具体的なコードの流れは以下のようになります。まずvalidate_order()ステップで注文内容の検証を行い、次にprocess_payment()ステップで決済処理を実行します。決済が完了したら、配送システムへの連携のためsend_for_shipping()ステップへ進みます。各ステップ間で外部サービスの応答待ちが必要ならcontext.wait_for_condition()を用いてポーリング待ちを挿入できます。最終的にnotify_customer()ステップで顧客へ通知し完了です。このようにDurable Functionsなら、複数のステップからなる注文処理をコードの自然な逐次フローとして記述でき、かつ各ステップの途中経過や結果は自動で保存されるため、途中障害が起きても安全に再実行できます。

開発者にとっての利点 – コード中心のワークフロー設計で開発生産性とコードの可読性・保守性が向上

Durable Functionsは、開発者がコード中心でワークフローを設計できるようにしたことで、開発体験に大きな利点をもたらします。まず、従来Step FunctionsのDSL（ドメイン固有言語）を学習していた時間が不要になり、普段使っているプログラミング言語だけでワークフローを組み立てられるため開発生産性が向上します。コードとしてフローを記述できるため、IDEで補完が効いたりバージョン管理もしやすく、チーム開発時のレビューもJSON定義より読みやすいという可読性・保守性向上のメリットがあります。また、コードで書けることで条件分岐やループなども通常の言語機能として表現でき、デバッグもLambdaのローカルテストやユニットテストで一部ロジックを検証できるなど、従来のワークフロー定義より馴染みやすい環境と言えます。総じて、Durable Functionsによりサーバーレス開発者は従来以上に直感的かつ柔軟に長時間ワークフローを実装できるようになり、その結果コードの簡潔さと保守のしやすさが大きく向上します。

Durable Functionsがもたらすサーバーレス開発への影響 – 新機能が広げるLambda活用の可能性

Durable Functionsの登場は、AWS Lambdaを用いたサーバーレス開発の可能性を大きく広げました。これまでLambdaは短時間のトリガー駆動イベント処理に適したサービスという位置付けでしたが、Durable Functionsによって長期間にわたるビジネスプロセスのオーケストレーションまで賄えるようになりました。これにより、サーバーレスで扱えるユースケースの幅が広がり、従来はバッチサーバーや他サービスで実装していた業務フローをLambdaに統合できるケースが増えています。

また、Azure Durable Functionsなど他クラウドの類似機能と肩を並べたことで、マルチクラウド環境におけるワークフロー実装の選択肢としても注目されています。開発者視点では、「コードでフローを書ける＝アプリケーションロジックとワークフローロジックの一体化」を意味し、設計の一貫性が増すという効果もあります。AWSとしても、Durable FunctionsによってLambdaが単なる関数実行環境に留まらず、長期に及ぶ処理の統合的な実行プラットフォームとなったことで、サーバーレス活用シナリオのさらなる拡大を狙っています。総じてDurable Functionsは、サーバーレス開発における新たな可能性を切り拓くキーファクターであり、今後のアプリケーション設計手法に影響を与える重要な機能と言えるでしょう。

Lambda Durable Functionsの始め方（セットアップ手順）初心者向け徹底解説ガイド

ここでは、Lambda Durable Functionsを利用し始めるための具体的な手順を解説します。初めてDurable Functionsを触る方向けに、必要な準備から実際の関数作成、コード記述、動作確認までを順を追って説明します。本ガイドではコンソール（AWSマネジメントコンソール）を使ったセットアップを中心に、AWS SAMやCDKでのデプロイに触れるポイントも紹介します。初心者のエンジニアでも迷わず導入できるよう、各ステップで注意すべき事項やハマりやすいポイントにも言及します。

Durable Functions利用の前提条件 – サポート対象ランタイムや利用可能リージョン、必要なSDKアップデートの確認

まずDurable Functionsを使うための前提条件を押さえましょう。Durable Functionsは現時点でNode.js 24とPython 3.14といった最新のランタイムでサポートされています（その他の言語ランタイムは順次対応予定の場合があります）。したがってLambda関数を作成する際は、対応するランタイムを選ぶ必要があります。また、Durable Functionsは2025年時点で一部のリージョンから提供が開始されました。東京リージョンなど主要リージョンでは利用可能ですが、利用前に自分の使うリージョンでサポートされているかAWSの最新情報を確認してください。

開発環境の準備としては、Durable Functionsに対応したAWS CLI・開発者用SDKを最新バージョンにアップデートしておくことが望ましいです。たとえばAWS SAM CLIやAWS CDKもDurable Functionsサポートのアップデートが入っていますので、最新リリースに更新しておきましょう。以上の前提を満たせば、Durable Functionsを使う準備は整います。

Lambda関数作成時にDurable Executionを有効化 – コンソール画面での新規関数設定方法

AWSマネジメントコンソールからDurable Functions対応の関数を作成するには、通常のLambda関数作成手順において追加のオプションを有効化します。まず「関数の作成」で「一から作成」（Author from scratch）を選択し、関数名やランタイム（Node.js 24 / Python 3.14 など対応ランタイム）を入力する基本情報画面まで進めます。その画面内に「耐久実行を有効にする (Enable durable execution)」といったチェックボックスが新たに表示されているので、これをオンにします。これがDurable Functionsを有効化する設定項目です。このオプションを有効にした上で関数を作成すると、その関数はDurable Execution対応となり、以降チェックポイント保存や待機機能が利用可能になります。なお、Durable Executionの有効化は関数作成時にしか設定できず、既存の関数に後から適用することはできない点に注意してください。

Durable Execution SDKの導入 – 耐久実行用ライブラリをコードに追加しLambdaハンドラを修飾

Durable Functionsをコードから利用するためには、対応するDurable Execution SDKライブラリを関数コードに組み込む必要があります。Node.jsの場合は@aws/durable-execution-sdk-js、Pythonの場合はaws-durable-execution-sdk-pythonといったパッケージが提供されています。コンソール経由で関数を作成した場合、これらSDKはランタイム環境にあらかじめインストールされていますが、本番環境では依存としてコードに含めバージョンを固定することが推奨されています。

コード上では、Durable Execution SDKが提供する関数ラッパーやコンテキストを利用します。例えばNode.jsならLambdaハンドラをwithDurableExecution(handler)でラップし、ハンドラ内でDurableContext（引数のcontext経由）を使ってstepやwaitメソッドを呼び出します。Pythonでもデコレーター@durable_stepや@with_durable_executionを使って似たように実装できます。このようにSDKを導入し、ハンドラ関数に適用することで、その関数がDurable Executionとして動作する準備が整います。

初めてのDurable Function実行 – Hello Worldで動作確認し基本的な流れを学ぶ

セットアップ後は、シンプルな例でDurable Functionsが正しく動作するか確認してみましょう。コンソールで新規作成時に提供されるサンプルコード（Hello WorldのDurable Function）を使うと簡単に試せます。例えばNode.js向けには、ステップ実行と待機を組み合わせたサンプルワークフローコードが自動生成されます。このコードをデプロイしてテスト実行すると、CloudWatch Logsのログストリーム上で各ステップの開始・終了や待機の開始・再開といったメッセージを確認できます。

実行履歴を見ることで、Durable Functionがどのように処理を進めているか把握できます。最初の例では、ログに「Step 1開始→完了」「Wait開始→○秒後に再開」「Step 2開始→完了」のような出力が順番に現れ、Durable Executionが正しくステップ実行と待機・再開を行っていることを確認できるでしょう。まずはこのHello World的なDurable Functionで基本的な流れを体験し、期待通りに動作するかを確かめてみてください。

導入時の注意点 – 既存のLambda関数には有効化できない点やIAM権限設定への留意

Durable Functions導入にあたっていくつか注意すべきポイントがあります。まず前述の通り、既存のLambda関数を後からDurable対応に切り替えることはできません。Durable Functionsを使いたい場合は、新規に関数を作成して「Durable Executionを有効化」オプションをオンにする必要があります。また、Durable Functionの実行ロール（LambdaのIAMロール）には追加の権限が必要です。コンソール経由で作成した場合、自動的にlambda:CheckpointDurableExecutionやlambda:GetDurableExecutionStateなど必要権限がロールに付与されますが、自前でCloudFormation/SAMを使う場合はこれらを忘れず設定してください。

さらに、Durable Functionsではコードの変更が実行中のワークフローに影響を与える点にも注意が必要です。実行中のDurable Functionは$LATESTバージョンではなく固定バージョン/エイリアスで呼び出すように推奨されています（実行途中でコードを変更するとリプレイ時に不整合が生じる可能性があるため）。開発段階ではこれを踏まえて、デプロイ戦略やバージョン管理を検討しましょう。以上の点に留意すれば、Durable Functionsをスムーズに導入・利用開始できるはずです。

AWSマネジメントコンソールからLambda Durable Functionsを有効化する手順を詳しく解説

ここでは、AWSマネジメントコンソールを使用してLambda Durable Functionsを有効化した関数を作成する具体的な手順を解説します。コンソールでのGUI操作を一つ一つ確認しながら、Durable Functions対応の関数を作成・デプロイ・テストする流れを見ていきましょう。初心者の方でも迷わないように、各ステップで画面上の項目名や選択肢を挙げながら説明します。

ステップ1: AWSマネジメントコンソールのLambda画面で新規関数作成を開始

まずAWSマネジメントコンソールにログインし、「Lambda」のサービスページに移動します。Lambdaの関数一覧画面から「関数の作成」ボタンをクリックして、新しい関数の作成ウィザードを開きましょう。この時点で、以降の手順は通常のLambda関数作成とほぼ共通です。新規関数の作成画面が表示されたら、次のステップで基本情報を入力していきます。

ステップ2: 基本情報の入力 – 関数名を指定し、ランタイムにNode.js 24またはPython 3.14を選択

新規関数作成ウィザードでは、まず基本的な設定を行います。関数名を任意に決めて入力します（例: myDurableFunction）。次にランタイムを選択しますが、Durable Functions対応のNode.js 16以降（Node.js 24推奨）やPython 3.14を選びます。※Durable Functionsは対応ランタイムが限定されるため、必ずサポートされているランタイムを選択してください。今回は例としてNode.js 24を選びます。また、アーキテクチャ（x86/ARM）や権限設定（デフォルトでは新しいロールの作成でOK）など、他の基本項目も通常どおり設定します。

ステップ3: Durable Executionの有効化 – Durable execution設定をオンにして新機能を利用可能に

基本情報のフォーム内に、Durable Functions専用の設定項目があります。例えば「コードとランタイム」のセクション下部に「Durable executionを有効にする」というチェックボックスが表示されます。これがDurable Functionsを有効化するためのオプションです。このチェックボックスにチェックを入れてください。デフォルトではオフになっていますので、Durable Functionsを使う場合は必ずオンにします。この設定により、作成される関数がDurable Execution対応（チェックポイント機能などが有効）になります。なお、一度関数を作成すると後からこの設定を変更できない点に注意してください。

ステップ4: 実行ロールと権限の確認 – Durable Functions用のIAM権限が自動付与されていることを確認

Durable Executionを有効化して関数を作成すると、Lambdaは自動的に実行ロールに必要な権限を追加します。例えばlambda:CheckpointDurableExecutionやlambda:GetDurableExecutionStateといったDurable Functions特有の権限が付与されます。コンソール上でも、関数作成後の設定タブでIAMロールのポリシーを確認すると、これらの権限が含まれたポリシー（AWSLambdaBasicDurableExecutionRolePolicy等）がアタッチされているはずです。手動でロールを作成した場合も同様の権限を付与する必要があります。自動付与された権限は原則そのままで問題ありませんが、必要に応じてリソースを絞る（ポリシーのResource欄を特定の関数ARNに限定する等）ことでよりセキュアにできます。ひとまずこの時点では、実行ロールにDurable Functions用権限が付いていることを確認する程度で大丈夫です。

ステップ5: コードエディタでDurable関数コードを編集 – サンプルのコードテンプレートを貼り付け

関数が作成できたら、次にコードを入力します。コンソールのコードエディタを開き、テンプレートとして用意されたDurable Functionのサンプルコードを利用すると良いでしょう。例えばNode.jsの場合、コンソール作成直後に生成されるindex.mjsにはDurable Functionsの雛形コードが含まれています。これをそのまま使っても構いませんし、公式ドキュメントに載っているサンプルコードをコピー＆ペーストしても構いません。

サンプルコードでは、withDurableExecution(async (event, context) => {...})でハンドラをラップし、内部でcontext.stepやcontext.waitを用いた簡単な処理が定義されています。必要に応じて自分のユースケースに合わせコードを修正してください。編集が終わったら「デプロイ」ボタンを押してコードをデプロイします。これで関数が最新コードに更新され、Durable Functionsとして動作する準備が整いました。

ステップ6: 関数をデプロイしてテスト – Durable Executionの実行ログを確認し正常に動作することを検証

最後に、作成したDurable Functionが期待通り動作するかテストしましょう。コンソールのテスト機能を使って関数を実行します（適当なテストイベントを投入してみます。特に入力が不要な場合はデフォルトの空イベントで実行可能です）。関数が呼び出されると、Durable Functionsでは処理途中で一旦関数が終了するケースがあります。例えばwaitを含むコードの場合、待機開始時に関数が中断され、指定時間後に自動再実行されます。

こうした挙動はCloudWatch Logsのログ出力や、Lambdaの「モニタリング」タブにあるDurable Executionの実行履歴で確認できます。ログに各ステップの実行完了や待機の開始・終了が順番に記録されていれば成功です。例えば「STEP_COMPLETE」「FUNCTION_SUSPEND」「FUNCTION_RESUME」といったイベントがCloudTrailやログに出力されます。最終的に全ての処理が完了し、期待する結果が得られればテストは成功です。ここまでで、コンソールを使ったDurable Functions対応関数の作成からデプロイ、テストまでの一連の手順が完了しました。

SAM／CDKを使ってLambda Durable Functionsをデプロイする方法を詳しく解説

次に、AWS SAM（Serverless Application Model）やAWS CDK（Cloud Development Kit）を用いて、コードやテンプレートからLambda Durable Functionsをデプロイする方法を解説します。インフラストラクチャをコードで管理している場合や、自動デプロイのパイプラインに組み込みたい場合には、SAMやCDKでDurable Functions対応の関数を扱うことになります。その際に必要な設定項目や記述方法、注意点について説明します。

SAMによるDurable Functionデプロイ – SAMテンプレートでのDurable Execution設定と実装のポイント

SAMを使用してDurable Functionをデプロイする場合、テンプレート（template.yamlもしくはtemplate.yml）内でLambda関数リソースにDurable対応の設定を追加します。具体的には、AWS::Serverless::FunctionまたはAWS::Lambda::FunctionリソースでDurableConfigというプロパティを指定します。DurableConfig内ではExecutionTimeoutやRetentionPeriodなど、Durable Executionに関する各種パラメータを設定可能です。例えば以下のようになります。

DurableConfig:
ExecutionTimeout: 3600
RetentionPeriodInDays: 30
AllowInvokeLatest: false

上記は1時間（3600秒）の実行タイムアウト、状態保持期間30日、そして実行時には特定バージョンのみ許可（$LATESTを許可しない）という設定例です。SAMの場合、YAMLでこれらを記述しデプロイすることで、対応するLambda関数がDurable Execution有効となります。

SAMテンプレートの記述例 – DurableConfigプロパティを含むAWS::Lambda::Functionリソース定義

より具体的に、SAM/CloudFormationテンプレートでの定義例を示します。Serverless::Functionを使う場合:

MyDurableFunction:
Type: AWS::Serverless::Function
Properties:
FunctionName: my-durable-function
Runtime: python3.14
Handler: app.handler
DurableConfig:
ExecutionTimeout: 31536000 # 1年（秒単位）
RetentionPeriodInDays: 7
AllowInvokeLatest: true

同様にAWS::Lambda::Functionリソースを直接使う場合もDurableConfigを指定できます。上記の例では、Lambda関数my-durable-functionに対しDurable Executionを有効化し、最大実行時間を1年、状態保持期間を7日としています。このテンプレートを用いてsam deployすれば、Durable Functions対応の関数がデプロイされます。テンプレート記述時はインデント等のYAML構文ミスに注意しましょう。

AWS CDKでDurable Functionを実装 – Durable Executionに対応したLambda関数をコードで定義

AWS CDKでDurable Functionsを使う場合も、基本的にはCloudFormationの定義をコードで記述する形になります。CDKのLambda Functionコンストラクト（例えばlambda.Functionクラス）にはDurableConfigに対応するプロパティが用意されています。例えばTypeScriptのCDKコードでは:

new lambda.Function(this, 'MyDurableFunc', {
runtime: lambda.Runtime.NODEJS_18_X,
code: lambda.Code.fromAsset('lambda'),
handler: 'index.handler',
durableConfig: {
executionTimeout: cdk.Duration.days(7),
retentionPeriod: cdk.Duration.days(30),
allowInvokeLatest: false
}
});

このようにdurableConfigプロパティに対し、CDKのDuration型でタイムアウトや保持期間を指定できます。CDKではプロパティ名がCamelCaseになっている点に注意してください（executionTimeout等）。CDKコード上で上記のように設定した上でcdk deployを行えば、Durable Functionsが有効化されたLambda関数がプロビジョニングされます。

CDKコードの例 – DurableConfigを設定したLambda関数Constructの記述サンプル

さらに具体的なCDKコード例として、PythonでDurable Functionを定義する場合を考えます（CDK v2を前提）。

function = lambda.Function(self, \"MyDurableFunction\",
runtime=lambda.Runtime.PYTHON_3_14,
code=lambda.Code.from_asset(\"lambda\"),
handler=\"app.handler\",
durable_config=lambda.DurableConfig(
execution_timeout=Duration.days(1),
retention_period=Duration.days(7),
allow_invoke_latest=False
)
)

上記のようにDurableConfigオブジェクトを渡すことで、CDKでもDurable Executionのパラメータを指定できます。このようなCDK定義をdeployすると、自動的に実行ロールへの権限付与も行われ、Durable Functionが完成します。CDKではTypeScript/Java/Pythonいずれも似たようなプロパティ構成ですので、公式ドキュメントを参照しつつ記述してください。

SAM/ CDKデプロイ時の注意点 – ツールのバージョンアップやデプロイ後の設定確認に留意

SAMやCDKを用いる際の注意点として、まずローカルのツールを最新バージョンにしておくことが重要です。Durable Functions対応は比較的新しいため、古いバージョンのSAM CLIやCDKではDurableConfigプロパティ自体が認識されない場合があります。各ツールのリリースノートを確認し、Durable Functionsサポートが追加されたバージョン以降にアップデートしてから利用してください。

また、テンプレートやコードによるデプロイ後は、コンソールで関数の設定を確認し、Durable Executionが有効になっていることやIAMロールに必要な権限が含まれていることをチェックしましょう。特にCDKの場合、一部プロパティ名が異なることやデフォルト挙動に注意が必要です。例えばCDKでallowInvokeLatest: falseを指定し忘れると既定で$LATESTが許可されてしまう可能性があります。デプロイ時のスタックイベントや出力されるテンプレートを確認し、意図した設定になっているかを検証することをお勧めします。

Lambda Durable Functionsのアーキテクチャと内部の仕組みをわかりやすく解説

このセクションでは、Lambda Durable Functionsが内部でどのように動作しているか、そのアーキテクチャの概要を解説します。Durable FunctionsはLambdaの実行モデルに新たな要素を加えた形となっており、チェックポイントの保存場所やリプレイの流れ、Durable Execution SDKの役割など、通常のLambdaとは異なる内部処理があります。これらを理解することで、Durable Functionsの動作を正しく予測・設計でき、トラブルシューティングの際にも役立ちます。

Durable Executionの内部構造 – Lambda実行環境内でのチェックポイント保存と再開処理の流れ

Durable Functionsの内部構造は、Lambdaの実行環境に耐久実行用のコンポーネントが追加された形です。関数が実行されると、Durable Execution SDKがコード中のstepやwaitの呼び出しをフックして、各ステップ完了時点での実行状態（戻り値や実行済みフラグなど）を専用のストレージに保存します。保存先はAWS内部の管理ストレージ（例えば専用のDynamoDBテーブルやS3領域が裏で利用されていると考えられます）であり、このストレージが関数の実行ごとに隔離されて記録を保持します。

関数が待機に入ると、実行環境はいったん関数を終了させます。しかし実行環境自体（コンテナ）はキャッシュされている場合もあり、環境変数や/initでの初期化状態は保存されたままになる点は通常のLambdaと同様です。そして再開時、Lambdaサービスが新たなInvokeを発行し、Durable Executionはその保存済み状態を取り出して、ハンドラ関数を最初から起動します。起動直後、SDKが前回までに完了したステップの情報を参照し、完了済み部分をスキップして未完了の処理から実行を再開する、という流れです。このようにLambdaの実行環境と耐久実行用ストレージ・SDKが連携することで、長時間にわたる実行がシームレスに行われています。

リプレイ機構の詳細 – 中断時に関数を終了し、再起動後にチェックポイント済み処理をスキップして続行

Durable Functionsのリプレイ機構では、待機やエラーで関数が中断されると、一度その関数実行が正常終了したかのように処理が終わります。例えばcontext.wait(1時間)を呼ぶと、「待機を開始した」というチェックポイントを記録してLambda関数がいったん終了します。その後1時間後にLambdaが再Invokeされると、Durable Execution SDKはまず前回記録された実行履歴を読み込み、「待機完了」に相当する状態を構築します。そしてハンドラ関数の先頭からコードを実行し始めますが、この際に各step呼び出しで「このステップはすでに完了済みか？」を内部的にチェックします。

完了済みマークのあるステップについては、その中身の処理（例えばAPIコール等）をスキップし、直前に記録されたそのステップの戻り値を復元します。こうして既に終わった部分は二度実行せず、未完了だった次のステップから処理を再開できるのです。これがいわゆる「checkpoint & replay」の仕組みで、関数再起動後に前回の続きから処理が走るように見える所以です。なお、リプレイ時には同じイベント入力が再びハンドラに渡されますが、SDKが内部で完了状況を管理しているため、開発者は自分で条件分岐を入れる必要はありません。この透明なリプレイ処理により、Durable Functions利用者は普通にコードを書くだけで実行再開が保証されるようになっています。

Durable Execution SDKの役割 – チェックポイント管理や待機処理を透過的に実現するフレームワーク

Durable Functionsを支えるDurable Execution SDKは、開発者の書いたコードからチェックポイントの記録・復元や待機制御といった処理を引き受けるフレームワーク部分です。SDKはLambda関数の起動時にDurableContextを初期化し、context.stepやcontext.waitの呼び出しをフックして内部処理を行います。例えばcontext.stepが呼ばれると、SDKは引数で渡されたコールバックを実行するとともに、実行後にその戻り値を保存します。また例外発生時にはリトライ戦略に従って関数を終了・再実行する制御もSDKが行います。

さらにcontext.waitでは、指定時間をタイマーセットし、その場で関数を終了させる、という通常のコードではできない操作もSDKが裏で実現します。言わばSDKがLambdaランタイムと協調し、「今この関数を終わらせて○時間後に再度起動してね」という指示をしているイメージです。これらの複雑な制御はすべてSDKが肩代わりしてくれるため、開発者は単純にSDKのメソッドを使っているだけで高度な耐久実行が実現します。Durable Execution SDKは各対応言語ごとに用意されており、Lambdaプラットフォームとの橋渡し役を担っているのです。

状態データの保存先と保護 – 永続ストレージに実行状態を保存し、自動暗号化でセキュアに保管

Durable Functionsにおけるチェックポイントデータや実行状態データは、AWS内部の永続ストレージに保存されます。その具体的な保存先はAWSが管理しており開発者からは直接見えませんが、一般にはDynamoDBやS3に類似した分散ストレージ基盤上に記録されていると考えられます。この保存はすべて暗号化された状態で行われ、同一アカウント内でも他の関数実行とは分離されています。Durable Function実行ごとに一意の実行IDが割り当てられ、その単位で状態データが保管・参照されます。

また、RetentionPeriod（状態保持期間）を過ぎた古い実行のデータはAWS側で自動的に削除されます。デフォルトでは30日程度の保持期間が設定されますが、要件に応じて1日から最大365日まで調整可能です。状態データには各ステップの出力やタイムスタンプ、エラーログなどが含まれ、CloudTrailのDurableExecutionデータイベントとしてもその操作ログが残されます。これらのデータ保存・保護機構はAWS Lambdaサービス自体の一部として提供されるため、開発者は自分でセキュリティ実装をすることなく、安全かつ信頼性の高い状態保持が利用できます。

Step Functionsを使わない長時間実行アーキテクチャ – Lambda単体でワークフローを完結させる設計

Durable Functionsのアーキテクチャの特筆すべき点は、「長時間実行=ステートマシンによるオーケストレーション」という従来の常識を覆し、Lambda単体でワークフローを完結させていることです。AWS Step Functionsはステートマシン（状態遷移図）に従って複数のLambda間で制御するアーキテクチャでしたが、Durable Functionsは1つのLambdaプロセス（厳密には再起動をまたぎますが論理的には単一関数）内で完結します。

この設計により、余計なサービス間通信や状態伝搬のオーバーヘッドが減り、よりシンプルで高速なワークフロー実行が可能になります。もちろんStep Functionsには可視化やネイティブサービス統合といった利点がありますが、Durable Functionsのアーキテクチャは「コードで書けるシンプルさ」と「Lambdaのパフォーマンス」を重視した形です。Lambda内部にリトライや待機のロジックを組み込みつつも、それをフレームワークが自動処理することでコードは簡潔に保つというバランスの取れた設計となっています。このようなLambda単体完結型のアプローチは、AWSのサーバーレスプラットフォームが一段進化したものと言えるでしょう。

長時間バッチ／ワークフローをLambda Durable Functionsで実装する方法を具体例を交えつつ解説

ここでは、実際に長時間実行が必要なバッチ処理やワークフローをLambda Durable Functionsでどのように実装できるか、具体例を通じて解説します。Durable Functionsは長時間のバッチ処理に理想的な機能を備えていますが、設計上押さえておくべきポイントもあります。以下に、典型的な長時間処理シナリオ（大規模データのバッチ、承認待ちを含む業務フロー、外部サービスの完了待ちなど）に沿って、Durable Functionsの利点と実装パターンを説明します。

長時間バッチ処理のニーズ – Lambda Durable FunctionsがLambdaタイムアウトを超える処理を可能にする解決策

企業システムでは、数時間から場合によっては数日かかるようなバッチ処理のニーズが存在します。従来、Lambda単体では15分以上の処理ができないため、EC2やオンプレミスサーバーでバッチを動かしたり、Step Functionsで刻んだステップを連携させる必要がありました。Durable Functionsはまさにこの課題への解決策です。Lambdaのタイムアウトを超える長時間処理を、小分けのステップ＋待機として表現することで、Lambda環境で実現します。

例えば、数百万レコードのデータをETL処理するようなバッチを考えます。Durable Functionsを使えば、データをチャンクに区切って1チャンクずつcontext.stepで処理し、一定件数ごとにcontext.waitで一時停止する、といった形で実装可能です。全体では何時間もかかる処理でも、Lambdaは断続的に動くためタイムアウトしません。このようにDurable Functionsは、Lambdaを長時間バッチ処理に活用する道を開き、インフラ管理を伴う別環境を使わずにサーバーレスで長大な処理を完結できるようにしています。

大規模データ処理を段階的に実行 – 処理を複数ステップに分割し、チャンク単位で順次完了させるアプローチ

Durable Functionsで長時間のデータ処理を行う際のポイントは、データを適切なサイズに分割し、ステップごとに処理することです。例えば1億件のレコードを処理する場合、一度に全件を扱うのではなく、1万件ずつ10000件×10000回のようにチャンクに区切って順次処理します。具体的にはcontext.step内で「次の1万件を処理する処理」を実行し、その完了をもってチェックポイントを作成、次のステップへ進む形です。

このように段階実行すれば、各ステップは比較的短時間で終わるためLambdaの実行制限にもかからず、全体として大きなバッチジョブを完遂できます。各ステップ完了時に進捗を保存しているので、途中でエラーが起きても最後の正常完了ステップまでの成果は有効ですし、再実行すれば途中から処理を再開できます。結果的に、大規模データの処理でもDurable Functionsなら堅実かつ効率的に進めることが可能です。このステップ分割アプローチは、Durable Functionsを用いた長時間バッチ実装の基本と言えるでしょう。

人手承認を含む長期ワークフロー – 承認待ちのために関数を待機させ、許可後に処理を再開する実装

Durable Functionsは、人間の承認や入力待ちが入るような業務プロセスにも適しています。例えば、社員の休暇申請フローを想定します。申請を受け付けた後に上長の承認待ちとなり、承認されたら最終処理（記録や通知）を行う、といった流れです。このケースでは、承認待ち部分でcontext.waitかcontext.create_callback()を使用します。具体的には、申請受付ステップの後でcontext.wait_for_condition()を呼び出し、人事システムで承認フラグが立つのをポーリングで待つ方法があります。あるいはcontext.create_callback()で承認完了通知用のトークンを発行し、外部からの承認完了API呼び出しで再開する方法も取れます。

いずれにせよ、Durable Functions上では関数が承認完了まで停止し、完了時に自動再開して後続処理（結果の反映や通知）を行います。待機中はリソース消費がなくコストもかからないため、数日承認が保留になっても問題ありません。このように、Durable Functionsなら人手を挟む長期プロセスもサーバーレスでスマートに実現できます。

外部サービス完了待ちの実装 – Durable Functionsで定期ポーリングや条件待ちを行い他システムとの連携を実現

長時間ワークフローでは、外部システムの処理完了を待つ場面もよくあります。例えば外部のデータ集計サービスにジョブを投げ、その完了を待って続きを実行するケースです。Durable Functionsではこのようなポーリング処理も簡単に書けます。具体的には、context.wait_for_condition()メソッドを使い、一定間隔で外部APIを呼び出して結果をチェックする処理をリトライします。

例えば「5分おきに外部サービスのステータスを確認し、完了フラグが立ったら待機解除」というロジックをcontext.wait_for_conditionに渡します。Durable Functionsはその関数内部で自動的にスリープ→再実行を繰り返し、条件が満たされると先に進みます。この間、関数自体は待機→再起動を繰り返す形になりますが、実装者はあたかもループを書いている感覚で条件待ちを表現できます。これにより、他システムと連携した長時間処理（他システム処理完了待ちのバッチ連携など）もサーバーレスで完結し、クロスシステムなワークフローがシンプルに実現できます。

長時間実行の監視と途中経過の取得 – 実行履歴やログを活用して長時間ワークフローの進行状況をトラッキング

長時間実行するバッチやワークフローでは、その進捗状況の監視が重要です。Durable FunctionsではCloudWatch LogsやCloudTrail、LambdaのExecution historyなどを活用して途中経過を把握できます。例えば、各ステップの開始・終了ログをCloudWatch Logsに出力することで、「現在全体工程の何%まで完了したか」「最後に成功したステップはどこか」などを確認可能です。またCloudTrailではCheckpointDurableExecution（チェックポイント作成）やSendDurableExecutionCallbackSuccess（コールバック成功）といったイベントが記録されるため、承認が完了したタイミングなど重要イベントの履歴も追跡できます。

さらに、Execution history（関数の詳細画面で確認できるDurable Executionの履歴）を見ると、各Durable Function実行ごとの開始・終了・中断・再開のタイムラインが表示されます。これらを総合的に活用することで、長時間実行中のワークフローが健全に動いているか、どのステップで待機中なのか、エラーで停止していないか等を管理者が把握できます。運用時には適切なログとメトリクスを設定し、必要に応じてSNS通知などで異常をアラートすると良いでしょう。

Step FunctionsやAzure Durable Functionsとの違い・使い分けを徹底解説

Durable Functionsは、既存のAWS Step Functionsや他クラウドのAzure Durable Functionsと機能的に重なる部分があります。ここでは、それぞれとの違いを整理し、どのように使い分けるべきかを解説します。Step FunctionsはAWSの従来からのサービスであり、Azure Durable FunctionsはマイクロソフトAzureの類似機能です。Durable Functionsが登場したことで、AWS上でのワークフロー実装には複数の選択肢が揃った形になります。それぞれの強み・弱みを理解し、適材適所で使い分けましょう。

Step Functionsとのアプローチの違い – コードでワークフローを記述するDurable Functionsと、定義ファイル（JSON）で構築するStep Functions

AWS Step FunctionsとLambda Durable Functionsは、ワークフローを実現するアプローチが根本的に異なります。Step FunctionsはJSONもしくはYAMLで状態遷移図（ステートマシン）を記述し、その定義に従って複数のサービス（主にLambda関数）を呼び出す形式です。一方、Durable Functionsはプログラミング言語のコード上でワークフローを記述し、内部でそのコードに従ってLambdaが処理を進めます。言い換えると、Step Functionsは外部にワークフロー定義を切り出す（宣言的定義）アプローチであり、Durable Functionsは関数内にワークフローを内包する（命令的定義）アプローチです。

この違いにより、Step Functionsはフロー全体を可視化しやすく、分岐やエラー処理も見通しよく定義できますが、複雑なビジネスロジックを入れ込むには不向きです。一方Durable Functionsはコードで細かな処理を書ける柔軟性がありますが、フロー全体像はコードを読まないとわからないという側面もあります。それぞれ長所短所があるため、どちらが優れるというより使い慣れた手法やプロジェクトの性質に応じて選択すると良いでしょう。

Step Functionsとの機能比較 – サービス統合や実行可視化に優れるStep Functionsと、コード内で細かな制御が可能なDurable Functions

機能面で両者を比較すると、Step FunctionsはAWSの各種サービスとの統合が豊富で、たとえばAWS SDK呼び出しをネイティブにステートマシン内で行えたり、GlueやSageMakerなど他サービスを直接組み込める利点があります。また、実行の可視化（どのステップが実行中/成功/失敗か）がマネジメントコンソール上で一目瞭然で、オペレーション観点で優れています。さらに同時並行の分岐やMap状態など複雑な制御フローも視覚的に表現しやすいです。

一方、Durable Functionsはコード内で全てを制御するため、極めて柔軟です。任意のタイミングでループや条件分岐を入れたり、サードパーティのAPIロジックを組み込んだりが容易です。Step Functionsでは表現しづらい複雑なビジネスロジックも、Durable Functionsなら通常のプログラミングの延長で実装できます。また、コーディングしている分、Gitでの変更履歴管理やコードレビューも行いやすいという利点もあります。まとめると、「AWSサービス連携やオーケストレーションに強いのがStep Functions」、「細かいロジックやカスタム処理を入れ込みやすいのがDurable Functions」と覚えると良いでしょう。

用途に応じた使い分け – 外部サービス連携や高度な分岐が必要ならStep Functions、シンプルな順次処理はDurable Functionsが適合

実際にどちらを使うべきかはユースケース次第です。例えば、人の承認や複数の外部サービス呼び出し、エラー時の複雑な分岐処理など高度なワークフローを、チームで可視化しながら開発・運用したい場合にはStep Functionsが適しています。Step Functionsなら各ステップの状態がGUI上で追えるため、運用メンバーも含めて状況把握が容易です。また、非エンジニアとも連携してワークフロー図を検討したい場合も視覚的なStep Functionsが有利でしょう。

一方、処理自体は順次または簡単な繰り返しが中心で、開発者だけで実装・運用が完結するようなケースではDurable Functionsの方が実装量が少なく済みます。例えば単純なバッチ処理や、1つのサービス内で閉じるデータ処理フローなどはDurable Functionsがシンプルです。またコスト面でも、Durable Functionsは待機中課金がなくステップ課金も安価と予想されるため、ステート遷移が多発する大規模フローを低コストに実行したい場合にも向いています。総じて、可視化・オーケストレーション重視ならStep Functions、コードの表現力やコスト効率重視ならDurable Functions、といった使い分けになるでしょう。

Azure Durable Functionsとの共通点 – ワークフローのコード化やチェックポイント方式など類似するコンセプト

マイクロソフトAzureのDurable Functions（Azure Functionsの拡張機能）とAWS Lambda Durable Functionsは、その名前が示す通りコンセプトがよく似ています。どちらも関数型のサーバーレス環境でワークフローをコードで表現し、長時間実行や関数間の呼び出しを可能にする仕組みです。例えばAzure Durable Functionsではオーケストレーター関数とアクティビティ関数とに役割を分け、関数の状態を記録・再開するパターンを取りますが、AWS Durable Functionsもチェックポイントとリプレイによって同様の耐久実行を実現します。

また、Azure側にもWait（タイマー）やExternal Event（一種のコールバック）といった概念があり、人間の承認待ちや一定時間スリープなど似た機能が提供されています。さらに並列実行やファンイン・ファンアウトパターンも両者サポートするなど、全体的なコンセプトは共通しています。要するに、Durable Functionsというアイデア自体はAzure発のものですが、AWS版Durable Functionsもほぼ同等の機能を提供し、サーバーレスコードによるワークフロー実現というトレンドに沿った実装になっていると言えるでしょう。

Azure Durable Functionsとの相違点 – 開発言語やフレームワークの違い、AWS Lambdaならではの統合環境による利点

共通点が多い一方で、AzureとAWSのDurable Functionsにはいくつか相違点もあります。まず、Azure Durable FunctionsはC#やJavaScript、Pythonなど複数言語で利用できますが、Azure Functions自体の仕組み上、.NETでの利用が主流でした。一方AWSのDurable Functionsは現時点でJavaScript（TypeScript）とPythonが主対応で、今後Javaや他言語にも拡大予定です。つまり利用可能な開発言語に若干の差があります。

また、AzureではDurable FunctionsはFunctionsランタイム拡張としてライブラリを導入する形で、開発者がオーケストレーター関数/アクティビティ関数をそれぞれ実装していきます。AWSでは1つのLambda関数内でDurable Executionを完結させる設計で、仕組みは似ていますが開発モデルに微妙な違いがあります。さらに、AWS版Durable FunctionsはLambdaの他の機能（例えばProvisioned ConcurrencyやLambdaのVPC統合など）ともそのまま統合できる利点があります。総合すると、Azure/AWSで基本概念は同じものの、細部ではプラットフォームに合わせた違いがあるため、他クラウドから移行してくる場合は用語や実装パターンの差異に注意が必要です。ただしエッセンスは共通しているので、一度片方に習熟すればもう一方も理解しやすいでしょう。

Lambda Durable Functions利用時のベストプラクティスと注意点まとめ【徹底解説】

最後に、Lambda Durable Functionsを実際の開発・運用で使う上でのベストプラクティスと注意点を紹介します。耐久実行という特性上、通常のLambda開発とは異なる考慮が必要な点があります。例えばリプレイによる再実行への備えや、長期間状態を保持することによる影響、デバッグ方法などです。以下に主要なポイントをまとめますので、Durable Functionsを活用する際のガイドラインとして参考にしてください。

リプレイを考慮した冪等性設計 – ステップ内の処理で副作用を避け、再実行時にも結果がぶれないようにする

Durable Functions開発でまず留意すべきは、処理の冪等性（Idempotency）です。Durable Functionsではリプレイによって同じステップを二度実行しないよう制御されますが、場合によっては関数がエラーで完全に失敗し、外部から再度イベントを受けて最初から実行し直す可能性もあります。その際、各ステップが何度実行されてもシステムの状態が不整合にならないよう設計することが重要です。

具体的には、ステップ内で外部サービスに書き込みを行う場合などは、重複実行してしまっても副作用が生じないように工夫します。例えば一意なトランザクションIDを使って二重処理を防ぐ、更新系操作をできるだけcontext.stepの中に閉じ込めてDurable Functions側の再実行制御に委ねる、といった方法があります。また、ステップ開始時点で対象データの状態をチェックし、既に処理済みならスキップする、といった冪等性担保のコードを入れておくのも有効です。これらの工夫により、リプレイや再呼び出しが発生しても結果が一貫し、システム状態が乱れないようにします。

コード更新とバージョン管理 – 実行中ワークフローに影響を与えないよう$LATESTではなくバージョン固定を使用

Durable Functionsでは、長期間実行されるワークフロー中にLambda関数のコードを変更するケースに注意が必要です。というのも、Durable Functionは一度実行されると最大で1年近く同じコードで断続的に動き続ける可能性があり、その間にデプロイされた新コードが即座に反映されるわけではありません。実行中のインスタンスは古いコードで進行し、次回Invoke時も通常は$LATESTエイリアスを指すため新コードに切り替わってしまいます。これにより、途中からコードが差し替わり、リプレイ時の挙動が変わってしまうリスクがあります。

この問題を避けるためのベストプラクティスは、Durable Functionsを特定のバージョンまたはエイリアス経由で呼び出すことです。AllowInvokeLatestオプションをfalseに設定し、ワークフロー開始時に関数の特定バージョンをInvokeすることで、その実行中はコードが固定されます。開発・デプロイ時には、新バージョンを発行してからDurable Functionのフローを開始するようにすると、安全にコード更新ができます。また、コード変更によってステップの内容や順序が変わると、既存の実行には対応できなくなる恐れもあるため、後方互換性を考慮した変更を心がけることも重要です。

エラーハンドリングのベストプラクティス – 再試行可能な例外と致命的な例外を区別し、適切にcatchして処理

Durable Functionsには自動リトライ機構がありますが、すべてのエラーを無制限に再試行するのが良いわけではありません。ベストプラクティスとして、再試行すべき一時的エラーと即座に失敗すべき致命的エラーを明確に区別することが挙げられます。例えば一時的なネットワークエラーやスロットリング（HTTP 429, 503等）は数回リトライすれば成功する可能性が高いので、自動リトライ対象とします。一方、入力データ不備や認可エラーなど、リトライしても成功しない性質のエラーは、早めにcatchしてワークフロー全体を失敗させた方がよいでしょう。

Durable Functionsのコード内では、try-catchブロックを活用してこの区別を実装します。context.stepの中で発生し得る例外を予測し、再試行すべき例外の場合は何もせずSDKに任せ、再試行すべきでない例外の場合はcatchしてその場でthrowし直すか、ワークフロー用に定義した致命的エラーとしてマークします。また、SDKのretryStrategyをカスタマイズして特定のエラーのみリトライするよう制御することも可能です。適切なエラーハンドリング戦略を組むことで、無駄なリトライで時間を浪費したり、逆にすぐ諦めてしまったりすることを防ぎ、効率的で信頼性の高いワークフロー実行が実現できます。

状態データのサイズ管理 – 大きなデータは外部ストレージへ退避し、チェックポイントに保存する情報を最小化

Durable Functionsでは各チェックポイントに任意のデータ（ステップの戻り値など）を保存できますが、そのサイズには注意が必要です。大量のデータをそのまま状態として持ち回りすると、チェックポイント保存・読み込みに時間がかかったり、内部ストレージの容量を圧迫してコスト増や性能低下を招く可能性があります。ベストプラクティスは、チェックポイントに保存するデータは本当に必要な最小限にとどめ、巨大なデータセットはS3やDynamoDBなど外部の永続ストアに保管することです。

例えば、前段のステップで生成した大きなレポートファイルがある場合、それを直接次のステップに渡すのではなく、一旦S3にアップロードして、そのキー（パス）だけをチェックポイントに保存するようにします。次のステップではキーを読み出してS3からデータを取得すれば良いでしょう。こうすることで、Durable Functions側で保持する状態は小さく抑えられ、全体の効率と信頼性が向上します。また、RetentionPeriod経過後に消える状態データしかDurable Functions上には残らないため、長期保管が必要な成果物も外部ストレージに保存しておく方が安全です。要するに「Durable Functions上の状態は軽量に」というのが重要なベストプラクティスです。

監視とロギングの徹底 – CloudWatch LogsやCloudTrailを活用して長時間実行の進捗とチェックポイントを可視化

Durable Functionsを運用する際は、通常のLambda以上に監視とロギングを重視しましょう。長時間実行のワークフローでは、途中経過や停止状況を把握することが特に重要です。前述の通り、Durable Functionsは実行履歴やCloudTrailイベントで内部動作を確認できますが、加えてアプリケーションログにも適切な情報を出力することが推奨されます。

各ステップの開始・終了、重要な変数の値、エラー発生箇所などをCloudWatch Logsに記録すれば、何時間も続く処理でも今どの段階か追跡できます。例えば「Step1開始」「Step1完了：件数1000処理」「承認待ち開始：ID=abc123」等のログを埋め込んでおくと、運用者が状況を把握しやすくなります。さらに、CloudWatch Logsのメトリクスフィルタやアラームを活用して、エラー検出時に通知することもできます。CloudTrailのDurable Executionデータイベントも有効にしておけば、AWS側でのチェックポイント作成や再開イベントも監査できます。これらにより、長時間実行のブラックボックス化を防ぎ、確実な監視体制を整えることができます。

開発環境での検証ポイント – ローカル実行テストの難しさや、タイムアウト設定値に注意して挙動を確認

Durable Functionsの開発・テストでは、いくつか押さえておきたいポイントがあります。まず、ローカル環境で完全なDurable Executionをシミュレーションするのは困難です。Lambdaのクラウドサービスと内部ストレージが絡むため、ローカルテストではDurable部分は擬似的にしか検証できません。LocalStackなど一部ツールがDurable Functionsをサポートする動きもありますが、基本的にはクラウド上で実際に動かしてテストするのが確実です。

また、ExecutionTimeout（最大実行時間）の設定値には十分注意しましょう。例えばExecutionTimeoutを極端に長く（1年など）設定すると、予期せぬ無限リトライやバックエンドの長期占有を許してしまう可能性があります。ワークフローに必要な長さに見合った適切な値を設定することが大事です。さらに、開発中に頻繁にデプロイを繰り返す場合、前述の通り実行中インスタンスへの影響が出ないようバージョン管理を徹底する必要があります。テスト段階から、バージョンごとに別のエイリアスを使って実行するといった方法で検証すると安全です。総じて、Durable Functions開発ではクラウド上での挙動を確認しつつ、時間に関わる設定と変更管理に細心の注意を払うことが安定稼働への近道です。

Lambda Durable Functionsにおけるタイムアウト・リトライなどの制限と料金の考え方を解説

最後に、Lambda Durable Functionsを利用する上で知っておきたい制限事項や料金モデルについて整理します。Durable Functionsは強力ですが、無制限に何でもできるわけではなく、いくつかの上限やルールがあります。また、料金も従来のLambdaとは少し異なる考え方が必要です。ここでは、タイムアウト設定や状態保存期間、リトライ挙動の制限、そして料金の仕組みとコスト見積もりのポイントについて説明します。

ExecutionTimeoutの上限 – Durable Functionsの最大実行時間は1年（31,536,000秒）まで設定可能

Durable Functionsでは関数ごとにExecutionTimeout（実行タイムアウト）を設定できます。これはワークフロー全体が許容される最大実行期間を表し、秒数で指定します。上限は31536000秒（=365日）つまり1年です。デフォルトではおそらく24時間程度に設定されている場合がありますが、要件に応じて数時間から数十日、最大で1年まで延ばすことができます。ただし、無尽蔵に長く設定すれば良いわけではなく、設定した時間に達した時点でワークフローがタイムアウト失敗とみなされる点には注意が必要です。例えばExecutionTimeoutを3日（259200秒）に設定したなら、開始から3日以内に全処理が完了しないと自動的にタイムアウトエラーとなります。この値はワークフローの性質に合わせて適切に見積もる必要があります。

状態保存期間（RetentionPeriod）の制限 – チェックポイントデータは最大365日間保持され、期間超過後は自動削除

Durable Functionsではチェックポイントや実行履歴データを保存する期間をRetentionPeriodInDaysで指定できます。上限は365日（1年）で、デフォルト値は30日程度とされています。この期間を過ぎたデータはAWSによってクリーンアップ（削除）されます。RetentionPeriodを長く設定すれば、完了済み実行の詳細を長期間振り返ることができますが、その分ストレージ使用量（およびコスト）が増える点に留意しましょう。

通常、デバッグや監査目的である程度の期間は履歴を保持しておくと便利ですが、不要に長く保持する必要はありません。例えば週次バッチであれば90日程度、1年に1回の長期プロセスなら365日保持しておけば十分でしょう。なお、RetentionPeriodは1〜365の範囲で整数日を指定します。自組織のポリシーに従って適切な値を設定し、必要以上に古いデータが残らないようにすることが推奨されます。

リトライと実行中断の制限 – 再試行はExecutionTimeoutまで繰り返し、超過時には実行全体がタイムアウト終了

Durable Functionsの自動リトライ機能には、ある意味での上限があります。それは、再試行が繰り返されるのはExecutionTimeoutの範囲内に限られるという点です。例えばExecutionTimeoutを1時間に設定し、あるステップで一時的なエラーが発生し毎回1分待ってリトライするケースでは、60回程度リトライした時点で1時間に達し、タイムアウトとなります。つまり、どんなに粘ってもExecutionTimeoutを超えて無限に再試行し続けることはなく、制限時間切れでワークフロー自体が失敗します。

また、リトライ間隔（バックオフ）も無制限に長くは設定されていません。デフォルトでは指数バックオフで最大数分〜数十分程度の待機で打ち止めになるよう設計されています（詳細な数値はSDKの実装依存）。これらの制限は、無限ループや意図しない長期占有を防ぐための仕組みです。設計時には、最悪の場合どれくらいリトライが繰り返され得るかを念頭に置き、ExecutionTimeoutやリトライ戦略を調整すると良いでしょう。そして、タイムアウト終了した場合に備えたフォールバック処理（例: 管理者通知やデータの手動修復プロセス）も考えておくのがベストプラクティスです。

Durable Functionsの料金モデル – Lambda実行時間＋ステップ数と状態データ保存量に応じた追加コストが発生

Durable Functions利用時の料金は、大きく分けて2つの要素で考える必要があります。1つはLambdaの実行時間と呼び出し回数に基づく通常のLambda料金です。Durable Functionsでも各ステップ実行や待機再開時にLambda関数が起動・実行されるため、その累計実行時間（待機中を除く）とInvoke回数に対して料金が課金されます。もう1つはDurable Functions特有のコストで、ステップのチェックポイント保存や状態保持に伴うコストです。公式にはLambda料金ページでDurable Functionsに関する記載がありますが、例えば100万回のステップ実行あたり数ドル程度、状態データの保存量GBあたり月数十セント程度といった低料金が設定されています。

概算として、Durable FunctionsではStep Functionsのような明確な「状態遷移数課金」はありませんが、ステップごとの保存操作が内部的にデータ書き込みとしてカウントされ、微小な料金が発生する形になります。また、長期間状態を保持するためのストレージ費用もGB・月単位でわずかにかかります。しかしこれらはかなり低めに抑えられており、例えば100万ステップ・数GBの状態保持でも数ドル〜十数ドル程度と言われています。総合的には、Durable Functionsの追加コストはStep Functionsの料金モデルと比較してもリーズナブルになるよう設計されています。

Step Functionsとのコスト比較 – Durable Functionsは状態保存料とステップ処理課金、Step Functionsは状態遷移課金

コスト観点でStep FunctionsとDurable Functionsを比較すると、性質の違いが見えてきます。Step Functionsは、状態遷移ごとに課金（標準ワークフローで1,000回あたり約0.025USD）されるため、ステップ数が多い複雑なフローほど料金が嵩みます。一方Durable Functionsは、基本的にLambdaの実行時間課金であり、追加コストは前述の通りステップ保存とストレージ程度です。そのため、長時間待機が多くステップ数が少ないフローではDurable Functionsの方がかなり安上がりになる可能性があります。逆に短時間で大量の状態遷移が必要なケースでは、Lambdaの呼び出し回数自体が増えるDurable Functionsも料金が増えますが、それでもStep Functionsの遷移課金より低コストに抑えられるケースが多いでしょう。

例えば1回のワークフローで100ステップ・合計1時間実行の場合、Step Functionsでは遷移課金だけで約0.0025USD、Lambda実行分は外部になります。一方Durable FunctionsではLambda実行1時間相当（メモリ1GBなら約0.06USD）＋ステップ保存100回（数十回で0.0008USD程度）となり、総額で見ても数セントレベルです。もちろんメモリサイズや実行環境により異なりますが、一般的にDurable FunctionsのコストモデルはStep Functionsに比べて大規模フローでも安価に収まりやすいです。ただしワークフローの性質によって差が出るため、事前に両者のコストを試算し、安価な方を選ぶのが良いでしょう。