re:Invent 2025: オープンソースで構築するAIエージェント型プラットフォームエンジニアリング
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Building agentic AI platform engineering solutions with open source (OPN303)
この動画では、AWSのNiall ThomsonとCiscoのHasith Kalpageが、プラットフォームエンジニアリングにAI機能を統合する実践的なアプローチを解説しています。DORAレポートによると76%の組織が専任プラットフォームチームを持つ中、開発者の90%が日常業務でAIを使用している現状を踏まえ、Model Context Protocol(MCP)やAgent-to-Agent(A2A)といったオープンソースプロトコルを活用したマルチエージェントシステムの構築方法を紹介。CiscoのOutshiftでは、CI/CDパイプラインのトラブルシューティングやLLMキー発行などのタスクを、従来半日かかっていたものを2分以内に自動化することに成功。Cloud Native Operational Excellence(CNOE)の取り組みとして、Community AI Platform Engineering(CAIPE)をオープンソース化し、Backstage、Argo CD、KubernetesなどのツールとAIエージェントを統合した実装例を詳細に解説しています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
re:Inventでのセッション開始：プラットフォームエンジニアリングとAIの融合への導入
皆さん、ようこそ。通常、皆さんの前に立ってお話しするのは、私が時間を費やす中でもかなりストレスフルなことの一つなのですが、この1ヶ月は大変な月だったので、いつも以上に、今日ここで皆さんとお話しできることをとても嬉しく思っています。お時間を割いてお越しいただき、本当にありがとうございます。月曜日の朝9時、早朝からお越しいただいていることは承知しております。皆さんの多くにとって、おそらくこれが最初のセッションだと思いますので、re:Inventへようこそ。皆さんをお迎えできて大変嬉しく思います。
共同スピーカーに月曜日の朝9時のセッションだと伝えたとき、彼の目には誰もいない空っぽの部屋で話すことになると思っている様子が見えましたが、ここではまったく逆の状況ですね。お越しいただきありがとうございます。私の名前はNiall Thomsonで、AWSのContainer Specialist Solutions Architectです。この早口言葉のような肩書きは、私が大半の時間を、お客様のEKSクラスターがIPアドレスを使い果たした理由についてお話しすることに費やしているということを意味します。分かる方は分かると思いますが、分からない方は、それは良いことです。本日は共同スピーカーと一緒に登壇しておりますので、彼から自己紹介してもらいます。
こんにちは、私の名前はHasith Kalpageです。CiscoのIncubation unitでplatform engineeringとsecurityを担当しています。
はい、いいですね。それでは私から始めさせていただき、その後少ししてからHasithにバトンタッチします。
了解です。
本日は盛りだくさんのアジェンダをご用意しています。これは300レベルのセッションです。簡単なイントロダクションはありますが、プラットフォームエンジニアリングとは何かについて話す時間はありません。LLMとは何かについて話す時間もありません。皆さんがラスベガスから戻られた後、組織で持ち帰って使える、より有用なことに直接飛び込んでいく必要があります。
ですので、組織がすでに存在するプラットフォーム機能の上に、プラットフォームチームやアプリケーションチームにAI機能をどのように提供しているかについて、直接飛び込んでいきます。彼らがそれを行うためにオープンソースツールをどのように使用しているかを見ていきます。HasithがCiscoのOutshiftの一部として、Ciscoのプラットフォームで行ってきた素晴らしい取り組みをお見せします。そして、皆さん自身でこれらのことを試すきっかけになることを願って、彼らがその作業をどのようにオープンソース化しているかについて話します。その後、まとめに入ります。
プラットフォームエンジニアリングの現状と課題：開発者体験の向上を目指して
さて、プラットフォームエンジニアリングです。これがプラットフォームエンジニアリングについて本当に基礎とできることのすべてです。これは、お客様がAWS上で運用を実現するための非常に人気のある方法であり続けています。今年のDORAレポートでは、76%の組織が少なくとも1つの専任プラットフォームチームを持っていると答えており、少なくとも1つ、複数持っているところもあります。しかし、プラットフォームエンジニアリングとは何かという点では、私は集中化された機能を構築することという観点で考えるのが好きです。
これらの機能のいくつかは、本番環境へのゴールデンパスかもしれません。つまり、ゼロから本番環境まで本当に速く到達できる標準的なCI/CDプロセスを作り出すことです。セルフサービス機能かもしれません。例えば、Backstageは、それを行うための非常に人気のある開発者ポータルです。アプリケーションを作り出したらすぐに使える標準的なオブザーバビリティ、そして通常はコンピュートに関する何らかの抽象化があります。多くの場合、これがKubernetesであることが多いですが、Amazon ECSやさらにはAWS Lambdaの上にプラットフォームを構築しているAWSのお客様もいます。お客様はプラットフォームエンジニアリングを採用し始めています。ですので、ワークロードを実行するために何を使用しているかは関係なく、誰もが何らかの形でプラットフォームエンジニアリングに取り組んでいるのを目にしています。
さて、プラットフォームエンジニアリングに関しては、避けられない程度のテクノロジービンゴをプレイしなければなりません。
私はこれをCNCFヒップスタースタックと呼ぶのが好きなんですが、これらは明らかに私が推奨している技術というわけではありません。これらは単に、特にKubernetesの世界で、私たちが最もよく目にするものの例です。これらのそれぞれに対して、選択できる可能性のある5つの代替案があります。これらを私からの推奨として受け取らないでください。しかし、オープンソースの観点から言えば、これらは私たちがよく目にするものです。そして、これらはオープンソースで、実戦でテストされたツールであり、多くのコミュニティでの採用を見てきました。また、これらは後ほどAI関連のことに踏み込む際にも役立ちます。
しかし、皆さんの中で、すでに組織内で何らかの形のプラットフォームエンジニアリングを行っていると言える方はいらっしゃいますか?
ええ、かなり多くの方がいらっしゃいますね。ですから、皆さんは誰よりも、プラットフォームエンジニアリングを立ち上げて稼働させることが、最良の状況でもかなり困難であることをご存知でしょう。先ほど見たすべてのツールを、インフラストラクチャ、組織、その仕組みと組み合わせる必要があります。非常に複雑になるのがとても早いんです。そして、これらすべてのツールの周りに優れた開発者体験を構築しなければ、採用はおそらく苦戦するでしょう。
プラットフォームを採用する開発者たちは、おそらくプラットフォームの使用に苦労するでしょうし、彼らが経験する認知負荷が増大し始める可能性がありますよね?それは、十分に考え抜かれていない抽象化かもしれませんし、2022年以降更新されていないドキュメントやwikiかもしれません。これがつまずき始める理由はたくさんあります。そして最終的に起こることは、プラットフォームチームがずっと手取り足取りサポートすることになってしまうんです。より多くの機能や特徴を構築する代わりにね。
そして、ここで私たちが求めているのは、単にKubernetesクラスターを提供するだけのプラットフォームチームではありません。開発者の生産性を高めるソリューションを構築することを目指しているんです。単にSlackメッセージやJIRAチケットに一日中答えて、彼らがその日を乗り切れるようにしているだけでは、それを実現することはできません。
CNOEとAIの進化：エージェントによる開発者支援の可能性
さて、AWSにおけるオープンソースの取り組みの一つで、こうしたプラットフォームエンジニアリングの難題を解決するために私たちが立ち上げを支援したのが、Cloud Native Operational Excellenceです。これはかなり長い名前ですが、CNOEと短縮されています。これは本質的には、プラットフォームエンジニアリングを採用している大規模組織のグループで、オープンに協力し合い、彼らのアプローチ、戦略、ツールセット、そしてこれをどのように進めているかのリファレンスアーキテクチャを共有しています。もしまだCNOEをチェックしていないなら、皆さんのプラットフォームエンジニアリングの取り組みにとって非常に有用かもしれませんし、そこを見ることで何か学べるかもしれません。
しかし、組織が手を伸ばしているもう一つのツールがAIです。 これは2025年の今年としては、おそらく驚くことではないでしょう。AIが最初に登場してから進化してきたのを見るのは非常にクールでした。LLMから始まり、プロンプトを投げると段落のテキストやコード、画像が返ってくるところから、もう少し洗練されたエージェントへと移行し、タスクをより小さなステップに分解し始め、APIを通じて外部情報にアクセスしたり、アクションを取ったりできるようになりました。最近さらに見られるようになってきたことの一つは、右端にあるこれらのエージェントにさらに自律性を与えることです。手動でトリガーされることすらないかもしれません。既存のアーキテクチャのイベントに反応し、少なくとも何らかの形でアクションを取ります。通常はまだ何らかのレベルのレビューと承認がありますが、AIに何かをするよう依頼する時間が減り、皆さんの代わりに勝手に始めるようになってきています。
さて、開発者とAIに関して言えば、コーディングは LLMのかなり人気のある使い方だったと思います。今年のDORAレポートも、これは名前が変更されて少し私を驚かせたのですが、「The State of AI Assisted Software Development」に改名されました。つまりState of DevOpsはなくなりましたが、ここでの回答者は90%が日常業務でAIを使用していると報告し、80%がより生産的になったと述べています。さて、この80%という数字を信じるかどうかは、皆さんにお任せします。さまざまな研究やレポートが行われていますが、90%の開発者が使用していると報告しているということは、もう船は出航し、人々は毎日使っているということです。
ですから、プラットフォームエンジニアとして、私たちはAIをプラットフォームの抽象化とどのように組み合わせるかを考え始める必要があります。そうすることで、AIが私たちのプラットフォームと連携し、開発者が生産性を高めるために組織内に構築したプラットフォームと うまく機能しないコードや設定を大量に生み出さないようにする必要があります。もう一つ有用な統計があります。開発者の中央値は1日1時間未満しかコーディングに費やしていません。ですから、AIについて考えるときにコーディングとコードの実践的な開発だけを考えているなら、彼らの残りの時間を無視していることになります。彼らのCI/CDパイプラインは壊れるでしょうし、それを修正しなければなりません。脆弱性にパッチを当て、issueやPRに取り組み、コメントやレビューをします。午前2時にインシデントに対処し、コストの最適化を行います。
ですから、本当に彼らをより生産的にしたいのであれば、コードを生成することだけに集中することはできません。プラットフォームエンジニアリングの一部として自然に適合する、恩恵を受けられる他の多くの領域があり、それについて考える必要があると思います。そして、これをプラットフォームエンジニアリングと開発者のより多くの領域に広げたいのであれば、 開発者がいる場所にAIを注入できる場所を広げ始める必要があります。彼らがいる場所で彼らに会うのです。開発者はIDEでコーディングしていますし、最近はCLIでもますますコーディングしています。Kiro CLI、Claude Code、その他すべてのツールにより、今はCLIでより多くコーディングしています。GitHubでissueやPRに取り組み、Backstageで組織内をナビゲートし、インシデント管理でインシデントに取り組んでいます。これらすべてが、AIを注入して彼らをより生産的にし、私たちが構築したプラットフォームと抽象化、そして持っているすべての生産性ツールが、これらすべての異なる領域で彼らをさらに支援できるようにする場所なのです。
実践デモ：CI/CDパイプライン障害をAIエージェントで自動解決する
では、これが実際にどのように見えるのか、実例を見ていきましょう。さて、私は誰よりもGenAIのライブデモをするのが大好きなんです。通常のデモのリスク要因を取って、それをもう少しだけ増幅させて、少しだけ緊張感を高めてくれますからね。でも、ちょうど去年のこの時期、Mandalay Bayで、WiFiの一部が落ちてしまったんです。なので、今日はそれを言い訳にして、その弾丸を避けることにします。ですので、事前に録画したものを用意しましたが、本当はこれをライブでお見せしたかったんです。
さて、このケースでは、開発者のJohnがイノベーションとトランスフォーメーションに取り組んでいて、彼が持っている1時間の時間を使ってコーディングしていると、パイプラインが失敗します。パイプラインの内容自体はそれほど重要ではないんですが、右端を見ると、ステージング環境へのデプロイメントが失敗しているのがわかります。さて、Johnのチームが使っているプラットフォームはKubernetes上に構築されていて、GitOpsにはArgo CDを使っていて、まあ、何らかの理由でCodePipelineも使っているんですが、これは私が立ち上げて動かすのに一番簡単だったからです。
でも、Johnにはパイプラインの何が壊れているのかを突き止めてもらいたいんです。そこでJohnはKiro CLIに飛び込みます。さて、Kiro CLIに馴染みがない方のために説明すると、つい最近までQ Developer CLIと呼ばれていました。最近Kiroブランドにリブランディングされたんです。 これは、コマンドラインでAIを直接使ってアプリケーションを書いたり、アプリケーションをデプロイしたり、テストを書いたり、あらゆる素晴らしいことができるツールです。 ここでお見せしているものは、Kiroで行う必要はないんです、よね？例えば、Claude Codesのようなものでも、これを行うことは完全に可能です。これはオープンソーストラックなので、これを行うためにAWSのものを明示的に推奨しているわけではありません。ここでお見せしているもののほとんどについて、できることはたくさんあります。
さて、ここで、これらのツールがよく持っているものの1つに、私たちがツールと呼ぶものがあります、よね？これは、AIやモデルが手を伸ばして、通常は何かを実行したり、何かを取得したりする方法です。ファイルを読むこともできますし、ファイルを書くこともできますし、APIにアクセスすることもできます。ツールを使って、あらゆる素晴らしいことができます。さて、下の方を見ていただくと、私たちのプラットフォームチームがQueryという単一のツールを追加しています。ちょっと小さいのはわかっていますが、これ以上大きくできませんでした。彼らは私たちにカスタムMCPを構築してくれたんです。
私たちのケースでは、素晴らしいプラットフォームチームが、開発者が使える集中型AIを構築してくれました。これは、開発者が作業しているさまざまな場所から再利用可能なものです。そこでJohnがやることは、私たちのMCPを使って、集中型AIに接続し、「私のpayment APIワークロードの最後のCI/CDパイプライン実行が失敗した理由をトラブルシュートして」と尋ねることです。さて、彼はシステム識別子を一切使っていません。CodePipelineやArgoやKubernetesなど、そういったことについては何も言っていません。かなり曖昧な文ですが、実行を承認した後、集中型AIエージェントに接続しているので、それが私たちのために大量の作業を開始してくれます。私たちのシステムの多くを処理し、何が間違っていたのかを調べて、推奨事項を持って戻ってきてくれます。
では、技術的な部分をカバーした後で、そこで何が起こったのか、より詳細にお話ししましょう。システムが戻ってきて言うには、どうやらJohnか彼のチームメイトの誰かが、誰を指しているわけではありませんが、Helmのvaluesファイルへの最後の更新で入力ミスをしてしまい、Kubernetesのメモリのリソースリクエストをリミットよりも高く設定してしまったようです。そしてKubernetes APIがそれを拒否しました。それによってArgo CDのプッシュが失敗し、パイプラインが失敗して、彼らは通知を受け取ったわけです。
そこでKiroが戻ってきて、これを修復するためのオプションをいくつか提示してくれました。提案としてオプション1を選択しましょう。この時点でKiroは、上流のセントラルプラットフォームエージェントから得たすべての情報を取得し、デスクトップ上で、すみません、ラップトップ上でローカルの作業を行い、実際に修正を実行に移します。さて、この部分が本当に重要だと思います。私たちは多くのGenAIデモを見てきましたが、そこでは大量の情報を吐き出すだけで、何ができるかは想像に任せるというものです。私は本当にGenAIが完全なループを埋めるところを見せたいんです。つまり、抱えていた問題に対して実際に修復を行うということです。問題を見つけました、さあどうしますか？というところで終わらせるのではなく。
ですから、ここでは実際に問題を解決しています。KiroがYAMLファイルを更新していて、私たちがやるべきことはそれをレビューして、プッシュするだけです。そうすればパイプラインが実行されて、問題が解決されます。そして、問題から修復までかなり迅速に進みました。Johnがやった作業はレビュー以外ほとんどありません。さて、先ほど開発者が作業している異なるチャネルについてお話ししました。このAIエージェントをプラットフォーム機能の一部として中央に構築したので、KiroやClaude Codeに直接組み込むのではなく、Slackから呼び出して同じ結果を得ることができます。
もちろん、Slackが私たちのコードを更新してくれるわけではありませんが、異なる場所で同じAIから同じ結果が得られることを示すために、複数の異なるチャネルでこれを行い、同じ結果を得ることができます。しかし、もしも、これはより自律的なモードに向かうものですが、パイプラインが失敗し、イベントが発火し、AIが自動的にトリガーされて問題を解決するためのプルリクエストを上げるだけだったらどうでしょう。ここで、方程式のより自律的な部分に到達し始めます。AIを明示的にトリガーする必要がないのです。イベントを通じてトリガーされますが、それでも提案された変更をレビューすることができます。
AIを野放しにして、環境を勝手に更新させるわけではありません。それでも私たちは入って、AIが行った変更をチェックして検証し、承認して、プロモートすることができます。そして、人間をループに入れたまま、AIから得られるすべての支援を受けることができるのです。
AIエージェントの構築基盤：フレームワークとコンテキストの重要性
正直に言うと、時間がなくて含められなかった他のユースケースがたくさんあるんです。私たちはまだ表面をなぞっているだけだと思いますし、皆さんの想像力はすでに多くの可能性をカバーしているでしょう。例えば、開発者が私たちのプラットフォームでコードを書いたり構築したりする際に単純に支援することです。私たちが社内で構築したHelmチャート、集中的に定義したTerraformモジュール、これらすべてが様々なチャネルを通じてアクセス可能になり、開発者が構築したり質問したりするのを支援します。本番環境の問題、CI/CDの問題、その他何でもトラブルシューティングできます。平均復旧時間を短縮したり、開発者が問題を修正するためにしなければならない作業量を減らしたりすることを目指しています。
セキュリティのユースケースにも使えます。脆弱性を見つけるための素晴らしいツールはすでにたくさんありますし、DependabotやRenovateのようにプルリクエストを上げてくれるツールもありますが、多くの場合、実際に問題を修正するにはまだ多くの作業が必要です。そこも考慮し始めることができます。そして最後にコスト最適化です。既存の素晴らしいツールをすべて置き換えようとするのではなく、コスト最適化の推奨事項をどのようにプラットフォームの抽象化の一部として実際に実装するか、それがTシャツサイズのインスタンスタイプであれ、開発者が簡単に利用できるように構築した他のものであれ、ということです。
これが、できることの可能性の一部です。かなり現実的で、皆さんの組織でも起こり得ると思っていただける実例だと思います。では、これがどのように組み立てられたかに話を切り替えましょう。これは、Hasithがこれから少し話す内容につながっていきます。
まず必要なのはエージェントです。これがデモで使用したものの全体図へと積み上がっていきます。さて、エージェント自体は、LLMと比較すると比較的シンプルです。エージェントループがあり、これは入力、判断、ツール、ユーザーレスポンスの継続的なループに過ぎませんが、他にも必要なものがあります。モデルの柔軟性が必要です。なぜなら、モデルは非常に速いペースで進化しているので、それに追いつき、切り替えられる必要があるからです。セッション管理が必要で、メモリが必要で、内部で何が起こっているかを理解するための可観測性も必要です。これらのフレームワークは、他のフレームワークと同様に、ゼロから始める必要がないように設計されています。
そして、JavaScriptコミュニティから学んだことが一つあるとすれば、フレームワークにはいつでも一つ追加する余地があるということです。常にもう一つ追加できます。さて、これは決して何を使うべきかという推奨ではありません。このスライドに挙げたものの3倍か4倍のフレームワークが利用可能だと思います。これらは人気のあるものの一部に過ぎません。左側のStrandsはAWSのもので、これもオープンソースです。それぞれがこの問題に取り組む方法について独自の強みと意見を持っています。何が理にかなっているかを判断するのは本当に皆さん次第ですが、要点は、ゼロから始める必要はないということです。何か使えるものがあるのです。
さて、エージェントとモデルを手に入れたら、かなり強力なものになりますが、非常に汎用的なものになってしまいます。公開されているドキュメントの回答や、Mediumの投稿、Stack OverflowのQ&Aを返してくれるでしょう。先ほどの例で見たように、本当に生産的なものにするためには、私たちのプラットフォームについて知っている必要があり、できれば私たちのプラットフォームに関連するいくつかのアクションを実行できる必要があります。
これらのエージェントに取り込むことができる素晴らしいコンテキストがたくさんあり、それによって組織固有のことを実際に実行できるようになります。検索可能なすべてのドキュメントのような単純なものでさえ、Backstageを通じて構築しているソフトウェアカタログ、ワークロードやオーナー、それらの関係性、適用されるインフラストラクチャをマッピングしたもの、こういった情報が突然金鉱になるんです。私たちが持っている他のすべてのもの、先ほど使用例をお見せしたCI/CDシステム、クラウドコスト、インシデント管理、これらすべてが、エージェントにアプリのデプロイ方法を尋ねてKubernetesのYouTubeチュートリアルを得るのと、実際に皆さんのプラットフォームを使ってデプロイする方法を得るのとの違いを生み出します。これが違いを生むものであり、もし許可するなら、さらに迅速にするためのアクションを実行できる可能性もあります。
Model Context Protocol（MCP）：AIとシステムを接続する標準プロトコル
さて、ここからは皆さんの多くがおそらくご存知だと思いますが、全体像を埋めておきたいと思います。Model Context Protocol、つまりMCPの登場です。これは本質的に、AIを他のものに接続するための標準プロトコルで、AIが物事を照会し、潜在的に私たちの代わりにアクションを実行できるようにします。ここでいくつか指摘しておきたいことがあります。まず、標準化されているため、エージェントフレームワークや異なるモデル間で動作します。MCPサーバーを一度構築すれば、うまくいけばどこでも使えるようになります。
リアルタイムデータもここで重要になります。実際にAPIを叩いてデータを取得しているので、構築した知識ベースを叩いているわけではなく、古くなっている可能性がありません。そこには長所と短所がありますが、これによってデータのソースに直接アクセスできます。
そして、必要に応じてアクションを実行することもできます。最後に、この仕様は多くの企業によってオープンに開発されています。元々はAnthropicによって開発されましたが、現在ではAWSを含む多くの組織がその仕様に貢献しています。
さて、オープンに開発されているのは仕様だけではありません。多くの組織が、MCPサーバーもオープンに構築しています。AWSサイドでは、AWS Labsの下にこのMCPリポジトリがあって、えーと、このスライドを少し前に作ったんですが、55以上、おそらく今はもっと増えているでしょう。これによって、あらゆる種類の素晴らしいもの、事前に構築されたMCPサーバーが手に入ります。AWS API MCPサーバーは、基本的にAIエージェントにAWS CLIへのアクセスを提供しますが、実際にシェルアクセスを持つことなく、例えばそういった形で提供します。つまり、AWSアカウント全体をナビゲートするための、トークン効率の良い非常に興味深いアプローチなんです。もちろん、パーミッションを使ってロックダウンします。
実は、これが月曜日の朝早くにこういったことをするのが好きな理由の一つなんですが、昨日、ホステッド型のAWS API MCPのプレビューを発表したばかりなんです。つまり、もう自分で実行する必要すらないんです。SIGV4認証で保護されたAPIエンドポイントを提供するので、それを叩くだけでいいんです。ローカルやリモートで実行する必要はありません。私たちがそれを提供するので、すぐに使い始めることができます。ぜひチェックしてみてください。ブログなどもあるんですが、これらのスライドに追加する時間がありませんでした。でも、これは素晴らしい追加機能です。
これら他の多くのものについても、Knowledge MCPサーバーを使ってエージェントがAWSドキュメントにアクセスできます。Dynamoのものを使えば、Dynamoから直接データを取得できます。Cost Explorerでコスト情報を取得することもできます。これによってエージェントは非常に多くの情報にアクセスできるようになります。AWSに対してかなり汎用的ですが、それでも素晴らしいスタートです。もっと広くオープンソースを見てみると、ArgoプロジェクトにはArgoCD MCPサーバーがあります。Backstageには今、MCPサーバーが組み込まれています。別のMCPサーバーすら必要ありません。非常に多くのオープンソースプロジェクトで、MCPサーバーがファーストクラスシチズンとして構築され始めていて、すぐに使えるようになっています。さらに、私たちのように、ホステッド型のものを構築している多くの組織もあります。MCPサーバーは、単に取得して使えるものになってきていて、構築について考える必要がなくなってきています。
マルチエージェントアーキテクチャとAgent-to-Agentプロトコルの活用
では、エージェントにMCPを追加すると、このような感じになります。GitHub MCPサーバーを通じてコードやissue、PRにアクセスできます。Kubernetes MCPサーバーを通じてpodやイベントにアクセスできるかもしれません。そして、Backstage MCPサーバーを通じてBackstageカタログやtech docsにアクセスできるかもしれません。これらすべてがかなり簡単になり、エージェントがほぼ即座に私たちのプラットフォームに対してより特化したものになります。しかし、これらのMCPサーバーをどんどん追加していくと、
いくつかの実用的な影響が出始めます。ツールを追加すればするほど、エージェントは適切なツールを選び、何を使うべきかを判断するのに苦労し始める傾向があります。より多くのタスクを与えると、モデルのコンテキストウィンドウが、もう少し慎重に管理する必要が出てきて、特定のタスクに対して最適化できなくなります。Langchainがこれについて素晴らしい記事を書いていて、シングルエージェントとマルチエージェントアーキテクチャの影響を測定しようとしました。
さて、複数のエージェントを実行するというのは、私たちが最近よく目にするようになってきたパターンです。一つの汎用的なエージェントを作成する代わりに、これらの個別のエージェントはそれぞれ独自のツール、独自のプロンプトを持ち、それぞれの領域のスペシャリストになります。そうすることで、それらを専門化し始めることができ、適切な選択をして適切な情報を引き出すことにおいて、より効率的にすることができるのです。先ほど見たエージェントフレームワークの多くは、これをどう行うかについて独自の考え方を持っています。設計の観点からも、やり方はたくさんあります。しかしまた、これらを一つのコンテナでモノリスとして実行するのか、それともマイクロサービスのように分散して実行するのか。その点においても選択肢があるわけです。
そして、もし分散エージェントを実行するつもりなら、オープンソースの話をしている中で、Agent2Agentプロトコルというのも知っておくべきものです。さて、これはGoogleから出てきたプロトコルですが、Linux Foundationに寄贈されています。MCPがエージェントを情報に接続するための標準プロトコルだったのに対し、Agent2Agentは、名前が示すように、エージェント同士を接続し、それらが協力して一緒に作業できるようにするための標準プロトコルです。通常、分散的に実行されているときに使われます。
これについていくつか注目すべき点があります。まず、自律的な発見という観点から物事が面白くなり始めます。エージェントはお互いを見つけ出し、お互いが何ができるかについてほぼ交渉のような形を行うことができるので、どこにタスクを委任すればいいかを把握できるのです。コラボレーション、エージェントたちはより協調的な方法で一緒に作業し始めることができます。そしてもちろん、これもオープンソースです。仕様はオープンに構築されており、私が知る限り、彼らは現在、多くの改善を含むV1の仕様に向けて取り組んでいるところです。
では、A2Aの実践を、恐ろしくシンプルに見てみましょう。これは、異なるエージェントフレームワークを使用し、異なるモデルを使用している複数のエージェントが、
異なるMCPサーバーと一緒に作業を始めることができるということを意味します。そして、それらはAgent-to-Agentを介して通信します。これは例えばJSON-RPCのようなものを使ったHTTP呼び出しです。これにより、例えば左側のエージェントが右側のエージェントを見つけ、それが何ができるかを把握し、ああ、自分でやる代わりに、このより専門的なタスクを解決するためにあなたを使うことができる、と言えるようになるのです。彼らがそれを行う方法の一つは、右側に見えるように、エージェントカードと呼ばれるものです。これは、OIDC、OpenID Connectにはすべての異なるエンドポイント、例えばトークンエンドポイントなどがどこにあるかを伝えるwell-knownエンドポイントがあることを考えてみてください。これはエージェントにとって同じものです。エージェントが自分の名前、説明、バージョン、URLを宣伝できるwell-knownエンドポイントですが、これは私ができることはこれで、送ってもらえるプロンプトの例はこれです、といったことの例も提供できます。そしてこれは、エージェントが実際に例に基づいて動的にプロンプトを自分で構築し始めることができることを意味します。基本的に、エージェントカードを通じて別のエージェントにプロンプトエンジニアリングのヒントを与えているので、それらが一緒に作業できるのです。これが、これらのエージェントが超具体的な指示なしで作業できる仕組みです。それでもいくつかのヒントは与えますが、それによってそれらははるかに疎結合になり、組み合わせるのがはるかに簡単になります。
デモの舞台裏：Strandsとマルチエージェントによる情報フローの詳細
では、先ほどお見せしたデモを見てみましょう。これは基本的に、今お見せしたものを使って私がまとめたものです。先ほどお見せしたデモは、実際にはこれよりも多くのエージェントがあったのですが、スライドにすべてを載せるスペースがありませんでした。これらはすべて、私のエージェントフレームワークのSDKとしてStrandsを使って構築されています。EKS上で実行していて、通常のデプロイメントで、実際には単なるAPIです。そして、ワークロードの観点から見ると、比較的シンプルです。
では、情報がどのように流れていったかを確認するために、実行したシナリオを見てみましょう。 最初は、私たちのCLIであるKiroにいて、最初の質問をしました。Kiroには、私たちが構築したMCPサーバーがありました。MCPサーバーは実際には私のエージェントに組み込まれていたので、実際にはそのエージェントにリモートでMCPエンドポイントを構築し、Kiroがそれを使用するように設定されていました。MCPコールを送信します。つまり、MCPは興味深いことに、バックエンドの何かであると同時に、クライアントプロトコルにもなり得るのです。そして、リモートエージェントに対して、私のCI/CDパイプラインをトラブルシューティングしてほしい、手伝ってほしいというクエリを送信しました。
プラットフォームエージェントは、私が認識させていたエージェントたちに連絡して、どのように手伝えるか尋ねました。すべてのエージェントカードを取得し、chain of thoughtやその他のパターンを使って戦略を立て始めました。これらのエージェントが推論を行う方法です。そして、計画を立てました。
最初に行ったのは、カタログエージェントへの連絡でした。カタログエージェント自体がMCP経由でBackstageに連絡しました。Backstage内のMCPサーバーに直接アクセスし、turning payment APIに関するカタログ情報を取得して、より具体的なワークロード識別子に変換しました。つまり、作業対象を正確に明確にしたのです。
その後、プラットフォームエージェントは、どのワークロードについて話しているのか正確に把握したと判断しました。そして、CI/CDパイプラインを支援できることがわかっているCI/CDエージェントにアクセスすることにしました。 そして、AWS API MCPサーバーにアクセスして、CodePipelineのステータスとCodeBuildのログを取得しました。ArgoCD MCPサーバーにアクセスし、ArgoCDのアプリケーションが同期に失敗したことを確認し、実際にKubernetesイベントを取得しました。これにより、リクエストとリミットが一致していないことがわかりました。 そして最後に、GitHubに連絡しました。先ほど小さなテキストを注意深く見ていた方は、トラブルシューティング中に実際にコミットIDが言及されていたことに気づいたかもしれません。実際にGitHubに連絡して、パイプラインをトリガーしたコミットを取得し、行われたコード変更を確認できるようにしたのです。
そしてそれらすべてを受け取って戻ってきます。そしてエージェント自体、つまりCI/CDエージェントが、プラットフォームエージェントへのレスポンスを作成し、それがKiroに戻ってきました。 そしてKiroは、ローカルでファイルを更新するという少しの作業を行うことができ、修正をプッシュして問題を解決することができました。メッセージング経由のSlackの例も、ほぼ全く同じように動作しました。私たちのプラットフォームチームが中央の機能として、APIとして構築したこの中央部分のすべては、オープンソーステクノロジーを使用しており、これらのチャネル全体で再利用可能です。Slack側からは、MCPの代わりにAgent-to-Agentを直接呼び出しただけでした。それが唯一の違いでした。しかし、ご覧のとおり、同じ結果が得られました。
では、このセクションをまとめますと、プラットフォームチームとしてこれらすべての機能を構築する際、オープンソースは私たちに非常に多くのものを提供してくれています。MCPやAgent-to-Agentのようなプロトコルが、オープンに開発されています。エージェントフレームワークも、どのように作業したいか、どのような意見を持っているかに基づいて、幅広い選択肢から選ぶことができます。そして、MCPサーバー自体も、すぐに使える形で入手できるものが増えています。特にプラットフォームエンジニアリングには、すぐに使えるものがたくさんあり、これらの機能を構築する際に利用することができます。それでは、Hasithに引き継いで、Ciscoで実際にどのようなことを行っているかについて、もう少し詳しく話してもらいます。
Cisco Outshiftの取り組み：agentic AIによるプラットフォームエンジニアリングの進化
ありがとうございます、Niall。まず Outshiftとは何かからお話しします。OutshiftはCiscoのインキュベーションユニットで、私たちは将来出現するものを非常に注視しています。現在、2つの重点分野があり、1つはagentic AI、もう1つは量子コンピューティングです。agentic AIについては、過去2年ほど様々な探索と作業を行ってきました。最近のものの1つが、エージェントのインターネットの未来を支えるAgent Collectiveのオープンソース化です。
では、Outshiftプラットフォームを高いレベルで見てみましょう。 これはOutshiftプラットフォームの簡略化された概要です。スピードのために単一のクラウドプロバイダー戦略を採用しています。3つの環境があり、dev環境、ステージング、そしてプロダクションがあり、エンジニアがアイデアをインキュベートして本番環境まで持っていくことができます。GPUやコンテンツ処理ユニット、または推論やトレーニングに関するデータの懸念がある場合のエッジコンピューティングがあります。それから、別のAWSアカウントにコマンドアンドコントロールとCI/CDの側面があり、シークレット、アクティブセキュリティ、脆弱性スキャンに関するCisco固有のセキュリティ機能もあります。また、集中型のオブザーバビリティプラットフォームとしてSplunkも使用しています。
では、少し歴史について考えてみましょう。約15年前に遡ると、開発と運用が分断されていました。開発者は運用チームに仕事を投げ渡していたわけですが、その後DevOpsが導入され、SREもほぼ同時期に登場しました。そしてマイクロサービス、コンテナ、Kubernetes、クラウドネイティブと、複雑性と多様性が爆発的に増大していきました。今日では、何か一つのことをするのに10通りもの異なる方法があり、これが問題となっています。
近年では、platform engineeringが意図的にボトルネックとして導入されました。「ザ・ゴール」という有名な本を読まれた方もいるかもしれませんが、ボトルネックは悪いものではなく、良いものなのです。しかし問題は、開発者とplatform engineersがその両側にいるボトルネックであるため、このボトルネックを効率的に運用しなければ、効果的でないプラットフォームにつながり、それが問題を引き起こすということです。これがplatform engineeringが困難である理由であり、ほとんどの組織では、目指しているほど成功していません。実際、AIによって、このボトルネックにさらに多くの負担が追加されています。AIを活用することで、私たちが知っているplatform engineeringを維持し、今後数年間に向けて進化させることができます。
では、過去2年間の話をさせてください。私は2024年1月に新しい役職に就き、インキュベーションユニットにおけるプラットフォームに関するすべてとセキュリティに関するすべてを担当することになりました。その仕事に就いたときに見つけたのは、インキュベーションユニットにいることで、さまざまな方向に引っ張られ、やや燃え尽きかけているSREチームでした。他の取り組みが進行する中で、私たちはagentic AIをplatform engineeringにどのように適用できるかという草の根的な取り組みを始めました。これはトップダウンのプロジェクトではなく、非常にボトムアップのプロジェクトでした。
いくつかのアイデアがあり、インターンシップを通じていくつかのことを試し、進行中の探索プロジェクトが一つありました。ワークフローも変更する必要があり、Argo Workflowのようなものを使うべきか、それともLangGraphを活用してワークフローエンジンとして考えるべきかと検討していました。これは多少矛盾していますが、実際にはかなりうまくいき、最終的にはかなり成功したマルチエージェントシステムができあがりました。さて、それ以降業界で何が起こっているかを見てみると、MCPが2025年3月に爆発的に広がりました。
A2AとAgentic Collectiveが登場し、先ほど述べましたが、私たちもこのCNOE、Cloud Native Operation Excellenceグループに参加しました。そして、この取り組みをオープンソース化し、CNOEに特別関心グループを作り、CAIPEを作成することが非常に理にかなっていました。これはCloud Native AI Platform Engineeringで、コミュニティによって、コミュニティのために構築されています。
Outshiftでの実装事例：ナレッジベースからセルフサービスまでの自動化
さて、これはOutshiftでの様子を視覚的に表現したものです。一方の端にはOutshiftの開発者がいて、彼らは既存の多くのインターフェースを通じてエージェントシステムと対話することができます。私たちはインスタントメッセージングプラットフォームとしてWebexを使用し、内部開発者ポータルとしてBackstageを使用しています。そしてJira、CLI、そしてIDEがあります。機能面では、ナレッジベースがあります。これはプラットフォームエンジニアリングにおいて、ほとんどの場合、wiki、プレイブック、そしてチャット履歴を含むこれらの場所に多くの部族的知識があるため、非常に有用な出発点となります。これらを収集することは非常に有用です。
そして、システムにクエリを実行するためのライブツール呼び出しができます。そして多くの場合、脆弱性が1つのシステムにあり、特定のものを相関させる必要があるような、断片化されたデータソースを持つことになります。ですから、これらを組み合わせることで、非常に迅速に多くのインサイトとデータを得ることができます。インサイトのようなものは、システムへのアクセスがあっても、プラットフォームエンジニアは2時間かかる可能性がありますが、エージェントシステムは1、2分以内にそれに答えることができます。
では次に、セルフサービスについて考えてみましょう。これも別のツール呼び出しです。現在のプラットフォームエンジニアリングの聖杯は、送信ボタンをクリックできるフォームにたどり着くことです。しかし、問題はそのフォームに何が含まれているかを理解し、実際に正しい方法でそれを記入することです。適切なフォームにたどり着くことは簡単ではなく、多くのやり取りが発生します。エージェントシステムはここで完璧です。なぜなら、エージェントシステムはそのギャップを埋めることができ、ほぼパーソナルバトラーのように、あらゆる開発者をそのプロセスを通じてガイドすることができるからです。
そして、私たちはより高度なこともいくつか行いました。このEKSサンドボックスでは、自然言語を使用して、開発者はKubernetesに関する知識をほとんど持たずに、Kubernetes上のアプリケーションを反復処理することができます。では、影響について話しましょう。エージェントAIが導入される前は、3人のエンジニアによる専任のサポートデスクがあり、そこには多くの雑務があり、多くのリクエストが来ていました。私たちはそれをほぼ完全に削除することに成功し、その時間を活用してより創造的でエンジニアリング的な作業を行うことができるようになりました。
そして質問のようなものについては、複数のSlackルームで多くの質問がされていました。20以上のスペースがあり、そこで質問が飛び交っていて、すべてが迅速に回答されているわけではありませんでした。そして今では、人々が答えを得るために使用できるAIシステムがあり、また高い信頼度がある場合は、それが介入して答えを提供することができます。さて、LLMキーが必要だとか、開発マシンが必要だといった簡単なタスクは、誰も見ていなければ半日、1日、または時には数日かかることがありましたが、これらのタイプのものは今ではエージェントシステムの助けを借りてエンドツーエンドで自動化されています。
さて、こちらが内部開発者ポータルです。このような見た目になっています。 ええ、Backstage上に構築されていて、いくつか見覚えのあるものがあるかもしれませんね。さて、右下の隅にこのアイコンがあって、これをクリックするとエージェントシステムのチャットインターフェースを立ち上げることができます。そしてそれをクリックすると、このフレンドリーなインターフェースが表示されます。 やあ、私はCAIPEです、どのようにお手伝いできますか？そして、ねえ、何ができるの？と尋ねると、 アクセスできるすべてのツールを使って、CI/CDライフサイクルに関する多くのことをリストアップして、お手伝いできることを示してくれます。
では、実際に例を見てみましょう。例えば、私が新しいエージェントプロジェクトをやっていて、 LLMキーを取得する必要があるとします。
このようなリクエストは1日に何度も発生しています。これは少なくとも半日かかっていたもので、何度も試行する必要があり、多くのインキュベーションが進行中だったため、ここには多くの競合がありました。一方、このようなことを尋ねると、システムが戻ってきて、 ねえ、プロバイダーからどこで取得するか知る必要があります。どのモデルが欲しいか、そしてどのプロジェクトに所属しているか教えてもらえますか、そうすれば帰属などができます、と言ってきます。それを完了すると、処理されて情報が送信されます。
そしてこちらが、 こちらが情報が届く例です。さて、以前は半日かかっていたものが、エンドツーエンドで2分以内で完了し、しかもバックエンドにAI LLMゲートウェイを備えて行われます。つまり、すべての優れたプラットフォームエンジニアリングのプラクティスが適用されているのです。監査やトレーシングなしで提供されるキーではありません。
では、別の例を見てみましょう。こちらはJiraチケットです。私は別のことをしようとしています。 同じタイプのリクエストで、開発マシンを要求しています。正確には何かを指定していなくて、ねえ、おそらくEC2タイプのインスタンスが必要だと思う、と言っています。もしかして、何か推奨してもらえますか？そしてこれについてJiraチケットを作成します。
さて、これがサービスデスクに届きます。 サービスデスクのエンジニアは、ああ、Jarvisがこれを処理できるな、と分かります。サービスデスクのエンジニアがそれをJarvisに割り当てると、システムが引き継ぎます。現在はここに人間がいますが、将来的にはその割り当ても自動的に行われる可能性があります。
さて、それから情報を処理します。Jarvisは知識豊富な新人SREのようなものですよね。つまり、どんなシステムが利用可能かを知っているようなものです。ねえ、EC2を作成できるよ、EKSも作成できるよ、どうする？という感じで、それに関するすべてのオプションを提示してくれます。ある意味、より経験豊富なSREであれば、おそらくEKSについては言及すらしないでしょう。ですから、このタイプの状況では、EKSを提示したくない場合、システムはさらに改善される可能性があります。でも、ここではすべてのオプションが表示されています。
そして今、私はJarvisに応答します。 ねえ、EC2インスタンスが必要なんだ。詳細はこちら。このアカウントを使って。ねえ、Ubuntuをください、そしてEKSクラスターは不要です、と。そして、それは実際の人間によるループ内承認フローに戻ります。
つまり、SREサービスデスクに届き、このリクエストが処理されるためには、SREの誰かがそれを承認する必要があります。そして、通常のGitOpsワークフローと同じように、PRに承認を与えるだけで承認されます。職場でコラボレーションに使用しているチャットインターフェースでリンクが届きます。ですから、既存のワークフローの外ではなく、通常のGitOpsが行われる方法と同様です。
はい、そしてすべてが整理されると、情報が届きます。ねえ、詳細はこちらです。開発インスタンスにアクセスできます。秘密鍵はこちら、セキュアなチャネルで送信されます。ですから、責任を持って取り扱ってください、というわけです。このような複雑なことが、エージェンティックの支援によってエンドツーエンドで自動化されます。そして、その素晴らしさは、エージェンティックシステムが不完全または不正確な情報に対して何度もやり取りできることです。
では、Jiraチケットタイプの状況で何が起こるかというと、二人の人間の間で非同期的に多くのやり取りが発生します。一方、今ここにあるのは、ユーザーが特定の事柄や情報を求めているときに、検証も即座に応答もできるエージェントシステムです。このようにして、通常のプラットフォームエンジニアリングチームが直面する大量の面倒な作業を大幅に削減できるのです。
CAIPEプロジェクトの紹介と今後の展望：コミュニティ主導のAIプラットフォームエンジニアリング
さて、では少し違うユースケースについて考えてみましょう。非常に典型的なシナリオです。ほとんどの方が経験されていると思いますが、大規模な障害が発生して、オンコールのSREが全く眠れなかったとします。では、朝になったので、彼らを助けてあげましょう。そこで私は尋ねます、ねえ、Jiraを取得して何がオープンになっているか確認してくれないか、そうすればそれらを整理できるかもしれない、顧客により良い体験を提供しつつ、SREの担当者を煩わせずに、彼が睡眠を取れるようにしたいですよね？
スーパーバイザーは実行する必要があるタスクを計画します。
PagerDutyにクエリを投げる必要があり、Jiraで何がオープンになっているかを確認する必要があり、そして調査結果を提示する必要があります。これは実際にはディープエージェントと呼ばれています。新しく登場している概念です。つまり、このスーパーバイザーはタスクのリストを作成してそれを達成できるディープエージェントなのです。そしてタスクのリストが完了しているのが見えますね、そのプロセス中に発見された追加のステップも含めて。そして応答があります。オンコールのSREはこの人物で、この特定のアドレスで連絡が取れます。手動で確認したい場合に備えて、PagerDutyのスケジュールへのリンクがあります。Jiraをどのように確認したかを説明し、そして最も重要なのは、リンク付きで見つかった4つの問題すべてが記載されていることです。これで私は何か対処できますし、そのSREから負担を取り除くことができます。
また、これがどのように実行されたかを見ると、40秒以内に完了しています。明らかに、多くの反復とステップが含まれていました。上半分はディープエージェントのスーパーバイザーがタスクを達成する方法を計画していたことがわかります。そして、それを実行するために2つの並列化されたエージェントが必要だと判断し、情報を処理して、ユーザーへの応答が提示されました。さて、これは比較的シンプルな例です。利用可能なツールを使えば、数十のエージェントを含む、はるかに複雑なことができます。ですから、システムにそのような能力があれば、達成したいことを説明して伝えることで、本当に非常に複雑なタスクを実行できることが想像できるでしょう。そしてそれらを反復することもできます。
それでは、課題についてお話ししましょう。多くの技術的な課題があります。明らかに通常のものがあります。コスト、精度、ゴールデンデータセットと軌跡が必要になります。システムを評価するために、LLMをジャッジとして使用せざるを得なくなります。そして、許容できるパフォーマンスが得られたら、それを反復する際にコストがかかります。なぜなら、モデルを変更したり、新しいエージェントを導入したりすると、システムの動作が大きく変わる可能性があるからです。ですから、これらの新しい確率的システムのCIには、多くの検討と非常にしっかりしたCIプロセスが必要です。そうしないと、それによって痛い目に遭うことになります。そして明らかに、エージェントシステムによって導入される多くの安全性、セキュリティ、ガバナンスの懸念があります。
私たちにとって特に、最大の問題の1つは、サブエージェントが使用するすべてのツールでした。それらはより頻繁に特権アクセスを持っていますが、一方でユーザーは様々なRBACを持っています。あなたがSREであれば、特定のRBACを持っています。特定のプロジェクトにいる場合は、異なるRBACを持っています。ですから、偶発的または意図的な権限昇格の重大なリスクがあり、それを保護する必要があります。さて、これはユーザーとチーム自体の両方にとって根本的な変革です。なぜなら、通常AIに対する多くの不信感があるからです。そして同様に、成長マインドセットと学習タイプの姿勢で考えなければ、実際にこれらのタイプの変革を可能にすることは非常に難しくなります。つまり、テクノロジーを見ると、非常に多くのことが可能ですが、組織において最も困難なのは、それらの人間の変革と側面なのです。
さて、それでは私たちがCommunity AI Platform Engineerについて行っていることに移りましょう。 CAIPEは、コミュニティによってコミュニティのために構築されたAIを活用して、プラットフォームエンジニアリングを再定義する試みです。それは本番環境で適用できるスケーラブルなシステムです。組み込みのナレッジベースがあります。 多くのオープンソースエージェントがあります。異なるワークフローで開発者と対話でき、オープンソーステクノロジー上に構築されています。MCP、A2A、LangGraphです。つまり、何でもMCPまたはA2Aに抽象化すれば、 マルチエージェンシーシステムのシステムと統合できます。
マルチエージェンシーシステムフレームワークでは、現在LangGraphとStrands Agentsがあり、他のフレームワークも使用できます。エージェント的な可観測性に関しては、すべてがOTelに抽象化されています。そしてエージェントがあり、特定のニーズに対応する特定のマルチエージェントシステムを持つことができます。Backstageプラグインはオープンソースになっています。 これはCAIPEと統合するA2A互換のチャットプラグインです。他のものとも統合できる可能性があります。さて、重要なことは、チャットだけではないということです。ストリーミング、システムで何が起こっているか、構造化された入力と構造化された出力によって生成されるフォームなどは、非常に良いユーザーエクスペリエンスを持つための鍵となります。適切なものが入力されたフォームを提示するような単純なことが、ワークフローが実際に人々にとって機能するかどうかに大きな違いをもたらします。
さて、私の大きなアドバイスは、何かを始めるなら、 ナレッジの側面から始めることです。なぜなら、それは参入障壁が低いからです。本番環境のデプロイメントを変更する前に、プラットフォームドキュメントを理解するのを助けてください、ということです。プレイブック、Wiki、部族的知識の観点でより良いコンテキストがあれば、それをエージェントシステムに取り込むことができれば、質の高い結果につながります。多くの場合、特に特定のモデルをトレーニングするのではなく、今日私たちが行っているようにLLMを活用している場合、その高品質なナレッジを持つことが良い結果の鍵となります。明らかに、将来的に内部ナレッジを持つ優れたシステムがあれば、より有能なAIシステムを構築することもできます。
さて、これは統合RAGアーキテクチャです。現在3回目のイテレーションになっており、RAGとGraphRAGの両方を使用できます。異なるシステムからデータを取り込むことができ、また関係性を自動的にマッピングするオントロジーエージェントも備えています。すべてオープンソースですので、試していただくことができますし、皆さんの企業ニーズに合わせて接続や進化させることもできます。それでは、コミュニティに参加してください。caipe.ioでアクセスできます。毎週ミートアップを開催していますので、プロジェクトが気に入ったら、ぜひGitHubスターでブックマークとサポートをお願いします。それでは、Niallに引き継ぎます。
はい、Hasithさん、本当にありがとうございました。CiscoでHasithさんが実際に行っていることを共有するために来ていただけて、本当に感謝しています。私がここに立って皆さんに何かをお見せするのも一つですが、Hasithさんが実際にCiscoで行っていることについて話していただくことで、現実の世界で人々が何をしているのかを見ていただけたことが、価値があったのではないかと思います。それでは、少しまとめに入りたいと思います。冒頭で申し上げたように、これは皆さんと何を共有すべきか判断するのが難しいトピックだと思います。明らかに、この分野では非常に多くのことが起こっています。私たちはプラットフォームエンジニアリングとAIの上に構築し、その上にレイヤーを重ねています。ですので、今日皆さんと共有できたことが、皆さんの組織で何かを試してみるきっかけになり、実行可能な方法でどのように取り組めるかのアイデアを提供できていれば、本当に嬉しく思います。もちろん、CAIPEプロジェクトは始めるのに非常に役立つものをたくさん提供しています。
簡単に振り返りますと、これを行っているのはCisco Outshiftの人たちだけではありませんよね。私は毎週多くのお客様と話をしていますが、このバリエーションを検討している方々もいらっしゃいます。re:Inventでは、この路線に沿った他の講演も見られるでしょう。Salesforceの講演があると思いますが、インシデント管理側に少し寄っているものの、まさにこのプラットフォームエンジニアリングのケースについて話すと思いますので、もっと見たい方はカタログで探してみることをお勧めします。Ciscoは決して例外ではありません。多くの方々がこれを検討しており、少なくとも少し時間を投資する価値があることだと思います。
オープンソースは、最近私たちが行っている多くのことと同様に、かなり堅実な基盤を提供してくれていますよね。ゼロから始める必要はありません。エージェントフレームワーク、MCPサーバー、そして相互運用性のために使用できる素晴らしいプロトコルがすべてオープンに開発されており、それらを使ってより早く始めることができます。そしてCAIPEも、皆さんに見ていただければと思います。もし皆さんの組織でこれを検討することに興味があれば、より早く立ち上げることができるでしょう。
それでは、今朝Mandalayまで来て私たちと一緒に過ごしていただき、本当にありがとうございました。お時間をいただき、心から感謝しています。ぜひセッションを評価して、レビューを残してください。これは私たちにとって非常に重要です。私たちがどのように行っているかを知ることができますし、フォームに記入していただければ本当にありがたいです。もし私たちと話したい場合は、少しの間外にいますので。今は質問を受けることはできませんが。それ以外では、皆さんが素晴らしいre:Inventを過ごされることを願っています。そして、お越しいただき本当にありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion