Clawkとは？Claude Codeを使い捨てVMで動かす新ツール

Claude Codeでコマンド実行のたびに許可を求められて、そのつど手を止められる——このわずらわしさ、使い込んでいる人ほど身に覚えがあるはずです。

かといって --dangerously-skip-permissions で全部自動承認にすると、AIが暴走したときに開発機ごと壊れるかもしれない不安がついて回ります。

この板挟みに正面から答えを出したツールが「Clawk」です。

2026-07-13のShow HNで222pt/156コメントを叩き出し、GitHubスターは662★（2026-07-17時点）まで一気に伸びました。

以下、記事内の「Clawk」は clawkwork/clawk のことを指します（同名の別プロダクトが複数存在するため）。

Clawkとは何か？ Claude Codeを使い捨てVMで動かす新ツール

GitHub - clawkwork/clawk: Give coding agents a disposable Linux VM, not your laptop

Give coding agents a disposable Linux VM, not your laptop - clawkwork/clawk

github.com

一言でいうと、Claude CodeやCodexといったコーディングエージェントを、いつでも壊して捨てられる軽量Linux VMの中で走らせるためのCLIツールです。

作者はcelrenheit、言語はGo、ライセンスはApache License 2.0。

リポジトリ作成は2026-07-06と、まだ生まれて10日ほどの若いプロジェクトです。

使い捨てLinux VMという設計思想

名前は「claw（爪）」と映画『時計じかけのオレンジ（A Clockwork Orange）』のもじり。

ゼンマイを巻いて放ち、いつでもリセットできる自動人形——というイメージが、Clawkの思想そのものです。

VMは軽量なLinuxイメージで、AIエージェントの作業が終わったら丸ごと捨てます。

ホストのファイルや秘密鍵にアクセスさせないまま、ゲスト内では「何をしてもいい」という自由をエージェントに与える。

「制限する」のではなく「壊れてもいい場所に置く」——この非対称な設計が肝です。

Claude Code・Codex・OpenCode・汎用シェルに対応

対応しているエージェントは現時点で4種類。

シェル経由なら他のCLIエージェントも動かせるので、実質「Claude Code特化」ではなく「CLIエージェント汎用の隔離ランナー」と考えるほうが正しい位置づけです。

では、なぜここまでして「使い捨てVM」にこだわる必要があるのか。

次の章で、その理由に踏み込みます。

なぜClaude Codeに使い捨てVMが必要なのか

Claude Codeを本気で使い込むと、必ずぶつかる悩みが「許可プロンプトのわずらわしさ」です。

コマンド実行のたびに承認を求められる、ファイル書き込みでも聞かれる、長時間の自律作業をさせようとすると承認待ちで放置できない——この体験のストレスは、使っている人なら分かるはずです。

許可プロンプトを消したいが、安全に済ませたい

回避策としてよく使われるのが --dangerously-skip-permissions（bypassPermissions）フラグ。

ただしAnthropic公式のドキュメントには「隔離されたコンテナ/VM/専用環境の中でのみ使うべき」と明記されています。

想像してみてください。

フルオープンで動くAIが rm -rf ~/ を打った瞬間、開発機が壊れます。

Clawkは、この「隔離された環境」の部分を、コマンド1つで用意してくれるツール——と理解するのが正確です。

Anthropic公式が示す運用ラインに、真正面から答える設計になっています。

Dockerコンテナとの違い（カーネル共有 vs 仮想化分離）

「Dockerコンテナで動かせばいいのでは？」という疑問には、作者本人がShow HNで技術的に回答しています。

普段Dockerでコンテナを回している人ほど、この違いはピンとくるところでしょう。

コンテナは同じ建物の中の一室を借りるようなもので、壁の向こう側（カーネル）は住人全員で共有しています。

VMは建物ごと自分専用に建てて、使い終わったら丸ごと解体するイメージです。

k8sやDockerを触るテストをコンテナ内で回そうとするとDocker-in-Dockerになって不格好、というのはよく分かる話です。

VMなら、ゲストの中でDockerがそのまま動きます。

いつものDocker運用フローをそのまま持ち込めて、しかもホストのカーネルとは完全に切り離されている——コンテナ派のエンジニアほど、この差は効いてくるはずです。

次はこのVMを実際に手元へ持ってくる方法を見ていきます。

Clawkのインストール方法と対応環境

対応環境は現時点で次の通り整理できます。

macOSではAppleが提供する仮想化フレームワークを使うため、root権限もカーネル拡張も不要です。

社給のMacに、勝手にkext（カーネル拡張）なんて入れられない——そういう制約のある環境で働いている人ほど、このハードルの低さがありがたく感じるはずです。

Homebrewでのインストール

正式手順はHomebrewです。

コマンド1行で終わります。

brew install clawkwork/tap/clawk

これでバイナリが入ります。

あとは clawk run claude を叩くだけ。

内部でVMが立ち上がって、Claude Codeがゲストの中で動き出します。

ソースからのビルド（Linuxは実験的）

Linuxで試したい場合はGo 1.26+でソースビルドしつつ、Firecrackerのセットアップが必要です。

TAPデバイスを触るのでroot権限が要りますし、環境依存で動作が変わる領域なので、本番運用は避けて検証環境で試すのが無難です。

インストールが終わったら、いよいよ実際の使い方です。

Clawkの基本的な使い方

clawk コマンドでVM起動してClaude Codeに接続

コマンド一発で軽量Linux VMが起動し、その中でClaude Codeが実行されます。

ホストから見ると、VMの内側でエージェントが自由に動いている状態。

作業が終わったらVMを破棄し、次のタスクではまたゼロから作り直す——この繰り返しがClawkの基本サイクルです。

「毎回作り直すの重くない？」と思うかもしれませんが、Apple純正の Virtualization.framework は起動がかなり速く、体感で待たされる時間は短めです。

ネットワークallow-listとセッションの復帰・削除

面白いのはネットワーク制御です。

iptables/nftablesを使わず、gvproxy をフォークして作った独自のユーザー空間allow-listで実装されています。

ゲスト側からは回避できない位置でフィルタリングされるので、AIが勝手に外部にデータを送りつける、というリスクを絞れます。

フルオープンでrootを渡していても、外に出せる通信先はこちらでコントロールできる——この二段構えが安心材料になります。

また clawk work を使うと、複数のリポジトリを別々のworktreeとして1つのVM内に配置し、横断した作業ができます。

類似ツールにはあまりない独自機能で、モノレポで運用していないチームには特に効いてくる機能です。

基本の使い方はここまでです。

気になるのは「結局、他のツールと何が違うのか」でしょう。

次で整理していきます。

Claude Codeサンドボックス・類似ツールとの違い

Claude Codeネイティブサンドボックスとの違い（制限をかける vs 全開放して隔離する）

「Claude Codeにはネイティブのサンドボックス機能があるのでは？」という疑問への答えを整理します。

真逆の設計思想ですが、対立というより「別解」です。

「危険な操作を禁止する」か、「危険な操作をやらせてから壊れたら捨てる」か——どちらを選ぶかは好み次第です。

制限を細かく設計したい人はネイティブ、開放してVM境界で守りたい人はClawk、という棲み分けになります。

海外の類似ツール（yoloai・Fly.io Sprites等）との位置づけ

Show HNでは「これで30個目のAIサンドボックス系プロジェクトだ」という皮肉コメントが飛んでいます。

実際、yoloai、Fly.io Sprites、virtdev、take-ai-control、byre など、海外では類似コンセプトのツールが乱立しているのが現状です。

「またか」と感じても不思議ではありません。

ただ、乱立している=中身が同じ、とは限りません。

作者はClawkの独自性として、clawk work によるmulti-repo worktreesと、ローカルファーストで完結する完全制御ネットワーク（外部SaaSに社内コードを送らない）の2点を挙げています。

特に後者は、社内コードを外部SaaSに一切渡さずに完結する設計だという点で、日本企業が導入を検討するときの障壁を一つ減らしてくれます。

「30個目」という皮肉に飲まれず、自分のワークフローに合うかどうかで判断するのが賢明です。

気になるのは、実際に使うとなったときの注意点でしょう。

次で率直に見ていきます。

Clawkを使う上での注意点と現状の限界

万能ツールではないので、注意点も正直に触れておきます。

対応環境の制約と実験的サポート

現時点で本番運用に耐えるのはmacOS 14+ Apple Siliconだけ、と考えるのが安全です。

LinuxはFirecracker依存で実験的サポートの明記があり、Windowsは対応予定すら公開されていません。

チームで導入する場合、開発機の統一がほぼ前提になります。

「VM級の隔離は本当に必要か」という論争との向き合い方

Show HNのコメント欄では「隔離用の別ユーザーを作るだけで十分では」という懐疑派と、作者との長い技術論争が起きています。

これに対して作者は、「別ユーザー隔離ではホストとカーネルを共有してしまうため、カーネルレベルの脆弱性に対する防御にはならない」と回答しています。

VMなら仮想化によってゲストカーネル自体が分離されるので、より攻撃対象領域が小さい、という理屈です。

「そこまで厳密にやる必要ある？」と思うかもしれませんが、これは要件次第です。

個人開発でファイルを守りたいだけなら別ユーザー隔離で十分な場面もあります。

Anthropic公式の推奨に沿って「dangerously-skip-permissions を心置きなく使いたい」なら、Clawkのようなツールが選択肢に入ってきます。

まとめ：Claude Codeの自動承認を安全に使いたい人向け

Clawk（clawkwork/clawk）は、Claude Codeを始めとするCLIエージェントを、使い捨てLinux VMで走らせる新しめのツールです。

ポイントを整理すると、

• macOS 14+ Apple Siliconなら brew install clawkwork/tap/clawk で即導入できる
• root権限もカーネル拡張も要らない設計で、社給Macでも入れやすい
• Claude Codeネイティブサンドボックスとは真逆の「全開放して隔離する」思想
• 弱点は対応OSの狭さと、市場飽和したAIサンドボックス界隈での差別化がまだ進行形なこと

--dangerously-skip-permissions を使いたいけどローカルを守りたい、という悩みにストレートに応えるツールです。

macOS Apple Siliconの環境が手元にあるなら、まずは brew install clawkwork/tap/clawk を打って clawk run claude を叩いてみてください。

コマンド一発でVMごと壊せる気楽さを体感するのが、一番早い判断材料になります。