jawsug-tokyo bedrock night 2025_iida

Transcript

1. Amazon Bedrock Agentsの仕組み解説 ～Agentsの実装を少し覗いてみよう～ JAWS-UG東京 Bedrock Night 2025 ～AIエージェント祭り！～ 2025.02.14 裏側の
2. ※発表は個人の見解に基づくものであり、所属組織を代表するものではありません。 飯田 壮一 о所属：株式会社HBA о業務：AWS基盤構築、運用 о資格：AWS認定 × 14 о家族：妻、息子（4歳）、娘（1歳） о好きなAWSサービス：Amazon Bedrock 自己紹介
3. Agenda(本日押さえたいポイント) 1. Agentsの大まかな全体動作 2. プロンプトとParser Lambdaの実装を知る ※全てを紹介することはできません
4. Amazon Bedrock Agentsとは?(旧称:Agents for Amazon Bedrock) アプリケーションへ組み込み可能(※1)な「LLMベースのAIエージェント(※2)」を、 サーバレスかつフルマネージドで構築できる機能(追加料金なし) ※1:作成したエージェントはInvokeAgent APIでシンプルに呼び出せる ※2:環境を「知覚」する仕組みと「行動」をつなぐ「脳」として、LLMを使うAIエージェント https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2024_Amazon-Bedrock-Agents-b_1029_v1.pdf
5. 1. Agentsの大まかな全体動作
6. Amazon Bedrock Agents Session Store 前処理 後処理 入力 出力 オーケストレーション Prompt Store プロンプトテンプレートの管理 • 前処理用 • オーケストレーション用 • ナレッジベース回答生成用 • 後処理用 • 会話のサマリ用 会話のサマリを保持(Memory機 能) Agentsの全体動作 各フェーズで • プロンプト作成 • 基盤モデル呼び出し • Parser Lambda(※) の処理を順に実行 ※基盤モデルの出力を 解析してエージェント が処理できる形式に変 換するLambda関数
7. 前処理 「前処理」フェーズでは、ユーザの入力内容に対するチェックを行う 前処理 後処理 入力 出力 オーケストレーション 受付可能か? Yes No • ユーザから入力された内容を以下の観点でチェック - 倫理的に問題はないか - 悪意のある攻撃(プロンプトインジェクション等)でないか - エージェントが対応可能な範囲か • 受付不可の場合は「オーケストレーション」をスキップ
8. オーケストレーション 「オーケストレーション」フェーズは、自ら行動を計画してタスクを処理する 前処理 後処理 入力 出力 オーケストレーション 最終回答か? Yes No 「ReAct」の手法に基づき、 • ユーザーの要求を満たすために自ら行動を計画（Reasoning） • 計画に沿って行動（Acting） - API実行:Action Group - RAG:Knowledge Bases - コード生成:Code Interpreter • 行動結果を観察し計画と行動を繰り返して、最終回答を生成する （Observation）
9. 後処理 「後処理」フェーズは、最終的な回答内容を補正する 前処理 後処理 入力 出力 オーケストレーション 最終回答か? Yes No • 悪意や攻撃からの防御 - エージェントの内部ロジックが明らかになってしまう内容 があれば、補正する • これまでの会話履歴との整合性 - 過去の会話履歴を踏まえた回答内容にする
10. 2. プロンプトとParser Lambdaの実装を知る
11. Amazon Bedrock Agents Session Store 前処理 後処理 入力 出力 オーケストレーション Prompt Store プロンプトテンプレートの管理 • 前処理用 • オーケストレーション用 • ナレッジベース回答生成用 • 後処理用 • 会話のサマリ用 会話のサマリを保持(Memory機 能) 各フェーズで • プロンプト作成 • 基盤モデル呼び出し • Parser Lambda(※) の処理を順に実行 ※基盤モデルの出力を 解析してエージェント が処理できる形式に変 換するLambda関数 Agentsの全体動作 • この部分の実装を覗い てみる
12. プロンプトとParser Lambdaの実装を知るメリット • エージェントの細かな動作を理解でき、シンプルに解像度があがる • デバッグやトラブルシューティングが容易になる • プロンプト、Parser Lambdaともにオーバーライド可能(※)であり、独自のカスタマイズに挑 戦できる(逆に中身を知らないとエージェントのカスタマイズは難しい) ※Parser Lambdaのオーバーライドで指定できる関数は1つのみである点は注意
13. Parser Lambdaの実装を確認する Parser Lambdaの実装はAmazon Bedrockユーザガイドから確認できる https://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/lambda-parser.html
14. 前処理のParser Lambda • 前処理のParser Lambdaでは、基盤モデルの回 答から、受付可否とその根拠を判定しているこ とが分かる • この例では悪意のある攻撃(カテゴリB)とみな して受付不可で応答している
15. 前処理のParser Lambda • カテゴリが「D」「E」の場合は受付 可能、それ以外のカテゴリを受付不 可として返却 • <thinking>タグから根拠、 <category>タグからカテゴリを抽出 していることが分かるのでプロンプ トの実装を確認する
16. プロンプトの実装を確認する プロンプトの実装は管理コンソール(Orchestration strategy)から確認できる
17. 前処理のプロンプト • <category></category> に分類、 <thinking></thinking> に理由を出力す るよう誘導している • 分類のルールは細かく指示されていて、 入力内容をカテゴリA～Eに分類 - A:悪意のある、有害なもの - B:情報搾取など攻撃的なもの - C:エージェントが持つ機能では回答でき ないもの - D:エージェントが持つ機能で回答できる もの - E:エージェントからユーザに尋ねた質問 に対する回答
18. まとめ 1. Agentsの大まかな全体動作 2. プロンプトとParser Lambdaの実装を知る • 前処理、オーケストレーション、後処理の3つのフェーズがある • 各フェーズはプロンプト→基盤モデル→Parser Lambdaの順で処理する • プロンプトは管理コンソールから、Parser LambdaはAmazon Bedrockユーザガイド から実装を確認する • 実装を知ることで、エージェントに対する解像度があがり、開発しやすくなる
19. Thank you!!