7
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【Amazon Bedrock AgentCore】LT会に参加しました!

Last updated at Posted at 2025-08-28

はじめに

2025/8/26に弊社Works Human Intelligence主催の「Amazon Bedrock AgentCoreについて発表するLT会!」に参加しました。

私のAWSのレベル感としては、大学時代に制作していたWebアプリケーションを記事を見ながら一回デプロイした程度で、詳細なサービスについては勉強中です!目指せ12冠!!

発表内容

AIエージェント運用の課題を一気に解決する!Amazon Bedrock AgentCore 入門

発表者:井上 大貴さん

概要

現状のAIエージェント開発の課題として、5つ挙げています。

  • 柔軟なエージェントを運用するにはインフラの管理が必要
  • セッション管理や短期・長期メモリを保存するために Aurora や Dynamo の管理が必要
  • エージェントのトレースのために専用のツールを導入することが必要
  • エージェントの認証・認可の仕組みは自前で用意する
  • エージェントが使えるツール群を自前で用意する

これらを解決できるのがAmazon Bedrock AgentCoreであり、こちらのサービスの解説とできることについてまとめています。

Amazon Bedrock AgentCoreとは

一言でまとめると「AI エージェントの本番運用に必要不可欠な要素がすべて提供されたサービス」です。

あらゆるフレームワークとモデルを使用して、AI エージェントを大規模、迅速、安全にデプロイおよび運用するのに役立つ、包括的な一連のエンタープライズグレードのサービス

とAWSブログには記載があります。

以下の7つのサービスで構成されています。

  • AgentCore Runtime:エージェントを実行する基盤
  • AgentCore Memory:エージェントの記憶部分をつかさどる
  • AgentCore Gateway:エージェントが利用するツール機能を提供
  • AgentCore Browser:エージェントが利用するツール機能を提供
  • AgentCore Code Interpreter:エージェントが利用するツール機能を提供
  • AgentCore Identity:エージェントの認証・認可をサポート
  • AgentCore Observability:上記サービスを監視する

いずれもプレビューリリースかつ、東京リージョンでは利用不可です。(2025/8/26時点)

LTではそれぞれのサービスについてまとめていましたが、本記事では発表者の井上さんが推していた2つのサービスについてまとめます。

AgentCore Observability

エージェントの監視・トレースができるサービスのこと。

統合された運用ダッシュボードを通じて、本番環境におけるエージェントのパフォーマンスをトレース、デバッグ、監視する開発者を支援します。OpenTelemetry互換のテレメトリとエージェントワークフローの各ステップの詳細な可視化をサポートすることで、AgentCoreはエージェントの挙動を容易に可視化し、大規模な環境でも品質基準を維持できるようにします。

モデル呼び出しの各種メトリクス(CPU使用率やメモリ使用率などのシステム情報をグループ化したもの)をモニタリングすることが可能になっています。
それに加え、エージェントのトレース(システムの実行過程、データの流れ等を追跡・記録すること)も実現できます。

現状のAIエージェント開発の課題で述べられていたように、現状はLangSmithやLangfuseのような外部ツールを導入することでトレースを実現していました。
しかし、そのツール内で別途に権限管理を行う必要があり、運用が煩雑になりがちであると述べています。
しかし、このサービスによってトレースをAWS内で実現できることにより、IAMでの管理が可能になるため運用負荷が軽減されます!

AgentCore Identity

エージェントの代理アクセスを安全に管理する専用認証サービスのこと。

安全でスケーラブルなエージェントIDおよびアクセス管理機能を提供し、AIエージェント開発を加速します。既存のIDプロバイダーと互換性があるため、ユーザーの移行や認証フローの再構築は不要です。AgentCore Identityは、安全なトークンボールトによって同意取得の負担を最小限に抑え、合理化されたAIエージェントエクスペリエンスの構築を支援します。必要最低限のアクセスと安全な権限委任により、エージェントはAWSリソースやサードパーティのツールやサービスに安全にアクセスできるようになります。

現状、エージェントの認証・認可の仕組みは自前で用意していましたが、こちらのサービスによって

  • ユーザー ⇔ エージェント間のインバウンド認証
  • エージェント ⇔ 外部サービス間のアウトバウンド認証

がサポートされるようになりました。
Google、GitHub、Slack、Salesforceといったよく利用するサービス向けのプロバイダーも組み込まれているようです。

まとめ

AgentCore Runtime の登場によりあらゆるエージェントを実行できる基盤ができました。
ユーザーが用意していたサービスをAgentCoreで網羅できるのでコストや運用負荷を軽減できるようになりました。

Bedrock AgentCore Memoryでメモリオン vs メモリオフ

発表者:星 七花さん

概要

Bedrock AgentCore Memoryを利用し、長期メモリをオフにした場合とオンにした場合のエージェントの返答の比較を行っています。

Bedrock AgentCore Memoryとは

メモリを管理してくれるマネージドサービスのこと。

複雑なメモリインフラストラクチャ管理を排除しながら、AIエージェントが記憶する内容を完全に制御できるため、開発者がコンテキストアウェアエージェントを容易に構築できるようにします。Memoryは業界最高レベルの精度を提供するだけでなく、複数ターンの会話に対応する短期メモリと、エージェントやセッション間で共有できる長期メモリの両方をサポートします。

長期メモリの特徴

  • データの永続性:情報を抽出し、将来のために保存
  • 目的:過去の会話から情報を抽出し、エージェントの知識や振る舞いを強化
  • 戦略:ユーザー設定やセマンティックな事実、セッション要約など必要
  • 設定時間:ACTIVEになるまで2~3分かかる
  • 利用シナリオ:ユーザーの長期的な好み、ドメイン知識の維持、過去セッションの要約

メモリオン vs メモリオフ:検証内容

メモリオフにした状態でエージェントAに「好きな食べ物はハンバーグ」と教えます。
別のエージェントBに「私の好きな食べ物覚えてる?」と聞き、忘れていることを確認します。

一方、メモリをオンにして同じ手順を行った際、エージェントBが「ハンバーグ」と答えることを確認し、別エージェントと会話したことも覚えているということを検証します。

samplesを参考にJupyter Notebookで実行しています。
実際に発表者の星さんが作成されたJupyter Notebookはこちら

メモリオン vs メモリオフ:検証結果

メモリオフの場合、予測通り別エージェントと会話した内容は把握していませんでした。

「申し訳ありませんが、私はこれまでの会話を記憶していないので、あなたの好きな食べ物について以前お聞きしていたとしても覚えていません。」

メモリをオンにした場合、予測通り別エージェントと会話した内容を記憶していました。

「もちろん覚えていますよ。あなたの好きな食べ物はハンバーグでしたね。」

まとめ

  • Bedrock AgentCore Memoryとは
    • マネージドサービスなので、メモリインフラストラクチャの管理が不要
    • DBなどの管理がいらなくなるのでとても便利!
    • 短期メモリと長期メモリを提供
  • メモリオン
    • メモリIDが一緒であれば、エージェントが異なっていても記憶したものを返してくれる
  • メモリなし
    • セッションが切れてしまうと記憶も失われてしまう
    • エージェント単体でも、エージェント自体が同じ、かつ、同じセッションのものは、記憶は保持される

マルチテナントなAIエージェントを作ってみた

発表者:木谷 明人さん

概要

Amazon Bedrock AgentCoreでマルチテナントを実装し、データ漏洩のようなセキュリティ対策が実現できているかを検証しています。

マルチテナントSaaSアーキテクチャとは

マルチテナントSaaSアーキテクチャ=コントロールプレーン+アプリケーションプレーンと発表者の木谷さんは述べていました。

  • コントロールプレーン:SaaSを運用・管理するための仕組み
  • アプリケーションプレーン:ユーザーが利用するサービスのコアとなる機能

マルチテナントSaaSアーキテクチャを構築する上での注意点として、以下を述べていました。

  • クロステナントアクセス防止が重要
    • テナント分離
      • 他テナントのアクセスからテナントのリソースを保護する対策・実装が必要
    • データパーティショニング
      • データ特性に応じてテナントのデータを分割するストレージ戦略
    • テナントのルーティング
      • テナントの共有リソースと専用リソースを正しくつなぐ必要がある
  • 生成AIのリソース:プロンプト、ベクトルデータ、モデル、etc
    • テナント分離などの一般的マルチテナントの原則を適用可能

実装

  • AIエージェント:Strands Agent
  • データ:テナントごとのベクトルインデックスにロックンローラーの名前を格納
    • tenant1: teOzzy Osbourne
    • tenant2: Ronnie James Dio
  • テナント分離:テナント専用のデータのみアクセスできるIAMロール

検証

ベクトルインデックスのデータに応じた回答が返ってくることを確認する。

tenant1の場合

「Black SabbathのボーカルはOzzy Osbourneです。」

tenant2の場合

「Black SabbathのボーカルとしてRonnie James Dioが挙げられています。」

本当はtenant2が正しいため、tenant1からtenant2のデータにアクセスしようとする。

「アクセス権限の問題により、ベクター検索を実行できませんでした。」

これによってデータが漏洩していないことがわかった。

まとめ

  • S3 VectorsとBedrock AgentCoreを使ってマルチテナントなAIエージェントを作ってみた
  • 生成AI、AIエージェントでもクロステナントアクセスの防止は、通常のSaaSと同じ考え方でいけそう
    • テナント分離
    • データパーティショニング

LT会に参加した感想

難しかったです。というか、自分のレベル感にあってなかったなという印象です。
そもそも普段まだAWSを触れていない現状に加え、サービスがどのような役割を担っているかがすぐ理解できなかったので、耳から入ってきた情報を処理している間に新しい情報が入ってきて英語のリスニングをしている気分でした。
ただ、そんな中でもBedrockがどのようなサービスで、なにが嬉しいのかを知ることができるLT会でもあったと思います。
AWSの勉強を頑張ろうと思えました!!

7
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
7
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?