ブログ

エージェントを大規模に動かすための基盤：AX (Agent Executor) の基本コンセプト

2026年9月26日 H.Ueda

Googleが公開している Declare an agentic task.AX runs it at scale. という記事を読み、AIエージェントを実運用するためのインフラ構成が非常に具体的で参考になったので、こちらで内容を整理してみたいと思います。

Googleの新しい基盤の様です。参考まで。

最近、AIエージェントを自作して動かしてみる機会が増えてきましたが、いざ「本番環境で大規模に動かそう」とすると、実行環境の分離やリソース管理、コストの抑制など、意外と考えるべきことが多いなと感じています。AXは、こうした「エージェント特有のワークロード」を効率よく管理するためのランタイムです。

エージェントは「新しい種類のワークロード」である

これまで私たちが扱ってきたシステムは、大きく分けると「リクエストに対して即座に応答するマイクロサービス」か、あるいは「決まった処理を順次こなすバッチジョブ」のどちらかでした。

しかし、AIエージェントはそのどちらとも少し性質が異なります。AXの考え方では、エージェント特有の課題を以下のように捉えています。

特徴 内容
状態の蓄積 実行プロセスの中で、メモリやファイルといった「状態」が積み重なっていく。
厳格な隔離 エージェントが生成したコードやツールを実行するため、安全なサンドボックスが必要。
外部依存性 モデルAPIやツール用のサーバー（MCPなど）を頻繁に呼び出す。
コストのリスク 適切な監視がないと、無限ループに陥ってAPIコストを浪費し続ける可能性がある。

こうした「マイクロサービスでもバッチでもない」性質を持つエージェントを、宣言的に（「こうあるべき」という定義を書くだけで）管理しようとするのが、AXというツールの面白いところです。

AXを構成する4つのプリミティブ

AXでは、エージェントの実行環境を構成するために4つの基本的な要素（プリミティブ）を提供しています。

1. タスク (Task)

エージェントが実行する最小単位です。CPUやメモリの制限がかけられたサンドボックス内で動きます。作成や一時停止、破棄が低コストで行えるため、必要なときにサッと作って終わったら消す、という使い方がしやすいかと思います。

2. ワークスペース (Workspace)

エージェントが作業する「机」のようなイメージです。GitリポジトリやMCP（Model Context Protocol）サーバー、特定のスキルセットなどを定義しておくと、タスクが始まる前にAXがそれらを自動でセットアップしてくれます。

3. ゲートウェイ (Gateway)

ネットワークの交通整理役です。特定のホストやポートだけに通信を制限する「許可リスト」の管理や、リクエストを送る際の認証情報の注入などを一括で担います。

4. モデル (Model)

LLM（大規模言語モデル）の接続設定を一元化します。モデルの種類やパラメータ、APIキーなどのシークレットを1箇所で管理できるため、モデルのバージョンを上げたりキーを更新したりする際も、定義ファイルを1回書き換えるだけで済みます。

処理の流れを可視化してみる

AXがどのようにエージェントを立ち上げるのか、そのイメージをMermaid図にしてみました。

flowchart TD
    subgraph "定義 (YAML)"
        A["Task<br>(実行内容)"]
        B["Workspace<br>(環境・ツール)"]
        C["Model<br>(LLM設定)"]
    end

    D["AX Controller"]

    subgraph "実行環境 (Sandbox)"
        E["Isolator<br>(CPU/メモリ制限)"]
        F["Agent Actor"]
        G["Network Gateway<br>(通信制限)"]
    end

    A & B & C --> D
    D --> E
    E --> F
    F --> G
    G --> H["External APIs / Tools"]

定義ファイルを投げると、AXが裏側で安全なサンドボックスを用意し、ネットワーク制限をかけた状態でエージェントを動かし始める、という流れですね。

実際の操作感（CLIの例）

操作感は、Kubernetesを使っている方なら馴染みやすいかもしれません。たとえば、Go言語のツールチェーンを確認するタスクを定義する場合、以下のようなYAMLファイルを用意します。

apiVersion: ax.io/v1alpha1
kind: Workspace
metadata:
  name: golang
spec:
  git:
    - repo: https://github.com/golang/go.git
      branch: "my-fix"
---
apiVersion: ax.io/v1alpha1
kind: Task
metadata:
  name: test
spec:
  workspaces:
    - name: golang
      goal: "Goツールチェーンがビルドされていることを確認する"

これを ax apply -f task.yaml で実行します。実際にタスクが動き出すと、ax ssh コマンドで実行中のサンドボックスに入って中身を覗くこともできます。

面白いのは suspend（一時停止）と resume（再開）ができる点です。たとえば、エージェントが途中で迷っているときに一旦止めて、状態を保持したまま後で再開する、といったコントロールが可能です。

数十億のタスクを支える仕組み

AXがなぜ大規模（スケール）を強調しているのかというと、その基盤に Agent Substrate というコンピューティングランタイムを採用しているからだそうです。

これは、非常に多くのアクター（エージェントの実行主体）を、高密度かつ高速に処理するためにゼロから設計されているとのこと。1クラスターで数十億ものタスク実行を支援するという辺りに、将来的な「エージェントが当たり前に大量稼働する世界」を見据えた意図が感じられます。

まとめ

これまでは、エージェントを動かすための「ロジック」の部分に注目が集まることが多かったですが、実際に運用フェーズに入ると、こうした「安全でスケーラブルな実行基盤」が欠かせなくなるはずです。

AXのように、タスクやワークスペースを宣言的に定義できるツールが出てくることで、エージェントの開発はより「何をさせるか」という本質的な部分に集中できるようになっていくのかもしれません。

まずは自分の手元で、小さなタスクをいくつか定義して試してみるのが良さそうですね。

参照記事

« 記事一覧へ戻る