※本記事は、AWS主催のイベント「AWS AI and Data Conference 2026」（第5回、2026年3月12日にアイルランド・KilkennyのLyrath Convention Centreにて開催）におけるセッション「Agents and Memory Architecture」の内容を基に作成されています。本セッションは、メモリアーキテクチャがインテリジェントなAIエージェントの基盤である理由を解説し、短期・長期メモリがステートレスなチャットボットを、対話から学習し測定可能なビジネス成果をもたらす適応的で文脈認識型のシステムへと変革する仕組みを、Amazon Bedrock AgentCoreの実装例を交えて探求するものです。登壇者は、Fintua社のチーフ・エンジニアリング・オフィサーであるMark Cliffe氏と、AWSのプリンシパル・データ・ソリューションズ・アーキテクトであるVenkatesh Periyathambi氏です。本記事では、セッションの内容を要約しております。なお、本記事の内容は原登壇者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの動画をご視聴いただくことをお勧めいたします。AWSのイベントに関する詳細は https://go.aws/events をご参照ください。
1. イントロダクションとエージェントの進化
1.1 登壇者紹介とロードマップ
Venkatesh： 皆さん、聞こえていますか。大丈夫そうですね。これがデータ＆アナリティクストラックでは本日最後のセッションになります。まず会場の皆さんに伺いたいのですが、エージェントを使ったり、いじったりしたことがある方はどれくらいいらっしゃいますか。ほぼ全員ですね。では、そのエージェントを触る中で、メモリを持たせることの重要性に気づいた方はどれくらいいますか。ごく少数ですね。それは良い兆候です。この一日の終わりまでに、エージェントを動かしたり構築したりするうえでメモリがいかに重要な役割を果たすかを、皆さんに学んでいただければと思います。私はVenkatesh Perumalと申します。Dublinを拠点とするプリンシパル・データ・ソリューションズ・アーキテクトです。そして本日は、FintruXのチーフ・エンジニアリング・オフィサーであるMark Cliffに来ていただいています。彼はスクリーンの後ろに隠れていますが。
Mark： ええ、隠れています。ありがとうございます。見つけられてしまいましたね。私は無料のバーが開くのを待っているところです。興味のある方はぜひご一緒に。ですが、後ほど自分のユースケースを紹介させていただきます。
Venkatesh： では本日のロードマップをお話しします。まずエージェントの進化から始め、次になぜメモリが不可欠なのかを取り上げます。そしてFintruXが自社のパイプラインをどのように近代化したかというユースケースに移ります。その後、Agent Core Memoryに入っていきます。Agent Core Memoryについては深掘りしますが、ここでの私の狙いは、深掘りに入る前に基本的な考え方、設計、そしてその背後にあるアーキテクチャの発想をお話しすることです。そうすれば、皆さんはその学びを持ち帰って、自分なりのやり方で実装できるようになります。時間が残っていればデモも行いますが、スクリーンショットを用意してあるので、それで済ませることになるかもしれません。もしうまくいかなくても、バックアップのデモがありますので、その後に動かしてみます。最後に、QRコード形式で役立つリソースもご用意しています。
1.2 生成AIから自律型エージェントへの進化
Venkatesh： ではエージェントの進化です。このスライドは、隣の生成AIトラックでも一日を通してご覧になったかもしれません。あちらは人で溢れかえっていましたね。すべては生成（ジェネレーティブ）から始まりました。数年前は、何かを入力すると、その出力は基本的にテキストや画像、動画でした。当然ながら、そこには多くの人間の介入が必要でした。問いかけたり、正しい方向へ導いたりと、人がステアリングしてやらなければならなかったのです。
そこから私たちはGenAIエージェントへと移行しました。これは興味深い領域です。ReActやChain of Thoughtといったフレームワークと一緒に動かせるようになった段階です。人間の介入を減らしながら、より広いワークフローを自動化できるようになりました。とはいえ、この段階で自動化できたのはまだ単純なタスクに限られており、それでもワークフロー自体を自動化できたという点に意味がありました。
さらに私たちは、より自律的な側へと進みました。ここでは、エージェント自身が意思決定を行えるようになります。エージェントが呼び出しを実行し、次のアクションを計画し、何をすべきか、ユーザーが求めた結論にどうたどり着くかを自ら決められるようになったのです。これがエージェンティックの世界が向かっている方向であり、すでに多くの事例やユースケース、記事をご覧になってきたと思います。そして本日のセッションでは、こうしたエージェントを構築するうえで、なぜメモリが重要な役割を果たすのかを見ていきます。
1.3 エージェンティックループの4要素とメモリの生成・消費
Venkatesh： では、このエージェンティックループのアーキテクチャは何で構成されているのでしょうか。主に4つのコンポーネントです。まずスライド上部にあるパッシブな部分、ここは環境に注意を払い、ユーザーの入力を待つところです。次に推論（リーズニング）の部分があり、ここでコンテキストを分析し、その後に何をすべきかを判断します。続いてアクトの部分です。大きなタスクが小さな単位に分解されたうえで、APIを呼び出すべきか、エンドポイントを叩くべきか、あるいはMCPサーバーを使って処理すべきかを決めます。そして実行すると、データベースを更新したり、皆さんが依頼したその他の変更を加えたりと、実際に何らかの変更を行います。その後、出力を観察（オブザーブ）し、それがユーザーの求めたものかどうかを確認して、ループが続いていきます。
この反復は、満足のいく結論にたどり着いたと判断されるまで回り続け、そこでループが止まります。ここで重要なのは、ご覧のとおり、各ステップでメモリを生成するか、あるいはメモリを消費しているという点です。これが決定的に重要な部分であり、このメモリのコンポーネント全体を支えるインフラが必要になります。そして、それを実現するうえでAgent Core Memoryがどのように役立つのかを、これからお話ししていきます。
2. なぜメモリが不可欠なのか
2.1 メモリなし／ありのカスタマーサポート体験の対比
Venkatesh： さまざまな種類のメモリの話に入る前に、まずエージェント型アプリケーションにメモリがないと何が起こるのかを理解しておく必要があります。ここに一枚のスクリーンショットがあります。左側を見てください。あるカスタマー対応のやり取りを想像してみてください。お客様にフォームが提示され、ユーザーIDを入力し、問題の説明を記入します。すべて入力し終えて、いざ実際のエージェントが対応に入ると、そのエージェントは同じ情報を何度も何度も聞いてくるのです。「アカウントIDを教えてください」「問題をもう一度説明してもらえますか」と。お客様からすれば、「ついさっき、5分前に全部やったのに、なぜまた同じことをしなければならないのか」と思うわけです。当然ながらフラストレーションが溜まり、SLAは悪化し、そこに悪い体験が生まれます。
一方、右側では同じ状況でも、エージェントはあなたのアカウントIDを理解しています。問題についても、すでに説明済みなので把握しています。さらに賢いことに、あなたのアカウントには特別なプランが紐づいていることも理解しています。これは何らかの割引かもしれませんし、個別の価格契約のようなものかもしれません。加えて、あなたが過去に似たような問題を抱えていて、それがエスカレーションによって解決されたことも知っています。ですから、お客様にすべてを説明させたり、エピソード記憶から判断を引き出させたりすることなく、「過去にこういうことが起きていたのだな。では今回はエスカレーションして解決を図ろう」と理解して動くのです。ここでは当然、より良い体験と、より速いSLAが得られます。ご覧のとおり、メモリは決定的な役割を果たしているのです。
2.2 ステートレスとステートフルの違い
Venkatesh： 左側は基本的にステートレスで、右側はステートフルです。これが次の図につながります。左側は静的なワークフロー、つまりステートレスなものです。とてもシンプルなので説明するまでもありませんが、ユーザーが入力を与えるとLLMがそれを処理して出力を返すだけです。永続性もなく、保持すべき履歴もなく、学習したり取り出したりするものも何もありません。そして毎回コールドスタートになります。新しいセッションが始まった瞬間、それまでに起きたこととは一切無関係で、まるで金魚のような記憶しか持たないのです。
一方、右側ではオーケストレーターを持ち、ストレージへのアクセス、メモリへのアクセス、ツールへのアクセスを得ることになります。そのメモリ層へのアクセスがあることで、取り出すこともできれば、保存することもでき、時間とともに賢くなっていくことができます。さまざまな種類のメモリについては、この先でさらに詳しく見ていきます。
2.3 フレームワーク非依存のオーケストレーター設計
Venkatesh： ここでオーケストレーターについて触れておきます。オーケストレーターは基本的にフレームワークに依存しないものであるべきです。特定のフレームワークに縛られるのではなく、その上にストレージ層、メモリ層、ツール層へのアクセスが成り立っている、という構図です。ステートフルな仕組みでは、このオーケストレーターがメモリ層を介してコンテキストや学習を呼び出し、ユーザーの入力に対して状態を保ちながら応答できるようになります。
つまり、メモリ層へのアクセスを備えたフレームワーク非依存のオーケストレーターこそが、ステートレスな金魚のような振る舞いから抜け出し、取得・保存・継続的な賢さの向上を可能にする鍵になるのです。この設計の発想を念頭に置いていただいたうえで、次はメモリがない場合に具体的にどのような失敗が起こるのかを見ていきましょう。
3. メモリ欠如による5つの失敗モード
3.1 コンテキストウィンドウの枯渇とコスト試算
Venkatesh： ここで、いわば5つの失敗モードをご紹介します。ボットとやり取りをした経験のある方なら、この会場にいる誰もが、どれか一つは経験したことがあるはずです。一つ目はコンテキストウィンドウの枯渇、私たちが「アムネジア（健忘）ループ」と呼んでいるものです。ご存じのとおり、プロンプトにはトークンの上限という天井があります。問題を説明し始めると、エージェントが確認のための質問をしてくるので、会話を続けますよね。10ターン目あたりで上限の何割かに達し、20ターン目あたりでおそらく天井に届きます。そして天井に達した瞬間に何が起こるかというと、コンテキストを切り捨て始めるのです。すると、最初に聞いてきた質問、「アカウントIDを教えてください」を、また聞いてくることになります。こちらとしては「いや、それこそ最初に伝えたことだろう」となるわけです。つまり、それまで取り組んでいたコンテキスト全体を見失ってしまった、ということです。これは大きな問題で、原因はひとえにトークンを使い果たしたことにあります。結果として、すべてをもう一度説明する羽目になり、それはつまり余計に費用を払うことになるのです。コストの例を挙げると、1,000トークンあたり15セントを支払う場合、ざっくり月22,500ドルにもなります。
3.2 嗜好喪失と冗長なツール呼び出し
Venkatesh： 二つ目は、嗜好やパーソナライゼーションの喪失です。もしあなたが常連の買い物客なら、その会社やショッピングサイトには自分の好みを把握していてほしいと期待しますよね。何かアレルギーがあれば、そのアレルギーに該当する商品を勧めてこないでほしいと思うはずです。そうしたパーソナライゼーションのメモリがなければ、当然ながら良い体験は得られません。
三つ目は冗長なツール呼び出しです。たとえば、自分のノートPCをIT部門に預けたとします。それをエージェントに尋ねるわけです。「私のノートPCのステータスはどうなっていますか」と。最初に返ってくる答えは、「IT部門にあり、2025年3月11日にハードウェアチームへトラブルシューティングのために割り当てられました」というものだとします。あくまで一例です。次にあなたが「いつ提出されましたか」と尋ねます。答えはすでに「3月11日」とわかっているのに、エージェントは先ほど何を取得したかを覚えていないため、もう一度APIを呼び出してしまうのです。ここでメモリは、起きていることを文脈づける、つまりコンテキスト化するうえで大きな役割を果たします。
3.3 失敗から学習できない問題とマルチターン
Venkatesh： 四つ目は、失敗から学習できないという問題です。エージェントには本当に賢くあってほしいわけですが、これこそがPOCのエージェントと本番のエージェントを分ける点です。エージェントには失敗から学んでほしいのです。たとえば、あるAIエージェントに問い合わせると、標準的なトラブルシューティングの手順を案内してきます。「コンピュータを再起動してください」「キャッシュをクリアしてください」といった具合です。ところが、それでは解決できません。そこでエスカレーションすると、ITチームが「ファイルサイズの上限は10MBで、それを超えています。解決策は、たとえばPDFを圧縮することです」と教えてくれたとします。これは一つの学びになったわけですね。しかし、別のユーザー（ユーザー2）が来て同じ質問をエージェントにすると、エージェントはまた同じこと、つまり「キャッシュをクリアしてください」「コンピュータを再起動してください」と答えてしまいます。本当の解決策は圧縮することなのに、失敗から学んでいないためにそうなってしまうのです。ユーザーであれ、エージェントを構築する側であれ、この文脈を持たせることは極めて重要です。
五つ目のマルチターンについては、この後のスライドでより詳しくお話ししますので、ここでは短く切り上げておきます。
4. 本番運用可能なアーキテクチャ
4.1 オーケストレーター層とメモリ層・ツール層
Venkatesh： ここでお見せするのは、エンドツーエンドの本番運用可能なアーキテクチャです。ここでの主たる狙いは、オーケストレーター層について語ることにあります。先ほども申し上げたとおり、このオーケストレーターはフレームワークに依存しないものであるべきです。LangGraphでも、CrewAIでも、Strandsでも、何であっても構いません。そして、この構成で何より良いのは、オーケストレーターがメモリ層と長期ストレージへのアクセスを持っているという点です。メモリといっても、それはどこかに保存しておく必要があるわけで、そこでデータストアの一群が登場します。
さらにオーケストレーターはツール層へのアクセスも持っています。ここで本当に重要なのは、本番運用に耐えるエージェントを構築する際、メモリは「あれば良い」という付加機能ではない、ということです。
4.2 メモリは必須という主張
Venkatesh： メモリは必須であり、システムをその前提で設計しなければならないものなのです。もちろん、ほかにもさまざまなコンポーネントはありますが、私のセッションはメモリについてのものですので、メモリの部分をより強調してお話ししています。本日の主役はあくまでメモリです。
ここまで見てきた失敗モード、すなわちコンテキストの枯渇や、嗜好の喪失、冗長なツール呼び出し、失敗から学習できないといった問題は、いずれもメモリを後付けの便利機能として扱った結果として生じるものです。だからこそ、本番システムでは最初からメモリを設計の中心に据える必要がある、というのが私の主張です。
4.3 実行時の流れ
Venkatesh： では、これが実際に動くときの流れを手短に見てみましょう。ユーザーのクエリが入ってくると、メモリ層の助けを借りて、私は短期メモリからコンテキストを、長期メモリから自分の学びを取得することができます。それらをもとに推論を行い、LLMの助けを借りて次のステップを組み立て、より速い解決を提供します。これが本番システム上での実際の動き方です。もちろんこれは作り込んだシナリオではありますが、これらすべてがどう連携して働くのか、その全体像はつかんでいただけると思います。
そしてここからは、Markに登場してもらいます。彼の近代化のユースケースについて語ってもらいます。Mark、お願いします。
5. FintruXの近代化事例 ― サーバーレス移行と技術スタック（Mark Cliff）
5.1 2,000倍の処理量増加とサーバーレス移行の説得
Mark： ありがとうございます。皆さん、こんにちは。一日の最後の小さなセッションということで、皆さん少しお疲れだと思いますが、それで全く構いません。ただ、ちょっと楽しいことをして、隣の部屋の皆さんに悪戯を仕掛けたいと思います。今日が初めてのAWSカンファレンスだという方、手を挙げてください。それほど多くはないですね。先ほど隣の部屋から歓声や拍手が聞こえてきましたよね。では、私が3つ数えたら、皆で数秒間叫んで歓声を上げて拍手しましょう。隣の部屋は何が起きているのか分からず、自分たちが何かを見逃しているように感じるはずです。いいですか。1、2、3。さあ、これで少し目が覚めましたね。
さて、私たちは2025年から2026年にかけて、大きな変化を経験しました。本日は2つの領域を見ていきます。一つは処理能力の増強、もう一つは生成AIに関するものです。私はちょうど一年前にこの新しい仕事に就きました。私は良い挑戦が好きなのですが、その挑戦とは、トランザクション処理量を2,000倍に増やすというものでした。これを2026年末までに達成しようとしているところです。もちろん挑戦は受けて立ちます。これは少し面白いことになりそうだぞ、と。
私たちは、これをグローバルに提供しながらトランザクションのスループットを高く保つ方法を検討し始めました。ただし、一つのクライアントが膨大なデータを送ってきても、その負荷が他のクライアントに波及して悪影響を及ぼすことは避けたかったのです。誰もが良いカスタマーサービスを提供したいですからね。そこで、すべてをサーバーレスのコンピュートモデルへ移行することを検討し始めました。これは、もし取締役会を説得できるなら、素晴らしい選択です。そして、それを説得するのが信じられないほど難しいのです。皆さんの中で、5年前にリリースされたアプリケーションに携わっている方、手を挙げてください。何人かいらっしゃいますね。そういう状況で、プロビジョンド環境からサーバーレス環境へ移行するよう取締役会を説得するのは、ものすごく困難なのです。
5.2 AIツールによる再アーキテクチャの容易化
Mark： そこには膨大な書き直しが伴います。私たちが取り組んできたことの一部は、単なる書き直しという観点だけでなく、マイクロサービスの全面的な再アーキテクチャという観点からのものでした。ここで、道中で学んだいくつかの手早い成果や知見をお話しします。もし一年前にこの旅を始めたとき、AWSのTransformプロジェクトがすでに完全に出荷されていたら、私はやりたかったところまで、はるかに速くたどり着けていたでしょう。かなり定期的にさまざまなツールが登場してきており、このプロセス全体をずっと簡単に、ずっと安く行えるようにしてくれます。
もし今、取締役会に戻って「素晴らしいアイデアがあります。古いプログラミング言語で書かれたものを全部、モダンな言語に書き直しましょう」と言い、その費用として約300万ドルの見積もりを出したら、彼らはノーと言うでしょう。決して承認は下りません。しかし、今利用できるAIツールを使えば、文字どおり書き換えを投入し、翌日には取り出すこともできます。そうなると、キャリアで経験したことのないほど途方もなく大規模なテストが待っているわけですが、それでもこれらは今や本当に実行可能なことなのです。Jiraのようなツールもあり、変換したコードに対して検証を走らせることができます。プロビジョンド環境からサーバーレス環境への移行を、しかも途中で言語まで変えながら行うこと、これは、技術者として「なぜ取締役会は承認してくれないのか」と愚痴をこぼすようなことから、今やこの会場にいる一人ひとりがPOCを実行し、何らかの本物のユースケースやROIの試算を取締役会に示せるようなものへと変わったのです。
私たちは本物のデジタルトランスフォーメーションの時代にいます。私のキャリアは二十数年に及びますが、正確な数字は自分が年寄りに感じるので言いませんけれども、長い間この仕事をしてきた中で、ずっと「愛着のあるプロダクトでこうできたらいいのに」と願ってきたことが、今や実際に実行でき、変革できるようになったのです。
5.3 技術スタックの変遷とS3 Tablesによる98%コスト削減
Mark： 面白い話をすると、私は新しい仕事に就いたとき、いつもやることをやりました。腰を据えて、ビジネスのワークフロー全体がどう回っているかをすべて洗い出すのです。骨の折れる作業ですが、就いたどの仕事でも必ずやってきました。当初の構想は、各国をより速くオンボーディングでき、保守も行える素晴らしいユーザーインターフェースを用意する、というものでした。ところが、ここで顔面を殴られるような瞬間が訪れます。仮に魔法の杖を振って、世界各国をカバーできたとして、いったいそれをどうやって保守し続けるのか、と。各国をオンボーディングするのと同じだけの作業量が、ずっとついて回るのです。複雑さの例を挙げると、VATの世界では、ドイツでVAT申告を行うのと、ベネズエラでVAT申告を行うのとでは、入力するフィールドの組み合わせがまったく違います。スキーマがまるごと異なり、一致するものなど何一つありません。税法はすべて別個の新しい文書で、それを追い続けるのは本当に悪夢でした。仮にソフトウェアでこれを実現できたとしても、その保守をどうやって賄えばいいのか、というわけです。そこで、まず技術面で何をしたかをお話しし、その後にAIで何をしたかをお話しします。
最初はすべてかなり単純でした。オンプレミスのサーバー環境から始まり、その後クラウドへ移行しました。クラウドに移ったときには、SQL RDSのようなものを使っていました。クラウドで動いているとは言えますが、私の分類ではクラウドネイティブな技術とは言えないものです。サーバーレスコンピューティングという発想が入ってくるのは、まさにそこからです。Fargateを技術的にサーバーレスと分類できるか、と言えば、まあできるとは思いますが、Lambdaのように数ミリ秒で自動的に何百万ものコピーを立ち上げるわけではありません。私たちはかなり単純なモデルから出発し、そこからはるかに複雑なものへと移っていきました。SQSのような部分はそのままに、データベース技術をDynamoDBとS3 Tablesに切り替えたのです。
この計画と設計のフェーズは本当に面白い作業でした。私はNoSQLソリューションの大きな支持者で、だからこそここにDynamoDBが入っているのですが、私たちが見いだしたのは、S3 Tablesを導入することでアーキテクチャのコストを98%削減できる、ということでした。S3 Tablesは異常なほど安く、扱うのも本当に簡単です。DynamoDBの利点の多くを得られますが、たとえば毎秒50万件のトランザクションが必要ならDynamoDB、それが不要ならS3 Tables、というように使い分けられます。一方は超安価、もう一方は大量に投入すると高くつきますが、原子的なレベルで見れば、SQL RDSよりもはるかに安いのです。おおまかな桁感で言えば、投入する1ドキュメントあたり、DynamoDBはSQL RDSより約100倍安かったと記憶しています。ですから、こうした技術をサーバーレス技術へ移行するユースケースを取締役会に示したいとき、これは本当に、結果としてはるかに安く済むことになるのです。
6. FintruXの近代化事例 ― ステートレスAIとエージェンティック・スウォーム（Mark Cliff）
6.1 国別オンボーディング維持の気づきとステートレスAIの選択
Mark： では、「魔法の杖を振って、指を鳴らして、魔法のランプを擦ったら世界各国をカバーできていた、でもそれをどう保守するのか」という問題を、私たちはどう乗り越えたのか。ここでAIが登場します。そして、これがこのセッションをメモリの話につなぎ戻す部分でもあります。メモリは常に欲しいものとは限りません。欲しいときもありますし、今後私たちが取り組んでいくことの多くでは、メモリは素晴らしいものです。短期メモリという概念も、長期メモリという概念も、Amazon BedrockやAgent Coreはそうした機能をすべてサポートしています。ところが、私たちの国別オンボーディングに関しては、おかしな話に聞こえるかもしれませんが、それらが欲しくなかったのです。私たちが欲しかったのは、いわゆるステートレスなAIでした。
なぜそんなものが欲しかったのか。実は以前、日の目を見なかったAIプロジェクトがありました。チャットボットを作って、「今この瞬間、スペインでのCoca-ColaのVAT率はいくらか」と尋ねられるようにしたかったのです。それは膨大なデータセットで学習されていました。その結果どうなったかというと、そのデータの中に矛盾する答えが含まれていたのです。
6.2 ハルシネーション考察と24時間ごとの再学習
Mark： 私たちはよく、ハルシネーションについて語り、AIが情報を間違えたと言います。でも、もし私が4人の子どもに「リンゴは何色か」と尋ねて、ある子が「緑」と言い、別の子が「赤」と言ったとして、どちらかが間違っているでしょうか。いいえ、間違ってはいません。どちらも正しいのです。VATでもこれと同じことが起こります。そこで私たちが行ったのが、ステートレスAIの活用でした。「よし、24時間ごとにAIを再学習させよう。そしてここに立法文書を渡そう」としたのです。
ステートレスにすることで、矛盾する複数の正解を抱え込んだ巨大な学習済みモデルではなく、最新の立法文書という単一の確かな根拠に基づいて、その都度クリーンに判断させることができるようになりました。VATのように国ごとに正解が分かれ、しかも法律が頻繁に更新される領域では、過去の記憶を引きずらないステートレスな設計のほうが、むしろ正確で信頼できるのです。
6.3 エージェンティック・スウォームの設計と成果、ヒューマン・イン・ザ・ループ
Mark： さらに私たちは、これを完全なエージェンティック・スウォーム（エージェントの群れ）として構築しました。このエージェンティック・スウォームは、現在私たちが持っているチームと、その業務内容を直接そのまま映し出したものです。何らかのAIエージェント開発を行う際の大きなコツをお伝えします。各エージェントには、できる限り少ないことだけをさせ、その代わりにたくさんのエージェントを用意することです。そうすれば、スウォームのどこかに問題が起きたとき、「これはあのエージェントだ」と特定できます。「全部ダメだ、使い物にならない」とはならず、「いや、問題はあの一箇所だけだ、そこを直せばいい」となるのです。これは、私たちが何年も使ってきた基本的なソフトウェア開発のオブジェクト指向の原則と同じです。異なるクラスを持ち、継承はそこまで多用せず、エージェントをあたかもクラスのように扱う、という具合です。とてもシンプルでわかりやすい見方ですね。
私たちのエージェンティック・スウォームが具体的にどんな姿をしているかはお見せできません。なぜなら、それはスウォームが社内の管理プロセスをそのまま再現したものであり、明かせない知的財産だからです。ただ、もし皆さんが自分のエージェンティック・スウォームを構築したいなら、まずそこから始めてください。ビジネスプロセスマップを描き出し、異なる部門がどこにあり、どう連携しているかを見て、それをより小さなエージェントへと分解していくのです。私たちが達成したのは、本質的にそういうことです。
その結果、これは誇張でも何でもなく、1つの国をオンボーディングするのに従来は1〜2か月かかっていたものが、今や数分のプロセスにまで短縮されました。そして、それを行う実際のコストは約1ユーロになりました。一方で、複数のチームメンバーを抱えるコストと比べれば、その差は歴然です。これは単に速さやコストだけの話ではありません。AIがすべての情報を取りに行き、自分が行ったすべてに対して信頼度（コンフィデンス・レベル）を示してくれるので、ヒューマン・イン・ザ・ループの要素が成り立つのです。専門の税務担当者がそれを見て、「これでいい」あるいは「これはダメだ」と判断できます。これは学校に戻って数学の宿題をやるようなものです。途中の計算過程を書き出さなければ、満点はもらえませんよね。それと同じで、すべての計算過程を示しておくことで、規制が厳しく複雑な環境にいる人々が、本当に的確で素早い判断を下せるようになります。AIが「ここは自信があります。この結論にこう至りました」と示してくれるので、専門家は「同意する」あるいは「同意しない」と言えるのです。以上が私たちのAIと近代化の旅でした。では、バトンをお返しします。
7. AWS AIポートフォリオとAgent Coreの位置づけ（Venkatesh Perumal）
7.1 データ基盤の重要性とインフラ・データサービス層
Venkatesh： ありがとう、Mark。さて、私の番に戻りました。ここからBedrock Agent Coreの話に入っていきますが、Agent Coreの中にあるすべてのモジュラーサービスについて語るつもりはありません。メモリだけに焦点を当てます。Agent Coreをまだ耳にしたことがない方のために、それが何かはこの後すぐにお見せします。今朝の基調講演でもご覧になっているはずです。
まず、AWSのAIポートフォリオにどのようなサービスがあるのか、別の視点からお見せします。皆さんがご覧のとおり、一番下にインフラの部分があります。ここがこの会場のどの組織にとっても鍵となるコンポーネント、すなわちデータ基盤です。もしデータ基盤が正しく整っていれば、仕事の約80%は完了したも同然です。残りの20%は技術にすぎません。技術は選べますし、それを使って取り組めばよいのです。しかし、強固なデータ基盤がなければ、それこそが本当の課題になります。私たちにはSageMaker Studioがあり、リレーショナルデータベースサービスがあり、オープンソースやNoSQL、OracleやSQLもあります。挙げればきりがないほど揃っています。さらにRedshiftがあり、S3があり、Markが話していたようにS3 Tablesもあります。その上にはIcebergがあり、オープンスタンダードの発想で扱うことができます。
7.2 モデルとモジュール式Agent Core、フロンティアエージェント
Venkatesh： そうしたものがすべて整ったうえで、自分なりのルートを取りたいなら、トレーニング用のチップなどのAIコンピュートを使えます。勇気があれば、自分でモデルを構築することもできます。あるいは、既存のモデルを使いたいなら、Bedrockがあり、そこからモデルを選べます。これらは開発ソフトウェアサービスに分類されます。そこにはAgent Coreのようなモジュラーサービス群があり、まるでLego（レゴ）のように、必要なものを選び取って組み合わせることができます。これについては後ほど詳しくお見せします。
さらに、さまざまなフレームワークがあります。ここにあるサービスの大半はフレームワーク非依存です。つまり、一つのフレームワークに縛られるわけではなく、LangChainでもLangGraphでも、好きなフレームワークを使い回すことができます。そして、フロンティアエージェントというものがあり、これは非常に新しいものです。ごく最近発表されたばかりで、私たちが向かっている先がまさにここです。これこそが本来の自律型エージェントです。Kiroはそうしたエージェントの一例で、人間の介入なしに、あるいは介入をより少なくして、24時間365日働き続けることができます。タスクを与えれば、皆さんが望む出力をひたすら出し続けてくれるのです。
7.3 デモと本番の差、Agent Coreの構成要素
Venkatesh： では、ここでの本当の課題は何でしょうか。デモ用のエージェントを作ることはできます。それは自分のマシンでは動きます。これは昔ながらの「自分のマシンでは動く／動かない」という話とまったく同じです。チームや組織の外へデプロイしようとした瞬間に、自分のマシンにあるもの以上のものが必要だと気づくのです。アイデンティティが必要で、ランタイムが必要で、オブザーバビリティが必要で、ガードレールも必要、といった具合です。その作業を楽にしてくれるのが、まさにAgent Coreです。
ご覧いただけるよう少し位置をずらしますね。揃っているサービスを見ていきましょう。まずランタイム、これは内部的にはEKSのようなものです。メモリはいったん飛ばします。認可と認証のためのアイデンティティ、APIエンドポイントを扱うためのゲートウェイ、監視のためのオブザーバビリティ、ガードレールのためのポリシーと評価（policy and evaluations）があります。そして本日の主役は、もちろんメモリです。私はこのメモリに焦点を当てていきます。とはいえご覧のとおり、きちんとしたアプリケーションを成り立たせるには、これらすべてが必要になります。ただし、必ずしもすべてを使わなければならないわけではありません。本番で開発・デプロイしたいものに合わせて、必要なものを選び取ればよいのです。
8. 短期・長期メモリの基本概念と長期メモリの戦略
8.1 短期メモリと長期メモリの基本概念
Venkatesh： Markがさまざまな種類のメモリについて話してくれましたね。私たちと同じように、機械もまた人間の振る舞いを模倣しようとしているのだと思います。つまり、エージェントにも人間が持つ2種類のメモリ、すなわち短期メモリと長期メモリを持たせようとしているわけです。では、これをどう模倣するのでしょうか。短期メモリは基本的に「今このとき」のものです。私が交わしている会話、あるいは今提示しているコンテキスト、そのセッションそのものです。これがコンテキストにあたります。一方、長期メモリは、私が長年かけて身につけてきたスキルや、私の好みといったものです。エージェントにこうした振る舞いを持たせたい、そしてそれをどう実現するかをこれからご覧いただきます。
スクリーンショットをいくつか用意しています。本当はデモを動かしたかったのですが、ネットワークが不安定でなかなか難しいと分かったので、今朝これらをスクリーンショットに変えておきました。たとえば、ユーザーが「iPhoneでアプリを切り替えるにはどうすればいいですか」と尋ねたとします。すると、エージェントは「どのモデルをお使いですか」と尋ね、ユーザーは「iPhone 16です」と答えます。これで今、エージェントはコンテキストがiPhone 16についてのものだと把握しました。以降のどんな会話でも、エージェントはコンテキストがiPhone 16に関するものだと分かっているので、その後のやり取りはすべてiPhone 16を軸に進みます。次に「iPhoneでスクリーンショットを撮るにはどうすればいいですか」と尋ねられても、「では、このガイドを参照してこう撮ります」と、中断したところから再開できるのです。これが、目の前のコンテキストに対する短期メモリの働きです。
8.2 ユーザー嗜好・セマンティック・サマリー戦略
Venkatesh： 長期メモリはここから本当に面白くなります。まずユーザー嗜好（user preference）から見ていきましょう。これからお見せするスクリーンショットは、それぞれ異なる戦略（ストラテジー）にあたります。そして、これらはAgent Coreが標準で（アウト・オブ・ザ・ボックスで）サポートしているので、「どう設定すればいいのか」と心配する必要はありません。ワンクリックで使えます。たとえば1月1日に、まったく別の会話の中で、あなたがたまたま「私は特定のブランドのヘッドフォンが好きで、割引も持っていて、ほしい色はこれだ」と口にしたとします。後日、あなたが「ヘッドフォンがほしい、古いものを買い替える時期だ」と尋ねると、エージェントはユーザー嗜好を参照して、「なるほど、このユーザーにはすでにこういう好みがある」と把握し、その好みを取り入れて応答するのです。これはユーザーにより良い体験を提供する、気の利いたやり方です。
次にセマンティック（semantic）です。これはRAGに似ています。RAGを扱ったことのある方は多いと思いますが、知識ベース、ベクトル、セマンティック検索といった言葉によく出くわすはずです。これも何ら変わりはなく、まさにそれです。つまり事実としての知識です。たとえば「先週買ったBoseのヘッドフォンを返品したいのですが、ほかでもっと安く見つけてしまいました」と尋ねたとします。私が確認するのは、知識ベースの中にある自社の返品ポリシーや価格調整のポリシーです。ここで疑問が浮かぶかもしれません。「自分は履歴の中でポリシーや過去の価格調整について話していないのに、どうやってチャットはこの情報を見つけられるのか」と。そこで登場するのが戦略の使い分けです。これをエージェントのパイプラインに組み込んでおけば、ユーザーが尋ねたとき、必ずしも現在のセッションからでなくても、たとえばすべての価格情報にアクセスできるグローバル戦略から、セマンティック検索を使ってその情報を取りに行けるのです。
サマリー（summary）は、その名のとおりのことをします。これまで話してきた内容の要約をそこに書き込むのです。「ユーザーは新しい白のオープンイヤホンを購入し、古いものを買い替えたいと考えていて、より安い価格を見つけ、100だけ安く手に入れた」といった具合に、これまでに起きたことの基本的な要約です。これがまさに起きたことであり、その要約を長期メモリに保存します。後日ユーザーが「ヘッドフォンを壊してしまった」と尋ねると、メモリを確認して保存内容を使い、「過去にこういうことをされていますね。では、今回の問題を教えてください。そこから進めましょう」と応答できるのです。
8.3 エピソディックメモリとリフレクション
Venkatesh： エピソディックメモリ（episodic memory）は、おそらく最も扱いの難しいものの一つで、これはかなり最近、今年の初めにリリースしたばかりだと思います。これは、会話の中からエピソードを見つけ出して保存しようとするものです。そして、リフレクション（reflection／内省）と呼ばれる部分があります。先ほどお話しした、ノートPCの再起動やキャッシュのクリアを案内するトラブルシューティングのエージェントを思い出してください。実際の問題はファイルサイズが10MB以上だったことで、それを縮小しなければならなかったわけです。これが一つのエピソードであり、何がうまくいかなかったかを学び、その学びを入力として使うので、これがリフレクションになります。
これも必ずしも自分の会話からでなくてもよく、グローバルな戦略レベルからのものでも構いません。ただ、エピソディックメモリはたいていユーザーレベルで設定します。そうすればユーザーが何をしたかを覚えていられるからです。とはいえ、先ほどの10MBのケースのように、特定のユーザーに依存しないものであれば、グローバルレベルで設定することもできます。エージェントはエピソディックメモリを確認し、画面の右側にあるような特定の構造で記録します。すなわち、Context（文脈）、Goal（目標）、Action（行動）、Outcome（結果）、Insight（洞察）です。これが私が話していた学びにあたります。前回のケースで文脈は何だったか、目標は何で、どんな行動を取り、結果はどうだったかを見て、もしそれが良い結果であれば、それをInsightとして書き込むのです。たとえば「ユーザーがフラストレーションを示しているときは、素早く焦点を絞った応答が必要だ」といった具合です。あるケースでは、ユーザーは音質が悪くて不満を抱いていて、新しいブランドを勧めてほしいと言いました。この経験に基づけば、エージェントはセラピーのようなやり取りをするのではなく、「では、私のおすすめはこの3つです。どうぞ」とずばり提示します。それが他の顧客でも常にうまくいってきたからです。こうしてユーザーは次のステップへと進めるのです。
9. データフローとAgent Core Memoryの仕組み
9.1 同期・非同期のデータフロー
Venkatesh： では、これが実際にどう動くのかを見ていきましょう。ユーザーがチャットエージェントと会話をします。そして、その生のイベントはそのままの形で短期メモリへ入っていきます。つまり、生の会話は、メタデータを含んだ会話テキストの塊（ブロブ）として扱われるわけです。メタデータの中身については後ほどスクリーンショットでお見せしますが、今のところ理解していただきたいのは、その会話の塊が同期的に短期メモリへ入る、という点だけです。
そして、右上にメモリ抽出モジュール（memory extraction module）があります。これが非同期的に、データを取得し、抽出し、統合（コンソリデート）し、埋め込み（エンベッド）を行い、索引付け（インデックス）をして、メモリに格納します。そして必要になったときには、長期メモリからそれを取り出してきます。これがワークフローです。短期メモリへ入る部分だけが同期的で、それ以外はすべて非同期である、という点を押さえてください。
9.2 ワンタイム設定とPython SDK
Venkatesh： 先ほども申し上げたとおり、これは一度きりの設定で済みます。このAgent Core Memoryを開いて設定する際には、ユーザー、セマンティック、エピソードといった戦略を選びます。設定した瞬間に、あとはすべて自動的に行われます。実際に何かをセットアップする必要はなく、Agent Core Memoryが自動でやってくれるのです。そして画面の下部にあるとおり、これはサーバーレスです。監視とトレーサビリティのためのオブザーバビリティが組み込まれており、TTL（time to live）もあります。つまり、すべてを保存しておく必要はなく、たとえば「10日経ったらメモリを完全に消す」といったTTLを設定すれば、それを覚えていて実行してくれます。さらに柔軟なネームスペースがあり、ここに戦略が関わってきますが、これについては次のスライドで詳しくお話しします。加えて、暗号化も組み込まれています。
そして、これがPython SDKです。とてもシンプルです。セッションを使い、Agent Core Memoryからメモリを作成、取得、あるいは読み出すことができます。メモリ名や説明、設定したTTLがあり、そしてIDが得られるので、それを自分のアプリケーションの中で使い続けられます。ご覧のとおり、手早く、速く、使うのも簡単です。エージェントでAgent Core Memoryを使い始めれば、それがどれほど有益かを実感していただけるはずです。
9.3 短期メモリの内部構造とブランチング
Venkatesh： これが先ほど話した部分です。生のイベントはメタデータを含む会話の塊として入ってきますが、短期メモリへ同期される際には、セッションの状態を伴ったチャットメッセージとして保存されます。短期メモリの中身、すなわち短期メモリにあるイベントを一覧表示すると、ご覧のようなものが見えてきます。画面右側に見えるのは、メモリID、アクターID、セッションID、ペイロード（これが実際のメッセージにあたります）、タイムスタンプ、ブランチング、そしてメタデータです。これがその構造で、JSONのようなものだと考えてください。これらがプロパティのフィールドであり、要するに短期メモリにはこうした要素がすべて含まれています。あとは、長期メモリのアセットを使うか、あるいは自分なりの抽出方法を用いて好きなように処理するか、皆さん次第です。
そして、ブランチングと呼ばれるものがあります。おそらくLLMを使う中で経験したことがあるシナリオだと思います。チャットの途中で打ち間違いをして、そこへ戻って質問を編集し、「いや、本当はこれではなく別のものがほしかった」とすることがありますよね。すると、そこで枝分かれ（ブランチ）します。あるいは会話の途中で「もうこれではなく、別の目的にしたい」とすることもあります。そうしたときにブランチングが効いてくるわけで、短期メモリはそれをサポートしているのです。
10. 長期メモリの管理方式と抽出・統合メカニズム
10.1 マネージド・オーバーライド・セルフマネージド戦略
Venkatesh： では、長期メモリに移りましょう。長期メモリの例はすでに見てきましたね。例をお見せした理由は、これらが実際の場面でどう使われるのかをより良く理解していただくためです。サマリー、ユーザー嗜好、セマンティック、エピソディック、これらはAgent Coreによって管理されます。つまり、一度設定すれば、あとは忘れていてよいのです。そして、Agent Coreアプリケーションを使う際に、どこでもそれを利用できます。
一方、下の2つ、オーバーライド（override）とセルフマネージド（self-managed）は、皆さん自身が管理するものです。先ほどのアクターID、セッションID、ペイロード、タイムスタンプといったプロパティを思い出してください。セルフマネージドでは、それらのプロパティを使うことになります。
まずオーバーライド戦略です。これが意味するのは、「抽出と統合について、自分で独自の戦略を書く」ということです。自分でモデルを選べますし、短期メモリから何を抽出するか、自分でプロンプトを書くこともできます。短期メモリのものをすべて長期メモリへ入れたいわけではありませんからね。何を短期から長期へ抽出するか、自分なりのパイプラインを構築できます。抽出のために選べるモデルがあり、統合のために選べるモデルがあり、そこに自分のプロンプトを書く、というわけです。これがオーバーライドです。
セルフマネージドも似ています。エージェントが短期メモリへ何かをプッシュした瞬間に、それがS3へ書き込まれ、通知が届きます。通知を受け取ったら、ユーザーである皆さんが自分でパイプラインを構築します。これは完全に端から端まで自分で管理するものです。抽出にあたっては、先ほど申し上げたとおり、パースして、自分の独自ロジックを適用し、抽出し、統合します。統合は厄介な領域なので、これについては後ほど触れます。既存のレコードを統合し、重複排除（デデュプリケーション）を適用し、競合を解消してから、レコードへ保存します。そしてすべてが終わったら、それを長期保存のためにAgent Core Memoryへプッシュします。ここで関わってくるのが、対応するベクトルストレージサービスです。画面の下部にあるとおり、これらはベクトル検索をサポートするネイティブなサービスで、この中から任意のものを選んで使えます。上部にあるのは、Bedrock環境の中でサポートされているベクトルサービスです。何をベクトルストアにするかは選び放題ですが、それぞれに長所と短所があるので、本番に移す前に必ずテストしてください。
10.2 抽出方法・トリガー・統合の内部動作
Venkatesh： では、メモリを抽出するさまざまな方法を見ていきます。一つ覚えておいていただきたいのは、デフォルトではAgent Core Memoryが短期から長期へ自動的にメモリを抽出してくれる、ということです。最初に挙げられるのは、API経由で長期メモリへエクスポート・インポートできるという選択肢です。ただし、私たちが一緒に仕事をする多くの顧客は、この経路を選ばず、単に自動の仕組みを使います。
ここは手早く進めます。3つのスライドで似た内容が出てくるからです。その戦略はこうです。短期メモリにトリガーを設定し、「メッセージごと」「10メッセージごと」「10秒間の非アクティブごと」といった条件で、短期から長期へすべてをプッシュします。プッシュされると、メモリ抽出モジュールが働きます。これがメッセージを受け取り、統合し、ベクトルストア向けに埋め込みと索引付けを行って、長期メモリへ格納します。統合の中で実際に何が起きているかをもう一段掘り下げると、まず重複がないかを確認します。重複があればスキップし、わずかな変更があれば既存のメモリを更新しようとし、何もなければただスキップします。これが内部的に起きている仕組みで、これらはすべて自動です。何も心配する必要はなく、すべてAgent Core Memoryがやってくれます。これがここでの朗報です。
エピソディックメモリは大きく異なります。エピソードには、先ほどのスライドにあったとおり、Action、Objective、Goal、Outcome、Insightがあります。各エピソードのあとに、これがエピソディックな洞察を抽出して書き留めます。同じ考え方ですが、全体を書き込むのではなく、エピソードだけを捉えるのです。しかも、その特定のエピソードや会話が完了したと判断されてから、初めてそのエピソードを書き留めます。一つの会話には必ずしも一つのエピソードしかないとは限りません。長い会話の中に、たとえば10個もの異なるエピソードが含まれることもあります。そこでリフレクションモデルが登場します。10個の異なるエピソードがあれば、何が起きたかについての大まかな全体像（オーバービュー）を書き出します。それ以外は同じで、埋め込み、索引付けをしてベクトルストアへ格納し、期待どおりに取り出せるようにするのです。
10.3 ネームスペースの階層構造
Venkatesh： これがネームスペースです。次のスライドを見ると、よりイメージしやすいと思います。下から見ていきましょう。一番下はグローバルレベルで、ちょうどファイルシステムのようなものです。最上位にあたり、エージェント全体に適用されます。次に、特定のチームへ降りていきたければ、戦略ID（strategy ID）を使ってそこから始めます。さらに、特定の部門のようなアクターへ降りていきたければ、アクターレベルへ進みます。そして、その先にセッションレベルやユーザーレベルがあります。最上位にあたるのがこのユーザーレベルで、現時点で利用できる最も粒度の細かい選択肢です。この戦略IDに基づいて、セッション内でメモリをどう使うかを設定できます。
これが先ほど申し上げたことで、エピソディックメモリは単一セッション内でも、セッションをまたいでも構いません。セマンティック検索が、どのようにグローバルからユーザーへと受け渡されていくか、その設定の仕方によって、すべてAgent Core Memoryが自動で行ってくれます。エンドツーエンドの流れは以前にも見たとおりです。生のメッセージがセッション内のチャットメッセージとして短期メモリへ入り、メモリ抽出モジュールが抽出・統合し、長期メモリへプッシュします。そして、皆さんが設定した構成に基づいて格納され、取り出すときには長期メモリから取得されます。これが覚えておいていただきたい全体像です。繰り返しになりますが、これはすべてAgent Coreがやってくれます。皆さんがすべきことは、どの戦略で進めるか、アクターレベルか、グローバルレベルか、ユーザーレベルかを選ぶことだけです。それさえ決めれば、あとはすべてAgent Coreが面倒を見てくれます。
11. ベストプラクティスとクロージング
11.1 保存対象の選別と機微データ保護
Venkatesh： 終わりに、メモリを扱う際のベストプラクティスをお話しします。これが最後のスライドです。まず、規制当局と連携してください。そして、コンプライアンスチームと協力して、何をメモリに保存すべきかを見極めてください。もちろん、すべてを保存したいわけではありません。メモリは、何でもかんでも保存しておくためのトランザクション用データベースではないのです。そのためのデータストアは別にありますよね。
次に、機微データの保護とパージです。ここで重要なのは、戦略レベルを設定する際に、異なるユーザーをきちんと分離することです。ユーザーの情報が、チームやドメインをまたいで漏れてしまうことは避けたいのです。なぜなら、それぞれ異なるポリシーを持っている可能性があるからです。これは本当に注意しなければならない点です。
11.2 メモリポイズニング対策とスコープ対パフォーマンス
Venkatesh： そして、メモリポイズニングです。この会場で、メモリポイズニングをご存じの方がどれくらいいるか分かりませんが、これを使ってさまざまな悪さができてしまいます。とはいえ、もちろんBedrock Guardrailで防ぐことができます。これは朗報です。繰り返しになりますが、何でもかんでもメモリに保存してはいけません。これはトランザクション用のデータストアではないのです。そして、保存されている内容は常にレビューしてください。そうすれば、パージしたり、クリーンにしたり、TTLを適切に設定したりできます。TTLを正しく設定しておけば、自動的にパージしてくれます。
最後に、スコープとパフォーマンスの関係です。すべてを保存することが、効率的であることを意味するわけではありません。選択的であるべきです。関連性とスピードのために、要約（サマリゼーション）や統合（コンソリデーション）を行ってください。何でもかんでも保存しようとすれば、非効率に陥り、当然ながらコンテキストのオーバーフローという形でツケを払うことになります。それは避けたいですよね。
11.3 リソースとクロージング
Venkatesh： さて、これでリソースのセクションになります。スマートフォンをお持ちでしたら、ぜひこれを撮っておいてください。ただ、私が特に注目してほしいのはコードサンプルです。これが当初デモでやろうと計画していたものです。残念ながら、今日のネットワークが想定していたものと違ったために、実行できませんでした。皆さんの忍耐に心より感謝します。ちょうど時間どおりに終えられたと思います。ええ、ぴったり時間どおりですね。