Cisco Live 2026がエンタープライズスタックマップに5番目のエージェント control plane を追加した

Microsoft、Salesforce、SAP、ServiceNowに並ぶ5番目のエージェント control plane としてのCisco AgenticOps

Turn this article into takeaways for your work.

Each assistant summarizes the article only for you and suggests best practices for your work.

2026年のCTOによるエージェントプラットフォームマップのほとんどは4行で構成されていました。生産性向けのMicrosoft、顧客対応業務向けのSalesforce、財務・調達(procurement)向けのSAP、IT・従業員サービス向けのServiceNowです。Cisco Live 2026 が5行目を追加しました。そして、ほとんどのエンタープライズアーキテクチャ文書には、まだそのための枠がありません。

この空白は、火曜日の基調講演スライドで見るよりもはるかに重要です。5つのエージェント control plane はお互いに競合しません。それぞれがソフトウェアエージェントが動作する異なるサーフェスを持っています。しかし、それらのサーフェスが交差する場所では、ガバナンス、監査証跡、インシデント対応がすべて分断し始めます。そして現時点で、その境界線を引いたエンタープライズチームはほぼ存在しません。

Cisco が Cisco Live 2026 で実際に出荷したもの

Cisco Live 2026はラスベガスのマンダレイベイで5月31日から6月4日にかけて開催され、75カ国から約2万人の参加者を集めました。CEO のチャック・ロビンスが6月2日火曜日の基調講演に登壇しましたが、ヘッドラインは新しいスイッチやルーターではありませんでした。改訂されたAIインフラ受注目標でした。

Channel InsiderとNetwork Worldの報道で引用された投資家向け開示によると、Ciscoは通年のAIインフラ受注予測を、以前の50億ドルから90億ドルへと引き上げました。1回の決算サイクルでほぼ2倍になったことは、Ciscoがエンタープライズインフラ支出の方向について持つ確信の強いシグナルです。

その数字を支えるプロダクトの話がAgenticOpsです。Ciscoは2026年2月のCisco Live EMEAでAgenticOpsを最初に発表し、2026年2月10日のCisco Newsroomの発表でポートフォリオ全体に展開を拡大しました。ラスベガスが開幕する頃には、ロードマップは発表から本番環境(production)へと移行していました。

2026年5月のGA(一般提供)マイルストーンは、Cisco Security Cloud Control内のファイアウォール運用とコンプライアンスをカバーします。アジェンティックコンプライアンスは継続的に稼働し、PCI-DSS要件に対してファイアウォール設定を評価し、スケジュールされた監査サイクルを待たずに修正案を提示します。これにより、ネットワークセキュリティポスチャは定期的なレビューから継続的モニタリングへとシフトします。

2026年6月の限定提供(controlled availability)リリースには、Automation Builder Agent、Triage Agent、データセンター機能が含まれます。Detection Builder AgentとGuided Response Agentはプレリリーステスト中です。Ciscoはまた、モバイルアプリを通じてMeraki とCisco Catalyst Centerからネットワークインサイトを取得・優先順位付けするエージェント内のModel Context Protocol(MCP)サーバーを使用しており、ネットワークエンジニアがチャットスレッドで質問するように自社インフラをクエリできるようにしています。

Key Facts

  • Ciscoは通年のAIインフラ受注予測を50億ドルから90億ドルへ引き上げた(Channel InsiderとNetwork Worldを通じたCisco投資家開示、2026年6月)
  • 2026年5月のAgenticOps GAマイルストーンには、Cisco Security Cloud Control内のファイアウォール運用とPCI-DSSアジェンティックコンプライアンスが含まれる(Cisco Newsroom、2026年2月・5月)
  • Cisco AI Defense は2026年3月にエージェント専用のセキュリティ機能を追加し、アジェンティック従業員環境を対象としている(Cisco Newsroom、2026年3月)

ネットワーク・セキュリティ層が独立した control plane として数えられる理由

エンタープライズアーキテクチャにおけるデフォルトの直感は、Ciscoをインフラとして扱うことです。ネットワークはパイプであり、エージェントはパイプの上で動くという考え方です。このモデルは、エージェントが人々のソフトウェア操作を意味していたときは成立していました。エージェントがネットワーク変更を自律的に行い、セキュリティ修正をトリガーするソフトウェアプロセスになると、このモデルは崩れます。

Cisco Live 2026 でCiscoをインフラベンダーからエージェントプラットフォームへとアップグレードする3つの変化がありました。

第一に、AgenticOpsはインサイトを表示するだけでなく、アクションを取るエージェントを出荷します。設定ワークフローを組み立て実行するAutomation Builder Agentは、アラートを表示するダッシュボードとは異なるカテゴリーです。ネットワーク変更を実行するエージェントは独自のアクションサーフェスを所有し、そのサーフェスには独自のガバナンス層が必要です。

第二に、Cisco AI Defense にはエージェント専用のセキュリティコントロールが追加されました。2026年3月のリリースは、人間ではなくソフトウェアエージェントが認証されたコールを行う環境向けに設計された機能を追加しました。これは、アジェンティック環境の脅威モデルが人間のオペレーターを中心に構築されたものとは構造的に異なるという認識です。

第三に、Model Context Protocol(MCP)の統合により、CiscoのネットワークレイヤーはWM他のプレイン上のエージェントから直接呼び出し可能になりました。Microsoft 365内のエージェントは、MCP サーバー経由でMerakiのネットワークコンテキストを取得できます。これはCiscoがパイプとして機能していることではありません。他のプラットフォームのエージェントがクエリするAPI サーフェスとして機能しているということです。別のプラットフォームのエージェントがCiscoのMCPエンドポイントを呼び出すようになると、プレイン間の境界は急速に複雑になります。

5つの Control Plane 監査

Cisco AgenticOpsによって追加されたネットワーク・セキュリティ層を示す5つのエージェント control plane 図

2026年初頭のエンタープライズアーキテクチャマップの多くは4つの control plane を中心に描かれていました。以下のフレームは5番目を追加し、各 control plane がCTOに迫るQ3の意思決定を名指しします。

Control Plane 担当ドメイン 主要エージェントユースケース 監査サーフェス Q3の意思決定
Microsoft Agent 365 生産性、Office、ID(Entra) メールトリアージ、ドキュメントワークフロー、Teamsトランスクリプト Microsoft Purview Microsoft 365内のエージェントアクション境界をどこに引くか
Salesforce Agentforce CRM、顧客エンゲージメント、Slack 顧客対応エージェント、営業フォローアップ、サポートルーティング Salesforce Shield、AppExchange Slack内のアジェンティック活動がCRMへの書き戻しサーフェスになるかどうか
SAP Joule ERP、財務、調達(procurement) 調達ワークフロー、ベンダーオンボーディング、決算処理 SAP Cloud ALM 財務決算プロセスのアジェンティックな深度をSAPに委ねるかどうか
ServiceNow ワークフロー、ITサービス、HRサービス チケッティング、インシデントルーティング、従業員リクエスト ServiceNow AI Control Tower ServiceNowワークフローエージェントがどこで他のプレインに引き渡すか
Cisco AgenticOps ネットワーク、セキュリティ、オブザーバビリティ ファイアウォール修正、脅威トリアージ、ネットワーク変更 Cisco AI Defense、Splunk、AgenticOps Triage Agent ネットワークエージェントが本番環境(production)での自動変更をトリガーするかどうか

この表は、各プラットフォームを単独で見ていると明らかにならないことを示しています。これら5つのプレインは冗長ではありません。それぞれが異なる領域を所有しています。しかし、実際のエンタープライズ環境では常に交差し、各交差点でのアクションを誰が所有するかという問いは、ほとんどのアーキテクチャ文書で未回答のままです。

例えば、顧客エスカレーションを処理しているSalesforce Agentforceエージェントが、アクセスを復旧するためにVPNポリシーの変更が必要と判断したとします。Agentforceエージェントは顧客インタラクションを所有しています。Cisco AgenticOpsレイヤーはネットワーク設定を所有しています。そのシナリオにおけるこの2つのプレイン間の定義された引き渡しプロトコルはありません。誰かが2026年の本番環境(production)でそれに遭遇するでしょう。そして事前に答えが出ていなければ、インシデント対応はその場の対応になります。

同じダイナミクスはServiceNowとSAPの間でも展開されます。ベンダーオンボーディングワークフローを完了するServiceNow調達エージェントは、SAP JouleでPO(発注書)をトリガーする必要があるかもしれません。どちらのプレインもエージェントを持っています。どちらのプレインのガバナンスフレームワークも、自社のエージェントがプロセス境界で相互作用するときに何が起きるかを明示的にカバーしておらず、それが監査証跡が壊れる場所であり、「どのシステムが責任を持つのか?」という問いへの回答が不可能になる場所です。

境界が実際に壊れる場所

最初の失敗モードはファイアウォールルールの衝突です。承認されたワークフロー内で動作するMicrosoft 365エージェントが、営業チームのために新しいSaaSツールを許可する必要があるとします。エージェントはMicrosoftテナント設定を更新できます。しかしトラフィックを許可するネットワークレベルのファイアウォールルールはCisco Security Cloud Controlが所有しています。CiscoのアジェンティックコンプライアンスレイヤーがPCI-DSS に対して設定を評価している場合、Microsoftエージェントの変更は有効なコンプライアンスルールと競合する可能性があります。どちらのエージェントも相手の制約セットを把握していません。結果は、あるプレインでは完了するが別のプレインではサイレントに失敗する変更です。修正は、各プレインが行動前にクエリできる共有制約レジストリです。

2番目の失敗モードはSAPとServiceNowの引き渡しにおける監査ギャップです。ServiceNowインシデントチケットがSAP Jouleを通じてルーティングされる財務調整をトリガーするとき、ServiceNowのアクションログはチケットのクローズを記録し、SAPログは財務イベントを記録します。しかし、それらをつなぐ因果連鎖は、コンプライアンスレビュアーが追跡できる形でいずれのシステムの監査証跡にも現れないかもしれません。SOXまたは同様の規制に従う組織にとって、それは最悪のタイミングで手動監査が浮かび上がらせる文書上の問題です。

3番目の失敗モードはSalesforce WebhookからCiscoネットワークポリシーへのパスです。Salesforce Agentforceエージェントは顧客ワークフローの一部としてアウトバウンドWebhookをトリガーできます。顧客アカウントのステータス変更がCisco経由で管理されるパートナーネットワークのアクセスルールを更新する必要がある場合、WebhookはSalesforceから発火し、受信エンドポイントはCiscoのネットワークポリシーレイヤー内に位置します。Cisco AgenticOps Triage AgentがインバウンドWebhookを異常とフラグした場合、Salesforceエージェントのアクションはどちらのプラットフォームのオペレーターも迅速に診断できない明確なエラーなしに停止します。

3つの失敗モードはすべて同じ前提条件の修正を必要とします。エージェントが本番環境(production)で実行を開始する前に、誰かがクロスプレインのアクションマッピングを所有する必要があります。

今週すべきこと

アクション1: 現在のエージェントプラットフォームマップに「ネットワークとセキュリティ」の行を追加する。 アーキテクチャ文書にエージェント control plane の4行があり、Ciscoの行がない場合、今週更新してください。行は完全である必要はありません。ネットワーク層をインフラとしてではなく、アジェンティックサーフェスとしてチームが扱うために存在する必要があります。まずすでにGAになっているCisco AgenticOpsの機能、ファイアウォールのアジェンティックコンプライアンスとSecurity Cloud Controlから始めてください。

アクション2: 自社環境で頻度の高いクロスプレインアクションを2つか3つ特定し、アクションごとに単一のオーナーを割り当てる。 エージェントが来る前に、今2つのプラットフォームがデータを交換したり、お互いのプロセスをトリガーしたりしているワークフローのリストを取り出してください。それらがエージェントが入ってきたときに最も高リスクな交差点です。それぞれの引き渡しガバナンスについて責任を持つ人を1人選んでください。その人はウィーク1にクロスプレインプロトコルの問題をすべて解決する必要はありません。インシデントが答えを強制する前に、その問題が自分のものだと知っておく必要があります。

アクション3: AgenticOpsの一般提供展開が始まる前に、2026年3月リリースのCisco AI Defenseエージェント機能についてセキュリティチームにブリーフィングする。 3月リリースは、人間ではなくエージェントが認証してアクションを取る環境向けに特別に設計されたコントロールを追加しました。セキュリティチームの脅威モデルはおそらく人間のオペレーター向けに書かれています。アクターがパスワードを入力する人ではなく、永続的な認証情報を持つエージェントになるときに何が変わるかについてブリーフィングが必要です。Cisco Automation Builder AgentやTriage Agentが本番環境(production)に入った後ではなく、前にそのブリーフィングを実施してください。

関連記事


FAQ

Cisco AgenticOpsとは何ですか?一般提供はいつですか?

Cisco AgenticOpsは、ネットワーク運用、セキュリティコンプライアンス、インフラワークフローを管理するAIエージェントのためのCiscoのフレームワークです。Ciscoは2026年2月のCisco Live EMEAで最初に発表しました。最初のGA(一般提供)マイルストーン、すなわちCisco Security Cloud Control内のファイアウォール運用とPCI-DSSアジェンティックコンプライアンスは、2026年5月に出荷されました。Automation Builder AgentとTriage Agentは2026年6月に限定提供(controlled availability)に達しました。

ネットワーク・セキュリティ層が独立したエージェント control plane として数えられるのはなぜですか?

Cisco AgenticOpsエージェントは今やインサイトを表示するだけでなく、アクションを取ります。Cisco AI Defenseは2026年3月にエージェント専用のセキュリティコントロールを追加しました。アジェンティック環境の脅威モデルが人間のオペレーターモデルとは構造的に異なるためです。また、Model Context Protocol(MCP)の統合により、CiscoのネットワークレイヤーはWM他のプラットフォームのエージェントから直接呼び出し可能になり、MicrosoftまたはSalesforceエージェントがCiscoのネットワークサーフェスをAPI としてクエリできます。これはプラットフォームとして振る舞うインフラです。

CTOはCisco AgenticOpsと他のエージェントプラットフォームの重複をどう扱うべきですか?

エージェントが本番環境(production)で実行を開始する前に、クロスプレインの交差点をマッピングしてください。今2つのプラットフォームがデータを交換したり、お互いのプロセスをトリガーしたりしているワークフローを2つか3つ特定してください。それらはエージェントがアクションステップを引き継いだときに高リスクになります。交差点ごとに単一の名前付きオーナーを割り当て、各プラットフォームのエージェントが遵守すべき制約セットを文書化してください。この作業は統一された orchestration プラットフォームを必要としません。各プレインのエージェントが行動前に参照できる共有制約レジストリが必要です。

About the author

Victor Hoang

Victor Hoang

Co-Founder, Rework.com

Victor Hoang is Co-Founder and CMO of Rework. He spent 12+ years scaling B2B SaaS growth, building a lead engine that generated over 1 million leads and $10M+ in annual recurring revenue. Today he builds AI agents and MCP servers into Rework's products to empower customers across growth and operations. He writes about what actually works.