本動画では、Ciscoの先進技術部門OutshiftでエンジニアリングVPを務めるGuillaume de Saint-Marcが、AIエージェントの協調作業とスウォーム化の未来について語る。単一の巨大なエージェントではなく、複数のエージェントが連携して動く分散型システムこそが次世代のAI技術であり、人間が進化してきたように、エージェントも集団で知能を発揮する時代が到来しつつあるという。同氏はMoltbookの事例を引きながら、エージェント同士が単に接続するだけでは不十分であり、真の協調には状態管理、ガバナンス、セマンティックレベルでの同期が必要だと指摘する。OutshiftはLinux Foundationプロジェクトとして「agency」を立ち上げ、エージェントの接続・識別・発見・監視を可能にする「Internet of Agents」基盤を構築し、さらにその上位層として「Internet of Cognition」を開発中である。これにより、IT障害対応や複雑なクロスドメイン業務において、エージェントスウォームが自律的にタスクを分担し、数日かかっていた作業を数分で完了させる未来が見えてきている。

AIエージェントの新時代へ
AIエージェントが単なる有望技術から実際に仕事をこなすものへと飛躍するには、何が必要なのでしょうか。今日はその話をCiscoのOutshiftでエンジニアリング担当副社長を務めるGuillaume de Saint-Marcさんと一緒に掘り下げていきます。Guomさん、ようこそお越しいただきました。
こちらこそ、お招きいただきありがとうございます、Alex。
今日はエージェント同士がどう協力し合うか、そしてそれがAIの進化とともにどんな未来につながるかについてお話ししたいと思います。でもまず最初に聞きたいのですが、Moltbookの件はご存知ですか。エージェントのグループが集まって独自のソーシャルネットワークを形成したという事例です。どうやら彼らは独自の宗教まで始めたようなんですが、あれを見たときどう思われましたか。怖かったですか、それともワクワクしましたか。
ええ、本当に魅力的でしたね。あれが1月にバズったとき、私たちは皆一歩引いた場所からポップコーンを食べながら見守っていました。これはどこに向かうんだろうって。でも冗談抜きで、あれは興味深いエンジニアリングのケーススタディでした。当時、エージェントの数が急増して100万を超えたんです。最近では、本物の人間の裏付けがあるエージェントをもっと真剣に識別しようとしているようで、数は数十万に落ち着いています。
でもこれらすべてが単一のプラットフォーム上で、純粋なエージェント接続という観点から機能していた。これは非常に魅力的でした。メッセージがやり取りされ、エージェント同士が互いを見つけられたんです。ただ、一方でセキュリティ上の問題が多数ありました。クラウドセキュリティのプラットフォームが多くの脆弱性を発見し、バックエンドが実際には完全に開放されていて、悲しいことにAPIの認証情報や個人のメールアドレスが盗まれてしまいました。
もう一方で、私たちがすぐに診断した問題があります。これは驚きではなかったのですが、見世物としては良かったものの、あれらのエージェントは実際にはソーシャルメディアの行動パターンをマッチングしていただけだったんです。本当の意味での協力はしていませんでした。協力のパフォーマンス、演劇をしていたに過ぎません。
共有状態管理もなく、ガバナンスレイヤーもなく、エージェントが本当に意味のある何かについて調整するメカニズムもありませんでした。でも私たちは、これは非常に興味深い方向に向かっていると考えています。そしてこれらの欠けているピース、つまりエージェントのグループが単に接続するだけでなく、一緒に考え、より自律的に複雑な目標や高度なミッションに取り組めるようにするための部品こそ、私たちが今まさに構築している技術なんです。
Moltbookから見えた可能性と課題
なるほど、すごいですね。Moltbookには1400万件のコメント、230万件の投稿、そして約20万の検証済みエージェントがやり取りしていたわけですね。
そうです、正確には20万ですね。
ええ。で、この話を持ち出した理由なんですが、OutshiftはCiscoの一部門で、独立して考え、未来に何が起こるかを先取りしようとする部署ですよね。そして皆さんが本当に注目しているのは、エージェントが協調したときに何が起こるかということです。
私個人としては、Moltbookを見て、エージェントスウォームが実際にテック業界やビジネス界、もしかしたら私たちが生きている広い世界でも役割を果たすようになるかもしれないということが、現実味を帯びて感じられました。だからこそ、今この話をすることが非常に重要だと思ったんです。実際に動いているのを見たわけですから。
おっしゃる通りです。企業の世界にとっても多くのインスピレーションがあると思います。でも、私たちはこの課題にかなり長い間取り組んできました。私たちがこれに本格的に注力し始めたのは2年以上前のことで、当時から強力なテーゼとビジョンがありました。それは、知能というものは、より賢く、より大きく、より強力な単一のエージェントを構築することだけから生まれるのではなく、私たちが水平スケーリングと呼ぶものを通じて生まれるということです。
つまり分散システム、たくさんのエージェントが集まって、ちょうど人間のように、私たちがやっているように働くんです。これは私たち人間が何十万年、何百万年という時間をかけて進化してきた方法です。そして私たちは、エージェントも同じように進化すると考えています。ただしはるかに迅速に、なぜなら彼らは機械のスピードで動くからです。
だからこそ、いずれは超知能と呼ばれるようになるものの出現が、私たちにとって最初から魅力的だったんです。そして昨年、私たちは「Internet of Agents」インフラと呼ぶものをリリースしました。その目的は、まずエージェントがワークロードであることを認識しつつ、同時に人間やユーザーの属性も持っているということを認めることでした。
つまりエージェントはスタック全体において奇妙な存在、新しいタイプの存在として現れており、クラウドネイティブレイヤーの上に適切なレイヤーが必要だったんです。そして私たちは4つの主要な機能に取り組みました。エージェントをどう接続するか、どう強固なアイデンティティを与えるか、どう発見するか、そしてどう観測するかです。これは特に驚くことではありません。私たちはCiscoですから、接続し、セキュリティを確保し、物事を観測する、それが私たちのビジネスです。
ただしエージェントに適用する場合、これらすべての機能を再構想する必要がありました。そしてこの取り組みをバックアップするために、実際にagencyというオープンソースプロジェクトを立ち上げました。これはLinux Foundationプロジェクトとなり、Google、Oracle、Red Hat、Dellといった大手の創設メンバーの支援を受けています。これは公開されていて使われていますし、企業が実際にマルチエージェントシステムへ移行し始めているのを目にしています。
でもそうした中で、限界も発見しました。Moltbookの例と同じように、エージェントを接続するのは素晴らしいことで役に立ちます。いわゆる大規模マルチエージェントシステムを使って、かなり複雑なタスクに取り組むこともできました。私たちはたくさんのユースケースで実験し、オープンソース化したものもあれば、デザインパートナーと開発したものもあります。
でも同時に限界も見え始めました。その限界とは基本的に、事前定義されたワークフローがある場合です。古典的な企業のワークフロー、ステップ1、2、3、4と進むようなもの、そこに各タスクをエージェントに置き換えていけば、それなりに良い結果は得られます。でもそれは最も興味深いミッションではありません。最も興味深い自律的な、深いマルチエージェントシステムのミッションではないんです。
もっと興味深いミッションには、私たちが自己形成的な協力と呼ぶものが必要で、時には自己選択や、群れ自体の自己進化さえも必要です。そのためには、あらゆる種類の認知的な問題が浮上してくることがわかりました。エージェント同士が通信できても、本当に同期できないんです。私たちはこれに目をつけて、今まさに取り組んでいるところです。なぜなら、エージェント技術の次の波を可能にしたいからです。
自己形成エージェントとは何か
ちょっと待ってください。自己形成とおっしゃいましたが、これはどういう意味で自己形成的な存在になるんですか。
そうですね、自己形成というのは実際に考えてみると魅力的なんです。あなたはMoltbookに言及されましたが、私はOpenClawを例に取りましょう。OpenClawを見ると、その仕組みは実際には最先端のエージェントループなんです。エージェントは推論できますが、その推論の方法は、記憶、コンテキスト、スキル、そして個性に基づいており、実際にはサブエージェントを推論によって生み出すんです。それが自己形成なんです。
つまり基本的に、エージェントのセットは、OpenClawという小さな人気の例を取っているだけですが、これがはるかに大規模に、企業内で、はるかに高いセキュリティレベルと認証レベルで起こることを想像してください。このエージェントシステムが推論し、どのエージェントを参加させる必要があるかを決定する能力、それが重要なんです。だからこそ、エージェントを発見できることが非常に重要で、だからこそagencyにディレクトリ機能があるんです。それが基本的な構成要素の1つだからです。
必要なスキルを見て、それらのエージェントを発見し、ミッションに連れてきて、形成した計画の一部を彼らに任せる。これはすべてリアルタイムで起こります。そして今、これと事前フォーマットされたワークフローとの違いがわかるでしょう。ワークフローは素晴らしいです。非常に決定論的で、最初は企業にとって安心できるもので、認証もできます。でも本当に興味深いミッションに取り組みたいなら、この自己形成、真の推論、そしてエージェント間の認知的協力が必要で、ある時点でこれらすべてのエージェント間で、より深い認知と推論の課題が浮上してきます。もしよければ、これについてもう少し詳しくお話しできます。
ええ、ぜひお願いします。これは本当の技術的な会話ですね。技術がどこへ向かうのか、最先端やフロンティアについての話です。では、あなたの見解としては、私たちが目にすることになるのは、エージェントが自分たちでスウォームを形成し、外に出て何かをしようとするということですか。
ええ、でも絶対に、私たちは絶対にこうなると信じています。
でもどうやってそれをコントロールするんですか。暴走するAIへの道のように思えますが。
そうですね、だからこそ、あなたの質問は的を射ています。これをコントロールすることは、私たちが特定した認知的課題の一部なんです。なぜなら、この周りに多くのガードレールを設ける必要があるからです。そして異なるレベルでコントロールできます。
エージェントスウォームの制御とセキュリティ
純粋な接続レベルについて考えてみてください。これは公開されているもので、公開されていると言うとき、このポッドキャストを聞いている人たちに理解してほしいのは、これは非常に具体的だということです。agency.orgに行くか、対応するgitを見つければ、大量のコードがあります。概念ではありません。たくさんのコードがあります。サンプルアプリケーションがあります。Coffee Agencyと呼ばれるものがあり、これはKubernetesのsock shopに相当するもので、始め方を示すものです。そして小さなサンプルアプリケーションで異なるagencyの機能を試せます。そしてより高度な例もそこにあります。
物事をコントロール下に置くには、接続をコントロールする必要があります。そのために、まず第一に、誰が誰と話すかを非常に厳格にコントロールできます。ちょうどネットワークの世界で基本的なことがあるように、ネットワークのビジョンをこの技術に適用することは非常に強力です。なぜなら、ネットワークにはネットワークセグメンテーションやマイクロセグメンテーションと呼ばれる技術や技法があるからです。
たとえば、財務担当者のラップトップがHR担当者のラップトップを見ることができないようにしたり、ある機能のサーバーが他のサーバーと無作為に通信できないよう厳格にセグメント化されていたりします。エージェントに対しても同じことをするんです。エージェントは通常、1対1ではなくグループで働くのが好きなので、私たちはエージェントのルームを形成します。WebExのルームやSlackのルームのように、人々が情報交換する場所です。
私たちはルームを作り、エージェントはこれらのルーム内で通信しなければなりません。これらのルームは特定のタスクやミッションの特定の部分に対処するように設計されており、必ずしもプロジェクト全体を見るわけではありません。そしてこれらの技術の多くは、agencyにあるslimと呼ばれる技術を通じて実現されています。これは本当にエージェントの転送とエージェントネットワーク接続すべてが暗号化されているものです。これは本当に重要です。
私たちはMLSという技術を使っています。これはコラボレーションプラットフォームで使われているのと同じ技術で、たとえばエージェントが暴走した場合、そのエージェントを取り消すことができますが、ルームが壊れることはありません。他のすべてのエージェントは、交換されたデータへのアクセスを引き続き持ちます。その暴走したエージェントだけが完全に外に出され、何にもアクセスできなくなります。これはよく適しています。
最後のポイントとして、TBACと呼ばれるものもあります。TBACは本当に重要で、これはエージェントのアイデンティティと結びついています。エージェントをシステムに迎え入れるとき、繰り返しますが、エージェントはかなり厳密な方法で発見されており、暗号署名されたエージェントカードと呼ばれるものを割り当てます。私たちはこれについてGoogleとも非常に緊密に協力しており、A2Aグループでも非常に活発です。agencyだけでなく、もちろんここでは業界の他の部分とも連携しています。
TBACがクールなのは、特定のエージェントが特定のツールにアクセスできるが、他のものにはアクセスできないようにする方法だからです。たとえばこの特定のエージェントがこのツールにアクセスしようとする理由はないので、永久に禁止します。でももっと興味深いことをしています。エージェントに特定のタスク、マイクロタスクを与えるとき、エージェントはあなたのために100のことをしようとしているか、生み出されたサブエージェントの1つがこのミッションのために100のことをしようとしています。
でも特定の時点で、たとえばユーロとドルの為替レートをチェックしてくださいと、このエージェントに頼みます。エージェントはそれをやります。でももしエージェントが「ああ、これをするために取引もする必要があります」と言ったら、あなたは「なぜ取引が必要なんだ。チェックを頼んだだけだよ」と思うでしょう。
このような意味レベルでの検証は、まさに私たちがやっていることです。独立したマイクロエージェントが来て、エージェントが呼び出そうとしているツールの種類が、エージェントに与えられたタスクと一致しているかチェックするんです。ガードの例をもっと挙げることもできますが、これで導入の観点から、どのようにコントロール下に置いているかのイメージがつかめたと思います。
そうですね。これらのものが最も役立つのは、最も多くのデータへのアクセスを与えたときだと思います。でも一方で、それは物事が少し厄介になる場所でもあります。だからこれが業界が解決する必要があることだと思います。そのアクセスと安心感や快適さをどう組み合わせるか。簡単ではありませんね。
いや、あなたは100%正しいです。まさにその通りです。そしてこれは、エージェンシーのないエージェントは役に立ちません。
その通りです。エージェンシーが多すぎるエージェントは危険になり得ます、特にコントロールを失うと。これは少しOpenClawで見たものです。OpenClawは素晴らしい技術ですが、もちろんセキュリティは今OpenClawにとって大きな焦点になっています。でも最初は、これが問題でした。多くのエージェンシーがあり、クールなことができましたが、レールから外れることもあったんです。これは問題です。
でも他にも、エージェントのグループを一緒に働かせようとするときの課題があります。だからこそ、私たちが構築している別のものがあるんです。少しお時間をいただけるなら、Alex、私たちが構築しているレイヤーを説明します。2つあるので、比較的シンプルです。
Internet of AgentsとInternet of Cognition
車輪を再発明したくないので、すべては既存のインターネット上で動いています、それは既に当然のことです。その上に、クラウドネイティブスタック、クラウドネイティブ開発者が使用するスタックがあります。これが、私たちが今日愛用しているすべてのアプリケーションを開発した方法です。すべてのSaaS、すべてのモバイルのものは、これで開発されてきました。それがクラウドネイティブレイヤーです。
そして私たちがagencyで行ったのは、新しいレイヤーについて考える時が来たと言ったことです。ちなみに、非常に具体的に言うと、OSIモデルを拡張する論文も公開しています。ほとんどのエンジニアはOSIモデルの7レイヤー、IPスタック、異なる通信レイヤーを知っているでしょう。レイヤー7は本当に過去15年間世界が生きてきた場所です。すべてがアプリケーションレベルです。QuickからHTTPまで、すべての最新のトランスポートはレイヤー7にあり、これは良いことです。
でも私たちは、エージェント技術にとって、2つの新しいレイヤーが出現していることを認識する時が来たと考えました。1つは構文レイヤーと呼ぶものです。これは本当にエージェント同士を接続するレイヤーで、A2AやMCPのようなプロトコルが存在する場所です。これが私たちがagencyで焦点を当ててきた場所です。
そして私たちの議論によれば、これは絶対に必要だが十分ではないと認識して、今、最後の、そして最後であることを願うレイヤーを追加しています。これがレイヤー9で、セマンティックレイヤーです。ここでは実際にメッセージの内容について気にします。通常、IPパケットを転送するとき、箱の中に何があるかなんて誰も気にしませんよね。IPパケット、内容は何でもいい。でもレイヤー9では、メッセージが何についてのものか、何を言っているのかの指標を与えるヘッダーを形成し始めます。
これは、エージェントが別のエージェントと意図を共有しようとしているのか、単に知識を共有しているのか、タスクを委任しようとしているのか、といったことです。これらのレイヤー9プロトコルが、現在私たちが構築しているプロトコルで、エージェント同士が同期し、私たちが期待する適切な認知と認知的行動を持てるようにするためのものです。
なるほど。ちなみにagencyのスペルは標準的なスペルとは少し違いますね。A-G-N-T-C-Yですね。ショーノートにリンクを貼っておきます。
母音なしです。母音なしです。そう、最初にAがあって、最後にYがあって、その間には誰もいません。ええ、良いポイントですね。そうしないと人々が見つけるのに苦労するかもしれません。はい。
ええ、間違いなくリンクを貼ります。もう少し具体的にしていただけますか。エージェントのスウォームが、単一のエージェントには必ずしもできないことで、何ができると期待されますか。これが理想的な形で機能するとき、どんな感じになるのでしょうか。
具体的なユースケース:IT障害対応
それは素晴らしい質問ですね。私たちが考える簡単な方法は、クロスドメイン、クロスファンクショナルなエージェントについて考えることです。例を挙げましょう。たとえば、ITインフラの重大な障害を解決するためのエージェントソリューションが欲しいとします。
ちなみにAgentic Opsは素晴らしいもので、これは明らかに、個人としてもCiscoとしても、私たちの庭先の大きな応用分野です。ITシステムのエージェント運用、それが私たちの仕事です。そして私たちは、エージェント技術が生産性と節約の面で大きなインパクトをもたらすのを目にしています。
例を取りましょう。かなり悪いIT危機があったとき、物事を正常に戻すことができるエージェントシステムが欲しい。これは複雑な問題です。SRE、サイト信頼性エンジニアの側面があります。
ちなみに、これについて簡単に補足すると、私のチームでは実際に独自のエージェントSREシステムを構築しました。マルチエージェントシステムで、CAPEと呼ばれるものです、C-A-I-Pです。そしてこれをCNCF Canoe COEというグループと共に完全にオープンソース化しました。これは基本的に、AWS、Adobe、私たち、そして他の多くの大企業の人々がSREとプラットフォームエンジニアリングの最先端を進めているグループです。
非常に具体的な例を挙げています。このSRE、サイト信頼性エンジニアのエージェントが必要です。なぜなら、もちろんプラットフォーム上で行動できる必要があるからです。セキュリティエージェントも必要です。なぜなら問題にセキュリティの側面があるかもしれないからです。そして大量のオブザーバビリティエージェントも必要です。そしてこれらは同じエージェントではあり得ません。これらはそれぞれ独自の完全なドメインです。
典型的には、あなたのオブザーバビリティエージェントは、もしあなたがSplunkの顧客ならSplunkから来るでしょう。なぜなら、それがあなたにオブザーバビリティエージェントを提供できる明らかに最高のチームだからです。セキュリティエージェントはCiscoや他のセキュリティプロバイダーから来るでしょう。あなたのSREエージェントは、SREプロバイダーの1つから来るかもしれないし、あるいは自分で設計したかもしれないし、あるいはCAPEを使っているかもしれません。
そして他のエージェントもあります。たとえば危機コミュニケーションエージェントです。なぜなら、これについて話す必要があるかもしれないし、障害について顧客や世界に伝える必要があるかもしれないからです。そして既に、私が今述べた5、6個のエージェントで、これらのエージェント間の調整が必要だとわかります。そしてそれが、このミッションを達成する唯一の方法です。
具体的な例を挙げるために、これが私たちが持っている野心のレベルです。これを超知能と呼ぶか、単なる通常の知能と呼ぶかはともかく、私たちが行っている多くの実験は、このような状況をコントロール下に置こうとするのに何時間も、時には何日もかかっていたものが、うまくいけばわずか数分になることを示しています。これは非常に重要になるでしょう。
そして他のエージェントもあります。トラブルシューティングを見つけるエージェント、いわゆる根本原因分析を行うエージェントです。私たちはこれについて驚くべき結果を得ました。文字通り、専門家を部屋に3日間置いていたのが、わずか数分になりました。
とにかく、なぜ私たちがこれをやっているのか、非常に具体的になることを願っています。ただ明確にしたいのは、私たちは良い結果を持っていますが、まだ完全にはそこに到達していません。エージェントを接続したい、ワークフローに従いたい、ええ、私たちは既に多くの良いものを持っています。
複雑な自己形成を入れたい、なぜならIT障害のソリューションの場合、エージェントのチームは障害に依存する計画を作成するからです。もちろん彼らはプレイブックを通過できますが、これは硬直しすぎています。これは私たちが見たことのない新しいものかもしれません。新しい攻撃や、これまで見たことのない新しい障害が毎日ニュースで報道されていますよね。
だから、自己形成、真の推論、エージェントの認知的協力がどれほど必要か、おわかりでしょう。そしてこれが私たちが可能にしたいことです。でも課題があります。このようなものを可能にするための課題があります。
エージェント間の技術的差異
Guom、ちょっと聞きたいことがあるんですが、これは私がしばらく疑問に思っていたことなんです。エージェントスウォームについて考えるとき、コーディネーターエージェントがいて、SREエージェントがいて、さまざまなタイプのエージェントがいますよね。それは異なる基盤技術なんですか、それとも同じエージェントまたはサブエージェント、同じエージェントが単に異なるプロンプトで何か別のものを探すようにタスクを与えられているだけなんですか。エージェント間の差別化は何ですか。
ええ、それは、まあ、状況によります。たとえばOpenClawのようなシンプルでありながら強力なエージェントソリューションを見ると、それらは大体同じですよね。背後のモデルを変えることができ、異なるプロンプトを与えることができ、おそらく異なるスキルへのアクセスを与えることができますが、大体同じタイプのパターンです。
でも私の例に戻ると、エージェントがコード化、作成された方法の多様性ははるかに広くなり得ます。なぜなら、彼らは完全に異なるドメイン、異なる会社から来るからです。たとえばCiscoのエージェントやMicrosoftのエージェント、Salesforceのエージェントを一緒に連れてくる必要があるかもしれませんが、企業のクロスファンクショナルなユースケースを解決するために、これらは同じではないでしょう。単なるプロンプトではなく、これらははるかにそれ以上のものです。
彼らはメモリを使い、特定のガードレールを使い、私たちが認知エンジンと呼ぶもの、つまりこれらのエージェントがどのように協力できるかのアクセラレータを使うかもしれません。だから非常に異なるでしょう。
正確に質問に答えると、複雑さが増し、私たちが前に言ったように、漸近的に超知能と呼べるものに向かって進むにつれて、非常に異質で、非常に異なるタイプのエージェント、異なるベンダー、異なるクラウド、異なる技術フレームワークが、それでも一緒に協力しなければならなくなります。
スタックに1つの多目的エージェントがあり、そのエージェントの基盤にこれらの大きな汎用モデルの1つがある一方で、1つのタスクだけを持つ1つのエージェントがあれば、より軽いモデルで実行できるので、コンピューティングとコストがそれほど集中的ではないという考え方は正しいですか。
その通りです。私が言及したように、私たちはこれをすぐに共有する予定ですが、TBACのような機能、セマンティックTBACのために、現在は接続したいモデルを使っています、実際にソリューションを動かすためのモデルを選んでください。
でも私たちは、はるかに小さく、小型になる小規模言語モデルにも取り組んでいます。だからこそ小規模言語モデルと呼ばれるのです。それがこのような機能を動かすことになります。
これは重要です。なぜなら、考えてみると、TBACは通常、各エージェントにサイドカーを通じて提供するものだからです。つまり、各エージェントには、このエージェントとのネットワーク通信を制御し、ポリシーを適用し、セマンティック検証、つまり私たちが認知エンジンと呼ぶものを適用するサイドカーがあります。
つまり基本的に、エージェントがツールを呼び出すたびに、LLMへの追加の呼び出しを1回生成する可能性があるということです。そしてこのLLMが高価であれば、このレベルを適用するのに指数関数的に莫大な費用がかかり始める可能性があります。
だからこの時点で、これらのルーティンタスクのための小規模言語モデルを持つこと、高度に特化していて、汎用モデルと同じくらい効率的だが、これだけしかできないが非常にうまくやる、というのは経済的に非常に重要です。
そして私たちはそれを強く意識しています。企業はセキュリティ、オブザーバビリティ、説明可能性を必要としますが、同時にこれらのマルチエージェントシステムのコストのコントロールも必要とします。
オープンソース戦略の理由
ちょっと聞かせてください。あなたは何度か、取り組んでいるプロジェクトの一部をオープンソース化していると言及されました。それを見られて嬉しいのですが、なぜそうしているのか気になります。なぜなら、私の認識では、あなたが取り組んでいるものは、Ciscoが競合他社に対してエッジを得るために社内に留めておきたいもののように思えるからです。それなのにここでオープンソース化している。そこの論理を説明してください。
ええ、聞いてくださって嬉しいです。なぜなら、私たちは、目の前にあるものは本当にCiscoだけでなく、エコシステム全体にとっての課題だと考えているからです。ちなみに、インターネットのルーツに戻ると、インターネットは当時、オープンで相互運用可能なシステムとして設計されました。そしてその上にデジタル経済と呼ばれる小さなものが出現したことに気づきました。
だから私たちはこのモデルを再現することに夢中になりました。エージェント技術が来るのを見て、これは非常に深遠だったので、これは閉じた庭に生きているだけではいけない、オープンで相互運用可能な基盤に基づかなければならないと考えました。だからこそInternet of Agents、Internet of Cognitionと呼んだんです。
そして正直に言うと、これらは複雑なトピックです。だから私たちは喜んで貢献しています。多くのアイデアがあります。でも、どの会社も単独でこれをすることはできません。私たちはエコシステムとしてこれを行う必要があり、これがエコシステム全体の価値を最大化する方法であって、一部のプレーヤーだけのためではありません。だからこそ私たちはこれをやっているんです。
そしてCiscoが差別化することについては、あまり心配していません。なぜなら、最近ではベロシティによっても差別化するからです。私たちはイノベーションのベロシティに焦点を当てており、そこで製品チームが多くのことをやっています。そして私たちの役割は、この関連技術の一部をできるだけ早くCiscoの仲間、Splunk、AI Defense、私たちが協力している他のチームに届けることです。
私たちが行うことの100%を必ずしもオープンソース化するわけではありません。もちろん、いくつかのものは、この技術は社内に留めておき、社内でのみ卒業させることができます。でも、私たちがやることのおそらく80%以上はオープンソースである必要があると言えるでしょう。なぜなら、私たちはこのオープンで相互運用可能であることの重要性を実際に信じているからです。
開発の現状と今後の展望
そうですね、ベロシティのポイントはよくわかります。物事は速く動いています。ええ、物事は本当に速く動いています。だからこそ私たちは今、多くの実験を行っている最中なんです。
非常に具体的に言うと、Internet of Agentsは公開されています。実運用に入っています。先ほど述べたように、A2Aと密接に結びついています。そして4つの技術要素、オブザーバビリティは既にSplunkを通じて利用可能で、多くのものをオープンソース化してきました。そして多くのプレーヤーがこれを行っています。オブザーバビリティ、接続性、エージェントのアイデンティティ、発見、これらのすべての技術は今日使用可能で、公開されています。
Internet of Cognitionについては、まだ取り組んでいるところです。1月にビジョンを示したホワイトペーパーを公開しました。そして私たちはアーキテクチャに懸命に取り組んでいます。4月の後半には、すぐにいくつかのコードをリリースする予定です。これは控えめな始まりに過ぎず、ツールやサンプルを共有し始めて、人々がインスピレーションを得られるようにします。
そして私たちは押し進め続けます。アーキテクチャを検証するために現在行っていることの1つは、多くの実験を行い、エージェントのスウォームを集めたときに、どこで脱線し始めるかを見ることです。私たちは、これらのマルチエージェントで繰り返し発生する、7つか8つの認知的問題の分類を持っています。そして私たちはそれらを1つずつ取り組もうとしており、エージェント間のこれらの認知的問題を軽減または除去できるアーキテクチャを構築しようとしています。それによって、彼らが非常にうまく機能できるようにするためです。
わかりました、Guom。もし人々がもっと学び、参加したいと思ったら、どこに行けばいいですか。
それは非常にわかりやすいですよ、Alex。私たちはoutshift.cisco.comというウェブサイトを持っており、そこですべてのニュースを発信しています。Internet of Cognitionのサブページを探してください。なぜなら、そこでコードを公開しているからです。そしてコードへのリンクがあり、Internet of Cognitionのインフラが、異なる種類のエージェント間で、より複雑なミッションを調整するのにどう役立つかを示す初期インフラが表示されます。
私たちはホワイトペーパーを持っています。アーキテクチャについて公開し始めた、より学術的な論文へのリンクもあります。そして最後に、今日ビデオで説明したすべてのコンセプトについての非常にクールなデモもあります。だからぜひチェックしてください。忙しく過ごせるものがたくさんあります。そして注目し続けてください。なぜなら、今後数ヶ月でさらに多くのコンテンツを展開する予定だからです。
素晴らしいですね。旅を追うのを本当に楽しみにしています。今日すべてを共有してくださってありがとうございました。感謝しています。
ありがとうございます、Alex。そしてぜひ参加してください。なぜなら、これは私たちだけでできることではないからです。私たちが行っているすべてのオープンソースの背後には、参加し、貢献し、私たちと一緒に楽しむためにオープンなワーキンググループがあります。
素晴らしいですね。ありがとうございます、Guom。そして皆さん、ご視聴ありがとうございました。今週後半にチャンネルで別の動画でお会いしましょう。


コメント