コーディングエージェントに使い捨てVMを与える理由

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

コーディングエージェントに使い捨て VM を与えれば、エージェントができる最悪のことは、10 分で再構築できるマシンを破壊することです。エージェントは引き続き root を取得し、パッケージをインストールし、すべての手順で許可を求めずにテストスイートを実行できます。違いは、被害が及ぶ場所です。ノート PC では、エージェントは SSH キー、ブラウザプロファイル、.env ファイル、これまでに clone したすべてのリポジトリがあるホームディレクトリを共有します。一時的なサーバーでは、エージェントにあるのは shell と checkout だけで、他に取得する価値のあるものはありません。

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

議論する前に被害範囲を明確にする

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

その範囲には、通常は暗号化されていない ~/.ssh/id_ed25519 が含まれます。これは、パスフレーズの入力に疲れたためです。設計上プレーンテキストになっている ~/.aws/credentials と ~/.config/gh/hosts.yml も含まれます。~/code 配下にあるすべての兄弟リポジトリも含まれます。ローカルの env ファイルに本番環境の接続文字列があるリポジトリも対象です。1度貼り付けたトークンが残っているシェル履歴も含まれます。さらに、ラップトップが接続しているネットワークも含まれます。そこは、多くの場合、認証なしのサービスが存在する自宅またはオフィスのネットワークです。

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

被害を抑える仕組みは、エージェントの判断力ではありません。被害を受けるマシンが、失っても構わないと考えていたマシンであることです。

コスト計算が退屈なのは、それが重要だからです

小規模な VPS は月に数ドルで利用できます。開発者用 laptop の復旧には1日かかります。しかも、すぐに問題に気付き、backup があるという、まだ良いケースです。

自分の数字で計算してください。時給に、operating system の再インストール、home directory の復元、SSH key のローテーション、personal access token のローテーション、20個の repository の再 clone に必要な時間を掛けます。その金額を、provider が提供する最小の server を12か月利用する費用と比較してください。損益分岐点は数年に1回未満の incident です。しかも、基準を超えるために catastrophic な incident は必要ありません。破損した local environment の復旧で午後を1回失うだけで、年間費用に達します。

計算の後半は snapshot です。リスクのある実行の前に snapshot を作成すると、悪い結果を「生活を復旧する」作業から「ロールバックして別の prompt を試す」作業に変えられます。今これを入力している laptop では、その選択肢はありません。机として使っている最中の machine を snapshot できないためです。

2026年7月時点の選択肢

「エージェントをどこで実行すべきか」について、適切な答えは3つあります。いずれも、境界の強さと、許容できるセットアップ量という同じ2つの要素のバランスで決まります。

ローカルのmicro VM。 このカテゴリのツールは、使用中のハードウェア上で実際の仮想マシンを起動し、リポジトリをその中にマウントして、エージェントに内部のroot権限を与えます。clawk が現在の例です。その主張は、この記事の結論そのものです。コーディングエージェントにはノートパソコンではなく、使い捨ての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ソケットをコンテナにマウントすることは、そのコンテナにホスト上のroot権限を与えることと同じです。

再構築できる通常のVPS。 新しいツールは不要で、実際のカーネル境界があり、プロバイダーのスナップショットを利用でき、ノートパソコンを閉じても実行を継続します。このガイドの残りで説明する方式であり、長時間実行するエージェントに適しています。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 で修正します。

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

使い捨てマシンの目的は、本番環境の秘密情報をコピーすると損なわれます。ルールは単純です。そのマシン上には、今日の午後にローテーションしても構わない認証情報以外を置かないでください。

git では、鍵をコピーせずに SSH agent を転送します。秘密鍵はノート PC に残り、接続経由で署名要求だけが送られます。

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. と応答するはずです。これにより、サーバー上に鍵ファイルがなくても git push が機能することを確認できます。その後、マシン上で ls -la ~/.ssh を実行し、秘密鍵が存在しないことを確認してください。

agent forwarding には重要な注意点が1つあります。接続中は、そのサーバー上で root 権限を持つユーザーが転送されたソケットを使い、あなたとして認証できます。そのサーバーの他のユーザーがあなただけなら、これは許容できるトレードオフです。共有マシンでは許容できません。その場合は、1つのリポジトリだけに範囲を限定した deploy key のほうが適切です。選択肢については SSH 鍵管理の基本 で説明しています。

API key には専用の支出上限を設定した専用の鍵を用意し、agent ユーザーが所有する mode 600 のファイルに保存します。マシンを破棄するときは、その鍵が漏えいしたかどうかを心配するのではなく、鍵を失効させてください。鍵ごとのモデル利用額を確認できるようにしておくことが、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 で失敗するはずです。rejectルールが直ちに応答し、接続をハングさせないためです。同じホストへのHTTPSリクエストは、引き続き成功するはずです。

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

タスク間でクリーンな状態にリセットする

タスクごとにクリーンな状態にすることは、過小評価されがちな利点です。前のチケットに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 バックアップを使って適切にバックアップしてください。破棄できるマシンが役立つのは、破棄しても本当に問題が起きない場合だけです。

複数のサーバーに費用をかけず、複数の分離された環境が必要な場合は、1台の大きな VPS で guest VM を直接ホストできます。VPS での nested virtualisationでは、その仕組みと、provider が許可しているか確認する方法を説明しています。

ノートPCで十分な場合

この点は正直に説明してください。分離を過度に強調すると、読者は話を聞かなくなります。

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

プロンプトを無視した時点で、判断は変わります。無人実行、夜間ジョブ、計画を承認してその場を離れるワークフローでは、封じ込めを担っていた人間による確認がなくなります。その場合は、マシン自体が封じ込めを担う必要があります。複数のリポジトリに対して同時にVPS上でコーディングagentを実行する場合など、agentの到達範囲を広げるものにも同じことが当てはまります。

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

FAQ

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

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

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

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

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

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

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

エージェントの作業は主にファイルの編集、build の実行、test の実行です。そのため、マシンのサイズは model ではなく build に合わせて決めてください。hosted model は provider の hardware 上で動作するため、network traffic は増えますが、ローカルの負荷はほとんど増えません。スクリプト作業では 2 GB RAM から開始し、repository が container を build する場合や、大規模なコンパイルを行う場合は 8 GB に増やしてください。

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

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