「AIエージェントをLambdaに乗せたら、コールドスタートで5秒かかって使い物にならなかった」
10社以上のAIエージェント導入を支援する中で、インフラ選定の失敗を最も多く見るのがこのパターンだ。Lambda・ECS・Kubernetes——どれも「AIエージェントに使える」と言われる。ただし、エージェントの特性と使い方を考えずに選ぶと、コストが跳ね上がるか、レイテンシで痛い目を見る。
この記事では、実際のベンチマークデータをもとに3つのデプロイパターンを比較し、「どのエージェントにどのインフラか」を判断するための実践ガイドをまとめる。コピペ可能なTerraform・Dockerfileも含めて全公開する。
AIエージェントの設計パターン全般については、AIエージェント構築完全ガイドで基本から解説しています。
まず試したい「5分即効」デプロイセットアップ3選
即効セットアップ1：Lambda（低トラフィック・イベント駆動）
呼び出し頻度が低く、処理時間が短いエージェント（ドキュメント分類、通知生成など）には、Lambdaが最も低コストに仕上がる。以下はDockerコンテナベースのLambdaにLangChainエージェントを乗せる最小構成だ。
# Dockerfile — Lambda用コンテナイメージ
# 動作環境: AWS Lambda, Python 3.12, arm64（Graviton2推奨 — 20%コスト削減）
FROM public.ecr.aws/lambda/python:3.12-arm64
WORKDIR /var/task
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY agent.py .
CMD ["agent.lambda_handler"]
# agent.py — Lambda関数本体
# pip install langchain-openai langchain-core
import json
import os
from langchain_openai import ChatOpenAI
from langchain.agents import AgentExecutor, create_openai_functions_agent
from langchain_core.prompts import ChatPromptTemplate, MessagesPlaceholder
# 注意: APIキーは環境変数 or AWS Secrets Managerから取得。ハードコード厳禁
llm = ChatOpenAI(
model="gpt-4o-mini", # エージェント向けコスト最適化モデル
api_key=os.environ["OPENAI_API_KEY"],
temperature=0
)
prompt = ChatPromptTemplate.from_messages([
("system", "あなたは丁寧なカスタマーサポートエージェントです。"),
MessagesPlaceholder(variable_name="chat_history"),
("human", "{input}"),
MessagesPlaceholder(variable_name="agent_scratchpad"),
])
def lambda_handler(event, context):
"""Lambdaエントリーポイント"""
body = json.loads(event.get("body", "{}"))
user_input = body.get("message", "")
# エージェント実行（ステートレス — セッション管理はDynamoDBで別途実装）
agent = create_openai_functions_agent(llm, tools=[], prompt=prompt)
executor = AgentExecutor(agent=agent, tools=[], verbose=False)
result = executor.invoke({"input": user_input, "chat_history": []})
return {
"statusCode": 200,
"body": json.dumps({"response": result["output"]}, ensure_ascii=False)
}
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
動作環境: AWS Lambda (arm64), Python 3.12, langchain-openai 0.1.x
コスト目安: 日10,000リクエスト以下なら月$28.50〜（後述のベンチマーク参照）
即効セットアップ2：ECS Fargate（中トラフィック・常時稼働エージェント）
会話が続く（ステートフルな）エージェントや、レイテンシを安定させたい場合はECS Fargateが「Goldilocks」な選択肢だ。Kubernetesの複雑さなしにコンテナ管理できる。
# FastAPIでエージェントをラップ — ECS/K8s共通
# 動作環境: Python 3.11+, fastapi>=0.110.0, uvicorn>=0.27.0
# pip install fastapi uvicorn langchain-openai redis
from fastapi import FastAPI
from pydantic import BaseModel
import redis
import json, os
from langchain_openai import ChatOpenAI
app = FastAPI()
# セッションストア（ElastiCache Redis — ECSと同一VPC内に配置）
r = redis.Redis(host=os.environ["REDIS_HOST"], port=6379, decode_responses=True)
class ChatRequest(BaseModel):
session_id: str
message: str
@app.post("/chat")
async def chat(req: ChatRequest):
# セッション履歴をRedisから取得（TTL 30分）
history_raw = r.get(f"session:{req.session_id}")
history = json.loads(history_raw) if history_raw else []
llm = ChatOpenAI(model="gpt-4o", api_key=os.environ["OPENAI_API_KEY"])
messages = [{"role": "system", "content": "丁寧なサポートエージェント"}]
messages.extend(history)
messages.append({"role": "user", "content": req.message})
response = llm.invoke(messages)
history.append({"role": "user", "content": req.message})
history.append({"role": "assistant", "content": response.content})
# セッション更新（30分TTL）
r.setex(f"session:{req.session_id}", 1800, json.dumps(history, ensure_ascii=False))
return {"response": response.content}
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
即効セットアップ3：Kubernetes（高トラフィック・マルチエージェント）
日8万5千件以上のリクエスト、または複数エージェントが協調する本番環境にはKubernetesが投資対効果に優れる。
# k8s/deployment.yaml — AIエージェント本番デプロイ
# 動作環境: Kubernetes 1.28+, EKS / GKE / AKS
apiVersion: apps/v1
kind: Deployment
metadata:
name: ai-agent
labels:
app: ai-agent
spec:
replicas: 3
selector:
matchLabels:
app: ai-agent
template:
metadata:
labels:
app: ai-agent
spec:
containers:
- name: agent
image: your-ecr-repo/ai-agent:latest
ports:
- containerPort: 8000
env:
- name: OPENAI_API_KEY
valueFrom:
secretKeyRef:
name: ai-agent-secrets # kubectl create secret で作成
key: openai-api-key
resources:
requests:
memory: "512Mi"
cpu: "500m"
limits:
memory: "2Gi"
cpu: "2000m"
# ヘルスチェック設定（必須 — 応答不能なPodを自動交換）
livenessProbe:
httpGet:
path: /health
port: 8000
initialDelaySeconds: 30
periodSeconds: 10
---
# Horizontal Pod Autoscaler（トラフィックに応じてPodを自動スケール）
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: ai-agent-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: ai-agent
minReplicas: 3
maxReplicas: 20
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 60
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
3つのインフラを3つの視点で比較する
コストで比較する
同一の感情分析エージェント（DistilBERTベース）を3つのプラットフォームで動かした場合の月額コスト比較だ。
| 日次リクエスト数 | Lambda（月額） | ECS Fargate（月額） | EKS（月額） | 最安 |
|---|---|---|---|---|
| 10,000件 | $28.50 | $75.08 | $194.96 | Lambda |
| 35,000件 | $99.75 | $75.08 | $194.96 | ECS |
| 85,000件 | $242.25 | $88.08 | $194.96 | EKS |
| 200,000件 | $570.00 | $150.00 | $194.96 | EKS |
測定条件: 同一ワークロード（DistilBERTモデル、平均レスポンスタイム含む）、us-east-1、2026年3月時点の公開料金で計算
クロスオーバーポイント: ECSがLambdaより安くなるのは日35K件、EKSがECSより安くなるのは日85K件
最終確認日: 2026-04-11（AWS公式料金ページ）
「総所有コスト」には人件費も含めて考えること。EKSを使いこなすには専任のインフラエンジニアが実質必要だ。採用コスト$120K/年を加味すると、少規模チームではLambdaやECSの方が経済合理性が高くなる。
レイテンシで比較する
| メトリクス | Lambda | ECS Fargate | EKS |
|---|---|---|---|
| 平均レイテンシ | 245ms | 156ms | 128ms |
| P99レイテンシ | 1,450ms | 498ms | 389ms |
| コールドスタート | 3〜5秒 | なし（常時起動） | なし（常時起動） |
| スループット（RPS） | 42 | 98 | 156 |
Lambdaで最も問題になるのは「P99レイテンシが中央値の7.3倍」という事実だ。稀に発生するコールドスタート（3〜5秒）がP99を引き上げる。AIエージェントでは会話の「最後の1%」が重要なのに、そこでタイムアウトに近い応答時間が出る可能性がある。
Provisioned Concurrencyを設定すればコールドスタートを防げるが、その場合のコスト計算は再度行う必要がある（常時起動分の費用が加算される）。
スケーラビリティで比較する
AIエージェント特有の「状態」という問題がスケーラビリティを複雑にする。
Lambdaはそもそも「ステートレス」設計だ。マルチターンの会話を実装するには、DynamoDBやElastiCacheにセッション状態を外出しする必要がある。実装コストはかかるが、スケーリングは自動で行われる。
ECSはサービスオートスケーリングで対応できる。Redisと組み合わせてセッション共有を実装すれば、複数タスク間で一貫したエージェント状態を保てる。
Kubernetesは最も強力だ。HPAによるPodの自動スケーリング、PersistentVolumeによるステート永続化、複数エージェントのオーケストレーションを全て統合的に扱える。マルチエージェントシステム（複数の専門エージェントが協調する構成）は、実質的にKubernetesかそれに準じるオーケストレーター上でしか実用的に動かない。
【要注意】よくある失敗パターンと回避策
失敗1: LambdaにステートフルなAIエージェントをそのままデプロイする
❌ 会話履歴をLambdaのグローバル変数やファイルシステムに保存する
⭕ DynamoDB / ElastiCacheにセッション状態を外出しし、LambdaはCPU処理のみに徹する
なぜ重要か: Lambdaインスタンスは複数並行する。グローバル変数はインスタンス間で共有されない。別のユーザーの会話履歴が混入するバグが本番で発生する。
失敗2: Lambdaのタイムアウト設定を忘れる
❌ デフォルトタイムアウト（3秒）のままGPT-4oのような重いモデルを使う
⭕ Function URLのタイムアウトを最大900秒に設定し、LLM呼び出しに十分なマージンを確保
なぜ重要か: GPT-4oの応答は平均3〜8秒かかる。デフォルト3秒のタイムアウトでは毎回タイムアウトエラーになる。
失敗3: EKSのノードプール設計を誤る
❌ 全エージェントを同一ノードプールに詰め込む
⭕ CPU最適化ノード（LLM推論）とGPUノード（ローカルモデル）を別プールで管理する
なぜ重要か: ノードプールを分けることで、GPU高コストノードをLLM推論が必要な時だけスケールアウトできる。混在させるとGPUノードが常に稼働してコストが膨らむ。
失敗4: コスト上限アラートを設定しない
❌ API使用量・コンピューティングコストの上限設定なしで本番稼働させる
⭕ AWS Budgetsで月次アラートを設定し、LLM API呼び出しにmax_tokensとレート制限を実装する
なぜ重要か: AIエージェントのコスト暴走は一晩で数十万円規模になりうる。特にループする設計のエージェントは要注意だ。
参考・出典
- Deploying ML Models to Production: AWS Lambda vs ECS vs EKS — A Data-Driven Comparison — DEV Community（参照日: 2026-04-11）
- Deploying AI Agents to Production: Architecture, Infrastructure, and Implementation Roadmap — MachineLearningMastery.com（参照日: 2026-04-11）
- Serverless (Lambda) vs. Containers (Kubernetes) | AI Agents — AntStack（参照日: 2026-04-11）
- AWS Lambda GPU Support in 2026: Serverless AI Infrastructure — Blaxel Blog（参照日: 2026-04-11）
あわせて読みたい
- AIエージェント構築ツール徹底比較 — インフラを選んだ後、どのフレームワークで実装するか
- AIエージェント導入戦略 — 小規模から本番展開までのロードマップ
著者: 佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。早稲田大学法学部在学中に生成AIの可能性に魅了され、X（旧Twitter）で活用法を発信（@SuguruKun_ai、フォロワー10万人超）。100社以上の企業向けAI研修・導入支援を展開。著書累計3万部突破。
ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。
