Cohesity Agent Resilience、AIエージェントが生むリカバリーギャップを狙う

Cohesityは9月16日、AIエージェントと、それらが変更可能なシステムにまでリカバリー保護を拡張するCohesity Agent Resilienceを発表した。この新機能には、人的承認を外さずにサイバー対応の自動化を進めるという、より難しい約束が伴う。

この違いは重要だ。企業向けエージェントは、受動的なアシスタントではなく、能動的なオペレーターになりつつある。メモリーを保持し、アプリケーションを呼び出し、データベースを更新し、ワークフローを実行する。検知によって有害な操作を明らかにすることはできるが、検知だけではエージェントを復元したり、影響を受けたすべてのリソースを元に戻したりはできない。

Cohesityは、エージェント、その状態、接続されたインフラを、ひとつの復元可能なシステムとして扱っている。Commvault、Druva、Rubrikも関連するアプローチを進めており、AIエージェントのリカバリーはデータ保護市場における新たな競争領域になっている。

Cohesity Agent Resilienceはエージェント以上を保護する

Cohesity Agent Resilienceは、AIエージェントのメモリーと設定を復元可能な運用状態として扱う。

Cohesityは、9月16日と17日に複数地域で開催されたCatalyst 2026のバーチャルイベントでこの機能を発表した。同社は以前、Catalystでマルチエージェント環境と自律的なリカバリーワークフロー向けの新しい制御機能を導入すると述べていた。

エージェントの状態には、その動作に影響する保存済みコンテキストと設定が含まれる。悪意ある指示、設定ドリフト、または破損したメモリーによってその状態が変化した場合、データベースを復元してもエージェントの判断が復元されるとは限らない。

Cohesityによると、この新機能はその状態に対するポイントインタイムリカバリーの選択肢を提供する。管理者は、影響を受けたエージェントを再構築して蓄積されたコンテキストを失う代わりに、既知の正常なバージョンへ戻すことができる。

保護はエージェント周辺のインフラにも及ぶ。同社のagent recovery overviewによれば、その範囲には、アプリケーション、データベース、ファイルシステム、メモリーストア、およびエージェントが使用または管理するその他のサービスが含まれる可能性がある。

このより広い範囲は、エージェント型ソフトウェアにおける基本的な問題に対応する。エージェントはメモリーが破損していても機能し続ける可能性があり、あるいは復元されても、接続先システムに有害な変更を残す可能性がある。

そのためCohesityは、リカバリーの作業を2つに分けている。ひとつはエージェントを信頼できる状態に復元すること。もうひとつは、その操作によって影響を受けたリソースを特定し、復旧することだ。

同社は両方の作業に、確立されたデータ保護メカニズムを使用している。これにはスナップショット、不変バックアップ、そしてしばしばクリーンルームと呼ばれる隔離リカバリー環境が含まれる。

クリーンルームは、本番環境へ直ちに再接続せずにシステムを調査・復元するための分離環境だ。対応チームは、復旧したコンポーネントが侵害されたままでないかを確認できる。

同社はまた、各エージェントをそのメモリー、アプリケーション、データベース、支援インフラに対応付けるエージェントトポロジーについて説明している。この関係マップは、保護上のギャップを示し、信頼できるリカバリーに必要なすべてを特定することを目的としている。

Cohesity Agent Resilienceは当初、Amazon Bedrock AgentCoreとBedrock Agentsをサポートする。一部の顧客はすでに利用可能で、一般提供は2026年末を目標としている。Microsoft AzureとGoogleのプラットフォームはロードマップに残されている。

こうした制限から、これは汎用的なエージェントリカバリー層ではなく、焦点を絞った初回リリースといえる。Cohesityは、このモデルが異なるクラウド、エージェントフレームワーク、メモリーシステム、権限構造にわたって機能することを示す必要がある。

それでも、この発表はリカバリーの境界を変える。バックアッププラットフォームは伝統的にデータとアプリケーションを保護してきた。Cohesityは現在、エージェントの運用メモリーも本番環境の活動を直接左右し得るため、その境界の内側に属すると主張している。

報じられたローンチの詳細とロードマップは、元のagent resilience coverageにも記載されている。中心となる考え方は単純だ。企業には、エージェントが触れた資産だけでなく、その行為者自体を復元する手段が必要である。

AIエージェントは従来のリカバリー計画に圧力をかける

AIエージェントは、侵害されたひとつの判断が複数の接続システムへ波及し得るため、インシデントの影響範囲を拡大する。

従来のリカバリー計画は一般に、チームが損傷したワークロードを特定し、正常なコピーを復元し、得られた環境を検証できることを前提としている。AIエージェントはコンテキストを保持し、アプリケーション境界をまたいで操作するため、この流れを複雑にする。

チケット、顧客記録、ナレッジリポジトリにアクセスできる社内サポートエージェントを考えてみよう。破損した指示は、情報の漏えい、分類の変更、あるいは複数のシステムへの誤った内容の書き込みを引き起こす可能性がある。

チケット管理データベースを復元すれば、削除された記録は回復できるかもしれない。しかし、エージェントのメモリーから侵害された指示を取り除くことも、どの下流操作を取り消す必要があるかを示すこともできない。

同じ問題はソフトウェア運用にも現れる。設定の変更、デプロイ要求の作成、クラウドリソースの管理が可能なエージェントは、正規に認証されたものの有害な変更を連鎖的に生み出す可能性がある。

こうした操作は、従来型の侵入に似ていない可能性がある。エージェントは、汚染されたコンテキストや不適切な設定に基づいて動作しながらも、正当な認証情報と承認済みのインターフェースを利用する場合がある。

これが、CohesityがAIエージェントのリカバリーを単なる監視の問題ではなく、レジリエンスの問題として位置付ける理由だ。監視は動作を記録する。リカバリーは信頼できる時点を確立し、その後に損害を受けたシステムを復元する。

Cohesityの最高製品責任者であるVasu Murthyは、このギャップを端的に要約した。検知はエージェントが逸脱したことを示せるが、変更を取り消すことはできない。この主張は、同社が状態と依存関係の両方を保護する理由を説明している。

最初に圧力を受けるのは、セキュリティチームとインフラチームだ。どのエージェントメモリーが重要か、どの頻度で取得するか、接続リソース全体のリカバリーをどう調整するかを決めなければならない。

AIエンジニアリングチームも関連する負担に直面する。保護システムがエージェントのバージョン、設定、メモリーストア、権限、外部依存関係を識別できるよう、十分な情報を提供する必要がある。

アプリケーションの所有者もリカバリーチェーンに加わる。データベース、アイデンティティ制御、業務アプリケーションが不整合な状態のままであれば、エージェントを正常に復元しても価値は限定的だ。

組織上の問題は、ストレージの問題より難しくなる可能性がある。異なるチームがエージェント、モデルアクセス、基盤データ、接続された各アプリケーションを所有している場合があるためだ。

Cohesityのトポロジー概念は、インシデントの前にこうした関係を可視化しようとするものだ。最新の依存関係マップは、どのシステムを調査すべきか、どの復旧順序なら整合性を維持できるかを対応チームに示せる。

このマッピングは、目標復旧時間と目標復旧時点も支える。RTOはサービスがどれだけ早く復帰すべきかを定義し、RPOは組織が失っても許容できる直近の状態の量を定義する。

エージェントでは、これらの指標はより不明確になる。昨日のメモリーを復元すると有用なコンテキストが失われる可能性があり、今日のメモリーを復元するとインシデントの原因となった破損が残る可能性がある。

そのためチームには、永続的な知識と一時的な状態を区別するポリシーが必要になる。また、どのエージェント操作を自動的に取り消せるか、どれに業務上のレビューが必要かも決めなければならない。

Cohesityの提案は、他のバックアップベンダーにも圧力を生む。顧客は、リカバリー計画がこのより広いシステム境界に従うことを期待するようになるためだ。自律型ソフトウェアがファイルとワークロードの両方を変更できるようになれば、それらだけを保護する方法は不十分に見える。

この問題は、高度に自律的なエージェントをまだ導入していない企業にも及ぶ。限定的なエージェントであっても、要約の作成、記録の分類、ツールの呼び出し、後続の判断に影響するワークフローの起動を行える。

したがって、エージェントレジリエンスは完全自律システムだけのものではない。重要な境界は、そのソフトウェアが状態を保持できるか、あるいはすべての操作を人間が確認せずに重大な変更を加えられるかどうかだ。

新たな競争はCohesityのAIエージェントリカバリー対断片化した制御機能

市場での競争は単純にCohesityと他社ベンダーの対決ではない。統合されたAIエージェントリカバリーと、分断された監視、バックアップ、アプリケーション制御との競争である。

企業にはすでに、エージェントリスクの一部に対処するツールがある。オブザーバビリティシステムはトレースを取得し、アイデンティティプラットフォームはアクセスを管理し、アプリケーションログは変更を記録し、バックアップ製品はデータを保持する。

リカバリーの問題は、これらの層の間に生じる。インシデントチームは不審なエージェントセッションを特定できても、そのメモリーと影響を受けたすべての依存関係を連携して復元する手段を欠く場合がある。

Cohesityは、自社のデータプラットフォームをその調整層にしたい考えだ。既存のスナップショットと不変コピーを活用しつつ、エージェントのトポロジーと状態に関する知識を追加できる。

このアプローチは、確立されたバックアッププロバイダーにとって自然な参入点となる。同社はすでに、多くの顧客向けにリカバリーコピーと隔離環境を管理している。

しかし、既存のインフラがエージェントの意味的な特性を自動的に解決するわけではない。プラットフォームは、どのメモリー項目、設定ファイル、プロンプト、ツール、認証情報、アプリケーション変更が特定の復旧時点に属するかを把握しなければならない。

競合各社は異なる方向から同じ問題に近づいている。RubrikのAgentCloudは、エージェント運用、ガバナンス、オブザーバビリティ、および意図しない操作を巻き戻す機能を重視している。

Rubrikはまた、Model Context Protocol、すなわちMCPを通じて、自社のサイバーレジリエンスデータを顧客のエージェントに公開している。MCPは、AIシステムが定義された制御のもとで外部ツールとデータにアクセスするための標準インターフェースだ。

この戦略により、エージェントはリカバリー情報を基に推論し、ガバナンスの下でワークフローを開始できる。最近のMCP integration detailsは、リカバリープラットフォームがより広範なAIシステム内で呼び出し可能なコンポーネントへと急速に変化していることを示している。

CommvaultはAI Protectを発表しており、接続環境全体でエージェントを検出し、その依存関係をインベントリ化するよう設計されている。計画されている記録には、モデル、設定、データソース、アプリケーション、インフラが含まれる。

Druvaは、エージェントの保護、エージェントを通じたバックアップ情報へのアクセス、AI攻撃の疑いに対する自動応答について説明している。これは、エージェントのリカバリーと、エージェント支援による調査を組み合わせるものだ。

これらのアプローチは重複するが、それぞれ異なる制御点を重視している。Cohesityは復元可能な状態と接続リソースを中心に据える。Commvaultは継続的な検出を重視する。Druvaは保護とセキュリティ調査を組み合わせ、Rubrikはガバナンスと可逆的な運用を結び付ける。

顧客は、各プラットフォームがエージェントの依存関係をどれほど深く理解しているかを確認すべきだ。下流のリソースをマッピングせずに設定だけを取得する製品は、問題の半分しか解決しない。

また、フレームワークの対応範囲も確認すべきである。CohesityがAWS Bedrockを最初にサポートすることで明確な統合対象は得られるが、多くの企業はカスタムフレームワークと複数クラウドサービスを組み合わせてエージェントを構築している。

リカバリープラットフォームは、すべてのエージェントを1社のオーケストレーションモデルに強制せず、そうした環境を扱う必要がある。オープンなインターフェースは役立ち得るが、管理者が扱うべき権限とセキュリティ上の判断も拡大する。

競争圧力は、3つの能力を結び付けられるベンダーに有利に働く可能性が高い。エージェント間の関係を発見し、信頼できるバージョンを保持し、依存システム全体で一貫した復旧をオーケストレーションする能力だ。

企業のエージェントスタック全体でこれが普遍的に機能することを示したベンダーは、まだ存在しない。製品発表は方向性を示すが、統合された復旧が断片化されたコントロールを上回るかどうかは、本番環境での実証によって決まる。

Cohesityの優位性は、既存の復旧基盤にある。課題は、その基盤が、エージェントの絶えず変化する状態を安全な復元を支えられるほど高い精度で表現できることを証明する点にある。

自律型サイバーレジリエンスは依然として人間の判断に依存する

Cohesityの自動化計画は反復作業を減らせるが、安全な復旧で何を保持すべきかを判断する必要性まではなくせない。

Cohesity Agent Resilienceと並行して、同社はAutonomous Cyber Resilienceと呼ぶ、より広範なビジョンを示した。これは、5段階のレジリエンスフレームワークの一部をエージェント型ワークフローで自動化するものだ。

この5段階は、保護、復旧可能性、脅威の修復、復旧訓練、そしてデータおよびAIのリスク態勢の継続的な改善を対象とする。提案されているシステムは、資産を継続的に発見し、保護状況を評価し、復旧準備の整合性を確認し、計画を更新する。

Cohesityによると、管理者はCohesity Copilotを通じて業務目標を設定する。その後、プラットフォームが関連するワークロードを評価し、保護ポリシー、脅威スキャン、復旧リハーサルを推奨する。

実行前には、人間がそれらの推奨を承認する。インシデント時には、管理者が影響を評価し、攻撃者の活動を示す兆候を探し、隔離された復旧環境を準備する自動ワークフローを開始できる。

このモデルは、完全自律型の修復より慎重な設計だ。発見、分析、準備、オーケストレーションはソフトウェアに担わせつつ、承認権限は人間のオペレーターに残す。

この境界は重要である。復旧の判断には、相反する目標が含まれるためだ。利用可能な中で最も新しい復元ポイントには、破損した状態が残っている可能性がある。より古い復元ポイントなら脅威を除去できるかもしれないが、直近のトランザクションが失われる。

エージェント型ワークフローは証拠を集め、選択肢を検証できるが、組織には依然として、これらの結果の間で選択する責任者が必要だ。適切な選択は、業務上の優先順位とインシデントの状況に左右される。

Cohesityは、このモデルが、すでにインシデント対応と復旧の一部を調整しているRecoveryAgentを基盤にすると説明している。また、レジリエンス機能を外部AIツールへ接続するインターフェース層、Cohesity Maestroの拡張も計画している。

同社は、MaestroがClaude、ChatGPT、Gemini、Helios管理コンソールなどのシステムと連携すると見込む。Cohesityはすでに、Claude workflows がMCPとエージェントスキルを通じて同社のレジリエンスインテリジェンスにアクセスする仕組みを説明している。

こうした統合は有用な柔軟性を生む。セキュリティチームは、すでにインシデント調査に使っているAI環境から復旧情報にアクセスできる。

一方で、新たなコントロール面も生まれる。復旧データを照会したり、アクションを準備したりできるエージェントには、厳密に限定された権限、信頼できるアイデンティティ、包括的なログ、レビュー可能な出力が必要となる。

侵害された自動化システムが、本番資産とその復旧コピーの双方に無制限にアクセスできてはならない。エージェントがプロセスを調整する場合でも、職務分離は依然として重要である。

「自律型サイバーレジリエンス」という表現は、異なる自動化レベルを覆い隠すこともある。自動的な資産発見は、本番アプリケーションの自動復元よりも運用リスクが小さい。

ポリシーの推奨は、その中間に位置する。管理業務を削減できる一方、チームが前提を理解せずに承認すれば、不適切な推奨は重大な結果を招く。

Cohesityの現在の自動化チュートリアルは、基盤機能がすでにデータ発見と継続的な保護判断を結び付けていることを示している。より広範な商用自動化は段階的に導入される見通しだ。

この段階的なアプローチは妥当である。システムは各レベルで実証を必要とするからだ。発見精度、ポリシーの品質、クリーンルームの準備、復旧の一貫性は、それぞれ個別に測定すべきである。

最大の不確実性は、エージェントが復旧手順を実行できるかどうかではない。自動化ソフトウェアは長年にわたり、インフラタスクを調整してきた。

不確実なのは、アプリケーションやエージェントが変化する中で、プラットフォームが業務上の依存関係について十分に正確なモデルを維持できるかどうかだ。トポロジーが古くなれば、技術的には成功していても、運用面では不完全な復旧につながり得る。

人間の承認があっても、このリスクはなくならない。レビュアーには、ワークフローが何を発見し、何を除外し、どの復元ポイントを選択し、どの程度の確信を持っているのかについて、明確な説明が必要だ。

自律型サイバーレジリエンスは、こうした判断を検証可能にして初めて信頼性を得る。インシデント時には速度が重要だが、説明のない速度は被害を拡大させかねない。

Cohesity Agent Resilienceがまだ実証していないこと

この発表は信頼できる復旧モデルを定義しているが、本番でのカバレッジと測定可能な復旧成果は依然として未検証である。

第1の制約は可用性だ。現在Cohesity Agent Resilienceを利用できるのは一部の顧客に限られ、広範な提供開始は2026年末を目標としている。

管理された段階的展開は、Cohesityがエージェント発見と復旧を洗練させる助けになる。一方で、ほとんどの見込み顧客は、まだ自社の完全な本番環境でこの製品を比較評価できないことを意味する。

第2の制約はプラットフォームの対象範囲である。初期サポートはAmazon Bedrock AgentCoreとBedrock Agentsに焦点を当てており、AzureおよびGoogle環境への対応は今後の計画にとどまる。

企業のエージェントは、多くの場合複数のサービスにまたがる。あるエージェントは一つのクラウドで実行され、別のプラットフォームから文書を取得し、SaaSアプリケーションを呼び出し、外部データベースにメモリを保存することがある。

サポート対象の部分だけを復旧すると、状態の不整合が生じる可能性がある。Cohesityは、その連鎖の一部が自社の直接管理外にある場合に、トポロジーと復元がどのように機能するかを示す必要がある。

第3の制約は復旧粒度に関わる。エージェントの状態には、プロンプト、短期メモリ、長期メモリ、ツール定義、モデル設定、アクセスポリシー、外部レコードなどが含まれ得る。

すべてのコンポーネントを同じ時点へ戻すべきとは限らない。インシデント発生後のレコードにも有効なものがある一方、単一の汚染されたメモリ項目が実際の原因である場合もある。

状態バンドル全体を復元すれば正当な作業まで削除される可能性がある。復元範囲を狭めすぎれば、侵害が残るかもしれない。

Cohesityは、こうしたシナリオに関する詳細な性能結果を公表していない。購入者は、発見精度、復元時間、アプリケーションの整合性、必要となる手動照合の量について証拠を求めるべきである。

共有依存関係をシステムがどのように扱うかも尋ねる必要がある。2つのエージェントが同じデータベースへ書き込んだり、同じメモリストアを利用したりすると、個別の復旧は難しくなる。

アイデンティティも未解決の問題をもたらす。エージェントをクリーンな設定へ戻しても、侵害されたトークンが必ず失効するとは限らず、過度に広い権限が修正されるとも限らない。

完全な復旧プロセスは、アイデンティティおよびアクセスシステムと連携しなければならない。そうでなければ、復元されたエージェントが問題を可能にした同じ経路を引き継ぐ可能性がある。

第4の制約は、自動化された推奨に関するものだ。Cohesityは、自社プラットフォームが態勢を評価し、ポリシー、スキャン戦略、復旧リハーサル計画を提案できるとしている。

顧客が実際のインシデントや複雑なアプリケーション環境で検証するまでは、これらの出力は企業側の主張にすぎない。購入者は、自動化そのものを成果と見なすのではなく、推奨の品質を評価すべきである。

Cohesity自身の調査は緊急性を示すが、製品を検証するものではない。同社の第5回年次サイバーレジリエンスレポートでは、調査対象組織の78％が、事業運営の維持ではなくシステム復元に復旧努力を集中していることが分かった。

この数字は、技術的な復元だけでは不十分になり得るという同社の主張を支える。しかし、Agent Resilienceや自律型ワークフローがそのギャップを埋めることは示していない。

システム復旧と事業復旧の区別は、依然として有用である。復元されたアプリケーションは、業務を再開する前に、アイデンティティサービス、最新データ、従業員のアクセス、他のアプリケーションに依存することがある。

Cohesityは催事Catalystでこの問題を強調し、孤立したインフラではなく、最小限に機能する事業の復元を中心に復旧を位置付けた。

この考え方は、適切な基準を引き上げる。顧客は、スナップショットが正常にマウントされたかではなく、信頼できる業務プロセスが再開するかでエージェント復旧を判断すべきだ。

第5の制約は説明責任である。自動ワークフローが誤った復元順序を推奨した場合、組織には、その選択に至った理由と誰が承認したかの記録が必要となる。

ガバナンスは人間による承認ボタンだけでは不十分だ。特にインシデントの圧力が迅速な行動を促す場面では、承認を意味あるものにするために、レビュアーには十分な文脈が必要である。

これらの疑問はいずれもCohesityの方向性を否定するものではない。もっともらしいアーキテクチャから信頼できる運用システムへ進むために必要な証拠を定義するものだ。

戦略が機能するかを示す3つのシグナル

Cohesityの戦略は、プラットフォームのカバレッジ、検証済みの復旧成果、自動化に設けられた境界によって判断すべきである。

第1のシグナルは、2026年末までの一般提供開始だ。このリリースには、保護対象の状態、依存関係の発見、復元順序、非対応構成について明確なドキュメントが含まれるべきである。

より広いクラウド対応は、日程と同じくらい重要になる。MicrosoftおよびGoogleとの統合が進展すれば、Cohesityが厳密に管理されたAWS実装を超えて拡張できることが示される。

リリースの遅延やフレームワークのカバレッジ不足は、このプラットフォームが企業エージェント向けの汎用復旧レイヤーになれるという主張を弱めるだろう。

第2のシグナルは顧客による証拠だ。Cohesityには、接続されたアプリケーションとデータの整合性を保ちながら、エージェントが信頼できる状態へ戻ることを示す事例が必要である。

有用な証拠には、復旧時間、発見された依存関係の数、失敗または不完全な復元、事後に必要となった手作業が報告されるべきだ。

最も強い証明は、準備されたデモではなく現実的なインシデントに関わるものとなる。設定の破損、汚染されたメモリ、過剰な権限、意図しない下流への書き込みは、それぞれ異なる復旧課題を生むはずだ。

顧客は、反復的な演習にも注目すべきである。一度だけ成功した復旧よりも、エージェントやアプリケーションの変化に合わせてシステムが最新性を保つことを示す定期テストの方が重要だ。

第3のシグナルは、Cohesityが自律型サイバーレジリエンスをどのように拡張するかである。同社は、このモデルが商用提供に近づくにつれて自動化を追加するとしている。

重要な問いは、どの判断が推奨にとどまり、どの判断が実行可能なアクションになるかだ。自動的な発見やクリーンルームの準備は、本番の復元ポイントを自動選択することとは異なる。

透明性の高い承認コントロールは、Cohesityの主張を強めるだろう。そうしたコントロールは、提案されたアクション、根拠となる証拠、予想される影響、除外された資産、ロールバックの経路を示すべきである。

自律性が監査可能性より速く進めば、この戦略は弱まる。復旧の自動化は、責任の所在を曖昧にせず、対応時間を短縮すべきだ。

競合他社の動向は、これら3つのシグナルすべてに追加の文脈を与える。Commvault、Druva、Rubrikが、エージェント保護を狭い機能カテゴリのまま放置する可能性は低い。

それらの対応は、トポロジーマッピング、エージェントの巻き戻し、不変の状態、オープン統合に関する共通の期待を形成し得る。また、Cohesityのカバレッジにおけるギャップを明らかにする可能性もある。

企業の購買担当者にとって実務上の第一歩は、現在エージェントが変更可能な対象を棚卸しすることです。各重要エージェントに接続されているメモリストア、認証情報、アプリケーション、データベース、インフラを特定すべきです。

この作業により、既存のバックアップ計画が運用チェーン全体をカバーしているかどうかが明らかになります。また、AIエージェント向けのリカバリー製品が、アイデンティティ、アプリケーション、セキュリティの各制御とどこで統合すべきかも分かります。

社内ナレッジワークフローを構築する組織も、情報依存関係に同じ規律を適用すべきです。適切に維持されたAIナレッジベースは、人間と自動化システムの意思決定を導くソース資料をチームが把握する助けになります。

Cohesity Agent Resilienceは、必要な変化を示しています。リカバリー計画では、記憶し行動するソフトウェア主体を考慮する必要があります。この製品の成否は、整合性、文脈、制御を失うことなく、そうした主体を復元できるかにかかっています。

リカバリーを自動化に委ねる前に、具体的な問いを一つ投げかけてください。システムは、何を復元し、何を変更せずに残し、その理由は何かを正確に説明できるでしょうか。答えが不完全であれば、人間による承認ゲートを確実に維持してください。