Cleanroom - repository task を policy-controlled microVM に閉じ込める CI sandbox

いま、多くの team がより複雑な作業を automation に渡しています。CI は test を走らせるだけではありません。Code generation、migration check、dependency download、image build も行います。AI coding agent は repository を読み、command を実行し、file を変更し、人間の review に渡す結果を作ります。

しかし、これらの task が code を実行できるなら、それは単なる便利 tool ではありません。Credentials に触れるかもしれない。Internal service にアクセスするかもしれない。Host の file を読むかもしれない。あるいは、外へ出してはいけない data を network に送るかもしれない。

Container は隔離の一部を解きますが、container boundary と VM boundary は同じではありません。速度と便利さを優先した CI environment では、container に広い network、mount、credential permission が与えられがちです。今日紹介する buildkite/cleanroom は、もう少し狭い問題を扱います。Self-hosted environment で repository workload を policy-controlled microVM に入れ、network、image、credential、workspace sync の境界を明確にする tool です。

公開時点の GitHub page では、およそ 49 stars、2 forks。主な言語は Go、license は MIT です。Project は 2026-02-16 に作成され、現在も active に更新されています。Latest release は v0.11.0 で、2026-06-06 に公開されています。

プロジェクト概要

項目	内容
Repository	buildkite/cleanroom
位置づけ	Self-hosted, policy-controlled microVM sandbox
Stars	約 49
Forks	2
主な言語	Go
License	MIT
Latest release	v0.11.0

「repository command を実行する」を複数の境界に分ける

Cleanroom の中心は、もう一つの general-purpose CI runner を作ることではありません。「この command は何に触れてよいのか」を分解して管理することです。

README では、次のような boundary が強調されています。

• Container namespace だけではなく、hardware virtualization の microVM を使う。
• Network は default deny。Repository 内の cleanroom.yaml で明示的に destination を allow する。
• Credentials は host side に置き、host-side gateway が git clone、package fetch、upstream request を代理する。
• Sandbox base は standard OCI image を使い、policy では digest pinning を促す。
• Repository execution は copy-in、copy-out、sync を明示し、host workspace を自動的に丸ごと見せない。

この設計は、現代の CI と agent の場面によく合います。問題は「code が container から逃げないか」だけではありません。「package registry に行けるのか」「どの commit を見ているのか」「generated file を host に戻せるのか」「token を guest に渡さず private dependency を clone できるのか」も重要です。Cleanroom はそれらを同じ policy surface に置きます。

cleanroom.yaml が主要な interface

Cleanroom は repository root の cleanroom.yaml を確認し、fallback として .buildkite/cleanroom.yaml も確認します。この file は sandbox image、resources、network、dependency cache、service preparation などを記述します。

Network policy の簡略例は次のような形です。

version: 1
sandbox:
  image:
    ref: ghcr.io/buildkite/cleanroom-base/debian@sha256:...
  resources:
    vcpus: 4
    memory: 8GiB
    disk: 16GiB
  network:
    default: deny
    allow:
      - api.github.com:443
      - registry.npmjs.org:443

この file の価値は audit 可能性です。Test task がどこへ access できるのかが、runner config、Docker argument、script の奥に隠れません。Repository と一緒に review できます。Supply chain risk を制御したい team にとって、「CI machine は internet に出られる。test の中で気をつける」よりもずっと明確です。

microVM は見せかけではなく、隔離 model を明確にするため

Cleanroom は Linux の Firecracker と、macOS の Virtualization.framework backend を support します。README では、container isolation ではなく hardware VM isolation と説明されています。

この選択には実務上の意味があります。

一つ目は、guest kernel と host kernel の間に VM boundary があることです。Container は host kernel を共有しますが、microVM は一回の execution に小さな virtual machine を与える考え方に近いです。もちろん risk がなくなるわけではありません。しかし boundary の種類が違います。

二つ目は、Cleanroom が VM 由来の performance と usability の問題を扱う必要があることです。毎回重い VM を cold start するという話ではなく、warm path の fast VM creation、image rootfs materialization、dependency cache、service cache を重視しています。つまり、microVM を rare high-risk job の専用道具ではなく、日常の build/test loop に入る cost へ近づけようとしています。

これは重要です。Isolation tool が遅すぎると、team は最後には bypass します。Cleanroom が面白いのは、security boundary と CI speed を同時に設計しようとしている点です。

Credentials は host side に残す

CI sandbox で難しい問題の一つは credentials です。Private repository を build する、private package を pull する、artifact registry にアクセスする。多くの場合 token が必要です。Token を guest にそのまま注入すると、隔離 boundary は弱くなります。不信な code が environment variable を読み、process を観察し、log に書き、外へ送る可能性があるからです。

Cleanroom は host-side gateway を使います。README によれば、gateway は git clone、package fetch、OCI image、Go modules、RubyGems、immutable downloads などを代理し、upstream request の側で credentials を注入できます。Guest が見るのは controlled proxy であって、raw token ではありません。

すべての case を一度に解くわけではありませんが、方向はよいです。CI と agent にとって危険なのは、「command を実行できる」ことだけではなく、「command を実行している間に広い credentials を拾える」ことです。Credentials を host boundary の外に置き、egress allowlist と組み合わせることで、damage surface を小さくできます。

Repository-aware execution: 空の sandbox を開くだけではない

Cleanroom は repo-agnostic sandbox を作って command を実行できます。

cleanroom doctor
cleanroom sandbox create --image ghcr.io/buildkite/cleanroom-base/alpine:latest
cleanroom exec --in <sandbox-id> -- uname -a

ただし CI に近い使い方は repo-aware run です。README の例では --repo-url で GitHub repository を指定し、sandbox bootstrap の前に具体的な commit へ解決し、その commit 上の policy を読み、command を実行します。

cleanroom exec \
  --repo-url https://github.com/buildkite/agent.git \
  -- mise x -- go run . --version

これにより、よくある曖昧さを避けられます。Sandbox は local dirty workspace を見ているのか、branch head を見ているのか、それとも CI が見るべき committed code を見ているのか。Cleanroom はそれを明示させます。Uncommitted local changes には --copy-in や --sync を使い、generated result には --copy-out を使います。

この explicit sync は AI agent にも向いています。Agent は isolated environment で test を走らせ、file を生成し、修正を試し、review すべき結果だけを host に戻せます。Host context 全体を最初から持つ必要はありません。

Service を host 側へ expose できる

Isolation は、完全に interaction を失うことではありません。Cleanroom は sandbox の実行中に service を host へ expose できます。Raw TCP も local HTTPS route も扱えます。README の例では、sandbox 内の PostgreSQL を host の 127.0.0.1:15432 に出す形や、development server を cleanroom.localhost 配下の HTTPS route として出す形があります。

これは現実的な test では重要です。多くの repository は go test や npm test だけではありません。Database、Web server、browser test、integration service が必要です。Cleanroom は service を許しつつ、その expose action を policy と command の一部にします。

v0.11.0 の焦点: repository-aware creation と policy hardening

Latest release の v0.11.0 は、repo-aware sandbox creation、explicit system warmup、gateway/policy hardening に焦点を当てています。

Release note では、remote caller が sandbox creation 時に repository checkout を渡せるようになったと説明されています。Caller が自分で policy を compile して送らなくても、Cleanroom が checkout を concrete commit に解決し、その commit から cleanroom.yaml または .buildkite/cleanroom.yaml を読み、policy を compile して creation path を続けます。

これは、Cleanroom を他の system から呼び出せる sandbox control plane に近づけます。CI platform、internal developer tool、agent orchestrator は、「この repository のこの revision を実行したい」と Cleanroom に渡し、Cleanroom が repository policy に従って sandbox を作れます。

同じ release には security hardening も含まれます。Policy host、DNS、Git gateway port、OCI cache scope、unknown key ID の JWKS refresh、retained execution output、Git mirror command output などの扱いが tightened されています。この種類の tool では、security detail は周辺機能ではなく product の中心です。

どこに置くとよいか

Cleanroom は三つの場面で考えたい tool です。

一つ目は self-hosted CI です。Team がすでに自分たちの runner を持ち、third party に workload を渡さず、高リスクな test、dependency install、code generation、build task をより強い isolation に入れたい場合です。

二つ目は AI coding agent です。Agent は repository command を実行する必要がありますが、host file、credentials、任意の network access を当然のように持つべきではありません。Cleanroom は agent の execution layer になり、明確な policy の下で試行錯誤させられます。

三つ目は supply-chain-sensitive な build/test です。Third-party generator、plugin、script、不完全に信頼できる test fixture を実行する必要があるが、network access は declared host に限定したい場合です。

注意したい boundary

Cleanroom はまだ若い project です。採用時には boundary を見る必要があります。

• microVM は absolute safety ではなく、host configuration、backend capability、update maintenance が必要です。
• Linux Firecracker と macOS darwin-vz の capability は完全に同じではなく、README も macOS backend には gaps があると明記しています。
• Network allowlist は maintenance cost を増やします。Modern frontend や multi-language repository は dependency source が多いからです。
• Credential proxy と cache mechanism を team が理解していないと、「なぜこの package が取れないのか」で時間を使います。
• Self-hosted CI/runner capability を持つ team に向いた tool であり、browser だけで使う lightweight tool ではありません。

この type の tool は demo だけでは判断しにくいです。試すなら、まず dependency relationship が clear な小さな repository を選び、minimum cleanroom.yaml を書き、cleanroom doctor、policy validate、repo-aware test を実行し、その後に cache、service、network rule を足していくのがよいでしょう。

まとめ

buildkite/cleanroom が注目に値するのは、CI、agent、supply chain risk の現実的な問題を一つの設計に集めているからです。Isolation strength、default-deny network、credentials outside guest、repository policy、explicit workspace sync、そして他 system から呼べる execution API です。

すべての CI runner をすぐ置き換える general answer ではありません。MicroVM を使えば安全、という単純な話でもありません。より正確には、repository task の boundary をより明確に書くための tool です。Automation と agent により多くの code execution を任せる team にとって、この種の boundary はこれからさらに重要になります。