Google の分散エージェント ランタイム、Agent Executor のご紹介

※この投稿は米国時間 2026 年 5 月 21 日に、Google Cloud blog に投稿されたものの抄訳です。

モデルとハーネスの進化に伴い、エージェントは数時間、場合によっては数日間にわたって実行される、より複雑なタスクを担うようになっています。しかし、エージェントにより多くの処理を任せるにつれ、新たな運用上の課題も明らかになってきました。長時間実行されるエージェント ワークフローは壊れやすく、本番環境で信頼性と効率を保ちながら管理することが非常に困難です。

Google はこのたび、エージェントの実行、再開、分散デプロイのためのオープンソース ランタイム標準である Agent Executor を発表します。Google が社内でこうした課題を解決する過程で得た知見をもとに、Agent Executor には次のネイティブ機能が組み込まれています。

• 耐久性のある実行: 長時間実行される処理では、障害が発生した場合や、人間参加型（HITL）の確認などによってエージェントの処理が中断された場合でも、再開できる仕組みが必要です。Agent Executor は、イベントログとスナップショットを通じて、エージェント、エージェント ハーネス、スキル、ツール、サンドボックスなど、あらゆるアクターにこのバックエンドのレジリエンスを自動的に提供します。

• 安全な分離: Agent Executor は、安全性を重視して設計されたサンドボックス内にコンポーネントを分離し、有害な副作用を防ぐとともに、悪意のあるアクティビティがサービス全体を侵害しないようにします。サンドボックスは、エージェントがコードを生成する場合や、複数のテナントやユーザーデータを同時に扱う場合に特に有用です。

• セッションの整合性: 分散エージェント ワークフローでは、複数のコンポーネントが共有セッション状態を同時に更新しようとすることがあります。Agent Executor に組み込まれた単一ライター アーキテクチャは、この状態の整合性を維持し、破損のリスクを軽減します。

• 接続の復旧: 長時間実行されるエージェント型処理では、ネットワーク障害など、さまざまな理由でクライアントが切断されることがあります。Agent Executor を使用すると、クライアントはエージェントに再接続し、クライアントが最後に確認したシーケンス以降のレスポンスを補完できるため、ユーザー エクスペリエンスが向上します。

• トラジェクトリの分岐: チェックポイントを使用すると、エージェントのトラジェクトリ、つまり意思決定やワークフローのパスを任意の時点で分岐できます。これにより、エージェントはコンテキストやその他の状態を失うことなく、複数のパスをテストまたは評価できます。

このブログ記事では、Agent Executor の詳細と、使い始める方法をご紹介します。

Google のエージェント ランタイムと連携する

企業がエージェントを導入するには、さまざまなデプロイモデルを横断してオーケストレーションできることが必要です。独自のワークフロー、パフォーマンス、コンプライアンスのためにオンプレミス インフラストラクチャを必要とするチームもあれば、価値実現までの時間を短縮するために、事前構築済みのエージェントやカスタムのマネージド エージェントを選ぶチームもあります。Google I/O では、エージェント型エンタープライズにおけるチームの構築とスケーリングを加速するために設計された新しいソリューション群として、Antigravity 2.0 や Managed Agents API などを発表しました。

Agent Executor は、こうしたデプロイモデルの橋渡しをします。次のいずれか、またはすべてを自由に組み合わせて使用できます。

• Gemini の最先端エージェント ハーネスである Google Antigravity

• 最新の Deep Research エージェントなど、Google が構築したフロンティア エージェント

• お客様が構築し、Google が管理するカスタム エージェント（新しい Gemini API の Managed Agents など）

• LangChain / LangGraph、Agent Development Kit（ADK）などで構築されたカスタムの専用エージェント、および Agent2Agent Protocol（A2A）を使用する任意のエージェント

エージェント、モデル、コンピューティングを自社で管理する

Agent Executor を使用すると、企業は最大限の柔軟性を確保しながら、ワークロードの主権を維持し、独自のワークフローを自社管理のコンピューティング環境やカスタム サンドボックス内に保持できます。社内の開発チームは、エージェントのデプロイと管理の方法をより柔軟に選択でき、次のようなメリットを得られます。

• ベンダー ロックインの防止: 特定のプロバイダのモデルやコンピューティング環境に縛られることなく、自社のインフラストラクチャにエージェントをデプロイできます。これにより、データ所在地やコスト、予算管理を完全に制御できます。

• 独自のハーネスとエージェントの使用: Agent Executor はハーネスに依存しない設計のため、独自のハーネスを使用することも、他のベンダーが提供するハーネスを使用することもできます。また、業界標準のフレームワークやプロトコルで開発されたエージェントもサポートしており、互換性のあるエージェントからなる幅広いエコシステムを利用できます。

• 実行の完全な制御: Agent Executor を使用すると、デベロッパーは MCP、スキル、その他のエージェントを含むエージェント型スタック全体を、自社のデータプレーン上で直接実行できます。カスタムの分離境界やワークロード ポリシーの適用を備えた、任意のコンピューティング環境を選択できます。

エージェント ファーストのコンピューティング レイヤを使用して Kubernetes 上でエージェントをスケール

エージェント ワークロードが数億規模へと拡大し、実行時間も長くなるにつれて、お客様は従来のコンピューティング抽象化の限界に直面しています。従来のソフトウェアとは異なり、エージェントは外部入力を待機する非線形のプログラムだからです。この問題を解決するため、Google は Google Kubernetes Engine チームと連携し、本日発表した新しいオープンソース プロジェクト Agent Substrate を開発しました。

Agent Substrate は Kubernetes に新しい抽象化レイヤを導入し、準備済みのコンピューティング キャパシティにエージェントをリアルタイムで割り当てたり、そこから退避させたりします。これにより、レイテンシを低減しながら、スケールと効率を高めることができます。標準の Kubernetes は、長時間実行される数千のサービスを処理するよう最適化されています。一方、Agent Substrate は、標準的なコントロール プレーンでは処理しきれない、数百万件規模の 1 秒未満のツール呼び出しが頻繁に発生する状況に対応できるよう設計されています。Agent Substrate は、既存のサンドボックス インフラストラクチャが備えるセキュアなランタイムとスナップショットの中核機能を活用しながら、Kubernetes の一部の制限を回避するために設計された最小限のコントロール プレーンと組み合わせます。Kubernetes のそれ以外の部分を作り直す必要はありません。これらのレイヤを連携させることで、次のことが可能になります。

• コンピューティング効率の最大化: Agent Substrate は、数億の登録済みエージェントを処理できるように設計された新しいコントロール プレーンを導入します。Agent Executor と組み合わせることで、Agent Substrate は現在最大規模のエージェント デプロイメントを支える基盤を提供できます。

• Kubernetes エコシステム内での運用: Agent Substrate は Kubernetes 上に構築されており、宣言型構成によるコンピューティングのスケジューリングと水平スケーリングを可能にします。

以下のデモでは、サンプル ワークロードを使って、Agent Executor と Agent Substrate を併用する方法を紹介します。

使ってみる

モデル、エージェント、ハーネス、そしてそれらを取り巻くインフラストラクチャは、かつてない速さで進化しています。Google は Agent Executor をオープンに開発することで、実際のデベロッパーに使用してもらいながら設計を検証し、皆様からのフィードバックに基づいて改善できるようにしています。

Agent Executor は現在、プレビュー版としてご利用いただけます。ぜひコードをご確認いただき、ご自身のワークロードでテストしながら、エージェント ランタイムの未来を形作る取り組みにご参加ください。今すぐ GitHub リポジトリにアクセスして、使い始めることができます。

- ソフトウェア エンジニア Jaana Dogan

- エンジニアリング ディレクター Ethan Bao