AWS Lambda Durable Functionsが欧州主権クラウドに対応――長時間ワークフローとAI処理の設計はどう変わるか

Lambdaで「途中経過を持つ処理」を設計しやすくなる

AWS Lambda Durable Functionsが、AWS European Sovereign Cloudで利用可能になりました。

Durable Functionsは、Lambdaのイベントハンドラーにstepやwaitといったプリミティブを追加し、複数段階にわたる処理の進捗をチェックポイントとして保持できる仕組みです。処理中に障害が発生した場合は、完了済みのステップを活用して自動的に復旧できます。また、外部イベントや一定時間の経過を待つ間、オンデマンド関数のコンピュート料金を発生させずに実行を一時停止できます。

これにより、従来は複数のLambda関数、状態管理用のデータストア、リトライ処理、スケジューラーなどを組み合わせて実装していたワークフローを、Lambdaの開発体験に近い形で構築できるようになります。

Durable Functionsで何が変わるのか

通常のLambdaは、短時間のイベント処理に適しています。一方で、次のような処理ではアプリケーション側の実装が複雑になりがちです。

• 注文受付後に在庫確認、決済、配送依頼を順番に実行する
• ユーザー登録後に本人確認、審査、通知を段階的に処理する
• AIエージェントが複数のツールを呼び出し、結果を評価して次の処理へ進む
• 外部システムの応答や人による承認を待ってから処理を再開する
• 途中まで完了した処理を記録し、障害発生後に最初からやり直さない

Durable Functionsでは、各ステップの完了状態を前提に処理を設計できます。重要なのは、単にLambdaの実行時間を延ばす機能ではなく、長時間にわたる処理の状態と再実行を、Lambdaのプログラミングモデルに取り込む点です。

Step Functionsや従来のLambda連携との違い

AWSには、以前からワークフローオーケストレーションのサービスとしてAWS Step Functionsがあります。Durable FunctionsとStep Functionsは競合するというより、処理の表現方法や運用単位が異なる選択肢です。

Step Functionsは、状態遷移を明示的に表現し、複数サービスを横断するワークフローを可視化しやすい点が強みです。複雑な分岐、並列処理、サービス統合をワークフロー定義として管理したい場合は、引き続き有力な選択肢です。

一方、ビジネスロジックとワークフローの処理が密接で、Lambdaのコードを中心に開発したい場合は、Durable Functionsの方が自然に感じられる可能性があります。既存のLambdaアプリケーションへ段階的に導入しやすいかどうかも、選定時のポイントになります。

実装イメージ：注文処理をステップ化する

Durable Functionsを利用する場合の考え方は、処理を再実行可能な単位へ分割することです。以下は概念的な実装イメージです。実際の関数名やコンテキストの扱いは、利用するランタイムとAWS Lambdaの開発者ガイドに従って実装します。

# 概念例：実際のSDK呼び出しは利用するランタイムの仕様に合わせる

def order_workflow(event, durable_context):
    order_id = event["order_id"]

    inventory = durable_context.step(
        "reserve-inventory",
        lambda: reserve_inventory(order_id)
    )

    payment = durable_context.step(
        "authorize-payment",
        lambda: authorize_payment(order_id, inventory)
    )

    durable_context.step(
        "request-shipping",
        lambda: request_shipping(order_id, payment)
    )

    durable_context.wait("wait-for-shipping-event")

    durable_context.step(
        "notify-customer",
        lambda: notify_customer(order_id)
    )

この設計では、在庫確保が成功した後に決済処理で失敗しても、在庫確保から無条件にやり直すのではなく、チェックポイントを利用して再開する考え方になります。

ただし、Durable Functionsを利用しても、業務処理の冪等性が不要になるわけではありません。決済や外部API呼び出しでは、同じ処理が再試行されても二重請求や二重登録が起きないよう、次のような設計が必要です。

• 業務上の一意なリクエストIDを付与する
• 外部APIが提供する冪等性キーを利用する
• ステップの結果を業務データと整合する形で保存する
• タイムアウトと再試行による重複実行を想定する
• 外部システム側の状態を照会してから再開する

AIエージェントの長時間タスクに適する理由

AIエージェントの処理は、単一のモデル呼び出しで完了しないことがあります。ユーザーの要求を解釈し、検索や業務APIを呼び出し、結果を検証し、必要であれば追加のツールを使うという流れになるためです。

さらに、次のような待機が発生する場合があります。

• モデルによる計画の生成
• 複数の外部ツールや社内APIの呼び出し
• 人による承認
• 非同期ジョブの完了待ち
• 利用制限やレート制限からの回復待ち

Durable Functionsのstepとwaitを使えば、エージェントの処理を段階化し、途中結果を保持しながら次のイベントを待つ構成を検討できます。待機中にLambdaを実行し続ける必要がないため、処理の大半が外部サービス待ちになるワークロードでは、常時実行型のコンピュートよりも適した設計になる可能性があります。

ただし、AI処理ではモデル呼び出し自体の料金、外部APIの料金、実行履歴や入力データに含まれる機密情報の管理も重要です。Durable Functionsはオーケストレーションの仕組みであり、モデルの品質評価、プロンプト管理、ガードレール、個人情報の取り扱いを自動的に解決するものではありません。

障害復旧で設計者が意識すべきこと

Durable Functionsのチェックポイントと自動リカバリは、障害に強いワークフローを構築するための基盤になります。ただし、復旧単位を適切に設計しなければ効果を発揮しません。

特に重要なのは、1つのステップを大きくしすぎないことです。複数の外部API呼び出しやデータ更新を1ステップにまとめると、途中で失敗した場合にどこまで成功したかを判定しにくくなります。

一方で、ステップを細かく分割しすぎると、実行履歴や状態管理が複雑になります。次のような単位を目安に、再試行の境界と業務上のトランザクション境界を合わせることが重要です。

• 失敗時に独立して再試行できる処理
• 成功または失敗を明確に判定できる処理
• 外部サービスとの一連の呼び出しを含める必要がある処理
• 補償処理を用意できる処理

また、キャンセル、タイムアウト、部分成功、手動介入といった異常系も、通常系と同じレベルで設計する必要があります。

AWS European Sovereign Cloudでの意味

今回の対応は、AWS European Sovereign Cloudを利用する企業にとって、サーバーレスのワークフロー選択肢が広がるという点で意味があります。欧州のデータ主権やコンプライアンス要件を満たしながら、注文処理、ユーザーオンボーディング、AI支援業務などを構築する際に、Durable Functionsを候補へ加えられます。

ただし、サービスが対象リージョンで利用可能であることと、システム全体が要件を満たすことは同義ではありません。実際の設計では、次の項目をワークロード単位で整理する必要があります。

• ワークフローの入力、実行履歴、出力に機密情報が含まれるか
• データやログがどのリージョンに保存されるか
• 利用するLambda以外のAWSサービスも主権要件を満たすか
• 暗号化、鍵管理、アクセス制御をどう構成するか
• 管理者アクセスや運用担当者の権限をどう制限するか
• バックアップ、監査ログ、障害対応の保管場所をどうするか
• AIサービスや外部APIにデータを送信する必要があるか

Durable Functionsの採用だけでコンプライアンス対応が完了するわけではありません。ワークフローが呼び出すサービス、ログに残るデータ、運用経路まで含めた構成レビューが必要です。

対応ランタイムとIaC

Durable Functionsは、次のLambdaランタイムを利用する新規または既存の関数で有効化できます。

• Python 3.13および3.14
• Node.js 22および24
• Java 17以降

Javaが対象に含まれるため、既存のJavaベースの業務システムやエンタープライズ向けバックエンドにおいても、候補にしやすくなっています。導入方法は、AWS Lambda API、AWS Management Console、AWS SDKに加え、次のInfrastructure as Codeツールに対応しています。

• AWS CloudFormation
• AWS Serverless Application Model（AWS SAM）
• AWS CDK

本番環境では、コンソール上の設定変更だけでなく、IaCで有効化設定や関連リソースを管理するのが現実的です。開発、ステージング、本番で設定差分が生じないよう、ランタイム、権限、ログ、アラーム、保持期間をコード化しておくと運用しやすくなります。

どのケースで採用を検討するか

Durable Functionsは、次の条件に当てはまるワークロードで特に検討価値があります。

• 処理が複数ステップに分かれ、途中状態を保持したい
• 外部サービスや人の操作を待つ時間が長い
• 障害時に完了済み処理を再実行したくない
• Lambdaのコード中心でワークフローを実装したい
• AIエージェントのツール呼び出しや承認フローを管理したい
• AWS European Sovereign Cloud上でサーバーレス構成を採用したい

一方で、複雑な分岐や並列処理を可視化し、複数サービスの状態遷移を運用チームと共有したい場合は、Step Functionsが適している可能性があります。単純なイベント連携であれば、SQS、EventBridge、通常のLambdaなどの方が構成も運用も軽量です。

まとめ

AWS European Sovereign CloudでLambda Durable Functionsが利用可能になったことで、欧州のデータ主権要件を意識した環境でも、長時間・多段階のサーバーレス処理を設計する選択肢が増えました。

実務上のポイントは、単にLambdaを長く動かすことではありません。stepによるチェックポイント、waitによる待機、障害からの再開を組み合わせ、再試行可能で、状態を追跡でき、外部サービスとの失敗境界が明確なワークフローを作ることです。

導入時は、Step Functionsとの役割分担、業務処理の冪等性、AIデータの取り扱い、実行履歴とログの保護、リージョンおよびサービス全体のコンプライアンスをまとめて評価するとよいでしょう。

出典： AWS What’s New