re:Invent 2025: AIエージェントによるクラウド運用自動化とSecurity Lake活用

はじめに

海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！

re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください

📖 re:Invent 2025: AWS re:Invent 2025 - AI agents for cloud ops: Automating infrastructure management (AIM340)

この動画では、AWSのSolutions ArchitectであるOmar TabbakhaとShawn Abdiが、クラウド運用のためのAIエージェントとセキュリティオペレーションの自動化について解説しています。午前2時のセキュリティインシデント対応という現実的なシナリオから始まり、異なる形式のログを手動で調査する課題を提示した上で、Amazon Security Lakeを活用したマルチエージェントアーキテクチャのソリューションを紹介します。Strands Agentsを使用した実装では、DynamoDBからビジネスコンテキストを取得するエージェント、Amazon Athenaを通じてSecurity Lakeをクエリするエージェント、Cloud Control MCPサーバーを使ったクラウドオペレーション自動化エージェントを構築し、スーパーバイザーエージェントがこれらを統合します。Jupyter Notebookでの実際のコーディングデモを通じて、ツール定義、システムプロンプト、human in the loopの重要性を説明し、最後にAmazon Bedrock AgentCore Runtimeを使った本番環境へのデプロイ方法まで網羅しています。

https://www.youtube.com/watch?v=JRu2GqRe9sg
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。

本編

セッション開始：クラウド運用のためのAIエージェントとインフラ管理の自動化

皆さん、こんにちは。本日は私たちのコードトークにお越しいただきありがとうございます。今日はクラウド運用のためのAIエージェントと、インフラ管理を自動化する方法についてお話しします。本日議論する重要なトピックの一つは、セキュリティオペレーションをどのように運用できるかということです。本日のセッションの構成ですが、まずエージェントとは何かというコアコンポーネント、統合のタイプ、ツール、そしていくつかの基本的な概念についてお話しすることから始めます。そこから、AWSコンソールに入って実際のデモを見ていき、コードについて説明し、私たちが開発したこのエージェントアプリケーションから出力される結果を見ていきます。

私の名前はOmar Tabbakhaです。AWSのSolutions Architectをしています。皆さんこんにちは、私の名前はShawn Abdiです。私もAWSのSolutions Architectをしています。では始める前に、挙手でお願いしたいのですが、これまでにエージェントを構築したことがある方はどれくらいいらっしゃいますか？シンプルな天気予報アプリケーションのエージェントでも構いません。一人、二人手が挙がりましたね。なるほど、かなりの方がエージェントを構築したことがあるんですね。おそらくAWSか、あるいは他のフレームワークを使われたのだと思いますが、何人かの方はすでにエージェントを構築されているようですね。素晴らしいです。では早速始めていきましょう。

午前2時のセキュリティインシデント：手動プロセスの限界とAIの必要性

では、あなたが午前2時に電話を受けたセキュリティエンジニアで、セキュリティインシデントに関する高圧的な状況に突然放り込まれたと想像してみてください。 ログインして、最初のタスクは、JSONやプレーンテキストなど、すべて異なる形式の膨大な量のログを調べることです。それはVPCフローログ、ファイアウォールログ、APIログ、CloudTrailログ、さらにはオンプレミスやクラウド環境で使用している可能性のあるサードパーティベンダーのログなど、AWSネイティブではないものも含まれます。

そして、これらの異なる断片をつなぎ合わせようとしているうちに何時間も経過していきます。先ほど述べたように、GuardDutyアラート、CloudTrailログ、DynamoDBログ、Security Hubの検出結果などがあり、これらの異なるリソースがどのように相互に通信しているのかをまだ解明しようとしています。ご存知のように、これらは別々のシステムから来ており、異なる言語を話していて、本当に互いに通信することを意図していないのです。そして時計は刻々と進んでいます。疑わしいIPを特定しようとし、それが本当にセキュリティインシデントなのか、それとも 誤検知なのかを確認しようとしていますが、何が起こっているのかを把握しようと何時間も何時間も検索に費やしています。

この時点で、あなたは疲れ果て始めています。 AIのようなものが処理できるかもしれない地道な作業をすべて行ってきました。先ほど述べたように、JSONやプレーンテキスト、その他の標準化されたスキーマなど、異なる形式であるために異なるツールを使ってこれらのリソースを検索することに時間を費やし、今何をする必要があるのかを考えています。では、この問題を解決して、エージェントのような何らかの特化したインテリジェンスシステムを使用できるとしたらどうでしょうか。それらがこれらすべてのログを精査し、これらの異なるツールを精査して、現在のリスクについて実行可能なインサイトを提供し、この問題に取り組むためのより正確な道筋を示してくれるのです。

それでは、なぜセキュリティオペレーションにAIが必要なのかについてお話しします。現在の現実として、すべてが超高速で動いています。攻撃は自動化されてきており、人々は何が起こっているのかを特定するのに何時間も費やしています。そして、この手動プロセスによる従来のアプローチは、もはや誰にとってもうまく機能しないように見えます。AIがゲームチェンジャーとなったのは、膨大で複雑なデータセットを数秒で分析できるようになったという点です。人間が見逃してしまうかもしれないパターンや異常を、エラーが発生しやすい手動プロセスの中で検出できます。そして、トリアージやログの相関分析のような反復的なタスクを自動化できます。そしてこれらを使って重要なインサイトを表面化させ、典型的なセキュリティエンジニアが日々の業務で目にするような雑務ではなく、実際の脅威に集中できるようにします。

LLMとエージェント型AIの違い：推論能力と反復処理の重要性

それでは、典型的なLLMとエージェント型AIの違いから始めましょう。左側には通常のLLMがあります。これは既に訓練された知識を使って、多くの反復や思考プロセス、推論を行うことなく、シンプルで簡潔な答えを提供します。例えば、フランス革命はいつ起こったのかと質問すると、1789年というシンプルな答えを返してくれます。

さて、右側にはエージェント型AIがあり、ここからが面白くなります。エージェントは自分で考えることができます。では、天気予報のウェブサイトをチェックしてみましょう。来週の予報を詳しく見てみましょう。雨の日もありますが、来週の金曜日は晴れて暖かいですね。そして評価と反復を繰り返し、推論能力を使って適切な答えにたどり着きます。来週の金曜日が富士山ハイキングに最適な日だと。ここでの違いは、先ほど述べたように、既に訓練された知識に基づいた簡潔な答えを出すだけでなく、自分で考え、反復して、トリアージに使える価値のある回答を出したり、フォローアップのプロンプトを尋ねることでエージェントからさらなる情報を得ることができるということです。

データの集約と正規化：Amazon Security LakeとOCSFの活用

それでは、最初に強調しておきたい重要なポイントは、データがこのエージェント構築のすべての鍵となる情報源だということです。適切なデータソースを持ち、すべてを読みやすく、セキュリティユースケースに特化してフォーマットされた場所に集約することが重要です。ここでAmazon Security Lakeが登場します。

ご存じない方のために説明すると、これは基本的に、先ほど述べたさまざまなツール、JSONであれ、プレーンテキストであれ、その他のものであれ、すべての異なるログをAWSアカウント内のデータレイクに集約できるサービスです。そうすることで、異なるスキーマからのデータを、OCSFと呼ばれるOpen Cybersecurity Schema Frameworkという、すぐに使える形式に正規化できます。そうすれば、これらのデータサイロやそもそもバラバラだったものを心配することなく、単一のツールや単一のアプローチ方法でログ分析を行うことができます。それでは、コンソールに入る前に、Omarにソリューションの簡単な概要を説明してもらいます。

マルチエージェントアプリケーションの構成：専門性を持つサブエージェントの協働

素晴らしい、Seanありがとうございます。それでは私たちのソリューションについて説明していきましょう。今日まず最初にお話ししたいのは、マルチエージェントアプリケーションを導入するということです。これは、異なる専門性を持つエージェントのチームを持つことを意味します。これを説明する際に私が好きな例えは、今日皆さんが持っているチームについて考えることです。通常、データサイエンティストがいて、コンピュータサイエンティストがいて、営業チームやマーケティングチームがいるかもしれません。そして各チームや各人は特定のスキルに特化していて、彼らが持つ知識に基づいて専門的なアウトプットを生み出すことができます。私たちはこれとまったく同じパラダイムをエージェントの世界に持ち込みます。

例えば、このケースでは、これらのエージェントがあります。私はこれらをサブエージェントと呼びますが、なぜなら彼らは多数のエージェントの中の一つであり、これらが協力して異なるセキュリティイベントを見つけ、さらにそれらの問題を修復するクラウドオペレーションを自動化するのを助けてくれるからです。この最初のサブエージェントはDynamoDBにアクセスして、私たちの環境から実際のビジネスコンテキストを取得することができます。

もう一つの重要なものは、Security Lakeを使用できるエージェントです。ここでの重要な要素は、もしオンプレミスにサーバーがあったり、他のクラウドプロバイダーを使っていたり、あるいは異なるSaaSプロバイダーと連携している場合でも、すべてのデータを一つの特定のスキーマを持つ中央のセキュリティデータレイクに集約して正規化できるということです。そうすることで、私たちのエージェントがアクセスしてこれらのログにアクセスし、その情報を全体のシステムに提供できるようになります。

もう一つの重要なものはクラウドオペレーションです。ここにいる皆さんの中で、MCPが何か知っている方はいますか？その用語を聞いたことがある方は？素晴らしい。これはModel Context Protocolの略です。今日のトークでは何度も、ツールとして使用できるカスタム関数を構築していきます。繰り返しになりますが、ツールとは本質的にAPIやデータソースであり、大規模言語モデルが回答を提供するための追加のコンテキストとして使用できるものです。クラウドオペレーションでは様々なことができます。Cloud Control MCPサーバーがあり、これを使って例えば、悪意のある可能性がある特定のIPアドレスにブロックルールを追加したりできます。EC2インスタンスを隔離したい場合や、EBSボリュームのフォレンジックスナップショットを取得したい場合もあるでしょう。私たちはクラウドオペレーションを自動化できるのです。

明らかに一つの重要な懸念は、本当に本番環境の鍵をエージェントに渡したいのか、ということです。これは誰もが気にする大きな疑問であり、そこで私たちはガードレールの実装や、human in the loopの実装といった様々なことを検討します。実際にすべての発見事項のサマリーを取得して、ユーザーに「これは正しいアプローチですか？」と尋ねることができます。今日の最高のエージェントアプリケーションでさえ、成功率は90%台前半程度です。ですから、重要なクリティカルなオペレーションについては、常にそのプロセスの中にhuman in the loopを入れたいと考えます。

そしてもちろん、インシデント対応のplaybookです。一部のセキュリティイベントには機密性の低いデータが含まれている可能性があり、そういったものについては、より重要度の高い環境を持つアカウントとは異なるアプローチで対処していきます。ここでは、これらのエージェントを連携させることができ、前面にスーパーバイザーエージェントを配置することができます。このスーパーバイザーエージェントは、サブスペシャリストのチームを活用して、実際にさまざまなタスクを調整し、異なる回答を得て、それらを最終的なレスポンスに統合することができます。

これは2つの異なる方法で機能します。1つ目は、イベント駆動型アーキテクチャのようなアプローチで、GuardDutyの検出結果を取得することができます。GuardDutyは私たちの脅威検出サービスです。GuardDutyの検出結果を取得して、それを自動的にagenticシステムに送ることができます。例えば、誰かがS3バケットを公開したとしましょう。これによって何らかのGuardDutyの検出結果がトリガーされ、それが直接エージェントに送信されます。そしてエージェントはそれを見て理解することができます。「わかりました、これはどのアカウントから来ているのか？ログを見てみよう。誰がこれをやったのか？これを修復するためにどのようなステップが必要か？」といった具合です。そして、ビジネスコンテキストに基づいて、そのバケットが属するセキュリティチームにアラートを上げるといったことや、エージェントと直接やり取りすることもできます。イベントをより深く掘り下げたい場合や、より高度なことをしたい場合は、エージェントと対話することができます。では、実際にそれがどのように見えるか見てみましょう。

フロントエンドアプリケーションのデモ：脅威検出から自動応答まで

これはSeanと私が開発したフロントエンドアプリケーションです。このアプリケーションを作るためにStreamlitを使用しています。左側には、セキュリティエンジニアが実際に見て使用できるサンプルクエリがあります。ここでの1つの例は、脅威検出クエリです。ここでは、過去1時間に10回を超えるログイン失敗の試行を見つけ、送信元IPと影響を受けたアカウントを分析し、そして疑わしいIPをブロックしてスナップショットを作成する、と言っています。このプロンプトは、このタスクを完了するために複数の異なるエージェントを活用することになります。

submitを押すと、実際にエージェントが「わかりました、認証ログを分析しましょう」と進んでいくのが見えます。そこで特定のツールを呼び出します。これらのツールは、Security Lake内にある異なるテーブルを見ることができます。CloudTrailイベントとSecurity Hubの検出結果を見つけます。そして、送信元IPが何かを見つけるためにクエリを実行することができます。ここでは、異なるリージョンにまたがる3つの主要な送信元IPを見つけ、そして実際にそれをブロックできるCloud Operationsエージェントを実行することができます。ほら、ブロックされているさまざまなIPが表示されています、そしてここには自動応答アクションが表示されています。

繰り返しになりますが、これはより自動化されたアプローチです。できることの1つは、見つけたものの異なるサマリーを提供し、そして「これらのIPアドレスをブロックしてほしいですか？アカウント内に制限付きのSTPコントロールを設定してほしいですか？」と尋ねることができます。ですから、これらは考え抜く必要があることです。一部のプロセスではエージェントに完全な自律性を与えたいですが、より重要な他のプロセスでは、間違いなくhuman in the loopについて考える必要があります。左側には再び異なるエージェントがあり、今日はコンソールでいくつかのコアエージェントを見ていき、実際にどのように書いたかをお見せします。では、開発方法ですが、次のスライドに行きましょう。

Strands Agentsによる開発：エージェント構築の簡素化とagentic loopの実装

さて、これを開発した方法ですが、Strands Agentsを使用しています。これはオープンソースのSDKで、わずか数行のコードでエージェントを構築できるようになっています。非常に直感的で使いやすいんですね。私が約1年前にエージェントを見始めて構築し始めた時、Pythonをやっていなかったんです。大学以来Pythonに触れていなかったので、少し錆びついていました。でもStrandsを使うことで、非常に早く習得することができたんです。今日後ほどご覧いただきますが、エージェントを構築する際の複雑さの多くを抽象化してくれています。

もう一つの核となるものは、ネイティブツールです。今日はツールを構築します。Python関数を定義してツールにしていきますが、既に存在するコミュニティツールも活用できるので、実際にコードを書く必要がない場合もあります。また、さまざまなMCPサーバーとの簡単な統合も可能です。AWSには今日活用できる多数のMCPサーバーがありますし、他のプロバイダーもMCPサーバーを提供していて使用できます。どのモデルプロバイダーもサポートできます。つまり、Amazonのモデルだけに縛られることはありません。Bedrockを見ていただければ、使用できる10以上の基盤モデルがあります。OpenAIやGeminiを使いたい場合も、どのプロバイダーにもロックインされることはありません。

一つお話ししたいのは、これらのサブエージェントについて、タスクに応じて、その特定のエージェントを動かすさまざまなモデルで試すことができるということです。つまり、その核心において、Strandsが行っているのは、このagentic loopの実装です。動作の仕組みですが、天気アプリケーションの例を見てみましょう。例えば、また明日の天気を確認したいとします。繰り返しになりますが、基盤モデルは来週の天気がどうなるかという知識を持っていません。そのようなデータで訓練されていないからです。

ここで何が起こるかというと、プロンプトがエージェントに送信され、エージェントはモデルとツールにアクセスできます。ここでは、ReActオーケストレーションを使用していて、実際にユーザープロンプトでモデルを呼び出します。そしてモデルは、アクセスできるツールに関するすべてのコンテキストを持っています。モデルは推論を行うことができます。例えば、明日の天気を取得する必要がある、待てよ、get weatherのようなさまざまなツールのリストがある、といった具合です。そしてその応答をエージェントに返し、特定のツールを実行するように伝えます。この場合、weather.com APIにアクセスして明日の天気を取得するPython関数である可能性があります。

その結果を返してモデルに送り返し、このループは最終的な応答が得られるまで続きます。ユーザーにプロンプトを出すこともできます。一部のツールが特定の入力を必要としていて、それがない場合、ユーザーに尋ねることができます。例えば、明日の天気について聞いていますが、州が必要です、と。どの場所について話しているのか分からなければ、天気を提供できませんよね。そういったことについても後ほどお話しします。

それでは、StrandsやQ AIのようなSDKを使用する場合の違いについて、簡単にビジュアルでお見せします。ご覧のとおり、天気アプリのエージェントで350行のコードが55行になります。ツールの登録、会話管理、API通信、これらすべてが抽象化されています。自動的に処理されるんです。そして繰り返しになりますが、コードトークを見ていただければ、定義する必要があるものはそれほど多くないことがわかります。繰り返しますが、私たちの目標はエージェントの作成を簡素化することです。エージェントループについても同じですよね。以前は、イテレーションロジックを手動で構築する必要がありましたが、今ではエージェントクラスを呼び出すだけで、それを実行してくれます。

つまり、4時間から6時間かかっていたプロセスが、今では15分から30分で完了できるようになったんです。では、最初のエージェントを見る前に、AWSコンソールに入っていきましょう。どうぞ、John。

ビジネスコンテキストメタデータエージェントの構築：DynamoDBからアカウント情報を取得

コンソールに入る前に、これから構築する最初のエージェントを簡単に見ておきたいと思います。これはビジネスコンテキストメタデータエージェントです。ご覧のとおり、エージェントはAWSアカウントに基づいてアカウントIDを尋ねます。これは12桁の番号で、それを入力します。「このアカウントについて教えて」と言うわけです。エージェントをインスタンス化する前にアタッチするメタデータツールは、DynamoDBテーブルや、そういった情報を保持している特定のAPIを検索できるようになります。ビジネスコンテキストに関して話している情報というのは、ビジネスユニット、重要度、何か報告が必要な場合の連絡先、コンプライアンスの範囲などです。これについては、コンソールでDynamoDBテーブルを開いたときに見ていきます。

しかし、これによって可能になることは、ほとんどの人が気づいていないことなんですが、セキュリティインシデントに関連するコンテキストとビジネスコンテキストは、技術的な詳細と同じくらい重要だということです。これらすべてを数秒で選別して、これがチームが優先すべきものなのか、それとも放置しておいてもよいものなのかを特定できるようになります。リスクが低く、もしかしたらすでに発生しているかもしれない、より優先度の高いセキュリティインシデントのために後回しにできるかもしれません。では、コンソールに入って、構築したものを見ていきましょう。

ええ、コンソールに入って、みんなが楽しみにしている面白い部分に入る前に、これまで議論したことについて質問がないか確認したいと思います。コードに入る前に、それらの質問に対応しておきましょう。これまでStrandsやエージェントについて議論したことで、何か質問はありますか。素晴らしい、オーケー、素晴らしいですね。それでは早速始めましょう。

いいですね。ここではAWSコンソールが表示されていますが、これは標準的なランディングページです。ここからAmazon SageMaker AIに移動したいと思います。Amazon SageMaker AIを使用する理由は、私たちが使えるノートブックが用意されているからです。皆さんがJupyterに馴染みがあるかと思いますが、Jupyter NotebookはインタラクティブなIDEで、コードを構築したり、出力を可視化したり、リアルタイムで実験したりすることができます。これは、このエージェントを一緒にステップバイステップで構築していく上で非常に役立ちます。 では、簡単におさらいしておきましょう。

さて、このエージェントのために最初にやりたいことは、すべての依存関係をインストールすることです。Boto3やPandas、その他必要になるかもしれないライブラリなどですね。では、これらの依存関係をインストールしていきます。依存関係がインストールされたら、次にここにある別のインポートコードスニペットを使ってJSONを取得します。また、Strandsからエージェントとツールファンクションもインポートします。さらに、このコードトークで使用するStrandsモデル、Bedrockモデルもインポートします。では、これを実行しましょう。

そして今、楽しい部分に入ってきました。ここでは、データソースへの接続から始めたいと思います。今回はDynamoDBを使用しています。Boto3セッションを作成して、AWSリソースにプログラマティックに対話できるようにします。そして、データソースとしてDynamoDBを使用しています。ご覧のとおり、リソースはDynamoDBです。US East 2を拠点としています。この特定のコードスニペットでは、作業しているリージョンを定義しています。これを自動検出する方法もあり、US East 2をハードコードする必要はありません。必要であれば、作業しているリージョンを自動的に検出させることもできます。

そして、このエージェントのためにメタデータテーブルを作成して定義したいと思います。これをmetadata_tableと名付け、コンソールで既に事前作成しているDynamoDBテーブルにリンクさせます。はい、もう少しズームインしますね、ええ。これで見やすいですか？素晴らしい。現在セットアップしているデータベースは SOC Account metadataと呼ばれるもので、コンソールに戻ってDynamoDBを見てみると、 先ほど説明したすべてのもの、アカウントID、コンプライアンスのスコープ、重要度などがここに表示されているのがわかります。

ご覧のとおり、アカウントID、 アカウント名、コンプライアンススコープがあり、さらに右にスクロールすると、重要度、作業している環境、本番環境か開発環境かなどを判断して、何に対してアクションを起こすかの優先順位付けに役立つ情報が表示されています。これは、エージェントを使ってビジネスコンテキストを返す際に取得するデータのタイプを確認するためのものです。

では、コードに戻りましょう。DynamoDB テーブルに接続したので、最初にやりたいことはツールを定義することです。まず@toolデコレーターから始めます。ツールにあまり詳しくない方のために説明すると、これは単にエージェントに与える特殊な機能で、コアとなる推論能力を超えて動作できるようにするものです。この特定のケースでは、

AWSアカウントからアカウントメタデータを取得するツールを定義しています。これをget_aws_account_metadataと定義します。アカウントIDが与えられたときに、AWSアカウントに関するメタデータを取得するための情報と指示を与えています。与えている引数は、メタデータが必要なAWSアカウントです。IDは常に12桁になります。ここでそれを明確にすることが重要です。なぜなら、先ほど述べたように、AWSの場合は12桁のアカウント番号だからです。それより小さい数字を入力すると、このアカウントが見つかりませんという結果が返されます。どれだけ細かく設定したいかは、引数の中で見つかります。

エージェントツールは、先ほど見たようなメタデータコンテキストを含む辞書を返してくれます。コンプライアンスの範囲、アカウント名、どの環境に属しているか、誰に連絡すべきか、そしてこれを優先すべきか、それとも他のことに移るべきかといった情報が含まれます。ここでご覧いただけるように、レスポンスはDynamoDBテーブルで見たアカウントID文字列に基づいており、エージェントをインスタンス化して実行すると、そのリストが辞書形式で取得できます。では、このコードを実行して、エージェントを初期化する準備をしましょう。

エージェントは3つのコンポーネントで構成されています。エージェントを構成するその3つのコンポーネントが何か、誰か教えていただけますか？大丈夫です。エージェントとは、モデル、システムプロンプト、そしてツールです。ここで気づかれるかもしれませんが、このエージェントにはモデルが定義されていません。これについてはすぐに説明します。エージェントにmetadata_agentという名前を付けます。システムプロンプトを与えます：「あなたはアカウントIDに基づいてAWSアカウントに関するメタデータを検索する親切なエージェントです。」先ほど述べたように、アカウント番号が12桁でない場合、または見つからない場合は、ユーザーに知らせて、もう一度試せるようにします。エージェントに与えるツールは、先ほど上のコードスニペットで作成したget_aws_account_metadataです。では、エージェントを初期化しましょう。

次のこの部分ですが、先ほど述べたように、モデルが定義されていません。それは、Strandsが提供してくれるデフォルトのモデル、つまりClaude Sonnet 4.0を使うことで全く問題なかったからです。このmodel configコマンドを実行すると、 それを確認できます。もちろん、ユースケースに応じて特定のモデルが必要な場合は、自由に変更して、使いたいモデルを設定していただいて構いません。Claude Sonnet 4は、この例では完璧に機能しました。

必要なリソースがすべてコンパイルされて準備が整いましたので、エージェントにメッセージを送信して、そのディクショナリを使ったレスポンスを取得することができます。アカウント679851713709について教えてください。もしかしたら、すべてを実行していなかったかもしれません。ええ、ブロックを実行する必要がありますね。これでいいですね。もしこのようなことが起きたら、事前にすべてのコードスニペットを実行したことを確認してください。ここでご覧いただけるように、アカウント名はProduction-Mainとなっています。これは最初にエージェントに渡したIDです。所属するビジネスユニットも確認できます。また、これがproduction環境でcriticalの重要度であることも確認できます。そして、セキュリティ担当者に知らせたい場合は、[e-mail]に連絡でき、インシデントの優先度は、例えば最高優先度となっています。

これは、データソースに保存されている情報から収集するのに何時間もかかるかもしれないコンテキストの種類です。エージェントは、アカウントIDを与えられただけで、わずか数秒でそれを取得することができました。それでは、Omarに戻して、このビジネスコンテキストをどのように使用するか、そしてログ分析のためにどのようにデータを使用するかを見せてもらいます。

Security Lakeエージェントの実装：Amazon Athenaを使った自然言語クエリの実行

ありがとう、Sean。エージェントについて話すときに強調したい重要なことの一つは、エージェントの構築が初めての場合は、常により単純なユースケースから始めることです。もう少し分かりやすいものから始めて、さまざまなツールの定義のコツをつかめるようにしましょう。何が機能して何が機能しないかを理解するためです。このケースでは、DynamoDBから始めました。明らかに、ビジネスコンテキストエージェントはシンプルですが、全体的なアーキテクチャの重要なコンポーネントでもあります。それでは、コンソール上で構築する次のエージェントを見てみましょう。これはSecurity Lakeエージェントになります。

これは間違いなくコアなものです。このエージェントの動作方法は、Amazon Athenaを使用します。これはサーバーレスのインタラクティブなクエリサービスで、Security Lakeにあるすべてのデータソースに対して直接SQLクエリを実行できます。この仕組みは、エージェントが特定のプロンプトを受け取ることができるというものです。自然言語を変換できます。例えば、ここで画面を見ていただくと、異常なトラフィックパターンに続くセキュリティグループの変更を表示、と言っています。セキュリティグループの変更はどこに保存されるか、誰か教えてもらえますか？どのようなログに配置されるでしょうか？誰か分かりますか？CloudTrailです。その通りです。それがログソースの一つ、CloudTrailです。では、異常なトラフィックパターンはどうでしょうか？

VPCログ、その通りです。つまり、ここにあるこの自然言語クエリだけに基づいて、Security Lakeをクエリして異常なトラフィックパターンを持つセキュリティグループの変更を取得するためのSQLコードを作成する必要があることを理解するのです。これがエージェント単体のパワーの例です。

こちらにマルチエージェントのサンプルクエリがあります。ここで、異常なAPIアクティビティとネットワーク異常を関連付けて、脅威を封じ込めるという場合、どの2つのエージェントを使用する必要があるか分かる方はいますか?まず1つ目は、APIアクティビティをどのように関連付けるか?そのためにはどのエージェントが必要でしょうか?ヒントは、今まさにそれを見ているということです。何ですか?はい、1つのエージェントはSecurity Lakeエージェントになります。そして脅威の封じ込めについては、もし名前を覚えている方がいれば、戻ってみましょう。はい、Cloud Opsエージェントです、その通りです。この2つが連携して、実際にそのクエリを処理し、私たちが抱えている問題を解決していくことになります。

では、実際のコンソールに入って、これがどのように見えるか確認しましょう。私が操作しましょうか?大丈夫です、ありがとう。それではdemoに行きましょう。いいですね、では、Security Lakeノートブックに入りましょう。Seanと同じように、依存関係をインストールします。それから様々なものをインポートします。重要な2つは、agentクラスです。これによって、異なるツール、foundation model、プロンプトを使ってエージェントを実際に定義できます。また、toolクラスもインポートしているので、Python関数を実際にツールとして定義できます。もちろん、ズームインしますね、どうですか?素晴らしい。

ここでは、Security Lakeの設定を行っています。エージェントに、私のSecurity Lakeに関連付けられたAthena workgroupへのアクセス許可を与えています。繰り返しになりますが、私のSecurity LakeにはVPC Flow Logs、Security Hubの検出結果、そしてCloudTrailイベントなど、全体のログがあります。ここでは異なるAWSクライアントを初期化しているので、Athenaと実際にやり取りできます。私ではなく、エージェントがAthenaと実際にやり取りでき、Bedrockで異なるfoundation modelに実際にアクセスし、そしてGlueも使います。Glueはスキーマ情報を取得するのに役立つので、クエリを構築できます。

ここではBedrockモデルを定義しています。ここで最も強力なポイントの1つは、エージェントに使用したいモデルをたった1行のコードで定義できることだと思います。Claude Opus 4.5はおそらく1、2週間前に出たばかりですが、1行のコードを変更するだけで、別のfoundation modelに置き換えることができました。そして繰り返しになりますが、考えたいことの1つは、エージェントとそのタスクの複雑さに応じて、使用したいモデルを調整したい場合があるということです。レイテンシーについて考えたいですし、コストについても考えたいです。metadataエージェントについて考えると、DynamoDBテーブルを作成するだけです。かなりシンプルなタスクで、そこではあまり多くのことは起こっていません。その場合、例えばHaikuのような、より高速で安価な軽量モデルを使用できます。このような、自然言語を見て、スキーマを検索し、実際のクエリを作成し、データを取得し、そしてアクティビティ間の相関関係を作成する必要があるものには、より高度で能力の高いものを使用したいです。その場合、Claude Opus 4.5を使用することになります。

では、実際にツールを定義していきましょう。さて、どのようなツールが、Security Lakeエージェントのために私のエージェントがアクセスする必要があるか、分かる方はいますか?間違った答えはありません、ここにヒントがあります。誰かを指名しないといけませんね。データをクエリするにはどうすればいいですか?それをクエリする最良の方法は何ですか?何ですか?Athena?Athena、はい、それが必要なツールの1つです。エージェントが実際にAmazon Athenaを使用するためのツールを作成する必要があります。それがここでやっていることです。

では、コンテキストについて説明します。ご覧のとおり、すべてのツールにはこのメタデータの説明が付いています。これは、この情報をモデルに渡すためです。モデルは、Athenaを使ってSecurity Lakeにクエリを実行できるツールがあることを認識していて、必要な引数はこれを実行するためのSQLクエリだけです。そして、これが返り値ですね。結果を文字列テーブルとして返すか、Security Lakeから何も返ってこなかった場合はエラーメッセージを返します。ここではAmazon Athenaに接続していて、Athenaデータベースは既に上の方で定義済みなので、Athenaに接続しています。そして実際に、Athenaに属するユニークなクエリ実行IDを取得します。これが実行されて、Amazon Athenaの結果を実際に取り込んでいきます。これが1つ目のツールです。

1つ目のツールは実際にクエリを実行するものです。では、2つ目のツールが何をするか、誰か分かりますか？画面にヒントが出ていますね。2つ目のツールは実際にテーブルをリストアップするものです。なぜなら、エージェントはどのようなデータソースがあるのか分からないからです。

VPC Flow Logsかもしれませんし、CloudTrail、Security Hubかもしれません。あるいは、他のサードパーティプロバイダーやセキュリティサービスを使っている場合は、独自のテーブルもあるかもしれません。これがSecurity Lakeを非常に強力にしている理由です。正規化された標準化されたデータフォーマットが1つあるので、エージェントはクエリを変更する必要がありません。統一された1つのアプローチ方法があるのです。

最後に、get table schemaがあります。これはGlue Data Catalogからスキーマ情報を取得します。エージェントはスキーマを取得する必要があります。カラム情報とデータのパーティション方法を確認して、それに基づいて、Amazon Athenaに対して実行できるクエリを実際に作成できるのです。ここで3つのツールを定義しています。これを実行します。

さて、ツールを定義した後は、用意しているAgentクラスを呼び出します。繰り返しになりますが、Shawnが言ったように、エージェントには3つのコアコンポーネントがあります。使用したいBedrockモデル、または任意のモデルが必要です。Bedrockだけに縛られる必要はありません。OpenAIや他のファウンデーションモデルを使いたい場合は、自由に使ってください。それから、このエージェントがアクセスできる様々なツールを定義します。非常に重要なコンポーネントだと思うのですが、エージェントについて多くの人が見落としがちなのが、システムプロンプトです。

システムプロンプトは基本的にエージェントのペルソナ、つまり性格を定義するものです。このケースでは、あなたがAWS Security Lakeへのアクセス権を持つサイバーセキュリティアナリストであることを認識させています。重要なデータベースのコンテキストを与えていますが、ここで注目していただきたいのは、ワークフローも与えているということです。実際のところ、エージェントはエージェンティックループを通じてワークフローを自分で見つけ出すことができます。しかし、このケースでは実際のクエリを生成するための良い方法が一つあって、それはテーブルをリストアップし、スキーマを取得し、そして実際のデータとスキーマに基づいてクエリを構築するというものです。これが私が定義する一つのワークフローです。

エージェントを構築する際にやりたいことの一つは、時々何かを実行するのに2回から3回の反復処理を行っていることに気づくと思います。プロンプトの中で直接情報を伝えることができれば、通常かかるレイテンシーや余分なトークンの多くを削減できます。アウトプットに関しては、具体的な修復手順を提供するように指示しています。データドリブンなインサイトと、リスクアセスメントを含む主要な発見事項が欲しいわけです。

以上です。これらの異なるツールを使ってSecurity Lakeエージェントを定義しました。最初にテストしたいプロンプトは、「私のSecurity Lakeにはどんな種類のデータがあるのか？」です。それでは実行してみましょう。ご覧のとおり、最初に行うのはSecurity Lakeのテーブルをリストアップすることです。3つの異なるテーブルがあることがわかったので、全体像を把握するためにスキーマと詳細を取得しましょう。

実行されると、ご覧のように3つの異なる実行が行われ、各テーブルに対して1回のツール呼び出しが行われ、その情報を取得します。そして、CloudTrailイベントがあることを教えてくれます。これにはAPI活動、ユーザーロール、認証情報、ソースAPIコールが含まれています。Security Hubの検出結果も同様で、これらの特定の検出結果に通常含まれるすべてのもの、脆弱性、修復ガイダンス、コンプライアンスステータスなどを教えてくれます。VPC Flow Logsも同じ方法です。はい、こんな感じです。

SOC Orchestrator Agent：マルチエージェントアーキテクチャによる包括的なセキュリティレポート生成

さて、このSecurity Lakeエージェントを構築したので、次は複数のエージェントを一緒に使用できるようにスーパーバイザーエージェントを実際に構築する方法を見ていきましょう。次のステップとして、このログ分析エージェントがあります。これは入ってくる異なるイベントやエージェントとのインタラクションに基づいて独自のSQLクエリを生成し、結果を返すことができます。また、メタデータエージェントもあります。では、これら2つを実際にマルチエージェントアーキテクチャで連携させるにはどうすればよいのでしょうか？

最初にお話ししたときに、コミュニティによって作成されたネイティブツールについて触れました。この特定のエージェントで使用したい2つのツールは、file writeです。これは、エージェントに実際にコンピュータにファイルを書き込む能力を与えるものです。もう1つはcurrent timeです。つまり、昨日起こったイベントについて教えてくださいといった特定のクエリがある場合、これはネイティブツールです。繰り返しになりますが、これらのためにロジックを書く必要はありません。すでに組み込まれているので、Strands toolsクラスからインポートするだけでいいんです。ということで、この2つをインポートします。

Shawnが説明したこのmetadataエージェントは別のノートブックで定義されていたので、この特定のノートブックがエージェントを認識できるように、ここで再定義します。実際に複数のツールをどのように定義するか見てみましょう。この例でやっている方法は、エージェントをツールとして定義することです。

あのagenticループを思い出してください。SOC Orchestrator Agentは今、タスクを完了するために使用できる異なるエージェントにアクセスできるようになっています。つまりこの場合、私がやっているのは、Security Lake agentをツールの1つとして定義することだけです。そのロジックは、アクセスできる異なるツールやそのペルソナに関して、すでに上で定義されているので、ここではスーパーバイザーエージェントが何にアクセスできるかを知るためのコンテキストを提供するだけでいいんです。get AWS account metadataも同じです。メタデータを定義して、IDが間違っている場合に備えてエラーハンドリングを入れておきます。

そしてここで再び、agentクラスをインポートして、異なるツールを定義しています。この場合、Strandsにネイティブな2つのネイティブツールと、実際のエージェントである2つの異なるツールがあります。ここでも重要なのは、パーソナリティ、ペルソナ、つまりシステムプロンプトです。エージェントを構築し始めるとき、私が強くお勧めすることの1つは、異なるプロンプトを試してみることです。そうすると、まったく異なる結果が得られるのがわかるでしょう。この場合、investigation workflowを定義しています。メタデータを取得し、Security Lake agentを使ってfindings overviewを見つけ、CloudTrail network IP analysisを取得し、そして最後にセキュリティチームに送信されるレポートを生成してほしいと指示しています。利用可能なツールのリストを与え、そしてアウトプットも指定しました。account contextのcriticality、account summary、利用可能なデータに基づくrisk assessment、そしてrecommended actionsが欲しいです。そして、手動調査が必要なデータギャップがある場合、エージェントが実際に何らかのremediation planを提供するために必要なコンテキストや推論をすべて持っていないこともあるので、環境内にどのようなデータギャップがあるかを教えてくれることができます。

そこで、file writeのような異なるネイティブツールを使用する場合、Strandsはそれを実際にコンピュータに書き込む機密操作と見なします。通常、invocationの途中で、コンピュータに書き込んでもいいかどうかの同意を求められます。この場合、エージェントは自律的です。途中で止まって、この特定のツールを呼び出してもいいですか、と知らせてほしくないんです。なので、これを実行して、ツールの同意をバイパスするように指示します。人間のループの許可なしに、好きなツールを使用することが許可されています。

それでは、今構築したばかりのSOC Orchestrator Agentを実際に使ってみましょう。このアカウントIDが侵害されています。懸念すべき影響を受けたリソースは何でしょうか？これを実行すると、私とSeanは実際に過去2、3ヶ月間、ほぼ毎分60件のイベントでSecurity Lakeにデータを投入してきました。つまり、そこには大量のログがあるわけですが、それでも非常に良好なパフォーマンスを発揮しています。そして実際に異なるデータソースへのクエリを開始し、スキーマを取得していきます。これはおそらく完了まで1、2分ほどかかるので、昨夜生成したレポートをお見せします。

ホームに戻って、すべてのレポートを見てみましょう。ここに、生成した様々なレポートがあります。4時間前のものを見てみましょう。これが私が生成したレポートです。アカウントIDが表示され、ビジネスコンテキストに基づいて、これが本番アカウントであることが記載されています。つまり、非常に重要な環境です。P1優先度で、クリティカルであり、サマリーが表示されます。このアカウントには機密情報、PCI情報があり、アクティブな侵害が発生しています。即座の封じ込めが必要です。すべてのコンテキスト、その特定のAWSアカウント内のセキュリティ連絡先が表示されます。

エグゼクティブサマリーがこちらです。私とSeanは間違いなく困った状況です。このアカウント内に18,000件を超えるセキュリティファインディングがあるので、確実に多くの作業が必要です。繰り返しになりますが、私たちはSecurity Lakeに大量の異なるイベントを送り込んできました。そしてここで詳細が分類されています。S3バケット、IAMユーザー、EC2インスタンス、変更されたセキュリティグループに859件のクリティカルがあり、リスクが示されています。データ露出、IAMユーザー、侵害されて使用された認証情報があります。攻撃分析、送信元IP、どのユーザーが侵害されたか、そしてVPCトラフィックも表示されています。

こちらです。発生している様々なAPI操作です。そのユーザーはセキュリティグループを作成し、セキュリティグループを削除し、既存のセキュリティグループ内の特定のポートを承認しています。そして実際に必要な即座のアクションが列挙されています。すべての認証情報、特に管理者IAMを直ちにローテートしてください。そして、即座のアクションが必要なクリティカルなもの、短期的なアクション、そしてコンプライアンス影響評価に関する詳細情報が示されています。それでは、サポートが生成されたか見てみましょう。

まだ処理中ですね。ここに戻ってくることができますが、おそらくあと1分ほどかかります。では、次のスライドに進みましょう。エージェントコードができて、書き出して、正常に動作していることを確認し、Jupyter notebooks内でテストして達成したいことができるようになりました。次の大きな疑問は、これを本番環境でどのように実行するかということです。これが私たちが目にしている重要なポイントの一つです。

AgentCore Runtime：本番環境でのエージェント実行とスケーラビリティ

そしてこれがAgentCore Runtimeです。 これは数ヶ月前にリリースされたマネージドサービスで、AIエージェントのコードを実行できるようになっており、基盤となるインフラストラクチャを気にする必要がありません。つまりこの場合、Strands SDKを使用できますし、OpenAI、Gemini、またはBedrockにある多数のモデルのいずれかなど、お好きな基盤モデルを使用できます。フレームワークについても同様ですよね。LangGraphやCrewAIに慣れている場合は、Strands SDKを使う必要はありません。すでにそれらを使用している場合は、自由に使っていただけます。

では何が起こるかというと、例えば私が持っているこのPythonファイルがあるとします。できることは、Dockerfileでコンテナ化するか、コードをそのままAgentCoreにアップロードすれば、パッケージングとホスティングを行ってくれます。ここで起こることは、AgentCore Runtimeがランタイムエンドポイントを作成し、これが冒頭でお見せしたフロントエンドアプリケーションに統合されているエンドポイントです。すべてのプロンプトをこのエンドポイントに送信しており、エンドポイントは実際に需要に基づいてコンピューティングリソースの量をスケールアップできるんです。つまり、実際のインシデント時に多くのユーザーが入ってきて使用している場合、スケールアップでき、デフォルトでスケールダウンもできます。

また、アイデンティティを通じた統合や、オブザーバビリティの設定、さらに異なるMCPサーバーを統合したい場合など、多くの優れた統合機能があります。クラウド運用を自動化するCloud Control MCPサーバーについて話しましたよね。これらのMCPサーバーをまだチェックしていない方は、ぜひ強くお勧めします。エージェントにアクセス権を与えることができる様々な機能が示されています。何か質問はありますか？はい。

質疑応答：自動化の価値、認証、インフラストラクチャアズコードとの統合

理解しています。ええ、ご質問は、これらのサービスやツールをたくさん使っているのに、セキュリティエージェントを使う価値は何か、ということですね。基本的に、どんな利点が得られるのか？現在自動化されているのか？なるほど、ええ、つまり自動化を設定する複雑さという点で、セキュリティ検出結果の修復を自動化しているのか？ええ、これらすべてを誰が行っているのか？ええ、何か見落としていますね。いえいえ、確かに良い懸念点です。よろしければ、後で話しましょう。使用しているツールや、やっていること、そしてこれが全体的にどう適合するかについて、もっと探求したいと思います。いくつか質問したいことがあります。ええ、質問ありがとうございます。

他に質問はありますか？はい。レジストリ仕様について、これはツールの登録に関連しているのでしょうか、それとも何に関連していますか？現在使用していますか？現在のセットアップでレジストリを使用していますか？なぜなら、エージェントへの認証を許可しようとしているからです。これについて統一的なアプローチが必要だとしましょう。ええ、ええ、AgentCoreについては、この特定のスライドにはありませんが、AgentCore Identityというコアコンポーネント、機能もあり、その領域内でエージェントの異なるアクセスと認証を統一できる場所です。よろしければ、トークの後でそれがどのように機能するか、高レベルで深く掘り下げることができます、ええ。

はい、この方向で進めて、それから戻ってきます。それで、クラウドにおいては、エージェントがTerraformのようなインフラ環境と最新の状態を保つことを確実にするということですか？つまり、例えば、どこかに環境があって、セキュリティポスチャを変更するイベントが発生したとします。その2つの状態を調整したいんです。ああ、なるほど、実際の状態を反映させるということですね。ええ、この環境ではどう考えればいいでしょうか？ええ、それは本番環境の変更について、エージェントの現在の状態とその動作方法において、私が推奨することの1つです。それは、人間をループに入れることを検討する場面の1つで、さまざまな変更と推奨事項を確認してから、環境内で手動で自分で実装するということです。

それに関しては、まだ人間をループに入れる必要性があります。なぜなら、自動修復が知らないうちに行われるのは望ましくないからです。わかりますよね？そして、それを調整しなければならなくなります。ええ、そこに向かっています。うまくいけば来年にはスタック全体を自動化できるかもしれませんが、現時点では、どのような変更が必要かという推奨事項を受け取り、実際にTerraformコードをフィードすることができます。Terraformコードを確認してから、それをフィードしてメインのコードリポジトリにアップロードし、それを同期させることができます。

ええ、そのエージェントに同じCSCDプロセスを実行させることはできますか？できますね、そうすればドリフトは発生しません。なぜなら、エージェントがあなたが使っているのと同じ方法でTerraformを使用するからです。まさにその通りです、ええ、つまり、全体的なソリューションの一部として、その特定の環境で開発し、作業することに特化したエージェントを持つことができます。その通りです、それも別の選択肢ですね。ええ、こちらに質問がありました。ありがとうございます。Security Lakeに、またはSecurity Lake以外の他のソースと？それについては確認する必要があります。後でお話しして、使用しようとしている他のソースについて確認させてください。ほとんどのリソースについては、人々がSecurity Lake内に集中化していることは知っていますが、それらを別々に保ちたい理由は何かありますか？Security Lakeです。すみません、あなたは？わかりました。Marksさんですね。了解しました。それについては確認して、後でお答えします。何か言いたいことがありましたか？いいえ、後で彼と話します。聞こえませんでした。

では要約すると、現時点では、こう言うべきでしょうか？ええ、現時点では監視だけでなく、相関分析も行うということだと思います。例えば、異なるデータソース間をジャンプしたり、SQLクエリを実行したり、削除された特定のセキュリティグループと特定のIPとの相関関係を実際に調べたりすることです。つまり、その手作業プロセスの多くの地道な作業は、確実に自動化できます。そして、実際にインフラストラクチャアズコードを自動化してデプロイすることに関しても、それはCloud MCPサーバーが実際にアクセスできるものですよね？Terraformを書いて、実際にそれを実行できますが、繰り返しになりますが、現時点では、あなたがおっしゃるように、実際に何をしているのかを確認せずにエージェントに本番環境の変更を実行させることには、十分な自信が持てません。素晴らしい。まとめましょうか？ええ、ええ。

まとめとリソース紹介：StrandsスタートガイドとAWS Skill Builder

それでは、これらのいくつかが会場の皆さんにとって有用だったことを願っています。左側にはStrandsのスタートガイドがあります。これは、このようなものを自分の環境でテストしたい場合に、Strandsで実験を構築するために必要なすべてのドキュメントとすべてのものです。実際に手を動かして試してみることを強くお勧めします。また、StrandsエージェントをAmazon Bedrock AgentCore Runtimeにデプロイすることに興味がある方は、右側のQRコードをスキャンしてください。これにより、自分のAWS環境でこれをテストするための運用可能な機能が提供されます。始めるために必要なものはすべてそこにあります。

そして最後に皆さんにお伝えしたいことがあります。もしまだAWS Skill Builderについて聞いたことがない方、クラウドが初めての方、AWSが初めての方、あるいはもっと実践的な経験を積んで自分のスキルを高めたい方、私たちは何千もの無料の学習リソース、ハンズオンラボ、実際の状況を再現した没入型の環境を用意しており、そこでこれらのことを構築する経験を得ることができます。AWS認定資格の取得を目指していて、その勉強のための追加ツールが必要な場合も、私たちのサイトで利用可能です。そして、ご自身やチームのために実践的なスキルを検証するためのマイクロクレデンシャルが必要な場合も、それもAWS Skill Builderで利用可能です。

それでは、本日ご参加いただき誠にありがとうございました。ご質問がある方は、ありがとうございます。素晴らしかったですよOmar。ご質問がある方は、この後10分間ここにおりますので、お気軽にお立ち寄りください。ぜひお話ししたいと思います。もしご質問にお答えできなかった方、お話しできなかった方がいらっしゃいましたら、どうぞお残りください。ぜひお話ししたいと思います。皆さん、re:Inventの残りの時間をお楽しみください。ありがとうございました。ありがとうございました。

---

※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。