危険を冒しつつClaudeコードを安全に実行する

背景

最近、Claude Code をますます利用しています。
ある時点で、処理が完了するまで別の作業を行うよりも、
「もう一度許可が必要か」などと頻繁に確認している自分に気付きました。
それは、エージェントが何かをやる本来の目的から外れてしまっていたようです。
そこで

--dangerously-skip-permissions

まだ試したことがない方へ――このフラグは名前の通りで、
「許可を求める前に何でも実行する」ことができます。
「このパッケージをインストールしてもいいですか？」「設定を変更しても良いですか？」と 聞くことなく、単に処理を進めます。
処理の流れはスムーズですが、その分危険性も増します。

ファイルシステムを安全に保ちたいので、OS アカウント上で直接実行しない方針です。

考えたオプション

Docker

一番自然なイメージは Docker コンテナ。
コンテナは隔離のためにあるはずですが、Claude が Docker イメージをビルドしたり、コンテナを走らせたり、 さらにはオーケストレーションまで行う必要があるので
「Docker‑in‑Docker」状態になります。
その場合

--privileged

• Claude がファイルシステムを壊す可能性 → 「ファイルシステムは安全」
• 逆にコンテナランタイムへのルート権限 → 「隔離は失敗」

というジレンマに。
さらに、ネットワークのネストやボリュームマウント時の権限問題、 ツールを使うよりも逆に対処する感覚が強くなります。

他にも考えたもの：

• yolo – そのまま裸で実行：いいえ、いや、絶対にやりません
• sandbox‑runtime – ACL ベース。Claude が何でもできるようにしたいので不要
• firejail 等 – Docker‑in‑Docker と同じ問題
• 手動 VM 設定 – 動くが面倒で再現性なし
• クラウド VM – コスト・レイテンシーが発生し、コードをアップロードする必要あり

Vagrant

ここで思い出したのは、Docker が流行る前に使っていた Vagrant です。
Vagrant はローカル開発環境をインフラコード化してくれるツールで、 次のようなメリットがあります。

• 完全な VM 隔離（共有カーネルなし）
• 簡単に破棄・再構築
• ローカル感覚で使えるシェアフォルダ
• Docker‑in‑Docker という無駄がない

私は長らく VirtualBox を使っていませんでしたが、
最新バージョン（7.2.4）を入れて試してみました。

最初に

vagrant up

VirtualBox 7.2.4 はアイドル時に高 CPU を消費する回帰がある

という GitHub issue を発見しました。

Vagrantfile

以下は私のシンプルな

Vagrantfile

vm_name = File.basename(Dir.getwd)

Vagrant.configure("2") do |config|
  config.vm.box = "bento/ubuntu-24.04"

  # config.vm.network "forwarded_port", guest: 3000, host: 3000, auto_correct: true
  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

実際に使う手順

1. cd ~/my-project

2. vagrant up

3. vagrant ssh

4. claude --dangerously-skip-permissions

これで Claude に任せるだけ。
最初の起動は数分かかりますが、以降は高速です。
作業終了時は

vagrant destroy

強化された Claude

VM 内で実行しているため、sudo 権限を与え、
「何でもできる」と認識させました。具体的には：

• 手動で Web アプリ API を起動し、curl で検証
• ブラウザをインストール・手動確認後にエンドツーエンドテスト作成
• Postgres データベース構築 → SQL テスト実行、マイグレーション確認
• Docker イメージのビルド・起動

ホスト上でやりたくない操作を、フラグが有効な状態でも安全に実行できます。
Claude が自律的に作業するため、コマンド入力・結果確認・反復処理を 私自身が手間取る必要はありません。

パフォーマンス

Claude Code はリソース消費がそれほど高くないので、 VM には十分余裕があります。
シェアフォルダの同期もスムーズで、ファイル変更時に遅延や不具合は発生しません。
これは Linux + VirtualBox 環境で確認済みです。他プラットフォームでは結果が異なる可能性があります。

安全対策

防ぎたいもの

• ファイルシステムへの偶発的損傷
• 過剰なパッケージインストール
• 変更を見逃す設定変更
• 「Claude がやってほしくないこと」を誤実行

守れないもの

• プロジェクトファイル自体の削除（同期は双方向）
• VM エスケープ脆弱性（稀で、意図的な攻撃が必要）
• ネットワークレベルの攻撃
• データ漏洩：VM はインターネットに接続していますが、コード以外にはほぼデータはありません

脅威モデル

自分自身がエージェントの動作を常に監視できるわけではないので、 偶発的な事故を防ぐ設定です。
プロジェクトはすべて Git で管理しているため、 破損してもローカルコピーから復旧可能です。
さらに Vagrant の

config.vm.synced_folder

type: "rsync"

結論

VirtualBox の CPU バグを解消し、設定を整えるまでに少々時間がかかりましたが、 現在はスムーズに動作しています。
Claude Code を危険フラグ付きで使う際には、この構成をおすすめします。
VM を破棄して再起動するだけで、いつでも安全なサンドボックス環境を手に入れられます。

Vagrantfile

vagrant up