著者 コーディングエージェント用の使い捨てVM構築法
コーディングエージェントはノートPCではなく、10分で再構築できる使い捨てVMへ。被害範囲を抑え、タスクごとのクリーンな環境とsnapshotを安く実現するVPS構成を紹介します。
使い捨て VM がノート PC より優れている理由
コーディングエージェントに使い捨て VM を与えれば、最悪の場合でも、10 分で再構築できるマシンを破壊されるだけです。エージェントは root 権限を持ち、パッケージをインストールし、各手順で許可を求めることなくテストスイートを実行できます。違いは、被害が及ぶ場所です。ノート PC では、エージェントが SSH キー、ブラウザープロファイル、.env ファイル、そしてこれまでに clone したすべてのリポジトリがあるホームディレクトリを共有します。使い捨てサーバーにあるのは、シェル、checkout、そして持ち出す価値のあるものがほかに何もない環境です。
これが主張のすべてです。これは確率ではなく、非対称性に関する主張です。慎重なエージェントを慎重に使うノート PC なら、ほとんどの場合は問題ありません。問題が起きたときのコストは、悪い commit の修正ではありません。バックアップがあれば、そこからの復元が必要になります。
議論の前に影響範囲を定義する
影響範囲（blast radius）とは、あるプロセスが到達可能な対象の集合を指します。通常のユーザー権限で通常のPC上で実行されるエージェントにとって、その範囲は多くの人が想像するよりも広大です。
そこには、パスフレーズの入力が面倒で通常は暗号化されていない ~/.ssh/id_ed25519 が含まれます。設計上プレーンテキストである ~/.aws/credentials や ~/.config/gh/hosts.yml も含まれます。~/code 配下のすべての兄弟リポジトリも含まれ、その中にはローカルの env ファイルに本番環境への接続文字列が含まれているものもあるでしょう。一度貼り付けたトークンが残っているシェル履歴も含まれます。さらに、ラップトップが接続しているネットワークも含まれます。これは多くの場合、認証なしのサービスが稼働している自宅やオフィスのネットワークです。
これらすべてにおいて、悪意のあるエージェントは不要です。必要なのは、自信満々に間違ったコマンドを1つ実行することだけです。BUILD_DIR が未設定のまま実行される rm -rf "$BUILD_DIR"/* は /* に展開され、/ 自体の削除を拒否する GNU rm のデフォルト設定をすり抜けます。間違ったディレクトリでの git clean -xfd、ローカルデータベースを巻き込む docker system prune -af --volumes、ホームディレクトリに対する親切な chmod -R 777 なども同様です。エージェントは、他のすべての人にそれらのコマンドを教えたのと同じインターネット上で学習しています。
あなたを救うメカニズムは、エージェントの判断力ではありません。被害を受けるマシンが、あなたが失っても構わないと思えるものであるという事実です。
コスト計算は退屈ですが、それが重要な点です
小規模な VPS は、月に数ドルで利用できます。開発者のノート PC を復旧するには 1 日かかることがあります。しかもこれは、問題にすぐ気付き、バックアップもあるという、よいケースです。
自分の数字で計算してください。時給に、OS の再インストール、ホームディレクトリの復元、SSH key のローテーション、personal access token のローテーション、20 個のリポジトリの再 clone に必要な時間を掛けます。それを、プロバイダーが提供する最小構成のサーバーを 12 か月利用する費用と比較します。数年に 1 回未満のインシデントでも損益分岐点を超えます。しかも、基準を超えるために深刻なインシデントである必要はありません。ローカル環境の破損によって午後を 1 回失うだけで、年間費用を回収できます。
計算のもう半分はスナップショットです。リスクの高い処理を実行する前にスナップショットを取得しておけば、問題が起きたときに「環境をすべて復元する」のではなく、「ロールバックして別の prompt を試す」ことができます。いま入力に使っているノート PC では、この選択肢はありません。作業机として使っているマシンを、その使用中にスナップショット取得することはできないためです。
2026年10月時点の状況
「エージェントをどこで実行すべきか」という問いに対する誠実な回答は3つあり、それらは境界の堅牢さとセットアップの手間という2つの要素をトレードオフの関係にあります。
ローカルのマイクロVM。 このカテゴリのツールは、自身のハードウェア上で実際の仮想マシンを起動し、リポジトリをマウントして、内部でエージェントにroot権限を与えます。clawkが現在の代表例であり、その主張はまさに本稿のテーマそのものです。コーディングエージェントにはラップトップではなく、使い捨てのLinux VMを与えよ、というものです。2026年10月現在、Appleシリコン搭載のmacOS 14以降を対象としており、Firecrackerを通じた実験的なLinuxサポートも提供しています。インストールはbrew install clawkwork/tap/clawkで行います。リポジトリ内でclawkを実行してサンドボックスを起動しエージェントを接続し、clawk downで停止、clawk destroyで削除します。境界はハイパーバイザーであり、堅牢です。制限としては、VMが持ち運んでいるマシン上で動作するため、メモリリソースを競合し、ノートPCの蓋を閉じると停止してしまう点が挙げられます。
コンテナ。 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。 新しいツールは不要で、実際のカーネル境界があり、プロバイダーのスナップショット機能が使え、ノート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 ls /home/youls: cannot open directory '/home/you': Permission denied と表示されるはずです。ファイル一覧が表示される場合、ホームディレクトリが他のユーザーから読み取り可能になっています。その場合、エージェントは個別にロックされていない限り、世界から読み取り可能な .env ファイルなど、ディレクトリ内のあらゆるファイルを読み取ることができます。sudo chmod 700 /home/you を実行して修正してください。このテストは秘密鍵を保護するためのものではありません。ssh は他のユーザーがアクセス可能な秘密鍵ファイルを無視するため、実際に使用できている鍵であれば、ホームディレクトリのモードに関係なく agent からは読み取り不可になっています。
認証情報をマシン上に一切置かない
使い捨てマシンの目的は、本番環境の Secret をそこへコピーした時点で失われます。原則は単純です。そのマシン上には、今日の午後にローテーションしても構わないと思えない認証情報を置いてはいけません。
git では、key をコピーせずに SSH agent を転送します。private key は laptop 上に残り、接続を通過するのは署名要求だけです。
ssh -A agent@203.0.113.10
ssh -T git@github.com2 番目のコマンドは 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 エラーが発生し、その後に curl のバージョンに応じたメッセージが表示されるはずです。同じホストへの HTTPS リクエストは引き続き成功するはずです。
2つの重要な制限があります。第一に、これらのルールは保存しなければ再起動時に失われます。sudo apt install -y iptables-persistent を実行し、続いて sudo netfilter-persistent save を実行してください。第二に、これはポートとアドレスをフィルタリングするものであり、ドメイン名をフィルタリングするものではありません。ポート 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を安全に実行する方法では、各レベルで実際に何がブロックされるかを解説しています。作業対象が単一のリポジトリであり、マシン上に本番環境の認証情報が一切存在しない場合、影響範囲はすでに限定的です。エージェントのセッションが短時間で監視下にあるなら、リスクにさらされる時間も短くなります。
プロンプトの確認を省略した瞬間に状況は変わります。Claude Codeのデフォルトがオートモードになった現在、新規インストール時にファイル編集やコマンド実行のたびに確認を求められなくなったことを考慮する必要があります。無人実行、夜間ジョブ、計画を承認してその場を離れるようなワークフローはすべて、これまで人間が行っていた抑制機能を排除することになります。その場合、マシン側で制御を行う必要があります。これは、VPS上でコーディングエージェントを実行するなど、エージェントのアクセス範囲を複数のリポジトリに広げる場合も同様です。
この判断は、モデルをどれだけ信頼するかという問題ではありません。モデルが誤った動作をした際に、その隣で何が守られているかという問題です。
FAQ
コーディングエージェントの分離にはコンテナだけで十分ですか？
ほとんどの作業では十分ですが、2 つの条件があります。コンテナを --privileged で実行してはなりません。また、/var/run/docker.sock をコンテナ内にマウントしてはなりません。どちらも、プロセスからホストの root へ到達する経路になるためです。コンテナはホストのカーネルを共有するため、分離境界は仮想マシンより弱くなります。エージェントがインターネットから取得した信頼できないコードを実行する場合は、実際の仮想マシンまたは別のサーバーを使用してください。
エージェントにサーバー上の sudo は必要ですか？
いいえ。sudo を与えると、構築した分離が無効になります。root はサーバー上の他のすべてのアカウントを読み取れるためです。エージェント用ユーザーは sudo なしで作成し、自身の作業ディレクトリだけに書き込み権限を与えてください。本当にパッケージのインストールが必要な場合は、共有マシンの root ではなく、エージェント専用のマシン全体を割り当ててください。
サーバーに SSH 鍵を置かずに、エージェントから git に push するにはどうすればよいですか？
接続時に ssh -A で SSH agent forwarding を有効にしてください。署名要求は接続経由で送られ、秘密鍵はノート PC に残ります。そのため、ssh -T git@github.com で認証でき、サーバーに秘密鍵がなくても git push が動作します。ただし、接続中は、そのサーバーの root が転送されたソケットを使用できます。他の人と共有するマシンでは、リポジトリ単位の deploy key を使用してください。
エージェントにはどの程度のサイズの VPS が必要ですか？
エージェントの作業は、主にファイルの編集、ビルドの実行、テストの実行です。そのため、マシンのサイズはモデルではなくビルドに合わせて決めます。ホスト型モデルはプロバイダーのハードウェア上で実行されるため、ネットワークトラフィックは増えますが、ローカルの負荷はほとんど増えません。一方、エージェント自体にも最低要件があります。2026 年 10 月 20 日時点で、Claude Code のシステム要件では RAM 4 GB が最小値です。スクリプト作業でも 4 GB から始め、リポジトリでコンテナをビルドする場合や、規模の大きいものをコンパイルする場合は 8 GB に増やしてください。
マシンはどの程度の頻度で破棄して再構築すべきですか？
状態を説明できなくなった時点で再構築してください。少なくとも、マシン上の認証情報が漏えいした可能性がある場合は、必ず再構築します。日々の状態のずれには、タスク間で新しいチェックアウトを作成すれば対応できます。また、最初のエージェント実行前に取得したスナップショットがあれば、クリーンなシステムイメージへ戻せます。再構築にコストがかかると感じるなら、それは使い捨てと考えていたマシン上で、重要なものを運用している兆候です。