20260722【JAWS-UG東京 ランチタイムLT会 #37④】AWS Well-Architectedフレームワークに沿った回答をするAIエージェントを作ってみた

Transcript

1. JAWS -UG 東京 ランチタイム LT会 #37 ④ AWS Well-Architectedフレームワークに沿った回答を するAIエージェントを作ってみた AWS Well -Architected AI エージェントをマルチエージェント 化した 話 Strands Agents を 使った Swarm パターンによる 自律協調型レビューの 構築 登壇者：野崎 高弘
2. 自己紹介 野崎 高弘（のざき たかひろ） ・仕事：前職まではインフラ構築・保守やSOCセキュリティアナリスト 現在は技術検証が主のクラウドインフラエンジニア ・趣味：資格取得、犬の散歩、ドラマ鑑賞、巨人ファン ・資格：現在AWS・GCP全冠、その他100種以上保持の資格オタク ・2024年3月『AWS認定 高度なネットワーキング-専門知識（ANS-C01）完 全対応テキスト』（リックテレコム）部分執筆（2章、巻末模擬問題担当） ・主な受賞歴 2023 Japan AWS All Certifications Engineers 2024 Japan AWS All Certifications Engineers 2024 Japan AWS Top Engineers(Networking) Google Cloud Partner All Certification Holders 2025 JAWS-UG東京 ランチタイムLT会 #37 01
3. 背景・目的・やりたいこと AWSシステムで課題やそれに対する解決策を考える上で、以下のような疑問が湧 くことはないでしょうか？ ・現状がAWS Well-Architectedフレームワーク（以下、W-A）のあるべき姿からど のくらいずれているかを知りたい ・この方法ってW-Aにどのくらい整合してるんだろうかレビューしてもらいたい ・あるAWS認定試験問題に対して、W-A準拠の理想的な解答が知りたい ・W-Aのゲームデーで理想的な方法を発表してみたい ・AWSソリューションアーキテクトとして、お客様にW-Aのベストプラクティスに沿っ た提案をしてみたい そこで、あらかじめW-A専用の回答をする仕組みを作り込んでおくAIエージェント を作成し、そのエージェントに様々な疑問をぶつけてどのくらいW-A寄りの回答を してくれるか試してみました！ JAWS-UG東京 ランチタイムLT会 #37 03
4. 類似ツールとの差別化 WAFRアクセラレーター BedrockをはじめとするAWSサービスを通じて生成型AIの機能を活用することで、複雑なアーキテク チャドキュメントの分析を自動化し、W-Aの柱に照らし合わせて評価を行い、詳細な評価結果と推奨 事項を提供します。 多数のリソースを作成するため、初回デプロイに15〜30分程度かかります。 AWS Well-Architected IaC Analyzer AWSが提供する生成AIベースのコードレビューツールで、CloudFormation・CDK・Terraform などの IaCテンプレートが、W-Aに準拠しているかを自動評価してくれる仕組みです。 IaCに特化しており、コードレビュー限定 AWS Well-Architected Security Assessment Tool MCP Server W-Aのセキュリティの柱に沿ってAWS環境を監視・評価するための運用ツールを提供するMCPサー バーで、セキュリティ限定であるし、セキュリティに関する情報をAIに与えるので、最小権限に基づい た適切なプロファイルを付与する必要がある。 上記いずれの方法も、気軽にサクッと試すには敷居が高く、重い腰を上げなければなりません。 その点私が作ったエージェントはサクッと1分で試せます。腰を上げて大掛かりなシステムを構築する 必要はありません。 JAWS-UG東京 ランチタイムLT会 #37 03
5. 概要図 JAWS-UG東京 ランチタイムLT会 #37 04
6. 自律システムを支えるコアコンポーネント Strands Agents Claude 4.6 Sonnet LLMに依存せず、軽 量で高度なエージェ ントオーケストレー ション（自律ハンド オフ機能）を実現す るフレームワーク 仕分けルーターには 超高速なHaiku 4.5 、各柱の深掘りレビ ューには圧倒的推論 力を持つSonnet 4.6 を適材適所で配備 JAWS-UG東京 ランチタイムLT会 #37 AWS MCP MCPに基づき、AWS公 式ドキュメント （docs.aws.amazon.co m）とエージェントを 安全に双方向ストリー ム接続 05
7. マルチエージェントパターンの比較 Agents as Tools 制御 方式 実行 順序 並列 実行 Workflow Swarm（今回採用） ルーターLLMがツー コード側で順序・依存関 ル呼び出しで委任 係を完全に定義 LLMが決める（非決 dependenciesで固定 定的） （決定的） エージェント同士が自律 的にハンドオフ LLMが決める（非決定的） ルーターが順番に or並列に呼ぶ 依存がないタスクは自 動で並列 不可（1つずつバトンを渡 す） 全柱を必ず通すレ ビュー 質問が多様で、どの柱が 関係するか予測できない 場合 向いて シンプルな委任構 る用途 造 Swarmを選んだ理由は、「セキュリティだけ教えて」のような単一柱の質問にも、 「全体レビューして」のような全柱レビューにも柔軟に対応できるから JAWS-UG東京 ランチタイムLT会 #37 04
8. Swarmパターンとは Strands Agentsのマルチエージェントパターンの1つであるSwarmは、エージェント同士が自律的 にハンドオフ（バトンパス）する仕組み swarm = Swarm( nodes=[router_agent, security_agent, cost_agent, ...], entry_point=router_agent, max_handoffs=6, max_iterations=12, execution_timeout=300.0, node_timeout=120.0, repetitive_handoff_detection_window=4, repetitive_handoff_min_unique_agents=3, ) ルーターがユーザーの質問を分析し、関連する柱の専門エージェントに自律的にハンドオフします。 「セキュリティだけ教えて」ならSecurityExpertだけが動き、「全体的にレビューして」なら複数の専門 家が順番に動きます。 JAWS-UG東京 ランチタイムLT会 #37 04
9. マルチエージェント：Swarmパターン [ユーザーの質問] ⇩ WARouter（ルーター）が質問 [WARouter（総合窓口/軽量・高速] ── 適切な専門家へ │ハンドオフ を適切に仕分け、W-Aの6つの ├─➔ [SecurityExpert] ← security_skill.md ├─➔ [CostExpert] ← cost_optimi_skill.md 柱に配置した各専門エージェ ├─➔ [ReliabilityExpert] ← reliability_skill.md ントへ自律的にハンドオフ（ ├─➔ [PerformanceExpert] ← perf_effici_skill.md ├─➔ [OpsExpert] ← operational_excelle_skill.md バトンパス） └─➔ [SustainabilExpert] ← sustainabil_skill.md ⇩ 各エージェントは、必要なタイミ 各専門エージェントが必要時のみ公式ドキュメントをMCP検 ングでのみ AWS 索 ⇩ Documentation MCP を介して レビュー結果を出力 総合窓口と 6つの専門チーム 最新の公式ドキュメントを検索 JAWS-UG東京 ランチタイムLT会 #37 04
10. 設計思想：Skills分割 柱ごとに完全に独立したSkillsで定義 `security_skill.md`, `cost_optiion_skill.md` などの構成 例）セキュリティSkills の中身 # セキュリティ（Security / SEC） あなたはAWS Well-Architectedの「セキュリティ」を評価する専門 家です。 不変の「設計原則」等はスキルに持 たせる 公式のコア原則やベストプラクティ ス構造をスキルに直書きして定義 ## 設計原則 1. **強力なアイデンティティ基盤を実装する**: 最小特権の原則を 実装し... 2. **トレーサビリティの維持**: リアルタイムでモニタリング... （以下、公式の7原則をすべて記載） 可変の「詳細情報」はオンデマンド 取得 普遍思想はスキルで自己解決、最新 の深いドキュメントのみMCPで検索 ## ベストプラクティス（SECプレフィックス） - SEC 1: ワークロードを安全に運用するにはどうすればよいです か？ - SEC 2: 人間の ID をどのように管理しますか？ （以下、SEC 12まで） ## 情報ソースの優先順位 1. まず上記の設計原則・ベストプラクティスの知識で回答する （MCP不要） 2. より詳細なBPページの内容が必要な場合のみ MCP を使用する JAWS-UG東京 ランチタイムLT会 #37 06
11. 設計思想：具体的な回答形式の指定 例）セキュリティSkillsの中身 ## 出力スタイル - 見出し、箇条書き、リンクを活用して読みやすくすること - 関連する柱の名前がある場合は明示すること - 検索結果で見つかったページにさらに詳細なサブページがある場合は、 read_documentationツールを使って深い階層のページも必ず読むこと - 柱のトップページだけでなく、個別のベストプラクティスページ（SECXX-BPXX 形式のIDを持つページ）まで掘り下げ、該当するベストプラクティスのID（例: SEC01-BP01 等）を特定し、回答に含めること - リスクの緊急度を「高・中・低」で分類すること JAWS-UG東京 ランチタイムLT会 #37 06
12. システムの高速化・最適化アプローチ 1. ルーターLLMの軽量化（Haiku 4.5） - 「どの専門家に振るか」の判断に重厚な推論モデルは不要。軽量・高速化を徹底 2. プロンプトキャッシュの自動有効化 - `CacheConfig(strategy='auto')` を実装 - 分割したスキルファイルやツール定義を2回目以降キャッシュし 、オーバーヘッドを最小化 3. MCPの「必要時のみ」利用による劇的な速度改善 - 当初は「必ず検索」としていた指示を「スキル知識で足りない場合のみ検 索」に変更 - 通信回数とトークンが絞り込まれ、応答速度が向上 JAWS-UG東京 ランチタイムLT会 #37 07
13. ユースケース検証：SAP-C02試験のサンプル問題 AWS Certified Solutions Architect - Professional (SAP-C02) 試験問題サンプルからの抜粋 【お題：サードパーティ製モニタリングツールの統合要件】 2）ある企業は、AWS Organizations 内の組織に複数の AWS アカウントを持っています。 同社は オンプレミスの Active Directory と AWS Single Sign-On (AWS SSO) を統合し、すべて のアカウントの インフラストラクチャを管理するための最小権限のアクセス許可を Active Directory ユーザーに 付与しています。 ソリューションアーキテクトは、すべての AWS アカウントでの読み取り専用アクセスを必要とす る、 サードパーティーのモニタリングソリューションを統合しなければなりません。 モニタリングソリューションは独自の AWS アカウントで実行されます。 モニタリングソリューショ ンに必要なアクセス許可を与えるために、ソリューションアーキテクトは何をすべきですか。 ── このプロフェッショナル試験レベルの要件を、作成したマルチエージェントに投入 JAWS-UG東京 ランチタイムLT会 #37 。 09
14. 検証結果：エージェントが自律生成した解決策 専門エージェント群が導き出した回答 選択肢なしでベストアンサー 「各AWSアカウントにクロスアカウント IAM ロールを作 成し、AWS CloudFormation StackSets を使用して Organizations 全体に自動展開する。 各 IAM ロールの信頼ポリシーには、サードパーティー のアカウント ID とsts:ExternalId 条件を設定する。」 StackSets を 用いたロール 展開 （→OPS05 -BP03 ） ＋ 信頼ポリシ ー ＋ sts:ExternalId （→SEC01 -BP03 ） の構成を 、 W -A原則の解説を 添え てピンポイントで 提示！ 実際の「正解の選択肢」 D) サードパーティーのモニタリングソリューションの新し い IAM ロールを定義する AWS CloudFormation テン プレートを作成する。信頼ポリシーで、サードパーティー のモニタリングソリューションの AWS アカウントを指定 する。スタックセットを使用して、 リンクされたすべての AWS アカウントで IAM ロールを作成する。 JAWS-UG東京 ランチタイムLT会 #37 10
15. 現状の課題 とはいえ、自律性とパフォーマンスにおける課題も…Swarm型の限界 • 1. Swarmの「非決定性」が根本的には未解決 - ルーティングやハンドオフの判定はLLMの自律判断に依存するため、全く同じ質 問でも毎回結果が微妙に変わる可能性が残る - descriptionやスキルファイル内の指示を細かくチューニングして精度を向上させ てきたが、これは対症療法であり、原理的な完全保証にはならない • 2. 処理時間はまだ長め（複数ノード跨ぎ時の蓄積） - 複数の柱にハンドオフされる広範な質問では、1エージェントあたり数十秒〜1分 の処理時間がホップ数分積み重なってしまう - `execution_timeout`（現在300秒）に達すると、処理が途中で強制終了され、 途中結果までしか返らないリスクがある JAWS-UG東京 ランチタイムLT会 #37 12
16. まとめと今後の展望 不変の「原則（スキル）」と、動的な「詳細（MCP）」のハイブリッド W-Aの「6つの柱」を独立したスキルファイルに切り離し、ルーターで制 御するSwarm構成は、精度と速度のバランスが良く機能的です。変わらない 思想はスキルで、最新の詳細BPはMCP経由で補完することで、極めてス マートかつ高精度な設計レビューが可能に • 設計の良き伴走者： 「インフラ構成を入力したら、W-Aの観点でレビューが 返ってくる」ツールが手元にあると、設計レビューの初手として非常に便利 • Workflowパターンのハイブリッド追加： 100%全柱のチェックを必須とするレ ビュー • 社内独自基準の追加： Bedrock Knowledge BasesとMCPを接続したレビュー 基準自動判定 JAWS-UG東京 ランチタイムLT会 #37 12
17. ブログ参照 • AWS Well-Architectedフレームワークに沿った回答をするAIエージェン トを作ってみた（シングルエージェント版） https://nozakitakahirokun.hatenablog.com/entry/2026/07/09/123216 •AWS Well-Architected AIエージェントをマルチエージェント化した（Strands Agents Swarmパターン） https://nozakitakahirokun.hatenablog.com/entry/2026/07/15/155339 JAWS-UG東京 ランチタイムLT会 #37 12
18. ご 清聴ありがとうございました ★ご 質問・ 感想などございましたらお 気軽にお 寄せください ！★ JAWS -UG 東京 ランチタイム LT会 #37