エージェントはアイドルでも、Kubernetesの請求は止まらない

Agent Substrateとは

Agent Substrateは、デフォルトでセキュアな設計のエージェント実行ランタイムです。標準的なコンテナランタイムの10倍の密度で数百万のサンドボックスを実行できるように設計されており、500ミリ秒未満での再開と、毎秒500件以上の一時停止/再開を処理できます。分離はデフォルトでgVisorが担い、より強固な境界を必要とするワークロード向けには、マイクロVMサンドボックスクラス(Kata Containers + Cloud Hypervisor)をオプションで利用できます。

中核となる考え方は**多重化(マルチプレクシング)**です。Substrateは、多数のアクター(エージェントのインスタンス)を、はるかに少数のワーカー(実際に実行を担うサンドボックス)のプールにマッピングします。エージェント型のワークロードは時間の大半をアイドル状態で過ごす、という前提に基づく設計です。

本題に入る前に、押さえておきたい用語がいくつかあります。

• アクター(Actor): 実行中のエージェントの1インスタンス
• ActorTemplate: 特定バージョンのアクターを作成するためのイミュータブルな設計図(コンテナイメージ、環境、スナップショットポリシー)
• ワーカー(Worker): アクティブなアクターが実行されるサンドボックスPod
• WorkerPool: アクターを受け入れる準備が整った、事前ウォームアップ済みワーカーの集まり
• Atespace: アクターとテンプレートが所属する、namespaceに似たグルーピング

これが1エージェント=1Podの構成よりはるかに高密度で動作できる理由は、SubstrateがKubernetesのコントロールプレーンをクリティカルパスから外しているためです。基盤となるPodのプロビジョニングと管理は引き続きKubernetesが行いますが、Substrateはすべての一時停止/再開サイクルをPodスケジューリング経由にはしません。それらはSubstrate自身のコントロールプレーンが直接処理します。アクターとワーカーのライフサイクルを担うateapi、WorkerPoolを調整するatecontroller、DNSとルーティングを担うatenet、そしてノードレベルのDaemonSetとして動作するateletです。

Agent Substrateは、標準的なOCIコンテナを生成するあらゆるフレームワークと連携できます。プロジェクトでは、Agent Development Kit、LangChain、Claude Codeとのインテグレーションパターンが紹介されています。Agent Substrate自体はエージェントフレームワークやSDKではなく、その下層を支える基盤(サブストレート)です。

この複雑さに見合う価値

信頼できないコードは、AI生成のものであれ単発のツール呼び出しであれ、カーネルとネットワークの分離環境の中で実行され、クラスタの他の部分を危険にさらしません。アクターの作業メモリとファイルは一時停止サイクルをまたいで保持されるため、最初からやり直すのではなく、停止した地点から正確に再開できます。復元は1秒に満たない速さのため、バースト的で人間と対話するエージェントでも応答レイテンシは許容範囲に収まります。そして、ウォームなワーカーの共有プールが多数のアクターを処理するため、アイドル状態のアクターが使っていないコンピュートに費用を払う必要がありません。

この組み合わせは、特定のワークロードによく適合します。数日にわたってコンテキストを保持しつつ短いバーストでしかアクティブにならないバックグラウンドアシスタントは、バースト間の一時停止によって節約効果の大半を得られます。信頼できないLLM生成コードを実行する使い捨てサンドボックスは、1秒未満の復元の恩恵を受けます。毎回フルコールドブートすることなく、起動し、タスクを実行し、解放できます。開発者とリアルタイムのやり取りを行うコーディングエージェントは、プロンプトの間もターミナルとファイルシステムの状態をそのまま保持しつつ、クラスタは実際にアクティブな開発者にだけコンピュートを費やします。

リクエストが実際に処理される流れ

テンプレートからアクターが作成されると、Substrateは一時的な「ゴールデンPod」を起動し、コンテナのスタートアップロジックを一度だけ実行し、初期化が完了した瞬間にゴールデンスナップショットを取得します。以降、そのテンプレートから作られるすべてのアクターは、コールドブートではなくこのスナップショットから再開します。そのため、コストの高い初期化処理(モデルのロード、ベースライン接続の確立など)は、ウェイクアップのたびに繰り返される場所ではなく、エントリーポイントに置くべきです。

ひとつ注意点があります。Substrateは現時点でアイドル状態を自動検出しません。一時停止は、Substrateがアクティビティを監視して自ら判断するのではなく、アクターをオーケストレーションしているシステムからの明示的なAPI呼び出しによってトリガーされます。

設定方法:WorkerPoolとActorTemplate

Substrateのリソースはate.dev/v1alpha1 APIグループ配下のKubernetes CRDなので、通常のGitOpsフローにそのまま組み込めます。主な作業を担うのは2つのリソースです。

WorkerPoolは物理的なキャパシティを定義します。待機させておくウォームPodの数、使用するサンドボックスランタイム、ノード配置ルールなどです。

apiVersion: ate.dev/v1alpha1
kind: WorkerPool
metadata:
  name: research-agent-pool
  namespace: ate-demo
spec:
  replicas: 10
  ateomImage: ko://github.com/agent-substrate/substrate/cmd/ateom-gvisor
  # sandboxClass defaults to gvisor; set to microvm for a Kata + Cloud
  # Hypervisor pool if your workload needs stronger isolation.

ActorTemplateはワークロードそのものを定義します。コンテナ、スナップショットの保存先、実行を許可するワーカープールなどです。

apiVersion: ate.dev/v1alpha1
kind: ActorTemplate
metadata:
  name: research-agent
  namespace: ate-demo
spec:
  pauseImage: "gcr.io/gke-release/pause@sha256:<digest>"
  containers:
  - name: agent
    image: registry.example.com/research-agent@sha256:<digest>
    readyz:
      httpGet:
        path: /readyz
        port: 8080
  sandboxClass: gvisor
  workerSelector:
    matchLabels:
      workload: research-agent
  snapshotsConfig:
    location: gs://my-bucket/snapshots/research-agent/

自分で書く前に知っておきたい細かい点がいくつかあります。コンテナイメージはダイジェストで固定する必要があります。イメージを変更すると既存のスナップショットが無効になるためです。readyzプローブは任意ですが、設定する価値があります。コールドブートと復元の両方を、ワークロードが単に起動しただけでなく、実際にトラフィックを処理できる状態になったことを条件にできるからです。また、エージェントの新しいバージョンごとに専用のActorTemplate(research-agent-v2など)を用意すべきです。Substrateはテンプレートを、その場で書き換えるものではなく、イミュータブルな状態のルートとして扱うためです。

テンプレートがReadyに達したら、CLIで論理的にアクターを作成します。

kubectl ate create atespace demo
kubectl ate create actor my-agent-1 -a demo --template=research-agent

すると、リクエストが到着した瞬間に、参照先プール内の空いている任意のワーカー上でアクターが再開されます。