はじめに
AWS Lambdaを使ってLLMエージェントを構築する際、以下のように実装が難しくなります。
- 複雑なツール実行ループ: 「LLMの回答 ➔ ツール実行 ➔ 再度LLMへ」という処理の制御の自前実装
- 履歴のステート管理: ページを閉じても会話を継続するための、データベース設計やセッション管理の手間
本記事では、これらの課題を解決するために、エージェントのロジック管理にStrands Agent SDKを、会話履歴の保存にAgentCore Memoryを組み合わせた「ホームセンター向けAIショッピングアシスタント」の構築手法を解説します。
本記事ではAmazon Bedrock AgentCoreとStrands Agentsにフォーカスするため、その他のサービスの解説は割愛いたします。
構成図は以下です。 
Strands Agentsとは
AIエージェントを効率的に構築・実装するために設計されたオープンソースのSDKです。 今回の実装では主に以下の処理を担います。
- 会話履歴 + システムプロンプトの組み立て
- LLM呼び出し
- ツール自動実行
- 2.3. をループ管理
1. 会話履歴 + システムプロンプトの組み立て
「プロンプトをどう組み立てるか」はStrands Agents SDKが裏側で自動的に行います。Lambda上では「入力と出力のハンドリング」にのみ集中できます。
※必要に応じてmaxIterationsなどのオプションを設定し、Lambda側からツール実行のループ回数を制御することも可能です。
| 処理 | 担当 |
|---|---|
| 会話履歴の取得・保存 | Lambda（AgentCore Memory経由） |
| プロンプトの組み立て | Strands Agents SDKが自動 |
| モデルへの送信・ツール呼び出し制御 | Strands Agents SDKが自動 |
| レスポンスの返却 | Lambda |
2. LLM呼び出し
Strands Agentsは内部で以下を自動で実行します。
- テキスト生成モデル（Claude Sonnet）の呼び出し
- 必要なツールを実行
- ツール結果を持って再度テキスト生成モデルを呼び出す
- 最終的なテキスト回答が返るまでループ
よって、Lambdaはagent.invoke(message)を呼ぶだけです。
const agent = new Agent({
model: new BedrockModel({ modelId: "claude-sonnet-4-..." }),
systemPrompt: getSystemPrompt(userContext),
tools: createTools(...),
messages: history,
});
const result = await agent.invoke(message); // ← これだけ
3. ツール自動実行
Strands Agentsを使って、LLMにどのようなツールを持たせるかをコードで定義することができます。
ツールは、ベクトル検索用、SQL実行用など、機能や処理ごとに分けます。
例えば、ユーザーが「キャンプをしたい」と入力した場合、Bedrockモデルによって「商品検索用のツール（search_products）」が選択され、商品検索が実行されます。
また、「3000円以下で庭に水をやるもの」といった質問の場合は、「3000円以下」という条件に対してはSQL検索（query_database）が、「庭に庭に水をやるもの」という意図に対してはベクトル検索（search_products）がそれぞれ呼び出されます。このように、条件検索と意味検索を組み合わせたハイブリッド検索が可能です。
- SDKが全自動で処理すること： AIによるツールのルーティング、実行結果のLLMへの返却
- 開発者がやること： コールバック関数内に「実際の処理」を書くだけ
// 🔍 search_products（商品検索）
// → Bedrock Knowledge Baseに自然言語で問い合わせる（RAG）
const searchProducts = tool({
name: "search_products",
description: "商品をキーワードで意味検索する",
inputSchema: z.object({ query: z.string() }),
callback: async ({ query }) => {
// ここに実際の処理（ベクトル検索で上位何件抽出するかなど）書くだけ。
// いつ呼ぶか・結果をどう使うかはSDKが自動で判断する。
const res = await knowledgeBase.search(query); // キーワードで商品を意味検索
return JSON.stringify(res.results);
},
});
// 🗄️ query_database（在庫・価格検索）
// → Athena（Text-to-SQL）へHTTPリクエストを投げる
const queryDatabase = tool({
name: "query_database",
description: "在庫・価格をSQLで検索する",
inputSchema: z.object({ sql: z.string() }),
callback: async ({ sql }) => {
// ここにfetchを書くだけ。LLMが生成したSQLをそのまま受け取れる。
const res = await fetch(`${apiBase}/query`, { method: "POST", body: JSON.stringify({ sql }) });
return JSON.stringify(await res.json());
},
});
Amazon Bedrock AgentCoreとは
Amazon Bedrock AgentCore（以降、AgentCore）は、Amazon Bedrockとは別のサービスです。似た機能で、Amazon Bedrock Agentsがありますが、これはAmazon Bedrockの中に含まれるAgents機能になります。
二つの違いについてはこの記事（Bedrock Agents対Bedrock Agentcore比較）が参考になると思います。
AgentCoreには、以下の機能があります。
- Runtime（実行環境）
- Memory（記憶機能）
- Gateway（外部連携・呼び出し管理）
- Identity（認証）
- Observability（監視）
AgentCoreは上記から必要な機能を組み合わせて設計できます。
今回はAgentCore Memoryを使用します。
ユーザーが質問すると、AgentCore Memoryは会話履歴を保存・取得します。会話履歴を保存する方法としては他にもDynamoDBやローカルストレージがありますが、いずれも実装コストがかかったり、リロードすると消えてしまったりするので、AgentCore Memoryで保存しておくのが理想です。
| 比較項目 | フロントエンドで保持 | DynamoDBなどの自前DB | AgentCore Memory |
|---|---|---|---|
| インフラ構築 | 不要 | テーブル設計・構築が必要 | 不要 |
| 実装コスト | 低い | 削除処理・TTL設定など手間がかかる | 低い |
| データの永続性 | ページを閉じると消える | 永続保存できる | 永続保存できる |
| セキュリティ | ユーザーが改ざんできる | サーバー管理のため安全 | サーバー管理のため安全 |
| 通信量 | 履歴が増えるほど増大する | 必要な分だけ取得できる | 必要な分だけ取得できる |
| エージェント向け設計 | なし | 自前で実装が必要 | メッセージのロール管理やタイムスタンプ管理が組み込み済み |
会話履歴の保存・取得のフロー 
実際に動かしてみた
「キャンプがしたい」と入力すると、キャンプに使えそうな商品を提案してくれます。 
「全部ほしい」と入力すると、AIがこれまでの会話の流れ（文脈）を正確に読み取り、直前に提案した複数の商品を一つずつ自動で購入する処理を進めてくれます。 
予約フローを進めると無事に取置証が発行されます。 
おわりに
本記事では、Strands Agents SDKとAgentCore Memoryを組み合わせた「ホームセンター向けAIショッピングアシスタント」を構築しました。
Strands Agents SDKを導入したことで、LLMの呼び出し・ツール実行・ループ制御といった複雑な処理の実装コストを削減でき、いかにAIの精度を上げるかに時間を割くことができました。
またAgentCore Memoryによって、会話の文脈を保持するための仕組みをゼロから作ることなく、複数ターンの自然な会話を実現できました。
