AX

AX は Google が公開したオープンソースの宣言型オーケストレーターで、エージェントのワークロードをクラスタ規模で実行するために作られています。前提にあるのは「エージェントはチャットセッションでもマイクロサービスでもない」という見方です。状態を蓄積し、厳密な分離を必要とし、モデル API やツールサーバーを呼び出し、誰も見ていなければループの中で費用を燃やし続ける。AX はそのために YAML マニフェストと、意図的に kubectl の形をした CLI を用意しています。

すべては ax.io/v1alpha1 リソースで、1 つのコマンドで apply できます。プロジェクトが掲げる目標は 1 クラスタあたり数十億タスクの実行です。サンドボックス実行は別プロジェクトの Apache-2.0 ランタイム Agent Substrate に委譲されています。

主な機能

4 つのプリミティブ：Task は CPU とメモリ上限付きの分離サンドボックスで、作成・一時停止・破棄が安価です。Workspace はタスク開始前に Git リポジトリ、MCP サーバー、スキルパッケージを用意します。Gateway はホストとポートの許可リストとしてネットワークポリシーを表現し、外向きリクエストに資格情報を注入します。Model はモデル・パラメータ・シークレットを 1 つのオブジェクトにまとめ、キーのローテーションやバージョン固定が 1 回の apply で済みます。
kubectl 風の CLI：ax apply、get、describe、watch、delete に加えてエージェント固有の動詞があります。ax ssh task -- ls -la /workspace で実行中サンドボックスに入れ、ax suspend / ax resume でチェックポイントして続きから再開できます。
kube context に追従：現在のコンテキストに応じてコントロールプレーンを解決しトンネルするため、kubectx prod-cluster && ax get tasks が追加設定なしで動きます。
交換可能な Runner：コントロールプレーンとタスクコンテナの契約が文書化されており、既定の runner イメージを自作のものに置き換えられます。
宣言的な状態：ax get task <id> は spec とライブ状態を YAML で返し、ax watch はフェーズと条件の遷移をストリーム表示します。

ユースケース

プラットフォームチーム：エージェントが生成したコードを、開発者のノート PC ではなく厳密な分離・予算上限・監査証跡つきで実行したい場合。
バッチ的なエージェント作業：コード移行、テスト修復、データ抽出、評価など、長い 1 セッションではなく数百の独立サンドボックスが必要な場合。
長時間動くエージェント：ステップの合間に止めたい場合。suspend / resume はワークスペースを失わずにリソース消費を止めます。
ネットワーク制限のある環境：エージェントが明示的な許可リストのホストとポートにしか到達できないようにしたい場合。

料金

AX 自体は Apache License 2.0 のオープンソースで無料です。実費は自前の Kubernetes クラスタ、コンテナレジストリ、そしてエージェントが実行するモデル API 呼び出しで、資格情報は Model リソースに集約します。2026-09-25 時点で公式サイトにホスト版の AX はありません。

クイックスタート

CLI をインストール：go install github.com/google/ax/cmd/ax@latest。
コントロールプレーンをデプロイ：make deploy AX_IMAGE_REPO=<your-registry>。Kubernetes クラスタ、ko、クラスタが取得できるレジストリが必要で、コンポーネントは ax-system ネームスペースに入ります。
タスクを投入して観察：

ax apply -f task.yaml
ax watch task test
ax ssh test -- ls -la /workspace

リポジトリには ./demo.sh があり、workspace の適用、ready 待ち、ax ssh でのコマンド実行、タスクの suspend まで一連の流れを確認できます。

制限とリスク

1.0 未満で、公式に不安定と明記：README はコア概念・プロトコル・仕様が流動的で、安定版までに大きな破壊的変更が入り得ると警告しています。2026-09-25 時点の最新タグは 2026-09-20 の v0.3.0 で、オープン issue は 38 件でした。
単一エージェントには重い：最初のタスクまでに Kubernetes クラスタ、ko、レジストリが必要です。
ホスト型コントロールプレーンは無い：AX は自分で運用するインフラであり、アップグレード、Redis 依存、クラスタのセキュリティは利用者の責任です。
ドキュメントはリポジトリ内：整った製品マニュアルではなく concepts / manifests ガイドを読む前提です。

よくある質問

AX はモデルですか、エージェントフレームワークですか？

どちらでもありません。エージェントワークロード向けのスケジューラ兼コントロールプレーンです。エージェント、モデル、ツールは利用者が用意し、AX はそれらをどこでどう分離して動かすかを決めます。

どのモデルを使えますか？

Model リソースはプロバイダー単位で設計されています。リポジトリのマニフェストは Gemini を既定にしており、クラスタから到達できるプロバイダーであれば Kubernetes Secret の資格情報で設定できます。

LangGraph や CrewAI との違いは？

それらは 1 つのエージェントのロジックの流れを記述するフレームワークです。AX は多数のエージェントがどう動くか（スケジューリング、分離、ネットワークポリシー、ライフサイクル）を記述します。補完関係にあり、AX のタスクは LangGraph や CrewAI のアプリを起動するコマンドでも構いません。

Kubernetes の経験は必要ですか？

実務上は必要です。CLI は kubectl 利用者に馴染むよう設計され、kubectx との相互運用も一級機能です。

代替手段

LangGraph：クラスタスケジューリングではなくエージェントのロジックが主題のときのグラフ型オーケストレーション。
Google ADK：AX がスケジュールするエージェントを構築するための Google の開発キット。
E2B と Daytona：コントロールプレーンを自前で運用せずに分離実行を得たい場合のホスト型サンドボックス API。
Strands Harness：エージェントループ自体を担う harness SDK。

まとめ

AX が答えているのは、最初のエージェントデモが動いた後にほとんどのチームが直面するインフラの問いです。何千ものエージェントを、分離され、監査可能で、コストの読める形で動かすにはどうするか。Google の賭けは、YAML と Kubernetes の習慣が専用ランタイムに勝つというものです。プロジェクトは若く、不安定であることを公言しているため、いまは試作に使い、仕様が固まってから本番導入を評価するのが妥当です。

まずは AX 公式ドキュメントとリポジトリの concepts ガイドから読むと全体像がつかめます。