ハクソク

世界を動かす技術を、日本語で。

エージェントに厳しく、ファイルシステムには優しく

59日前原文(jai.scs.stanford.edu)

概要

  • jai はAIエージェント利用時の ファイル損失やディレクトリ消去 リスクを低減する軽量サンドボックス
  • Docker や VM のような複雑なセットアップ不要、コマンド一つで即利用可能
  • 作業ディレクトリ のみ完全アクセス、他は コピーオンライト や 隠蔽 で保護
  • 3つの分離モード で用途に応じて隔離レベルを選択可能
  • Stanford Secure Computer Systems研究グループ による 無償ソフトウェア

jai: AIエージェント用軽量サンドボックス

  • AIツール利用時の危険性 ：ファイル消失、作業ツリー消去、ホームディレクトリ全消去などの被害報告
  • 従来の問題点 ：本アカウントをAIエージェントに渡すと全権限を与えてしまう
  • jaiの特徴 ：コンテナやVM構築の手間なし、既存ワークフローに即導入可能な軽量サンドボックス
  • 用途例
    • コーディング支援
    • 一時的なローカルタスク実行
    • 外部作成インストーラスクリプトの安全実行

ファイルアクセス管理

  • 作業ディレクトリ（CWD） ：サンドボックス内で完全な読み書き権限
  • ホームディレクトリ ：コピーオンライトで保護、オリジナルは変更されない
  • その他ファイル ：/tmpや/var/tmpはプライベート、それ以外は読み取り専用

使い方

  • 実行方法 ：コマンドの前に「jai」を付けるだけ
    • 例：jai codex、jai claude、または単にjaiでシェル起動
  • セットアップ不要 ：Dockerfileやイメージ作成不要
  • 即時利用 ：一行でサンドボックス環境へ

分離モード

  • Casualモード
    • ホームディレクトリ：コピーオンライト
    • プロセス権限：ユーザー自身
    • 機密性：弱（多くのファイルが読める）
    • 整合性：オーバーレイでオリジナル保護
    • NFS対応：あり
  • Strictモード
    • ホームディレクトリ：空のプライベート
    • プロセス権限：非特権jaiユーザー
    • 機密性：強（UID分離）
    • 整合性：完全隔離
    • NFS対応：なし
  • Bareモード
    • ホームディレクトリ：空のプライベート
    • プロセス権限：ユーザー自身
    • 機密性：中（UIDは同じだがホーム隠蔽）
    • 整合性：完全隔離
    • NFS対応：あり

他ツールとの比較

  • Docker
    • イメージベースの再現性重視
    • ad-hocなホストツールのサンドボックスには重い
    • ホームディレクトリのオーバーレイ運用不可
  • bubblewrap
    • 強力な名前空間サンドボックス
    • ファイルシステムビューの明示的構築が必要で煩雑
    • jaiはこの手間を排除
  • chroot
    • セキュリティ機構ではない
    • マウント、PID、認証情報の分離なし
    • Linux公式でもサンドボックス用途非推奨

セキュリティモデル

  • 完全な安全性は保証しない
    • jaiは「カジュアルサンドボックス」
    • 被害範囲（blast radius）は縮小するが、全リスク排除は不可
    • Casualモードは機密性保護なし
    • Strictモードでもハード化されたコンテナやVMと同等ではない
    • 強固な分離や多人数利用時は本格的なコンテナやVMを推奨

ライセンスと開発体制

  • 無償ソフトウェア
    • 開発元：Stanford Secure Computer Systems研究グループ、Future of Digital Currency Initiative
    • 目的：AI活用時の安全性向上推進

Hackerたちの意見

すごいプロジェクトだけど、タイトルが残念だね。クリックしなかったかもしれない。提供されているトレードオフが気に入ってる：現在のディレクトリにはフルアクセス、他の部分は読み取り専用、ホームディレクトリはコピーオンライト。データ流出を防ぐための厳しいモードもあるみたいだし。エージェントシステムのデフォルトにすべきだと思う。

└

サイト自体にタイトルがないから、「jai - AIエージェントのファイルシステムコンテインメント」みたいな感じにしたかも。

.claude/settings.jsonにこれを追加してね: { "sandbox": { "enabled": true, "filesystem": { "allowRead": ["."], "denyRead": ["~/"], "allowWrite": ["."], "denyWrite": ["/"] } } } 読み取り部分は外部を読み込むのが大丈夫なら変更してもいいよ。ちなみにこの機能は10日前に追加されたばかりだけど、すごくいいしほぼこれだね。

└

ポイントは、claude-codeの今後のどこかのリビジョンで設定名が静かに削除されたり変更されたりする可能性があるってことだと思う。人々は本当に他のソフトウェアにサンドボックスをやってほしいかもしれない。狐以外の何かで。

└

これは本物のサンドボックスなの？それともただのお願い？

└

面白いね、ありがとう。私は隔離された環境でリモートのエフェメラル開発コンテナを使ってるから、ファイルシステムのダメージは気にしない。PRがレビューで良さそうならね。でも、いい追加のガードレールだね。プロジェクトレベルの設定に追加するよ。

└

クロードがどのディレクトリにいるのか混乱するのを見たことがある。そしてもちろん、クロードがrm -rf *を実行するのも見たことがある。幸い、同時にはなかったけど、想像するのは簡単だよね。クロードのサンドボックスはいいアイデアだけど、効果的にするには非常に低いレベルで実装して、クロードが起動する全てのプログラムに強制する必要がある。あと、クロード自体はほとんどAIによって開発された巨大なプログラムだから、3000行未満の人間が実装したプログラムを別の防御層として持つことは、意味のある追加の保護を提供するよ。

└

それに、たくさんの人が複数のハーネスを使ってるよね。俺はよくclaude、codex、opencodeを切り替えてる。実際に動かしてるAIアシスタントとは独立したサンドボックスポリシーがあるのは、結構いい感じだよ。

└

ある意味、私たちはClaudeのコード内でオペレーティングシステム、もしくは少なくともユーザースペースを再構築し始めているね。このパターンには何か名前があった気がするけど、思い出せないな。

└

Claudeが自分のサンドボックスを無効にする権限を持っているのが可愛いね。そして実際にそれをやってる。

└

そんなシンプルな設定でうまくいくなんて驚きだよ！私はClaudeの基盤となるサンドボックスにallowReadオプションを追加した人なんだけど、ツールチェーンやスキルをそれに合わせるのが大変だったんだ。[0] 自分が書いた混乱したドキュメントが、Claudeのドキュメントにほぼそのまま載ってるのを見るのは面白いね。[1] 私の設定はここにあるから、誰かの役に立つかもね：https://github.com/carderne/pi-sandbox/blob/main/sandbox.jso...

└

それってハード設定なの？それともクロードの解釈次第？後者だとこんな感じになるかもね。https://news.ycombinator.com/item?id=47357042

└

これはハードサンドボックスなの？（LLMの外で強制されるやつ）

記事の例は全部大きな怖いワイプだけど、もっと一般的なダメージは小さくて気づきにくいと思う。数ヶ月間毎日claudeのコードを使ってるけど、最悪のことはワイプじゃなかった（まだ）。SVGファイルを保存する必要があったから、/public/blog/フォルダを作成したんだ。それでApacheがその実際のディレクトリを提供し始めて、/blogがルーティングされなくなった。ブログが404になって、解決するのに1時間くらいかかった。何も削除されてないし、パーミッションの問題でもない。エージェントが自分にとって意味のある場所にファイルを置いただけなんだ。jaiは確かにrm -rfのケースには役立つけど、こういうのは捕まえるのが難しい。パーミッションの問題じゃないから、エージェントがウェブサーバーが何か知らないだけなんだよね。

サイトがバイブコーディングされてるって明らか（かつ言われてる）事実が、このツールが手書きであることを損なってるのかなって思ってる。 > jai自体はスタンフォード大学のコンピュータサイエンスの教授によって手動で実装されたもので、C++とUnix/Linuxの経験が数十年あるんだって。

└

もう少し具体的に言うと、これはデイビッド・マジエレスが書いたもので、彼は2000年からユーザーレベルのファイルシステムについてソフトウェアや論文を書いてきたんだ。今はスタンフォード大学のセキュアコンピュータシステムグループを運営してる。デイビッドは素晴らしい仕事をしてるし、面白い仕事もしてる。時にはその両方を兼ね備えてる。

└

ここにいるのは人間の著者です。ウェブデザインを知らないからって、オペレーティングシステムの専門知識が損なわれるわけじゃないよ。俺がソフトウェアとマニュアルを書いたし、それがセキュリティにとって本当に重要なことだから。ウェブサイトは…まあ、CLIサンドボックスツールのために想像していたものとは全く違うものだと言っておこう。クロードがそれを出したとき、思わず笑っちゃったけど、部分的には皮肉で、でも自分でランディングページをデザインする方法がわからないから、残すことにした。ウェブサイトのドキュメント部分の内容は不正確なところを修正したから、内容は有効なはずだよ。

└

はぁ、まだこのクソみたいな冗長さよりも、手書きの簡潔な情報が載った基本的なHTMLページの方が良かったな。

最近、エージェントのサンドボックスソリューションを見直してたんだけど、エージェントがプロジェクトディレクトリに書き込むことを許可するツールには、持続的なエクスプロイトの大きな隙間があることに気づいた。これみたいにね。最初は、git diffで全部レビューできるから大丈夫だと思ってたんだけど、後から考えたら、エージェントが書き込めるファイルがいろいろあって、開発者としてはサンドボックスの外で実行しちゃう可能性があるんだよね。例えば、全ての.pycファイルや、.venv内のファイル、.gitフックファイルとか。ChatGPTも、根本的なエクスプロイトのベクターが確認されていて、エージェントのサンドボックスツールに関してあまり議論されてないことを認めてる。俺の結論は、唯一本当に安全なサンドボックス技術は、サンドボックスから開発者のマシンにファイルを転送する際に、何らかのgitパッチや類似の方法を使うことだと思う。つまり、ファイルはバージョン管理に入っていて、開発者がサンドボックスの外に転送する前にレビューしたものだけが転送できるってこと。もっとこのことについて話してほしいな。解決策はそんなに難しくない。CWDをオーバーレイとして保持して、コンテナ内で修正されたファイルを、gitに入っていないファイルや、潜在的に危険なファイル（バイナリファイルなど）をフィルタリングするプロキシを通して転送すればいいんだ。もちろん、ここには何らかの設定オプションが必要になるだろうね。

└

いいポイントだね。現在の作業ディレクトリの中でも特定のディレクトリを読み取り専用にするオプションを追加した方がいいかも。そうすれば、.git/をプロジェクトディレクトリから移動させずに読み取り専用にできる。CWDを「jai -D」でオーバーレイにすることはもうできるし。難しいのは、変更をメインの作業ディレクトリにどうやって統合するかだね。

└

そうだね、githooksは絶対に許可しない方がいい ;)

みんながプライベートマシンにこれらのエージェントを簡単にインストールすることを受け入れたのには本当に驚いてる。何十年もあらゆる方法でシステムを守ってきたのに、ある日突然「おお、予測不可能で信頼できない、チューリング完全なソフトウェアがデータを無限の未知の方法で持ち出したり破壊したりできるよ。はい、鍵をあげるから、好きにして！」って言ったんだもん。

└

みんな、ビルドツールが自動的に大量の依存関係を引き込むことについて心配しているのを軽視してたけど、今や高プロファイルな開発者のサプライチェーンが次々と侵害されてる真っ最中だよね。短期的な考え方が、平均よりも客観的に賢くて教育を受けている人たちのグループでも支配しているみたい。

└

いつか、モンスターを閉じ込める檻を作る日が来るだろうね。まあ、その間に食べられないことを祈るけど。もしくは、もっと大きなモンスターに食べられちゃうかも。 :)

└

その気持ち、わかる！でも「すべての方法でセキュリティを確保する」って？2026年には「password」をパスワードに選ぶ人がたくさんいると思うよ。中には生年月日を使って、ちょっとおしゃれに名前を足す人もいるだろうけど。/愚痴

└

俺もそう思う。これらのものをシステムにアクセスできる状態で動かすのは本当に馬鹿げてる。サンドボックスがあってもなくてもね。でも、目先の利益を追い求めるせいで、明らかなセキュリティと信頼性の問題が無視されてるんだよね。

└

セキュリティの話はいつもそうだよね。セキュリティと便利さの戦い。セキュリティ機能って、不便だと逆にセキュリティが下がることが多いんだよ。ユーザーに難しいパスワードを求めると、どこでも同じのを使い回しちゃうし。エージェントがファイルを変更するたびにユーザーに確認を求めると、みんなそのガードレールを無効にする方法を見つけちゃう。

└

それを言うなら、Dockerも似たようなスタートだったよ。「Docker Hubからこのイメージをダウンロードするだけ！何が悪いの？」ってね。でも業界はすぐに気づいたけど。

これ、めっちゃ良さそうだし、よく考えられてるね。俺の解決策よりも便利で、ちょっと安全性も高い感じがする。俺は別のユーザーを与えるだけなんだけど、エージェントは「エージェント」のホームディレクトリを消せるけど、俺のは読んだり書いたりできない。自分のユーザーをエージェントグループに入れたから、エージェントのホームディレクトリにはアクセスできるけど、ちょっと面倒なんだよね（時々、間違った権限が設定されるから、それを直すスクリプトを用意してる）。ターミナルがどのユーザーで動いてるかを把握するのも面倒でミスしやすいし。--- でも、俺が見つけた一番の解決策は「ノートパソコンを一台あげること」。OSやソフトウェアの解決策は完全に忘れて、別のマシンを手に入れるのが一番！ユーザーを切り替えるより便利だし、「物理的に別のマシン」ってセキュリティの面でもかなり強いよね :) マックミニの話に似てるけど、古いThinkPadは結構安いし。（俺はこれを50ドルでゲットした！）

└

ここで問題になるのは、エージェントが外部とやり取りするためにはキーを渡さなきゃいけないこと。エージェントと外部サービスの間で本物のキーを扱うプロキシがないと、そのキーが侵害されるリスクがあるんだ。それに、エージェントは「セキュリティペネトレーションテスト」をハッキングするのが得意だから、「別のユーザー」じゃ悪意のあるコンテキストに対して十分な信頼を持てないよ。

└

ユーザーのことは、今私もやってるよ。コンテナのことも考えたけど、自分でコンテナを作って使うように頼むと、みんな混乱しちゃうんだよね。

フルVMか、何もなしかだね。AIにはOSへの完全かつ無制限のアクセスを持たせたい。すべてのコマンドを承認して見守るなんて、やりたくないから。VM上にあるものはすべてが対象だし、VMイメージは外部から定期的にバックアップされてる。これが唯一の方法だよ。

これはクールな解決策だね。でも、もっとシンプルな方法があるよ。ただ、用途によっては劣るかもしれないけど。ssh経由で自分のユーザーアカウントで実行するんだ。読み込ませたいときにプロジェクトディレクトリをホームディレクトリにバインドマウントする感じ。マウントコマンドはこんな感じだよ：sudo mkdir /home// sudo mount --bind --map-groups $(id -g ):$(id -g ):1 --map-users $(id -u ):$(id -u ):1 /home// これ、特にvscodeのsshリモートで使ってる。

エージェントはsystemd-runを使って、必要なセキュリティプロパティが設定された一時的なスコープユニットで運用すべきだと思ってるんだ。だから、適切なシェルエイリアスでこれができるんじゃないかな、少なくともLinuxでは。