AI
Google AX 使い方ガイド｜導入条件、
Google AX 使い方の要点を、AIエージェント実行基盤としての役割から非技術者向けに解説します。Agent SubstrateやKubernetesとの関係、向いている業務、導入条件、検証手順、本番採用前に確認すべき制約をまとめました。
はじめに
AIエージェントの試作に成功しても、そのまま業務へ展開できるとは限りません。 利用部門が増えると、担当者はモデルの性能だけでなく、実行環境や権限も管理する必要があるからです。
業務へ展開する際は、途中で止まった仕事の再開方法、認証情報の保管場所、想定外の操作を止める担当者を決める必要があります。
こうした実行管理を担う基盤が、Google AXです。 Google AXは、長時間動くAIエージェントを隔離環境で実行し、担当者が停止、再開、状態を確認するためのオープンソース基盤です。 複数のエージェントを継続運用したい組織にとって、導入候補となります。
ただし、現時点で採用するには、Kubernetesを扱える技術体制と小規模な事前検証が必要です。 Google AXの使い方を検討する事業責任者は、機能の数だけでなく、導入によって変わる業務と自社が検証へ進める状態にあるかを確認します。
Google AXとは、
Google AXが担うのは、AIエージェントに仕事を渡し、隔離環境で実行しながら状態を管理することです。 正式名称をAgent Executorといい、チャット画面やAIモデルではなく、エージェントを継続して動かすためのAIエージェント実行基盤に当たります。
Googleは2026年5月、Agent Executorを、実行、再開、分散配置に対応するオープンソースのランタイムとして発表しました。 Google Cloud公式ブログのAgent Executor発表↗では、長時間の処理を再開する仕組み、隔離された実行環境、接続回復を説明しています。
ただし、エージェントの実行に必要な機能を、AXだけですべて担うわけではありません。 AXとAgent Substrate、Kubernetesが次のように役割を分担します。
| 層 | 担う仕事 | 事業側が得られるもの |
|---|---|---|
| AX | タスクの定義、投入、監視、停止、再開 | 実行方法を標準化し、状況を追いやすくする |
| Agent Substrate | エージェントの状態保存と隔離実行 | 待機中の資源消費を抑え、作業状態を保ちやすくする |
| Kubernetes | コンテナ、計算資源、ネットワークの管理 | 既存の運用技術を生かせる一方、専門人材が必要になる |
また、AXはエージェントの回答精度を高める製品ではありません。 担当者がエージェントの仕事を同じ条件で繰り返し、実行状況を管理するための基盤です。
Google AXで
Google AXを使うと、担当者はエージェントの作業場所、モデル、実行内容を設定ファイルで定義し、共通の操作で監視できます。 担当者の端末で個別に動かす場合と比べて、組織として実行条件や進捗を管理しやすくなります。
公式READMEによると、AXは次の三つの単位を使います。
- Task：実行する仕事
- Workspace：リポジトリや外部ツールを含む作業環境
- Model：利用するAIモデルと認証情報の設定
担当者は実行後の状態を監視し、一時停止、再開、隔離環境への接続を行えます。 導入方法と現在の仕様は、一次資料である公式READMEで確認できます。
導入によって想定される業務上の変化は、次のとおりです。
- 作業の再現性：担当者が同じ環境を用意しやすくなり、交代時の引き継ぎ負担を減らせる
- 障害対応：担当者が実行状態を確認し、長時間の仕事を停止または再開できるため、最初からやり直す場面を減らせる
- 統制：管理者がエージェントごとに環境や権限を分け、業務データへ接続できる範囲を管理しやすくなる
- 費用管理：管理者が待機中のエージェントを休止すれば、常時稼働より計算資源を抑えられる可能性がある
ただし、休止機能を使えば必ず費用が下がるわけではありません。 削減額は、エージェントの待機時間、クラスタ構成、運用人員によって変わるためです。 採用担当者は、モデル利用料に加えて基盤の維持費も投資効果の計算に含める必要があります。
長時間・複数エージェントの
Google AXは、長時間動くエージェントや複数部門で使うエージェントを、自社管理の環境で継続運用したい組織に向いています。 一方、数回の試作や単純な定型処理では、基盤を構築する負担が便益を上回る可能性があります。
| 検討中の状況 | AXとの相性 | 理由 |
|---|---|---|
| 調査や開発など、途中状態を残したい仕事がある | 高い | 停止後も作業状態を保って再開できる |
| 複数のエージェントを共通ルールで運用したい | 高い | タスクと環境の定義をそろえられる |
| 機密情報を扱い、自社環境で実行したい | 要検証 | 自社管理の基盤を選べるが、権限と通信の設計は必要 |
| 一つの業務を短期間だけ試したい | 低い | 構築と保守の負担が相対的に大きい |
| 技術担当者なしで現場だけが導入したい | 低い | Kubernetes、コンテナ、認証情報の知識が要る |
Agent Substrateは、休止したエージェントのメモリとファイルを保存します。 担当者は、必要になった時点で保存済みの状態を実行環境へ戻せます。 Google CloudのAgent Substrate解説↗では、長期間待機する支援エージェント、使い捨ての隔離環境、コーディングエージェントを用途として挙げています。
ただし、エージェントの数だけでは向き不向きを判断できません。 担当者は、停止による業務への影響、エージェントへ与える権限、運用を標準化する効果を確認します。
導入前に
Google AXの検証には、Kubernetesクラスタ、Agent Substrate、AX本体が必要です。 一般的な業務用SaaSのように、アカウントを作るだけで試せる製品ではありません。
公式READMEでは、Agent Substrateを導入したKubernetesクラスタ、Go、kubectlを主な前提としています。 コンテナイメージを作成するkoと、クラスタから接続できるコンテナレジストリも必要です。 そのため、コンテナと認証情報を管理できる技術担当者も必要です。 基盤担当者と対象業務の責任者が共同で評価し、事業部門だけでは導入しない体制が現実的です。
技術環境が整っていても、業務側の条件が曖昧なままでは検証結果を評価できません。 事前に決める項目は次のとおりです。
- エージェントへ渡す入力データと、完了とみなす条件
- 接続を許可する社内システムと外部サービス
- 人の承認なしで実行できる操作
- 異常終了や予算超過を検知したときの停止方法
- ログを確認する担当者と保存期間
- 出力内容の正しさに責任を持つ担当者
なお、隔離環境を用意しても、入力ミスやエージェントの誤判断まで防げるわけではありません。 基盤担当者は実行環境の安全性を管理し、業務責任者は出力結果が妥当かを確認します。
Google AXの
Google AXの使い方を検証するときは、失敗しても顧客や基幹業務に影響しない一つのタスクから始めます。 最初から顧客対応や基幹業務へ適用するのは妥当ではありません。
検証は次の順序で進めます。
- 入力、出力、完了条件が明確な業務を一つ選ぶ
- 本番データと切り離したKubernetes環境を用意する
- Agent SubstrateとAXを導入し、最小権限でタスクを設定する
- 同じ条件で複数回実行し、結果のばらつきと失敗原因を記録する
- 実行中の監視、一時停止、再開、強制終了を試す
- 人の確認時間と基盤運用時間を含む総費用を見積もる
本番採用の判断には、機能が動いたという事実だけでなく、復旧時間、確認作業、運用費の記録が必要です。 評価担当者は、これらを記録して業務全体への効果を確かめます。
成功率だけで評価するのも不十分です。 処理自体が速くなっても、担当者がすべての出力を修正するなら、業務全体の時間はあまり減りません。 処理時間の短縮が小さくても、担当者が夜間の長時間作業を安全に再開できれば、運用上の利点はあります。
最初の検証では、同じ仕事を繰り返せるか、失敗時に担当者が止められるかを確かめます。 費用と責任者を明らかにすることも、本番採用を判断する条件です。
本番採用前に
小規模な検証で動いても、安定した仕様や長期サポートまで保証されたわけではありません。 Google AXは公開直後の開発段階にあるため、重要業務へ適用する前に、変更へ追随する方法とAXを使えなくなった場合の代替手段を決めておく必要があります。
公式READMEでは、安定版になるまでに主要な破壊的変更が入る可能性を警告しています。 Google AXの公式ロードマップ↗では、権限の最小化、予算制御、監査、可観測性を今後の項目に挙げています。 したがって、採用担当者は、ロードマップに載っている機能を現在使えるものとして計画へ含めることはできません。
GKE版Agent Substrateも、Google Cloud公式文書では評価目的と非本番利用向けに公開され、本番サポートは限定提供とされています。 少なくとも現時点では、採用担当者は商用サポートが標準で付く基盤として扱わないほうが安全です。
本番採用の判定項目は次のとおりです。
- 利用するバージョンを固定し、更新前に検証できるか
- 認証情報、外部通信、ファイル操作を最小権限にできるか
- エージェントの誤操作を人が止められるか
- ログへ機密情報が残る場合の対策があるか
- AX、Agent Substrate、Kubernetesの障害を担当者が切り分けられるか
- 保守が止まった場合に、別の実行方法へ移せるか
一項目でも担当者が決まらないなら、検証範囲を広げる段階ではありません。 技術上の未解決事項を残したまま利用部門を増やすと、削減できた作業時間以上に、担当者が障害対応や調整へ時間を使う可能性があります。
まとめ
Google AXは、AIエージェントの仕事を隔離環境へ投入し、担当者が監視し、異常を検知した際に停止し、復旧後に再開するための実行基盤です。 長時間のタスクや複数のエージェントを統制し、自社環境で運用する必要がある組織は、検証の対象にできます。
ただし、試作が動いても、本番で継続運用できるとは限りません。 採用担当者は、Kubernetesを維持できるか、停止と復旧を管理できるか、総運用費が削減効果に見合うかを確認します。
Google AXの使い方を確かめるには、影響範囲の小さい業務を一つ選びます。 担当者が成功率、人の確認時間、復旧手順、費用を記録すれば、AXを採用する業務と別の手段を選ぶ業務を分けて判断できます。