TL Terralien
Compute

AWS Lambda

GenAIアプリでは「モデルを動かす場所」ではなく「モデルの手足になる場所」。Bedrock Agentsのアクショングループ実体、MCPツールサーバ、動的モデル切替の配線としてD1〜D3に顔を出します。

  • B｜実装まわり
  • D1 FM統合・データ・コンプラ
  • D2 実装と統合
  • D3 安全性・セキュリティ・ガバナンス

最終更新: 2026年8月18日

ひとことで言うと

Lambda自体はGenAI専用サービスではありません。試験での役どころは一貫していて、FMが「実際に何かをする」ための手足です。Bedrock Agentsのアクショングループの実体、AgentCore Gatewayが呼ぶツールの実装、動的なモデル切替の配線がすべてLambda経由で登場します。

要するに、モデルの手足です。FMは頭脳として推論はできても、社内APIを叩いたり在庫を引き当てたりはできません。その最後の一手をLambdaが引き受けます。
だから試験の分岐は「何をさせるか」ではなく「その手足をどれだけ長く・どれだけ重く動かすか」です。15分で終わる作業ならLambda、それを超えるならStep Functionsやコンテナに委譲します。

なぜ生まれたか

GenAIアプリの実装で必ず出てくる需要は、FMの外側にある「小さく・イベント駆動で・すぐ終わる処理」を、専用サーバを立てずに実行したいというものです。エージェントがツールを呼ぶたび、モデルを切り替えるたび、データを検証するたびにサーバを常駐させるのは無駄です。

AIP-C01のスキル文でLambdaが繰り返し出てくる場面は、アクショングループの実装・データ検証パイプライン・イベント駆動統合（API Gateway・EventBridge）・MCPのステートレスなツールサーバの4つです。共通するのは「呼ばれたら動いて、すぐ終わる」という性質で、これはサーバーレスの適性そのものです。

GenAIアプリで埋めていた隙間Lambdaが引き受ける形
ツール呼び出しのたびにサーバを常駐させたくないアクショングループ・MCPツールとして呼ばれた時だけ起動
モデル切替のたびにデプロイし直したくないAppConfigの設定値を読むだけの薄い層に
データ検証をパイプライン専用サーバに任せたくないGlue Data Quality等と組み合わせるイベント駆動の検証層に

何に使うか

用途使い方関連ドメイン
Bedrock Agentsのアクショングループエージェントが選んだアクションをLambdaが実行し、結果をFMに返すD2
MCPツールサーバ（ステートレス）単発で完結するツールをLambda、複雑な状態を持つMCPサーバはECSに分けるD2
動的なモデル切替AppConfigの設定値をLambdaが読み、コード変更なしでモデルIDを差し替えるD1
データ検証パイプラインGlue Data Quality・Data Wranglerと組み、投入前のデータをLambdaで検証D1
イベント駆動統合API Gateway・EventBridge・SQSと組み合わせ、非同期でFM呼び出しをトリガーするD2

試験でどう問われるか

問われ方正解に寄る条件引っかけの選択肢
エージェントのツール実行をどう実装するか単発・短時間で完結する処理 → Lambdaのアクショングループ常時起動のEC2でツールサーバを立てる案（過剰）
ツール呼び出しが長時間（15分超）かかる単一Lambdaで完結させようとする案は不成立 → Step Functionsに分割し.waitForTaskTokenで待つかECS/Fargateに委譲Lambdaのタイムアウトを伸ばそうとする（900秒が上限で伸びない）
コード変更なしでモデルを切り替えたい設定を外出しにする → AppConfig＋LambdaモデルIDをLambdaのコードに直書きしてデプロイし直す案
MCPサーバをどこでホストするかステートレスで軽い → Lambda／複雑な状態管理や長時間接続が要る → ECSすべてのMCPサーバを一律Lambdaに寄せる案

15分の壁はGenAIワークロードで特に効きます。エージェントのオーケストレーション自体をLambda 1本でやろうとすると、モデルの複数ターン推論・ツール呼び出しの往復が15分の壁に当たりやすい構造です。長時間の非同期処理はStep Functionsや専用ランタイム（Bedrock AgentCore Runtime）に任せ、Lambdaは「単発の手足」に留めるのが試験・実務双方の定石です。

実務でどう使うか

  • 同期呼び出しのペイロード上限（リクエスト/レスポンスとも6MB） は、画像やドキュメントをそのままLambda経由でFMに渡す設計だと簡単に当たります。S3を経由させる設計に倒すのが定石です
  • ストリーミングレスポンスなら200MBまで扱えるので、チャットのストリーミング応答をLambda経由で返す設計自体は選択肢に入ります
  • メモリと同時実行数の既定クォータ（同時実行1,000） は、エージェントのファンアウト（複数ツールを並列呼び出し）で意外と早く当たります。新規アカウントは特に低いクォータから始まる点に注意
  • AppConfigのデプロイ戦略には自動ロールバックがあり、CloudWatchのアラームと連携して設定変更を安全に戻せます。モデル切替を段階的に展開する設計と相性が良い機能です
クォータ既定値GenAIワークロードで当たりやすい場面
同期ペイロード（req/res）6MB画像・長文ドキュメントをそのまま渡す設計
同時実行数1,000エージェントのツール並列呼び出し（ファンアウト）
実行時間900秒（15分）複数ターンの推論・ツール往復を1関数に詰め込む設計

取り違えやすいもの

迷う相手切り分けの一言
Step FunctionsLambda＝単発の手足。Step Functions＝手足を並べる指揮者。15分を超える・分岐やリトライが複雑なら後者
ECS/FargateLambda＝ステートレスで短時間。ECS＝状態を持つ・常駐する・GPUなど重い処理を必要とするMCPサーバ
Lambda@Edge同じLambdaという名前だが別物。EdgeはCloudFrontのリクエスト経路上で動き、FM呼び出しの実行環境としては制約が強すぎる
Bedrock AgentCore RuntimeAgentCore Runtimeはエージェント本体（長時間のセッション）を動かす場所。Lambdaは個々のツールを動かす場所

想起チェック

Q1. エージェントのツール呼び出しが恒常的に15分を超えるとき、まず疑うべき設計は？

単一Lambdaに処理を詰め込みすぎていることです。Step Functionsで工程を分割して.waitForTaskTokenで長時間待機を外に出すか、状態を持つ処理はECS/Fargateに委譲します。Lambdaのタイムアウトを伸ばす選択肢は存在しません（上限900秒固定）。

Q2. モデルIDをコード変更なしで切り替えたいときの定石は？

AppConfigの設定値をLambdaが読み、BedrockのConverse APIに渡す構成です。AppConfigは検証・段階的ロールアウト・CloudWatch連携による自動ロールバックを備えているため、モデル切替を安全に展開できます。

Q3. MCPサーバをLambdaで作るべきか、ECSで作るべきかの分岐条件は？

ステートレスで単発・短時間なら Lambda。複雑な状態管理や長時間接続を持つなら ECS。 「複雑なMCPサーバはECS」という対応がAIP-C01の公式スキル文にも明記されています。

出典（AWS公式）