LangSmith のサンドボックス機能が一般提供開始
LangChain が、不信任コードの実行に耐えうるハードウェア仮想化マイクロVMベースの「LangSmith Sandboxes」を一般提供開始し、エージェント開発におけるセキュリティと実行環境の標準を強化した。
キーポイント
ハードウェアレベルの完全隔離の実現
従来のコンテナ技術を超え、マイクロVMによるカーネル分離を実現することで、モデル生成コードやサードパーティライブラリの悪意ある動作からサービスを守る堅牢な環境を提供する。
エージェント実行のセキュリティ課題への対応
Shai-Hulud 型 npm ワームやカーネル脆弱性など、コンテナベースの実行が抱えるリスクを解消し、本番環境でのコード生成・実行ワークフローを安全に運用可能にする。
包括的な実行プラットフォームの提供
スナップショット、コピーオンライトフォーク、ブループリント、CLI、認証プロキシなどの新機能を実装し、エージェント開発ライフサイクル全体をサポートする基盤となる。
重要な引用
Each sandbox runs as a hardware-virtualized microVM, fully kernel-isolated from your services and other sandboxes
Real-world supply chain attacks and kernel exploits show that running agent code in containers or eval boundaries is dangerously insufficient for production workloads.
GA ships powerful new primitives for agent workflows
影響分析・編集コメントを表示
影響分析
この発表は、生成AIエージェントが自律的にコードを実行・修正するワークフローが本番環境で普及する中で、最も懸念されるセキュリティリスク(サプライチェーン攻撃やカーネルエクスプロイト)に対する決定的な解決策を示すものである。開発者は、従来のコンテナベースの制限に縛られず、より安全かつ効率的なエージェントアプリケーションを構築できるようになる。
編集コメント
エージェントが自律的にコードを実行する時代において、セキュリティは最大のボトルネックでしたが、マイクロVM技術の採用によりこの壁を突破した画期的な発表です。開発現場での実装リスクが劇的に低下し、本番環境でのエージェント活用が加速すると予想されます。

主要なポイント
- LangSmith Sandboxes が一般提供(GA)されました。各サンドボックスはハードウェア仮想化されたマイクロ VM として実行され、サービスや他のサンドボックスから完全にカーネルレベルで隔離されています。これにより、信頼できないモデル生成コードの実行が真に安全に行え、コンテナ単体では保証できないセキュリティを実現します。
- エージェントには本格的な隔離が必要であり、「サンドボックス」機能だけでは不十分です。実際のサプライチェーン攻撃やカーネルの脆弱性(Shai-Hulud npm ワームや Copy Fail CVE など)は、エージェントコードをコンテナや評価境界内で実行することが、本番環境のワークロードに対して危険に不十分であることを示しています。
- 一般提供により、エージェントワークフローのための強力な新プリミティブが提供されました。スナップショットと低コストのコピーオンライトフォーク、事前ウォームされた環境用のブループリント、サービス URL、Sandbox CLI、Auth Proxy により、LangSmith Sandboxes は完全な実行プラットフォームとなっています。
本日、LangSmith Sandboxes が一般提供(GA)となりました。これはエージェントコードの実行向けに設計され、Deep Agents SDK および LangSmith プラットフォームと統合された、安全でスケーラブルな環境です。
各サンドボックスはハードウェア仮想化されたマイクロ VM であり、サービスや他のサンドボックスからカーネルレベルで隔離されています。Sandboxes は LangSmith の残りの部分と同じ SDK と API キーを使用し、あらゆるフレームワークやカスタムコードと連携します。
image.png)
なぜエージェントにはサンドボックスが必要なのか
過去1年間、コード実行をコアワークフローの一部として活用する新しい種類のエージェントが登場し始めました。Cursor、Claude Code、OpenSWE、Deep Agents といったシステムは、事前に定義されたツールを呼び出すだけでなく、コードの生成、依存関係のインストール、テストの実行、失敗箇所の調査、ファイルの編集を行います。
コード実行を必要とするいくつかの一般的なワークロード:
- 応答する前に自身の出力を実行して検証するコーディングアシスタント
- リポジトリのクローン作成、依存関係のインストール、テストの実行、PR(Pull Request)の作成を行う CI スタイルのエージェント(OpenSWE など)
- データセットに対して Python を実行するデータ分析エージェント
これらのエージェントには、ファイルシステム、パッケージマネージャー、シェル、永続的な状態を備えたコンピュータのような環境が必要です。また、それらが実行するコードはモデルによって生成されたものや、外部の依存関係から取得されたもの、あるいはユーザーが提供したものである可能性があるため、隔離(isolation)も必要です。
多くのチームはまずこれをノートパソコン上で実行し始めます。プロトタイプとしては機能しますが、本番環境では破綻してしまいます。
エージェントコードには強力な隔離が必要である
現実の隔離境界の外でエージェントコードを実行するリスクは理論上の話ではありません:
- サプライチェーン攻撃はランタイムにまで及ぶ可能性があります:2025 年 9 月、自己複製型の Shai-Hulud npm ワームが @ctrl/tinycolor を含む 500 以上のパッケージにバックドアを仕掛け、テスト実行前に preinstall スクリプト内で実行されました。11 月の第 2 波では、796 の追加パッケージ(週間ダウンロード数 2,000 万以上)と 25,000 以上の GitHub リポジトリが数時間で影響を受けました。
- 「サンドボックス」機能は常に安全な砂の箱とは限りません:n8n では単一の日に 6 つの RCE(リモートコード実行、Remote Code Execution)CVE が公開され、その中には JS 式サンドボックスをバイパスする CVE-2026-1470 (CVSS 9.9) や、Python タスクエグゼキュータからの脱出を可能にする CVE-2026-0863 も含まれていました。JS の eval バウンダリは隔離ではありません。
- コンテナはカーネルを共有しており、カーネルは破綻します:Copy Fail (CVE-2026-31431) は 732 バイトの Python スクリプトで、Linux カーネル暗号化 API を経由して 2017 年以降の主要な Linux ディストリビューションすべてをルート権限で乗っ取るものです。AI ツールがこれを約 1 時間で発見しました。コンテナはここでは役立ちません。なぜならホストとカーネルを共有するため、誤ったスクリプトを実行するエージェントが脱出してしまうからです。
コンテナはエージェントワークロードのために作られたものではありません。彼らは既知で審査済みのアプリケーションコードをステートレスに実行するために設計されています。例えば、固定された操作を処理して消滅する Web サーバーなどが該当します。一方、エージェントはその正反対です。パッケージのインストールやファイル編集、長時間続く作業スレッドの追跡、そして中断した場所から再開できるような「状態を持つ小さなコンピュータ」を望みます。また、彼らが実行するコードは定義上信頼できません。LangSmith Sandboxes はそのような実行モデルのために構築されています。
LangSmith Sandboxes
LangSmith Sandboxes は、インフラストラクチャにリスクを負わせることなく、エージェントが利用可能なコンピュータのような環境を提供します。各サンドボックスは、独自のファイルシステム、シェル、パッケージマネージャ、およびネットワーク境界を持つ一時的なマイクロ VM として実行されます。エージェントはコードの記述、依存関係のインストール、テストの実行を行い、長時間実行されるセッションにわたって作業を継続できますが、サンドボックスはお客様のサービスや他のサンドボックスから隔離された状態を保ちます。
これらは、チームがすでに使用している同じ LangSmith SDK および API キーを通じて管理されるため、ランタイム層を自ら構築することなく、セキュアなコード実行をエージェントワークフローに統合できます。Sandboxes は Deep Agents、Open SWE、LangSmith Deployment、LangSmith Fleet、およびカスタムコードと連携します。また、認証情報、リソース制限、ライフサイクル、アクセスに関するチームが必要とする生産環境向けの制御機能も含まれており、GA(一般提供)により並列ワークロード、スナップショット作成、エンタープライズセキュリティの新たな機能が追加されました。
image.png)
GA リリースに伴う新機能
- スナップショットと低コストフォーク:実行中のサンドボックスをキャプチャするか、Docker イメージから構築して、そこから新しいサンドブックスを起動できます。フォークはコピーオンライト方式で状態を共有するため、10 本の並列ブランチを立ち上げても、1 つのブランチを起動するコストとほぼ同じです。エージェントが間違った道に進んだ場合でも、復元して別のブランチを試すことができます。
- 非アクティブ時に一時停止:アイドル状態のサンドボックスは自動的に一時停止するため、何もしていないリソースに対して課金されることはありません。
- サービス URL: サンドボックス内で実行されているあらゆるものへの認証済み HTTP アクセス。ブラウザでサンドボックスホスト型のプレビューを開いたり、スクリプトからアクセスしたり、チームメンバーと URL を共有したりできます。ポート転送は不要です。
- サンドボックス CLI:Dockerfile からスナップショットを構築し、サンドボックスを管理し、対話型コンソールを開き、生 TCP をトンネリングし、ssh、scp、rsync、sftp などの標準ツールを使用して、Linux サーバーと同様にサンドボックスを操作できます。
- デフォルトでクリエイター専用:サンドボックスにはクリエイター固有の認証が付属しており、サンドボックスを起動したユーザー(およびワークスペース管理者)のみがシェルに接続したり、サービス URL にアクセスしたりできます。共有する準備ができたら、他のワークスペースメンバーへのアクセス権限を付与してください。
- カスタムコールバック付き認証プロキシ:サンドボックスからのアウトバウンドリクエストは、ネットワーク層で資格情報を注入するプロキシを経由して流れるため、機密情報がランタイムに直接接触することはありません。GA で新機能として追加されたのは、高度なセットアップ向けにカスタムのシークレット解決をプラグインできるコールバックです(テナントごとのトークン、バault 参照、監査フックなど)。また、ドメインのホワイトリスト/ブラックリストを設定して、アクセス境界を制御することも可能です。
チームがサンドボックスをどのように活用しているか
サンドボックスはすでに、質問に答えるだけのエージェントから、安全に作業を実行できるエージェントへとチームを移行させる手助けをしています。monday.com においては、これは Sidekick に高度なユーザーワークフローのためにコードを書き実行するための安全な環境を与えることを意味します。
*LangSmith のサンドボックスは、AI アシスタントである Sidekick を *monday.com* ユーザー向けにさらに能力の高いものにするのに役立っています。安全な環境により、Sidekick はコードを書き実行し、その結果を活用して、データ分析の実行やマルチメディアの生成など、より豊かなワークフローを構築できます。*- Omri Bruchim, AI Platform Group Manager, monday.com
今後の予定
- ローカルからクラウドへエージェントを開発。ラップトップ上のサンドボックスに対してエージェントを開発し、コード変更なしで同じエージェントをクラウドホスト型のサンドボックスにプロモートします。
- 共有ボリュームにより、エージェント間の協働が可能に。エージェント 1 がボリュームに書き込み、その後エージェント 2 がその続きから作業を開始します。
- ボリュームマウント。起動時に即座にアクセスできるよう、独自の blob ストレージや git リポジトリをマウントできます。
- VM 内のすべてのプロセスおよびネットワーク呼び出しの完全な実行追跡。これは監査ログとしても機能します。
ワークフローにおいて最も重要なことを共有するために、Slack コミュニティ にご参加ください。
関連コンテンツ

LangSmith
LangSmith Engine の紹介

Ben Tannyhill
2026 年 5 月 13 日
5 分

LangSmith
エージェントの観測(Observability)のためのデータレイヤー、SmithDB を構築しました

Ankush Gola
2026 年 5 月 13 日
11 分

LangSmith
LangSmith Context Hub のご紹介

Harrison Chase
2026 年 5 月 13 日
8 分
エージェントが実際に何をしているかを確認する
エージェントエンジニアリングプラットフォームである LangSmith は、開発者がすべてのエージェントの意思決定をデバッグし、評価(Eval)の変更を検証し、ワンクリックでデプロイできるように支援します。
原文を表示

Key Takeaways
- LangSmith Sandboxes are now GA — Each sandbox runs as a hardware-virtualized microVM, fully kernel-isolated from your services and other sandboxes, making them genuinely secure for running untrusted, model-generated code, something containers alone can't guarantee.
- Agents need real isolation, not just "sandbox" features — Real-world supply chain attacks and kernel exploits (like the Shai-Hulud npm worm and Copy Fail CVE) show that running agent code in containers or eval boundaries is dangerously insufficient for production workloads.
- GA ships powerful new primitives for agent workflows — Snapshots and cheap copy-on-write forks, Blueprints for pre-warmed environments, Service URLs, a Sandbox CLI, and an Auth Proxy make LangSmith Sandboxes a full execution platform.
Today, LangSmith Sandboxes are Generally Available: secure, scalable environments built for agent code execution, and integrated with the Deep Agents SDK and the LangSmith platform.
Each sandbox is a hardware-virtualized microVM, kernel-isolated from your services and from other sandboxes. Sandboxes use the same SDK and API key as the rest of LangSmith and work with any framework or custom code.
.png)
Why do agents need sandboxes?
Over the past year, a new class of agents has started to use code execution as part of their core workflow. Systems like Cursor, Claude Code, OpenSWE, and Deep Agents don’t just call predefined tools. They generate code, install dependencies, run tests, inspect failures, and edit files.
A few common workloads that need code execution:
- A coding assistant that runs and validates its own output before responding
- A CI-style agent that clones a repo, installs deps, runs tests, and opens a PR (like OpenSWE)
- A data analysis agent that runs Python against a dataset
These agents need a computer-like environment with a filesystem, package manager, shell, and persistent state. They also need isolation, because the code they run may be generated by a model, pulled from an external dependency, or supplied by a user.
Most teams start by running this on a laptop. That works for a prototype, but it breaks down in production.
Agent code needs strong isolation
The risks of running agent code outside a real isolation boundary aren't theoretical:
- Supply-chain attacks can reach into your runtime: In September 2025, the self-replicating Shai-Hulud npm worm backdoored 500+ packages including @ctrl/tinycolor, executing in preinstall before any tests ran. A second wave in November hit 796 more packages (20M+ weekly downloads) and 25,000+ GitHub repos in hours.
- "Sandbox" features aren't always sandboxes: n8n had six RCE CVEs disclosed in a single day, including CVE-2026-1470 (CVSS 9.9) bypassing the JS expression sandbox and CVE-2026-0863 breaking out of the Python task executor. A JS eval boundary is not isolation.
- Containers share a kernel, and kernels break: 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 surfaced it in about an hour. Containers can't help here because they share a kernel with the host, so an agent running the wrong script escapes.
Containers weren’t built for agent workloads. They’re designed to run known, vetted application code statelessly, such as a web server that handles fixed operations and disappears. Agents are the opposite. They want stateful little computers where they can install packages, edit files, follow long-running threads of work, and come back to where they left off. And the code they run is untrusted by definition. LangSmith Sandboxes are built for that execution model.
LangSmith Sandboxes
LangSmith Sandboxes give agents a computer-like environment they can use without putting your infrastructure at risk. Each sandbox runs as an ephemeral microVM with its own filesystem, shell, package manager, and network boundary. Agents can write code, install dependencies, run tests, and keep working across long-running sessions, while the sandbox stays isolated from your services and from other sandboxes.
They’re managed through the same LangSmith SDK and API key teams already use, so you can attach secure code execution to an agent workflow without building the runtime layer yourself. Sandboxes work with Deep Agents, Open SWE, LangSmith Deployment, LangSmith Fleet, and custom code. They also include the production controls teams need around credentials, resource limits, lifecycle, and access, with GA adding new capabilities for parallel workloads, snapshotting, and enterprise security.
.png)
New features with the GA release
- Snapshots and cheap forks: Capture a running sandbox, or build one from a Docker image, then boot new sandboxes from it. Forks share state via copy-on-write, so spinning up ten parallel branches costs about the same as one. When your agent goes down a wrong path, you can restore and try a different branch.
- Pause when inactive: Idle sandboxes pause automatically, so you don’t pay for resources that are doing anything.
- Service URLs: Authenticated HTTP access to anything running inside a sandbox. Open a sandbox-hosted preview in a browser, hit it from a script, or share the URL with a teammate. No port forwarding needed.
- Sandbox CLI: Build snapshots from Dockerfiles, manage sandboxes, open interactive consoles, tunnel raw TCP, and use standard tools (ssh, scp, rsync, sftp) against a sandbox like any Linux box.
- Creator-private by default: Sandboxes ship with creator-specific auth, so only the user who launched a sandbox (and workspace admins) can shell into it or open its Service URLs. Grant access to other workspace members when you are ready to share.
- Auth Proxy with custom callbacks: Outbound requests from a sandbox flow through a proxy that injects credentials at the network layer, so secrets never touch the runtime. New in GA: callbacks let you plug in custom secret resolution for advanced setups (per-tenant tokens, vault lookups, audit hooks). Also allowlist/denylist domains to control your access boundary.
How teams are using Sandboxes
Sandboxes are already helping teams move from agents that answer questions to agents that can do work safely. At monday.com, that means giving Sidekick a secure environment to write and run code for more advanced user workflows.
LangSmith Sandboxes are helping us make our Sidekick, our AI assistant, 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
What's Coming Next
- Local-to-cloud agents. Develop an agent against a sandbox on your laptop, then promote the same agent to a cloud-hosted sandbox with no code changes.
- Shared volumes so agents can collaborate. Agent 1 writes to a volume, then Agent 2 picks up where it left off.
- Volume Mounts. Mount your own blob storage or git repository for instant access on startup.
- Full execution tracing of every process and network call inside the VM, doubling as an audit log.
Join our Slack community to share what matters most for your workflows.
Related content

LangSmith
Introducing LangSmith Engine

Ben Tannyhill
May 13, 2026
5
min

LangSmith
We built SmithDB, the data layer for agent observability

Ankush Gola
May 13, 2026
11
min

LangSmith
Introducing LangSmith Context Hub

Harrison Chase
May 13, 2026
8
min
See what your agent is really doing
LangSmith, our agent engineering platform, helps developers debug every agent decision, eval changes, and deploy in one click.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み