Lambda Durable Functionsとは？東京リージョン対応と15分制限を超える長時間ワークフロー実装

AWS Lambda Durable Functions（耐久関数）は、2025年12月のre:Invent 2025で一般提供（GA）が始まった機能です。従来のLambdaにあった15分の実行時間制限を超え、途中で処理を中断・再開しながら最大1年にわたるワークフローを、Step Functionsのような別サービスを使わずLambdaのコードだけで書けます。

本記事は、まず結論として要点を示し、そのうえで「東京リージョンで使えるか」「どう実装するか」「料金と上限」「Step Functionsとの使い分け」を、公式ドキュメントで裏取りした事実に絞って解説します。

まとめ：Lambda Durable Functionsの要点

• 正体：Lambda関数のコード内でチェックポイントと待機を記述し、長時間ワークフローを耐久実行（durable execution）する機能。GAは2025年12月2日。
• 東京リージョン：GA当初はUS East（オハイオ）のみ。2025年12月18日に東京を含む14リージョンへ拡大し、2026年4月にさらに拡大（大阪も対応）。東京では利用可能。
• 実行時間：待機を挟みながら最大1年。ステップごとに進捗を保存し、失敗時は未完了分のみ再実行する。
• 実装：JavaScript／TypeScript／Python／Javaの各SDKを使い、ハンドラをラップしてcontext.step／context.waitを呼ぶ。耐久実行は関数の新規作成時のみ有効化でき、既存関数には後付けできない。
• 料金：通常のLambda実行料金（待機中は課金なし）＋各耐久操作のチェックポイント書き込み・状態保持ストレージ。料金は公式のLambda料金ページで確認。
• 使い分け：可視化・サービス統合ならStep Functions、コードで細かく書きたい・待機主体の長時間フローならDurable Functions。

Lambda Durable Functionsとは – 15分制限を超える「耐久実行」

Durable Functionsの本質は、1つのLambda関数の実行を複数のステップに区切り、各ステップの結果を自動保存（チェックポイント）しながら進める点にあります。関数が待機に入ると実行はいったん終了し、状態はAWS側に保存されます。指定時間の経過や外部イベントで再び呼び出されると、SDKが保存済みの履歴を読み込み、完了したステップをスキップして続きから実行します。この「チェックポイント＆リプレイ」により、長時間動かし続けなくても論理的に1本のワークフローとして完結します。

従来のLambda 15分制限と、Durable Functionsが解決する課題

通常のLambdaは1回の呼び出しが最大15分で強制終了します。そのため15分を超えるバッチや、人の承認待ちを含むフローは、Step Functionsで刻むか、状態をDynamoDBなどに書き出して自前で分割実行する必要がありました。Durable Functionsは、この状態管理・再開処理をフレームワーク側が引き受けます。開発者は「在庫確認→決済→出荷」のような処理を素直な逐次コードで書き、途中に待機を挟むだけでよく、リトライや途中再開の仕組みを自作せずに済みます。なお正確には、個々の呼び出し（ステップ実行）自体は従来どおり最大15分のままで、待機とチェックポイント／リプレイによってワークフロー全体が最大1年まで継続できる、という仕組みです。1回の関数実行が15分を超えて動き続けるわけではありません。GSCでも「lambda 15分」「lambda 時間制限」といった実クエリでこの記事が表示されており、15分の壁を越えたいという需要が実在します。

チェックポイントとリプレイの仕組み

各ステップは完了時にチェックポイントを記録します。関数が再開すると、SDKはコードを先頭から再実行しますが、記録済みのステップは中身を実行せず保存された戻り値を復元します。この動作の前提として、ステップ内の処理は決定的（同じ入力なら同じ結果）であることが求められます。乱数や現在時刻の生成、外部への副作用は必ずcontext.stepの内側に閉じ込め、リプレイのたびに結果がぶれないよう設計します。チェックポイントのデータは保存時に暗号化され、実行ごとに分離されます。

東京リージョンの対応状況と対応ランタイム

主力クエリ「lambda durable functions 東京」への答えは「利用可能」です。GA当初（2025年12月2日）はUS East（オハイオ）のみでしたが、2025年12月18日にアジアパシフィック（東京）を含む14リージョンへ拡大し、2026年4月にはさらに16リージョンが追加されて大阪リージョンなどでも使えるようになりました。ただしリージョン展開は随時更新されるため、実装前にAWSの「リージョン別サービス提供状況」ページで最新を確認するのが確実です。

対応ランタイムは、マネージドランタイムでNode.js 22／24、Python 3.13／3.14、Java 17／21／25。これ以外のバージョンはOCIコンテナイメージで利用します。旧来の解説で見かける「Node.js 16以降」「Python 3.14のみ」といった記述は現状と異なるため注意してください。

セットアップと実装 – SDKと実コード

有効化とSDKの導入（新規作成時のみ・IAM権限）

耐久実行は関数の作成時にだけ有効化でき、既存関数への後付けはできません。マネジメントコンソールなら作成画面で耐久実行のオプションを有効にし、IaCならDurableConfigを指定します。実行ロールには管理ポリシーAWSLambdaBasicDurableExecutionRolePolicy（lambda:CheckpointDurableExecution／lambda:GetDurableExecutionStateを含む）を付与します。デプロイパッケージには、Node.jsなら@aws/durable-execution-sdk-js、Pythonならaws-durable-execution-sdk-pythonを同梱します。

ステップ・待機・コールバックの実コード

ハンドラをSDKのラッパーで包み、渡されるDurableContextから各操作を呼び出します。JavaScript／TypeScriptの例：

import { DurableContext, StepContext, withDurableExecution } from "@aws/durable-execution-sdk-js";

export const handler = withDurableExecution(
  async (event, context) => {
    // ステップは自動でチェックポイント保存され、再開時は完了済みをスキップ
    const profile = await context.step("create-profile", async () =>
      createUserProfile(event.email, event.name)
    );

    // 待機中はコンピュート課金なし。最大1年まで一時停止できる
    await context.wait("cool-down", { minutes: 10 });

    // 外部の承認・確認をコールバックで待つ（24時間でタイムアウト）
    await context.waitForCallback(
      "wait-for-verification",
      async (callbackId) => sendVerifyMail(event.email, callbackId),
      { timeout: { hours: 24 } }
    );

    return { status: "completed" };
  }
);

Pythonでは@durable_executionでハンドラを、@durable_stepでステップ関数を修飾し、context.stepには修飾済み関数の呼び出しを渡します。待機はDuration.from_minutes()などで指定します：

from aws_durable_execution_sdk_python import (
    DurableContext, StepContext, durable_execution, durable_step,
)
from aws_durable_execution_sdk_python.config import Duration

@durable_step
def create_profile(step_context: StepContext, email: str) -> str:
    return save_user(email)  # ここで例外が出ると設定した戦略で自動リトライ

@durable_execution
def handler(event: dict, context: DurableContext):
    # step へは @durable_step 済みの関数呼び出しを渡す
    profile = context.step(create_profile(event["email"]))
    context.wait(Duration.from_minutes(10), name="cool-down")
    return {"status": "completed"}

DurableContextが提供する操作は、step（実行＋チェックポイント）、wait（待機）、waitForCondition（条件が満たされるまでポーリング）、callback（外部入力待ち）、invoke（別関数の呼び出し）、parallel／map（並列・一括処理）、childContext（入れ子の実行単位）です。承認待ちはwaitForCallbackで発行したトークンを外部システムに渡し、完了時にLambda APIへコールバックさせて再開します。

IaC（SAM／CDK／Terraform）での設定

AWS SAMではLambda関数にDurableConfigを付け、修飾ARNで呼び出せるようAutoPublishAliasを指定します。ExecutionTimeoutは秒（1〜31622400）、RetentionPeriodInDaysは日（1〜90）で指定します。任意でKMSKeyArnを指定すればカスタマー管理キーで暗号化できます。

Resources:
  DurableFunction:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: myDurableFunction
      Runtime: nodejs24.x        # python3.13 / python3.14 / java17 なども可
      Handler: index.handler
      CodeUri: ./src
      DurableConfig:
        ExecutionTimeout: 86400        # 秒。1〜31622400（最大約1年）
        RetentionPeriodInDays: 7       # 1〜90 日
      Policies:
        - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicDurableExecutionRolePolicy
      AutoPublishAlias: prod           # 修飾ARN（バージョン/エイリアス）で呼び出す

CDKではdurableConfig（executionTimeout／retentionPeriodをDuration型で指定）を、Terraformではdurable_configブロック（AWSプロバイダ6.25.0以降が必要）を使います。いずれもバージョンかエイリアスを発行し、修飾ARN経由で呼び出す点が共通の必須事項です。なお一部の解説にあるAllowInvokeLatestというプロパティは公式のDurableConfigには存在しません。$LATESTでの実行を避けたい場合は、修飾ARN（バージョン／エイリアス）を使うのが正しい方法です。

タイムアウト・状態保持と料金

実行タイムアウトと状態保持期間の上限

ExecutionTimeoutはワークフロー全体の最大実行期間で、1秒から31,622,400秒（約366日＝最大1年）まで設定します。個々の呼び出しではなく実行全体に適用され、超過するとタイムアウト失敗になります。チェックポイントや実行履歴の保持期間RetentionPeriodInDaysは1〜90日です。保持期間を過ぎるとGetDurableExecutionHistory API から履歴を取得できなくなります。「最大365日保持できる」という記述は誤りで、履歴の保持上限は90日である点に注意してください（待機自体は最大1年可能でも、実行後の履歴保持は別物です）。

料金の考え方

料金は大きく2要素です。1つは通常のLambda料金で、ステップ実行や再開時の実行時間と呼び出し回数に課金されます。待機中は関数が動いていないためコンピュート課金は発生しません。もう1つが耐久操作のコストで、各操作が作るチェックポイントのデータ書き込みと、状態の保持ストレージに応じて課金されます。したがって、ステップの戻り値やコールバックのペイロードを小さく保つほど有利です。大きなデータはS3などに退避し、キーだけをチェックポイントに載せるのが基本設計です。具体的な単価は変動するため、見積もりは公式のLambda料金ページで確認してください。

Step Functionsとの違いと使い分け

両者はワークフローを実現する手段が根本的に異なります。Step FunctionsはJSON（ASL）で状態遷移図を定義する宣言的アプローチで、実行の可視化やAWSサービス統合に強みがあります。Durable Functionsはプログラミング言語のコードでフローを書く命令的アプローチで、複雑な条件分岐や独自ロジックをそのまま表現できます。

判断の目安はこうです。運用メンバーを含めてフローを図で共有したい、複数のAWSサービスを跨ぐ調停が主役なら、迷わずStep Functions。逆に、処理が順次または単純な繰り返しで、開発者だけで実装・運用が完結し、長い待機が多いなら、Durable Functionsのほうがコード量も待機コストも抑えられます。Step Functionsの状態遷移設計そのものは、ステートマシンの設計パターンと採用判断の記事で整理しています。

導入前に押さえる注意点

耐久実行はリプレイを前提とするため、通常のLambda開発にはない注意点があります。実務では次の3点を最初に決めておくべきです。

• 冪等性を必ず設計する：外部への書き込みはcontext.step内に閉じ込め、一意なトランザクションIDや処理済みチェックで二重実行を防ぐ。リプレイや再起動が起きても結果がぶれないことが前提。
• コードはバージョン固定で流す：実行中のワークフローは最大1年動き続けうる。$LATESTを指すと途中でコードが差し替わりリプレイが壊れる。バージョン／エイリアスを発行し、修飾ARNで呼び出す。ステップの順序や内容を変える変更は後方互換に注意する。
• ローカル完全再現は諦める：内部ストレージが絡むため、耐久部分はローカルで完全にはテストできない。クラウド上で実行し、Durable executionsタブの実行履歴・CloudTrailデータイベント・CloudWatch Logsで挙動を確認するのが現実的。

逆に、数秒で終わる単発イベント処理や、状態を持たない変換処理にDurable Functionsを使うのは過剰です。チェックポイントのオーバーヘッドとコストが増えるだけなので、その用途では通常のLambdaのままにします。サーバーレス全体の構成判断はサーバーレスアーキテクチャの構成パターンと採用判断も参考にしてください。

よくある質問

Lambda Durable Functionsは東京リージョンで使えますか？

使えます。GA当初はUS East（オハイオ）のみでしたが、2025年12月18日に東京を含む14リージョンへ拡大しました。大阪も2026年4月の拡大で対応しています。最新の対応状況はAWSのリージョン別提供状況ページで確認してください。

従来のLambda関数を後から耐久実行に切り替えられますか？

できません。耐久実行は関数の新規作成時にしか有効化できないため、Durable Functionsを使う場合は新しく関数を作成し、DurableConfigを指定します。

待機している間も料金はかかりますか？

待機中は関数が動作していないため、コンピュートの実行料金はかかりません。課金対象は実際に実行した時間・呼び出し回数と、チェックポイントのデータ書き込み・状態保持ストレージです。

最大でどれくらい長く実行できますか？

待機を挟みながら最大1年です。ExecutionTimeoutは1〜31,622,400秒（約366日）で設定します。ただし実行履歴の保持期間（RetentionPeriodInDays）は別で、上限は90日です。

Step FunctionsとDurable Functionsはどちらを選ぶべきですか？

フローの可視化や複数AWSサービスの調停が主役ならStep Functions、コードで細かく制御したい・待機主体の長時間フローならDurable Functionsが適します。両者は排他ではなく、用途で使い分けます。

関連記事

• ステートマシンとは？状態遷移の設計と実装パターン・採用判断を実装者目線で解説
• AWS SAMとは？サーバーレスアプリケーション開発における役割とメリット
• サーバーレスアーキテクチャとは？構成パターン・AWS実装・採用判断を実装者目線で解説