re:Invent 2025: Discussion Control PlaneによるAIチームメイトを活用した運用の再定義
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - The AI Discussion Control Plane: How Your Agentic Team Redefines Ops (AIM418)
この動画では、Edge DeltaがDiscussion Control Planeという新しいオペレーションパターンを紹介しています。AnthropicのCEO Dario Amodeiの予測によれば、AIがソフトウェア開発者のコードの90%を書くようになる中、SREやオペレーションエンジニアには新しいアプローチが必要です。AIアシスタントとAIチームメイトの違いを明確にし、後者はプロアクティブにアクションを開始し、マルチターンで思考し、サービスマップや依存関係を理解して自律的に動作します。ストリーミングデータ上でLLMを実行する際の課題として、ログとイベントはLLMと互換性が高い一方、メトリクスとトレースには前処理が必要であることを指摘。Telemetry pipelineを活用してデータをマスキング・フィルタリングすることで、LLMにデータを流す際のセキュリティリスクを管理しながらコストを抑制できると説明しています。人間の役割はリスク管理と戦略的意思決定へと昇華すると結論づけています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
AIによるコード生成時代の到来とAIチームメイトの必要性
皆さん、こんにちは。このような遅い時間の会議にお越しいただき、ありがとうございます。本日は Discussion Control Plane についてお話しし、今後2年間でオペレーションがどのように変わるかについてお話しします。ソフトウェアに関して皆さんが今扱っていることは、今後は異なる方法で扱うことになります。自分たちで扱うか、自分たちの製品を使って扱うかのどちらかです。
Anthropic の CEO である Dario Amodei からのこの引用を皆さんと共有したいと思います。2025年3月、約8ヶ月前のことですが、彼は AI がソフトウェア開発者が担当していたコードの90%を書くようになると言いました。この意見に同意するかどうかは分かりませんが、私たちはそこに向かっていると思います。今はまだそこまでには至っていないと思いますが、今日の時点では90%ではなく、50%程度だと思います。2年前の状況を考えると、これはかなりの飛躍だと思います。今は90%に達していなくても、非常に近い将来にはそこに到達すると思います。
これは実は興奮させるものに聞こえます。なぜなら、今はコードを書くという大変な作業をしなくて済むからです。しかし、これは朝の2時に、自分たちが文脈を持たないコードについてのアラートを受け取る責任があるということを意味します。場合によっては、その問題についてさらに文脈が少ないかもしれません。また、この問題が他のシステムにどのような影響を与えるかについても文脈がないでしょう。そして、その他のシステムもおそらく AI によって書かれています。この領域には何か新しいものが必要です。SRE やオペレーションエンジニア、そして朝の2時に起きる責任がある人たちのための新しいオペレーションパターンが必要なのです。
今日でさえ、AI が関わっていなくても、現代のオペレーションはすでに非常にサイロ化しています。人々はシステムの異なる部分に責任を持ち、他の部分については気にしません。彼らはいつも反応的に行動ステップを考え出しており、たとえ runbook が積み重なっていても、それは他のインシデントから学んだ教訓についてのものです。人々はダッシュボードを見て、データをクエリしようとして、エラーを認識して、すべてをこのような古いツールで行っています。昨日のツールで明日の問題は解決できません。だからこそ、私たちは本日、Discussion Control Plane と呼ぶものを導入しています。ここでは、皆さんの agentic SRE チームメイトや他のチームメイトがシステムと対話することになります。
もっと詳しく説明する前に、自己紹介をさせてください。私はほぼ10年間 observability に取り組んできました。observability での私の旅を始めたのが、2020年に Site Reliability Engineer になるきっかけとなりました。実は、元々は開発者で、偶然プロダクトマネージャーになり、今は AI の力を持った開発者になっています。今年は7回目の AWS イベントで、AI がすべての役割にどのように変化をもたらすか、そして今後1年間でどのように変わるかについて、ここでのエネルギーを本当に感じています。将来がどのようになるかについて、すでに多くの質問でいっぱいです。
では、本日の残りのアジェンダについてお話しします。まず、私がチームメイトと言うのは何を意味するのかについて説明します。アシスタントとは何か、そしてチームメイトとは何かについて議論します。その後、ストリーミングデータ上で LLM を実行する際の課題についてお話しし、それをテレメトリーパイプラインのガードレールと結びつけます。なぜなら、すべてを LLM に送信することはできないからです。そして、AI 後の文化的シフトについてお話しします。まず、アシスタントとチームメイトについてお話しします。
AI アシスタントは今、ウェブサイトのいたるところにあります。すべてのウェブサイトに、SRE のユースケースに関連する情報を取得するのが得意な AI アシスタントがあります。何か質問があったり、何かについて知りたいときに、Prometheus や私が使っているどんなクエリ言語でも、クエリを立てるのを手伝ってくれます。ダッシュボードからデータを取得するのは得意ですが、その後、議論を続ける必要があります。それに対して、わかりました、答えは得ましたが、これは実際に役に立っているのでしょうか、と言う必要があります。設計上、これらは受動的なヘルパーです。問題を解決してくれるためにそこにあるのではなく、あなたが問題を解決できるように質問に答えるためにそこにあります。これは良いことで、私たちは長い間 AI をこのために使ってきました。しかし、これはある種受動的です。
アシスタントとチームメイトの実際の違いは、アクションと情報に根ざしています。 AI アシスタントはプロンプトに応答して答えを出し、次の質問を待ちます。一方、AI チームメイトはプロアクティブにアクションを開始し、あなたが何も尋ねなくても問題について研究を始めることができます。AI アシスタントの場合、スコープとメモリはあなたが尋ねている質問に限定されます。以前の質問と議論だけを覚えています。一方、AI チームメイトはマルチターンです。彼らは考えます。私は何かをしましたが、それは解決策ではなかったので、別のことをする必要があります。
その観点から、AI アシスタントをヘルパーと見ることができ、AI チームメイトをあなたの協力者、ほぼあなたのジュニアエンジニアのように見ることができます。彼らは学ぶすべてのことでより良くなっていきます。文脈は、AI チームメイトがあなたが与えるプロンプト以外のことを知ることができるということです。彼らはあなたのサービスマップがどのように見えているか、あなたの依存関係マップがどのように見えているかについて学ぶことができます。そして、AI チームメイトがあなたよりもあなたのシステムについてもっと知っていることを理解できます。それが実際に彼らを信頼できる方法です。彼らはあなたが設定した境界内で自律的に行動することができます。このような AI チームメイトにこれをしてほしいが、あれはしてほしくない、と言うことができます。いくつかのアクションを制限し、このタイプのことについては特定の承認許可が必要だと言うことができます。
Discussion Control Planeによる実践的なインシデント対応の実例
実際のシナリオについてお話ししましょう。 ここでは名前を匿名化していますが、これは AI チームメイトとの議論を始める方法の一つです。 人間として、あなたはそれに質問をすることができますが、他の方法もあるかもしれません。モニターが事前に議論をトリガーすることもできますし、外部イベントや定期的なタスクが議論をトリガーすることもできます。この時点で、人間が質問をしています。何か問題があるように見えます。それがインシデントなのかどうか確実ではありません。何か起きているのかを確認したいだけです。これは通常、Slack でどのように行動するかですよね。何か変に見えるので、確認できますか、と言うでしょう。
では、ここから始まります。すべての AI チームメイトのためのオーケストレーターがあって、このオーケストレーターがシステム内のすべての AI チームメイトを把握しています。例えば、10 人の AI チームメイトがいて、1 人は SRE を担当し、1 人はコード作成を担当し、1 人はデザインを担当しているとします。オーケストレーター、私たちの場合は Edge Delta の Eco AI ですが、これがすべてのチームメイトを見て、彼らのすべてのツールを見て、彼らのすべての権限を見て、彼らのすべてのメモリを見て、この質問に最も適したチームメイトを選びます。この場合は SRE で、この分析を実行してこの質問に答えるためのプロンプトを与えています。
このアプルーバル機能に注目していただきたいのですが、先に進む前に許可を求めています。これが実際に、あなたが設定した境界線の中でシステムを動作させることができる方法です。これは人間に承認を求めて、その後分析を開始し、取得できる最初のデータをスレッドに直接引き込みます。
その後、オーケストレーターに戻って、オーケストレーターは「分析をしてみたけど、他にもいろいろあるかもしれないけど、進めたい？」と言います。
ユーザーは「今何が起きているのか分かった」と言います。
「もっと詳しく質問したいのですが、ロックパターンも見ることができますか？」と言います。そうするとオーケストレーターは他のチームメイトを選んでこの質問を見てもらいます。
もう一人のチームメイトが別の承認を求めて、このデータを引き込みます。
ここに本当に注目していただきたいのですが、通常、あなたがこの問題を解決しようとしている人だったら、タブを切り替えることになります。「今はパターンを見る必要がある、今はダッシュボードを見る必要がある」と言って、気づいたら同時に 10 個のブラウザタブが開いていることになります。でも、ここではすべてが実際にコンテキスト内にあって、ただ 1 つのスレッドの中にあります。
この会話は長く続いて、その後しばらくして、 他のチームメイトが参加してきました。SRE がレポートして、コード分析ツールが最新のデプロイメント内の問題のあるコミットを特定しました。「ロールバックを追加したいですか？」と聞いてきました。ユーザーはロールバックをリクエストして、それが実行されました。
分析を続けて問題を監視することができます。問題は最小限の人間の関与で解決され、この人はデータをクエリする方法やアクションをオーケストレートする方法を知っている必要がありません。単に素直な方法で質問をして、AI チームに仕事をさせるだけです。もう 1 つ話したいことがあります。ご覧の通り、これらのスレッドではすべてが保存されています。この目的のために取得されたすべてのチャートとデータ、描画されたすべてのチャートが、このスレッドに保存されています。人間のユーザーとして、いつでも戻って実際に何が起きたのかを見ることができますが、さらに重要なことに、あなたの AI チームメイトは戻って そこで何が起きたのかを見ることができます。
Telemetry Pipelineを活用したLLMへのデータ管理と人間の新たな役割
ストリーミングデータ上で要素を結合することは、セットを使って作業することより難しいです。 テレメトリデータセットの中には、AI で実行するのに適しているものもあります。ログとイベントには今、星がついています。なぜなら、それらは LLM とより互換性があるからです。その性質上、LLM によってトークン化可能な単語が含まれていて、実際にはどのログ行も LLM にとって何か意味があります。同様に、Kubernetes イベントのようなイベントは実際に意味があり、LLM はそれについて十分なコンテキストを持っています。これらは LLM にとって理解しやすいのですが、LLM に供給するのは簡単ではありません。なぜなら、それらはペタバイト規模で到着し、LLM に蒸留された方法で供給する方法を見つける必要があるからです。
メトリクスのエントリも興味深いものです。LLMにトレンドを自動的に見つけてくれることを期待することはできません。メトリクスに異常があることを自分で特定して、それを LLM に渡す必要があります。同様に、トレースについても、トレースに対して分散テイルサンプリングを行い、それを LLM に渡して分析させます。すべてのメトリクスとトレースを LLM にダンプすることはできません。そうすると破産してしまいます。効率的なデータ処理には、テラバイトまたはペタバイトのデータを処理する必要がありますが、英語でクエリを実行することができます。 もちろん、スケーラビリティは最高の状況ではありません。
トークンが安くなってきているのを見ていますし、将来的にはすべてを LLM に流し込むことができるかもしれません。しかし、どれだけ安くなったとしても、スケールでは依然として非常に高額になります。独自のメトリクスでモデルをトレーニングおよびファインチューニングすることは、ほとんどのデータでは実行不可能です。AI へのデータフローについて、誰も言わない真実があります。私たちはすべてを流出させているのです。つまり、LLM よ、すべてを読んでくれ、私のコードを読んで、私のデータを読んで、私の知的財産をすべて読んでくれということです。これはリスクを露呈させており、チームは現在 LLM に流れるデータを管理するのに忙しくしています。
ここで telemetry pipeline の話になります。Telemetry pipeline が最初に登場したとき、データを圧縮し、宛先にアーカイブし、telemetry データセットを S3 バケットに保存して、データを安全に保つために使用されていました。その後、データを見るより良い方法を発見し、コストは実際にさらに 100 倍低下しました。データを Splunk や Datadog に送信することもできますが、そのためにすべてのデータを取り込むだけでも破産してしまいます。だから telemetry pipeline が登場したのです。データを削減し、インテリジェントな方法でデータをフィルタリングし、データをマスクするためです。これが今日の telemetry pipeline として知られているものです。これは良い価値ですが、戦略的ではありません。コストを削減することについてですが、データ自体を語らせることはできません。
現在、telemetry pipeline を使用している LLM があり、これもコストが 100 倍高くなっています。Telemetry pipeline を使用すれば、AI に高い価値を提供しながら、データを制御下に置くことができます。多くの企業がこれらのセキュリティ関連のすべてのこととセキュリティ認証に準拠しているのを知っていますが、彼らは単に LLM にソースコードとアーキテクチャを露骨に共有しています。 Telemetry pipeline を使用すれば、LLM に流れるデータをマスクしたいと言うことができます。ユーザーに関する情報、個人識別情報、または独自のコードとサービストポロジーに関する情報を漏らしたくないと言うことができます。
データが LLM に流れる前にマスキングおよびフィルタリング機能を備えていれば、実は自分自身を保護するだけでなく、顧客や今後数ヶ月で採用する新入社員も保護することができます。彼らは機密情報にさらされることはありません。
では、AI エージェントが私たちの仕事を奪いに来ているのではないかと、皆さんは疑問に思うかもしれません。この新しいパラダイムにおいて、私たちの役割は何なのでしょうか。私は、これは置き換えではなく、むしろ昇華だと考えています。人間として、皆さんはリスク管理に対して依然として責任を持ちます。LLM が起こす可能性のある誤りと、それが生み出す問題に対して、皆さんはまだ責任を負っています。
皆さんは、AI エージェントがどのように振る舞うかに焦点を当て、使用するツール、使用するモデル、使用するデータを調整することで、その振る舞いを変える必要があります。皆さんは積極的にそれらを管理する必要があります。また、組織的なリスク管理の観点から、より高いレイヤーへと移行し、より複雑なケースに焦点を当てることになります。開発フローの中で左にシフトして、本番環境に到達する前に問題に対応することになります。
皆さんは、AI エージェントがどのように振る舞うべきか、そして人間がこれらの仕事にどのように焦点を当てるべきかについて、最終的な意思決定者となります。これで私のプレゼンテーションを終わります。ご質問がありましたら、あちらにデータブースがありますので、これらのトピックについて喜んでお話しさせていただきます。本日はお聞きいただきありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion