メインコンテンツまでスキップ

コンテナクラウドからインテリジェントクラウドへ

· 約7分
tanzhuo

AI エージェント（Agent）システムが今日まで発展してきた結果、単一のエージェントではもはや足りなくなりました。私たちに必要なのは、マルチエージェントの協調、観測可能な実行トレース、安全な副作用ガバナンス、そして分散環境での信頼性の高いスケジューリングです。

OpenClaw は gateway、tools、sessions、ローカルでのマルチエージェントルーティングにおいて優れた性能を発揮していますが、大規模な協調、ノード間スケジューリング、オペレーターへの可視性という面ではまだ弱点があります。一方、golutra のようなオーケストレーションと trace の能力は、貴重な補完を提供してくれます。

OpenClaw の gateway runtime をベースに、私はひとつの進化アーキテクチャを提案します。Kubernetes を堅牢な土台とし、その上に AI 専用に設計されたコントロールプレーンを構築する——これを Kubernetes AI OS と呼びます。Kubernetes を置き換えるのではなく、インフラストラクチャ層として位置づけ、エージェントランタイム、実行スケジューリング、ケイパビリティディスカバリー、副作用ガバナンス、ノード間協調といった能力を新たに加え、真にオペレーターに向き合った実行システムを作るのです。

なぜこのアーキテクチャが必要なのか​

OpenClaw は現在、channels、tools、sessions、ローカルのマルチエージェントルーティングにおいて強力ですが、大規模な協調、実行トレースの監査、ノード間の配置についてはまだ明らかな弱点があります。

私たちが融合させたいのは次の三つです。

  • OpenClaw のサウスバウンド統合と agent runtime
  • golutra 的な実行トレースと可視化の能力
  • Kubernetes のライフサイクル管理、スケジューリング、障害復旧の能力

核心となる理念は一言に尽きます。実行は可視化でき、検査でき、帰属を特定できなければならない。明確な実行台帳がなければ、マルチエージェントシステムは容易にブラックボックスと化してしまいます。

設計目標​

  • 単一ノード内でのマルチエージェントの明確な協調をサポートする
  • ノードをまたぐワークフロー単位のスケジューリングをサポートする
  • ノードの自動参加・隔離・復旧を可能にする
  • 小規模モデルでロール推薦を補助するが、高リスクの意思決定は必ずポリシープレーンを通す
  • 意味のあるすべてのアクションを統一実行台帳に記録する
  • コントロールプレーン、実行プレーン、可観測性プレーン、ポリシープレーンを明確に分離する

やらないこと：Kubernetes ネイティブのスケジューリングを置き換えない。エージェント同士の無制限な自由チャットを許可しない。権限昇格やトポロジー変更といった高リスク操作をモデルに直接決定させない。

六層アーキテクチャの概要​

システムは六つの層に分かれ、責任の境界は明確です。

  • Southbound Gateway Layer：OpenClaw の channel・tool・session 接続能力をそのまま活用する
  • Execution Kernel：中核となる実行層で、Run → Flow → Step → SideEffect の全ライフサイクルを管理する
  • Cluster Mesh：ノード登録、ケイパビリティの公開、step のスケジューリングとセキュリティ隔離を担当する（ノード間の自由なチャットは推奨しない）
  • Observability Plane：統一実行台帳として、runs、flows、steps、side effects の可視化ビューを提供する
  • Cognition Plane：小規模モデルで workload の識別、ロール推薦、状態サマリーを行う
  • Policy Plane：セキュリティ承認、secret のスコープ管理、side-effect ガバナンス、信頼チェックを担当する

コントロールプレーンは「何を実行すべきか、どこで実行するか、どのポリシーで実行するか」を決定し、実行プレーンは実際の実行を担って trace を生成します。

単一ノードのマルチエージェントランタイム​

ノードが一つしかなくても、複数ロールの協調実行をサポートすべきです。推奨する基本ロールは次のとおりです。

  • Planner（計画）
  • Executor（実行）
  • Reviewer（レビュー）
  • Watcher（監視）
  • Specialist（ドメインエキスパート）

すべてのアクションはまずローカルの ledger に報告され、その後コントロールプレーンで集約されることで、実行トレースの明確な可視性が確保されます。

ノード間スケジューリング：チャットではなく Step ベースで​

ノード間協調のカギは、ノード間で自由にメッセージを転送させるのではなく、Step を単位としてスケジューリングすることです。これによって初めて、所有権の明確さ、キャンセル可能性、監査可能性が保証されます。

スケジューラは、必要なツール、モデルの可用性、ハードウェアリソース、locality、信頼レベル、tenant のアフィニティといった要素を総合的に考慮します。

ノードの状態には joining、ready、degraded、quarantined、draining などがあり、高リスクノードの自動隔離をサポートします。

中核プリミティブ：Execution Ledger（実行台帳）​

これはシステム全体で最も重要な部分です。すべてのイベント（run、flow、step、side effect、policy など）は runId に紐づけられ、統一的にクエリ可能な台帳を形成します。

オペレーターは次の問いに簡単に答えられるべきです。

  • どの agent が実行しているのか？
  • どんな副作用が発生したのか？
  • 現在どのステップで止まっているのか？
  • この失敗は安全にリトライできるのか？

Kubernetes との関係​

Kubernetes は引き続き、Pod のスケジューリング、liveness、service discovery、ストレージ、RBAC といったインフラストラクチャ能力を担当します。

AI OS 層は CustomResource（CRD）を通じて HiveRun、HiveFlow、HiveStepLease、HiveNode などのオブジェクトを表現し、Operator でリコンサイルロジックを実装します。

進化の道筋の提案​

小さな一歩から始めることをおすすめします。

  1. Phase 1：単一ノードで run ledger、flow graph、side-effect の可視化を整備する
  2. Phase 2：単一クラスタの step scheduler とノード管理を実装する
  3. Phase 3：軽量なロール推薦を追加する
  4. Phase 4：適応的なクラスタ挙動を実現する

最初の目標は完全な自律を追求することではなく、まず単一ノードで一級の可観測性を備えた AI ランタイムを作ることです。まず実行を可視化し、次に副作用をガバナンス可能にし、最後にノード間スケジューリングに取り組みます。

まとめ​

Kubernetes AI OS の目標は、Kubernetes を AI 時代のオペレーティングシステムの土台へと真に進化させることです。安全性と制御可能性を保った前提のもとで、マルチエージェントの協調能力を最大限に発揮させます。車輪の再発明はせず、OpenClaw のサウスバウンド接続、golutra 的な実行トレース、そして Kubernetes のスケジューリング・復旧能力を組み合わせます。設計全体はただ一つの主軸を巡っています——実行は可視化でき、検査でき、帰属を特定できなければならない。実装は一足飛びである必要はありません。単一ノードの実行台帳から始めて、段階的にノード間スケジューリングと適応的クラスタへと進んでいけばよいのです。

COMMENTS