コーディングエージェント用の使い捨てVM構築法

使い捨て VM がノート PC より優れている理由

コーディングエージェントに使い捨て VM を与えれば、最悪の場合でも、10 分で再構築できるマシンを破壊されるだけです。エージェントは root 権限を持ち、パッケージをインストールし、各手順で許可を求めることなくテストスイートを実行できます。違いは、被害が及ぶ場所です。ノート PC では、エージェントが SSH キー、ブラウザープロファイル、.env ファイル、そしてこれまでに clone したすべてのリポジトリがあるホームディレクトリを共有します。使い捨てサーバーにあるのは、シェル、checkout、そして持ち出す価値のあるものがほかに何もない環境です。

これが主張のすべてです。これは確率ではなく、非対称性に関する主張です。慎重なエージェントを慎重に使うノート PC なら、ほとんどの場合は問題ありません。問題が起きたときのコストは、悪い commit の修正ではありません。バックアップがあれば、そこからの復元が必要になります。

影響範囲を明確にしてから議論する

Blast radius とは、プロセスが到達できる対象の範囲です。通常のマシンで通常のユーザーとして実行する agent の場合、その範囲は多くの人が想定するより広くなります。

そこには ~/.ssh/id_ed25519 が含まれます。これは通常、暗号化されていません。passphrase の入力に疲れてしまうためです。~/.aws/credentials と ~/.config/gh/hosts.yml も含まれます。これらは設計上、平文です。~/code 配下にあるすべての sibling repository も含まれます。ローカルの env file に production の接続文字列が入っている repository も例外ではありません。1 度貼り付けた token が残る shell history も含まれます。さらに、laptop が接続しているネットワークも含まれます。そこは自宅やオフィスのネットワークで、認証なしのサービスが稼働していることもあります。

これらはいずれも、悪意のある agent を必要としません。必要なのは、確信を持って実行された誤ったコマンドだけです。未設定の変数が / に展開される rm -rf、誤ったディレクトリで実行する git clean -xfd、ローカルデータベースまで削除する docker system prune -af --volumes、home directory に対して実行する親切な chmod -R 777 などです。agent は、他の人々にもそのようなコマンドを教えたのと同じインターネット上の情報で学習しています。

被害を抑える仕組みは、agent の判断力ではありません。被害を受けるマシンを、失っても構わないものにしておくことです。

コスト計算は退屈ですが、それが重要な点です

小規模な VPS は、月に数ドルで利用できます。開発者のノート PC を復旧するには 1 日かかることがあります。しかもこれは、問題にすぐ気付き、バックアップもあるという、よいケースです。

自分の数字で計算してください。時給に、OS の再インストール、ホームディレクトリの復元、SSH key のローテーション、personal access token のローテーション、20 個のリポジトリの再 clone に必要な時間を掛けます。それを、プロバイダーが提供する最小構成のサーバーを 12 か月利用する費用と比較します。数年に 1 回未満のインシデントでも損益分岐点を超えます。しかも、基準を超えるために深刻なインシデントである必要はありません。ローカル環境の破損によって午後を 1 回失うだけで、年間費用を回収できます。

計算のもう半分はスナップショットです。リスクの高い処理を実行する前にスナップショットを取得しておけば、問題が起きたときに「環境をすべて復元する」のではなく、「ロールバックして別の prompt を試す」ことができます。いま入力に使っているノート PC では、この選択肢はありません。作業机として使っているマシンを、その使用中にスナップショット取得することはできないためです。

2026 年 7 月時点の状況

「エージェントをどこで実行すべきか」という問いには、正直な答えが 3 つあります。いずれも、境界の強さと、どれだけのセットアップを許容できるかという同じ 2 つの要素のトレードオフです。

ローカルの micro VM。 このカテゴリのツールは、自分のハードウェア上で実際の仮想マシンを起動し、リポジトリをその VM にマウントして、エージェントに内部の root 権限を与えます。clawk が現在の例で、この投稿の主張そのものでもあります。つまり、コーディングエージェントにはノート PC ではなく、使い捨ての Linux VM を与えます。2026 年 7 月時点では、Apple silicon 上の macOS 14 以降を対象とし、Firecracker を通じた実験的な Linux サポートもあります。インストールには brew install clawkwork/tap/clawk を使用します。リポジトリ内で clawk を実行するとサンドボックスを起動してエージェントを接続できます。停止には clawk down、削除には clawk destroy を使用します。境界はハイパーバイザーによって提供されるため、強固です。ただし、VM は持ち運ぶマシン上で動作するため、メモリを消費し、蓋を閉じると停止します。

コンテナ。 Docker は、すでにインストールしている人が最も多い選択肢であり、実際に便利です。

docker run --rm -it -v "$PWD:/work" -w /work --network none ubuntu:24.04 bash

--rm は終了時にコンテナを破棄し、--network none はコンテナにネットワークを一切与えません。ビルドやテストの実行には適したデフォルトです。ただし、これで実現できないことを明確にしておく必要があります。コンテナはホストのカーネルを共有するため、カーネルのバグが脱出経路になります。また、--privileged を追加した時点、またはエージェントが「Docker を使用」できるように /var/run/docker.sock をマウントした時点で、境界はなくなります。Docker socket をコンテナにマウントすることは、そのコンテナにホスト上の root 権限を与えることと同じです。

再構築できる通常の VPS。 新しいツールは不要で、実際のカーネル境界があり、プロバイダーのスナップショットを利用でき、ノート PC をシャットダウンしても実行を継続します。このガイドの後半で説明するのがこの構成です。長時間実行するエージェントに適しているのもこの構成です。4 時間かかるジョブは、あなたが帰宅したかどうかを気にしないからです。

VPS の基本構成: エージェント専用のユーザーを作成する

強化済みのサーバーから始めます。新しい VPS で最初の 10 分に行う作業では、エージェント固有ではない更新、root 以外でのログイン、鍵のみを使用する SSH、ファイアウォールの設定を扱います。

次に、エージェント専用のアカウントを作成します。エージェント内部のミスが、サーバー上の他のものに影響しないようにするためです。

sudo adduser --disabled-password --gecos "" agent
sudo install -d -m 700 -o agent -g agent /home/agent/work
sudo -u agent -H bash -lc 'id; ls -la ~'

--disabled-passwordにより、推測できるパスワードは存在しません。アカウントには sudo -u agentまたは SSH 鍵でアクセスします。agentを意図的に sudoグループへ追加していない点に注意してください。sudoを持つエージェントは root 権限を持ちます。root は他のすべてのユーザーのファイルを読み取れるため、先ほど構築した分離は形だけになります。エージェントが本当にパッケージのインストールを必要とする場合は、共有サーバーで sudoを与えるのではなく、エージェント専用のサーバー全体を用意すべきです。一般的なルールについては、VPS 上の Linux ユーザーに対する最小権限を参照してください。

信頼する前に、分離境界を確認します。agentユーザーとして、自分のアカウントに属するファイルを読み取ってみます。

sudo -u agent cat /home/you/.ssh/id_ed25519

cat: /home/you/.ssh/id_ed25519: Permission deniedと表示されるはずです。代わりに鍵のマテリアルが表示される場合、ホームディレクトリのモードが 755 になっており、まだ実際には分離されていません。sudo chmod 700 /home/youで修正します。

認証情報をマシン上に一切置かない

使い捨てマシンの目的は、本番環境の Secret をそこへコピーした時点で失われます。原則は単純です。そのマシン上には、今日の午後にローテーションしても構わないと思えない認証情報を置いてはいけません。

git では、key をコピーせずに SSH agent を転送します。private key は laptop 上に残り、接続を通過するのは署名要求だけです。

ssh -A agent@203.0.113.10
ssh -T git@github.com

2 番目のコマンドは Hi yourname! You've successfully authenticated, but GitHub does not provide shell access. と応答する必要があります。これにより、サーバー上に key file がなくても git push が動作することを確認できます。その後、マシン上で ls -la ~/.ssh を実行し、private key が存在しないことを確認します。

Agent forwarding には実質的な注意点が 1 つあります。接続中は、そのサーバー上で root 権限を持つユーザーが転送された socket を使い、あなたとして認証できます。そのサーバーの他のユーザーがあなただけであれば、許容できるトレードオフです。共有マシンでは許容できません。その場合は、1 つの repository に限定した deploy key の方が適切です。選択肢については SSH key 管理の基本 で説明しています。

API key では、専用の支出上限を設定した key を agent 用に発行し、agent user が所有する mode 600 の file に保存します。マシンを破棄するときは、漏えいしていないか悩むのではなく、その key を revoke します。key ごとの model 支出を把握しておくことが、VPS 上の AI agent のコスト管理 の数値を予測可能に保つ方法でもあります。

エージェントがネットワーク上で接続できる範囲を制限する

ファイルシステムの分離は境界の半分にすぎません。残りの半分はエグレス、つまりプロセスが接続できる対象です。Linux では、プロセスを作成したユーザーに基づいて送信トラフィックをフィルタリングできます。この構成に適しています。

sudo iptables -A OUTPUT -m owner --uid-owner agent -o lo -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p udp --dport 53 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p tcp --dport 443 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -j REJECT

ルールは上から順に評価されるため、最後の REJECT によって、それ以前の行で許可されなかったすべての通信が捕捉されます。エージェントとしてテストします。

sudo -u agent curl -sS -m 5 http://example.com

curl: (7) Failed to connect to example.com port 80: Connection refused で失敗するはずです。拒否ルールが接続をハングさせず、直ちに応答するためです。同じホストへの HTTPS リクエストは引き続き成功するはずです。

注意すべき制限が 2 つあります。1 つ目は、保存しない限り、次回の再起動でこれらのルールが失われることです。保存には sudo apt install -y iptables-persistent、続いて sudo netfilter-persistent save を使用します。2 つ目は、名前ではなくポートとアドレスをフィルタリングすることです。ポート 443 を許可するルールは、インターネット上のすべての HTTPS ホストへの接続を許可します。これでモデル API には接続できますが、pastebin にも接続できます。実際のドメイン許可リストには、要求されたホスト名を読み取るプロキシをトラフィックが通過する必要があります。これは、多くの単独開発者の構成には過剰な仕組みです。主張する範囲は、実際に実装した内容に限ってください。つまり、失っても構わない状態に準備したマシン上での、ポート単位のエグレス制御です。

タスク間でクリーンな状態に戻す

タスクごとにクリーンな状態を用意することは、過小評価されがちな利点です。前のチケットに 3 時間かけたエージェントが、インストール済みパッケージ、途中まで適用されたマイグレーション、古い node_modules、そして誰もレビューしていない変更を含む git の作業ツリーを残していくことがあります。次のタスクはそれらをすべて引き継ぐため、レビューの時間を使って、どの実行がどの問題を残したのかを調べることになります。より限定されたエージェントなら、そもそも残すものが少なくなります。そのため、使い捨て可能なマシンとエージェントに動作する最小限の変更を促すスキルを組み合わせると、差分も残存状態もレビューしやすい範囲に抑えられます。

手軽な方法は、タスクごとに新しい checkout を用意することです。

sudo -u agent -H bash -lc 'rm -rf ~/work/repo && git clone git@github.com:you/repo.git ~/work/repo'

より確実な方法は、マシンのセットアップ直後、エージェントが触れる前に provider の snapshot を 1 回取得しておくことです。その snapshot を復元すると、パッケージを含むシステム全体が既知の状態に戻ります。多くの provider では、これはマシン上のコマンドではなく、control panel または API から実行します。そのため、具体的な手順は利用する provider によって異なります。重要なのは、マシンがまだ何も変更されていない状態で snapshot を取得することです。

必要なデータは使い捨て可能なマシンの外に保管してください。主な方法は、ブランチをローカルに溜め込まず push することです。もしそのマシンに失うと困るデータを置くことになった場合は、VPS での restic backupを使って適切にバックアップしてください。破棄できるマシンが役立つのは、実際に破棄しても問題が起きない場合だけです。

複数のサーバーに費用をかけず、複数の分離された環境が必要なら、より大きな VPS 上で guest VM を直接ホストできます。VPS での nested virtualisationでは、その仕組みと provider が対応しているかの確認方法を説明しています。ここで分離には両面があります。同じマシン上の 2 つのエージェントを互いに隔離するよりも連携させたい場合は、引き継ぎのたびに自分を経由させず、1 つの Claude Code セッションから別のセッションへテキストを直接送信できます。

注意して使うノート PC で本当に問題ない場合

この点は正直に考える必要があります。分離の効果を過大に説明すると、読者は話を聞かなくなるためです。

実行前にすべてのコマンドを確認しているなら、ノート PC で問題ありません。権限確認プロンプトは実際に機能する制御であり、サーバー上で Claude Code を安全に実行する方法では、各レベルで実際に何がブロックされるかを説明しています。マシン上に本番環境の認証情報がなく、作業対象が単一のリポジトリだけなら、影響範囲はすでに小さく抑えられています。エージェントのセッションが短く、監視下で実行しているなら、露出する時間も短くなります。

プロンプトを省略した時点で状況は変わります。2026 年 8 月 14 日に auto mode が Claude Code のデフォルトになることで、新規インストールではファイルの編集やコマンドの実行前に確認されなくなるため、この点は今のうちに考えておく価値があります。無人実行、夜間ジョブ、計画を承認してその場を離れるワークフローでは、封じ込めを担っていた人間による確認がなくなります。その場合は、マシン自体が封じ込めを担う必要があります。複数のリポジトリを同時に扱う VPS 上でコーディングエージェントを実行する方法など、エージェントの到達範囲を広げる構成にも同じことが当てはまります。

判断の基準は、モデルをどの程度信頼しているかではありません。モデルが誤ったとき、その隣に何が存在しているかです。

FAQ

コンテナだけでコーディングエージェントを十分に隔離できますか？

ほとんどの作業では十分です。ただし、2 つの条件があります。コンテナは --privileged で実行してはなりません。また、/var/run/docker.sock をコンテナ内にマウントしてはなりません。どちらも、プロセスがホストの root へ到達する経路になるためです。コンテナはホストのカーネルを共有するため、仮想マシンより境界が弱くなります。エージェントがインターネットから取得した信頼できないコードを実行する場合は、実際の仮想マシンまたは別のサーバーを使用してください。

エージェントにサーバー上の sudo は必要ですか？

いいえ。sudo を与えると、構築した隔離が失われます。root はサーバー上の他のすべてのアカウントを読み取れるためです。エージェント用ユーザーは sudo なしで作成し、自分の作業ディレクトリだけに書き込み権限を与えてください。本当にパッケージのインストールが必要なら、共有マシンの root 権限ではなく、エージェント専用のマシンを割り当ててください。

SSH key をサーバーに置かずに、エージェントから git に push するにはどうすればよいですか？

接続時に ssh -A で SSH agent を転送してください。署名要求は接続経由で送信され、private key はラップトップに残ります。そのため、ssh -T git@github.com が認証し、git push はサーバー上に private key がなくても動作します。ただし、接続中はそのサーバーの root が転送された socket を使用できます。他のユーザーと共有するマシンでは、リポジトリに限定した deploy key を使用してください。

エージェントにはどの程度のサイズの VPS が必要ですか？

エージェントの作業は主にファイルの編集、build の実行、test の実行です。そのため、モデルではなく build に合わせてマシンのサイズを決めてください。ホスト型モデルはプロバイダーのハードウェア上で実行されるため、ネットワークトラフィックは増えますが、ローカルの負荷はほとんど増えません。スクリプト作業なら 2 GB RAM から始め、リポジトリでコンテナを build するか、規模の大きいコンパイルを行う場合は 8 GB に増やしてください。

マシンはどのくらいの頻度で破棄して再構築すべきですか？

状態を説明できなくなった時点で再構築してください。少なくとも、マシン上の credential が漏えいした可能性がある場合は、必ず再構築します。日常的な状態のずれには、タスク間で新しい checkout を作成すれば対応できます。最初のエージェント実行前に取得した snapshot があれば、クリーンなシステムイメージへ戻せます。再構築が高コストに感じられるなら、それは使い捨てと呼んだマシン上で重要なものを運用している兆候です。