re:Invent 2025: Agentic AIによるAWSパッチ自動化システムPatchyの構築とマルチエージェント実装
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Building custom agents for intelligent AWS patch automation (COP407)
この動画では、Log4Jのような重大なCVE発生時の混乱した対応を改善するため、Agentic AIを活用したインテリジェントなパッチ自動化システム「Patchy」の構築事例が紹介されています。Strandsを使用したマルチエージェントパターンで、supervisorと3つのspecialist agents（Vulnerability Analyst、Patch Manager、Compliance Analyst）を実装し、Amazon Bedrock Agent Coreにデプロイしています。数秒で脆弱性の特定、SLA要件の確認、パッチ適用判断を自動化し、段階的ロールアウトとヘルスチェックも実行します。プロンプトエンジニアリングの実践的なヒント、tool decoratorの活用、システムプロンプトでのスコープ制御など、具体的な実装方法とコードが詳細に解説されています。小さく始めてテストと反復を重ねる重要性が強調されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
Log4Jイベントから学ぶ：カオスな緊急対応の現実
素晴らしい皆さん。まず最初に言いたいのは、Justin と私は想像できる通りかなり緊張していたんですが、皆さんがこんなに早く、セッション開始の15分前に来てくれているのを見ると、本当に心強いです。だから本当に、こんなに早く来てくれてありがとうございます。そして、皆さんが私たちに投資してくれた時間に見合う内容をお届けできればと思っています。
それでは、手を挙げてもらってもいいでしょうか。数年前に起きた Log4J イベントを経験した人はいますか？素晴らしい。半分の人ですね。素晴らしい。インシデント対応の最前線にいて、CISO や CIO、CTO に対して exposure や blast radius について答えなければならなかった人はいますか？最前線にいた人はいますか？何人か手が上がっているのが見えます。その経験はどうでしたか？冗談で言ってますが、わかりますよね？本当にカオスでした。絶対に狂気の沙汰でした。本当に大変でしたよね？そして、それが今日私たちが話したいことなんです。Agentic AI がどのように皆さんと皆さんの組織を、Log4J イベントのような状況に対してより良く準備させることができるのか、ということです。
皆さん、私は Praveen Bhatt です。Principal Solutions Architect で、Down Under、つまりオーストラリアからやってきました。そして今日は Justin Thomas と一緒にいます。私は Senior Cloud Support Engineer で、毎日顧客と一緒に cloud operations に関する仕事をしています。Praveen が先ほど言及した Log4J イベントについては、私は最前線にいて、多くの顧客、本当に多くの顧客を同時にサポートしていました。私が目撃したのはカオスでした。大規模な organized chaos でした。ある顧客との通話で exposure を見つけるのを手伝っていると、突然5人以上の顧客が同じ問題と同じ質問を持ってやってくるのが見えるんです。
では、同じような経験の例を見てみましょう。これは架空の会社、Manual Everything Corp です。金曜日の午後だと想像してください。チームは週を終わらせる準備ができていて、突然重大な CVE が発表されて、今や数千のインスタンスにパッチを当てる必要があります。そこで緊急のブリッジコールがスケジュールされます。Security Director がコールに参加します。
皆さん、私たちは exposure を受けているのか、いないのか？exposure はあるのか？blast radius はどのくらいなのか？最初の数分間、誰も答えません。沈黙です。Platform チームはまだコールに参加していません。しばらく経って、platform チームをページングした後、platform engineer がコールに参加して言います。まだそれを把握しようとしているところです。インスタンスにログインする必要があります。アカウントにログインする必要があります。今、どのくらいのインスタンスが non-compliant なのかを確認する必要があります。
このパッチがリリースされたばかりなので、本番環境へのデプロイを開始する前にテストする必要があります。IT Compliance Manager が割り込んできて、今は緊急パッチを行っているのか、それともパッチメンテナンスウィンドウまで待つことができるのかと聞きます。
会社の CTO がこの会話をずっと聞いています。意思決定に必要な正しいデータを探すのが宝探しのようになっているので、イライラしています。CTO は、より良い自動化とより良いインテリジェンスが必要であることを認めています。この会話は、私が常に目にするものです。緊急ブリッジコールの最初の 30 分から 1 時間は、ただ待っているだけです。適切な人たちがコールに参加するのを待っています。そして適切な人たちがコールに参加すると、同じ質問が出てきます。どのインスタンスが影響を受けているのか？パッチはいつ行うのか？ダウンタイムが必要か？
この単一の評価、この会話は 1 つの CVE のためのもので、これは数時間かかります。では、1 ヶ月に複数の CVE でこれを行うことを想像してください。チームはそれをスケールして対応することはできません。では、エンジニアと一緒に働くインテリジェント エージェントを追加して、これらの脆弱性を特定・評価し、コンプライアンス要件を確認し、さらに修復も行うことができたらどうでしょうか？チームは制御を保ったまま、これらのエージェントによって重い作業をすべて行ってもらうことができます。
インテリジェント パッチ自動化：マルチエージェントパターンとStrandsの活用
今日お見せしたいのは、私たちが構築したインテリジェント エージェントです。デモに移ることができます。私たちが用意したデモセットアップは、エンタープライズセットアップとかなり似ています。3 つの異なる環境があります。development、staging、production です。各環境には異なるパッチスケジュールと異なるパッチコンプライアンス要件があります。既存のサービスは既に設定されています。Amazon Inspector、AWS Systems Manager、AWS Config です。これらは脆弱性を検出し、修復しているサービスです。不足しているのは、重大な CVE がリリースされたときに道を示すインテリジェント オーケストレーターです。ここが、私たちのインテリジェント パッチ自動化を追加する場所です。
これはマルチエージェントパターンです。スーパーバイザーと3つのスペシャリストエージェントという4つのエージェントを作成します。これらのエージェントは Strands を使って構築されています。Strands はオープンソースの SDK で、わずか数行のコードでエージェントを簡単に構築・実行できるようにしてくれます。これが提供するのはモデル駆動型のアプローチで、つまり LLM に自分自身で考えさせ、自律的に思考して判断を下し、結果に到達させるということです。これは Amazon Bedrock Agent Core を使ってデモアカウントにデプロイされています。Agent Core はエージェンティック AI プラットフォームで、AI エージェントを大規模かつ安全にデプロイして運用することを簡単にしてくれます。
Patchyの実演：環境分析から緊急パッチ判断まで
では、ターミナルに切り替えて、私たちが構築したインテリジェントなパッチ自動化が実際に動作しているのを見てみましょう。フォント、特に後ろの方は見えていますか？素晴らしい、ありがとうございます。私たちが構築したエージェンティックシステムを Patchy と呼んでいます。スペシャリストエージェントにアクセスできるのが見えますね。実際に見えているのは、エージェントと対話するために構築したシンプルなチャットクライアントです。当然、本番環境ではちゃんとした Web アプリを構築することになりますし、Jira や ServiceNow のような内部チェンジシステムと統合することもできます。ただここでは、エージェントとどのように対話できるかをシンプルに示したいだけです。
チャットクライアントはかなりシンプルに見えます。ですから、クリティカルなイベント中の最初のステップは、環境を理解し、アカウントで何が実行されているかを理解することです。プラットフォームエンジニアがコンソールにログインして本番インスタンスと本番環境がどのような状態かを確認するのに時間がかかっている間でも、環境に何があるかをサマライズするようにエージェントに依頼することができます。また、それらの本番インスタンスのコンプライアンス要件に関する情報も提供するよう依頼するつもりです。
私たちがやっているのは、先ほど見たスーパーバイザーエージェントと対話することで、必要な API コールを実行させています。EC2 タグを読み込み、AWS Config サービスをクエリしています。数秒以内に、本番環境の完全な全体像が得られます。インスタンスの詳細と本番環境の設定情報が得られますが、最も重要なのは、各インスタンスのコンプライアンスフレームワークが見えることで、これは意思決定を下すのに役立つ情報です。
Manual Everything Corp. をご覧ください。この情報は、スプレッドシート、Excel シート、データベースツールに分散していますが、ここではたった1つのプロンプトでそれを取得できました。覚えていますか？セキュリティディレクターが最初に質問したことは何だったか。それは、私たちは露出しているのか、私たちの露出状況はどうなのかということでした。では、エージェントに本番環境に脆弱性があるかどうかを調べるよう依頼してみましょう。
今回は、スペシャリストエージェント、特に Vulnerability Analyst エージェントが supervisor に相談し、そのエージェントは Amazon Inspector をクエリしてこれらの検出結果を取得するように構築されています。セキュリティエンジニアであれば、AWS コンソールに手動でログインして、検出結果をダウンロードして、CVE の詳細を確認して、それらの CVE に対してパッチが利用可能かどうかを検証することになります。
その後、すべてをダウンロードして優先度リストを取得することになり、それは数時間の作業を表しています。数秒以内に、正確には 37.6 秒で、すべての結果が表示されます。 エージェントは、本番環境に 50 個の高重大度の脆弱性があることをまとめ、また CVSS スコアに基づいて最も重大なものがどれであるかをまとめています。 これらの脆弱性の影響を受けるインスタンスがどれであるか、また CVE にパッチを当てない場合にリスクにさらされるコンプライアンスフレームワークがどれであるかを特定しています。 ここで、IT コンプライアンスマネージャーから質問された興味深い質問が出てきます。パッチを当てるのに適切な時期はいつなのか。会社からの SLA 要件とパッチ管理ウィンドウがあります。パッチを当てるタイミングについてどのように判断するのでしょうか。
エージェントに来てもらって、パッチを当てるのに適切な時期はいつなのかを教えてもらいましょう。 重大度を指定していないこと、脆弱性を指定していないことに注意してください。単にいつパッチを当てるべきかを聞いているだけです。これは Agent Core を使用しているためです。Agent Core メモリを使用しています。 これは私たちが行ったすべての会話履歴を記憶しています。つまり、これはコンテキスト認識エージェントであり、アーキテクチャを見たら一度それについて説明します。今回は、エージェントが Patch Manager エージェントに相談しており、それはスペシャリストエージェントであり、パッチ管理ウィンドウが何であるか、SLA が何であるかを確認して、判断を下します。 パッチ適用の判断が必要です。次のウィンドウまで 24 日です。つまり、メンテナンスウィンドウは今日から 24 日後です。脆letalityの状態は最初は何らかの理由で SLA データが利用不可と表示されています。実際にもう一度確認してみましょう。
Patch Manager エージェントがコードを見て、バックエンドでは、このエージェントに SLA 要件を計算できるツールへのアクセスを与えます。いつパッチを当てるべきかを聞くと、実際にそれぞれの重大度に対する SLA ポリシーが何かをチェックして、メンテナンスウィンドウとの差分を確認します。 では、こういうことになります。緊急パッチが必要だと言っています。SLA 違反があります。必ず期限があります。なぜなら、あなたのインスタンスには PCI-DSS 要件があるので、48 時間以内にパッチを当てる必要があります。しかし、メンテナンスウィンドウは 24 日先です。つまり、リスクがあります。推奨事項は、48 時間以内に即座にパッチを当てることです。エージェントは SLA 違反を避けるのを助けてくれました。 そして、今すぐパッチを当てる必要があるという明確な推奨事項を提供しました。
段階的パッチ適用とSLAコンプライアンス履歴の追跡
ここまでで、どのインスタンスが影響を受けているか、どの脆弱性があるかを特定し、今パッチを当てる必要があるという決定に至りました。では、エージェントにパッチを当てるよう依頼しましょう。ただし、まず Dev から始めたいです。本番環境については今チェックしましたが、dev から始めて、その次に staging、そして本番環境へと進む必要があります。では、こう聞きます。OK、Dev インスタンスに緊急パッチを適用してください。今回も、Patch Manager エージェントが登場します。これは、すべての Systems Manager API コールを実行するために構築されています。パッチマネージャーでデプロイして実行コマンドを実行する場合、AWS Run Patch Baseline ドキュメントを使用します。 実際に、どの環境にパッチを当てるべきかを明確にするよう求めてきました。OK では、dev 環境にパッチを当てましょう。はい。バックエンドでは、実行コマンド ID を生成し、その 5 つの dev インスタンスをターゲットにして、その環境用の AWS パッチベースラインドキュメントを使用します。
大規模言語モデルの賢さに気づくのは非常に興味深いことだと思います。ずっと本番環境について議論していたのに、突然 dev 環境に切り替えたいと言っているのを理解して、実際に確認を取ろうとしています。 多くの場合、これは本当に起こりません。大規模言語モデルが持つメモリとコンテキストが多いほど、 あなたの組織とプロセスについて認識が高いほど、このようなことでより良くなります。
コマンド ID が生成されて、現在のステータスは pending です。5 つのインスタンスがターゲットになっています。エージェントが提供する次のステップがあります。 ステータスを確認できます。また、「proceed」と入力して staging 環境への進行を続けることもできます。基本的に、エージェントはこれが段階的なロールアウトであることを理解しています。dev から始めて、それが staging、その後本番環境というようになることを指定しませんでしたが、「proceed」と入力すると、次に staging 環境へのパッチが開始されることを理解しています。または、待機して、すべてが問題ないことを確認してから進めることもできます。
SLA 違反を避けて、緊急パッチを実施しました。しかし、その SLA ミスをキャッチできなかった場合はどうでしょうか。それが今、Manual Everything Corporation の CTO が考えていることです。チームがデータの宝探しをしていたせいで、何回非準拠だったのでしょうか。これは監査人も聞くことになります。あなたのコンプライアンス履歴は何ですか。Manual Everything Corporation には、この情報を取得するツールがありません。
では、エージェントに SLA を逃した回数を確認するよう依頼してみましょう。今回は、最後のスペシャリスト エージェントである compliance analyst agent が supervisor agent に相談されます。このエージェントが行うことは、S3 バケットからレポートを取得してから計算を実行することです。脆弱性がいつリリースされたか、パッチ適用をいつ行ったか、そして SLA ポリシーも確認します。 SLA ポリシーを確認して、パッチ適用を何回行ったか、つまり SLA のタイムライン内に完了すべきだったかを確認します。 過去 30 日間に合計 6 件のブリーチがあったこと、そしてどの CVE がブリーチされたか、どのチームが影響を受けたかなどのブリーチの詳細を提供します。
では、アーキテクチャと、スコアをどのように構築したか、そしてこれを構築する際に採用した決定原則について探ってみましょう。このために、Praveen にバトンを渡します。コードに入る際に強調したいことがいくつかあります。patch manager agent 自体は、パッチ適用プロセスの一部として検証とヘルスチェックを実行する能力を持っています。時間の都合上これを行うことができる理由ですが、内部的には基本的にアプリケーションとインフラストラクチャをチェックしています。実際にどのように行われるかについては、詳しく説明します。 パッチ適用が完了すると、すべての情報を S3 バケットにアップロードします。
Supervisorパターンとアーキテクチャ：AWS サービスとの統合
ソリューションが実際に動作しているのを見たので、ここからはソリューションを駆動する基盤となるアーキテクチャとコードを見てみましょう。すでにお気づきかもしれませんが、複数のエージェントが関わっています。これは supervisor pattern と呼ばれるパターンに基づいています。 このパターンでは、supervisor agent がワークフロー全体のエンドツーエンドのオーケストレーションを管理し、スペシャライズされたエージェントと相談して調整します。各スペシャライズされたエージェントは、特定の役割、一連の指示、そして与えられたタスクを完了するために使用できるツールのセットを持っています。
エージェント自体は、ユーザーの意図を理解したり推論したりする能力を持っていません。その意図のために、Amazon Bedrock 上で実行される Claude 4.5 という大規模言語モデルがあり、それが脳力を提供します。 すべてのその脳力があっても、エージェントは AWS サービスと相互作用できる必要があります。 そのために、スペシャライズされたエージェントに公開されるスペシャライズされたツールがあります。関わっている AWS サービスという点では、脆弱性の検出結果を得るための Amazon Inspector と、エージェントにインフラストラクチャの理解を与える AWS Config があります。
AWS Config はエージェントにリソースの依存関係の理解を提供します。patch manager agent がパッチ適用の決定を下すとき、パッチ適用操作全体に影響を与える可能性のあるビジネスの重要度を理解しています。Web アプリケーション、エンドユーザーに向かったフロントエンド アプリケーションで、ビジネスへの影響が非常に高い場合、パッチを適用したくありません。そのすべての決定が patch manager agent によって考慮されます。あなたの場合、これは ServiceNow や Jira のような CMDB のようなものかもしれませんが、リソースの依存関係ビューを提供できるものであれば何でも、大規模言語モデルがその情報を吸収して意思決定プロセスで利用可能にします。
Systems Manager を使うことで、パッチのコンプライアンス状態を把握し、パッチを適用することができます。コンプライアンスレポートの保存と取得には S3 を使用し、最終的にパッチの適用自体には EC2 を使用しています。
Justin が言及したように、Strands SDK を使用しています。Strands が重要である理由として、特に強調したい点が1つあります。Strands を使うと、ユーザーが大規模言語モデルとツールと継続的にやり取りできるエージェントを非常に簡単に構築できるということです。これは agentic loop と呼ばれるものです。
どういうことかというと、ユーザーが「dev 環境のインスタンスにパッチを当ててほしい」というリクエストを出すシナリオを考えてみてください。エージェントは最初はそれを理解していないので、意図を理解する必要があります。このリクエストは大規模言語モデルにルーティングされます。モデルは「わかりました、意図は理解しましたが、AWS サービスと連携できるツールへのアクセスが必要です」と言います。そこでリクエストはツールにルーティングされ、ツールは関連するサービスと通信し、レスポンスを返してきます。そのレスポンスは大規模言語モデルにフィードバックされます。モデルはそれを推論して、ユーザーの元のリクエストが完了するまで、このプロセスが繰り返されます。これらすべてが agentic loop と呼ばれるもの内で起こります。コードを書く必要はなく、単に利用可能になっているだけです。実際のコードに進むときに、その様子をお見せします。
スケールとセキュリティの観点から、Bedrock AgentCore にこれをデプロイするのは非常に簡単でした。AgentCore には6～7個のプリミティブが付属していますが、私たちはそのうち3つだけを使用しています。エージェントをホストして実行するための Runtime、エージェントをコンテキスト認識にするための Memory、そして最後に、トレーシング、メトリクス、ログを使用してエージェントの状態を理解できるようにするための Observability です。これらはすべて、問題をデバッグしようとしているときや、プロンプトを反復・評価しようとしているときや、大規模言語モデルのパラメータに変更を加えているときに非常に役立ちます。この Observability により、その情報を非常に簡単に取得できるようになります。
最初のイテレーション：シンプルなEC2エージェントの構築
Justin と私が4ヶ月前にこのアイデアを思いついた時、最初からこのようなアーキテクチャ全体を想定していたわけではありませんでした。非常にシンプルで基本的なものから始めて、大規模言語モデルの機能を理解し、エンタープライズユーザーがこの機能で何を望んでいるのかを理解したいと考えていました。ですから、かなり小さい規模から始めて、その後も何度も何度も反復していきました。顧客からのフィードバックを得て、また反復し、また反復し、という具合です。これからの30分間で、私たちがどのように非常にシンプルなものから始めて、どのように反復していき、今日の Patchy の段階に到達したのかを、加速度的な体験として皆さんにお見せします。うまくいけば、私たちが従ったヒントと実践、そしてアーキテクチャパターンを活用して、皆さんとチームが大規模なイベントをより快適に処理できる段階に到達できるようになるでしょう。
最初に私たちが始めたのは、すべての EC2 インスタンスをリストアップして、コンプライアンス状態を取得できるという非常にシンプルな EC2 エージェントでした。 まず、いくつかのメインクラスをインポートすることから始めます。Agent クラスがメインクラスです。これは大規模言語モデルへのコア インターフェースであり、会話管理などのためのものです。これが最も重要なクラスです。その次に、エージェントが AWS サービスと相互作用できるようにするには、ツールが必要です。 Strands には use_aws という組み込みツールがあり、Strands ライブラリで利用できます。 エージェントを定義し始めます。名前から始めます。エージェントは独自のアイデンティティを持っています。
次に、システムプロンプトを与えます。 システムプロンプトは、エージェントに持たせたいロール、ペルソナ、特性、そして指示を指定する場所です。私たちの場合、非常にシンプルに保ちます。あなたは EC2 アシスタントです。それだけです。そして最後に、ツールを忘れないでください。 AWS を使用します。これはエージェントが AWS サービスと相互作用できるようにするツールです。それだけです。Strands 内の6、7行のコードで、エージェントがアカウント内の EC2 サービスと相互作用し、EC2 インスタンスのリストを取得し、Systems Manager と相互作用してコンプライアンス日付を取得できるようになります。それだけです。
では、すぐに始めます。US East One のすべての EC2 インスタンスとそのコンプライアンス状態をリストアップしてほしいと言います。それだけです。これを実行します。 よし、Python です。 タイプミスをしていないといいのですが。そうですね。一番上に表示されているのは「すべての EC2 インスタンスをリストアップするのをお手伝いします」です。これは大規模言語モデルが実際にユーザーの意図を理解しており、いくつかのことをする必要があることを認識しています。EC2 インスタンスを取得してから、コンプライアンス日付を取得します。その後、ツール呼び出しと返ってくる応答が表示されます。 意図は大規模言語モデルによって推論され、ずっと続きます。ですから、複数のツール呼び出しが発生するのが見えます。 そして、最終的な応答が出てきます。これは、ここにすべての本番インスタンスと、それらが非準拠か準拠かどうか、そして他の多くの情報があります。おそらく必要のない情報です。 とにかく、これはただの基本的なエージェントですね。強調したいのは、エージェンティックループです。 大規模言語モデルがツールを呼び出し、応答を得ました。ここで見えるように、ハイライターが機能しているかどうかわかりませんが、無効なパラメータ値の例外です。大規模言語モデルが自動修正できる段階に到達しました。 従ったシンタックスが間違っていることを認識し、ナレッジベースに戻り、正しいシンタックスが何であるかを認識し、再度送信します。そしておそらく AWS Config を試します。ほら。コンプライアンス状態と言ったので、何らかの理由で Config に行ってコンプライアンス情報を取得し、Config にはそれがないことを認識し、自動修正して Systems Manager からその情報を取得しようとします。ここのどこかにあります。Systems Manager コンプライアンス API を使用してそれを取得します。それだけです。
エージェントの進化：ツールとプロンプトの最適化
ということで、私たちは多くのことができることに気づきましたが、パフォーマンスは最適ではありませんでした。5回のツール呼び出しを経由する必要があり、時には7回になることもあり、それは理想的ではありませんでした。そこで、エージェントをもっとリッチで、もっとパワフルにしたらどうだろうかと考えました。 もっと多くのツールを与えて、システムプロンプトを調整しましょう。その時点で、私たちはこのようなものを使うことにしました。 これを削除するつもりです。同じエージェントですが、少し充実したプロンプトと、それがアクセスできるより良いツールを備えています。そして、内部で何が起こっているかについて、もう少し説明させていただきます。
Bedrock モデルが定義されています。Strands で定義しなかった場合、デフォルトでは Claude を使用します。今日の US East One では、温度や top P などのすべてのパラメータも設定されます。これは創造性を制御し、max tokens などの他のいくつかのものも制御します。デフォルトパラメータは私たちのユースケースに適さないかもしれません。ですから、私たちはそれも制御する必要がありました。そして、私たちの場合、Nova を使用できるかどうかを試してみました。これにより、より良いコスト性能が得られ、どのように機能するかを確認できます。 これが2番目のイテレーションでした。文字通りこれだけです。そして、大規模言語モデルの創造性を制御するために温度要素を制御して、できるだけ決定論的にしました。
さて、Python 愛好家の皆さんのために、ここでツールを見ることができます。2つのツールがあります。 1つは EC2 インスタンスを取得するためのもので、もう1つはパッチコンプライアンス状態を取得するためのものです。これは単に Boto3 を活用する Python 関数です。それだけです。 唯一の違いは、tool デコレータを使用することです。これにより、Python 関数が大規模言語モデルによって使用されるツールとして公開されます。そしてそれがどのように機能するかというと、docstring によってです。docstring は、ツールが何をするかについて明確で構造化されている限り、それがいつどのように使用するかを知っています。この場合、環境でオプションでフィルタリングされた EC2 インスタンスを取得するだけです。それだけです。そして、パッチコンプライアンスの取得についても、ここで同じことをしています。ですから、それがツールの部分です。
さて、プロンプトについて、以前は「あなたは EC2 アシスタントです」と言っていました。それを変更したかったのは、すべてのその追加情報が通ってくるのが見えたからです。それは私たちが必要としなかったものです。ですから、それを制御することができます。これは behavior のようなものを使用することによってです。これは基本的に、エージェントがいくつかのことに従うことを確認するためにエージェントに与えている一連の指示です。 私が望んでいたことです。
最初に正確なサマリーを与えてほしい、そして詳細、複数のインスタンスのための markdown テーブル、そして言及されていない場合はデフォルトリージョンを使用してください。しかし、ここから興味深い部分が来ます。私は EC2 アシスタントを構築しており、他に何も望んでいません。ですから、プロンプトを使用して、それが実行する必要があるスコープとロールを制御できます。この場合、ユーザーが EC2 に関連しないクエリについて何かを尋ねた場合、それを処理しないと言って応答するだけです。それだけです。
次に、ツールを明示的にすることについてです。繰り返しになりますが、必須ではなく、個人の好みの問題です。docstring 自体が 大規模言語モデルがいつツールを使うべきかを理解するのに役立つからです。ただ、私は細かいので、非常に明示的にして、エージェントが何をする必要があるのかをしっかり理解させたいのです。そして出力形式についてですが、ターミナル上でチャットボットを使っているので、出力の観点から特定の指示セットに従う必要がありました。そしてツールについてです。ご覧の通り、AWS はもう使っていません。 2 つのツールだけです。チャットボット体験を考え始めるための非常に基本的な while ループがあるだけで、それだけです。
では、これを実行してみましょう。Claude、Python、EC2 ですが、ツール付きです。リクエストが来るので、前のプロンプトをコピペします 正確な動作を見てもらうためですが、今回はより知的なエージェントを使っています。ストリーミング情報が 流れてくるのが見えるでしょう。これがターミナル上でチャットボットを構築した理由の 1 つで、ストリーミング動作を示すためです。Web アプリでもできたかもしれませんが、ターミナルの方がちょっと簡単だったんです。
ご覧の通り、意図を理解して、ツール呼び出しを 2 つだけ行っています。それだけです。前のことを覚えていたら、この動作も観察してください。これはかなり重要だからです。1 行ずつ入力されているという事実です。これの背後で何が起こっているのか、そしてなぜこれが理想的ではないのかについて説明します。 ツール呼び出しを 2 つ行いました。前のエージェントを覚えていたら、5 回、時には 7 回、時には 2 回でした。予測不可能でした。ツールを使うと、より予測可能で決定論的な動作が得られるようになります。
では、その 1 行ずつ出力されるという点についてです。これは、パッチコンプライアンス状態用に用意したツールが一度に 1 つのインスタンスしか許可していなかったからです。つまり、大規模言語モデルは基本的に Systems Manager に 5 つの API 呼び出しを行っています。5 つのインスタンスがあるからです。理想的ではありません。バッチ処理が方法ですが、私たちはそれを難しい方法で気づきました。実は、私たちが怠け者だったんだと思います。スコープについての最後の 1 つのこと。「すべての Lambda インスタンスをリストアップしてください」。覚えていたら、これは単なる EC2 エージェントです。エージェントは私に何の情報も与えるべきではありません。ですから、セキュリティの観点から、ガードレールを構築できます。これはそれを実現する 1 つの方法です。 他の方法もあります。おそらくもっと複雑なものもありますが、これは実現する 1 つの方法です。特にプロンプトに不要なコンテンツを注入することに関しては。
これはそれを実現する 1 つの方法です。システムプロンプト内に制御を置くことです。EC2 関連のクエリのみを処理すると言っています。重複を無視してください。ただ、EC2 関連のクエリのみを処理すると言っているだけで、同じことが繰り返し試みた場合にも適用されます。それだけです。私たちは AWS が使っているものより多くのことができることに気づいた段階に達したので、より多くのツールを構築し始めました。しかし、エージェントはどんどん重くなっていきました。そこで、単一のエージェントにするべきか、複数のエージェントに分割し始めるべきかという、モノリシック対マイクロサービスのような議論が再び始まった段階に達しました。
Patchyのコードベース：Supervisor、専門エージェント、ワークフロー制御
我々がこの後者のパスを進むことがより明らかになった理由は、hallucination と confusion があったからです。我々が従い始めた単純な哲学は、agent が1つの specialized task をやっていないのであれば、それは分割されるべきだということです。繰り返しになりますが、これは philosophical な議論です—monolith 対 microservices ですね。私はそこに入り込むつもりはありません。多分、丸一日、もしかしたら1週間かけてこれについて議論することになるかもしれませんが、どこにも到達しないと思います。ただ、我々の現実としては、それを分割して、進化させて、より多くのツールを追加することで、より良い結果が得られるようになったということです。我々は今日 Apache という段階に到達しており、これから Apache のコードベースを歩いていきます。
よし、これらを閉じるだけです。では、プロジェクト構造の観点から非常に素早く説明すると、agent 関連のコードはすべて agent フォルダ内にあります。helper フォルダ内に helper 関数があり、それについても説明します。ただ、非常に素早く、 Docker ファイルに表示されている Bedrock Agent Core YAML ファイル—これらは agent コードのデプロイメントに関連しており、runtime が agent をデプロイするために使用する設定ファイルと Docker ファイルです。
その他すべてには、4つの agent が含まれています：patch manager、supervisor、vulnerability agent、および compliance analyst です。helper 関数では、 memory、globals、およびその他いくつかのものがあります。強調したい重要なことは、tools ファイルです。
tools を agent 内に埋め込むこともできます。ただし、ソフトウェアエンジニアリングのバックグラウンドを持つ私にとっては、externalize して、すべてを別のファイルに持つ方が簡単でした。これにより、maintainability、readability、およびその他の考慮事項が容易になりました。単純にこのようにインポートすることができます。私は既にいくつかの tools について説明しましたので、それについてもう一度退屈させるつもりはありません。私が1つのツールを見せたいだけで、それが我々の観点からどのように見えるかを示したいのです。
ここに get vulnerability findings tool があります。これを削除して、画面全体が見えるようにします。おそらく23の重要なことがあります。1つは docstrings です。Python コードを実行したことがあれば、これに精通しているでしょう。できるだけ明確で構造化されていることで、large language model がツールをいつどのように使用するかを理解するのがはるかに容易になります。ゴミを入れればゴミが出てくる、それと同じくらい単純なことです。
私たちの場合、目的が何であるか、CVSS severity、environment、limit といった arguments を定義します。例えば、デフォルト値について非常に明確にして、可能な限り例を示すようにしています。 また、ツールが呼び出されたときに何を返すかも定義します。可能な限り dictionary objects を返すようにしてください。大規模言語モデルが単なる文字列出力と比べてより多くのコンテキストを持つほど、出力としてより豊かな情報を提供できるようになります。
さて、ここで強調したいことの 1 つは 、optional と required、つまり mandatory な arguments があるという事実です。基本的に、この 1 つのことを使ってエージェントの動作を制御できます。例を挙げるなら、get vulnerability findings で、私の severity が mandatory または required だったとしましょう。大規模言語モデルが呼び出されるとき、Justin がプロンプトで「すべての脆弱性を教えてください」と言うだけで、severity については全く言及していないとします。その時点で、これが required または mandatory だった場合、大規模言語モデルはユーザーがすべてを求めていると仮定するかもしれません。つまり、critical な findings を求めていると仮定する可能性があります。なぜなら critical は high だからです。大規模言語モデルに仮定が組み込まれてしまうわけです。
しかし、これを強制すれば、大規模言語モデルはユーザーに再度質問または確認して、critical、high、medium、low のどれを意味するのかと聞きます。arguments 自体を使うだけで動作を制御できるのです。それ以外は、 ロケット科学ではありません。シンプルな Python 関数です。vulnerability findings の情報を取得するために Bedrock clients を使用しています。
supervisor agent に移ります。時間を確認させてください。時間は大丈夫です。これが私たちが持っている supervisor agent で、基本的にはワークフロー全体のオーケストレーションを制御するものです。supervisor がエージェントと相互作用するために、私たちは agents' tool と呼ばれるパターンを使用しています。一番下までスクロールすれば、その意味が分かり始めるでしょう。1 つのことだけ非常に素早く言及させてください。
これら 3 行が見えるようになります。そこでは、異なるファイルに属する 3 つの主要なエージェントをインポートしており、tool decorator を使用してそれらをツールとして利用可能にしています。 非常に素早くスクロールダウンします。ここです。これは単に vulnerability analyst、つまりエージェント自体、specialized agent に相談するためのものです。 自然言語リクエストを文字列として渡すだけで、vulnerability analyst がユーザーの意図を理解できるようにします。つまり、supervisor agent がやっていることは、意図を理解して、その specialized agent の能力に基づいてそのリクエストを specialized agent に渡すだけです。そして、その方法についても説明します。その後、specialized agents に残りの処理をさせるのです。
この場合、3つのツールを使っています。また、これら3つのエージェントのスコープ外のリクエストが来た場合に備えて、AWS ツールも使用しています。システムプロンプト自体をさっと説明していきます。ここでは、パッチ自動化コーディネーターという役割を定義していて、リクエストを専門のエージェントにルーティングします。出力の冗長性など、従うべきことに関するレスポンスガイドラインがあります。つまり、実際に何が必要で、どのフォーマットが必要かについて、非常に直接的である必要があります。
実際に必要なのは、ページネーションを含むデータのフォーマットを理解することで、例えば50個の重大度が利用可能ですが、10個だけ表示するというように、データが10項目以上の場合は切り詰めることです。こういった細かいことが重要です。次に、ルーティングの優先度があります。優先度をどのように設定したいのか、リクエストをどのようにルーティングしたいのかということです。これはユーザーの主な意図を理解することが関わっています。その情報が見つからない場合は、メモリ自体からコンテキストを取得します。それも見つからない場合は、AWS を使用するようにルーティングします。それだけです。セキュリティ脆弱性、CVE などを分析するための専門エージェントをいつ使用するかについての詳細を提供するだけです。セマンティックルーティング、キーワードルーティング、または機能ベースのルーティングも使用できます。これはその一つの方法に過ぎません。
ツールについてもう一度言及します。メモリからの2番目のエージェントを思い出してください。ツールが1行ずつ出力を始めたとき、これが私が説明したかったことです。定義したツールを使用すれば、バッチ処理を制御できます。API呼び出しを10回または20回行う必要がある場合、それを制御できます。しかし、AWS を使用するような組み込みツールの場合、制御できません。そのため、プロンプト自体を使用して、大規模言語モデルがそのツールをどのように使用または活用すべきかの動作を制御しています。この場合、関連するクエリをバッチ処理し、フィルターを使用してデータ転送を削減することで、トークン消費を削減するのに役立ちます。はい、トークンに対して支払う必要があり、コストが上がり始めたときにそれを再認識しました。
出力フォーマットは、絵文字のようなもので、見た目を良くするためのものでした。それだけです。これが supervisor agent です。概要を説明するために、Patch Manager を素早く紹介します。これが最も複雑なもので、他のすべての専門エージェントも同じような形式に従っています。ご覧のように、利用可能なヘルパーツールが山ほどあります。非常に具体的な機能を引き出したかったからです。決定論的であることを望んでいて、一貫性を望んでいます。説明していくと、スコープを非常に明確に定義しました。なぜなら、スコープが定義されていない場合、supervisor agent がリクエストを受け取ると、複数のエージェントにルーティングしてしまうことが観察されたからです。専門エージェントがそのタスクを実行できない場合、それがそのスコープ内にないため、スコープ外のレスポンスで戻ってきて、supervisor agent は自分自身を修正し、リクエストをルーティングする必要がある他の専門エージェントを把握する必要があります。これは非常に重要で、心に留めておきたいことです。
ご理解いただけるように、パッチ適用というプロセスは非常に厳密で、非常に制御されています。単にアドホックな方法で行われるべきではなく、そのプロセス全体を制御したいのです。最初は、Patch Manager は並列で処理を行っていました。例えば、dev と staging を同時に行おうとしていて、より効率的になろうとしていました。しかし、そうすべきではないことに気付きました。そのため、プロンプト内にワークフローの概念を組み込んで、その動作を制御する必要がありました。最初のやり方は、CVE の重大度を最初に取得することでした。ユーザーがプロンプト自体で「dev 環境で重大度が高いものをくれ」と言って提供するか、それが利用できない場合は、メモリからも抽出します。そのため、その情報を吸収してその計算に使用できるさまざまな方法があります。
次に、パッチコンプライアンスについてです。これらのインスタンス内で複数のアプリケーションが実行されており、それぞれに SLA が関連付けられたコンプライアンスフレームワークが割り当てられています。環境と提供されている重大度に基づいて、パッチコンプライアンスの状態を取得します。次に、当該環境のメンテナンスウィンドウを取得します。これはパッチ適用の観点から次の実行がいつ行われるかを示しています。ここで Patch Manager エージェントのスマートな意思決定能力が活躍します。重大度情報を持ち、アプリケーションの SLA を理解した上で、緊急形式でパッチを適用するか、つまり直ちに適用するか、それとも次のメンテナンスウィンドウまで待つことができるかを判断する必要があります。これはわずか数行のコードで実現されます。おそらく書いていたであろう大きな if-else ステートメントではなく。それは誰にとっても理解するには複雑すぎます。その後、その情報を表示します。つまり、ウィンドウが SLA デッドラインの範囲内か範囲外かを示し、今すぐパッチを適用する必要があるか、後で対応するかを判断します。このワークフロー全体がプロンプトに組み込まれていました。最適化できたでしょうか？もちろんです。しかし、私たちは多くのテストに基づいてこの段階に到達しました。
先週、リリースがありました。re:Invent に近づいている中で、実は既に re:Invent の最中なのですが、多くの新しい発表があります。新しい発表の一つは Strands の Standard Operating Procedure で、ワークフロー実装の多くを実際に外部化できるというものです。これによってプロンプトがはるかに小さくなり、トークン消費が減り、応答が高速化され、エージェントの応答も高速化されます。次に、インスタンスランキングについてです。緊急と非緊急のシナリオに対する計算を実行し、ビジネスインパクトとブラストラディウスに基づいてインスタンスをランク付けする機能があります。実は段階的な実行を行うことができます。これには長い時間がかかるため、先ほど述べたようにデモでは示すことができませんでしたが、内部的には緊急パッチ適用の状況であっても、段階的に進める必要があるという認識を持っています。これを行う際に、ヘルスベリフィケーションが非常に重要であることを念頭に置いています。これは各環境の後に必須です。パッチを適用するときに、アプリケーションに問題が発生してダウンしてしまい、アップタイムなどに影響を与えることを、私たちは皆経験しています。そこで、非常にシンプルなヘルスベリフィケーションシステムを構築しました。もちろん、より複雑なものを構築することもできますが、ロジックは同じです。2 つのレイヤーのチェックがあります。1 つはインフラストラクチャレイヤー用の Systems Manager を使用したシンプルな ping チェックです。もう 1 つは CloudWatch アラームです。皆さんの場合、Splunk、New Relic、DataDog、または使用しているものにエージェントを webhook として統合して、パッチの一部としてアラームがトリガーされたかどうかを確認できます。それが起こった場合、ロールバックできます。
パッチが適用されたことが原因でシステムが壊れたため、容量をロールバックできるという経験がどれほど有用でしょうか？また、その環境のみをロールバックする必要があることを認識するほど賢いため、パッチが成功した前の環境またはより低い環境との間のデルタを比較することもできます。最後に、このすべての情報は、CTO が満足するようにコンプライアンスレポート用のどこかに送信される必要があります。それは特定のツールで行われ、すべての情報がキャプチャされます。ロールバックポリシーの出力形式がありましたが、これはかなり単純です。プロンプトの観点から皆さんに持ち帰ってほしいことがいくつかあります。皆さんはこれを経験されていると思います。プロンプトエンジニアリングは芸術だと言いたいところですが、今ではその背後に多くの科学があるように感じます。私たちを助けてくれた重要なヒントをいくつか紹介します。できるだけ構造化され、明確に保つこと。簡潔に保つこと。より堅牢であればあるほど、エージェントが専門家エージェントと連携するたびに、これらの多くを持ち運ぶことになり、それは非常に難しくなり、より高くつきます。上部と下部に矛盾する指示がないことに注意してください。上部で何かを言ったのに、下部は全く異なるという場合が何度かありました。エージェントはそれに関して非常に混乱しやすいです。例を示してください。良い例を示して、それを今後のパターンとして使用するようにしてください。
まとめ：小さく始めて反復する、Agentic AIの実践的アプローチ
これが基本的にコード自体に関して私たちが持っていたものです。私が非常に素早く行おうとしているのは、それを PPD に変更することです。皆さんは見たことがあります。Justin は既にデモを示しており、私はコードベースを皆さんと一緒に確認しました。時間があれば、Romi がどれほど優しくしてくれるかによって、オフラインで質問に対応するか、質問に対応するか、または部屋を出て質問に答えるかのいずれかを喜んで行います。エージェント AI がいかにすべてをより良く管理し、より良く準備できるかを見てきました。技術的および運用的に実行可能です。それは「もし」ではなく、単なる時間の問題です。明日、すべてが魔法のように解決されると言っているわけではありませんが、セキュリティディレクターからのリスクやブラストラディウスについての質問に数秒で答えることができる段階に非常に近いと思います。アプリケーションオーナーとアプリケーションチームがその情報を提供するのに依存する必要はもうありません。数秒以内にそれを取得できます。プラットフォームエンジニアは、パッチを適用した場合、それをロールバックできるという確信と安心感を持っています。これは、アプリケーションチーム、プラットフォームエンジニアリングチーム、クラウドチームなどがいる集中化された環境で特に有用です。コンプライアンスマネージャーは、重大な脆弱性だからといって急いで対応する必要がないことを知っているため、少し安心しています。メンテナンスウィンドウに適合すれば、より早く判断を下すことができます。CTO は、より準拠しており、パッチ適用の観点からビジネスの健全性を理解し、チームが進化してより良くなるのを支援し続けることができるため、プレスに載ることがないことに非常に満足しています。したがって、皆さんに持ち帰ってほしい 3 つの重要なことがあるとすれば、それらが主なポイントです。
ツール対プロンプトが最初のものです。少し哲学的になる段階に到達すると思いますが、私たちが経験したのは、ツールはより決定論的でより一貫性があり、プロンプトはより創造的で大規模言語モデルが独自に考えることができるということです。時々うまくいき、時々うまくいきません。特定のソリューションを構築したり、特定の結果に到達しようとしたりするときは、これを念頭に置いてください。これらの決定を下すときに、ツール対プロンプトについて考えてください。
2番目の重要なポイントは「拡張か置き換えか」ということです。AIが世界を乗っ取るだけだと考えている人が多いと思いますが、最終的にはそうなるかもしれませんが、まだその段階には達していません。今日お見せしたものはすべて、AIがチームとシステムをより賢く、より強力にするための拡張機能を示しています。これらのツールは既存のシステムを拡張するか置き換えるためのものです。Agentsはスケールと俊敏性を提供しますが、ガバナンスと監視を提供するには人間が必要です。それがなければ、私たち全員にとって本当に悪い状況になります。
最後に、小さく始めて、テストして、反復するということです。私たちは初日からこの段階に到達したわけではありません。ここに到達するまでに数ヶ月かかりました。私たちは皆、本業を持っていますが、私たちがしたように、もし心を決めれば、確実に全体の経験を加速させることができると思います。小さく始めて、テストして、反復してください。Observability toolingを使用して、Agentsが何ができるのか、そしてレスポンスがどのようなものかを理解する段階に到達してから、それらを調整してください。このプロセスに時間をかけてください。
強調したい重要なポイントの1つは、ソフトウェアエンジニアでなくても、バージョン管理の観点からすべてのソフトウェアエンジニアリングプラクティスに従ってください。プロンプトとモデルを調整する際に、モデル評価とプロンプト評価を支援するツールを見てください。パラメータは非常に便利です。私たちは コードを間もなく公開する予定です。私たちが構築したものはすべて、簡単に入手できるパターンとサンプルに基づいています。これらは Bedrock Agent、コードサンプル、および Strands Agent の QR コードです。うまくいけば、すぐにコードが公開されますが、それまでの間、今日学んだレッスンをパターンとアーキテクチャの原則の観点から適用して、これらのサンプルで使用できます。
皆さんはスワッグのためにここにいるんだと思います。そうでなければ、デモのために来ることができます。私たちもそこにいます。AWS Village の Cloud Ops キオスクにぜひお立ち寄りください。Justin と私の代わりに、本当にありがとうございます。5分ありますので、Ziggy が大丈夫であれば、喜んで の周りに来て質問を受け付けます。 本当にありがとうございました。本当に感謝しています。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion