AI エージェントに専用コンピューターを提供（7 分読了）
LangSmith は、AI エージェントが安全かつ効率的にコードを実行し、複雑なタスクを完遂するために必要不可欠な「個別のコンピューター（サンドボックス）」インフラを提供するソリューションであると主張している。
キーポイント
エージェント実行環境の必要性
LLM の推論能力だけでは実務が完了せず、ファイルシステムやシェルへのアクセスを備えた独立したコンピューター環境（サンドボックス）が必要である。
ローカル実行の限界とリスク
エージェントは本質的に信頼できないコードを実行するため、開発者のローカルマシンや単一のコンテナに直接アクセスさせるのはセキュリティ上の重大なリスクとなる。
具体的なユースケースの拡大
コーディングアシスタントによる自動修正、データ分析レポート作成、CI/CD 自動化、研究エージェント、コンテンツパイプラインなど、実行環境を持つことで実現可能なタスクが劇的に増加する。
スケーラブルなインフラシフト
サティア・ナデラ氏の指摘通り、数百万のタスクを処理するにはゼロから数千のスandbox を瞬時に生成・破棄できる動的なインフラアーキテクチャへの転換が不可欠である。
影響分析・編集コメントを表示
影響分析
この記事は、AI エージェントが単なるチャットボットから自律的な作業実行者へと進化するための決定的なインフラ要件を明確に示しています。特に「信頼できないコード」を実行する際のセキュリティリスクと、大規模タスク処理におけるスケーラビリティの課題に対し、専用サンドボックス環境という解決策を提示することで、業界全体のアーキテクチャ設計に影響を与える可能性があります。
編集コメント
AI エージェントの実用化において、セキュリティとスケーラビリティを担保する「個別のコンピューター」概念は、今後数年間のインフラ設計における最重要課題の一つとなるでしょう。
LLM は推論できます。しかし、推論だけでは多くの成果は得られません。
AI エージェントでのコード実行は、見た目よりも難しいものです。エージェントには実際のコンピュータ（ファイルシステム、シェル、パッケージマネージャー、永続的な状態）が必要ですが、インフラストラクチャへのアクセス権を渡すのは危険です。
こう考えてみてください：あなたは 1 台のラップトップを使っています。あなた自身もまた 1 人です。しかし、エージェントは数百万ものタスクを実行することになり、それぞれのタスクが動作するために独自のコンピュータが必要です。まさに今、このインフラストラクチャの転換が起こっています。サティア・ナデラ氏は率直にこう述べています。「すべてのエージェントにはコンピュータが必要だ」。問題は、そのコンピュータがどのようなものであり、どのように安全に提供するかです。
LangSmith Sandboxes がそれに対する私たちの答えです。なぜそれが重要なのか、また自分で実装しようとするのが聞こえるほど難しいのかについて説明します。
エージェントにコンピュータがあることで可能になること
Cursor や Claude Code、ChatGPT のコードインタープリタが、単なるチャットインターフェースではできないことを考えてみてください。それらは単に質問に答えるだけでなく、コードを実行し、エラーを確認し、修正し、再度実行して、動作するものを提供します。このフィードバックループこそが、それらを有用にする理由です。
同じループが、デモ用エージェントと本番環境向けエージェントを分けるものです。あなたのエージェントが実行できるようになると、新しいカテゴリの作業が可能になります：
- 単に修正を提案するだけでなく、実際に修正を適用し、テストを実行して何も壊れていないことを確認するコーディングアシスタント
- CSV を取得し、Python で処理してフォーマットされたレポートを手渡すデータアナリスト
- リポジトリをクローンし、依存関係をインストールし、完全なテストスイートを実行し、PR を作成する CI エージェント（OpenSWE のようなもの）
- 検索だけでなく、閲覧・スクレイピング・統合・執筆を行うリサーチエージェント
- 生成・レンダリング・エクスポートして完成した成果物を生み出すコンテンツパイプライン
- パラレルで環境を起動し、バーストスケールでエピソードを実行し、即座にシャットダウンする必要がある RL や評価ハーン。ゼロから数千のサンドボックスへ、そして再びゼロへ。
共通している点：これらのエージェントにはトークンストリーム以上のものが必要です。彼らには作業するための場所が必要なのです。
なぜ単にエージェントにあなたのラップトップを渡してはいけないのか
当然次の疑問は生じます：なぜエージェントにローカルでコードを実行させたり、Docker コンテナ内で実行させたりしないのか？チームは初期のプロトタイプではこれを行いますが、本番環境では以下の 2 つの理由で機能しなくなります。
第一に：エージェントは定義上、信頼できないコードを実行します。
エージェントが実行するコードは、モデルから生成されたもの、ユーザーからのプロンプト、クローンされたリポジトリ、あるいはインストールされたパッケージから来る可能性があります。あなたが書いたものではなく、完全に検証することもできません。2025 年 9 月には、Shai-Hulud という自己複製型の npm ワームが 500 以上のパッケージにバックドアを仕掛け、事前検証が実行される前に preinstall スクリプト内でコードを実行しました。11 月の第 2 波では、数時間以内にさらに 796 のパッケージと 25,000 件以上の GitHub リポジトリが被害を受けました。ワークフローの一部として npm パッケージをインストールするエージェントは、まさにこのリスクに晒されています。
第二に、コンテナだけでは不十分です。
一般的な直感は「Docker で実行すればいい」というものです。コンテナは、既知で検証済みのアプリケーションコード（つまり Web サーバーやバックグラウンドジョブなど）を隔離するには優れた手段です。しかし、任意の依存関係をインストールし、モデル生成スクリプトを実行し、長時間稼働するセッションにわたって状態を保持するエージェントのために設計されたものではありません。そして何より重要なのは、コンテナはホストとカーネルを共有している点です。カーネルの脆弱性を突けば、コンテナの境界を容易に突破できます。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 では、Sandboxes が Sidekick AI アシスタントの基盤となっており、データ分析やマルチメディア生成を含む高度なユーザーワークフローのためにコードを書き実行するための安全な環境を提供しています。
*"LangSmith の Sandboxes は、monday.com ユーザー向けに Sidekick の能力を大幅に向上させるのに役立っています。安全な環境により、Sidekick はコードの作成と実行が可能となり、その結果を活用してデータ分析の実行やマルチメディアの生成など、よりリッチなワークフローを作成できます。"*
— Omri Bruchim, AI Platform Group Manager, monday.com
注目に値する転換点
ここ数年、エージェントの能力を高めることは、より優れたツールを与えることと同義でした：検索 API、電卓、データベース接続など。これは依然として真実です。しかし、事前に定義されたツールが達成できることの上限は低いです。
実際にワークフローを代替する（単に支援するだけでなく！）のは、必要なあらゆるツールを選択し、実行し、結果を確認し、適応できるエージェントです。それがコンピューターを持つことで可能になることです。これはインフラの詳細ではありません。*思考*できるエージェントと*行動*できるエージェントとの違いなのです。
あなたが 1 台のラップトップを使っているなら、あなたの各エージェントもそれぞれ 1 台必要になります。LangSmith Sandboxes は、それらに与えるための手段です。
始め方： LangSmith Sandboxes を試す または ドキュメントを読む。
原文を表示
LLMs can reason. But reasoning alone doesn't get much done.
Running code execution in an AI agent is harder than it looks. Your agent needs a real computer (filesystem, shell, package manager, persistent state) but handing it access to your infrastructure is dangerous.
Think about it this way: you use one laptop. You are n of one. But agents are going to run millions of tasks, and each one needs its own computer to work from. That's the infrastructure shift happening right now. Satya Nadella put it plainly: "Every agent needs a computer." The question is what that computer looks like, and how you give it to them safely.
LangSmith Sandboxes are our answer to that. Here's why it matters, and why doing it yourself is harder than it sounds.
What becomes possible when an agent has a computer
Think about what Cursor, Claude Code, or ChatGPT's code interpreter can do that a plain chat interface can't. They don't just answer questions: they run the code, see the error, fix it, run it again, and hand you something that works. That feedback loop is what makes them useful.
That same loop is what separates a demo agent from a production agent. Once your agent can execute, a whole category of work opens up:
- A coding assistant that doesn't just suggest a fix: it applies the fix, runs your tests, and confirms nothing broke
- A data analyst that pulls a CSV, runs Python against it, and hands you a formatted report
- A CI agent that clones your repo, installs dependencies, runs the full test suite, and opens a PR (like OpenSWE)
- A research agent that browses, scrapes, synthesizes, and writes — not just searches
- A content pipeline that generates, renders, and exports finished artifacts
- An RL or eval harness that needs to spin up environments in parallel, run episodes at burst scale, and tear them down immediately — zero to thousands of sandboxes, then back to zero
The common thread: these agents need more than a token stream. They need a place to *work*.
Why you can't just hand your agent your laptop
The obvious next question is: why not just let the agent run code locally? Or in a Docker container? Teams do this in early prototypes. It stops working in production for two reasons.
First: agents run untrusted code by definition.
The code your agent executes might come from a model, a user prompt, a cloned repo, or an installed package. You didn't write it. You can't fully vet it. In September 2025, a self-replicating npm worm called Shai-Hulud backdoored 500+ packages — code that executed in preinstall before any validation could run. A second wave in November hit 796 more packages and 25,000+ GitHub repos in hours. An agent that installs npm packages as part of its workflow is exposed to exactly this.
Second: containers aren't enough.
The common instinct is "just run it in Docker." Containers are great for isolating known, vetted application code (i.e. a web server, a background job). They're not designed for an agent that's installing arbitrary dependencies, running model-generated scripts, and persisting state across a long-running session. And critically: containers share a kernel with the host. A kernel exploit reaches through them. Copy Fail (CVE-2026-31431) is a 732-byte Python script that roots every major Linux distribution back to 2017 via the kernel crypto API. *AI tooling found it in about an hour.*
A container boundary is not an isolation boundary. For untrusted, model-generated code, you need hardware-level separation.
LangSmith Sandboxes: a computer for every agent
The mental model that helps here: a sandbox needs to be two things at once. It needs the instant startup of a serverless function because you can't make an agent wait two minutes for a VM to boot. And it needs the statefulness of a full machine because agents aren't stateless request-handlers; they're mid-session workers that install dependencies, edit files, and pick up where they left off.
LangSmith Sandboxes are built for that model. Each one is a hardware-virtualized microVM. Not a container, a full machine with its own kernel. The agent gets:
Agent
└── its own computer
├── filesystem
├── shell
├── package manager
├── network access
├── code execution
└── persistent state
It can install packages, run scripts, edit files, spin up a local server, and keep working across a long session — all without touching your production infrastructure or any other agent's sandbox. When the work is done, the sandbox disappears.
You access it through the same LangSmith SDK and API key you already use:
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)
It just takes one call, and your agent has a computer.
There's also a less obvious benefit for teams running GPU workloads: when your sandbox spins up instantly, your GPU doesn't idle waiting for CPU compute to provision. Fast sandboxes are a GPU efficiency multiplier — a detail that compounds quickly at scale.
What you get beyond basic execution
A sandbox is more than a place to run code. The GA release ships a set of primitives that make agent workflows production-ready:
Snapshots and forks: Capture a sandbox mid-session and boot new ones from it. Forks use copy-on-write, so spinning up ten parallel branches costs roughly the same as one. When your agent goes down the wrong path, restore and try again, without rebuilding from scratch.
Blueprints for pre-warmed environments: Define a base image (your repo cloned, your deps installed, your config in place) and boot sandboxes from it in seconds instead of minutes.
Service URLs: If the agent starts a local web server — say, to preview a generated report — you get an authenticated URL you can open in a browser or share with a teammate. No port forwarding.
Auth proxy: Outbound requests from the sandbox flow through a proxy that injects credentials at the network layer. Secrets never touch the agent runtime.
Creator-private by default: Only the user who launched a sandbox (and workspace admins) can access it. Share when you're ready.
When to reach for Sandboxes
Sandboxes are the right layer when your agent needs to *do* something, not just *say* something. Concretely:
- Your agent generates code and you want it to verify that code runs before responding
- You're building a coding assistant, CI agent, or data pipeline that operates on real files
- You're running multi-step workflows where state needs to persist across tool calls
- You need burst capacity (i.e. thousands of parallel environments for RL training or evals) that has to scale from zero in seconds
- You're accepting any user-supplied input that could end up being executed
Sandboxes are overkill if your agent only calls APIs with fixed schemas and never executes dynamic code. A retrieval agent that searches docs and returns citations doesn't need one. An agent that writes and runs a Python script does.
How teams are using this today
At monday.com, Sandboxes power their Sidekick AI assistant, giving it a secure environment to write and run code for advanced user workflows, including data analysis and multimedia generation.
"LangSmith Sandboxes are helping us make our Sidekick much more capable for monday.com users. With secure environments, Sidekick can write and run code, and use the results to create richer workflows, like running data analysis and generating multimedia."
— Omri Bruchim, AI Platform Group Manager, monday.com
The shift worth paying attention to
For the last few years, making an agent more capable meant giving it better tools: a search API, a calculator, a database connector. That's still true. But the ceiling on what predefined tools can do is low.
The agents that will actually replace workflows (not just assist with them!) are the ones that can pick up whatever tool they need, run it, see what happened, and adapt. That's what having a computer makes possible. It's not an infrastructure detail. It's the difference between an agent that can *think* and an agent that can *act*.
You use one laptop. Your agents will each need their own. LangSmith Sandboxes are how you give them one.
Get started: Try LangSmith Sandboxes or read the docs.
関連記事
エージェントシステムにおける意図と実行の架橋
Amazon Science は、AI エージェントのパフォーマンスはモデル自体の問題ではなく、LLM とツール間の仲介役となるハッチ（OS）の設計がボトルネックであると指摘し、意図を実行に移すシステムの重要性を強調した。
マイクロソフト、Frontier ユーザー向けに Scout AI エージェントを本格展開
マイクロソフトは、Microsoft 365 の自動化を強化する常時稼働型エージェント「Scout」を Frontier プログラムのユーザーへ提供を開始した。同エージェントは多段階ルーチンの実行やローカルファイルとの連携、OpenAI や Anthropic モデルのサポート機能を備えている。
AI エージェントに専用コンピューターを付与する
LangChain は、数百万のタスクを実行する AI エージェントが安全かつ効率的に動作するために、各エージェントに個別のファイルシステムやシェル環境を持つ仮想コンピューターを提供するインフラシフトの必要性を提唱している。
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み