Tobi Lütke氏の「wrapvm」 エージェントに画面付きの使い捨てVMを渡す
ShopifyのTobi Lütke氏がGitHubで公開した「wrapvm」は、ブラウザとデスクトップを載せた仮想マシンを作業フォルダごとに立て、エージェントに画面の操作を任せる。手元のPCの画面や鍵には触らせない作りだ。
記事の内容を自社でどう進めるか、内容が固まっていない段階でも相談できます。仕事の相談
毎週 1 回、その週の記事から 5 本と実践の 1 本を選んでメールで届けます。ニュースレターを購読する(無料)

ShopifyのTobi Lütke氏が、エージェント向けのデスクトップ付き仮想マシン「wrapvm」をGitHubで公開した。作業フォルダごとに1台の仮想マシンを立て、その中のChromeとデスクトップをエージェントに操作させる。人は手元のブラウザから画面をのぞくだけで、手元のPCのブラウザや鍵はエージェントに渡らない。ブラウザ操作をエージェントに任せたいが、自分のPCをそのまま触らせるのは怖いという読者に、1つの答えの形を示した。
画面の操作は危ない作業になりやすい
コーディングエージェントにブラウザを動かさせると、作った画面を確かめたり、管理画面で設定を変えたりする作業まで任せられる。ただし手元のPCで動かせば、ログイン済みのブラウザや、ホームのディレクトリにある設定と鍵にも手が届く。間違ったクリック1つで、本番の画面を書き換えるおそれもある。
wrapvmは、この作業を手元から切り離す。Lütke氏の別の道具「wrap」は、今いるフォルダを中心に、使い捨てのArch Linuxの仮想マシンを作り、その中でコマンドやエージェントを動かす。wrapvmは、wrapのデスクトップ版のイメージを土台に、画面とブラウザの操作に要る部品をまとめた。
フォルダごとに1台、中に画面とブラウザ
中身は、画面を描く仮想のディスプレイ(XvfbとXFCE)、常に動き続けるGoogle Chrome 1つ、ブラウザを操作する「agent-browser」、デスクトップのアプリを操作する「agent-desktop」だ。Chromeはデバッグ用の口(CDP)を9222番で開き、agent-browserはそのChromeにつながる。エージェント向けの手順書(スキル)として「desktop」と「browser」も入れてある。音はPulseAudioに流し、ffmpegで録画もできる。
使い方は短い。プロジェクトのフォルダで同梱のwrapvmのスクリプトを動かすと、そのフォルダ用の仮想マシンを作って起動し、中のシェルを開く。スクリプトは、フォルダの名前とパスのチェックサムから仮想マシンの名前を決めるので、同じ名前のフォルダが2つあっても混ざらない。仮想マシンの管理には「smolvm」を使う。Dockerのコンテナとして6080番だけを手元に開いて動かす方法も、READMEに載っている。
人は、手元のブラウザで6080番を開けば、パスワード付きで中の画面をのぞける。中の画面はH.264の映像としてブラウザに流れる。エージェントが今どの画面で何をしているかを、手元の作業を止めずに見守れる。スクリプトは起動のたびに、中の画面の入口のリンクを用意できるまで最大でおよそ1分待ち、手元の端末に出す。手元の6080番がふさがっている時は、環境変数で別の番号に変えられる。
鍵は手元に置いたまま渡す
安全の要は、設定ファイル「Smolfile」にある。仮想マシンは4 CPU、メモリ8GBで動き、作ったフォルダだけを中の作業用ディレクトリに見せる。ネットワークは、家や社内のLAN、手元のPC自身、クラウドの管理用の窓口などの内向きの宛先を、初めから塞ぐ。必要な範囲だけを設定で開け直す。
GitHubとAnthropicの鍵は仮想マシンの中に置かない。GitHubとAnthropicのAPIへの通信にだけ、仮想マシンの外で鍵を付ける。中のgitやgh、エージェントは、見かけだけの値を持って普通に動く。初回の起動では、Claude Code、Codex、piなどのエージェントを中に入れる。
元になったwrapも、同じ考え方をとる。READMEによると、ネットワークは許した宛先だけに絞り、手元のエージェントの設定は頼んだ時しか中に写さない。作業は特権の無い利用者として動かす。READMEは使い道として、エージェントにプルリクエストをレビューさせる、知らないリポジトリを手元に入れずに試す、といった場面を挙げている。wrapvmは、その使い道に画面とブラウザを足した形だ。
試す前に押さえる条件
wrapvmは個人のリポジトリで、コミットの履歴は10月末に始まり、11月上旬までで7回だ。リリースの版はまだ無く、READMEは部品と使い方の説明が中心だ。動作の保証や、長く手入れを続けるかどうかは書かれていない。
Containerfileを読むと、Chromeは既定でサンドボックスを有効にしたまま動く。ただし、rootで動かす時と、Dockerの既定の設定のようにChromeが要る仕組みを拒む環境では、サンドボックスを外して起動する。Dockerで手軽に動かすと守りが1枚減るので、smolvmで仮想マシンとして動かす方が作者の想定に近い。
wrapvmが示したのは、エージェントに画面の操作を任せる時は、手元のPCではなく、フォルダごとの使い捨ての仮想マシンを渡すという形だ。鍵と内向きの通信を外側で押さえる作りは、自分で同じ環境を組む時の手本にもなる。
編集部の見方
編集部は、wrapvmの価値を道具そのものより、エージェントに画面を任せる時の安全の線の引き方にあると見る。見るのは画面の数ではなく、作業フォルダ、内向きの通信、鍵の3つをどこで区切るかだ。読者が試すなら、まず捨ててよいフォルダで動かし、管理画面にログインさせる前に、開いた宛先と鍵の範囲を設定ファイルで確かめるとよい。個人のリポジトリで版の約束も無いので、そのまま業務の土台にするのは早い。手入れが続くかは、まだ分からない。
出典
に確認(日本時間)
- Tobi Lütke氏(github.com)
- GitHubで公開(github.com)
- wrap(github.com)
- スクリプト(github.com)
- Smolfile(github.com)
- コミットの履歴(github.com)
- Containerfile(github.com)
この記事は役に立ちましたか
ありがとうございます
ありがとうございます



