自前のKubernetesクラスタにOpenClawを載せるとき、ネットワーク分離やデバイス承認、暗号化ストレージまで手作業で揃えるのは手間がかかります。2026年6月27日、EdkaはOpenClawを自前クラスタへ高速デプロイできる機能を追加したと発表しました。ダッシュボードからエージェントを選ぶだけで、実運用に必要な構成要素をまとめて用意できます。

この記事では、Edkaの新機能が何を解決するのか、どのような運用要素が含まれるのかを整理します。

  • Edkaが追加したOpenClawデプロイ機能の概要
  • TailscaleとCloudflare Zero Trustによる非公開アクセス
  • Edka UIからのデバイス承認の流れ
  • ネットワーク分離・暗号化ストレージ・監視の位置づけ
  • 導入の前提条件と料金の目安

https://edka.io/

何が変わったか

Edkaは、ユーザー自身のクラウドアカウント上にKubernetes基盤を構築するインフラ自動化プラットフォームです。アプリやデータベースに加え、HermesとOpenClawといったAIエージェントランタイムの運用も対象にしています。

今回の更新では、OpenClawを自前Kubernetesクラスタへ素早く載せられる点が前面に出ています。発表では次の要素が挙げられました。

  • TailscaleまたはCloudflare Zero Trust経由の非公開アクセス
  • Edka UIからのデバイス承認
  • Kubernetesネットワークポリシーによるネットワーク分離
  • 暗号化ストレージとメトリクス

OpenClawは、WhatsAppやSlack、TelegramなどのチャットアプリとAIエージェントをつなぐセルフホスト型ゲートウェイです。1つのGatewayプロセスがセッション管理、ルーティング、チャネル接続を担い、開発者向けの常時稼働アシスタントとして設計されています。npmでの単体インストールも可能ですが、Kubernetes上で常時稼働させる場合は、ネットワークやストレージ、ペアリング承認の設計が欠かせません。

なぜKubernetes運用が課題になるか

OpenClawを本番相当の環境で動かすとき、ゲートウェイはセッションやツール実行の制御面にあたります。Control UIやWebhook、各種チャネル連携を公開するなら、アクセス経路と承認フローを最初から決めておく必要があります。

OpenClaw公式ドキュメントでも、Webhookはループバック、tailnet、信頼できるリバースプロキシの背後に置くことが推奨されています。デバイスやブラウザのペアリングは、Gatewayが発行する承認リクエストを管理者が明示的に承認する仕組みです。CLIでは openclaw devices approve で処理しますが、Kubernetes上ではUIや運用手順の整備が別課題になります。

Edkaは、この運用負荷をプラットフォーム側に寄せる方向です。クラスタはユーザーのHetzner Cloudアカウント内に置かれ、Edkaはその上のKubernetesレイヤーを管理します。インフラの請求はHetznerに直接行われ、Edkaはプラットフォーム利用料を別途請求するモデルです。

デプロイの流れ

Edkaのエージェント機能は、Workloads → Agents から操作します。Deploy Agentを選び、ランタイムとしてOpenClawを指定して設定フォームを送信すると、カタログ定義に基づくKubernetesリソースが展開されます。必要なアドオンも同じパイプラインでインストールされ、進捗はエージェントカードに表示されます。

エージェント詳細画面では、ランタイムの健康状態、CPU・メモリ使用量、ダッシュボードURL、ログなどを一覧できます。OpenClawはプロファイル機能を持たない一方、ブラウザやデバイスのペアリング承認に対応しているため、Devicesタブが表示されます。

デバイス承認の手順は次のとおりです。

  1. エージェント詳細からOpenClawダッシュボードを開く
  2. Control UIでブラウザペアリングが必要と表示されるまで待つ
  3. EdkaのDevicesタブでApproveをクリックする
  4. Control UIへの接続を再試行する

Approveを押すと、Edkaは稼働中のOpenClawゲートウェイから最新の保留中リクエストを取得し、そのIDを承認します。Control UI側からリクエストIDをコピーして貼り付ける必要はありません。ブラウザが異なる認証情報で再試行した場合は保留リクエストが置き換わるため、ペアリング待ちの表示が出ている状態で再度Approveする運用になります。

非公開アクセスの2つの経路

Edkaはプライベートトラフィック向けに、用途の異なる2系統を用意しています。

Tailscale

Tailscaleオペレーターをクラスタに導入し、tailnetへトラフィックを公開する方式です。Gateway APIと組み合わせる場合は、露出モード Tailscale tailnet (BYOD) のGatewayクラスを作成します。Envoy Gatewayはクラスタ内に残り、Gatewayサービスがtailnetへ公開されます。カスタムドメインを持たない場合は、デプロイのネットワーク設定で tailscale トラフィッククラスを選び、ワークロードごとにtailnetホスト名を割り当てる方法もあります。

Cloudflare Zero Trust

MetalLBがクラスタのプライベートサブネット上にVIPを割り当て、Cloudflareコネクタ（cloudflared）がそのサブネットをZero TrustのCIDRルートとして広告します。WARPクライアントからMetalLBのプライベートVIPやクラスタ内の非公開サービスへ到達できます。Account IDとAPIトークンを指定してアドオンをインストールする流れです。

どちらもインターネットに直接Control UIを晒さず、信頼境界の内側からエージェントを操作する構成に向いています。OpenClawのWebhookやダッシュボードを社内や個人tailnetからだけ触れるようにする用途に合います。

ネットワーク分離とストレージ

発表では、Kubernetesネットワークポリシーによるネットワーク分離が明記されています。エージェントPodが不要な通信を受け付けないよう、クラスタ内のトラフィックを制限する考え方です。OpenClawを本番Kubernetesへ載せる際、ゲートウェイを制御面として扱い、周辺サービスとの通信を最小限にする設計は、セルフホスト型エージェント運用の定石です。

ストレージ面では、Edkaのデプロイ設定でHetzner Block Storage Encryptedを選べます。永続ボリュームはノード再起動や再スケジュール後も保持され、LUKSによる暗号化が適用されます。エージェントの状態や設定をディスク上に持つOpenClawのようなランタイムでは、暗号化ストレージは本番環境向けの選択肢として位置づけられます。

メトリクスについては、Edkaがクラスタのオブザーバビリティ機能を提供しており、エージェントカード上でもCPU・メモリ・Podリソース使用量を確認できます。Gateway周辺の常時稼働ワークロードを、ダッシュボードから定点観測する運用が想定されています。

料金と導入の前提

Edkaの無料プランでは、最大24 vCPUまでのクラスタを1つ運用できます。Standardは月額180ユーロでクラスタ2つ、Proは月額450ユーロでクラスタ3つが対象です。いずれもクラウドインスタンス本体の料金はHetznerへ直接請求されます。

クラスタ作成にはHetzner CloudのAPIトークンが必要です。Edkaはk3sベースのKubernetesを約2分でプロビジョニングする設計で、Gateway API、証明書管理、データベース、オブザーバビリティ用アドオンをワンクリックで追加できます。AWSやGoogle Cloudへの対応は「近日公開」とされており、現時点で本番導入の主戦場はHetznerです。

Edkaはワンクリックでプラットフォームから切り離せ、ワークロードはクラスタ上に残ると説明しています。OpenClawを試す段階から本番相当の非公開運用へ移行する場合、Kubernetesネイティブな構成を維持したままエージェントだけを載せ替えやすい点が利点です。

他のOpenClaw運用手段との違い

OpenClawは npm install -g openclaw と openclaw onboard で単一マシンへ導入するのが基本ルートです。VPSの1クリックイメージを提供するホスティング事業者もありますが、Kubernetes上でのマルチワークロード運用やネットワークポリシー、GitOps連携まで含める場合は、プラットフォーム層の支援が効きます。

EdkaはHermesも同じAgentsワークスペースで扱えるため、学習ループ重視のHermesと、マルチチャネルゲートウェイ重視のOpenClawを、同じクラスタ運用モデルの上で選べます。OpenClawを選ぶ理由は、複数チャネルと複数エージェントのルーティング、Control UI、デバイスペアリングといったゲートウェイ中心の運用を重視する場合に当てはまります。

Kubernetesとゼロトラスト、エージェント運用の交差点にいるチームにとって、今回の機能追加は「自前インフラの境界内でOpenClawを速く、安全寄りに載せる」選択肢を増やす動きと言えます。