ハクソク

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

危険に（安全に）Claude Codeを実行する

110日前原文(blog.emilburzo.com)

概要

  • Claude Code の--dangerously-skip-permissionsフラグ使用時の安全な実行環境構築方法
  • Docker や他のサンドボックス手法の課題と限界
  • Vagrant ＋VirtualBoxによるVM隔離の利点と実践手順
  • パフォーマンスや安全性、実際の運用での注意点
  • Claude Code の自由度を保ちつつ、事故リスクを低減する運用ノウハウ

Claude Codeの危険なフラグとその課題

  • --dangerously-skip-permissions フラグで Claude Code が全権限で動作
  • 「パッケージをインストールしてもいい？」「設定を変更してもいい？」などの 確認プロンプトが不要
  • 作業効率向上だが、 ファイルシステム破壊リスク が高まる
  • ホストOS上で直接実行は危険、安全な隔離が必須

Dockerによる隔離の検討と問題点

  • Dockerコンテナ による隔離を最初に検討
  • Claude Code にDockerイメージ作成・実行権限を与える必要
    • Docker-in-Docker （dind）が必須となり、--privilegedモードが必要
    • サンドボックスの意義が損なわれる （root権限でのコンテナ実行）
  • ネットワークやボリュームの権限問題、運用の煩雑さ
  • 結果的に 本末転倒 となるため却下

他の選択肢の検討

  • ベアメタル実行 ：論外
  • sandbox-runtime ：ACLベースで制限が強すぎる
  • firejail等 ：Docker-in-Dockerと同様の制約
  • 手動VM構築 ：再現性・手間の課題
  • クラウドVM ：コスト・遅延・データアップロードの手間

Vagrant＋VirtualBoxによる隔離

  • Vagrant ：インフラをコードで管理できるローカルVM管理ツール
    • 完全なVM隔離 （カーネル共有なし）
    • 簡単な初期化・破棄
    • 共有フォルダ でローカル感覚の作業
    • Docker-in-Docker問題なし
  • VirtualBox 7.2.4 のCPUバグに注意（高負荷問題あり）

Vagrantfileの例

  • bento/ubuntu-24.04 ベースのVM
  • 共有フォルダ ：ホストとVM間で/agent-workspaceを同期
  • VMリソース ：メモリ4GB、CPU2コア、GUIなし
  • プロビジョニング ：Docker, Node.js, npm, git, unzip, Claude Codeインストール
  • vagrantユーザー をdockerグループへ追加
vm_name = File.basename(Dir.getwd)
Vagrant.configure("2") do |config|
  config.vm.box = "bento/ubuntu-24.04"
  config.vm.synced_folder ".", "/agent-workspace", type: "virtualbox"
  config.vm.provider "virtualbox" do |vb|
    vb.memory = "4096"
    vb.cpus = 2
    vb.gui = false
    vb.name = vm_name
    vb.customize ["modifyvm", :id, "--audio", "none"]
    vb.customize ["modifyvm", :id, "--usb", "off"]
  end
  config.vm.provision "shell", inline: <<-SHELL
    export DEBIAN_FRONTEND=noninteractive
    apt-get update
    apt-get install -y docker.io nodejs npm git unzip
    npm install -g @anthropic-ai/claude-code --no-audit
    usermod -aG docker vagrant
    chown -R vagrant:vagrant /agent-workspace
  SHELL
end

運用方法と利便性

  • cd ~/my-project
  • vagrant up でVM起動とプロビジョニング
  • vagrant ssh 後、 claude --dangerously-skip-permissions で実行
  • 初回のみ Claude Code へのサインインが必要
  • vagrant suspend で一時停止、 exit でセッション終了
  • VM破棄 も容易、何かあればすぐ再作成可能

Claude Codeの新たな力

  • sudo権限付与 でインストール・設定変更・Docker操作など自在
    • WebアプリAPIの起動・curlでの検証
    • ブラウザインストール・E2Eテスト作成
    • Postgres設定・マイグレーション検証
    • Dockerイメージのビルド・実行
  • ホストPCで実行するには不安な操作 も安心して任せられる
  • 出力/エラーメッセージの中継不要 で一気通貫の自動化

パフォーマンス

  • Claude Code 自体は軽量
  • VMリソース も十分、共有フォルダのファイル同期も問題なし
  • Linux＋VirtualBox での検証、他OSは要確認

安全性とリスク

  • 防げるリスク
    • ファイルシステムの事故破壊
    • 過剰なパッケージインストール
    • 意図しない設定変更
    • 「うっかり操作」全般
  • 防げないリスク
    • プロジェクト自体の削除（共有フォルダは双方向同期）
    • VMエスケープ脆弱性 （稀だがゼロではない）
    • ネットワーク経由の攻撃やデータ流出 （VMは外部ネットに接続可能）
  • 脅威モデル ：事故防止が主目的、高度な攻撃は想定外
  • git管理 ならプロジェクト破損もリカバリ可能
  • rsync型共有 で一方向同期も可能（要手動同期）

まとめと推奨

  • VirtualBoxのCPUバグ 以外は構築も運用も快適
  • Claude Code に全権限を与えても、VM隔離で安心
  • Vagrantfile は短く再利用性が高い
  • プロジェクトディレクトリに設置→vagrant upで即サンドボックス
  • Claude Code dangerousフラグ利用者には強く推奨
  • 慎重派でも、一瞬の油断で事故は起きる ため、こうした隔離策が有効

Hackerたちの意見

もちろん、Claude Codeを何に使うかによるけど、リポジトリをクローンしてそのリポジトリでClaude Codeを実行する場合は、絶対に隔離することをおすすめするよ（他の似たようなツールでも同じ）。リポジトリのオーナーがユーザーのマシンでコードを実行させる方法はいろいろあるから、メインのノートパソコンやデスクトップで実行させるのは良くない計画だと思う。個人的には、すべてのエージェントを専用のVMに入れて、必要なときに何もないテストサーバーを提供してる。ベアメタルが必要な作業をするときね。

└

どんな状況でベアメタルが必要になるの？

私は違うアプローチを追求してるよ：Claudeが動く場所を隔離する代わりに、何をしたいかをキャッチするの。Shannotは実行前に意図をキャッチするんだ。スクリプトはすべてのシステムコールをキャッチするPyPyサンドボックスで実行されるから、コマンドやファイルの書き込みはログに記録されるけど、実際には行われない。TUIで確認して、安全なものを承認したら、実際に実行される。VMとのトレードオフは、VMはClaudeが隔離された状態で何でもできるけど、Shannotは人間の承認を得て実際のシステムに変更を提案させるってこと。使い方が違うんだ。VMはエージェント的なコーディング用で、こっちは「サーバーを修正する」タスク向けで、変更を適用したいけどまずレビューが必要な場合。ClaudeのためのMCP統合、SSH経由のリモート実行、間違いを元に戻すためのチェックポイント/ロールバックもあるよ。フィードバック大歓迎！

└

すごく賢い名前だね！

└

作者の問題をどう解決するのか、ちょっと見えづらいな。これには価値があると思うけど、Claude Codeに既にある組み込みのコントロールと同じ流れに感じる。私が思うに、このアプローチの問題（もし私が誤解してたらごめんね）は、最初の承認が必要なところでエージェントがブロックされることだと思う。ほとんどの人が実際に求めているのは（少なくとも私が求めているのは）、エージェントがスペースを探索できるようにすること、つまり、許可やアクセスが必要な行き止まりを含めて、タスクが終わるまで止まらずに進めることだと思う。だから、エージェントが「サーバーを修正する」ことを試みると、パッケージのインストールや削除を提案するかもしれない。その提案が将来の進行をブロックしちゃうんだ。人間が「はい、やって」か「いいえ、代わりにXを試して」って言うまで、何も進まない。もし代わりに進めて、パッケージが問題を解決しないことを観察して、すぐに他の解決策を探索し続けられれば、かなりの時間を節約できると思う。

みんな自分の解決策を提案する傾向があるから、私のを紹介するね：sandbox-run npx @anthropic-ai/claude-code これを使うと、Bubblewrapサンドボックス内でnpx (...) を透過的に実行できて、$PWDだけが露出されるよ。他の多くの解決策とは違って、これは純粋なPOSIXシェルの数行で済むんだ。

└

Bubblewrapのアプローチは好きだけど、残念ながらLinux専用なんだよね。プロセスの権限を落とすと、再度それを復元するのは無理みたい。

VagrantはClaudeにぴったりだよ！Limaという軽量のVMコントロールプレーンも使えるし、qemuやVirtualization.Frameworkとネイティブに動くからね。（Vagrantもそうだと思うけど、試したのはちょっと前だから忘れちゃった。）これは従来、コンテナエンジンを実行するために使われてきたけど、こういう狭い範囲の使い方には最適だよ。ただ、Claudeが作業しているディレクトリの共有方法には気をつけないとね。私はGitリポジトリをコンテナボリュームにコピーしてClaudeと一緒に使ってる（DinDは問題になるから、Kindみたいなことをしないといけない）し、変更をrsyncで戻して確認してからプッシュしてる。こうすることで、Claudeがreflogを巻き戻すようなことをしても心配しなくて済むんだ。

└

Limaの設定はどうしてるの？ 環境をセットアップするためのスクリプトとかある？それともその都度適当にやってる？

あなたが守っていないこと: > 悪意のあるAIがVMから逃げようとすること（VMエスケープの脆弱性は存在するけど、稀で意図的な悪用が必要） VMエスケープの脆弱性は必要ないよ。悪意のあるAIは、あなたのVagrantfileに任意のコードを追加して、最初にvagrantコマンドを実行したときにホストアクセスを得ることができる。もしミスだけが心配なら、Claudeはコミットフックを追加して何かを修正/改善することを決めるかもしれない。その中にミスがあれば、そのミスは最初にgit commit/pushしたときにホストで実行されることになる。（本当に開発環境を隔離するのは、面倒だから難しいよね。）

└

悪意のあるAIは、あなたのVagrantfileに任意のコードを追加できる > [...] > Claudeはコミットフックを追加して何かを修正/改善することを決めるかもしれない。これを解決するには、Claudeをサブディレクトリに制限すればいいよ（例えばDockerボリュームマウントを使って）：repository/ ├── sandbox

└

ec2ノード？

└

もう一つの方法は、悪意のあるコードがリポジトリに追加されることだね。もしVMの外でリポジトリのコードを実行したら、感染しちゃうよ。

ちょっと広い話になるけど、プログラムに自分のコンピュータを好き勝手に使わせることについてどう思う？今のところLLMはそれほど能力が高くないけど、この考え方をAGIに当てはめたら、すぐにペーパークリップ最大化問題みたいなのが起きて、他のシステムにハッキングし始めるかもしれない。これは、裏庭で感染性のバイ菌の実験をするのと似ていて、近所の人たちはあまり喜ばないだろうね。

└

私は自分のをDockerコンテナで動かしていて、大体のものには読み取り専用アクセスを与えてるよ。

└

従業員を雇ってシステムにアクセスを与えるときも同じ問題があるんじゃない？ AIが害を避ける能力があって、害を避けようとする動機があるなら、アクセスを与えるリスクは期待される利益より大きくないと思う。従業員もある意味ではペーパークリップを最大化しようとしているし、できるだけお金を稼ぎたいと思ってるから、その点ではAIの方が潜在的な従業員よりも私の目標に合ってる気がする。

└

最新のClaudeモデルに自己複製ソフトウェアについて聞いてみて、どうなるか見てみて…（GPTも最近この件に関して態度を変えたのが面白いよ。）最も興味深いのは、会話を古いモデルにダウングレードする選択肢が与えられること。最近数ヶ月でこの点において能力に大きな変化があったことを示唆しているね。

└

TFAのポイントは、好き勝手にさせているわけではなく、VMにマウントしたファイルと機能のサブセットに制限していることだよ。

承認疲れや継続的な権限管理が始まると、--dangerously-skip-permissionsを使いたくなる気持ちが強くなるよね。みんなが求めてるのは、ミスやプロンプトインジェクション攻撃の影響範囲が最小限で許容できるような、制限されたサンドボックスでエージェントを動かすことだと思う。だから、限られたファイルアクセス（リポジトリのみ）と限られたアウトバウンドネットワークアクセス（ホワイトリストのみ）でdevcontainer内でClaude Codeを動かし始めたんだ。今週末には、これをdocker composeで使えるように一般化したよ。次は、追加のエージェント（CodexやOpenCodeなど）をサポートする予定。さらにその後は、ホスト上で動くプロキシを通してすべてのネットワークアクセスを強制したいな。そうすれば、よりコントロールとログが取れるから（今はiptablesルールを使ってる）。このワークフローは今のところうまくいってるよ。まだ新しいから、ちょっと粗いところもあるかもしれないけど、見てみてね： https://github.com/mattolson/agent-sandbox

OSのサンドボックス機能（Linuxのbubblewrap、macOSのSeatbelt/sandbox-exec）を使った、似たような軽量（でもあまり隔離されてない）ツールがcco [1]だよ（注：これを作ったのは俺）。今は、AnthropicがClaude Code自体にネイティブのサンドボックス機能を追加したから、opencodeやcodexのような他のエージェントもサンドボックスできるのが主な利点だね。彼らのサンドボックスも似たように動いていて、bubblewrapとseatbeltを使ってるし、Claude Code内の/sandboxスラッシュコマンドからアクセスできるよ [2]。 [1]: https://github.com/nikvdp/cco [2]: https://code.claude.com/docs/en/sandboxing

機能ベースのソフトウェアに興味があって、致命的なトリフェクタを特定するツールを探してるんだ。これは特にコーディングに関しては難しい問題だと思う。なぜなら、安全でないコンテンツ（ウェブ検索）が敏感なもの（コード）に影響を与えられるようにしたいから。こういうことについて話せる人を見つけたいな。

LinuxやUnix OSを使ってるなら、chroot jailがもっと軽量な解決策かもしれないよ。chrootコマンドは、基本的にchrootされたディレクトリをルートディレクトリのように見せるんだ。Claudeがアクセスできるすべてのディレクトリ（/usr/binとか）を設定する必要があるけど、まだ試してないけど、うまくいかない理由はないと思う。この解決策は、プロジェクト外のファイルが壊れるのを防ぐけど、悪意のあるデータの流出は防げないね。