OpenClaw Enterpriseは常駐AIエージェントを「Kubernetesのように」管理する──制御プレーンの仕組みと未完成の認証｜2026年10月1日版

2026年10月1日

個別の区画に隔離された多数のAIエージェントを、中央の制御盤が管理しているイメージ図

常駐型のAIエージェントを社内で動かそうとすると、多くの企業でまず情報システム部門が「待った」をかけます。OpenAIでこのプロジェクトを率いるKevin Lin氏も、多くの組織ではOpenClawのようなエージェント基盤を丸ごと禁止するのがITの標準的な対応になっていると認めています。

その状況に向けて、OpenClaw Foundationは2026年9月29日（米国時間）に「OpenClaw Enterprise（OCE）」を発表しました。MITライセンスのオープンソースで、自社のKubernetes上で動かすエージェント用の制御プレーンです。開発にはRed HatとNVIDIAが加わっています。

発想としては、プロジェクト自身が「エージェント版のKubernetes」と説明しているとおりです。エージェントを名前空間ごとに隔離し、資格情報、権限、変更履歴を一か所で管理します。ただし現在は1.0前で、推奨されている用途は「社内パイロット」までです。認証まわりには未完成の部分が残っています。

この記事の要点

OCEの中核は「OpenClaw Control Plane（OCC）」。エージェントの配置、隔離、権限、資格情報、監査を担当する
ハーネス（エージェントの実行部分）、モデル、サンドボックスは差し替えられる設計で、特定ベンダーに縛られない
自社インフラで動かすことが前提。Kubernetes版とDocker Compose版があるが、Compose版ではエージェントをデプロイできない
1.0は2026年後半の予定。現時点では認証、外部ゲートウェイの受け入れ制御、ワークロード認証が開発中と報じられている

OpenClaw Enterpriseで何が発表されたか

まず事実関係を押さえておきます。

発表日：2026年9月29日（米国時間）。OpenClaw公式ブログにKevin Lin氏が発表記事を掲載
ライセンス：MIT。どの組織も無償で使える。コードはGitHubのopenclaw/openclaw-enterpriseで公開
経緯：OpenAIの社内プロジェクトとして始まり、独立団体のOpenClaw Foundationへ寄贈された。その後Red HatとNVIDIAも加わって開発している
利用状況：Red HatとOpenAIが社内でパイロット運用している
位置づけ：1.0前の公開開発中で、推奨は社内パイロット用途まで

OpenClaw自体は、Peter Steinberger氏が始めた個人向けのエージェント基盤です。常駐型で、メッセージを受けて自分で作業を進めます。この便利さの一方で、セキュリティ面の批判を受けてきました。The Registerによると、Gartnerは元のOpenClawを企業利用者にとって「受け入れがたいサイバーセキュリティリスク」と評価し、中国の国家CERTも「極めて弱い既定のセキュリティ設定」について警告しています。

OCEは、このエージェントの実行部分そのものを作り直す取り組みではありません。エージェントの外側に「管理する層」を追加する取り組みです。ここを押さえると、構成の意図がつかみやすくなります。

制御プレーンはエージェントをどう分けて管理するか

OCEの設計は、Kubernetesの「制御プレーン」と「データプレーン」の分け方にそろえてあります。管理を担う層と、実際に処理を動かす層を切り離す構成です。

4つの部品と役割分担

公式ブログ、GitHubのREADME、各社の報道から整理すると、部品ごとの役割は次のとおりです。

部品	役割	差し替え
制御プレーン（OCC）	エージェントの配置、名前空間での隔離、設定・資格情報・権限の管理、変更記録	中核のため固定
ゲートウェイ	エージェント宛てのメッセージを受け取る入口	—
ハーネス	エージェントの1ターンごとの処理、モデル呼び出し、ツール実行	可
サンドボックス	ツール実行などを隔離環境に閉じ込める	可

利用者にとって大事なのは、管理者が触る部分（OCC）と、エージェントが実際に動く部分（ハーネスとサンドボックス）が分かれている点です。エージェントが暴走したり乗っ取られたりしても、権限や資格情報の管理はエージェントの外に置かれます。

リポジトリから見える実装の単位

GitHubのリポジトリを見ると、責務ごとにパッケージが分けられています。

packages/iam/：ID、ロール、認可
packages/audit/：監査イベントの記録と、機微データの除去（サニタイズ）
packages/occ/：リソースのライフサイクル、永続化、ワークキュー
packages/contracts/：リソース定義、APIスキーマ、Driverインターフェース

とくにDriverインターフェースが重要です。計算資源やサンドボックスの実行先をDriverとして抽象化しているため、「ハーネス、モデル、サンドボックスを他社製や自社製に差し替えられる」という説明を実装面で支えています。

エージェントごとの通信の隔離

設計方針がよく表れているのが、GitHubのIssue #75です。ゲートウェイの置き場所を議論したもので、次の要件が明記されています。

デプロイされた各エージェントは、自分のハーネスにだけ通信を渡す
他のエージェントや他の名前空間をまたぐ通信は拒否する
複数テナントでゲートウェイを共有する構成は、別途の承認なしには認めない

つまり、1つのゲートウェイを全エージェントで使い回す構成は、意図的に避けています。部署Aのエージェント宛てのメッセージが、部署Bのエージェントに届く経路を最初から作らない考え方です。

セキュリティ境界の考え方

公式ブログは、防御を次の組み合わせとして説明しています。

信頼できるワークロードとできないワークロードの間に引く「ハードな境界」
サンドボックス
LLMによるレビュー
きめ細かい権限

ただし、これらの保護の仕組みを詳しく説明するリファレンスアーキテクチャは「今後数週間で公開する」とされています。現時点では設計目標として示されている段階で、すべての保護が検証済みというわけではありません。

まだ完成していない部分

OCEは1.0前のため、手元で試す前に知っておくべき制約がいくつかあります。

報じられている未完成の機能

セキュリティ系メディアのまとめでは、次の機能がまだ開発中とされています。

認証の仕組み
外部ゲートウェイの受け入れ（admission）制御
ワークロード認証

どれも「誰が、どのワークロードが、どの入口から入ってきたのか」を確かめるための機能です。制御プレーンの価値を支える部分がまだ固まっていないため、本番の機密データを扱う用途には使えません。

セットアップ時の注意点

occ dev up で起動するDocker Composeのプレビューでは、エージェントをデプロイできない。デプロイを試すにはk3dを使うKubernetesプロファイルを明示的に選ぶ
ローカル検証には、DockerかPodman、k3d、kubectl、Helm、Go、Node.js 24以上、pnpmが必要
既定の構成ではOpenAIのAPIキーが必要。モデルは設定で差し替えられる
インフラ費用やモデルAPIの利用料は別途かかる

Red HatとNVIDIAは何を担当するか

2社の関わり方は異なります。それぞれの得意分野が、OCEの「足りない部分」を補う形です。

Red Hatは、OpenShiftをエージェントを配置するコンテナ基盤として位置づけています。Linux、Kubernetes、分散システム、セキュリティの技術者を投入し、社内でもOpenClawを使っていると説明しています。

NVIDIAは、以前からエージェント用のサンドボックス実行環境「OpenShell」を公開しています。OpenShellは、ファイルシステム、ネットワーク、プロセスの操作を宣言的なポリシーでカーネルレベルから制御し、許可・拒否の判断をすべて記録する仕組みです。OCEのリポジトリにはOpenShellのサンドボックスログを取り込むプルリクエストがあり、差し替え可能なサンドボックスの候補の1つとして統合が進んでいると読めます。

整理すると、OCEの制御プレーンが「誰に何を許すか」を決め、OpenShellのようなサンドボックスが「実際に何をさせないか」を強制する、という分担です。

ここがポイント：OCEは「賢いエージェント」を作るものではありません。エージェントを隔離し、権限と監査の下に置くための管理層です。エージェントの導入が進まない理由がモデルの性能ではなく統制の不足にある組織に向けた基盤です。

日本の読者が見るべきポイント

立場によって、確認すべきことが変わります。

情報システム部門・セキュリティ担当

エージェント基盤を「禁止」から「隔離して許可」に切り替えるための検討材料になる
評価は、ID管理、資格情報の扱い、テナント間の隔離、監査ログ、ポリシー適用の5点を、実環境で1つずつ検証する形にする
認証まわりが未完成のため、社外のチャットツールや外部システムとつなぐ検証は1.0以降に回すのが無難

開発者・プラットフォームエンジニア

Kubernetes、Helm、名前空間、RBACの知識をそのまま使える
ハーネスとサンドボックスがDriverで抽象化されているため、自社のエージェント実装を載せられるかどうかが最初の確認点になる
検証時は、リポジトリのリビジョンと選んだプロファイルを記録しておくと、1.0までの変更を追いやすい

事業部門・一般利用者

使う側の見た目はすぐには変わらない
ただし、社内エージェントが「どの部署の、どの権限で動いているか」を管理者が追跡できる前提が整うと、業務データに触れるエージェントを承認しやすくなる

継続ウォッチ

リファレンスアーキテクチャの公開：「今後数週間」とされる保護設計の詳細。LLMによるレビューが、どの判断にどう関わるのか
認証系の実装：外部ゲートウェイの受け入れ制御とワークロード認証が、1.0に間に合うか
サンドボックスの選択肢：OpenShell以外に、どのサンドボックスやハーネスがDriverとして実装されるか
OpenAI APIキーへの依存：既定構成からOpenAI前提が外れるか。「ベンダー中立」の実態を測る目安になる

今日のまとめ

OpenClaw Enterpriseは、常駐AIエージェントを企業内で運用するための「管理する層」を、オープンソースで標準化しようとする取り組みです。

仕組みの要は、制御プレーンと実行部分の分離にあります。エージェントごとに通信経路を分け、名前空間をまたぐ通信を拒否し、ハーネス・モデル・サンドボックスは差し替えられる構成です。

一方で、認証、外部ゲートウェイの受け入れ制御、ワークロード認証はまだ開発中です。いま手を動かすなら、Kubernetesプロファイルで社内パイロットを立ち上げ、ID、隔離、監査の3点が実際に機能するかを自社の要件と照らし合わせるところまでが現実的です。次の判断材料は、数週間以内に出るとされるリファレンスアーキテクチャになります。

参照リンク

よかったらシェアしてね！

URLをコピーしました！

URLをコピーしました！