GoogleがAX公開 エージェント大量実行基盤

Googleがエージェント作業負荷向けの宣言型実行基盤「AX」を公開した。 GitHub Trendingのgoogleによる公開情報では、作業領域と接続制御の仕様を宣言し、隔離実行と大規模運用を担う仕組みとして説明されている。 公開日は2026-09-24である。 現時点では中核概念や通信手順、仕様の精緻化が続いている。 安定版の前に大きな破壊的変更が入る可能性が明示されている。

AXの位置付けは、高処理能力の宣言型オーケストレータである。 1つの集合装置群で数十億件の自律型エージェント作業負荷の実行を想定する。 実行層にはAgent Substrateを用いる。 隔離実行の仕組みの上に制御面を載せる構成だ。 Kubernetesの利用経験があれば操作感覚をつかみやすいとされている。

Declare an agentic task with workspaces and gateway specifications. AX sandboxes it, wires up its workspace, fences its network, and helps running it at scale.

上記は公開貯蔵庫における定義文の引用である。 作業の宣言と作業領域の結合、通信網の遮断、大規模実行の支援を一連の機能として示す。 単一の命令で適用する宣言型の運用が核にある。

Kubernetes流の宣言型実行基盤

AXの操作はax.io/v1alpha1の宣言書で記述する。 種類としてTaskやWorkspace、Gateway、Modelを用いる。 単一の文書に複数種別を連ねて適用する。 命令はKubernetesのkubectlに近い。 applyやget、watch、suspend、resume、sshが用意される。

例示されたtask.yamlでは、golangという名のWorkspaceを定義する。 Git貯蔵庫としてgolang/go.gitを指定する。 分岐名も宣言書に含める。 Task側では作業領ドメインと目標文を指定する。 目標文には道具連鎖の可用性確保と源泉からの構築が記される。 debugを真にすればsshによる内部確認が可能になる。

適用後の流れも宣言型基盤に沿う。 ax apply -f task.yamlで適用する。 ax get tasksで状態を一覧する。 ax watch task testで段階と条件の変化を追う。 ax ssh testで隔離域内の作業領域を直接確認する。 GitHub Trendingのgoogleの記載では、実行中の主体や作業者網番地、経過時間の表示が例示されている。

この方式は再現性の確保に直結する。 Gitや模型、接続先の指定を文書に残せる。 同一文書の再適用で同条件の起動を狙える。 Google、クラウド好調でAI投資の成果を証明が示す基盤需要の拡大と並行し、実行環境の定型化が進むと見る向きもある。 AXはその定型化をエージェント領域に持ち込む試みである。

隔離実行と外部接続制御の仕組み

エージェントは従来の微細役務とも一括処理とも性質が異なる。 状態を蓄積し、厳格な分離を要する。 模型APIや道具鯖への外部呼び出しを伴う。 監視なき反復で費用が膨らむ危険がある。 AXはこの性質を前提に設計されている。

Taskは信頼できないエージェント符号を分離域で動かす単位だ。 CPUや記憶容量の上限を設定できる。 WorkspaceはGit貯蔵庫やMCP鯖、技能包を事前に結線する。 毎回の起動を温かい状態から始める狙いがある。 Gatewayは外向き通信を明示の主機許可一覧に絞る。 Modelは基盤自体が用いる言語模型を指定する。 資格情報はKubernetesの秘匿に置く。

この四つの小規模な基本要素が運用の骨格になる。 符号の分離と起動条件の固定を分けて記述できる。 外部接続の範囲を文書で監査できる。 模型の差し替えも宣言書の変更で追跡できる。 ClaudeチャットがGoogle検索に露出が示したように、模型出力の外部流通には管理の目が要る。 AXの接続制御はその管理を基盤側で支える構造だ。

技能包やMCP鯖の事前結合は起動時間の短縮に寄与する。 毎回取得する方式では遅延と失敗が増える。 温かい起動は大規模反復に有効である。 許可一覧方式は既定拒否の姿勢に近い。 必要最小限の外部接続だけを通す。 費用と情報漏えいの両面で遮断が意味を持つ。

タスク中断と内部覗き見の操作機能

AXは実行中の作業への介入手段を備える。 ax suspendは待機中のエージェントを休止させる。 検査点を作り処理を止める。 ax resumeは中断箇所から正確に再開させる。 長時間作業の費用制御に直結する。

ax sshは稼働中の分離域に入る手段だ。 ls -al /workspaceのような命令で内部を確かめる。 作業領域の実体や生成物の有無を直接見る。 watchは段階遷移を生で流す。 getは全体の状態把握に使う。 肩越しに挙動を見守る運用を想定する。

この操作体系は試行錯誤の多い開発と相性が良い。 宣言書の修正と再適用を繰り返せる。 内部確認で失敗原因を切り分けられる。 中断と再開で無駄な再計算を抑えられる。 自律動作の暴走時に人が割って入る余地がある。 費用上限と並ぶ安全弁として機能する。

公開情報ではexamples/task.yamlにTaskやWorkspace、Gateway、Modelを一括収容する例が示される。 単一文書で依存関係を閉じられる。 検証から本番への持ち運びが容易になる。 Google Maps通勤最適化、実用的な隠し機能3選のような利用者向け機能とは層が異なる。 AXは開発者と運用者のための制御層である。

数十億規模実行を見据えた設計思想

AXは集合装置群あたり数十億件の作業を掲げる。 高処理能力と宣言型の両立を狙う。 制御面はax-systemという名の名前空間に置く。 Redisを先に設定する。 koで制御面の像を構築し設定する。

導入にはKubernetesの集合装置群が要る。 koやコンテナ登録所も前提になる。 Agent Substrateの制御APIへ到達できることが条件だ。 集合装置内既定ではapi.ate-system.svc.cluster.local:443を用いる。 make deploy AX_IMAGE_REPOに登録所を指定して設定する。 CLIはgo install github.com/google/ax/cmd/ax@latestで導入する。 GOPATH配下のbinにax二値が置かれる。 当該経路を通す必要がある。

大規模化の鍵は状態管理と隔離の分離にある。 Agent Substrateが隔離実行を担う。 AXが宣言や設定、監視を担う。 Redisが制御状態の保持に用いられる。 宣言書中心の運用でAPI呼び出しを抑える。 監視命令も状態変化の購読に寄せる。

破壊的変更の予告は利用範囲を限定する。 現段階は仕様検証の時期にある。 概念や通信手順の改訂が続く。 本番直結の採用には注意が要る。 検証環境や研究用途での試用が中心になると評価できる。 それでも宣言型の枠組み自体は継続する可能性が高い。 Kubernetes流の操作は学習費用を抑える。

編集部の見解

短期的には、Kubernetes運用の知見を持つ組織での試行が増すと見る。宣言書管理や継続的結合との親和性が高く、検証環境の構築障壁は低い。破壊的変更の予告があるため、本番採用は限定的になると評価する。

長期では、エージェント実行の分離と外部接続制御が基盤の既定になると見る。作業領域や接続先の宣言が監査や費用管理の土台になる。運用実績が集まれば、仕様の安定化が進むと言えそうだ。

残る論点は、数十億規模の主張を裏付ける実測と費用制御の実効性である。停止や再開が状態の一貫性をどこまで保つのかは未検証である。外部接続の許可一覧が実務の速度を損なわないかも問われている。

参考

• 「google / ax」, by google — GitHub Trending, 2026-09-24 (ARR)
• 元記事URL: https://github.com/google/ax