AI News HubLIVE
サイト内リライト8 分で読了

エージェントには独自のコンピュータが必要:安全に提供する方法

AIエージェントが自律的にタスクを実行するには、分離された安全で迅速にデプロイ可能なコンピューティング環境が必要です。この記事では、エージェントがなぜ独自のコンピュータを必要とするのか、そしてLangSmith SandboxがマイクロVM分離、スナップショットとフォーク、認証プロキシ、安全な実行を通じてどのようにそのニーズを満たすかを説明します。また、プロンプトインジェクションなどのセキュリティリスクと緩和策についても議論します。

コンピューティングの歴史の大半において、開発者環境は物理マシン、VM、コンテナを意味し、それぞれ作業が共有され、意図的なセットアップと破棄が必要でした。すべてのエージェントに独自の独立したコンピュータを与え、1秒未満で起動し、タスク完了後にクリーンアップするというアイデアは、大規模には実用的ではありませんでした。サンドボックスは、アップグレードされたワークフローをより安全に実行する方法を提供します。反復、検証、および人間が通常使用するツールへのアクセスを必要とするタスクを、人間の監督なしで実行するための分離された環境を提供します。すべての人間の開発者にはラップトップが与えられます。すべてのエージェントにはコンピュータを与えることができます。

なぜエージェントに独自のコンピュータが必要なのか

LLMに失敗するテストのデバッグやデータセットのクリーニングを依頼すると、ほとんどの作業をこなしてくれます。修正方法を説明し、クエリを書き、分析の概要を示します。その後、停止し、残りのすべてをあなたが引き継がなければなりません。問題は、テキストしか生成できないシステムは、配管の修理方法を正確に説明できるが、手も工具もトラックもない配管工のようなものだということです。アドバイスは完璧かもしれませんが、誰かがレンチを回しに行かなければなりません。

エージェントは「手」を得ることでそのギャップを埋めます。モデルにコードを実行し、結果を読み、再試行する能力を与えると、完全なエージェントループにより、エージェントはより自律的に行動できるようになります。修正を提案することしかできないエージェントは、修正が機能するかどうかを知る方法がありません。そのため、エージェントには独自のコンピュータが必要です。ファイルシステム、シェル、パッケージマネージャー、ネットワークアクセス、およびステップ間で状態を保持する実際の環境です。

あなたが1台のラップトップを持ち、おそらくあなただけがそれを使用しているのに対し、エージェントプラットフォームはこれらの環境を並行して数千も起動しているかもしれません。それぞれが分離され、使い捨て可能で、実際の実行力を安全に委ねられるものでなければなりません。

実際には何を意味するのか

  • コーディングエージェントは、リポジトリをクローンし、依存関係をインストールし、テストスイートを実行し、失敗を読み、コードにパッチを適用し、すでに検証済みの差分を返すことができます。
  • データ分析エージェントは、生ファイルをロードし、スキーマを検査し、PythonまたはSQLで変換を書き、グラフを生成し、レポートを見せる前に自分の計算をチェックできます。
  • リサーチエージェントは、ウェブを閲覧し、ソースをダウンロードし、それらを解析して正規化し、主張を相互参照し、引用付きの完成したレポートをまとめることができます。

各例で、モデルは実際のステップを実行し、実際の結果をチェックしています。そのためには、推論のためのコンテキストウィンドウだけでなく、作業する場所が必要です。

なぜインフラを直接渡せないのか

では、なぜエージェントにローカルまたはDockerコンテナ内でコードを実行させないのでしょうか?ほとんどのプロトタイプはローカルで始まります。高速で、馴染みがあり、デモを動かすには十分です。その後、本番環境に移行すると、同じ設定が2つの方法で失敗し始めます。セキュリティ(エージェントが実行しようとしているコードは、人間が書いたり、レビューしたり、見たりしていない可能性がある)と分離(標準のコンテナ境界は、信頼されていないモデル生成の実行を保持するように設計されていない)です。

エージェントに悪意はありませんが、このコードがどこから来ているかはわかりません。コードの1行は、モデル自体、クローンされたリポジトリ、または実行中にインストールされたパッケージから発生する可能性があります。エージェントが実行するコードは、実行の数秒前に生成され、ユーザーが入力したものに直接形成され、エージェントがタスクを推論する過程で生成されます。その間にレビューステップはありません。よく書かれたプロンプトでも、セキュリティ上の懸念から免れることはできません。最も安全な姿勢は、マシンレベルの分離です。エージェントに実際の作業環境を与えますが、その環境をラップトップ、本番環境、および並行して実行されている他のすべてのエージェントのワークスペースから分離しておきます。

各エージェントのコンピュータがうまく行うべき4つのこと

  1. 安全な実行:2025年、自己複製型npmワームが数百のパッケージにバックドアを仕掛け、テストが実行される前にプリインストールフックで実行されました。2026年に開示されたLinuxカーネルCVEは、732バイトのPythonスクリプトで約1時間に主要なディストリビューションをルート化でき、コンテナはホストとカーネルを共有するため役に立ちませんでした。エージェントが実行するコードは、ソースに関係なく、デフォルトで信頼できないものとして扱われるべきです。各エージェントのワークスペースは、独自のカーネル、ファイルシステム、ネットワーク境界を持つハードウェア仮想化マシンであるべきです。
  1. 制御を維持する:サンドボックス内の制御は、高額、予期しない、または資格情報を漏洩する行為からあなたを守ります。資格情報管理:プロキシを介してネットワーク層で資格情報を注入することで、エージェントはトークンを見ることなく外部サービスを呼び出すことができます。リソース制限:CPU制限、メモリ上限、ネットワーク許可/拒否リストにより、タスクごとにコスト上限を定義し、暴走実行を防ぎます。ライフサイクル制御:サンドボックスはデフォルトでエフェメラルであり、タスクのために起動し、必要な間状態を保持し、アイドル時にクリーンアップされます。
  1. 観測可能性:エージェント実行における観測可能性とは、どのコマンドが実行されたか、どのファイルが作成または変更されたか、どのネットワークコールが送信されたか、どのパッケージがインストールされたか、各ステップの出力は何かを知ることを意味します。これは本質的にワークフローの監査ログであり、特に機密データに触れたり、現実世界に影響を与えるアクションを取るものにとって重要です。エージェントを信頼できるものにするのは、既知の状態から再実行し、ブランチを比較し、実際に何が起こったかをトレースする能力です。
  1. 迅速な構築と反復:本番要件には、高速プロビジョニング(ウォーム時1秒未満)、再現可能な環境(すべてのインスタンスが開始するDockerイメージまたはブループリントで定義)、および永続状態(ファイル、インストールされたパッケージ、セッションコンテキストがエージェントのターン間で引き継がれる)が含まれます。実行環境の起動に30秒かかる場合、複数の環境を必要とするエージェントタスクは遅く感じられます。環境が再現可能でない場合、バグの特定が困難になります。状態がセッション間で永続化されない場合、長時間実行タスクには高価な再起動が必要になります。

マネージドサンドボックスを使用するタイミングと自作するタイミング

DIYアプローチを取ることができます。開発者のラップトップでエージェントを実行し、ある程度の分離のためにDockerコンテナにアップグレードし、リソース制限と資格情報注入を手動で配線します。固定スキーマの外部APIのみを呼び出し、動的コードを決して実行しないエージェントの場合、これで十分なことがよくあります。スクリプトの生成、パッケージのインストール、テストスイートの実行、ファイルの解析にスケールアップしたい場合は、タスクごとにVMを起動し、ランタイムに触れずに資格情報を安全に注入し、並列ブランチのスナップショットとフォークサポートを構築し、実行トレースを記録してエージェントトレースに結び付け、ティアダウン、アイドル検出、クォータ管理を処理する必要があります。決定基準:エージェントがAPIのみを呼び出し、動的コードを実行しない場合、ローカルまたはコンテナ化された実行で問題ない可能性があります。エージェントがモデル生成コードを実行したり、パッケージをインストールしたり、任意のファイルを処理したりする場合、真の分離が必要であり、ゼロから構築することはサンドボックスプラットフォームを構築することを意味します。本番エージェントデプロイメントのDIYアプローチの運用オーバーヘッドは急速に増加します。マネージドサンドボックスパスは、そのエンジニアリング面を、作業の規模を処理するプラットフォームとのよりシンプルなインターフェースと交換します。

LangSmith Sandbox:すべてのエージェントにコンピュータを

各LangSmithサンドボックスは高速に起動し(中央値1秒未満)、独自のカーネルを持つハードウェア仮想化マイクロVMとして実行され、エージェントの作業セッション全体で状態(ファイル、インストール済みパッケージ、環境)を保持します。タスクが完了すると、サンドボックスはアイドル状態になり、自動的にクリーンアップされます。コンテナはホストとカーネルを共有しますが、マイクロVMは独自のものを持っています。サンドボックス内では、エージェントは何でもインストールでき、Dockerを実行し、サービスを開始できます。その間、インフラストラクチャや他のワークロードは影響を受けません。

コアプリミティブには以下が含まれます:マイクロVM分離(各サンドボックスはカーネル分離されており、他のサンドボックスやサービスに影響を与えません)、スナップショットとフォーク(実行中のサンドボックスの状態をキャプチャするか、Dockerイメージから構築します。フォークはコピーオンライトなので、同じスナップショットから10の並列ブランチを起動するコストは1つとほぼ同じです)、認証プロキシ(サンドボックスからの送信リクエストはプロキシを通過し、ネットワーク層で資格情報を注入します。エージェントはGitHub、S3バケット、内部APIを呼び出すことができ、シークレットはランタイムに触れません)、サービスURL(サンドボックス内で実行されているものへの認証済みHTTPアクセスが得られます。ポート転送は不要です)。

ワンコールセットアップ例:

from langsmith.sandbox import SandboxClient
client = SandboxClient()
with client.sandbox() as sb:
    result = sb.run("python my_analysis.py")
    print(result.stdout)

サンドボックスはDeep Agents、Open SWE、LangSmith Deployment、LangSmith Fleet、および任意のカスタムコードと連携します。これらはLangSmithの他の部分と同じSDKとAPIキーを使用します。

サンドボックスワークフローにおけるプロンプトインジェクションに関する注意

サンドボックスは強力な実行分離を提供しますが、言語モデルの基本的な特性を変えるものではありません。エージェントが読むものはすべて、エージェントが次に何をするかに影響を与える可能性があります。これはサンドボックス出力がモデルにフィードバックされる場合に重要です。懸念の例として、リサーチエージェントがドキュメントをダウンロードし、そのドキュメントにモデルへの指示のように見えるテキストが含まれていて、モデルがそれに従う場合があります。これはLLMアプリケーションのOWASP Top 10の#1脆弱性であり、外部コンテンツを処理するエージェント(ウェブページ、アップロードされたファイル、API応答、コード実行出力など)に適用されます。

サンドボックスはインジェクションの脅威を排除しませんが、実行の爆発半径を封じ込めます。サンドボックス内で実行される悪意のあるコードはホストに到達できませんが、その実行の出力がエージェントによって精査されずに読み戻された場合、出力内の注入された命令は下流の動作に影響を与える可能性があります。

緩和方法:

  • サンドボックス出力を信頼できないデータとして扱います。モデルは、確認なしに実行出力内の命令テキストに基づいて行動すべきではありません。
  • 最も機密性の高いワークフローでは、「非エージェント読み取り」パターンを使用します。モデル以外のプロセスがサンドボックスから完成したアーティファクト(ファイル、差分、レポート)を取得し、生の出力をエージェントのコンテキストを通じてルーティングしないようにします。
  • クロスバウンダリエージェントがローカルにアクセスできるものを制限します。エージェントがローカル環境とサンドボックス環境の両方で動作する場合、最小権限を適用します。ローカルアクセス面はタスクに必要な範囲に絞ります。
  • 境界で出力フィルタリングを適用します。構造化出力スキーマ、コンテンツ分類子、または形式検証は、モデルが単独でインジェクションに抵抗することを要求せずに攻撃面を減らします。
  • モデルにインジェクションを検出または無視するように促すプロンプトに依存しないでください。敵対的研究は、これが規模において不十分であることを一貫して示しています。

これらはサンドボックスに固有のものではありません。ウェブから読み取ったり、アップロードされたファイルを処理したり、外部APIを呼び出したりするエージェントは、同じ露出を持ちます。サンドボックスの付加価値は、実行ダメージを封じ込めるのに役立つことです。両方の層が必要です。

ユースケース:コーディングエージェント

コーディングエージェントは、実行分離が重要であるため、サンドボックスの人気のあるユースケースです。テストスイートを実行し、失敗を検査し、コードにパッチを当て、テストスイートを再実行できるエージェントは、パッチを生成して開発者に検証のために返すだけのエージェントよりも質的に優れています。サンドボックス内のコーディングエージェントは、リポジトリをクローンし、npm install、pip installなどを含む完全なセットアップスクリプトを、それらのパッケージが開発者のマシンに触れることなく実行できます。現在のコード状態に対してテストスイートを実行し、失敗出力を読み、修正を試み、テストを再実行し、検証済みのパッチを提供できます。複数の並列ブランチを処理し、それぞれ独自のサンドボックスを持ち、異なるアプローチの結果を比較できます。ローカルマシンにパッケージをインストールせずに依存関係をインストールしてテストできます。

コーディングエージェントは、セキュリティ境界が直接開発者の信頼に変換されるため、サンドボックスが活躍する典型的な例です。エージェントが環境を損なわないと信じれば、エージェントに自律的に実行させる可能性が高くなります。