GoogleがOSS「AX」公開、AIエージェントの待機コストを激減へ

• GoogleがKubernetesライクな自律AIエージェント向け実行基盤「AX」をApache 2.0でオープンソース公開
• Agent Substrate上でTaskやWorkspaceなどの4つの宣言的プリミティブを定義し、サブ秒で状態の中断・再開が可能
• 推論待ちや人間介入によるコンテナのアイドル浪費を解消する一方、K8s運用の重厚さというトレードオフを突きつける

深夜2時、自律型AIエージェントのパイプライン監視画面を見つめながら、溜め息をついた経験はないだろうか。画面上では数十個のDockerコンテナが立ち並び、潤沢に割り振られたCPUとメモリを占有し続けている。だが、その実態は外部LLM APIからのストリーミングレスポンスを待っているか、あるいは人間の承認待ち（Human-in-the-Loop）で完全にフリーズしている状態だ。計算資源を全く使っていないにもかかわらず、クラウドインフラの課金メーターだけが無慈悲に回り続ける。従来のステートレスなマイクロサービスや、 deterministicに完了まで走り抜けるバッチジョブを前提に設計されたKubernetesにとって、この「極端にバーストし、長時間にわたって待機する」ステートフルなAIエージェントは、最も相性の悪いワークロードの一つだった。

このインフラエンジニア共通の悪夢に終止符を打つべく、GoogleとGoogle DeepMindのシステム研究チームが投入したのが、オープンソースのオーケストレータ「AX（Agent Executor）」である。Apache 2.0ライセンスで公開され、agentexecutor.ioおよびGitHub上のgoogle/axリポジトリからアクセス可能なこのランタイムは、エージェントを単なるPodやコンテナではなく「ステートフル・アクター」として再定義する。最大の特徴は、推論プロバイダの応答待ちやツール呼び出しの待機に入った瞬間、エージェントの実行状態をチェックポイントとして保存し、ミリ秒単位でプロセスをサスペンド（一時停止）させる点にある。ホストのリソースを即座に解放し、イベント発生時にはサブ秒（1秒未満）の極小レイテンシでコールドスタートなしに実行を再開するのだ。1台のワーカーノード上に何十ものタスクを高密度に多重化（Dense Actor Multiplexing）できるこのアーキテクチャは、エージェント基盤のコスト構造を根底から覆す可能性を秘めていると私は確信している。

AXがプラットフォームエンジニアの心を掴むのは、その徹底したKubernetesスタイルの宣言的設計にある。ax.io/v1alpha1 APIグループの下で定義されるコントロールプレーンは、主に4つのプリミティブによって構成されている。開発者がシェルスクリプトで無理やり繋ぎ合わせていたワークスペースの初期化、外部ネットワーク制限、LLMプロバイダの秘密情報管理を、すべて堅牢なCRD（Custom Resource Definition）の世界へと引きずり込んだのだ。

特に私が刮目したのは「Workspace」と「Gateway」の設計だ。Workspaceでは、話題のModel Context Protocol（MCP）サーバの設定やGitリポジトリの展開を宣言的に行えるだけでなく、初期化エージェントに対して「このタスクに必要なツールチェーンを準備せよ」と自然言語で指示を与え、ブートストラップを自動化することすら可能にしている。また、Gatewayはサンドボックス化されたエージェントのアウトバウンド通信をホスト名やポートの許可リストで厳格に縛り、プロンプトインジェクション等による情報流出の爆発半径（Blast Radius）を最小限に食い止める。gVisorによるサンドボックス分離技術と組み合わさることで、危険なコード評価を伴う自律エージェントを本番環境で稼働させるための現実的なセキュリティ境界がようやく形作られたといえる。

Go言語で書かれた`ax` CLIツールを用い、`ax apply`でマニフェストを登録し、`ax watch`でフェーズ遷移を監視、障害時には`ax ssh`で即座に隔離コンテナへダイブしてデバッグを行う。さらに`ax suspend`や`ax resume`による手動制御まで網羅された設計は、インフラエンジニアの目には極めて整然とした美しいシステムに映る。デプロイパイプラインも`ko`とRedisを用い、既存のKubernetesクラスタの`ax-system`名前空間へ素直に流し込める。しかし、このアーキテクチャが技術コミュニティ、特にHacker NewsやRedditで激しい議論を巻き起こしている現実から目を背けるわけにはいかない。

コミュニティが真っ向から対立している最大の争点は、「本当にこのワークフローはエルゴノミック（人間工学的）なのか」という点だ。インフラエンジニアがクラウド請求額の削減効果を絶賛する一方で、アプリケーション開発者からは「コンテナレジストリを用意し、重厚なK8sクラスタを維持管理し、CRDの面倒まで見るのはオーバーヘッドが大きすぎる」という悲鳴が上がっている。ここで極めて重要なのは、AXがLangGraphやCrewAIのような「LLM推論ロジックを組む高レベルのアプリケーションオーケストレータ」ではなく、あくまで最下層でプロセスを動かす「コンピュート実行基盤」であるという事実だ。さらに初期リリース特有の課題として、エグレスプロキシのコネクション切断やシークレット管理の粗さといった未成熟な挙動も報告されている。個人開発者が手元で数行のPythonコードを動かすためのツールではなく、数千単位のエージェントフリートを安全に運用しなければならないエンタープライズのための基盤なのだ。

Googleが「k8s-aibom」によるクラスタ内の野良AI棚卸しツールを公開した動きや、マイクロサービスとモノリスの境界を再定義した「Service Weaver」の系譜を見れば明らかなように、彼らはクラウドネイティブ環境におけるAIネイティブな基盤の標準化を一気に狙いに来ている。従来のステートレスなWebアーキテクチャを無理やり流用したエージェントシステムが、性能面でもコスト面でも早晩行き詰まることは誰の目にも明らかだった。AXはその閉塞感を打ち破る確かな技術的回答を提示している。だが、我々現場のエンジニアは自らに問い直さなければならない。我々の組織は、単一障害点になりかねないKubernetesの運用複雑性を受け入れてまで、ミリ秒の中断・再開アーキテクチャを今すぐ本番投入する準備ができているだろうか。

明日から我々が取るべき実践的なアプローチは明確だ。まずは手元の検証クラスタに`ko`を用いてAXのコントロールプレーンを展開し、現在運用しているエージェントパイプラインのうち、最も推論待機時間が長くコストを垂れ流しているタスクを1つ選んで`Task`および`Workspace`マニフェストへ落とし込んでみることだ。その際、MCPサーバ連携の接続安定性とGatewayによるアウトバウンド制御の挙動を徹底的に検証し、インフラ運用のコスト増とコンピュート削減効果の損益分岐点を冷徹に見極める必要がある。AIエージェントの乱立期から運用最適化期へとフェーズが移り変わる今、実行基盤の抽象化レイヤを自前で泥臭くパッチワークし続けるのか、それともAXのような宣言的アクターモデルに命運を預けるのか。その決断の猶予は、我々にはもう残されていない。