Alibaba Cloud AgentRun で AI エージェントに使い捨てワークスペースを与える

Alibaba Cloud AgentRun は、AI エージェントに使い捨ての実行ワークスペースを提供するサーバーレスプラットフォームです。安全な環境でタスクを自動化しながら、スケーラビリティも確保できます。

執筆: Rizky Andriawan（Alibaba Cloud インドネシア、ソリューションアーキテクト）

TL;DR — AI エージェントは単に応答するだけでなく、行動します。コードを実行し、ブラウザを操作し、ファイルにアクセスします。だからこそ、ワークスペースが必要です。この 2 年間、エージェント基盤を構築してきた人々がほぼ共通してたどり着いた発想の転換は、「エージェントはステートレスであるべき」ということではありません。むしろ、デフォルトの前提を反転させるということです。人間の環境はデフォルトで永続化されますが、エージェントはデフォルトで隔離し、永続化は例外とします。実行環境は使い捨てにし、メモリや ID、アーティファクトは意図的に別の場所で永続的に保持します。本記事では、なぜこの反転が正しい設計判断なのか、そして Alibaba Cloud の AgentRun がサーバーを一切立てることなく、どのようにこの考え方を実用的なワークスペースとして実現するのかを解説します。

01_hero
作業する場所は使い捨てに、記憶する場所は永続的に。

エージェントは実際に何をしているのか

チャットボットは応答します。エージェントは行動します。

チャットボットに質問すれば、テキストが返ってきますが、外の世界は何も変わりません。一方、エージェントに「このスプレッドシートを分析して外れ値をチャートにして」「このリポジトリで失敗しているテストを直して」「このサイトを開いて最安の 3 件を取得して」と指示すると、エージェントは実際に操作を行う必要があります。コードを実行し、ファイルを書き込み、ブラウザを操作し、結果を読み取り、次の行動を判断する。これをループの中で何度も繰り返します。

「回答する」のではなく「行動する」。このたった一つの違いが、チャットボットには不要だったものを必要にします。それは、作業を行う場所です。コードを実行する場所、一時的なディスク、ブラウザ、シェル。これをワークスペースと呼びましょう。

ここで本当に問うべきは、エージェントにどのようなワークスペースを与えるべきかということです。「開発者と同じものを与えればいい」という直感は、実はまったくの逆だとわかります。その理由を理解することが、AgentRun のようなプラットフォームの存在意義を知る最も確実な道筋です。

02_chatbot_vs_agent
チャットボットは 1 ステップで回答。エージェントは隔離されたワークスペース内でループを実行し、その結果をもとに行動します。

デフォルトの反転

自分の開発環境を思い浮かべてください。ノート PC や SSH 接続する VM を一度セットアップすれば、ツールをインストールし、ファイルを置いたまま、翌日戻ってもすべてがそのまま残っています。これが人間のデフォルトです。デフォルトは永続化、隔離は例外。 信頼できないものを扱うごくまれな場合にだけ、サンドボックスやクリーンな VM を使います。

エージェントが求めるのはその逆です。デフォルトは隔離、永続化は例外。 すべてのタスクはクリーンな隔離環境で実行され、タスク完了後に残すべきものだけが、その環境の外へ意図的にプッシュされます。

ここで「ワークスペース」の意味を明確にしておきましょう。使い捨てにすべきなのはエージェントの実行環境、つまりコードを実行し、ブラウザを操作し、一時ファイルを書き込む場所です。一方、使い捨てにしてはならないもの — メモリ（「Acme 社の案件は停滞中」など）、ID と権限、生成したアーティファクト、実行の監査証跡 — は、ワークスペースの中には置きません。ワークスペースを破棄しても失われないよう、意図的にワークスペースの外部で永続化します。

この分離こそがすべての鍵です。実行環境のレベルで比較すると、コントラストは明確になります。

	人間の開発環境	エージェントの実行ワークスペース
ライフスパン	数か月。いつでも作業を再開できる。	1 タスク分。数秒〜数分で消滅。
保持されるもの	デフォルトですべて。	デフォルトでなし。永続的な状態は外部に存在。
ID	マシンは自分のもの。	ワークスペースは匿名。ID と権限はタスクごとに外部から付与。
プロビジョニング	一度セットアップすれば、コストは償却される。	オンデマンドで生成、完了時に消滅。
並行性	1 人に 1 台。	一度に数千を起動、その後ゼロに。
信頼	自分自身を信頼する。	構造的に信頼できない。悪意ある命令が埋め込まれた可能性のある入力（Web ページ、ドキュメント）上で、自ら生成したコードを実行する。

AgentRun はまさに、このギャップを解消するために構築されました。ユーザーがサーバーをプロビジョニング・保守する代わりに、AgentRun が各エージェントに隔離された使い捨ての実行ワークスペースをオンデマンドで提供し、課金はエージェントが実際に作業している間のみ発生します。以降では、なぜこれが適切な設計なのかを一つずつ見ていきましょう。

使い捨ての実行環境が優れている 5 つの理由と、AgentRun の実現方法

「使い捨て」と聞くと妥協のように感じるかもしれません。しかし実行環境に関しては、むしろ強化です。以下の 5 つの理由を見ていきましょう。いずれも AgentRun の具体的な機能に結びついています。

白紙の状態が保証され、動作が再現可能になる。 すべてのタスクは既知の正常なベースラインから開始されます。環境のドリフトは起こらず、前回の実行の残骸が結果をひそかに変えてしまうこともありません。AgentRun はタスクごとにサンドボックスを新規作成し、アイドル状態になればリリースするため、前回の混乱を引き継ぐことはありません（金曜日も火曜日とまったく同じ状態から始まるため、「火曜日は動いたのに金曜日は動かない」という問題がほぼ解消されます）。
影響範囲が空間的にも時間的にも限定される。 エージェントがディスクを埋め尽くしたり、汚染された Web ページから怪しいコマンドを拾って実行したり、自分自身のファイルを削除したとしても、すべてが隔離されており、いずれすぐに破棄されます。AgentRun は各サンドボックスを独立したファイルシステムとプロセス空間で実行し、生存時間に上限を設けます（最大でも数時間、アイドル状態ならさらに早く回収されます）。使い捨てであること自体が、潜在的なインシデントを些細な出来事へと縮小します。
タスク間・ユーザー間の汚染がない。 ワークスペースが永続化・再利用されると、あるタスクの認証情報やデータが次のタスク、場合によっては他のユーザーのタスクで漏洩するリスクがあります。タスクごとのサンドボックスは、この種の漏洩を「起こりにくくする」のではなく、構造的に不可能にします。
コストは経過時間ではなく、実際の作業量に応じて発生する。 人間のノート PC が 1 台アイドル状態でも問題ありません。しかし 100 万台のエージェントマシンがアイドル状態となれば、高額な請求につながります。エージェントの活動パターンはスパイク状で、大半の時間はモデルの応答やページの読み込みを待っています。AgentRun は Alibaba Cloud のサーバーレスプラットフォーム（Function Compute）上に構築されているため、事前のプロビジョニングは不要です。ワークスペースはオンデマンドで生成され、アイドル容量ではなく使用量に応じて課金されます。
フリート管理不要のスケーラビリティ。 1,000 個のエージェントが同時に起動すれば 1,000 個のワークスペースが立ち上がり、1 分後には消滅します。容量計画も、パッチ適用やクリーンアップ対象のマシンも不要です。サーバーレス基盤がワークロードに合わせて自動的にスケーリングします。

脅威モデルと設計がぴったり一致している点に注目してください。リスクの本質は、信頼できない入力上で信頼できないコードが実行されることです。その対策として、外部アクセスを遮断する隔離と、何をしても痕跡が残らない使い捨ての組み合わせが、このリスクを実質的に無効化します。

エージェントの仕組みとは

エージェントに何か謎めいたものを感じていた方へ。ワークスペースこそが、その仕組みの秘密を解き明かす鍵です。

エージェントは答えをあらかじめ知っている万能の存在ではありません。ワークスペースの中で物事を試し、結果を読み取り、再び試すというループです。使い捨てのサンドボックスが必要な理由はシンプルで、エージェントはエラーを出すコードを実行したり、誤ったものをインストールしたり、間違った方向へ進んだりして環境を散らかすからです。その散らかった状態を隔離して破棄できることに意味があります。メモリがワークスペースの外に存在する理由も同じで、学んだことは保持しつつ、散らかした部分だけを捨てられるようにするためです。試行錯誤は使い捨てのセルで行い、そこから得られた教訓は永続ストアに保存する。これがエージェントの基本構造です。

AI エージェントは天才というよりも、密閉された部屋に 1 台のコンピュータとたった 1 つのタスクだけを与えられた、超高速で疲れ知らずのインターンだと考えてください。次のジョブのためにその部屋はゼロから作り直しますが、メモは残します。これは単なる比喩ではなく、実際のアーキテクチャそのものです。

03_trace
エージェントは試行錯誤で作業を進めます。計画、実行、失敗、リトライ、そして成功。

1 つのタスクを最初から最後まで追う

具体的な例で見てみましょう。営業オペレーション用のエージェントに、こう指示したとします。「先週のパイプラインレポートを取得して、停滞している案件にフラグを立てて。」

エージェントは新しいワークスペースを立ち上げ、ブラウザで CRM にログインしてレポートをダウンロードします。数行の Python コードを実行して 14 日間動きのない案件を特定し、短いサマリーを作成します。処理が終わると、ワークスペースは削除されます。

ここで、何が起きなかったかに注目してください。

ログインしたまま放置され、次の実行に引き継がれるブラウザはありません。
長期稼働するマシンに、中途半端にインストールされた Python パッケージが残ることもありません。
24 時間 365 日稼働する VM に、CRM の認証情報が放置されることもありません。
金曜日の実行も火曜日とまったく同じクリーンな状態から始まるため、「先週は動いたのに」という環境ドリフトは起きません。

一方、作成されたサマリー、すべての操作の監査ログ、「Acme 社からの応答が途絶えた」というメモリなど、保持すべきものはワークスペースの外部に意図的に書き出されており、ワークスペースが消滅しても影響を受けません。

これが 1 つのタスクにおけるデフォルトの反転です。実行環境は使い捨て、しかし結果とメモリは永続。 この概念を一度理解すると、あらゆる場面で同じパターンが見えてきます。

AgentRun の紹介：マネージドサービスとしてのアプローチ転換

AgentRun がパッケージ化しているのは、まさにこの設計思想です。「オールインワンのエージェントボックス」と呼びたくなりますが、それでは異なるレイヤーを明確に分離したまま提供するという設計の妙を見過ごしてしまいます。

agentrun_01_agent_creation
セットアップは簡単。モデル、プロンプト、ツールをフォームで定義するだけ。インフラ管理は不要です。

実行サンドボックス — 使い捨てワークスペースそのものです。AgentRun の AIO サンドボックス（All-In-One）は、エージェントが実際に必要とする 3 つの機能を 1 つの隔離環境にまとめています。ヘッドレスブラウザ、コードインタープリター、そしてインタラクティブなターミナルとファイルシステムです。Alibaba はこれをエージェントの「目・脳・手」と呼んでいます。

agentrun_09_sandbox_templates
AgentRun は 5 種類のサンドボックステンプレートを提供。それぞれ異なるタイプのエージェント作業に特化しています。

ブラウザサンドボックス（専用ブラウザプレーン）： 標準ツール（DevTools プロトコル経由の Playwright や Puppeteer）で操作可能なクラウドヘッドレスブラウザです。VNC 経由のライブビューが組み込まれており、エージェントがサイトをクリックしていく様子をリアルタイムで監視できます。「エージェントが今何をしたのか」をデバッグする際、ブラックボックスとガラスボックスの違いを生む機能です。

AIO サンドボックスの作成画面。リソース、ブラウザ、ランタイムを選択するだけです。ワークスペースはオンデマンドで生成され、タスク完了時に消滅します。

モデルアクセスとガバナンス — エージェントがどのモデルを呼び出せるか、どのような制約の下で利用するかを制御します。

agentrun_07_model_management
モデルガバナンス画面。エージェントが呼び出せるモデルとその制約を管理します。

メモリと状態のプレーン — 使い捨てワークスペースと対をなす永続レイヤーであり、ワークスペースの外側に意図的に配置されます。

agentrun_03_memory
メモリは使い捨てワークスペースの外に配置。永続的かつ検索可能で、意図的に分離されています。

可観測性・コントロールプレーン — エージェントが何を行い、なぜそう判断したかのトレースを提供します。

agentrun_04_monitoring
可観測性レイヤー。すべての呼び出しが記録され、リソース使用量が計測されます。

使い捨てのワークスペースが、本記事の主題です。他のレイヤーは、ワークスペースを使い捨てにできるようにするために存在しています。AgentRun の役割は、これらのレイヤーを統合してユーザーの手間を省きつつ、各レイヤーの責務が明確にわかるよう境界をクリーンに保つことです。

04_boundary
中央は使い捨て、周辺は永続。すべてが 1 つのサーバーレスプラットフォーム上に統合されています。

agentrun_06_tools_marketplace
Playwright から RDS Copilot まで、MCP ツールとクラウドネイティブスキルのマーケットプレイスでエージェントの機能を拡張できます。

agentrun_11_agent_runtime_list
管理が容易。すべてのエージェントランタイムを 1 か所で可視化・制御できます。

クラウドで AI が生成したコードを実行しても安全なのか？

当然の懸念があります。エージェントが信頼できないコードを実行し、何千ものユーザーがハードウェアを共有しているなら、1 つのサンドボックスが突破されて他の顧客に影響する可能性はないのか。正当な疑問であり、正直な答えは「完全に密閉されている」でも「何でもあり」でもありません。

ワークスペースはベアメタルの共有マシン上に直接配置されているわけではありません。数百万のマルチテナントサーバーレスワークロードをすでに隔離している軽量 VM クラスの分離（セキュアコンテナ）の上で稼働しています。これは新しく脆弱な境界ではなく、実戦で検証済みの堅牢な境界です。ただし、「堅牢」は「完璧」を意味しません。突破できない隔離は存在せず、研究者が脆弱性を発見することもあります。さらに、エージェントはサンドボックスだけでは防げないまったく新しい攻撃面を生み出します。それがプロンプトインジェクションです。Web ページやドキュメントを通じて、信頼できない入力がエージェントへの命令として紛れ込む手法です。

そのため、実際のセキュリティ戦略は多層防御です。堅牢な隔離に加え、使い捨て（後に盗まれるものが何も残らない）、制御されたエグレス（外部への通信を制限）、そして最小特権の認証情報を組み合わせます。使い捨てだけでセキュリティが完結するわけではありませんが、エージェントの暴走を永続的な負債から数十秒で解消できる問題へと変えてくれます。

「Function Compute 上で動く」ことの意味

すべてがサーバーレスプラットフォーム上にあるため、リソースの予約やスケーリング、シャットダウンの管理は不要です。ワークスペースはオンデマンドで作成され、アイドル状態になれば自動的にリリースされ、寿命は数時間に制限され、使用量に応じて課金されます。スパイクが多く大半は待機状態というエージェント特有のワークロードパターンは、常時稼働の VM フリートでは破滅的な費用になりますが、サーバーレスならまさにこのパターンを効率的に吸収できます。ユーザーはエージェントのロジックを持ち込むだけでよく、AgentRun が必要な間だけ存在するインフラを提供します。

まとめ

エージェントを活用してシステムを構築しているなら、サーバーの管理から発想を切り替えましょう。「使い捨ての実行環境」と「永続的な記憶・状態」を意図的に分離するという考え方です。エージェントが生成したコードをアプリケーションと同じ環境で実行してはなりません。だからといって、そのために VM フリートを立ち上げる必要もありません。AgentRun を使えば、使い捨ての実行ワークスペースは API 呼び出しで利用できるマネージドサービスとなり、メモリ、ガバナンス、監査証跡がその周囲に組み込まれています。

このタイミングにも注目してください。使い捨て実行環境という形態は 2 年前には製品カテゴリとしてほぼ存在しませんでしたが、今ではあらゆる場所で見られます。互いに情報交換のないチームが、独立して同じ結論にたどり着いているのです。こうした現象が起きるとき、通常は問題そのものが解決策の形を示しています。コンテナがかつてあらゆるワークロードのデフォルトへと静かに定着したように、使い捨ての実行セルがエージェントワークロードのデフォルト基盤になりつつあります。AgentRun は、まさにその基盤となることを狙った Alibaba Cloud の戦略的な賭けです。

エージェントが注目を集めています。しかし、エージェントが実際に作業する地味な箱 — 1 つのタスクのために構築され、使用後には破棄され、重要なものはすべてその外側に安全に保管される仕組み — こそが、エージェントを本当に機能させている核心なのかもしれません。

[クロージング CTA のプレースホルダー — AgentRun のドキュメントへのリンク、およびフォローアップ記事としての実践的な「AgentRun で小さなエージェントを構築する」ウォークスルーへのリンク。]

この記事は英語版からの翻訳です。元の記事はこちらをご参照ください。

Community

Alibaba Cloud AgentRun で AI エージェントに使い捨てワークスペースを与える

エージェントは実際に何をしているのか

デフォルトの反転

使い捨ての実行環境が優れている 5 つの理由と、AgentRun の実現方法

エージェントの仕組みとは

1 つのタスクを最初から最後まで追う

AgentRun の紹介：マネージドサービスとしてのアプローチ転換

クラウドで AI が生成したコードを実行しても安全なのか？

「Function Compute 上で動く」ことの意味

まとめ

Read previous post:

Read next post:

Regional Content Hub

You may also like

Comments

Regional Content Hub

Related Products

Alibaba Cloud Model Studio

Alibaba Cloud for Generative AI

Qwen

Function Compute