AWS Lambda+Bedrock サーバーレスAIエージェント構築ガイド

「Amazon Bedrock の InvokeAgent を Lambda から叩くだけ」「Step Functions で複数エージェントをつなげば本番ワークフローは完成」——AWS のホワイトペーパーや初期ブログを読み込んで、こんな絵を描いた方は少なくないはずです。実際、私たち Uravation でも 2025 年下期から複数のクライアントで Lambda + Bedrock 構成の AIエージェントを構築してきました。

結論から書くと、PoC は 1 日で動きます。ただし、本番運用に投入した瞬間に「Cold Start で初回応答 14 秒」「Bedrock のスロットルで Step Functions の State が一斉に Failed」「DLQ にメッセージが滞留しているのに気づいたのが請求書を見たとき」といった事故が立て続けに起きました。

この記事では、AWS Lambda + Amazon Bedrock + Step Functions を組み合わせたサーバーレス AIエージェントの構築方法を、私たちが現場で踏んだ 3 つの大きな失敗事例と、その回避策・本番運用の SRE プラクティスとあわせて解説します。AgentCore のようなマネージドランタイムではなく、あえて「素の Lambda + Bedrock」で組む選択肢を取る場合のリアルなコストと運用負荷を、最新の AWS 公式仕様に基づいて整理しました。

なぜ今あえて Lambda + Bedrock 構成なのか

2025 年に Amazon Bedrock AgentCore が一般提供されてから、AWS のサーバーレス AIエージェント構築は「AgentCore Runtime にまるごと載せる」スタイルが主流になりつつあります。AgentCore は Runtime・Memory・Identity・Gateway・Browser/Code Interpreter Tool・Observability まで揃った「エージェント専用 PaaS」で、Lambda 単体や Step Functions 単体で組むよりも開発負荷は格段に低いです。AgentCore の詳細は Amazon Bedrock AgentCore 完全ガイド にまとめているのでそちらを参照してください。

ただし、現場では AgentCore を採用できないケースが残ります。代表的なのは次のようなパターンです。

• AgentCore がまだ未対応のリージョン制約があり、データレジデンシー要件を満たせない
• 既存の Step Functions ベースの業務ワークフローに「LLM 推論ステップだけ」を差し込みたい
• VPC 内のオンプレ連携 API・既存 RDS・Redshift を直接叩く必要があり、AgentCore の Gateway だけでは要件が満たせない
• Lambda + EventBridge + SQS の運用ノウハウが社内に蓄積していて、新ランタイムを増やしたくない
• 1 リクエストあたりの推論コストが小さく、AgentCore Runtime の vCPU/メモリ課金よりも Lambda 実行課金のほうがコスト的に有利

こうしたケースでは、Lambda + Bedrock + Step Functions という「レガシー寄り」のサーバーレス構成が依然として有力な選択肢になります。AWS の公式ドキュメントでも、Bedrock の InvokeModel や Converse API を Lambda から呼ぶサンプル、Step Functions の Optimized integration for Bedrock によるオーケストレーションは現役で推奨されているパターンです。

全体アーキテクチャ:Lambda + Bedrock + Step Functions の標準形

失敗事例に入る前に、私たちが「最終的にここに落ち着いた」標準アーキテクチャを共有します。これは AWS Well-Architected の Serverless Lens と、Bedrock Knowledge Base の公式リファレンスを下敷きにしています。

コンポーネント構成

レイヤ	サービス	役割
入口	API Gateway / EventBridge / SQS	同期・非同期・スケジュール起動を切り分ける
オーケストレータ	AWS Step Functions (Standard / Express)	複数ステップの分岐・再試行・並列実行
エージェントロジック	AWS Lambda	プロンプト生成・後処理・ツール呼出
推論	Amazon Bedrock (Converse / InvokeAgent)	LLM 推論本体
知識ベース	Bedrock Knowledge Base + OpenSearch Serverless / Aurora pgvector	RAG・社内文書検索
記憶	DynamoDB / S3	会話履歴・中間結果の永続化
監視	CloudWatch Logs / Metrics / X-Ray	レイテンシ・トークン・エラーの可観測性

2 つの「正解パターン」

私たちが現場で使い分けているのは、次の 2 パターンです。

パターン1:単発推論型(同期)

API Gateway → Lambda → Bedrock Converse API → API Gateway。Slack スラッシュコマンドや社内ポータルの「AIに聞く」ボタンのような短時間ユースケース向け。API Gateway の 29 秒タイムアウト制約があるため、レイテンシ要件が厳しい場合はこの構成にします。

パターン2:長時間ワークフロー型(非同期)

EventBridge / SQS → Step Functions(Standard) → 複数の Lambda → Bedrock。ドキュメント分析、メール一括処理、定期レポート生成のようにレイテンシよりも信頼性とリトライ性が重要な処理。Step Functions Standard はステートマシンの実行が最大 1 年まで保持されるので、長時間バッチに向きます。

ここまでは公式ドキュメントどおりですが、「ここからが地獄」というのが現場の本音です。次章から、私たちが本番で経験した 3 つの失敗事例を順番に解剖していきます。

失敗事例1:Cold Start を甘く見て初回応答が14秒になった

何が起きたか

最初の事故は、ある中堅メーカーのカスタマーサポート向け FAQ エージェントで起きました。要件はシンプルで、社内 FAQ・製品マニュアル・過去問い合わせ履歴を Bedrock Knowledge Base で RAG し、Lambda 経由で Slack に回答するというものです。

PoC 環境では Converse API の応答が平均 2.3 秒、Lambda の処理込みで 3 秒以内に収まっていました。ところが本番投入翌週から、Slack 上で「動かないんだけど」というユーザーからの問い合わせが急増します。CloudWatch を見ると、初回呼び出しに 12〜14 秒かかっているリクエストが日に数十件発生していました。

原因の解剖

原因は複合的でした。

• Lambda の Cold Start:Python 3.12 + boto3 + LangChain 系ライブラリを VPC Lambda にデプロイしており、初期化に約 4〜5 秒
• VPC 構成:Bedrock VPC Endpoint と Aurora pgvector への接続のために VPC 内 Lambda にしたが、ENI 確保はすでに Hyperplane で改善されていたものの、初回 import コストは消えない
• 大量パッケージ:本来は boto3 と最低限の RAG クライアントだけでよかったのに、当初は LangChain・LlamaIndex・OpenSearch クライアントなど 200MB 近いデプロイパッケージを使っていた
• Bedrock 側のウォームアップ:Claude 3.5 Sonnet など特定モデルの初回呼び出しレイテンシが、業務ピークタイムで体感的に増える時間帯があった

どう直したか

私たちは次のステップで段階的に修正しました。

1. Lambda のスリム化

LangChain・LlamaIndex のような汎用フレームワークを剥がし、Bedrock 呼び出しは公式 boto3 の bedrock-runtime クライアントだけにしました。デプロイパッケージは 30MB 以下まで縮小。

# 失敗版(初期化4-5秒):
# from langchain_aws import ChatBedrock
# from langchain.chains import ConversationalRetrievalChain
# ... 巨大なimport

# 改善版(初期化700ms):
import json
import boto3
from botocore.config import Config

# モジュールトップで初期化してCold Startに乗せる
_bedrock_config = Config(
    read_timeout=60,
    retries={"max_attempts": 3, "mode": "adaptive"},
)
_bedrock = boto3.client("bedrock-runtime", config=_bedrock_config)

MODEL_ID = "anthropic.claude-3-5-sonnet-20241022-v2:0"

def handler(event, context):
    user_input = event["question"]
    resp = _bedrock.converse(
        modelId=MODEL_ID,
        messages=[{"role": "user", "content": [{"text": user_input}]}],
        inferenceConfig={"maxTokens": 1024, "temperature": 0.2},
    )
    answer = resp["output"]["message"]["content"][0]["text"]
    return {"answer": answer}

2. Provisioned Concurrency の戦略的投入

全 Lambda に Provisioned Concurrency を入れるとコストが跳ね上がるので、ユーザー体感に直結するフロント Lambda(Slack 応答用)だけに、業務時間帯のみ Application Auto Scaling でスケジュール投入しました。夜間・休日はゼロに戻すことで、月額の固定費を約 65% 圧縮できました。

3. Lambda SnapStart の検討

SnapStart は Java/Python/.NET ランタイム向けで、初期化済みの実行環境スナップショットから起動する仕組みです。Python ランタイムにも対応しているので、SnapStart を有効化したところ、初期化時間が中央値で約 70% 短縮されました。ただし SnapStart にも「最初の数回はスナップショット復元コストがある」「ネットワーク接続は復元時に張り直す必要がある」という固有の癖があり、コネクションプールは before_snapshot で閉じ、after_restore で張り直す実装にしています。

4. メモリサイズの再設計

Lambda はメモリと vCPU が連動するので、推論前後の JSON パースや埋め込みベクトル処理を伴うときは、ケチって 512MB に絞るよりも 1769MB 以上(=1 vCPU 相当)を割り当てたほうがトータルでは安くなることが多いです。Power Tuning ツールで実測したところ、1024MB → 1769MB に上げただけで、トータル課金が 18% 下がりました。

学び

「サーバーレスだからスケーリングは自動で速い」というのは半分しか正しくありません。Cold Start・VPC・モデル選定・パッケージサイズの 4 つを意識的に設計しないと、PoC で速かったレイテンシは本番では絶対に再現しません。特に AIエージェントは「ユーザーがリアルタイムに待つ」UI が多いので、設計段階で「p50 / p95 / p99 のレイテンシ目標」を必ず設定してください。

失敗事例2:Bedrock スロットルで Step Functions が一斉に Failed

何が起きたか

2 つ目の失敗は、ある SaaS 企業の「過去 1 年分の問い合わせメール 12 万通を分類・要約する」バッチで起きました。S3 にメールが置かれ、SQS で Step Functions を起動し、Lambda が Bedrock を呼んでカテゴリを判定する——というシンプルな構成です。

初日のリハーサルは 1,000 通で正常に完了。本番投入で 12 万通を一気に流し込んだ瞬間、Step Functions の Failed States が一斉に積み上がり、最終的に約 4.3 万通が処理失敗で停止しました。CloudWatch のメトリクスを開くと、ThrottlingException と ServiceQuotaExceededException がずらりと並んでいます。

原因の解剖

Amazon Bedrock には、モデルごとに「Requests per Minute(RPM)」と「Tokens per Minute(TPM)」のクォータが存在します。On-Demand 推論ではアカウント単位・リージョン単位でこの上限が設定されており、超えると ThrottlingException が返ります。

私たちはここで 3 つの罪を犯していました。

• 並列度を Step Functions の Map State の MaxConcurrency で制御していなかった(デフォルトの全力並列で 1 万件超が一度に走った)
• リトライ戦略が Step Functions のデフォルト 3 回だけで、Exponential Backoff のジッタが効いていなかった
• Service Quotas を事前に確認・引き上げ申請していなかった(Claude 3.5 Sonnet の RPM 上限を超えていた)

どう直したか

1. Step Functions Distributed Map の活用

2022 年末に発表された Distributed Map State を使うと、ItemReader で大量データを分割しつつ、MaxConcurrency で同時実行数を厳密に絞れます。私たちは Bedrock のクォータから逆算して同時実行数を 20 に絞り、ToleratedFailurePercentage を 5% に設定しました。

{
  "Type": "Map",
  "ItemReader": {
    "Resource": "arn:aws:states:::s3:getObject",
    "ReaderConfig": { "InputType": "JSONL" },
    "Parameters": {
      "Bucket": "company-mail-inbox",
      "Key": "batch/20260527.jsonl"
    }
  },
  "MaxConcurrency": 20,
  "ToleratedFailurePercentage": 5,
  "ItemProcessor": {
    "ProcessorConfig": { "Mode": "DISTRIBUTED", "ExecutionType": "EXPRESS" },
    "StartAt": "ClassifyMail",
    "States": {
      "ClassifyMail": {
        "Type": "Task",
        "Resource": "arn:aws:states:::lambda:invoke",
        "Parameters": {
          "FunctionName": "classify-mail-by-bedrock",
          "Payload.$": "$"
        },
        "Retry": [
          {
            "ErrorEquals": ["Bedrock.ThrottlingException", "States.TaskFailed"],
            "IntervalSeconds": 2,
            "MaxAttempts": 6,
            "BackoffRate": 2.0,
            "JitterStrategy": "FULL"
          }
        ],
        "End": true
      }
    }
  }
}

Step Functions の JitterStrategy: FULL は地味ですが、同時刻に複数の Map ブランチがリトライをぶつけ合うのを防ぐ重要な設定です。

2. Service Quotas の引き上げ申請

Bedrock のクォータは Service Quotas コンソールから引き上げ申請できます。実運用に入る前に、想定 RPM / TPM を試算し、余裕を持って申請するのが鉄則です。私たちは 12 万通バッチを 4 時間で完了させたかったので、Claude 3.5 Sonnet の RPM を申請で引き上げました。

3. Provisioned Throughput の検討

本当に大量の安定推論が必要な場合は、Bedrock の Provisioned Throughput を購入するという選択肢があります。これは「モデルユニット単位で推論キャパシティを予約する」仕組みで、On-Demand のクォータを共有せずに専用枠が確保されます。コスト的にはモデルユニットあたり数千ドル/月クラスになるため、月間トークン量が大きい本番ワークロードでのみ採算が合います。

私たちはこのバッチでは Provisioned Throughput までは買わず、Distributed Map の MaxConcurrency 制御 + Exponential Backoff + クォータ引き上げの 3 段構えで対処しました。結果として 12 万通の処理は約 4.5 時間で完了、Failed は 0.4% に収まっています。

学び

サーバーレスは「無限スケール」のように語られますが、Bedrock の On-Demand クォータと Step Functions の並列制御は、AIエージェントの本番運用において最初に詰めるべき”ガードレール”です。「とりあえずスケールさせてみる」ではなく、「ガードレールを引いてからスケールさせる」が正解です。

失敗事例3:DLQに5万件が滞留していたのに気づかなかった

何が起きたか

3 つ目は、最も静かに進行した事故です。ある不動産プラットフォーム企業向けに、SQS → Lambda → Bedrock で「物件問い合わせの自動応答ドラフト生成」を運用していました。Lambda の Destinations 設定で、エラー時は DLQ(Dead Letter Queue)に送る——というベストプラクティスは押さえていたつもりでした。

3 週間後、月次レビューで「思ったよりレスポンスが返ってない」とクライアントから報告が入り、慌てて SQS の DLQ を確認すると、約 5 万件のメッセージが滞留していました。Bedrock の一時的なスロットルや、特定の入力でのプロンプトインジェクション失敗、添付ファイル付きメールでの JSON パースエラーなどが少しずつ積み上がっていたのです。

原因の解剖

• DLQ にメッセージが入っても、CloudWatch Alarm を設定していなかった
• X-Ray は有効化していたが、Bedrock 呼び出しのカスタムセグメントを切っていなかったため、どのステップで落ちているのか追跡が困難だった
• エージェントの「成功率」を SLI として定義していなかった(レイテンシだけ見ていた)
• 本番環境にだけ存在する入力パターン(添付 PDF、HTML メール、超長文)に対する Lambda の例外ハンドリングが甘かった

どう直したか

1. SLO/SLI の再定義

AIエージェントの SRE では、レイテンシだけでなく「タスク成功率(=ユーザーが意図した出力が返った割合)」を SLI として定義することが重要です。私たちは次の 4 つを正式な SLI として採用しました。

• エンドツーエンドのレイテンシ p95 / p99
• Lambda の Errors / Invocations
• Bedrock の ClientError / ServerError 比率
• DLQ メッセージ数(0 でない時点でアラート)

SLO の考え方や、本番 AIエージェントの監視設計の詳細は AIエージェント SRE・本番監視ガイド にまとめているので、本格運用前に必ず一読してください。

2. CloudWatch Alarm の整備

# DLQ 滞留アラート (例: CloudFormation スニペット相当)
aws cloudwatch put-metric-alarm 
  --alarm-name "agent-dlq-not-empty" 
  --metric-name "ApproximateNumberOfMessagesVisible" 
  --namespace "AWS/SQS" 
  --dimensions Name=QueueName,Value=agent-dlq 
  --statistic Maximum 
  --period 60 
  --threshold 0 
  --comparison-operator GreaterThanThreshold 
  --evaluation-periods 1 
  --alarm-actions "arn:aws:sns:ap-northeast-1:123456789012:agent-oncall"

「0 でない時点で鳴る」アラームを 1 本入れるだけで、3 週間気づかなかった事故は当日に検知できる事故になります。

3. X-Ray + Application Signals での可観測性

Lambda の Active Tracing を有効化し、Bedrock 呼び出しを aws_xray_sdk の capture でラップしてサブセグメント化しました。これで「リクエスト ID 単位で、どのモデルにどのくらいトークンを送り、何 ms で返ってきたか」が CloudWatch Application Signals 上で時系列で確認できるようになります。

4. 入力バリデーションと安全装置

添付 PDF や HTML メールは事前に Lambda の前段で正規化し、超長文(8 万トークン超)は要約パスへ分岐させました。Bedrock の Guardrails 機能も併用し、プロンプトインジェクションや個人情報の出力を制御しています。Guardrails は Bedrock 公式の安全機能で、Lambda 経由で ApplyGuardrail API を呼ぶか、Converse 呼び出しに guardrailIdentifier を渡すだけで適用できます。

学び

「サーバーレス × AIエージェント」は静かに壊れるシステムです。Lambda は勝手にリトライし、SQS は勝手に DLQ に流し、Bedrock は ThrottlingException を返してもユーザー側ログにしか残らない。本番に出すなら、観測の入口(SLI 定義)と出口(アラーム)を最初に作るべきで、「動いた」と「運用できる」の差は、この観測設計の有無で決まります。

本番運用のSREプラクティス9選

3 つの失敗を通じて確立した、Lambda + Bedrock + Step Functions 構成の SRE プラクティスを 9 個に圧縮しました。新規プロジェクトでは、このリストを設計レビューのチェックリストとして使ってください。

1. レイテンシ目標を最初に決める:p50 / p95 / p99 の数値を設計書に書く。書かないと最適化判断ができない
2. Provisioned Concurrency はフロント Lambda にだけ:全 Lambda に入れるとコストが破綻する。ユーザー体感に直結する関数のみ
3. SnapStart の活用:Python ランタイムでも有効。コネクションは before_snapshot で閉じ、after_restore で再構築
4. Step Functions は Distributed Map を標準採用:MaxConcurrency と ToleratedFailurePercentage をセットで指定
5. Exponential Backoff + Jitter:BackoffRate と JitterStrategy: FULL を必ず指定
6. Service Quotas の事前申請:本番投入の 2 週間前にはクォータ申請を完了させる
7. DLQ のアラーム化:メッセージ数 > 0 で即時通知。SNS → Slack / PagerDuty
8. Bedrock Guardrails の活用:プロンプトインジェクション・個人情報出力・トピック逸脱を 1 機能で押さえる
9. コスト監視は AWS Budgets + Cost Anomaly Detection:Bedrock のトークン課金は予測がぶれやすい。異常検知を必ず入れる

コスト最適化:7つのレバー

「Bedrock の請求書が想定の 3 倍だった」というのも、私たちが現場でよく聞く相談です。コスト最適化のレバーを 7 つに整理しました。

レバー	削減効果の目安	注意点
モデルの使い分け(Haiku 系で十分なタスクを Sonnet で叩かない)	30〜70%	タスクごとに精度評価が必要
Prompt Caching の活用	同一プロンプトの再送で大幅圧縮	Bedrock の対応モデルでのみ有効
Lambda のメモリ調整(Power Tuning)	15〜30%	過小割当は逆効果
Provisioned Concurrency の時間帯スケジュール	50〜70%(固定枠分)	業務時間外はゼロ化
Knowledge Base のチャンクサイズ最適化	10〜25%	RAG 精度とトレードオフ
Express Workflows の活用	Standard の 1/10 程度	5 分超のワークフローは Standard 必須
S3 Intelligent-Tiering / ログのライフサイクル	20〜40%(ストレージ系)	監査要件と相談

特に効くのは「モデルの使い分け」と「Prompt Caching」です。意思決定が必要な思考タスクは Sonnet、定型分類は Haiku、要約は Haiku か Sonnet を maxTokens 制限付きで——のように使い分けるだけで、月額が大きく変わります。

知識ベース連携:Bedrock Knowledge Baseの落とし穴

RAG を組むときに Bedrock Knowledge Base を使うと、ベクトル DB の構築・同期・チャンク分割をマネージドにできるので便利です。ただし、いくつか注意点があります。

• ベクトルストアの選択:OpenSearch Serverless はマネージド性が高い反面、月額固定費が発生する。低頻度ワークロードでは Aurora pgvector のほうが安いこともある
• 同期の頻度:S3 への追加・更新を即時反映させたい場合、EventBridge → Lambda で StartIngestionJob を呼ぶ仕組みを別途組む必要がある
• メタデータフィルタ:取得時に「部署」「期間」などのメタデータでフィルタをかけたい場合、ingestion 時のメタデータ JSON を必ず整備する
• RetrieveAndGenerate と Retrieve の使い分け:エージェント側で再ランキングや自前プロンプトを組みたい場合は Retrieve だけ呼ぶ

Knowledge Base を Lambda から扱う際の基本コードは次のとおりです。

import boto3

agent_runtime = boto3.client("bedrock-agent-runtime")

def retrieve(query: str, kb_id: str, top_k: int = 5):
    resp = agent_runtime.retrieve(
        knowledgeBaseId=kb_id,
        retrievalQuery={"text": query},
        retrievalConfiguration={
            "vectorSearchConfiguration": {"numberOfResults": top_k}
        },
    )
    return [
        {
            "content": r["content"]["text"],
            "score": r.get("score"),
            "source": r.get("location", {}),
        }
        for r in resp["retrievalResults"]
    ]

取得結果は Lambda 側で再ランキングや重複排除を行い、最終的に Converse API に渡すプロンプトに埋め込みます。

イベント駆動アーキテクチャ:SQS / EventBridge の使い分け

非同期エージェントの入口には SQS と EventBridge の 2 つの選択肢があります。私たちの使い分けは次のとおりです。

用途	SQS	EventBridge
大量メッセージのバッファリング	◎	△(クォータ要確認)
1:N のファンアウト	△(SNS と組み合わせ)	◎
スケジュール起動	×	◎(EventBridge Scheduler)
SaaS 連携(Stripe / Zendesk 等)	×	◎(EventBridge Partner)
順序保証	◎(FIFO)	×

「ユーザー操作 → 即時応答」は API Gateway + Lambda、「業務イベント → 後続ワークフロー」は EventBridge、「大量バッファ + ワーカープール」は SQS、というのが基本形です。Lambda + Bedrock 構成では SQS を ItemReader にした Step Functions Distributed Map が、もっとも汎用性の高い非同期パターンになります。

関連ツールエコシステム

2025〜2026 年にかけて、AWS は「AIエージェント開発を加速する開発者ツール」を矢継ぎ早にリリースしました。Lambda + Bedrock 構成と組み合わせて使えるツール群は、Agent Toolkit for AWS 完全ガイド にまとめています。Strands Agents SDK や AgentCore の関連 OSS、Bedrock のサンプルプロジェクト集など、現場で「これは入れておくと楽」というツールをカテゴリ別に整理しているので、新規構築前にざっと目を通しておくと、車輪の再発明を避けられます。

セキュリティ設計:押さえるべき5つの観点

Lambda + Bedrock 構成でやってはいけないアンチパターンと、対応するベストプラクティスです。

1. シークレット管理:Bedrock の API キー的なものは存在せず IAM で制御するが、外部 API キーは AWS Secrets Manager か Parameter Store の SecureString で扱う。環境変数直書きは NG
2. 最小権限の IAM:Lambda の実行ロールには、必要なモデル ARN だけを許可する。bedrock:InvokeModel をワイルドカードで開けない
3. VPC エンドポイント:Bedrock の VPC Endpoint(com.amazonaws.region.bedrock-runtime)を使い、トラフィックを AWS 内に閉じる
4. Guardrails の常用:プロンプトインジェクション・個人情報・有害コンテンツのフィルタは Guardrails 側に寄せる。Lambda コードで頑張らない
5. ログのマスキング:CloudWatch Logs にプロンプト・応答を残す場合、PII を必ずマスキング。CloudWatch Logs データ保護ポリシーが使える

移行判断:Lambda+Bedrock vs AgentCore

最後に、新規プロジェクトを始める時の「どっちで組むか」判断軸をまとめます。

判断軸	Lambda + Bedrock を選ぶ	AgentCore を選ぶ
既存資産	Lambda / Step Functions 資産が多い	新規ゼロベース
必要機能	シンプルな推論+RAG	マルチエージェント、長期記憶、Code Interpreter
リージョン要件	AgentCore 未対応リージョン	AgentCore 対応リージョン
運用ノウハウ	SRE がサーバーレスに慣れている	マネージドに寄せたい
コストプロファイル	呼び出し頻度が低い・スパイク型	常時稼働型・vCPU 課金が有利

「将来 AgentCore に移行するかもしれない」を意識して Lambda + Bedrock を組むなら、ビジネスロジックを Lambda 関数として独立させ、入出力 JSON のスキーマを最初から AgentCore Runtime に乗せ替えやすい形にしておくと、後の移行が楽になります。

参考・出典

• Amazon Bedrock Agents — AWS Documentation
• Amazon Bedrock Converse API — AWS Documentation
• Step Functions Distributed Map — AWS Documentation
• AWS Lambda SnapStart — AWS Documentation
• Amazon Bedrock Guardrails — AWS Documentation
• Amazon Bedrock Knowledge Bases — AWS Documentation
• AWS Machine Learning Blog

まとめ:今日から始める3つのアクション

1. 今日:既存または計画中の Lambda + Bedrock 構成について、p50 / p95 / p99 のレイテンシ目標と DLQ アラーム有無を棚卸しする
2. 今週中:Bedrock の Service Quotas を確認し、本番想定 RPM / TPM の 1.5 倍以上の余裕があるかチェック。不足していれば申請
3. 今月中:Step Functions の Map State を Distributed Map に置き換え、MaxConcurrency と Exponential Backoff + Jitter を設定。Bedrock Guardrails の最小構成を本番投入

サーバーレス AIエージェントは、設計を 1 段階深くするだけで「動く PoC」から「壊れにくい本番」に変わります。AgentCore 一択ではない選択肢として、Lambda + Bedrock + Step Functions の組み合わせは、これからも長く現役で活躍する構成です。

あわせて読みたい

• Amazon Bedrock AgentCore 完全ガイド
• Agent Toolkit for AWS 完全ガイド
• AIエージェント SRE・本番監視ガイド

この記事は AIgent Lab 編集部がお届けしました。