Linux Containerで作っていたCellをmacOSユーザーに変えた

✨ GPT-5.6 Solの要約

Linux VMとユーザー別Containerを基本とした計画をやめ、従業員ごとのmacOSユーザーとnative OpenClawを実行単位として定め直した記録。

一日で基本構造をひっくり返した

昨日はコーディネーターとワーカーを実際につないでみた。複数のAIが作った結果をWorktree、Branch、commitに分け、もう一度まとめる方法を試した。

その作業と並行して、AI Orchestrationの実行環境も作っていた。14日まで考えていた基本構造は次のとおりだった。

Mac mini
→ Colima Linux VM 1台
→ 従業員ごとのOpenClaw Cell Container

共通Imageを作り、従業員ごとにNetworkとVolumeを分ければ、デプロイと再現が容易に見えた。実際に公式OpenClaw Linux arm64 Imageを確認し、child ImageとCell Networkの契約も作った。従業員ごとの環境をContainerで分離する方向が、かなり具体化していた。

だが15日、この構造を基本案から外した。

作ろうとしていたのはContainerサービスではなかった

AI Orchestrationの目的を改めて書き出すと、ずれていた部分が見えた。

私が作りたかったのは、従業員がWebChatに目標だけを伝えれば、個人AIが必要な作業を分け、ツールを選び、最後まで処理する環境だった。コードや文書を作るだけではなく、Macアプリを操作し、XcodeとSimulatorを起動し、ユーザーのWorkspaceとGit identityで実際の成果を残さなければならなかった。

Linux Containerの中から無理にmacOSの機能を呼び出した瞬間、構造がおかしくなる。Containerの外に別の実行機構を置き、権限と状態をもう一度つなぎ、ユーザーのKeychainとGUI Sessionを渡さなければならない。分離のために追加した階層のせいで、本当に必要な機能には迂回路ばかり作ることになった。

OpenClawも単純なstateless workerではなかった。一人のユーザーのGateway、Profile、Session、Memory、OAuth、実行状態をまとめて持つ個人環境に近かった。それなら、CellをContainer一つと定義したこと自体が間違っていたのかもしれない。

15日、Cellの意味を定義し直した。

従業員1人
= macOSユーザー1人
= 独立したOpenClaw Gateway 1つ
= UID・HOME・Keychain 1セット
= ChatGPT OAuth・CODEX_HOME 1セット
= Workspace・Git identity・Session・Memory 1セット

一台のMac miniに従業員ごとの独立したmacOSユーザーを作り、各ユーザーの中でcomplete OpenClaw Gatewayをnative実行する構造だった。

LinuxとContainerを失敗として消しはしなかった

方向を変えたからといって、14日までに作ったものを失敗として扱いたくはなかった。

Containerの実験で確認できたことは確かにあった。公式Image、非root実行、read-only root、Networkの分離、Volumeとcredentialの境界、Image provenance、restartに関する証拠には、そのまま価値があった。

ただ、それが最終的なCellの定義ではなかった。

Linux VMとContainerは基本のPilot環境ではなく、本当に分離が必要な特定の作業だけで選ぶsandbox候補へ下げた。native macOSを基本とし、Containerは必要性が証明されたときに使うツールになった。

この違いは重要だった。すでに多くの時間をかけたという理由でContainer構造を押し進めれば、製品が実行環境に振り回されることになる。実装した量は、その選択を正当化してはくれなかった。

macOSユーザーを分けるだけで分離が終わるわけでもなかった

native構造は単純に見えたが、検証すべきことは増えた。

• ログインした従業員と実際に実行するmacOSユーザーは同じか？
• そのユーザーのGateway、OAuth、Workspace、Git identityが正確に結び付いているか？
• あるユーザーの認証に失敗したとき、別のユーザーの認証へ切り替わらないか？
• 別のユーザーのHOME、Keychain、Port、Workspaceへアクセスできないか？
• ファストユーザスイッチと再起動の後も、各Gatewayが自分の状態で復旧するか？

だから、文書上のtopologyを変更しただけでは終わらせなかった。native macOS Cellの契約とAcceptanceを新たに作り、実際のRuntime証拠がない項目はNOT_READYのまま残した。

テストfixtureが通ったからといって、実際の二人のユーザーの分離が完了したとは言えなかった。外部入力ファイルのhashと実際のprobe実行証拠を分け、別のユーザーを装った値やsymlink、macOSの大文字・小文字やUnicodeのパスaliasで検査を迂回できないように修正を重ねた。

正午にtopologyを変えてから、午後はずっと「通ったと偽れる抜け道」をふさぐcommitが続いた。構造を変えることより、新しい構造の合格条件を正直なものにする方が、さらに多くのコードを必要とした。

共通Workflowと個人状態も分けた

従業員ごとに完全に別の環境を与えても、会社が管理する共通Workflowは同じversionでデプロイしなければならなかった。その一方で、共通Workflowを更新したからといって、個人のOAuth、Memory、Workspaceまで変わってはいけなかった。

15日の午後には、Workflow Releaseをversionとcontent hashで固定し、検証済みのreleaseだけを選択できるadmission契約を作った。新しいreleaseの選択はatomicに切り替わらなければならず、実行中の作業は開始時に選んだreleaseに固定され、rollbackや整理の過程でも使用中のreleaseが消えてはならなかった。

これもSourceとテストを作ったからといって、実際のMacの共用インストール先へデプロイしたとは記録しなかった。インストールしていないRuntimeは、最後までNOT_READYだった。

製品が実行環境より先だった

14日は、複数のAIをどう分け、どう統合するかを考えた。15日は、そのAIたちが実際に暮らすCellとは何かを改めて考えた。

Containerをかなり準備した段階でnative macOSへ方向を変えることが惜しくなかったわけではない。それでも、製品がやるべきことにMacアプリ、Xcode、ユーザー別OAuth、Memoryまで含まれるなら、実行環境もその目的に従わなければならなかった。

Cellは分離されたprocess一つではなかった。一人の人が自分の認証、記憶、作業空間、ツールを持って働く、完全な個人AI環境だった。

15日は、Linux VMの上にさらにContainerを重ねる代わりに、macOSユーザーそのものをCellの境界にすると決めた日だった。