AIエージェントを動かすための基盤「AX」が公開された。これは、エージェント向けのタスクをYAMLで宣言すると、実行環境の準備、ネットワーク制御、再開、停止、削除までをまとめて扱えるようにする仕組みだ。単なる実験用のデモではなく、大量のエージェントを同時に回す前提で設計されている点が目を引く。生成AIの話題はモデルそのものに寄りがちだが、実際に現場で効いてくるのは、その周囲の実行基盤であることを改めて思い出させる発表でもある。
AX のサイトでは、まず task.yaml を書き、ax apply -f task.yaml で実行対象を作る流れが示されている。例では、Workspace に Go のリポジトリとして https://github.com/golang/go.git を指定し、branch: "my-fix" を使っている。その上で Task を定義し、goal には「Go tool chain がソースからビルドされることを保証する」と書く。debug: true も付いていた。
実行すると workspace.ax.io/golang created、task.ax.io/test created と表示され、ax watch task test で状態を追える。最初は Pending だったタスクが、数秒後に Running へ移る。ax get tasks では、名前、namespace、phase、actor、worker IP、経過時間が一覧で見える。さらに ax ssh test -- ls /workspace で作業領域を覗くと go ディレクトリがあり、go build ./... も実行できる。ps -o pid,cmd を見ると、/usr/local/bin/ax-task-runner が PID 1 として動き、その下で go build ./... が走っている。つまり AX は、タスクごとに隔離された環境を作り、その中でコードを動かし、途中で中身を確認できるようにしている。
しかも終わりではない。touch notes.txt でファイルを置いたあと、ax suspend task test で停止し、ax resume task test で再開すると、その notes.txt は残ったまま見える。最後には ax delete task test で削除できる。AX の説明文は、こうした使い方を「agentic task を宣言すると、AX が sandbox 化し、workspace をつなぎ、network を囲い込み、必要なら cluster あたり billions の規模で回せる」と表現している。
機能の説明は四つのプリミティブに整理されている。Task は CPU と memory 制限付きの isolated execution で、信用できない agent code を sandbox で回す。Workspace は Git repo や MCP servers、skills、あるいは自然言語の目標から環境を用意する。Gateway は network policy を管理し、許可した host と port だけ通し、credentials も注入する。Model は models、parameters、secrets を一箇所にまとめ、key のローテーションや model version の固定を一度の apply で行える。AX はこの四つで、エージェント運用に必要な最低限を宣言的にまとめた、と主張している。
ここで一番重要なのは、AX がモデルAPIの話ではなく、エージェントの実行形態そのものに焦点を当てていることだと思う。サイトは、エージェントを microservices や batch jobs と同列には置けないと言い切っている。状態を持ち、外部ツールを呼び、待ち時間が長く、しかも人の確認待ちにもなる。これ、かなり現実的な描写だ。LLM を使うアプリは、計算そのものより「待つ」時間のほうが長いことがある。そこで普通のオーケストレーターをそのまま当てると、idle な sandbox を抱えたままコストが膨らむ。AX の問題設定はそこにある。
ただし、ここで少し引っかかるのは、「billions of tasks per cluster」という派手な表現が先に立ちやすいことだ。もちろん技術的には夢があるが、実務で重要なのはそこではなく、何をどこまで自動化できるかだと思う。たとえば研究用途では、同じ条件の sandbox を大量に作って軌跡を集める用途がある。一方、企業の開発現場では、そこまでの規模よりも、壊れにくさ、監査しやすさ、再現性のほうが大事になりやすい。AX はその両方を狙っているように見えるが、実際にどちらへ強く寄るのかで評価は変わるはずだ。
AX が少し変わっているのは、単に YAML で宣言するだけでなく、workspace の定義そのものを自然言語で書ける点だ。例では「Set up a Python 3 development environment」という goal だけを与え、最初の起動時に agent が toolchain を入れ、依存関係を確認する、と説明している。これは便利そうに見えるし、実際にかなり便利だろう。ただ、便利さの代償もありそうだと思う。
というのも、環境構築が自然言語に寄ると、何が最終的な構成だったのかが曖昧になりやすい。再現性が命の研究や検証では、あとから同じ環境を作れることが大事だ。AX は declarative control plane を名乗っているので、その曖昧さを YAML や workspace 定義でどこまで固定できるかが肝になる。もし「いい感じに作る」だけなら、デモでは強く見えても、本番の運用では怖い。逆に、生成された環境をログや設定としてきちんと残せるなら、これはかなり強い。エージェントに環境構築を任せつつ、人間が後から追える、という設計になっているかどうかが評価の分かれ目だろう。
AI 開発の主戦場はしばらくモデル競争だったが、最近はその周辺に重心が移っている。推論コスト、tool use、agent orchestration、sandbox、secret management、network policy。要するに、モデルを賢くするだけでは足りず、動かし方を整える必要がある。AX はそのど真ん中を狙っていて、しかも Google DeepMind 系の research と大規模運用の経験を背景にしているのが強い。発表文も、研究から生まれたが production を想定していると繰り返している。
一方で、この手の基盤は「何でもできる」と言うほど難しくなる。Task、Workspace、Gateway、Model の四つに分けているのは見通しがよいが、実際に使う側からすると、権限設計や失敗時の挙動、コストの見え方、既存の Kubernetes や CI/CD とどう共存するかが気になる。AX が本当に刺さるのは、研究者が実験を回すときと、開発者が長寿命の agent server を運用するときの中間領域ではないかと思う。つまり、「エージェントを試したい」から「エージェントを継続運用したい」に移る瞬間だ。そこで基盤が足りなくなるからだ。
AX の面白さは、AI をさらに賢くする話ではなく、AI を安心して回すための土台を作ろうとしている点にある。派手さは地味だが、実際にはこちらのほうが導入効果が大きい場面は多いはずだ。エージェントが一般化するほど、必要になるのは新しいモデルよりも、壊れても戻せる実行環境、権限を絞れるネットワーク、状態を保ちながら止めて戻せる仕組みになる。AX はその需要をかなり正面から捉えている。
とはいえ、ここから本当に重要なのは製品の完成度だ。宣言的に書けることより、失敗したときに何が残るか、監査できるか、ロックインがどれほど強いかのほうが、現場ではずっと効く。私は AX を、単なるエージェント実行基盤ではなく、AI ワークロードが次の段階に入ったことを示すサインとして見ている。モデルの能力を競う段階から、モデルをどこでどう動かすかを競う段階へ。AX はその変化をわかりやすく表に出したプロダクトだと思う。
参考: AX
