Lambda待機コストをなくすAgentCore非同期呼び出しの3パターン

エージェントの応答待ちが課金を生む

Amazon Bedrock AgentCoreで構築したエージェントは、処理に時間がかかります。プロンプトやモデル、文書の複雑さによって応答までの時間は変動しますが、即座に返ってくることは稀です。従来のパイプラインでは、こうした遅い処理を同期的に呼び出し、結果を待つ実装が一般的です。

最も単純な実装は、AWS Lambda関数がAgentCoreを呼び出し、応答を待つというものです。しかし、その間、Lambda関数は何もせずに起動し続け、その時間分が課金されます。一方、AgentCoreのランタイムは消費ベースの課金で、アイドル中はCPU料金がかからず、メモリのみが課金されます。つまり、無駄はエージェント側ではなく、呼び出し側の待機時間にあります。

3つの非同期パターン

1つ目は、タスクトークンを使うパターンです。Step FunctionsがLambdaを呼び出す際にwaitForTaskToken統合を使用し、タスクトークンを渡して実行を一時停止します。Lambdaはエージェントを起動して即座に返答し、後でエージェントがSendTaskSuccessで再開します。この間、Step Functionsの実行は一時停止したままなので、待機中に課金されません。

2つ目は、Step FunctionsがAgentCoreに直接統合するパターンです。Lambdaを一切使わず、Step FunctionsのTask状態でエージェントを呼び出します。カスタムコードが不要な場合に最小限の構成で実装でき、待機コストも発生しません。

3つ目は、Lambdaのdurable functionを使うパターンです。オーケストレーションをコードで記述し、context.waitForCallbackで待機させます。関数はサスペンド中の課金がなく、エージェントはコールバックで再開します。Step Functionsを使わずにコードでパイプラインを管理したい場合に適しています。

コストへの影響

ブロッキングの実装では、Lambdaの課金時間がエージェントの処理時間とほぼ一致します。一方、非同期パターンでは、Lambdaが行うのはエージェントの起動だけなので数秒で終わり、待機時間は課金されません。Step Functionsの標準ワークフローは状態遷移単位で課金されるため、待機自体のコストは発生しません。

durable functionもサスペンド中はCPU課金がありません。つまり、待機時間をどこで持つかによって、支払うコストが大きく変わります。この記事で紹介された例では、文書検証のパイプラインで各パターンが同じ結果を返すことを確認しています。

実装時の選択基準と注意点

どのパターンを使うかは要件に応じて選びます。エージェント呼び出しの前後で独自のロジックが必要ならタスクトークン、不要なら直接統合、コードで全体を管理したいならdurable functionが選択肢です。

また、エージェントが応答しない場合に備えて、タイムアウトとハートビートを設定することが推奨されます。これにより、サイレントなエージェントがパイプラインを無限に停止させることを防げます。エージェント自体は受け取ったシグナルに応じて応答方法を変えるため、パターンを変更してもエージェント側の再デプロイは不要です。