こんにちは、丸山です。
2月後半に入って、急に暖かい日が増えてきましたが、それに伴い、花粉症が辛くなってきました（涙）。
本記事では Amazon Bedrock AgentCore Memoryのエピソード戦略を取り上げます。
他の記憶戦略と比較しながら、どのような情報が保存され、どんな場面で有効なのかを実例ベースで確認していきます。
1. AgentCoreとは
もう AgentCore を利用した経験のある人も多いと思いますが、ここでは、簡単にサマリしておきます。
Amazon Bedrock AgentCoreは、AIエージェントの構築、デプロイ、管理を統合的に行うためのマネージドプラットフォームです。
AgentCoreは以下のサービスで構成されます。
| サービス | 概要 |
|---|---|
| Runtime | エージェントとツールをデプロイ・スケーリングする安全なサーバーレス実行環境 |
| Memory | 過去の会話を覚えるエージェント構築のための短期・長期記憶システム |
| Gateway | APIやLambda関数などをエージェント互換ツールに変換するゲートウェイ |
| Identity | エージェントのIDとアクセス管理を簡素化 |
| Observability | エージェントワークフローの監視 |
詳しくは公式ドキュメントを参照してください。 docs.aws.amazon.com
2. AgentCore Memoryとは
AgentCore Memoryは、過去の会話を覚えるAIエージェントを構築するためのマネージドサービスです。
人間が対話を通じて関係性を構築し、経験から学習するように、AIエージェントにも同様の能力を付与します。
docs.aws.amazon.com
2.1. 短期記憶と長期記憶
AgentCore Memoryは大きく分けて以下の2種類があります。
| 種類 | メリット | デメリット |
|---|---|---|
| 短期記憶 | 会話内容を即メモリに反映できる | 1. AIエージェントが今の会話以外の会話情報を参照することができない 2. TTLあり（デフォルト: 90日） |
| 長期記憶 | 1. AIエージェントが今の会話だけでなく過去の会話の内容を思い出しながら会話できる 2. TTLがない |
会話がメモリに反映されるまでに時間がかかる |
2.2. 長期記憶の記憶戦略
短期記憶では利用できませんが、長期記憶では、「記憶戦略」というものが利用できます。
長期記憶について、AgentCore Memoryは4つの記憶戦略を提供します（カスタム戦略も利用可能です）。
それぞれの特徴は以下の通りです。
| 戦略 | 概要 | ユースケース例 |
|---|---|---|
| サマリ | セッション全体の会話を要約し、重要な文脈を長期的に保持する戦略 | サポート引き継ぎ：翌日も続く問い合わせで、前回までの経緯（症状・実施済み対応・未解決点）を要約として参照し、再ヒアリングを減らす。 |
| ユーザー嗜好 | ユーザーの嗜好・判断基準・発言傾向を学習し、対話をパーソナライズする戦略 | 提案のパーソナライズ：ユーザーが「コスト優先」「説明は短く」などの好みを示すため、次回以降はその前提で候補提示や文体を調整する。 |
| セマンティック | 対話から事実情報や決定事項を抽出し、再利用可能な知識として保存する戦略 | 事実の取り回し：ユーザーが伝えた注文番号・環境情報・確定した設定値などを抽出して保持し、後続の手順や問い合わせで再利用する。 |
| エピソード | 意思決定プロセス全体（状況・意図・行動・評価・学習）を経験として保存する戦略 | トラブルシュートの“経験”再利用：障害対応で「状況→仮説→実施手順→結果→学び」までを一連で保存し、次回の類似案件で有効だった手順や避けるべき判断を先に提示する。 |
エピソード戦略が保存する記憶情報
他の記憶戦略とは異なり、エピソード戦略で保存されるデータは大きく 2種類（エピソード／リフレクション） です。
①エピソードレコード
一つの会話固有の情報を保存します。
{ "situation": "<会話開始時点の状況。前提・背景・ユーザーの状態（曖昧さ/制約/悩み）を要約>", "intent": "<会話全体で達成したいゴール。目的・到達点・成功条件が入る>", "assessment": "<ゴール達成の評価。Yes/No などで結論を示す>", "justification": "<assessmentの根拠。何が決まり、何が具体化され、なぜ成功/未達かを説明>", "reflection": "<この会話から得られた学び。良かった進め方/回避すべき点/重要な洞察など>", "turns": [ { "situation": "<そのターン開始時点の局面。直前までの流れとユーザー状態>", "intent": "<そのターンでの狙い。次に何を前進させるか>", "action": "<実際に取った行動。質問/提案/制約確認/要約など>", "thought": "<行動の判断理由。なぜその問い・提案にしたか（任意）>", "assessmentAssistant": "<アシスタント視点の評価。このターンは意図通り進んだか（任意）>", "assessmentUser": "<ユーザー視点の評価。満足/未解決/継続など（任意）>" } ... ] }
② リフレクションレコード
複数の会話を横断して、再利用可能な“進め方の型”を保存します。
{ "title": "<抽出された“進め方の型”の名前（短いラベル）>", "use_cases": "<この型が有効な状況。どんな相談・条件で再利用すべきか>", "hints": "<実践手順。会話の進め方のポイント、推奨ステップ、避けるべきこと>", "confidence": "<型の確からしさ（例: 0.0〜1.0）>" }
エピソード戦略が有効なユースケース
単なる知識検索ではなく、「どのように考え、どのように解決したか」という経験の再利用が重要になる場合に最適です。（例：要件定義の壁打ち）
2.3. コスト
東京リージョンでの金額は以下の通りです。
https://aws.amazon.com/bedrock/agentcore/pricing/
| カテゴリ | 料金 | 課金単位 |
|---|---|---|
| 短期記憶 | $0.25 | 1,000イベント |
| 長期記憶 - 保存(ビルトイン戦略) ※1 | $0.75 | 1,000レコード/月 |
| 長期記憶 - 保存(カスタム戦略) ※1 | $0.25 ※2 | 1,000レコード/月 |
| 長期記憶 - 取得 | $0.50 | 1,000レコード |
※1: 保存料金は、「その月に何件のレコードをどれだけの日数保持したか」を日割りで合算し、月平均した“保持量”に対して課金されます
※2: カスタム戦略のレコード保存時は、別途LLMによるデータ整形分の金額がかかります
3. 実装と検証
長期記憶が持つビルトインの4つの戦略それぞれでメモリを作成・利用し、エピソード戦略は他の戦略と比較してどのような差分があるのか確認します。
本記事では、「スモールスタートとしてどの部署からアプリを導入するべきか、企業担当者がエージェントと壁打ちを行う」シナリオの会話データをメモリに登録した後で、
他のシナリオを進めたときにどのような差分が出てくるか検証します。
シナリオの詳細:
- アプリ導入を行う部署の候補を洗い出す
- 利益直結性から営業部署を採用
- 営業部署にはアプリ導入に割けるリソースがないことが発覚
- リソースのあるマーケティング部署を採用
3.1. メモリ作成
各戦略それぞれに対して、一つずつメモリを作成します。
3.2. メモリへ会話データを追加
事前に用意していたデータ（ユーザーが生成AIと壁打ちを行い、アプリ導入部署を決めた会話データ）をメモリに追加します。
追加した会話データの概要は以下の通りです。
- 生成AIによる業務効率化アプリの導入に向けた、スモールスタート領域の選定
- IT化の進んでいる経理部署と営業部署を候補にあげ、利益に直結する営業部署を採用
- 営業部署が持つすべての業務領域の中で効率化対象とする領域および、それを実現するために活用するデータを決定
- 営業部署のアプリ導入リソース不足が発覚し、リソースのあるマーケティング部署に方向転換
- マーケティング部署が持つすべての業務領域の中で効率化対象とする領域および、それを実現するために活用するデータを決定
"""AgentCore Memoryに値を追加する""" def add_conversation_event( memory_id: str, actor_id: str, session_id: str, messages: list[tuple[str, str]] ) -> dict[str, Any]: """会話イベントをメモリに追加する関数 Args: memory_id: メモリID actor_id: アクターID session_id: セッションID messages: (メッセージ, 役割)のタプルリスト Returns: 作成されたイベント情報の辞書 """ client = MemoryClient() event = client.create_event( memory_id=memory_id, actor_id=actor_id, session_id=session_id, messages=messages ) return event def main(): """メイン実行関数""" try: # 会話データ business_messages = [ ( "生成AIを活用して業務効率化を図るアプリを自社に導入しようと思います。まずはスモールスタートしたいと思っているので、どの部署から始めるべきか教えてください", "USER", ), ( "スモールスタートですね。比較的始めやすそうな領域から考えるのが良いでしょう", "ASSISTANT", ), ... ] add_conversation_event( memory_id=SUMMARY_MEMORY_ID, actor_id=ACTOR_ID, session_id="business_ideation_session", messages=business_messages, ) add_conversation_event( memory_id=PREFERENCE_MEMORY_ID, actor_id=ACTOR_ID, session_id="business_ideation_session", messages=business_messages, ) add_conversation_event( memory_id=SEMANTIC_MEMORY_ID, actor_id=ACTOR_ID, session_id="business_ideation_session", messages=business_messages, ) add_conversation_event( memory_id=EPISODIC_MEMORY_ID, actor_id=ACTOR_ID, session_id="business_ideation_session", messages=business_messages, )
3.3. メモリへの問い合わせ
ビジネスアイデア 壁打ち 経緯 結論 部署選択というクエリで、各戦略の出力を確認してみました。
※長期記憶レコードはイベント投入後に非同期で生成されるため、「3.2. メモリへ会話データを追加」での処理をしてから反映されるまで数分の待ちが発生する点に注意が必要です。
以下は各戦略の出力例です。
サマリ戦略
営業部署からマーケティング部署へ方針転換があったことが保存されていました。
<topic name="経緯と結論"> 生成AIを活用した業務効率化アプリの壁打ちを実施。 当初は営業部署を検討したが、営業・経理ともに人手不足で断念。 最終的に、リソースがありIT化も進んでいるマーケティング部署でスモールスタートする方針に決定。 </topic>
ユーザー嗜好戦略
ユーザーの方針（スモールスタート志向など）が保存されていました。
{ "preference": "スモールスタートを好み、ROIなど測定可能な指標を重視する", "categories": ["プロジェクト管理", "ROI", "KPI"] }
セマンティック戦略
最終的な結論（マーケティング部署に対してアプリ導入を行うこと）が保存されていました。
結論：マーケティング部署のデータを使ってスモールスタートすることに決めました。
エピソード戦略
①エピソードレコード
その会話の経緯、ユーザーの目的が達成されたか、 その会話からの学び(段階的に具体化すると良いなど) などが保存されていました。
{ "situation": "ユーザーは生成AIを活用した業務効率化アプリケーションの導入を検討し始めており、アイデアはあるものの、対象領域の選定、実装内容の具体化、リソースの考慮など、プロジェクト計画の策定方法について助言を求めていた。スモールスタートを希望しつつも、どこから始めるべきか明確な方向性が定まっていない状態で相談を開始した。", "intent": "生成AIを使った実用的なアプリケーション導入に向けて、対象部署の選定、具体的な実装内容、データ活用戦略、評価指標など、実行可能なプロジェクト計画を策定すること。特に、スモールスタートに適した領域を特定し、成功確率の高い実装方針を確立することを目指していた。", "assessment": "Yes — ユーザーのプロジェクト計画策定という目標は成功裏に達成された", "justification": "対話を通じて、当初の曖昧なアイデアから具体的な実行計画へと段階的に詳細化が進んだ。最終的に以下の明確な計画要素が確立された： 1) 対象部署：マーケティング部署（営業・経理部署のリソース不足を考慮した適切な転換） 2) 実施内容：顧客セグメンテーションの自動化（既存顧客の再ターゲティングに焦点） 3) データ戦略：購入履歴とWebサイト行動データの組み合わせ 4) 評価指標：半年で売上向上10%という測定可能な目標 5) 実現可能性：IT化が進みリソースがある部署を選択 ユーザーは最終ターンで「ありがとうございました！それでは導入を進めていきます」と明確に述べており、実行に移せる具体的な計画が完成したことが確認できる。", "reflection": "**効果的なパターン：** - オープンクエスチョンによる段階的詳細化：各ターンで「どの業界」→「どの部署」→「どのような活動」→「どのようなデータ」と、一つずつ具体化を促す質問設計が、ユーザー自身の思考を整理し、納得感のある計画策定につながった - 制約条件の早期発見：turn_5でリソースについて確認したことで、営業・経理部署の人手不足という重要な制約が明らかになり、実現可能性の低い計画への進行を防いだ - 肯定と方向修正のバランス：ユーザーの各選択を一旦肯定しつつ（営業部署選択など）、制約条件が明らかになった際には適切に方向転換を促すアプローチが、ユーザーの自主性を保ちながら現実的な計画へ導いた - 実行可能性重視の助言：スモールスタート、ROI測定の容易さ、既存リソース活用など、成功確率を高める要素を一貫して重視し、実行可能な計画に導いた **回避すべきパターン：** - 早期の技術提案の回避：ツールを使わず対話のみで進めたことで、ユーザーの状況理解と要件定義を優先し、性急な技術選択を避けられた - 一方的な選択肢の推奨回避：turn_2で経理と営業の両方の利点を提示したように、複数の選択肢を客観的に提示することで、ユーザーの自律的な意思決定を支援した **重要な洞察：** プロジェクト計画策定において、アイデアの詳細化だけでなく、リソース制約の早期確認が重要である。本会話では、リソース確認により方向転換が必要となったが、早期に発見できたため、大きな手戻りなく適切な代替案（マーケティング部署）への移行が可能となった。この「制約条件の早期発見→代替案の検討」というプロセスが、実現可能性の高い計画策定に不可欠である。", "turns": [ { "situation": "ユーザーが生成AIを活用した業務効率化アプリの作成を検討し始めており、アシスタントに相談を開始した段階。ユーザーの全体目標は、生成AIを使った実用的なアプリケーションの導入。", "intent": "ユーザーのアイデアを肯定的に受け止め、業界や対象領域について具体化を促すことで、プロジェクトの方向性を定める手助けをする。", "action": "ツールは使用せず、ユーザーのアイデアを肯定し、どの業界での業務効率化を考えているかを質問した。", "thought": "プロジェクトの初期段階では、対象業界を明確にすることが重要であり、オープンな質問でユーザーの考えを引き出すアプローチが適切と判断した。", "assessmentAssistant": "Yes。次のターンでユーザーがスモールスタートの方針と領域選択の悩みを述べており、対話が次の段階に進んでいるため。", "assessmentUser": "No。ユーザーは次のターンで領域選択について更なる相談を続けており、現在の問い合わせが継続中であることを示している。" }, "...", { "situation": "ユーザーがプロジェクト計画を完成させ、導入フェーズに移行する意思を表明し、現在の相談セッションを終了する段階。", "intent": "ユーザーを励まし、今後も継続的なサポートが可能であることを伝える。", "action": "ツールは使用せず、ユーザーを応援し、進捗があった際の再相談を促した。", "thought": "相談セッションの終了時には、ユーザーを励まし、継続的な関係性を維持することで、今後のサポート機会を確保することが適切と判断した。", "assessmentAssistant": "Yes。ユーザーが感謝と終了の意思を示しており、現在の相談セッションを適切に終了させるという目標が達成された。", "assessmentUser": "Yes。次のターンが存在せず、ユーザーが「これから導入を進めていきます」と明確に行動移行を示しており、現在の相談エピソードが完結している。" } ] }
②リフレクションレコード
ユーザーに自主性を持たせつつ、実現可能な改善策へ導くときのコンサルティングの場面で有用な進め方が保存されていました。
以下の2ステップで進めると良いとのことです。
- ユーザーの主張を肯定する
- 制限事項やトレードオフが浮き彫りになるような判断材料の提供と問いかけを行う
{ "title": "Balanced Validation and Redirection", "use_cases": "Applies in advisory/consulting scenarios where maintaining user autonomy while guiding toward feasible solutions is important. Useful when:\n- Users make choices that have merit but face practical obstacles\n- Direction changes are necessary but user buy-in is critical\n- Building user confidence while ensuring realistic planning\n- Multiple valid paths exist with different tradeoffs\n\nThis pattern was evident throughout the episode, especially when user initially chose sales department but later needed to pivot to marketing.", "hints": "Use a two-step approach for each user decision:\n1. First, validate the choice by acknowledging its merits or logic\n2. Then, provide context or ask questions that reveal tradeoffs or constraints\n\nExample sequence: 'Sales department makes sense for revenue impact [validation]. What resources do you have available? [constraint check]' → when constraints emerge → 'Resource limitation is significant. Marketing department with existing automation might be more feasible [redirection].'\n\nAvoid:\n- Immediate rejection of user ideas without validation\n- Unilateral recommendations without explaining reasoning\n- Presenting only one option when multiple exist\n\nThis maintains user engagement and ownership while steering toward realistic outcomes.", "confidence": "0.8" }
3.4. AIエージェントによる回答
ここまでは「スモールスタートとしてどの部署からアプリを導入するべきか、企業担当者がエージェントと壁打ちを行う」シナリオの情報をメモリに保存しました。
この状態で他のシナリオを始めたときに、AIエージェントがどのような回答を返すのか確認します。
Pythonのバックエンド構築の仕事が増えているため、エンジニアを追加で雇いたいのですが、どのようなスキルセットを持った人が良いでしょうか？ というクエリで、AIエージェントに問い合わせます。
サマリ戦略／ユーザー嗜好戦略／セマンティック戦略 ※類似する回答
ユーザーに質問をすることなく、必須スキルと推奨スキルを回答しました。
エピソード戦略
採用すべき人材のスキルセットを判定するために、まずはプロジェクトの具体的なニーズについて確認するよう、ユーザーへ促してきました。
「スモールスタートとしてどの部署からアプリを導入するべきか、企業担当者がエージェントと壁打ちを行う」シナリオで保存されたリフレクションレコードが効いていることが分かります。
3.5. メモリの削除（クリーンアップ）
今までの処理で登録したレコードによる継続的な課金を発生させないために、AgentCore Memoryのリソースを削除します。
4. まとめ
エピソード戦略の強みは、 1つの事例から得た進め方を別の事例に再利用できる点 だと分かりました。
ユーザーと対話するたびに賢くなるAIエージェントを作成できれば、ユーザー満足度は向上します。
みなさんもぜひエピソード戦略を活用してみてください。
Acroquest Technologyでは、キャリア採用を行っています。
- Azure OpenAI／Amazon Bedrock等を使った生成AIソリューションの開発
- ディープラーニング等を使った自然言語／画像／音声／動画解析の研究開発
- マイクロサービス、DevOps、最新のOSSやクラウドサービスを利用する開発プロジェクト
- 書籍・雑誌等の執筆や、社内外での技術の発信・共有によるエンジニアとしての成長
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
