AIエージェントを隔離環境で動かす企業が知っておきたいOSS「Sandcastle」の使いどころ

「コードを書くAIエージェントに、席を外している間も作業を進めさせたい。でも、開発者の端末で好き放題に動かれるのは怖い」「複数のエージェントを同時に走らせたら、誰がどの変更をしたのか追えなくなりそうだ」——AIによる開発を本格的に試し始めた企業の、開発責任者や情報システム担当者から出てくる声です。こうした不安への答えとして「隔離環境に閉じ込めれば安心」と考えがちですが、それだけでは足りません。本当は、どこまで隔離し、何を持ち込ませ、どの変更を人が受け入れるかを先に決めることが守りの中心です。この記事では、AIエージェントをコンテナなどの隔離環境で動かすOSS「Sandcastle」について、一次情報で確かめられる仕組みと、企業が使うときに注意したい既定の設定、人が決めておくべき範囲を整理します。導入や操作の手順は扱いません。

Sandcastleとは何か。2026年10月時点で確かめられる事実

Sandcastle は、GitHub上で公開されている TypeScript の部品（ライブラリー）です。READMEによると、コードを書くAIエージェントを隔離された環境（サンドボックス）の中で動かし、その作業を取りまとめるためのものです。一つの呼び出しでエージェントを起動し、隔離環境の用意と作業用の枝（ブランチ、つまりコードの変更履歴の分かれ道）の扱いを Sandcastle が受け持ち、エージェントが残した変更の記録を元の枝へ戻す、という流れが説明されています。

公開の時期と規模を確かめておきます。リポジトリは2026年3月17日に作られ、2026年10月21日時点でスターはおよそ8,500、複製（フォーク）は916です。最終の更新は2026年10月20日で、活発に手が入っている状態です。作者は mattpocock のアカウントで、2017年5月に作られ、公開リポジトリは224、フォロワーはおよそ5万1千と、開発者の間で広く知られた人物です。所属として「AI Hero」が記されています。

ライセンスはMITで、OSI（オープンソースの定義を管理する団体）が承認したライセンスです。そのため、この記事ではOSSと呼びます。なお、版の番号はまだ1.0に達していません。リリースの一覧では、最新の印が付いた版は0.12.0です。部品の呼び出し方や既定の値が今後変わる可能性は、推測として念頭に置いておくべきでしょう。

なぜ今、AIエージェントの「隔離して動かす仕組み」が求められるのか

コードを書くAIエージェントは、ファイルを読み書きし、命令を実行し、ときには外部へ通信します。人が一つひとつの操作を承認しながら使う分には目が届きますが、席を外している間に任せる使い方（READMEでは「AFK」、つまりキーボードから離れている間の実行と呼んでいます）では、承認の確認を省いて動かすことが増えます。

確認を省いたエージェントが開発者の端末でそのまま動くと、誤った命令や、読み込んだ文書に紛れた悪意のある指示によって、手元のファイルや保存されている鍵に手が届いてしまうおそれがあります。そこで、エージェントを端末から切り離した環境に閉じ込め、成果だけを受け取るという考え方が広がってきました。Sandcastle は、この考え方を開発の現場で扱いやすい形にまとめた部品の一つです。

加えて、複数のエージェントに別々の課題を同時に進めさせたい、という需要もあります。READMEは、席を外している間の複数のエージェントの並列実行や、レビュー（変更の点検）の流れづくりに向いていると説明しています。並列で動かすほど、どの変更がどのエージェントによるものかを切り分ける仕組みが要るため、隔離と枝の管理を一体で扱う設計になっていると読み取れます。

隔離環境の選択肢：手元のコンテナから、外部のクラウドまで

READMEによると、Sandcastle はエージェントを動かす隔離環境を差し替えられる作りです。組み込みで用意されているのは、Docker と Podman（どちらもコンテナと呼ばれる軽い隔離環境を動かす仕組み。Podman は管理者権限なしで動かせる方式）、そして Vercel のクラウド上の小さな仮想機械（Firecracker という技術を使うもの）の三つです。自社で別の環境を用意して組み込むこともできるとされています。

企業として押さえておきたいのは、隔離環境をどこに置くかで、コードと鍵がどこへ渡るかが変わるという点です。手元のコンテナなら、コードは社内の端末の中にとどまります。クラウドの仮想機械を選べば、コードとエージェントが使う鍵は外部の事業者の環境へ送られることになります。

READMEは、手元で動かす流れについて「すべて手元で完結する」と説明しています。一方で、エージェント自体は言語モデルの提供元に接続して動くため、コードの一部が言語モデルの提供元へ送られることは、隔離環境の種類にかかわらず変わりません。隔離は「端末を守る」ための仕組みであって、「情報を外に出さない」ための仕組みではない、と区別しておくことが大切です。

二つの隔離の方式：作業場所を共有するか、切り離すか

READMEは、隔離環境を二つの方式に分けて説明しています。一つ目は、手元の作業場所をそのまま隔離環境へ差し込む方式です。Docker と Podman はこちらで、ファイルの同期は要らない代わりに、エージェントの書き込みは差し込まれた場所を通じて手元のファイルに直接反映されます。

二つ目は、隔離環境が独自のファイルの置き場を持つ方式です。Vercel の仮想機械はこちらで、コードは決められた手段で中へ写し入れ、成果も決められた手段で外へ取り出します。手元のファイルとのつながりが細い分、切り離しの度合いは強いと言えます。

どちらが優れているというより、何を守りたいかで選ぶものです。手元の作業場所を共有する方式は手軽ですが、エージェントの誤った書き込みが手元の作業中のファイルに及ぶ余地があります。社内でどちらを標準にするかは、扱うコードの重要度と、外部の環境へコードを出してよいかの判断とあわせて決める必要があります。

変更を戻す三つのやり方と、既定の設定の違い

READMEによると、エージェントの作業結果の扱い方は三つから選べます。一つ目は、手元の作業中の場所へ直接書き込むやり方です。作業用の枝は作られません。二つ目は、一時的な枝で作業させ、終わったら元の枝へ取り込み、一時的な枝は消すやり方です。三つ目は、名前を付けた枝に変更を残すやり方です。

注意したいのは既定の値です。READMEでは、作業場所を共有する方式（Docker や Podman）では、手元へ直接書き込むやり方が既定とされています。切り離す方式（Vercel）では、一時的な枝を使って取り込むやり方が既定です。つまり、手元のコンテナで既定のまま動かすと、エージェントの変更は人の確認を挟まずに手元の作業場所へ入ってきます。

また、READMEは、直接書き込むやり方と、一時的な枝から自動で取り込むやり方は、同時に複数を動かす使い方では安全ではないと明記しています。人が変更を確かめてから取り込みたいなら、名前を付けた枝に残すやり方を選び、取り込みは人が行う、という運用が自然です。どのやり方を社内の標準にするかは、道具の既定に任せず、先に決めておくべき事項です。

対応するAIエージェントと、席を外している間の繰り返し実行

READMEによると、Sandcastle が呼び出せるエージェントは、Claude Code、Codex、Cursor、OpenCode、Copilot、Pi の六つです。そのうち Claude Code、Codex、Pi は作業の続きを引き継ぐ機能に対応し、残りは対応していないと説明されています。特定の事業者のエージェントに縛られない作りであることは、社内で複数の道具を試している企業には使いやすい点でしょう。

席を外している間の実行では、エージェントに同じ課題を何回まで繰り返させるかを決められます。既定は1回で、エージェントが「完了」の合図を出せば早めに終わります。また、エージェントが何も出力しない状態が既定で600秒続くと打ち切る仕組みもあります。動きの止まったエージェントが際限なく資源を使い続けることを防ぐための、地味ですが大切な安全装置です。

ただし、「完了」の合図はエージェント自身が出すものです。合図が出たことは、作業が正しく終わったことを意味しません。終わったかどうかの判断をエージェントの自己申告に任せないこと、つまり試験の結果や人の点検で確かめることが、使う側の責任になります。

実装と点検を分ける流れと、用意されているひな形

READMEは、一つの隔離環境の中で複数回エージェントを動かし、たとえば一つのエージェントが実装し、別のエージェントがその変更を点検する、という流れを組めると説明しています。途中で試験を走らせることもできるとされます。

ひな形も用意されています。READMEに挙がっているのは、何もない最小の形、課題を一つずつ拾って片付けていく形、課題ごとに点検の工程を挟む形、並列に進められる課題を計画して別々の枝で進めてから取りまとめる形、その形に枝ごとの点検を加えたもの、の五つです。課題の管理の仕組みと結びつけて、課題を拾い、片付け、閉じるところまでを自動で回す使い方が想定されていることが分かります。

ここで気をつけたいのは、点検役もAIである限り、点検は人の確認の代わりにはならないという点です。実装役と点検役が同じ種類の言語モデルなら、同じ見落としを共有する可能性もあります。AIによる点検は、人が読むべき箇所を絞り込む前段の作業と位置づけ、最終的な受け入れは人が行う形にしておくのが無難です。課題を自動で閉じる設定は、特に慎重に扱うべきでしょう。

比べる表：隔離のしかたで変わる、守れる範囲

READMEで確認できた選択肢を、企業の守りの観点で並べます。隔離を使わない選択肢も、同じ並びで扱われている点に注意してください。

観点	手元のコンテナ（Docker・Podman）	外部の仮想機械（Vercel）	隔離なし
隔離の方式	手元の作業場所を差し込んで共有	独自のファイルの置き場を持つ	手元の端末で直接動く
変更の戻し方の既定	手元の作業場所へ直接書き込む	一時的な枝で作業し、取り込む	選んだやり方による
コードの置き場所	社内の端末の中	外部の事業者の環境	社内の端末の中
端末への影響	差し込んだ場所には及ぶ	写し入れたもの以外には及びにくい	端末全体に及びうる
企業として決めること	差し込む場所と通信先の範囲	外部へコードと鍵を出してよいか	原則として使わない場面を決める

表の右端のとおり、READMEは隔離を使わずに手元で直接エージェントを動かす選択肢も、他と同じように選べるものとして説明しています。また、作業場所を別に切り出して人が対話しながら使う場面では、隔離環境を指定しなければ隔離なしが既定になるとされています。「Sandcastle を使っている」ことと「隔離されている」ことは同じではない点を、社内で共有しておく必要があります。

安全性の評価：紹介可とした根拠

このラインでは、OSSを取得・導入・実行せず、公開されている情報と精査の記録をもとに安全性を判定しています。Sandcastle の判定は「紹介可」です。根拠は次のとおりです。

ライセンスはOSI承認のMITです。作者のアカウントは2017年に作られ、公開リポジトリやフォロワーの数から見て、実績を外から確かめられる開発者です。公開済みのセキュリティ勧告は、2026年10月21日時点で見当たりませんでした。導入の際に自動で動く処理としては、開発者向けの仕組み（コードを記録する前の点検を用意するもの）を準備する設定が一つあるだけで、利用者の環境で勝手に動く処理は確認されませんでした。スターの伸びは1日あたり39程度で、不自然な急増とは言えません。

一方で、リポジトリにはセキュリティ上の問題の報告窓口を定めた方針の文書は置かれていません。また、問題が見つからなかったことは安全の保証ではありません。紹介可という判定は、道具の出どころに目立った懸念がないという意味であり、使い方しだいで生じる危険までを否定するものではない点に注意してください。

注意点の詳細：既定で権限の確認を省く起動と、名前の紛らわしい別の部品

最も注意したいのは、席を外している間の実行での既定の動きです。READMEによると、Claude Code を席を外している間に動かす場合、Sandcastle は既定でエージェントの操作ごとの許可の確認を省く起動のしかたを使います。Codex についても、既定では承認と、エージェント自身が持つ隔離の仕組みの両方を省く起動になると説明されています。

隔離環境の中で動かす前提なら、外側の隔離で守るという考え方は筋が通っています。しかし、隔離なしを選んだ場合や、手元の作業場所を共有する方式では、確認を省いたエージェントの操作がそのまま手元に及びます。リリースの記録によると、版0.8.0で、確認を省く代わりにAIが操作ごとに可否を判断する設定が加わりました。ただし、これも判断するのはAIであり、人による承認と同じではありません。

もう一つ、リリースの記録には、名前の似た無関係の部品が別に存在するため、作者の組織名の付いた正式な名前で取得するよう促す記述があります。似た名前の別物を取り違える危険は、開発の部品全般に共通する問題です。社内で使う場合は、取得する部品の正式な名前と配布元を決めて記録しておくことが大切です。

隔離の外とつながる設定：鍵・差し込む場所・通信

READMEには、隔離を弱める方向に働く設定も並んでいます。手元の任意の場所を隔離環境へ差し込む設定、コンテナを特定の通信網につなぐ設定、コンテナに手元の機器を見せる設定、追加の利用者の集まりに参加させる設定などです。READMEの例には、コンテナを動かす仕組みそのものへの接続口を差し込んだ場合を想定した記述もあります。

こうした設定は、使い方によっては隔離環境の中から、手元の端末や他のコンテナを操作できる状態を生む可能性があります。これは Sandcastle に固有の弱点ではなく、コンテナを使う仕組み一般に言えることですが、隔離の効き目を判断するには、既定の構成だけでなく実際に付け加えられた設定まで見る必要があります。

鍵の扱いも確かめておくべき点です。READMEによると、エージェントが使う鍵（言語モデルの提供元に接続するための鍵など）は、決められた設定ファイルや環境変数から読み込まれます。ひな形はこの設定ファイルを変更履歴に含めないようにしています。既定の隔離環境の中には、GitHub を操作する道具も入っていると説明されています。隔離環境に渡した鍵は、エージェントが使える鍵になるという前提で、渡す鍵の種類と権限の範囲を絞ることが欠かせません。

悪用されうるリスク

Sandcastle は守りの側の道具ですが、使い方によって生じうる危険を概要で挙げておきます。以下は一次情報の記述からの推測を含みます。まず、隔離されている前提で確認を省き、実際には隔離が弱い構成で動かしてしまう危険です。隔離なしの選択肢や、広い範囲を差し込む設定が紛れ込むと、守りの前提が崩れます。

次に、エージェントが読み込む課題の文面や文書に、悪意のある指示が紛れ込む危険です。課題を拾って自動で片付ける使い方では、外部の人が書き込める課題の文面がそのままエージェントへの指示になりえます。隔離環境の中に鍵や通信の手段があれば、紛れ込んだ指示によって鍵が外へ持ち出される可能性は否定できません。

さらに、作業の流れを定めるファイルやひな形は、エージェントを動かす前に実行される処理を含みえます。READMEによると、隔離環境の準備の段階で手元や隔離環境の中で処理を走らせる仕組みがあり、隔離環境の中では管理者の権限で動かすこともできるとされています。作業の流れを定めるファイルの変更も、コードと同じく点検の対象にすることが、手口の入り込む余地を減らします。

導入を検討するときに確かめること

Sandcastle を社内の開発に取り入れるかどうかを決める前に、少なくとも次の順で確かめておくと、後からの手戻りを防げます。

企業が取るべき対策

Sandcastle を使うかどうかにかかわらず、コードを書くAIエージェントを動かす企業に共通する対策があります。第一に、確認を省いた実行は、隔離された環境の中に限ることです。隔離なしで確認を省く組み合わせは、社内の規程で原則として禁じておくのが安全です。

第二に、エージェントの変更は必ず枝を分けて受け取り、人が確かめてから取り込むことです。自動の取り込みや、課題の自動の完了は、対象を限って使います。第三に、エージェントに渡す鍵は、作業に必要な最小限の権限のものに限り、使い終えたら無効にできる種類を選びます。

第四に、エージェントの作業の記録を残すことです。READMEによると、Sandcastle は既定で作業の記録をファイルに書き出し、外部の監視の仕組みへ流す手段も用意されています。誰が、いつ、どの課題について、どのエージェントを動かしたかを後から追えるようにしておきます。第五に、社内のAI利用の規程に、使ってよい隔離環境・渡してよい鍵・取り込みの承認者を書き込んでおきます。道具の既定に頼らず、規程として線を引くことが要点です。

AIに任せる範囲と、人が決める範囲

Sandcastle は、エージェントの実行と点検の両方をAIに担わせる流れを組める道具です。それ自体は作業を速くする工夫ですが、どの変更を受け入れるかの判断をAIに委ねてはいけません。AIに任せてよいのは、課題に沿って変更を作り、気になる箇所を拾い上げるところまでです。

人が決めるのは、任せる課題の範囲、隔離の強さ、渡す鍵、そして変更の受け入れです。点検役のAIには、指摘ごとにどのファイルのどの変更を見てそう判断したのか、根拠を書かせるようにし、人がその根拠を実際に読んで確かめます。人が確認する範囲を先に決めておけば、確認の手間も見積もりやすくなります。避けたい使い方を挙げます。

• 隔離なしの設定のまま、権限の確認を省いてエージェントを無人で動かす
• 点検役のAIが問題なしと答えたことだけを理由に、変更を取り込む
• エージェントの「完了」の合図を、作業が正しく終わった証拠として扱う
• 広い権限を持つ鍵を、作業に必要かどうか確かめずに隔離環境へ渡す
• 外部の人が書き込める課題を、文面を確かめないまま自動で処理させる

どの例にも共通するのは、道具が用意した仕組みを、人の判断の代わりに使ってしまうことです。隔離も、AIによる点検も、人の判断を支える材料として位置づけておくことが、道具を安全に生かす前提になります。

よくある質問：隔離環境で動かせば、エージェントに鍵を渡しても大丈夫なのか

答えは「隔離は端末を守るが、渡した鍵は守らない」です。隔離環境の中のエージェントは、渡された鍵を使って外部の仕組みにアクセスできます。紛れ込んだ指示に従ってしまえば、その鍵で許される操作は実行されうると考えておくべきです。隔離の強さと、渡す鍵の権限は、別々に絞る必要があります。

では隔離に意味がないのかというと、そうではありません。エージェントの誤った操作が開発者の端末全体や、保存されている他の鍵に及ぶ範囲を狭められることは、大きな利点です。並列に動くエージェントの作業を枝ごとに分けられることも、変更の追跡を助けます。「万全の守り」ではなく「被害の範囲を狭める仕組み」として位置づけるのが現実的です。

もう一つ、「外部の仮想機械を使えば、手元のコンテナより安全なのか」という問いもありそうです。手元の端末から切り離す度合いは強まりますが、コードと鍵を外部の事業者の環境に出すことになります。どちらを選ぶかは、守りたいものが端末なのか、コードの置き場所なのかを決めてからの判断になります。外部の環境での具体的な扱いについては、この記事で確認できた一次情報は限られます。

• Sandcastle の機能・隔離の方式・既定の値・ライセンスは、GitHubのリポジトリ（README・リリースの一覧・セキュリティの欄・ライセンス文書）と作者のアカウントの情報を2026年10月21日に確かめた範囲に基づきます。版の更新で内容は変わる可能性があります
• 外部の仮想機械を使う場合のコードと鍵の扱い、エージェントが外部へ変更を送る場合の動きは、確認した一次情報の範囲では詳しく確かめられませんでした
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順は扱いません

まとめ

Sandcastle は、コードを書くAIエージェントを、手元のコンテナや外部の仮想機械といった隔離環境で動かし、成果を作業用の枝で受け取る仕組みを提供するOSSです。ライセンスはMITで、作者は実績を外から確かめられる開発者であり、公開済みのセキュリティ勧告も見当たりません。

一方で、手元のコンテナでは作業場所を共有し、変更を手元へ直接書き込むやり方が既定で、無人の実行ではエージェントの許可の確認を省く起動が既定です。隔離を使わない選択肢も同じ並びで用意されています。隔離の強さ・渡す鍵・変更の受け入れを人が先に決め、AIの点検には根拠を書かせて人が確かめることが、Sandcastle を企業で生かすための現実的な付き合い方です。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。