re:Invent 2025: Generative AIで通信事業者のサイバーセキュリティ運用を効率化
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖re:Invent 2025: AWS re:Invent 2025 - Streamlining Telecom Cybersecurity Operations with AWS Generative AI (IND206)
この動画では、AWSのソリューションアーキテクトであるAnwar AliとRayが、Generative AIを活用した通信事業者のサイバーセキュリティオペレーション効率化について解説しています。通信事業者が直面する課題として、複数の場所に分散した膨大なログの分析、非標準フォーマット、相関の困難さが挙げられます。解決策として、Amazon Bedrock Agent Core上に構築されたAgentic AIとAmazon Security Lakeを組み合わせたアーキテクチャを提案し、Zscaler、Checkpoint、Illumioなどのログソースから自然言語クエリで根本原因を特定するデモを実施しました。このソリューションにより、インシデント解決時間が数時間から数分に短縮され、セルフサービスエージェントとしての展開も可能になります。Amazon Bedrock Agent Core Gatewayを使用することで、わずか4行のコードでエージェントを本番環境にスケールアップできる点が強調されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
通信事業者が直面するネットワークセキュリティログ分析の課題
Lightning Talkセッション「Generative AIによる通信事業者のサイバーセキュリティオペレーションの効率化」へようこそ。私はAnwar Aliです。本セッションの司会を務めさせていただきます。 Rayと共同でプレゼンテーションを行います。私たちは二人ともAWSでソリューションアーキテクトとして働いています。 それでは、このlightning talkで取り上げる内容の大まかなアジェンダです。通信事業者がネットワークセキュリティログを分析する際に直面する一般的な課題を見ていきます。特に、インシデントやセキュリティイベントが発生した場合のブロックされたユーザーリクエストの診断に焦点を当て、Agentic AIがセキュリティアナリストの問題解決をいかに迅速化できるかについてお話しします。興味深いデモがありまして、それはRayが担当します。また、彼はソリューションアーキテクチャと、このagenticアーキテクチャをどのように構築したかについても説明します。
さて、通信事業者やコミュニケーションサービスプロバイダーは、セキュリティ攻撃の増加に直面しています。彼らは常にサイバーセキュリティの脅威の増加に直面しており、厳格な規制基準の下で運営されています。セキュリティアーキテクチャを常に進化させる必要があるのです。結果として、多くの監視およびセキュリティ制御ツールを追加してきましたが、それがこれらの通信ネットワークの管理に多くの複雑さを加えています。そのため、セキュリティイベントが発生した際に、これらの特定のログを診断し、迅速に根本原因を見つけ出すことは、非常に困難で時間のかかる作業となっています。
ここでは、ユーザーが内部アプリケーションに接続する代表的なフローを示しています。これは非常にシンプルなフローです。通過するさまざまなネットワークセキュリティツールを見ることができます。相互接続されたさまざまなネットワークセグメントがあります。これはフローの1つの非常にシンプルな表現ですが、実際のネットワークでは、このようなリクエストが何百万も存在します。ユーザーからアプリケーションへの接続があります。異なるネットワークセグメント間でのアプリケーション間の接続もあります。そして、その間にさまざまなネットワーク監視およびセキュリティオペレーションツールがあります。そして、これらすべてのツールがログを出力しています。 そのため、セキュリティインシデントが発生すると、これらのログを診断することは非常に時間がかかり、エラーが発生しやすくなります。私たちが話しているagenticソリューションは、まさにこのケースで役立つものです。そして、私たちが焦点を当てている2つのユースケースがあります。正規のユーザーが通信ネットワーク上でアプリケーションにアクセスする際にブロックされるユースケースですが、セキュリティ分析診断にも拡張できます。それでは、この背景を踏まえて、ログを分析する際に直面する一般的な課題を見ていきましょう。
ログは非常に冗長です。その中には多くの情報があります。さて、これらすべてのセキュリティおよびネットワークツールがログを出力しています。それらは複数の場所に存在します。AWSクラウド上にあります。リージョンをまたいでいます。サードパーティのクラウド上、オンプレミス上にもあります。そして、これらのログは標準フォーマットではありません。多くのツールが独自フォーマットでログを出力しています。これらの特定のログを相関させるのに役立つ標準的な規約がありません。このため、非常に時間がかかり、面倒になります。
ログの量は膨大です。ログを保存するだけでも、多くの大企業は1日あたりテラバイト単位でログを出力しています。それが量の規模です。大企業でさえ、それが私たちが話している量なのです。これらの特定のログを保存し、処理し、分析ツールでこれらのログをクエリすることは、極めてコスト的に高くつきます。極めて困難になります。
そして最後になりますが、非常に重要なのは、これらのログを相関させることが難しいということです。これらのソリューションの多くは、独自形式でログを提供していたり、特定のクエリツールのみがサポートされていたりします。そのため、セキュリティアナリストは、これらの特定のログを学習して取得する必要があります。インシデントが発生したときのシナリオを見てみましょう。エンドユーザーがネットワークリクエストでブロックされます。開発者がブロックされます。彼はサイバーセキュリティチームにチケットを起票します。サイバーセキュリティチームの誰か、セキュリティアナリストが、すべてのログを確認し、それを理解しようとしますが、これは非常に煩雑で困難なプロセスになります。ですので、私は1つのフローをお見せしましたが、実際には多くの異なるフローが存在する可能性があります。
実際のネットワークでは複数のフローが発生する可能性があり、先ほど申し上げたように、アプリケーション間の接続や相互接続されたネットワークが存在します。通信事業者のネットワークにアクセスするユーザーもいます。また、その間には様々なセキュリティコンポーネントやネットワークコンポーネントも存在します。
Agentic AIとAmazon Security Lakeによる解決アプローチ
それでは、Agentic AIとAmazon Security Lakeがこれをどのように軽減できるかを見ていきましょう。右側に表示されているセキュリティアナリストは、ネットワークトレースエキスパートアシスタントを使用できます。これは、セキュリティアナリストがログを診断するのを支援できる仮想アシスタントに他なりません。簡単に言えば、チャットボットです。バックエンドでは、エージェント、Bedrock Agentic AIを持っています。これはBedrock Agent Core上に構築されたエージェントによって動作しており、これらの特定のエージェントは2つのことを機能して実行しています。1つは、様々なソースからログを取得し、これらの特定のログを相関させて分析するのを支援できることです。そして、ご存知のように、エージェントは推論能力も持っているため、この特定の問題の根本原因を診断して見つけ出すのを支援できます。
全体として、Agentic AIはあなたの友人になることができます。ログの診断を支援してくれます。数分以内に達成できることが、以前は数時間かけても達成できないこともありました。もう1つのベストプラクティスは、これらの特定のログを集中管理されたAmazon Security Lakeに保存することです。Amazon Security Lakeは、これらの特定のログを中央の場所に保存するのに役立ちます。また、Open Cybersecurity Schema Frameworkもサポートしています。これは、AIエージェントや他の分析ツールがこれらの特定のログを効率的にクエリするのに役立つ標準フォーマットです。また、これらのログをIcebergに非常に効率的な方法で保存するためのライフサイクル管理ポリシーの管理にも役立ち、クエリと処理が容易になります。
Amazon Security Lakeは、このAgenticアーキテクチャが機能するための前提条件ではありませんが、ベストプラクティスです。そのため、アーキテクチャでは組み合わせて使用しています。もう1つは、この特定のツールの成熟度が高まるにつれて、この特定のネットワークトレースエキスパートアシスタントをセルフサービスエージェントとしてユーザーに提供することさえできます。それでは、Rayをお呼びして、これらの特定のエージェントをどのように構築したかのアーキテクチャについて、詳細な説明とウォークスルーをしていただきたいと思います。
Amazon Bedrock Agent Coreを活用したアーキテクチャとデモンストレーション
ありがとうございます、Anwar。それでは、アーキテクチャについて少しお話しします。簡単なデモを行い、その後、ソリューションのメリットについてお話しします。左側から始めますが、このアプリケーションとやり取りする可能性のあるペルソナが確認できます。主に、セキュリティアナリストを挙げていますね。これは、現在これらのログを手動で確認している人です。このケースで彼らが行っているのは、実際には私たちのgenerative AIエージェントとやり取りすることです。このエージェントはAmazon Bedrock Agent Core Runtime上で動作しており、これはgenerative AIエージェント向けに特別に構築されたランタイム環境です。独自のフレームワークを持ち込むことができ、独自のモデルを持ち込むこともできます。このケースでは、Strands SDKで構築し、Amazon Bedrockで利用可能なモデル、Claude 3.7 Sonnetを使用しています。
エージェントは、もちろん、必要な情報を取得するために使用できるツールと同じくらい価値があります。そのため、実際にAmazon Bedrock Agent Core GatewayをMCPゲートウェイとして使用し、それらのツールをエージェントに公開しています。エージェントが最初にゲートウェイに認証する際、JWTを提示し、そのJWTはAmazon Bedrock Agent Core Identityによって、私たちが選択したIDP、このケースでは単にAmazon Cognitoですが、そこには何でも使用できます、つまりOktaやEntra IDを使用することもできますし、自由に入れ替えることができます。
さて、ゲートウェイについてですが、最初に起こることは、エージェントが初期化される際、実際にlist tool sync callを実行して、現在のツール情報を取得することです。これは、呼び出すことができるさまざまなツールのスキーマ、つまり渡す必要があるパラメータが何かということです。その後、エージェントは、持っているツール、ベースプロンプティング、そしてユーザーからの入力に基づいて合理化を行います。そのモデルを使用し、ツールを呼び出すことを決定し、Amazon Bedrock Agent Core Gatewayを通じて呼び出しを行います。これはMCP callですが、これらの呼び出しは実際にツールを実装するLambda関数に送られます。
このケースでは、Lambda関数は私たちのさまざまなログソースに接続します。デモのために、ここに3つリストアップしているのが確認できます。Zscaler、Checkpoint、そしてIllumioです。しかし、明確にしておきたいのですが、ログをどこでホストしていても、S3でも他の場所でも、場合によっては別のクラウドでも、それはサポートできるものです。そのログソースに接続し、エージェントを使用して多くの異なるソース間でトラブルシューティングを行うことができます。
それでは、ここで簡単なデモを見てみましょう。シナリオをご説明します。
それでは、David LeeはAcme Telecomの従業員で、Acmeのノートパソコンから自宅のインターネット経由でbillingアプリサービスにアクセスしようとした際に、セキュリティブロックに遭遇しました。それでは、このデモのために私が作成した簡単なフロントエンドをお見せします。ここでは自然言語クエリを入力しようとしています。では実行してみましょう。さあ、どうぞ。
自然言語クエリを入力して、それをエージェントに渡しています。エージェントはもちろんAmazon Bedrock Agent Coreランタイムでホストされており、現在エージェントはそのインシデントをトラブルシューティングしているところです。つまり、Agent Core gatewayに接続し、認証を行い、ツールをリストアップして、それらの3つのツールを使ってインシデントをトラブルシューティングします。この特定の呼び出しについて指摘しておきたいのは、私たちはある種の一般的なトラブルシューティングを依頼しているということです。つまり、実行する可能性のある特定のクエリや参照するソースについて具体的な指示を与えていません。ですから、このシナリオでは実際に3つのデータソースすべてをチェックすることになります。
しかし、これはチャットボット形式なので、実際に選択的に、つまり、もし私がフォローアップの質問をした場合、個別のデータソースを具体的に呼び出すことができるんです。ご覧のように、ここでレポートが生成されました。発見事項のサマリーがあり、このタイムスタンプでブロックされたトラフィックを特定しており、詳細なログ分析を提供してくれています。まずCheckpointから、次にIllumio segmentationログで、ここで実際にブロックされたトラフィックが見つかりました。そして最後にZscalerログです。
そして、この種の最終的な結論を生成しており、完全なトラフィックフローを順を追って説明してくれています。Zscaler Private Accessへの認証に成功しました。Elasticsearchへの接続を確立しました。最初の接続はZscaler Private AccessとCheckpointの両方で許可されましたが、Elasticsearchインスタンスへの接続の後続の試みが、3番目で最後のネットワークファイアウォールによってブロックされました。これがこのソリューションがどのように機能するかの簡単なデモです。
そして実際に、ここでコードについて少しお話ししたいと思います。それがいつもより楽しいですからね。少し読みにくいのは承知しています、申し訳ありません。おそらくここのプロンプティングは読めないと思いますが、これは本当に重要だと思うので含めたかったんです。ここでのプロンプティングは、エージェントがこれらのツールをどのように呼び出すべきかを指示するものです。お気づきのように、基本的な、つまり、あなたはアナリストであり、ユーザーに対して敬意を持って接するべきだ、といったものに加えて、実際に各ログソースのスキーマに関する情報があり、これによってエージェントは、あらゆるインシデントのトラブルシューティングに使用するクエリを動的に書くことができるんです。
それで、私たちが実行したシナリオは少し基本的なものでしたよね。単にこのインシデントをトラブルシューティングするという、より一般的なものでした。しかし、フォローアップの質問をした場合、つまり特定のデータソースに対して特定のクエリを実際に作成する必要がある場合、エージェントはこれらの各ログソースのスキーマに関する知識を使用して、それらのクエリを作成し、適切なツールを呼び出すことができます。また、画面の右上にあるAmazon Bedrockのモデルにアクセスしていることにもお気づきでしょう。これが私たちがClaude 3.7 Sonnetに接続している方法です。
そして、私たちのツールにアクセスするために、Agent Coreゲートウェイに接続しています。つまり、MCPクライアントを確立しているわけです。これはストリーム可能なHTTP MCPクライアントで、ゲートウェイURLに接続しています。これは渡されているもので、そこに渡している青い変数です。また、ベアラートークンも渡しています。これはゲートウェイに認証する際にAgent Core identityによって検証されるJWTです。
最後に、いくつか指摘しておきたいのですが、これらは追加する必要がある行のうちの2つに過ぎません。StrandsやLangGraph、LangChain、CrewAIなど、私たちがサポートしているフレームワークのいずれかで構築されたエージェントを使用する場合、合計で4行あります。Agent Coreランタイム上でそれらを実行しようとする場合、4行のコードを追加するだけで済みます。そのうちの2行がここに表示されています。最初にローカルで実行するかもしれないエージェントを取り上げて、それをAgent Coreにプッシュアップし、数百の同時リクエストまでスケールアップすることが、いかに簡単かを強調したかったのです。
ソリューションがもたらす価値と実装における重要な学び
さて、Anwar、このソリューションの価値について少し教えていただけますか？ええ、ありがとうございます、Ali。私たちが発見したのは、この特定のソリューションを採用している組織には複数のメリットがあるということです。まず第一に、インシデントの検出と解決時間が速くなることです。先ほど申し上げたように、セキュリティオペレーションチームにとって、特に新しいチームメンバーがいる場合や、チームがかなり手一杯だった場合、この特定のソリューションによって問題をより速く解決できるようになりました。以前は数時間かかっていたものが、今では数分以内に収まるようになり、チームの生産性向上に役立っています。
2つ目は、一部の組織では、内部ユーザー向けのセルフサービスエージェントとして展開しているところもあります。それにより、チケットに存在する情報、つまりエンドユーザー自身がクエリできる情報があり、内部ユーザーはこの特定のツールを使用して、特定のネットワークブロックがどこにあるかを特定できます。
開発者自身が問題を診断できるようになり、サポートチケットを起票する際も、より迅速に対応できるようになります。そしてチケットの量も削減されました。より速くなり、さらにコラボレーションの向上にも役立っています。つまり、開発チームとセキュリティオペレーションチームがより良い方法でコミュニケーションを取れるようになったのです。
多くの場合、開発者が問題を起票しても、セキュリティオペレーションチームは人手が足りず、数日以内に解決することができませんでした。そのため、開発者の生産性も低下していたのです。この特定のツールを使うことで、組織内の開発における俊敏性が向上しました。そして先ほど申し上げたように、エージェント自身がクエリを書くため、自然言語のクエリでチャットボットとやり取りができ、複雑なクエリやツールを学ぶ必要がありません。ですから、これらの多くの課題を軽減するという点で非常に有用なのです。
では、このソリューションを構築する際の主な学びと要点は何でしょうか。ありがとうございます。このソリューションから強調したい重要なポイントがいくつかあります。まず一つ目は、この特定のユースケースにおけるAWS上のgenerative AIの力です。Bedrock SDKを使って構築することで、インシデントの解決時間を劇的に短縮することができました。本当に数時間から数分へと短縮できたのです。以前は、セキュリティアナリストがログを精査し、様々なログソースを横断して理解する必要がありましたが、今ではエージェントがセキュリティアナリストに代わってそうした差別化されない重労働の一部を行い、インシデントの根本原因をより早く見つけられるよう支援しています。
二つ目に指摘したいのは、Amazon Bedrock Agent Core Runtimeが、このエージェントを本番環境に投入するまでの時間を劇的に短縮できるということです。私は最初、自分のコンピューター上でローカルに構築を始め、わずか4行のコードを追加するだけで、エージェントをAgent Core Runtimeにプッシュし、数分でスケールアップすることができました。これは強調する価値があると思います。
三つ目は、crawl、walk、runのアプローチです。私たちは、セキュリティアナリストがエージェントとやり取りするポータルから始めました。walkのステップとしては、実際にセルフサービスポータルを用意して、個人がネットワークブロックに遭遇した際に、エージェントとやり取りして根本原因を見つけ、現在ブロックしているポリシーの変更を希望する場合にのみチケットを提出すればよいようにすることができると思います。これにより、セキュリティアナリストが現在行わなければならない重労働の一部が削減されます。
そして、この最後の実行面では、同じインターフェースと同じエージェントを使って、実際に危険なセキュリティインシデントを調査することもできます。例えば、多数の失敗したリクエストがあった場合、それはシステムに対して悪意のある攻撃者が活動していた可能性を示しているかもしれません。ここでは、同じシステムを使って多くの異なるタイムスタンプを調べ、何がそれをブロックしたのか、あるいはブロックされなかった場合は何がブロックすべきだったのかを特定する機会があります。
Amazon Security Lakeについて指摘しておきたいのですが、私たちはこれを使ってすべてのログソースに関するセキュリティ態勢を一元化しています。これはここでも良い実践方法です。もちろん、私たちはS3とOpenSearchを使用しましたが、これは明らかにAmazon Security Lakeで保護できるものです。しかし、他の場所から独自のログソースを持ち込む場合も、Amazon Security Lakeを使用することができます。
そして、これは私が本当に強調したかった最後のポイントにつながると思うのですが、それはAmazon Bedrock Agent Core Gatewayのパワーです。私たちはAWS上で実行されている3つのログソースだけを紹介しました。しかし、皆さんのログソースがすべてAWS上にあると期待するのは現実的ではないと思います。例えば、オンプレミスにログがあるかもしれません。他のプロバイダーにログがあるかもしれません。Agent Core Gatewayのパワーは、ログが蓄積されている場所でMCPサーバーをホストすれば、Agent Core Gateway経由で接続できるということです。なぜなら、REST APIタイプやこのデモで使用していたLambdaターゲットだけでなく、MCPサーバーターゲットタイプもサポートしているからです。そして、それをゲートウェイに接続して、エージェントがトラブルシューティングプロセスでそのMCPサーバーを使用できるようにすることができます。
それでは、今日お話ししたかったことは以上です。お時間をいただき本当にありがとうございました。また、このスライドも入れておきたいと思います。スキルをレベルアップしてSkillBuilderを始めたい方は、今日から始めることができます。このQRコードをしばらく表示しておきますね。お時間をいただき本当にありがとうございました。そして、もしよろしければ、AWS Eventsアプリの中にセッションサーベイがありますので、ご記入いただけると大変助かります。皆さん、ありがとうございました。マイクの準備ができ次第、こちらでご質問をお受けいたします。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion