AIが「行動」できる時代へ：OpenClawのガバナンス

今週、OpenClaw（旧ClawdbotおよびMoltbot）上に構築されたAIエージェント向けソーシャルネットワーク「Moltbook」をめぐる話題によって、エージェント型AIが一気に世間の注目を集めました。ボット同士が交わした、アイデンティティ、新たな宗教の創設、人間へのソーシャルエンジニアリングといったテーマの対話は、各所で警戒感を呼び起こしています。

ITリーダーにとって明白なのは、AIが明確な転換点を越えたという事実です。OpenClawのようなツールは、もはや回答や提案を生成するだけの存在ではありません。実在のシステムに対し、実際の権限を用いて、現実の結果を伴うアクションを実行するよう設計されています。この「助言」から「実行」への移行は、自律性や意図、さらには機械の主体性にまで踏み込む、より広範な社会的議論を引き起こしています。

アシスタントが自ら行動できるようになった以上、ガバナンスは不可避です。可視性・統制・執行力を欠いたままの実行は、単に管理されていないリスクにすぎません。OpenClawが検討に値するのは、その目新しさゆえではありません。AIシステムが自律的に実行できる段階に至ったとき、これまで前提としてきたセキュリティの想定がもはや通用しないことを、これほど明確に浮き彫りにしている点にこそ、本質的な意味があります。

アシスタントが「行動」できるようになると、何が変わるのか

OpenClawは、もはや従来型のチャットボットとは異なります。むしろ、自動化を実行するレイヤーとして機能する、新しいタイプのアシスタントに属しています。これまでのAIツールが提案や文章を生成することに主眼を置いていたのに対し、こうしたエージェントはツールを呼び出し、各種システムにアクセスし、ユーザーに代わって具体的なアクションを実行します。

実務レベルで見れば、これは大きな変化です。売上管理（レベニューオペレーション）、ITサービスデスク、人事、調達、セキュリティといった領域における日常業務が、システム間で人が橋渡しをすることなく、チャット画面から直接開始され、そのまま完結できるようになります。

しかし、真に重要なのは生産性の向上ではありません。変わるのは「権限の所在」です。ここで動いているのは単なるコンテンツ生成ワークフローではなく、実在するシステム、実データ、実際のアクセス権限に直接触れる「意思決定と実行」のワークフローです。ひとつのプロンプトが、ファイルへのアクセス、APIの呼び出し、第三者へのメッセージ送信、さらにはインフラ構成の変更といった具体的な結果を引き起こし得ます。このレベルの自律性でアシスタントが行動できるようになった瞬間、従来のセキュリティ前提は崩れます。ガバナンスはもはや付け足しでは済みません。単なるチャット入力が、そのまま企業全体に影響を及ぼす実行へと直結する時代に入ったからです。

OpenClawの仕組み：ゲートウェイ統合型エージェントと「ローカル実装」という現実

OpenClawがなぜエンタープライズのセキュリティモデルを変えてしまうのかを理解するには、まずそのシステム構造を把握する必要があります。

大枠では、次のような構成になっています。

1. インバウンドチャネル： ユーザーからのリクエストは、チャットや各種メッセージングプラットフォームを通じて送られてきます。その多くは、従来のエンタープライズアプリケーションの境界の外側から流入します。
2. 中央ゲートウェイサービス： 受け取ったリクエストは中央のゲートウェイで処理され、セッションコンテキストが保持されます。同時に、どのツールや外部連携を呼び出すかがここで判断されます。
3. 実行フェーズ： ゲートウェイは、ローカルホストへのアクセスや接続済みAPIを介してアクションを実行します。その際、ユーザー自身の権限、ホスト環境の権限、さらに設定済みインテグレーションの権限を引き継いだかたちで動作します。
4. 結果のリターン： 背後で複数の特権的な操作が行われていたとしても、ユーザーには最終的な結果のみがチャット画面に返されます。

ここで戦略的に重要になるのが、「ローカル実装」という前提です。ローカルで稼働させることは、外部サービスへの依存を一定程度減らす効果があります。しかし同時に、常時稼働する実行サービスに加え、設定ファイル、ログ、トークン、さらには公開範囲やアクセス判断に関わる情報までもが、エンドポイントや社内サーバー上に直接配置されることを意味します。企業側のIT統制の観点から見ると、これは新たな“見えにくい制御層”が環境内に組み込まれることにほかなりません。それも、従来の調達プロセス、IDガバナンス、セキュリティ審査といった統制の枠組みの外側で動作しかねない存在としてです。

ブラスト半径を拡張する存在としてのゲートウェイ

エージェント型システムにおいて、ゲートウェイは制御が集中する中枢となります。ユーザーからのリクエストを仲介し、実行先を振り分け、さらにエージェントが依存する各種シークレットや外部連携情報を保持する中枢でもあります。ネットワーク構成や公開範囲という観点では、そのパターン自体は見慣れたものかもしれません。しかし決定的に異なるのは、このゲートウェイが「実在する権限を引き継いだ自動化アクター」を動かせる点です。その結果、影響範囲（ブラスト半径）は大きく増幅されます。このゲートウェイが誤設定されたり、意図せず外部に公開されたり、侵害された場合、リスクはもはや単一のサービスに限定されません。理由はいくつかあります。

• 意図しない到達の可能性：本来想定していない境界の外側からゲートウェイにアクセスできる状態になると、それは単なる「公開サービス」ではなく、遠隔から操作可能なコントロールプレーンへと変わります。
• 脆弱なアクセス制御：認証の強制が不十分であったり、トークンが共有されていたり、ローテーションが適切に行われていなかったりすると、「アクセス可能」であることがそのまま「操作可能」であることを意味してしまいます。
• ディスカバリーによる露出：mDNSのようなLANディスカバリープロトコルは、ローカルネットワークに可視性を持つ第三者に対して、システムの存在や環境情報の手がかりを不用意に知らせてしまう可能性があります。
• 制御チャネル特有の複雑さ：HTTP APIに加えて、WebSocketのような長時間維持される双方向接続が存在する場合、設定ミスのリスクはさらに高まります。そのため、リバースプロキシの厳密な構成、信頼ヘッダーの適切な取り扱い、そして厳格な許可リスト（allowlisting）の運用が極めて重要になります。

OpenClawプロジェクトが示すセキュリティ指針と、それがエンタープライズには不十分である理由

OpenClawプロジェクトのドキュメントには、セキュリティ強化に関する指針が示されています。これらの推奨事項自体は妥当なものです。しかし同時に、ひとつの根本的な問題を浮き彫りにしています。すなわち、安全な運用は、各導入環境ごとに規律ある設定と継続的なセキュリティ管理が徹底されることを前提としている、という点です。

エンタープライズにとって特に重要な推奨事項には、次のようなものがあります。

• 公開範囲は原則として最小限に抑える：ゲートウェイをホスト外から到達可能にする必要がないのであれば、利便性を理由に待ち受け範囲を広げるべきではありません。公開面は、あくまで必要最小限にとどめるべきです。
• 認証を「任意」にしない： 強固な認証情報を必須とし、定期的な更新を徹底すること。また、自らが十分に統制できていない上流コンポーネントを暗黙に信頼するような構成は避ける必要があります。
• 不要な検出機能は可能な限り抑制する： 導入環境でネットワーク検出機能が必須でない場合は、無効化するか、最小限に制限すべきです。不要な可視性は、そのまま不要な露出につながります。
• ログを機密情報として扱う： エージェントの対話履歴やツール出力は、機密情報や業務上の文脈を含む「もうひとつのアーカイブ」になり得ます。そのため、最小権限の原則に基づくアクセス制御と、適切な保存期間の管理を適用することが求められます。

問題は、仮に個々のユーザーがこれらの推奨事項を忠実に守ったとしても、企業全体としては一貫した可視性、ポリシーの強制、そして大規模環境での保証を確保できない点にあります。個別の指針強化は重要ですが、それだけでは中央集権的なガバナンスの代替にはなりません。

AIにおけるセキュリティリスク：プロンプトインジェクション、ツール悪用、そして権限の乗っ取り

エージェント型アシスタントの登場によって、失敗のあり方そのものが変わりました。これまでは「モデルが誤った内容を出力した」という問題でしたが、いま直面しているのは「モデルが誤った行動を取るように仕向けられた」という問題です。

ツールと接続されたアシスタント環境では、プロンプトインジェクションは単なる入力の攪乱ではなく、エージェントを具体的な行動へと誘導する手段になります。たとえば以下のような事態が現実的なリスクとして発生します。

• 本来アクセスすべきではないデータにアクセスし、取得する
• 情報を、意図しない送信先へ流出させる
• 承認済みの業務フローに従っているように見せかけながら、不適切な操作を実行する

ここで決定的に重要なのが、「権限の継承」という構造です。エージェントは、ユーザーの権限だけでなく、ホスト環境や接続された各種システムの権限までも引き継いで動作します。つまり、影響範囲（ブラスト半径）は、エージェントが到達可能な範囲そのものに依存します。それには、メールボックス、ファイルシステム、ブラウザ、APIトークン、社内ダッシュボードなどが含まれます。

企業は、外部コンテンツに触れるアシスタントである以上、いずれは悪意ある指示を取り込む可能性があるという前提に立つべきです。それが標的型攻撃であれ、機会的な攻撃であれ同様です。そして、それらの指示は、外形上は正当な実行経路を通じて届けられる可能性があることも、あらかじめ織り込んでおく必要があります。

「スキルを追加する」という行為が“信頼の判断”になるとき

エージェント型アシスタントは、ひとたび導入して終わりという存在ではありません。ユーザーがスキルやプラグイン、拡張機能を追加した瞬間、組織が向き合う対象は単一のツールではなくなります。そこには、エージェントの実行内容やアクセス可能な範囲、さらには時間の経過とともに変化する挙動にまで影響を及ぼす、第三者のロジックが組み込まれることになるからです。

ここで、サプライチェーンリスクという既視感のある課題が、より危険な形で再び姿を現します。人気や利用者数の多さが、そのまま安全性の裏付けであるかのように受け止められがちです。しかし実際には、アドオンの振る舞いは実行されるまで完全には予測できません。そして一見ささいに見える連携であっても、徐々に広範な権限を蓄積していきます。エージェント型システムでは、それらの権限が自律的に、しかも正規の業務フローを通じて行使されるという点が決定的に異なります。

さらに、名称や外観を巧妙に模倣した拡張機能や、改ざんされたトロイの木馬型アドオンといった存在が、リスクを一段と高めます。ブランド認知やユーザーの信頼を足がかりに、環境内部での実行権を獲得しようとするからです。企業が取るべき対応は、ソフトウェアパッケージやブラウザ拡張機能の分野で積み重ねてきた教訓と本質的に変わりません。すなわち、資産の正確な把握と棚卸し、承認済みコンポーネントの明確な許可制、出所の検証、そしてポリシーの一貫した適用です。

トロイの木馬型攻撃の拡大：偽OpenClaw／ClawdbotツールとRATの拡散

あるツールが急速に注目を集めれば、それを装った模倣や偽装が必ず現れます。攻撃者にとって、正規の製品そのものを侵害する必要はありません。本物と見分けがつかないほど巧妙な偽ツールを配布し、ユーザーにインストールさせることができれば十分だからです。

OpenClawを取り巻く環境でも、すでにその構図が現れ始めています。トロイの木馬化された類似ツールや偽の拡張機能が、ブランド認知や利用者の関心の高まりを悪用しています。中には、リモート監視・管理ツールやRAT（遠隔操作型マルウェア）に類するペイロードを仕込み、エンドポイントを直接制御可能な状態にするものもあります。これにより、課題は正規アシスタントの統制にとどまらず、機会的なマルウェア配布経路の封じ込めへと拡大します。

具体例としては、今年初めに報告された偽のClawdbot向けVS Code拡張機能が挙げられます。また、より広範なOpenClawエコシステムにおいても、必須コンポーネントを装った偽の「前提ソフトウェア」をインストールさせるソーシャルエンジニアリングが確認されています。こうしたケースでは、エージェント自体が主たる脆弱性というよりも、配布の媒介として悪用される存在へと位置づけが変わります。

防御側にとっては、対処すべき領域が一段と広がることを意味します。正規アプリケーションの実体と不審な亜種を識別する統制が求められるだけでなく、想定外の外向き通信、遠隔操作に類する挙動、不自然な実行連鎖といった下流の兆候も検知しなければなりません。意図されたツールの誤用を監視するだけでは、もはや十分とは言えないのです。

OpenClawのサードパーティ連携の内実：SASE可視化から見える初期動向

Cato Networks環境での現時点の観測によれば、OpenClawの導入はまだ少数のアカウントにとどまっているものの、着実に増加しています。本データはエンタープライズ全体の活動を網羅するものではありませんが、エージェント型アシスタントがどの領域から浸透し始めているのかを示す初期的な傾向を把握する手がかりになります。OpenClawの利用と併せて最も多く確認されているサードパーティ連携はGoogle Workspaceです。これにGitHub、X（旧Twitter）が続きます。さらに、Chartbeat、TripleLift、AdSafeといった、メディアおよび広告運用に関連するサービス群も一定のまとまりとして観測されています。

これらの連携状況から、初期のユースケースが見えてきます。Google Workspaceの利用が目立つことは、メール、カレンダー、ドキュメントを中心とする日常的な業務ワークフローに根差した導入が進んでいることを示唆しています。GitHubの存在は、ソフトウェア開発部門での試行的な活用が進んでいる可能性を示します。また、Chartbeat、TripleLift、AdSafeの観測は、メディアおよび広告分野における、より専門性の高い用途での導入が始まっていることを物語っています。

ここで注目すべきは、「導入の広がり」と「利用の強度」の違いです。Google Workspaceはより多くのアカウントで確認されている一方、Chartbeatは導入環境自体は限定的ながら、利用が確認された環境では比較的高い使用頻度が見られます。この傾向は、組織全体での一斉展開というよりも、限られたパワーユーザーが反復的な業務プロセスを自動化している状況と整合的です。

図1は、2026年2月1日までの観測データに基づき、OpenClaw関連のネットワークアクティビティを連携サービス別に割合で示したものです。

図1： OpenClaw導入アカウントにおける連携状況の内訳（2026年2月1日時点）

エンタープライズ環境におけるOpenClawのガバナンス：可視化し、統制し、遮断する

OpenClawは、ユーザー、デバイス、ネットワーク、アプリケーションにまたがるリスクの存在を明確に示しています。導入はユーザーや拠点を横断して進みますが、その影響はアプリケーション利用、ネットワークの公開範囲、データの移動にまで及びます。この横断性こそが、中央集約型の可視化とポリシー適用を不可欠なものにしています。

実効性のあるガバナンスは、次の三つの基本から始まります。

• 可視化する：組織は、いわゆるシャドーAIも含め、どのユーザーが、どこから、どのような振る舞いでエージェント型アシスタントを利用しているのかを把握する必要があります。この基礎的な可視性がなければ、ポリシー判断は推測に依存せざるを得ません。
• 統制する：セキュリティチームは、OpenClawの利用を厳格に範囲を限定した試験導入のみに許可するなど、明確な制御を行えるべきです。デバイスのセキュリティ状態や利用コンテキストに応じて制限を設ける、あるいはアクセスを全面的に拒否することも可能でなければなりません。多くの場合、統制されていない利用を遮断するという最も単純な対策が、最短でリスクを低減します。
• 悪用経路を遮断する：名称を模倣したインストーラーや、トロイの木馬化された拡張機能、侵害されたコンポーネントが外部との通信を開始した場合、ネットワーク層での保護機能により、不審なコマンド＆コントロール通信や異常な実行挙動を検知できる必要があります。

実務上は、エージェント型アシスタントを不透明なローカルツールとして扱うのではなく、識別可能なアプリケーションとして位置づけることも重要です。組織全体で一貫して認識・統治・適用できる状態を確立することで、統制なき実験と全面禁止という極端な選択肢の間で揺れ動く状況を避けることができます。

AI脅威研究の高度化

エージェント型AIに伴うリスクを理解し、適切に抑制するには、従来のアプリケーションセキュリティやネットワークセキュリティの枠組みだけでは不十分です。プロンプトインジェクション、データの持ち出し、自律型エージェントの悪用が、実際の運用環境においてどのように発生し、どのような経路で展開するのかを、実態に即して解明する専門的な研究が不可欠です。

この領域は、Cato Networksが積極的に投資している分野のひとつです。2025年にAim Securityを加えたことで、Cato NetworksはAIネイティブな脅威に関する研究体制を一段と強化しました。これにより、SASEに基づく可視化およびポリシー適用の基盤に加え、エージェントの挙動、実行経路、そして新たに出現しつつある悪用パターンに対する、より深い分析が可能になっています。本ブログで示した現実を前提に設計された、AI対応型の検査およびポリシー機能の継続的な高度化は、こうした研究活動に裏打ちされています。

OpenClawガバナンスのための実践的指針

OpenClawは、業務のあり方がどこへ向かっているのかを示す、ひとつの明確な兆候です。常時利用可能で、各種ツールと接続され、実際にアクションを実行できるアシスタント――そのような存在が現実の業務基盤に組み込まれ始めています。しかし、その能力こそが同時に、エージェント型AIをセキュリティおよびガバナンス上の課題へと変えます。なぜなら、そこで動作している実行レイヤーは実在するものであり、その影響範囲（ブラスト半径）も決して仮定上のものではないからです。

今後の進むべき道は、場当たり的な対応ではなく、意図的かつ計画的なエンタープライズ・ガバナンスの確立にあります。可視化、統制、そして多層的な防御を組み合わせ、正規のツールそのものだけでなく、必然的に生まれる模倣や亜種を含むエコシステム全体を見据えた対策を講じることが求められます。