Give your agent its own computer (7 minute read)｜AI エージェントに専用コンピューターを提供（7 分読了） | AIニュース最前線

LLM は推論できます。しかし、推論だけでは多くの成果は得られません。 AI エージェントでのコード実行は、見た目よりも難しいものです。エージェントには実際のコンピュータ（ファイルシステム、シェル、パッケージマネージャー、永続的な状態）が必要ですが、インフラストラクチャへのアクセス権を渡すのは危険です。 こう考えてみてください：あなたは 1 台のラップトップを使っています。あなた自身もまた 1 人です。しかし、エージェントは数百万ものタスクを実行することになり、それぞれのタスクが動作するために独自のコンピュータが必要です。まさに今、このインフラストラクチャの転換が起こっています。サティア・ナデラ氏は率直にこう述べています。「すべてのエージェントにはコンピュータが必要だ」。問題は、そのコンピュータがどのようなものであり、どのように安全に提供するかです。 LangSmith Sandboxes がそれに対する私たちの答えです。なぜそれが重要なのか、また自分で実装しようとするのが聞こえるほど難しいのかについて説明します。 ## エージェントにコンピュータがあることで可能になること Cursor や Claude Code、ChatGPT のコードインタープリタが、単なるチャットインターフェースではできないことを考えてみてください。それらは単に質問に答えるだけでなく、コードを実行し、エラーを確認し、修正し、再度実行して、動作するものを提供します。このフィードバックループこそが、それらを有用にする理由です。 同じループが、デモ用エージェントと本番環境向けエージェントを分けるものです。あなたのエージェントが実行できるようになると、新しいカテゴリの作業が可能になります： - 単に修正を提案するだけでなく、実際に修正を適用し、テストを実行して何も壊れていないことを確認するコーディングアシスタント - CSV を取得し、Python で処理してフォーマットされたレポートを手渡すデータアナリスト - リポジトリをクローンし、依存関係をインストールし、完全なテストスイートを実行し、PR を作成する CI エージェント（OpenSWE のようなもの） - 検索だけでなく、閲覧・スクレイピング・統合・執筆を行うリサーチエージェント - 生成・レンダリング・エクスポートして完成した成果物を生み出すコンテンツパイプライン - パラレルで環境を起動し、バーストスケールでエピソードを実行し、即座にシャットダウンする必要がある RL や評価ハーン。ゼロから数千のサンドボックスへ、そして再びゼロへ。 共通している点：これらのエージェントにはトークンストリーム以上のものが必要です。彼らには作業するための場所が必要なのです。 ## なぜ単にエージェントにあなたのラップトップを渡してはいけないのか 当然次の疑問は生じます：なぜエージェントにローカルでコードを実行させたり、Docker コンテナ内で実行させたりしないのか？チームは初期のプロトタイプではこれを行いますが、本番環境では以下の 2 つの理由で機能しなくなります。 **第一に：エージェントは定義上、信頼できないコードを実行します。** エージェントが実行するコードは、モデルから生成されたもの、ユーザーからのプロンプト、クローンされたリポジトリ、あるいはインストールされたパッケージから来る可能性があります。あなたが書いたものではなく、完全に検証することもできません。2025 年 9 月には、[Shai-Hulud](https://unit42.paloaltonetworks.com/npm-supply-chain-attack/) という自己複製型の npm ワームが 500 以上のパッケージにバックドアを仕掛け、事前検証が実行される前に preinstall スクリプト内でコードを実行しました。11 月の第 2 波では、数時間以内にさらに 796 のパッケージと 25,000 件以上の GitHub リポジトリが被害を受けました。ワークフローの一部として npm パッケージをインストールするエージェントは、まさにこのリスクに晒されています。 **第二に、コンテナだけでは不十分です。** 一般的な直感は「Docker で実行すればいい」というものです。コンテナは、既知で検証済みのアプリケーションコード（つまり Web サーバーやバックグラウンドジョブなど）を隔離するには優れた手段です。しかし、任意の依存関係をインストールし、モデル生成スクリプトを実行し、長時間稼働するセッションにわたって状態を保持するエージェントのために設計されたものではありません。そして何より重要なのは、コンテナはホストとカーネルを共有している点です。カーネルの脆弱性を突けば、コンテナの境界を容易に突破できます。[Copy Fail (CVE-2026-31431)](https://www.bugcrowd.com/blog/what-we-know-about-copy-fail-cve-2026-31431/) は 732 バイトの Python スクリプトで、カーネル暗号化 API を経由して 2017 年以降の主要な Linux ディストリビューションすべてをルート権限で乗っ取るものです。*AI ツールは約 1 時間でこれを発見しました。 コンテナの境界は隔離の境界ではありません。信頼できないモデル生成コードに対して必要なのは、ハードウェアレベルでの分離です。 ## LangSmith Sandboxes: a computer for every agent この場面で役立つメンタルモデル：サンドボックスは同時に二つの要件を満たす必要があります。サーバーレス関数のような即座の起動が必要なのは、エージェントが仮想マシンの起動に 2 分も待たせるわけにはいかないからです。また、フルマシンのような状態保持性（statefulness）も必要です。なぜなら、エージェントは無状態のリクエストハンドラーではなく、依存関係のインストールやファイル編集を行い、中断した場所から作業を再開するセッション中のワーカーだからです。 LangSmith Sandboxes はこのモデルのために構築されています。それぞれがハードウェア仮想化されたマイクロ VM です。コンテナではなく、独自のカーネルを持つ完全なマシンです。エージェントには以下が提供されます： Agent └── its own computer ├── filesystem ├── shell ├── package manager ├── network access ├── code execution └── persistent state パッケージのインストール、スクリプトの実行、ファイルの編集、ローカルサーバーの起動が可能で、長いセッションにわたって作業を継続できます。これらはすべて、あなたの本番インフラや他のエージェントのサンドボックスに触れることなく実行されます。作業が完了すると、サンドボックスは消去されます。 アクセスには、すでに使用している LangSmith SDK と API キーを使用します： from langsmith import Client client = Client() sandbox = client.create_sandbox() # Give the agent a shell result = sandbox.run("pip install pandas && python analysis.py") print(result.stdout) たった 1 つの呼び出しで、エージェントにコンピュータが与えられます。 GPU ワークロードを実行するチームにとって、もう一つの目に見えない利点があります。サンドボックスが瞬時に起動すれば、GPU が CPU 計算リソースのプロビジョニングを待ってアイドル状態になることがありません。高速なサンドボックスは GPU の効率性を高める乗数であり、これはスケールするにつれて急速に蓄積される重要な詳細です。 ## 基本実行を超えて得られるもの サンドボックスは単なるコード実行の場所ではありません。一般提供（GA）リリースでは、エージェントワークフローを実運用レベルに引き上げるための一連のプリミティブが用意されています： **スナップショットとフォーク：** セッションの途中でのサンドボックスをキャプチャし、そこから新しいインスタンスを起動できます。フォークは「コピーオンライト」方式を採用しているため、10 の並列ブランチを起動してもコストは 1 つの場合とほぼ同等です。エージェントが間違った道を進んだ場合でも、最初から再構築することなく復元して再度試行できます。 **事前ウォームされた環境用のブループリント：** ベースイメージ（リポジトリのクローン済み、依存関係のインストール済み、設定ファイルの配置済み）を定義し、数分ではなく数秒でそこからサンドボックスを起動できます。 **サービス URL：** エージェントがローカル Web サーバーを開始する場合（例えば、生成されたレポートをプレビューするため）、ブラウザで開いたりチームメンバーと共有したりできる認証済みの URL が提供されます。ポート転送は不要です。 **Auth プロキシ：** サンドボックスからのアウトバウンドリクエストは、ネットワーク層で資格情報を注入するプロキシを経由して流れます。シークレットがエージェントランタイムに直接触れることはありません。 **デフォルトでは作成者専用：** サンドボックスを起動したユーザー（およびワークスペース管理者）のみがアクセスできます。必要な時に共有してください。 ## Sandboxes を使うべきタイミング Sandboxes は、エージェントが単に「言う」だけでなく実際に「何かをする」必要がある場合に適切なレイヤーです。具体的には以下のケースです： - エージェントがコードを生成し、応答する前にそのコードが実行されることを確認したい場合 - 実際のファイルに対して動作するコーディングアシスタント、CI エージェント、またはデータパイプラインを構築している場合 - ツール呼び出し間で状態を維持する必要がある多段階ワークフローを実行している場合 - RL（強化学習）トレーニングや評価のために数秒でゼロから数千の並列環境までスケールできるバースト容量が必要である場合 - 実行される可能性のあるあらゆるユーザー入力を受け入れる場合 エージェントが固定されたスキーマを持つ API のみを呼び出し、動的なコードを一度も実行しない場合は、Sandboxes は過剰です。ドキュメントを検索して引用を返すだけの検索用エージェントに Sandboxes は不要ですが、Python スクリプトを書いて実行するエージェントには必要です。 ## 現在のチームでの活用事例 [monday.com](http://monday.com/) では、Sandboxes が Sidekick AI アシスタントの基盤となっており、データ分析やマルチメディア生成を含む高度なユーザーワークフローのためにコードを書き実行するための安全な環境を提供しています。 ***"LangSmith の Sandboxes は、monday.com ユーザー向けに Sidekick の能力を大幅に向上させるのに役立っています。安全な環境により、Sidekick はコードの作成と実行が可能となり、その結果を活用してデータ分析の実行やマルチメディアの生成など、よりリッチなワークフローを作成できます。"*** — Omri Bruchim, AI Platform Group Manager, monday.com ## 注目に値する転換点 ここ数年、エージェントの能力を高めることは、より優れたツールを与えることと同義でした：検索 API、電卓、データベース接続など。これは依然として真実です。しかし、事前に定義されたツールが達成できることの上限は低いです。 実際にワークフローを代替する（単に支援するだけでなく！）のは、必要なあらゆるツールを選択し、実行し、結果を確認し、適応できるエージェントです。それがコンピューターを持つことで可能になることです。これはインフラの詳細ではありません。*思考*できるエージェントと*行動*できるエージェントとの違いなのです。 あなたが 1 台のラップトップを使っているなら、あなたの各エージェントもそれぞれ 1 台必要になります。LangSmith Sandboxes は、それらに与えるための手段です。 **始め方：** [LangSmith Sandboxes を試す](https://smith.langchain.com/) または [ドキュメントを読む](https://docs.langchain.com/langsmith/sandboxes)。

AI エージェントに専用コンピューターを提供（7 分読了）

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト