OpenClaw で OpenClaw を開発する：Agent をチームの協働パートナーに
チームメイトとミニゲームを共同修正する段階から、Agent がデータベースの刷新を着実に進める段階、そしてエンタープライズのコントロールプレーンに至るまで：Peter Steinberger と Kevin Lin が、ソフトウェアを共同開発するために必要なコンテキスト、実行方式、権限の分担を共有した。
OpenAI DevDay において、OpenClaw（愛称「ザリガニ」）の創設者である Peter Steinberger と、OpenAI の OpenClaw Enterprise（OCE）責任者である Kevin Lin が、チームがどのようにOpenClaw で OpenClaw を開発しているか（ClawLabs: Building Open Source Together）を共有した。
Peter はすでに多数の Agent セッションを同時に実行できていたが、チームメイトが参加しようとすると、依然として彼を介して要望を伝言してもらう必要があった。またコードレビューの際も、何が変更されたかは見えても、なぜそう変更されたのかが見えないことが多かった。そこで彼らは作業を共有セッションへと移行し、チームメイトが直接参加できるようにしたうえで、ダッシュボードやミーティング議事録、継続的なメンテナンスを同じワークスペースへと統合した。チーム規模が拡大した後は、これらの常駐 Agent のIDと権限を一元管理することも求められるようになった。
OpenClaw は、Agent を継続的に実行させ、ツールやチームをまたいで協働させるためのオープンソースプラットフォームである。独立した非営利組織である OpenClaw Foundation が保有し、OpenAI が支援を提供している。登壇時点において、プラットフォームはすでに ChatGPT アカウントでのログイン、サブスクリプションの連携、プラグインの引き継ぎ、および Codex セッションの閲覧に対応していた。OpenClaw Enterprise（OCE） は、組織内における Agent のデプロイ、ID管理、および権限管理を担当する。
なぜ個人のセッションではチームの協働を支えにくいのか
Peter は冒頭で、自身がオープンソースプロジェクトのメンテナンスにおいて辿ってきたワークフローの変化を振り返った。初期の彼は主にターミナル（CLI）環境で作業していた。画面を分割して複数の Codex セッションを開き、ウィンドウ間でコードを行き来させていた。モデルの性能向上に伴い、Esc キーを押して Agent を強制的に中断したり微調整したりする頻度は徐々に減少し、その後ワークフローは、GUI、内蔵ブラウザ、レビューパネルを備えたデスクトップクライアントへと移行した。
並行タスクや実験の数が増えるにつれて、単一マシンの物理的な限界がすぐに露呈した：
- ノート PC のディスク容量が急速に枯渇した。
- 冷却ファンが高負荷で回り続けた。
- ローカルの負荷を分散するため、彼は複数の DevBox に接続し始め、Crabbox と名付けたクラウドテスト環境を構築して、6台から10台のマシンを同時に操作しながらコードの実行や実験を行い、Codex や VNC リモートデスクトップを通じて管理した。
マシンの台数を増やしても、協働における障壁は解決しなかった。チームの他のメンバーが参加したり Agent にタスクを割り振ったりしようとしても、セッションに直接アクセスできないため、Peter に代行して伝言してもらうしかなかった。Frank Allenby はこの状態を 「生身の中継役」（Meat Proxy） と表現した。開発者がチームメンバーと AI の間の仲介役となり、同僚が出した要望をあなたが Agent に伝え、Agent が生成したコードを再びあなたが同僚にコピーして渡すという構図であり、チームメンバーは Agent を中心として真に協働できていなかったのである。
さらに、コードの背後にある意思決定のコンテキストが分断されやすいという問題もあった。短いプロンプトから何千行、何万行ものコード変更が生成されることがあるが、その背後にあるプロンプトや対話ログは個人のローカルクライアントにしか残らないことが多い。チームメンバーがコードベースで大規模な変更をレビューする際、具体的にどのコードが修正されたかは理解できても、それらのコードを生成した際のモデルとのプロンプトのやり取りや議論の背景を把握することは困難だった。
同じ1つの変更 2つの協働アプローチ
チームメイトのリクエストは、まず誰の手元に届くのか？
2つの作業スタイルを並べて比較し、変更の提案、理由の確認、タスクの引き継ぎにおいて、コンテキストがどこに残されるかを追跡する。
各自が Agent を個別利用
チームメイトはセッションの所有者を介して作業を理解したり引き継いだりする必要がある。
共有セッションで共に作業
セッションがチーム全員で参加できる作業プロセスとなる。
同じ1つの変更を提案する場合：左側ではまず Peter に伝言を依頼し、右側では権限を持つチームメイトが共有セッションに入る。
講演で示された同等のアクセス権限を持つチームモデルに基づいて解説。共有とは全員に対して無制限に開放することを意味するわけではない。
こうした分散して切り離された状態を改めるため、チームは Agent を個人のスタンドアロン環境から複数人で共有するワークスペースへと移行する道を模索し始めた。
共有セッションはいかにしてチームメイトを同じ作業に参加させるか
個々人が孤立して作業する問題を解決するため、チームはマルチプレイヤー協働モードの導入を試みた。サーバーを単なる隔離された実行バックエンドとして見るのではなく、チームメンバーが常時オンラインで参加できる共有ワークスペースへと転換したのである。
共有サーバー上では、チームメンバーはお互いのセッション履歴を直接確認でき、相手のセッションに向けてプロンプトを送信し、作業を引き継いだり調整したりすることができる。
共同修正：ミニゲームのデモ
会場でのデモにおいて、Peter は音声を通じて PartyClaw に対し、『Frogger』（フロッガー）に似たミニゲームの制作を提案した。リクエストを送信すると、チームメンバーの Kevin がすでに利用可能なバージョン（Lily Lane）を先行して構築済みである旨がシステムから通知された。Peter はそれを開いて試遊した後、主人公をカエルから大きなロブスターに変更したいと考えた。
続いて Peter は一時的なリンクを提供し、オンラインの参加者をサーバーに招待した。複数人が同時にオンライン接続した環境では、画面上に複数のメンバーが同時にテキストを入力している様子が表示され、Peter は先手を打ってキャラクターをロブスターにし、ゾウは出さないようにするプロンプトを送信した。その後ゲーム画面が再読み込みされ、ロブスターとサメが登場するバージョンが生成された。
共有の前提：同等の権限と相互の信頼
このマルチプレイヤー協働モードは、特定の前提の上に成り立っている。すなわち、同等のアクセス権限を持ち、互いに信頼し合っているチーム向けに設計されているという点である。Peter は講演の中で、「自分の作業セッションに勝手に手を加えてほしくない相手は招待してはならない（Don't invite anyone who you don't want to mess with your sessions）」と明確に注意を促した。複数人が同時に参加できるということは、メンバーがお互いのセッションを変更できることを意味し、そのためにはチームがタスクの目標について共通の理解を持っている必要がある。共有セッションはお互いの意図を事前に把握し、一部の衝突を減らすのに役立つが、従来の Pull Request の仕組みが廃止されたことを意味するわけではない（PR とは Pull Request のことであり、コードベースにレビューおよびマージを依頼するために提出される一連の変更を指す）。
個人のセッションをチームに見えるサーバー上に置くには、通常、チームとしての習慣の転換を経る必要がある。Peter によると、以前彼はメンバーが PR を提出する際に個人情報をマスキングした対話ログを添付させようとプラグインを作成したが、進んで共有しようとする人はほとんどおらず、彼自身も提出をためらうことがあったという。Agent とやり取りするプロンプトには、個人の試行錯誤の癖やくだけた口語表現が色濃く出やすいためである。しかし、チームが社内サーバー上でセッションをデフォルト公開するようにしたところ、メンバーは約1日の適応期間を経て次第に慣れ、お互いのプロンプトを見て質問の仕方を学び合ったり、早い段階で思考のズレに気づいたりできるようになった。
変更を理解する：Victor のテーブルの事例
透明性の高いセッション記録は、チームの日々の協働において極めて重要な役割を果たした。講演では、変更に対する認識の違いから議論に発展した実際の事例が紹介された。
ある朝、Peter は自動化ツールによって提出された PR を目にした。作成者はチームの同僚である Victor だった。その PR の内容は、画面内のチャットテーブルのサイズを小さくするというものだった。Peter は前日に時間をかけてそれらのテーブルを大きくしたばかりだったため、その変更を見て非常に困惑した。
PR の詳細には関連する作業セッションへのリンクが添付されており、当時のやり取りのプロセスを他の人が遡って確認できるようになっていた。Peter がリンクをクリックして Victor の作業セッションを開くと、背後にある経緯が明らかになった：
- Victor は前日の作業を無視して勝手に覆したわけではなく、前日の Peter のセッションコンテキストを直接再利用していた。
- Victor はセッション内でメールやメッセージを通じて Peter に連絡を送っていた。
- セッションのやり取りの中で、Victor は CI の所要時間に対する愚痴を漏らしていた（これはセッション内の別の独立した話題である）。そしてテーブルの変更に関して、Victor はレイアウトを綿密に検討したうえで、コンテンツに応じて適応的に拡張するように設計し、大きすぎたり小さすぎたりする問題を解消していた。
これらの背景を理解した Peter は Victor の変更案に納得し、不要なコミュニケーションの行き違いを避けることができた。コードレビューからコード生成時の作業セッションを直接参照できるようになると、チームメンバーは変更の背後にある意図を直感的に把握できるようになり、非同期な協働における理解のコストが低減される。
共有ツールと長期タスクをどのように継続実行させるか
共有ツール：セッション生成と自動更新
チーム内の協働において、開発者は CI 所要時間ダッシュボードやコミュニティ PR の統計パネルなど、付随する多数のツールを維持管理しなければならないことが多い。従来、こうしたツールは異なるサーバーや自動化スクリプトに散在しており、更新やメンテナンスに手間がかかっていた。
Peter は、セッションを通じて生成され、修正にも即座に対応できるような軽量の社内ツールを 「ゼリーウェア」（Jellyware：ゼリーのように柔軟に改変できるソフトウェア） と表現した：
- この種のツールは通常、1つのセッションがコードを含む成果物（Artifact）を生成し、そのセッションを定期的に更新する自動化タスクと連携して動作する。
- ユーザーがUIや機能を調整したいときは、プロンプトで Agent に直接修正を指示することができ（例えば Agent に「このパネルを青色に変えて」と伝える）、Agent が該当コードを更新して表示を更新する。
ダッシュボードのほかにも、チームはサーバー上でマージされた変更点を抽出して新聞形式にまとめる Daily Claw を構築した。Peter によると、この日報は「ときどき良くできているが、多くの場合は非常に誤っている（many times it's very wrong）」とのことで、生成された内容は依然として人間による確認が必要であり、そのまま正確な記録として扱うことはできない。
CI ダッシュボード：テスト所要時間の確認
継続的インテグレーション（CI）パイプラインは、高頻度でコードテストを実行するための重要な構成要素である。Agent との協働が深まるにつれて、従来の全量テスト方式は応答速度の面で一定の負荷をもたらすようになった。
Peter は講演の中で、既存の CI 方式にはさらなる最適化の余地があると述べた。彼は Codex と組み合わせ、どのテストのサブセットが実際に有用であるかをモデルに補助的に評価させ、関連するテストのみを絞り込んで実行するアプローチを模索している。現時点ではこれはまだ模索中の試みであり、すでに確立された成熟した解決策ではない。
Slop Meter：冗長なコードのクリーンアップを促す
Agent を使ってコードを書いていると、コードは際限なく増えていきがちである。不要になったコードや冗長なコードが蓄積し続けるのを防ぐため、Peter は Slop Meter と呼ばれるダッシュボードを立ち上げ、コードの肥大化に注意を向けさせるとともに、Agent に冗長なコードのクリーンアップを求めた。Peter は、このダッシュボードによってメンバーの関心が高まり、事態が良い方向へ向かっていると考えている。
ミーティング議事録：コンテキストの保存とタスクの引き継ぎ
日常的なコミュニケーションの面では、チームはプロンプトとモデル（GPT-5.6-Luna）を組み合わせて、Discord でのミーティングの音声書き起こしを自動要約している。
Peter の説明によると、こうした議事録作成 Agent は GPT Live に接続して双方向の音声対話を行うことも可能で、開発者がミーティング中に作業の進捗を直接尋ねたり、新しいタスクを開始したりすることを支援できるという（会場ではこのリアルタイム対話機能の実演は行われていない）。Agent はサーバー上で統一されたIDを持ち、メインセッションで蓄積されたプロジェクトのコンテキストを引き継いでいるため、ミーティングで出た新しい要求を既存のプロジェクト作業へ直接つなげることができる。
長期タスク：ループによる保守とゴールによる推進
バックグラウンドでの自動実行に関して、Peter はタスクを「継続的ループ（Loops）」と「段階的ゴール（Goals）」の2種類に明確に区別した。前者は反復的な継続チェックを担い、後者は明確な完了状態を持つ長期タスクを対象とする。
2つの長期的な作業 2つの完了条件
ループは常に追跡し、ゴールは完了状態に向けて推進する
Loop · 継続的な保守
- フィードバックを監視し、レポートを読み込んで調査
- テスト環境で問題を明確に再現
- 修正案を提示し、問題が解決したかを検証
- 別の Agent にレビューを委任
- すべての条件が満たされて初めてマージへ
必要な条件が1つでも満たされない場合、直接マージすることはできない。
次のサイクルでも新たなフィードバックを追跡し続ける。ループが中断したり調整が必要になったりした場合は、チームが保守を引き継ぐ。
Goal · 段階的な刷新
- この完了状態に向けてリファクタリングを段階的に推進
- 変更を検証し、継続的にマージ
- 目標が未完了であれば、引き続き推進
Peter 本人の語り：この目標は当時すでに 18 日間稼働しており、100 を超える PR がマージされていた。
これは現在も進行中の具体的な刷新作業であり、固定された期間でも、すべてのプロジェクトに共通する生産性指標でもない。
Loop：フィードバックの反復チェックとリリース監視
継続的ループは、システムの定常運用と品質監視を維持するために用いられる：
- バグ修正ループ：Peter は小さな CLI ツールを作成し、Agent が Discord、ソーシャルメディア、GitHub からのフィードバックデータを効率的に取得できるようにした。フィードバックを取得して分類した後、更新に伴う不具合などの問題に対して、Agent はレポートを読み込んで調査を開始し、独立したテスト環境を立ち上げてエラーの再現を試みる。明確に再現できた場合にのみ、Agent は修正パッチの生成を試みる。そして修正が有効であることを検証した後、さらに別のレビュー用 Agent にコードレビューを委ねる。これらすべての条件が満たされた場合に初めて、変更が自動的にマージされる。明確に再現できない場合、検証に失敗した場合、あるいはレビューを通過しなかった場合は、いずれも直接マージすることはできない。
- リリース検知とリグレッションチェック：チームのサーバーで毎日のリリースが行われると、更新ループが新しいリリースを自動検知し、スナップショットを取得して性能劣化（リグレッション）がないか、改善すべき点がないかをチェックする。
これらのループ自体も時には停止することがあり、状況に応じて人間による調整や保守が必要となる。以前はこれらのループが個人の異なるマシン上で分散して動作しており、具体的にどこで動いているのか把握することすら困難だった。チームは現在、他のメンバーも状況を把握して引き継げるよう、ループを段階的にチームサーバー上へ移行させている。
Goal：明確な完了地点を持つ刷新の推進
定常的なループとは異なり、段階的ゴール（Goals）は明確な完了状態を持つタスクを対象とする。
Peter は現在進行中の実例として、コードベースを同期型の SQLite から非同期データベースアクセスへと段階的にリファクタリングする取り組みを挙げた。現時点でこのプロジェクトは依然として SQLite を使用しており、リファクタリングの目標は段階的に進行中である。システムの規模拡大に伴い、チームは将来的にデータベース自体を差し替え可能（swappable）にするかどうかも検討している。会場での Peter 本人の語りによると、この目標タスクはローカルの Codex 環境ですでに 18 日間継続して動作しており、その間に少しずつ分割されながら 100 を超える PR がマージされてきたという。
チーム拡大後、OCE はどのようにIDと権限を管理するか
ここまでに述べた共有スペースは、同等の権限を持ち、互いに信頼し合っているメンバーを前提としていた。しかし組織に適用する場合、異なるチームやタスクごとにリソースとアクセス範囲を個別に設定する必要がある。また組織としては、どの Agent が稼働しており、どのようなIDでシステムにアクセスしているのか、さらにはどのように権限を変更したり停止したりできるかを把握しなければならない。マルチプレイヤー協働の枠組みとは別に、統合された管理レイヤーが必要となるのである。
エンタープライズでのデプロイや権限ガバナンスにおける課題を解決するため、OpenAI の Kevin Lin はオープンソースプロジェクトである OpenClaw Enterprise（OCE） を正式に発表した。OCE は集約型のコントロールプレーンを提供し、Agent のデプロイ、設定、ID、アクセス権限を管理する（コントロールプレーンとは管理層を指し、マルチテナンシーとは異なるチームやプロジェクトのリソースとアクセス範囲を分離して管理することを指す）。
具体的な実行作業を担うのは Harness（モデルの周囲を取り囲み、ツール呼び出し、実行環境、コンテキスト状態を処理する実行フレームワーク）であり、これが Agent によるツールや環境の操作方法を決定する。OpenClaw の基盤は Codex のオープンソース実行基盤に接続することができる（オープンソース化の範囲は実行基盤であり、モデル本体や一連のクラウドサービス全体は含まれない）。そして OCE は、この実行層の上に位置する管理層である。公式の発表資料では、OCE がベンダー中立性を維持していることが強調されており、モデルを自由に切り替えられるだけでなく、Harness、モデル、サンドボックスを含む中核コンポーネントも、サードパーティのソリューションや社内独自の実装に置き換えることが可能である。
権限制御の仕組み：4つの制御はいかに連携するか
Kevin は講演の中で、Agent のデプロイを支える4つのセキュリティメカニズムを紹介した。それぞれの仕組みが異なる境界の責務を担っている：
- 信頼されたロジックと実行の分離（Separate Workloads）：決定論的（deterministic）な制御ロジック（ゲートウェイや設定管理など）と、非決定論的な Agent のコード実行を互いに分離する。実行環境を独立したコンテナや環境で動作させることで、Agent が下層の実行設定を不正に書き換えるのを防止する。
- サンドボックスによる制約（Sandboxing）：サンドボックスを通じて Agent の動作に制約を課し、アウトバウンド通信、ファイルシステムの読み書きパス、プッシュ可能な対象コードリポジトリを制限することで、権限の拡散を抑え込む。
- モデル補助による自動レビュー（Model-based Auto-review）：慎重な扱いを要するアクションを実行する前に、別のモデルを導入して操作リスクを評価・遮断し、追加の防衛線とする。モデルによるレビューはリスク判断を提供するものであり、システム本来のアクセス制御ポリシーの代わりにはならず、人間の承認と同等でもない。
- 独立したサービスアカウントとID（Dedicated Identity）：Agent に独立したサービスアカウント（Service Account）とコネクタを設定し、人間の従業員のアカウントを直接流用することなく永続的なエンティティとして存在させる。これにより、Agent に独立した監査用識別子を持たせ、個別の管理、監査、必要に応じた停止を可能にする。
実際の設定において、これら4つの仕組みは互いに連携する。デモに登場したコミュニティ Agent「Fred」を例にとると、システムはこれに対してコードリポジトリへの読み取り専用権限を設定し、コードを参照して質問に答えることはできるが、変更をプッシュする権限は与えない。タスク管理ツールの Linear に接続する際は、計画の閲覧は許可されるものの、書き込み操作にはチームの承認が必須となる。同時にモデルによるレビューを併用して操作リスクをフィルタリングするが、これは組織の権限に代わって許可を発行するものではない。これらの設定により、同一 Agent の異なるアクションが切り離して管理される。すなわち、コードを読めるからといってコード変更を提出できるわけではなく、Linear に接続しているからといって記録を自由に変更できるわけではないのである。
Fred のデモ設定を例として
Agent にタスクを与えることは、全権限を与えることと同義ではない
アクションを選択し、組織設定が「読み取り許可」「書き込み不許可」「事前の承認申請」をどのように区別しているかを確認する。
コードリポジトリは読み取り専用に設定されているため、読み取りは許可されますが、変更のプッシュに読み取り権限を流用することはできません。
システム権限どのリソースとアクションが許可されるかを決定。
モデルレビューアクションのリスクを補足的に識別するものであり、組織に代わって権限を付与することはできない。
人間の承認承認が必要な該当の書き込み操作を続行してよいかをチームが判断。
これはデモ設定に基づく権限の説明であり、実際のリソースを呼び出すものではありません。また、許可が得られたとしても実行が成功したことを意味するわけではありません。実際の隔離および承認機能はデプロイ設定に依存します。
デプロイのデモ：タスクに応じた Agent の設定
会場でのデモにおいて、Kevin は OCE コンソールから Fred という名前のコミュニティ Agent を立ち上げる手順を実演した。
コンソールにはプリセット（Preset）の仕組みが用意されている。これは組織が事前にパッケージ化した設定可能なバンドル（configurable agent bundles）であり、一般的なセキュリティ設定を備えた Agent の下書きをオンデマンドで作成できる：
- 実行フレームワークを Codex Harness に設定。
- 専用の独立したサービスアカウントを割り当て。
- 質問に答えるためにコードを参照できるよう、コードリポジトリへの読み取り専用権限を付与。
- コラボレーションプラットフォーム Linear との連携：プロジェクト計画の閲覧は許可し、変更の書き込みにはチームの承認を要求。
- Slack との連携：クレデンシャルストアから既存の Bot Token および App Token を参照し、選択された 4 つのチャンネル内に限定して利用するよう設定したうえで、ダイレクトメッセージ（DM）ポリシーを無効に設定（これらは今回のデモで選定されたチャンネルおよび DM ポリシーである）。
Cooper：チームメイトによる開発セッションの引き継ぎ
Fred の作成を開始して起動を待つ間、Kevin はすでに稼働中だった別のソフトウェアエンジニアリング Agent Cooper へと画面を切り替えた。
Cooper はチーム内の常駐型協働 Agent として位置づけられており、日常的な Issue のトリアージ、不具合の調査、機能開発の推進を支援している。Kevin は、OCE を通じてデプロイされたすべての Agent にマルチプレイヤー協働のサポートが組み込まれていることを明確に指摘した。彼は会場で、認証済みの Cooper チームサーバーセッションを開く様子を実演した。チームの同僚は同じ作業セッションにログインでき、リアルタイムで進捗を追跡できるだけでなく、プロンプトを直接入力して開発をそのまま主導することもできる。
会場でのデモにおいて、Kevin は Cooper に対して「各 Agent の Token 使用量ヒートマップ」をコンソール画面に追加するようリクエストを出し、さらにセッション内で「カスタムカラーパレットへの対応」を求めるプロンプトを入力した。会場では要望を発行し、セッション内で引き継いで誘導していくプロセスが示されたが、完成後の画面は展示されなかった。講演における Kevin 本人の語りによると、OpenAI 社内では 400 を超える Claw インスタンスがデプロイされており、コードの修正、実験の実行、データ分析、セキュリティ問題のフォローアップに活用されているという。ユーザーから提出された Codex の Issue に対しても、ソフトウェア Agent がトリアージと調査を行い、テスト環境で再現したうえで、一部の修正 PR をマージしている。
Fred：業務情報の読み取りと的を外した回答
Cooper の紹介を終えた後、Kevin はコミュニティ画面に戻り、起動が完了したばかりの Fred に対して「私たちは今日、何をリリースしているのか？」と質問した。
Fred は質問を受け取った後、Linear と Slack のコンテキストを検索した。数秒後に Fred は回答を返したが、その内容は OpenClaw のリリースノートを示すにとどまり、OCE を発表するという肝心な事項が漏れていた。Kevin は会場でプラグインの問題かもしれないと言及し（「おっと、プラグインに問題があるようです（Oops, I think we have some plug-in issues）」）、登壇上で次回はもっとうまくやってくれと冗談めかして語った。
OCE は現在どのような段階にあり、どのような制限があるか
公式リリースノートによると、OCE は現在 1.0 正式リリース前のオープンソース共創段階にあり、組織における社内パイロット運用の開始に適したステータスとなっている。このプロジェクトはもともと OpenAI によって立ち上げられたが、初期段階で独立した非営利組織 OpenClaw Foundation に寄贈され、Red Hat や NVIDIA などのパートナーとともに共同開発が進められており、ベンダー中立性を保っている。Kevin が講演の中でこれを Kubernetes になぞらえたのは、主に Agent のデプロイと管理における基盤フレームワークに育て上げたいという長期的なビジョンを表現したものであり、現時点で業界の既定標準になっているという意味ではない。
実際の実行アーキテクチャに関して、Kevin は壇上で社内の実践例として異なるクラスタ間で実行環境を分離していると言及したが、公開アーキテクチャ設計書におけるデフォルト構成は単一の Kubernetes クラスタとなっている：
- 単一クラスタのマルチテナント（multi-tenant）モデルにおいて、埋め込みモード（Embedded）を採用した場合、Gateway と Harness はデータプレーン上で統合されて動作する。
- 専用実行モード（Dedicated Kubernetes execution）を採用した場合に限り、テナントのネームスペース内で独立した Gateway および Harness の Pod、分離されたIDおよびストレージが使用される。このとき Gateway は制限されたファイル操作インターフェースを介して Harness と通信し、そのワークスペースを直接マウントすることはない。
2クラスタによる実行構成は、現時点ではまだ実験的段階にとどまる。単一クラスタでのデプロイにおいては、インフラ運用担当者が相互排他的なノードプール、ネットワークポリシー、ストレージ分離ルールを自前で設定しなければならない。ネームスペース管理者自身が高度な権限を保持しているため、ネットワークポリシーやクレデンシャルのマウントによって Namespace 管理者を厳密に隔離できるわけではないためである。
さらに、公開設計書に記載されている計画段階の機能の一部（外部アクセスゲートウェイやクレデンシャル不要の推論仲介ドライバなど）は、現時点ではまだ完全にはサポートされていない。講演では OpenAI の公式エンタープライズ統合ソリューションである Dots についても言及された。Dots が導入後すぐに使えるネイティブな製品体験に重点を置いているのに対し、OpenClaw と OCE はオープンソースの中立性、モデルの差し替え可能性、全コードの制御可能性、インフラのセルフホストに焦点を当てている。両者の将来的な双方向連携も、チームの研究方針のひとつとなっている。
自動化の後、人間は何に責任を持つべきか
スタンドアロン端末での分散したセッションから、共有サーバーを利用した協働コンテキストの蓄積、さらにはコントロールプレーンを導入した実行権限とデプロイ境界の管理に至るまで、今回の登壇はソフトウェアエンジニアリングが「生身の中継役」からチームの協働へと進化していく道筋を示した。
デザインの判断：Victor によるサイドバーの試行錯誤
長期的なビジョンとして、Peter は将来、すべてのプロジェクトに常駐 Agent が配属され、独立した記憶、自動化、目標、ループ（automations, goals, loops）を持ち、人間が高レベルな指示を出して保守を支援させる世界を思い描いている。このような役割分担において、エンジニアの代替不可能な中核的価値となるのが審美眼や判断のセンス（Taste）である。インタラクションの細かな肌感覚、視覚デザインの直感、アーキテクチャスタイルの取捨選択は、往々にして主観的な判断に属するものであり、モデルに完全に委ねることは難しい。
講演でオンラインメンバーのサイドバーが紹介された際にも、この審美眼を研ぎ澄ます具体的なプロセスが示されていた。Peter がまず誰がオンラインかを表示する粗削りなバージョンを作成した。Victor はそれをより洗練された見た目にしたいと考え、Agent に複数の異なるデザイン案を生成させ、さらにはスタイルを微調整するための専用エディタまで Agent に構築させたが、それでも Victor は満足しなかった。その後、他のチームメイトも同じセッションに参加して共同で修正を行い、要望を出し続けることで、最終的により魅力的なバージョンが確定したのである。
このプロセスが示しているのは、チームが共有ワークスペースに蓄積しているものが、最終的にマージされたコードだけにとどまらず、Agent にどのように要求を伝えるか、生成された複数の選択肢の中からどのように選別・取捨選択するかという試行錯誤の過程そのものであるということだ。バックグラウンドの自動化がどのように動作しようとも、選択肢を見極める審美的な判断と、Agent システム自体の保守責任は、常に人間の手の中に残る。
運用と保守：自動化の可用性を維持する
Peter はこの分担について、「チームは自分たちの代わりにソフトウェアを構築してくれる Agent 自体もメンテナンスしている」と総括した。継続的なループがフィードバックを自動でチェックし、段階的なゴールがアーキテクチャを着実にリファクタリングできるとしても、バックグラウンドで動作する自動化の仕組み自体が停止したり調整が必要になったりするため、人間の日常的な保守は依然として欠かせない。そしてインタラクション体験、アーキテクチャのスタイル、方針の選択において、人間の審美眼や判断のセンス（Taste）はシステムにとって不可欠な羅針盤であり続ける。
オープンソースでの共創：ツールのアクセシビリティ拡大と脆弱性修正
オープンソースコミュニティの面において、チームは Codex のオープンソース支援プログラムを拡張し、Trail of Bits などのセキュリティ機関と提携した Patch the Planet プロジェクトを通じて、オープンソースの基盤ソフトウェアにおける一連のセキュリティ脆弱性を Agent を活用して修復する取り組みを模索している。永続的な Agent を実際のチームに安定して定着させるには、信頼できる権限と隔離の境界が必要であると同時に、共有された協働の中で人間のエンジニアが継続的に判断力を注ぎ込むことが常に求められている。