AIエージェントの運用は、この1年で「作って動かす」から「本番で回し続ける」段階に移りました。すると次に問われるのは、うまくいっているときの話ではなく、壊れたときの話です。エージェントのメモリが汚染された、設定が知らぬ間に書き換わった、あるいは1体が想定外の操作を連発し始めた——そのとき企業は、そのエージェントを止められるのか、そして壊れる前の状態に戻せるのか。2026年9月に相次いだ発表と調査は、多くの企業がこの2つに「まだ答えを持っていない」ことを浮き彫りにしました。
homula はエンタープライズ向けの AIエージェント・インテグレーターとして、日本企業の「PoCから本番・全社へ」を日々支援しています。本稿は特定製品の宣伝ではありません。Cohesity が9月16日に投入した「エージェント基盤の保護・復旧」機能と、Kiteworks の2026年フォーキャスト調査が示す「封じ込めの欠落」を起点に、監視の次に組むべき『止める・戻す・守る』の層を実務目線で整理します。
データが示す「監視はできる、止められない」ギャップ
まず、多くの企業に共通する構造的なギャップから。Kiteworks が公開した「Data Security and Compliance Risk: 2026 Forecast Report」（意思決定層225名への調査）は、これをガバナンスと封じ込めの断層と呼びます。調査対象の100%がエージェンティックAIをロードマップに載せている一方で、実際に配備済みの統制には偏りがありました（Kiteworks, 2026年）。
| 統制の種類 | 導入状況 | 分類 |
|---|---|---|
| Human-in-the-Loop（人手チェックポイント） | 導入 59% | 監視系 |
| 継続的モニタリング | 導入 58% | 監視系 |
| データ最小化 | 導入 56% | 監視系 |
| パーパスバインディング（権限の目的限定） | 63%が未整備 | 封じ込め系 |
| キルスイッチ（強制停止） | 60%が未整備 | 封じ込め系 |
| ネットワーク隔離 | 55%が未整備 | 封じ込め系 |
読み方はシンプルです。「見張る」系の統制は5〜6割が持っているのに、「止める・縛る・切り離す」系の統制は5〜6割が持っていない。同レポートはこの差を「ガバナンスと封じ込めの間に15〜20ポイントの開き」と表現し、真に封じ込めの効く統制を備えた組織は37〜40%にとどまるとしています。監視ダッシュボードは整っても、いざ暴走したときにその場で止め、被害を巻き戻す手段がない——これが2026年の平均的な現実です。
監視（モニタリング）と封じ込め（コンテインメント）は別物です。ログやアラートは「起きたことを知る」ための仕組みであって、「起きていることを止める」仕組みではありません。異常を検知できても、停止権限・目的限定・隔離・認証情報の失効といった実際に手を止める手段がなければ、検知はインシデントを傍観する行為になります。
エージェントの「状態」が、新たな保護対象になる
止める話の次は、戻す話です。従来のバックアップ／災害復旧（DR）は、データベースやファイル、VMを対象にしてきました。しかしエージェントは、それ自身が状態（ステート）を持つ——メモリ（過去のやり取りや学習した文脈）、設定、接続先、実行中のタスク——という点で、これまでの保護対象と質が異なります。
この「エージェントの状態そのもの」を保護・復旧の対象に据えたのが、Cohesity が2026年9月16日に発表した Agent Resilience です。同社の Data Cloud の新機能として、エンタープライズAIエージェントの基盤を発見・保護・復旧すると位置づけられています（Cohesity, 2026年9月16日／Help Net Security, 2026年9月16日）。報道と公式情報を突き合わせると、初期リリースの中身は次のとおりです。
- メモリと設定の保護＋ポイントインタイム復旧: メモリ破損・設定ミス・悪意ある操作の後に、エージェントを既知の正常状態（known-good state）に戻すことを目的とする。
- エージェント・トポロジー: 各エージェントについて、メモリストア・接続アプリ・データベース・支援インフラを一枚のビューで可視化し、依存関係と保護カバレッジ、復旧に必要なリソースを把握できるようにする。
- エージェントが触る先も保護: エージェントが操作するデータベース・ファイルシステム・各種サービスも対象に含め、影響を受けたリソースを精密に復旧する。
- 対応基盤と提供時期: Amazon Bedrock（AgentCore / Bedrock Agents）に対応。Microsoft・Google のエージェント基盤はロードマップ上。現在は一部顧客向けに提供、一般提供（GA）は2026年末を目標（SiliconANGLE, 2026年9月16日／HyperFRAME Research, 2026年9月18日）。
特定製品の是非はここでの論点ではありません。重要なのは、「エージェントの状態」がバックアップ・復旧という独立した規律の対象として立ち上がってきたという事実です。データを守るだけでは足りず、そのデータを操作する主体（エージェント）そのものを、壊れる前の状態に巻き戻せるかが問われ始めています。
なぜ「戻す」が難しいのか——エージェント特有の壊れ方
エージェントの復旧が単純なデータ復元と違うのは、壊れ方が二層にまたがるからです。
第一に、エージェント自身の状態が壊れる。プロンプトインジェクションや汚染された参照データによって**メモリが毒される（memory poisoning）**と、エージェントは「間違った文脈」を正しいものとして持ち続け、以降の判断を歪めます。設定ドリフト（気づかぬ設定変更）も同様に、外からは正常に見えたまま挙動だけがずれていきます。
第二に、エージェントが外部の実システムに副作用を残す。メール送信、レコード更新、本番書き込み、支払い——エージェントは「考える」だけでなく「行動する」ため、壊れた状態のまま走れば、取り返しのつく範囲の外に影響が広がります。したがって復旧は、エージェントのメモリ・設定を戻すだけでは完結せず、そのエージェントが何に触れたかを辿り、影響先のリソースまで含めて巻き戻す必要があります。Cohesity がトポロジー可視化と「触れた先の復旧」をセットにしたのは、まさにこの二層性への対応です。
ここで効いてくるのが**証跡（監査ログ）**です。「そのエージェントがいつ・どのツールで・何をしたか」を全件たどれなければ、影響先を特定できず、精密な復旧も設計できません。復旧可能性（リカバラビリティ）は、平時に取り続けている監査ログの質に直結します。
「止める・戻す・守る」を、対で設計する
監視の次に組むべき層は、封じ込め（止める・切り離す）と復旧（戻す）を一体で設計することです。インシデントのライフサイクルに沿って並べると、必要な手段は次のように整理できます。
| フェーズ | 目的 | 具体的な統制 |
|---|---|---|
| 検知 | 異常を知る | 監視・アラート・全件監査ログ |
| 封じ込め | 被害を止める | キルスイッチ（強制停止）・ネットワーク隔離・認証情報の失効 |
| 限定 | 権限をそもそも狭める | パーパスバインディング（目的外の操作を禁止）・RBAC |
| 復旧 | 正常状態に戻す | メモリ・設定のポイントインタイム復旧・影響先リソースの巻き戻し |
| 再開 | 安全に戻す | 既知の正常状態からの再起動・原因のポリシー反映 |
前掲の Kiteworks データが示すのは、多くの企業が検知は持っているが、封じ込めと復旧が抜けているという偏りでした。理想は、監視で異常を捉えたら、その場で止め（キルスイッチ）、権限を切り（失効）、影響を辿って戻し（復旧）、原因をポリシーに反映して再開する——という一連が繋がっていることです。どれか1つでも欠けると、鎖はそこで切れます。停止できても戻せなければ業務は止まったまま、戻せても止められなければ被害は広がり続けます。
homulaの観点——復旧可能性は「平時の統制」で決まる
「止める・戻す・守る」は、インシデントが起きてから慌てて用意できるものではありません。平時にどんな統制と証跡を積んでいたかで、有事の復旧可能性はほぼ決まります。homula がエージェント導入で重視するのも、この平時の設計です。
- 全件の証跡と権限を一元的に持つ: Agens Control は、承認フロー・DLP・5年分の監査ログ・RBAC を提供します。「どのエージェントが何に触れたか」を全件たどれる証跡は、影響先を特定して精密に復旧するための前提です。RBAC と権限管理は、いざというときに認証情報を失効させて封じ込める土台にもなります。
- 接続は作り込まず、封じ込めの設計に時間を割く: Agens は MCP を活用し、200以上のツールと構築ゼロで接続します。接続先が増えるほど「壊れたエージェントが触れる面」も広がりますが、接続自体を作り込まずに用意できるぶん、どの操作を止め、どの範囲を復旧対象にするかの設計に人手を回せます。
- リスク階層でゲートと目的限定を作り分ける: n8n / Dify / LangGraph を組み合わせ、高インパクトな操作（送信・削除・本番書き込み・支払い）には実行前の関所と目的限定を、低リスクの参照系には軽い監査を——と、一律でない封じ込めを実装します。
- 着手前に「復旧要件」を定義する: AIエージェント・ブートキャンプでは、業務棚卸し・プロトタイプ構築・ROI試算を3〜5日で完結します。このとき「暴走時にどう止めるか」「どの状態まで戻せれば業務が再開できるか」を最初の要件として置くことが、規模が増えたときの被害を小さく抑えます。
順序が肝心です。機能を載せてから復旧・封じ込めを後付けすると、いざ壊れたときに「止める手段も、戻す先もない」状態に陥ります。証跡・権限・停止・復旧を平時に組み込んだうえで機能を載せる——これが、処理時間の大幅削減のような成果を、壊れても立て直せる形で取りにいくための現実的な道筋です。
まとめ——監視の次は、レジリエンス
2026年9月の一連の動きが示したのは、AIエージェントの議論が「賢さ」や「導入率」から、壊れたときにどう立て直すかへと軸足を移し始めた、ということです。Kiteworks の調査は、監視は普及しても封じ込めと復旧が欠けている現実を数字で示しました。Cohesity の発表は、エージェントの状態そのものがバックアップ・復旧の対象になったことを製品として裏づけました。
日本企業がいま準備すべきは、派手な自動化の追加ではなく、「止める・戻す・守る」の層を先に組むことです。全件の証跡で影響を辿れるようにし、危険な操作は実行前に止め、暴走時にはその場で停止・隔離・失効でき、壊れた状態は既知の正常状態に巻き戻せる。この備えがあって初めて、エージェントを増やすことは「怖いもの」ではなく「広げていけるもの」になります。監視はスタート地点であって、ゴールはレジリエンス——壊れても立て直せる運用です。
「便利だが、壊れたら戻せない」を、「壊れても立て直せる統制」に変えませんか。homula は、全件監査・権限管理・封じ込めと復旧を備えたエージェント運用層づくりを、業務棚卸しからROI試算まで一気通貫で支援します。