本文へスキップ

AIエージェントの実行基盤と非同期通信：サンドボックスを使い捨て、会話ごとにトピックを作る設計

公開日 最終更新日 解説
share
エージェントの実行基盤と非同期通信を象徴的に表現したイメージ（生成画像・技術図ではありません）

この記事が扱う問題

AI エージェントを業務に組み込むと、実行基盤に求められる性質が従来の Web アプリケーションとは変わります。一つのタスクが数分から数時間続き、その途中でコードを実行し、ファイルを書き、外部のツールを呼び出します。実行環境の数は利用者数ではなくタスク数に比例して増え、その多くは短時間で役目を終えます。

最初に決めるべきことは二つです。エージェントのコードを「どこで、どの単位で隔離して動かすか」と、長い処理の結果を「どの経路で受け渡すか」です。本記事では、展示されたサーバーレス実行基盤とサンドボックス、および Apache RocketMQ の LiteTopic を取り上げ、公開文書で確認できる仕様と展示上の主張を分けて整理します。

用語の整理

  • サンドボックス：エージェントが生成したコードやツールを、他の処理から隔離して実行する環境。公開文書上、AgentRun と ACS Agent Sandbox は、起動の速い軽量な仮想マシンである MicroVM による隔離を採用しています。
  • ゼロ縮退（スケール・トゥ・ゼロ）：要求がない間はインスタンスを 0 台まで減らし、待機中の計算資源の課金を抑える運用。
  • LiteTopic：RocketMQ 5.5.0 で導入された軽量なトピック。セッションやタスクごとに大量に作られ、使われなくなると自動で削除されます。
  • AgentCore：展示区画「Runtime & Orchestration」に掲げられていた Alibaba Cloud 側の展示名。AWS の Amazon Bedrock AgentCore と名称が同じですが別物です。閲覧時点で Alibaba Cloud 側の公式文書は確認できず、展示写真からも内部構成は判読できませんでした。

全体構成と処理の流れ

実行基盤と非同期通信を、一つのタスクが完了するまでの流れとして並べ直すと次のようになります。以下も、公開文書の記載を編集部が並べた整理であり、製品の実装順序を示すものではありません。

  • ① 要求の受信：同じセッションの要求は、セッション親和性によって同じインスタンスへ送られる。
  • ② 実行：エージェントが生成したコードとツールの呼び出しは、MicroVM で隔離されたサンドボックスの中で動く。
  • ③ 状態の退避：作業状態はサンドボックスの外の保存領域に置き、実行環境そのものは使い捨てにできる。
  • ④ 休眠：非活性になったサンドボックスはメモリ状態を保持したまま休眠し、vCPU とメモリの課金が止まる。
  • ⑤ 非同期の受け渡し：分単位から時間単位の処理は、セッションやタスクごとの LiteTopic を経路にして、接続を保持せずに受け渡す。
  • ⑥ 復帰と回収：要求が届いたら休眠から復帰して状態を戻し、TTL を過ぎたトピックと役目を終えたサンドボックスは自動で消える。

実行基盤：休眠という中間状態

展示では、Function Compute（FC）の「Serverless AI Runtime」として、ミリ秒単位の伸縮、ゼロまでの縮退、最小 0.05 vCPU・128 MB の割当、事前ウォームアップと浅い休眠によるコールドスタートの低減が掲げられていました。これらはいずれも測定条件の示されていない展示上の記載です。

公開文書で確認できる仕組みは次のとおりです。

  • AgentRun（Function Compute 系のエージェント基盤）は、同じセッションの要求を同じインスタンスに送るセッション親和性を持ち、セッションが非活性になると資源を解放します。MicroVM によるセキュアコンテナを用いた要求・インスタンス・セッションの多層隔離と、OSS／NAS のマウントによる保存領域の分離も記載されています。
  • ACS Agent Sandbox（Container Compute Service）は Public Preview の段階です。ウォームプールから数百ミリ秒で作成でき、休眠中はメモリ状態を保持したまま、典型的には 1〜10 秒で復帰します。休眠中は vCPU とメモリの課金が止まり、一時ストレージは利用分が課金されます（最初の 30 GiB 分も含む）。毎分最大 15,000 サンドボックスの伸縮が記載される一方、GPU は非対応とされています。

ゼロ縮退と低遅延は本質的に両立しにくい要求です。0 台まで縮めれば待機コストは消えますが、次の要求では必ず起動が発生します。ウォームプールを厚くすれば遅延は下がりますが、待機コストが戻ります。「休眠」はこの間を埋める中間状態として設計されています。展示の「ミリ秒単位」は FC の展示上の訴求であり、ACS Agent Sandbox の公開値（ウォームプールから数百ミリ秒、休眠から典型 1〜10 秒）とは製品も測定条件も異なるため、相互の裏付けには用いません。

もう一つの設計上の意味は、計算と状態の分離です。セッション親和性で一つの会話を一つのインスタンスに寄せつつ、作業状態をサンドボックスの外の保存領域に置けば、サンドボックス自体は使い捨てにできます。

非同期通信：LiteTopic の仕組み

数分から数時間かかるタスクを同期 HTTP で扱うと、接続の維持、タイムアウト、再試行時の重複実行、結果のポーリングといった問題が生じます。展示の「RocketMQ for AI」は、百万規模の LiteTopic によって状態を持つ非同期通信とセッションの保持を支えると説明していました。これは現地で確認した展示の提示内容で、「百万規模」の測定条件は示されていません（公開資料は閲覧時点で取得できていません）。一方、以下の項目は Apache RocketMQ の公開文書で確認できる仕様です。

  • Lite 型の親 Topic の中に置かれる二次的な格納単位で、既定では LiteTopic ごとに一つのキューを持ちます。
  • 初めて送信または購読されたときに自動作成され、TTL の間メッセージが届かなければ自動削除されます。TTL は親 Topic 側の設定に従います。
  • 消費は順序消費のみで、各 LiteTopic を一つの消費スレッドが処理します。公開文書には、全体のスループット（Total TPS）は LiteTopic の数に比例して伸びると記載されています。ただし、チャネル単位では単一キューの性能に制約され、Metelix による実測は行っていません。
  • 同じ消費者グループ内でも、消費者ごとに異なる LiteTopic の集合を購読でき、実行中に追加・削除できます。消費者一つあたり数千の LiteTopic まで扱えます。
  • 滞留量のメトリクスはありますが、処理遅延のメトリクスはありません。
  • サーバ 5.5.0 以降、gRPC SDK 5.1.0 以降が必要です。

公開時期にも注意が要ります。展示には「LiteTopic が Apache RocketMQ 5.5.0 とともに正式リリース」とありましたが、5.5.0 は GitHub Releases 上で 2026年4月10日に公開されています。9月の大会で初めて公開された機能ではありません。2026年8月20日の 5.5.1 では、Lite Simple Consumer のサーバ側対応など LiteTopic 関連の修正が行われています。

トレードオフ

LiteTopic は、従来は少数・長寿命だったトピックを、自動作成と TTL による自動削除によって使い捨て可能な単位に変えます。一方で次の代償があります。

  • 呼び出し側は、結果がいつ・どの経路で返るかを扱う状態機械を持つ必要があります。
  • 1 セッション内の処理能力は、単一キュー・単一消費スレッドに制約されます。
  • 配送を「少なくとも一回」と見なす場合、ツール側の冪等性（同じ要求を二度処理しても結果が変わらない性質）が必要になります。
  • 処理遅延のメトリクスがないため、遅延の監視は滞留量以外の手段で補う必要があります。

展示には「MCP Agentic Messaging Primitives」が「提案を推進中」として掲げられていました。これは提案段階の表示であり、標準として採択されたものとして扱うべきではありません。

評価前の検証チェックリスト

  • ウォームプールを使わない場合のコールドスタート時間（公開値は未確認）
  • 休眠からの復帰時間の分布と、自社のタスク長・再開頻度との関係
  • GPU を使うワークロードでゼロ縮退が可能か（ACS Agent Sandbox は GPU 非対応と記載）
  • サンドボックスへの資格情報の注入方式と、休眠・復帰をまたぐ有効期限の扱い
  • LiteTopic の再試行とデッドレターの挙動（取得した文書では確認できていない）
  • 展示の「百万規模の LiteTopic」がクラスタあたりの値か、クォータの上限とどう関係するか

まとめ

エージェント向けの実行基盤は、隔離された小さな実行環境を大量に作り、休眠させ、使い捨てる方向に進んでいます。その前提として、作業状態を実行環境の外に出すこと、長い処理を非同期の経路に移すことの二つが必要になります。LiteTopic はセッション単位の非同期経路を大量に作れるようにしますが、順序消費のみ・処理遅延メトリクスなしといった制約を理解したうえで、冪等性と遅延監視を呼び出し側で設計することが前提です。

本記事は Apsara Conference 2026 技術解説シリーズ の一部です。実行環境の外に置く保存単位の設計を扱う第3回「サンドボックス一つに保存単位一つ」は準備中です。

よくある質問

エージェントの実行環境はなぜ使い捨てにするのですか？

一つのタスクが数分から数時間続き、実行環境の数が利用者数ではなくタスク数に比例して増えるためです。作業状態をサンドボックスの外の保存領域に置けば、実行環境自体は役目を終えた時点で破棄できます。

長い処理を同期HTTPで扱うと何が問題になりますか？

接続の維持、タイムアウト、再試行時の重複実行、結果のポーリングが問題になります。LiteTopicのような非同期経路に移すことでこれらを分離できますが、呼び出し側に状態機械と冪等性の設計が求められます。

LiteTopicを使うときの主な制約は何ですか？

消費は順序消費のみで、1セッション内の処理能力は単一キュー・単一消費スレッドに制約されます。また処理遅延のメトリクスがないため、遅延監視は滞留量以外の手段で補う必要があります。

参照した一次情報

参照した一次情報（Alibaba Cloud / AWS / Apache RocketMQ）

記事情報

取材・執筆・編集株式会社Metelix
公開日
最終更新日
分類解説（エージェント実行基盤・サンドボックス隔離・非同期メッセージング）
利害関係本記事は、Apsara Conference 2026の展示と公開文書をMetelixが取材・編集した技術解説です。数値は特に断りのない限りベンダー提示値であり、Metelixによる測定値ではありません。
検証方法公開文書の記述は、2026年9月26日（日本時間）に公式サイト・公式リポジトリから一次情報を取得し、本文に含まれる文字列と一致することを確認しました。展示の記述は2026年9月の現地取材で確認した提示内容で、測定条件は示されていません。
評価時点展示の取材は2026年9月（杭州・現地）。公開文書の初回閲覧日は2026年9月25日（日本時間）、再確認日は2026年9月26日（日本時間）。内容と提供段階は閲覧時点のもので、今後変わる可能性があります。

関連記事

改訂履歴

初版公開
share

RiN Gateway

このコラムの内容を自社に適用する方法をご相談ください

RiN Gatewayは、企業のAI活用における統制・ガバナンス・コスト最適化を支援するプラットフォームです。トライアルや導入相談はお気軽にどうぞ。

RiN Gatewayの詳細お問い合わせ
コラム一覧へ