AXは、クラスター上で自律型エージェントのワークロードを実行するための、オープンで宣言型のオーケストレーターです。わかりやすく言うと、エージェントを取り巻くインフラ、つまり分離されたランタイム、ツール、ネットワークアクセス、モデル設定を、Kubernetesリソースのように適用・管理できる再利用可能な仕様に変換します。
この記事では、AXをGoogle発のオープンプロジェクトとして紹介し、エージェントインフラを宣言型のクラスターリソースとしてまとめる仕組みを説明しています。
プロジェクトのウェブサイトと `google/ax` リポジトリでは、4つの中核オブジェクトが説明されています。Taskは、CPUとメモリの制限を課したサンドボックス内で信頼できないエージェントコードを実行します。Workspaceは、実行前にGitリポジトリ、Model Context Protocol（MCP）サーバー、スキルを準備します。Gatewayは、ホストとポートの許可リストを使って外部への通信を制御します。Modelは、モデルパラメーターとシークレットを一元的に管理します。したがって、1つのマニフェストで、Goリポジトリと、その準備済み環境内で実行すべきタスク目標の両方を宣言できます。
ワークフローは、Kubernetes利用者にとって意図的に馴染みやすいものになっています。YAMLを書き、 `ax apply` を実行し、 `ax watch` でステータスを確認し、 `ax ssh` でサンドボックスを調査します。エージェントがモデル、ツール、または人間の応答を待っているとき、AXはアクターをチェックポイントして一時停止し、コールドスタートなしで1秒未満で再開できるとしています。この効率化の考え方は、タスクがアイドル状態のときはワーカーリソースを共有し、エージェントが実際にコードを実行しているときだけコンピューティング資源を消費するというものです。
この可能性を実現するには、かなりの前提条件があります。クイックスタートの説明では、Kubernetesクラスター、 `ko` 、コンテナーレジストリ、到達可能なAgent SubstrateコントロールAPIが必要です。AXはサンドボックス化された実行のために、そのサブストレート上で動作します。リポジトリは、その概念、プロトコル、仕様はまだ洗練されている段階であり、安定版リリースの前に大幅に変更される可能性があると警告しています。10億タスクという表現は設計目標であり、実世界の処理能力を独立して検証したベンチマークや証明ではありません。
実務上の疑問は、AXの価値がサンドボックスそのものにあるのか、それを取り巻くコントロールプレーンにあるのかという点です。仮想マシンでも分離は実現できます。しかしAXは、寿命の短いエージェントや長時間実行されるエージェントの多くを、1つのインターフェースを通じて、観測可能で、ネットワークが制限され、チェックポイント化でき、再現可能な設定を持つものにしようとしています。この資料は、本番環境での成熟度、独立した性能結果、VMスナップショットとの比較でその取舍がどうなるかを示していません。したがって、妥当に導ける結論はより限定されます。AXは、エージェントインフラをクラスター規模で運用する準備がすでに整っているチーム向けに、一貫した運用モデルを提供します。