AX（google/ax）とは｜Googleのエージェント実行基盤をv0.3.0の差分と実機で確かめる

AX（google/ax）は、エージェントのタスクをクラスタ上で大量に走らせるためのGoogle製オーケストレーターだ。Kubernetesを使ったことがあれば見慣れた形で、ax apply -f task.yaml と書いてサンドボックスを立ち上げる。2026年9月22日時点でstar 6.4k・fork 296、ライセンスはApache-2.0、最新タグは9月20日（JST）のv0.3.0。本記事ではリポジトリを全履歴でcloneし、v0.2.3とv0.3.0の差分を実際に取ったうえで、CLIをビルドして手元で動かした結果をまとめる。要約記事でよく見る「CRDからRedisへ移行」という説明が実体と食い違う点も、差分で確かめた。

エージェントを動かす枠組み全体の比較はAIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証にまとめている。

AX（google/ax）とは——4つの宣言でエージェントを動かす基盤

READMEの説明は率直だ。「エージェントは新種のワークロードで、ステートレスなマイクロサービスでも、走り切って終わるバッチジョブでもない。状態を溜め、厳格な隔離を必要とし、モデルAPIやツールサーバを呼び、誰も見ていなければループの中で金を燃やし続ける」。

AXはこれを4つの小さな部品で受け止める。

すべて ax.io/v1alpha1 のマニフェストとして書き、1コマンドで適用する。実行そのものはAgent Substrateという別プロジェクトに載っており、AXはその上で「どのタスクをどう並べるか」を受け持つ。

規模の主張には幅がある。READMEは「クラスタあたり数十億（billions）のタスク」と書き、DESIGN.mdは「数百万（millions）の短命タスク」を前提に設計理由を述べている。同じリポジトリの中で桁が3つ違うので、どちらかの数字を根拠に容量計画を立てるのは避けたほうがいい。

v0.3.0で何が変わったか——差分で確かめる

ここが本記事の主眼だ。v0.3.0について「タスク状態をKubernetesのCRD（つまりetcd）からRedis Streamsへ移した」という説明が流通しているが、リポジトリを全履歴でcloneして差分を取ると、実体は少し違う。

まずタグの日付と差分の規模を確認する。

git clone https://github.com/google/ax && cd ax
git log -1 --format='%ci %h' v0.3.0     # 2026-09-19 20:27:51 -0700 d8ed0fe
git log --oneline v0.2.3..v0.3.0        # 5 commits
git diff --stat v0.2.3..v0.3.0 | tail -1
# 150 files changed, 16203 insertions(+), 19451 deletions(-)

v0.2.3（2026-08-13）からv0.3.0までのコミットはわずか5本。そのうち再編の本体は dc4f36c Restructure AX into a general-purpose orchestration layer for agentic tasks の1本で、150ファイル・約1.6万行追加と1.9万行削除という規模だった。

次に中身を見る。cmd/ の構成と依存ライブラリを両タグで比べると、変化がはっきり出る。

git ls-tree --name-only v0.2.3 cmd/   # cmd/ax
git ls-tree --name-only v0.3.0 cmd/   # cmd/ax, ax-server, ax-controller, ax-task-runner
git show v0.2.3:go.mod | grep -iE 'pgx|redis'   # github.com/jackc/pgx/v5 v5.10.0
git show v0.3.0:go.mod | grep -iE 'pgx|redis'   # github.com/redis/go-redis/v9 v9.22.0

つまり移行元はKubernetesのCRDではなくPostgresだった。v0.2.3のツリーには internal/controller/eventlog/postgres.go と manifests/ax-postgres.yaml があり、CRDの定義ファイルは1つも無い。DESIGN.mdがCRDとetcdに言及しているのは、

数百万の短命タスクをKubernetesのCRDとして保存すると、etcdは快適な範囲を超える（1桁GBの保存上限、書き込みレートのボトルネック、コントロールプレーンの劣化）。

という「なぜCRDに置かないか」という設計理由の説明であって、CRDから移した記録ではない。要約を読んで「自分たちもCRDをやめてRedisにするべきか」と考えるなら、前提が1つずれていることになる。

再編後の役割分担はDESIGN.mdの表に明記されている。ax は開発者向けCLI、ax-server は8080番のステートレスなgRPC APIでマニフェストを検証してRedisへ永続化しイベントを発行、ax-controller はRedisのストリームを消費してAgent Substrate上にサンドボックスと実行主体を用意し外向きポリシーを適用する水平スケール可能なワーカー、ax-task-runner はタスクコンテナ内の入口でワークスペースを立ち上げメタデータを配信してエージェントのコマンドを走らせる。

実測：CLIをビルドして手元で動かす

ここからは2026年9月22日にLinux（x86_64・Kubernetesクラスタなし）で動かした結果だ。READMEのインストール手順は go install だが、差分を取るためにcloneしてあるのでソースからビルドした。

go build -o /tmp/ax-bin ./cmd/ax
/tmp/ax-bin version
# ax version v1alpha1 (standalone redis engine)

19.9MBの単一バイナリができた。バージョン文字列そのものに standalone redis engine と入っているのが目を引く。差分で確かめたRedisへの移行が、CLIの自己申告にも現れている形だ。

--help を見ると、コマンドの並びは意図的にkubectlに寄せてある。apply get describe watch delete に加えて、エージェント固有の動詞として ssh（動いているタスクの中でコマンドを実行）、suspend／resume（チェックポイントを取って一時停止・再開）、tunnel（クラスタへの背景トンネル管理）、ctx（接続先の確認）がある。

get の出力列もkubectl流に整えてある。READMEの例では、ゲートウェイが名前・atespace・待ち受け（8494/gRPC,8080/HTTP）・送信先許可（*）、ワークスペースがGitリポジトリ数とMCPサーバ数、モデルがプロバイダと具体的なモデル名（例では google と gemini-3.8-flash）を並べる。使用モデルが資源として独立しているので、どのタスクがどのモデルを使うかをマニフェスト側で切り替えられる。-a で別のatespaceを指定する形も、名前空間の扱いとして見慣れたものだ。

クラスタが無い状態で叩くと、どこで止まるかがはっきりする。

/tmp/ax-bin get tasks
# Error: listing tasks: rpc error: code = Unavailable desc = connection error:
#   desc = "transport: Error while dialing: dial tcp 127.0.0.1:8080: connect: connection refused"
/tmp/ax-bin ctx
# No active Kubernetes context detected.
# Fallback server: http://localhost:8080 (or set $AX_SERVER / --server)

CLIは単体で完結せず、8080番のgRPC APIを探しに行って失敗する。接続先は $AX_SERVER か --server で差し替えられるので、ポートフォワードやトンネル越しに使う運用が想定されている。

ビルド自体は素直だった。go.mod の指定に合わせてツールチェーンが解決され、追加の生成手順やサブモジュールは要らない。依存の取得を含めて数分で終わり、バイナリは1つだけ出る。エージェント基盤というと重装備を想像しがちだが、開発者が最初に触る部分に関しては敷居が低い。

公式の手順は3段階だ。go install github.com/google/ax/cmd/ax@latest でCLIを入れ、make deploy AX_IMAGE_REPO=<レジストリ> でRedisと制御プレーンを ax-system 名前空間へ配備し、ax apply -f examples/task.yaml で最初のタスクを流す。リポジトリには demo.sh も入っており、独自ワークスペースの適用から準備完了待ち、ax ssh 経由のコマンド実行、一時停止までを一通り通す構成になっている。ドキュメントは7本立てで、概念・マニフェスト・サンドボックス・ランナー・ネットワーク・アーキテクチャ・開発が分かれている。読む順番としては、まず概念でタスクの状態遷移を掴み、次にマニフェストで書き方を見て、サンドボックスでコンテナ内の前提を確認するのが素直だ。

タスクの一生と、サンドボックスの約束事

マニフェストを書く側から見ると、知っておくべきはタスクの状態遷移と、コンテナの中でエージェントが何に頼れるかの2点だ。どちらも docs/ に明文化されている。

状態は status.phase が一語で表し（Running・Suspended・Failed・Terminating など）、詳細は3つの条件が持つ。

遷移で押さえておくべきは2つ。タスクを一時停止すると Ready が理由 TaskSuspended でFalseになり、再開で戻る。削除すると Terminating へ移り、コントローラがサンドボックスを片付けてから記録ごと消える。ax delete はその完了までブロックするので、スクリプトから呼んでも後始末の途中で次へ進んでしまうことがない。

サンドボックスの中では、ax-task-runner がメタデータサーバを兼ねる。同じポートでHTTP/1.1と h2c を話し、エージェントはSDKなしで自分の設定を読める。/healthz は常に200、/readyz はワークスペース初期化中が503でクローンとMCP設定とスキルが揃うと200、/metadata/v1alpha1/ax/task が現在のTaskの仕様と状態をYAMLで返す。バインドされたWorkspaceは /metadata/v1alpha1/ax/workspaces からバインド順の複数ドキュメントとして取れる。

# タスクのコンテナ内から（未検証：クラスタが無いため実行していない）
curl -s "$AX_METADATA_URL/metadata/v1alpha1/ax/task"

この入口は差し替えられる。DESIGN.mdのコンポーネント表は ax-task-runner を「runner パッケージの薄いラッパーであり、独自イメージはそれを直接組み込める」と説明している。実際にv0.3.0の差分でも runner/runner.go（246行）と runner/runner_test.go（304行）が新設されていた。既定のイメージをそのまま使うか、自前のベースイメージにワークスペース初期化とメタデータ配信の契約だけを埋め込むかを選べる作りで、docs/runner.md が制御プレーンとタスクコンテナの間の取り決めを別立てで説明している。

ax ssh が使えるかどうかも、この層で決まっている。プロセス起動とファイル読み書きを許すゲストサービスは spec.debug: true のときだけ同じポートで開き、既定では閉じている。ドキュメントはその理由を「サンドボックス内での任意のプロセス実行とファイルアクセスを許すため」と明記し、有効化していないタスクには ax ssh が接続を拒否すると書いている。デバッグのために開ける穴が、明示的なフラグ1つに集約されている形だ。

同名OSSとの区別と、採用判断の目安

「ax」は名前が短い分だけ衝突する。検索する前に区別しておきたい。

用途がまったく違うので、「axを入れた」という説明だけでは何の話か決まらない。リポジトリ名で google/ax と明示するのが確実だ。

採用判断の軸は3つある。第一に規模。数個のエージェントを回すだけならKubernetesとAgent Substrateを前提にする構成は重い。AXが解こうとしているのは、短命タスクが大量に立っては消える環境で制御プレーンが先に音を上げる、という運用側の問題だ。第二に安定性の許容度。READMEが自ら破壊的変更を予告しており、v0.2.3からv0.3.0の実績がまさにそれだった。バージョンを固定し、移行の手間を織り込めるかが分かれ目になる。第三に隔離と通信制限を外に出したいか。Gateway で外向き通信を許可リストに絞る設計は、エージェントに任意のコードを書かせる運用では効く。

作業環境をどう持たせるかという論点は、AXの Workspace に限った話ではない。ログを正本に据えてローカル優先で作業空間を組むApache Maka（Incubating）とは｜ログを権威にするローカルファースト作業空間を実測と読み比べると、状態をどこに置くかで設計がどう変わるかが見える。エージェント基盤を小さく自前で組んだ例としてはAgentic Inboxとは｜Cloudflare Workersだけで動くAIエージェント付きメールクライアントをビルドして検証があり、AXが引き受けている範囲との差がはっきりする。

まとめ——AXは何を引き受ける器か

AXは、エージェントの賢さではなく「置き場所」を扱う。隔離・作業環境の事前配線・外向き通信の制限・モデル指定という、放っておくと各チームが独自に書く部分をマニフェストに寄せる。v0.3.0の再編で単一バイナリからCLIと3サービスに分かれ、状態はRedisへ移った。実測した範囲では、CLIは素直にビルドでき、接続先が無ければ素直に失敗する。

未検証のまま残したのは制御プレーンとタスク実行そのものだ。クラスタが無いため ax apply 以降は一度も通していない。手元で評価するなら、まずCLIをビルドして ax ctx で接続先の扱いを確認し、次に使い捨てのクラスタへ make deploy を流し、examples/task.yaml と demo.sh で一周させる順序が無駄がない。そのうえで、README の「数十億」とDESIGN.mdの「数百万」のどちらが自分の規模感に近いかを、自分の負荷で測り直すのが正しい読み方になる。

参照ソース

・google/ax（公式リポジトリ） — README・LICENSE・go.mod・タグ間差分（2026-09-22時点で確認）
・AX Design（DESIGN.md） — アーキテクチャ図とコンポーネント表、CRDとetcdに関する設計理由
・Agent Substrate — AXが実行基盤として載る別プロジェクト