100 million buildsを支えるDepot、共有cacheでCIの待ち時間を削る

Depotの出発点は、Docker buildが遅いという、開発者なら何度も踏む小さな待ち時間だった。

2022年5月、Kyle GalbraithはDepotをclosed betaとして発表し、hosted container build serviceとpersistent intelligent cachingを組み合わせる構想を示した。出典

「What if all this was just handled for me?」とKyle Galbraithはlaunch記事で問いかけた。出典

遅いbuildをcacheの問題として捉える

当時の課題は、Dockerfileのlayer cacheを正しく書く知識だけではなかった。

laptopごとにcacheが重複し、CIではdisk制約のためcacheを保存・復元する手間が発生していた。

Depotはこの負担をremote builderとpersistent SSD cacheへ移した。出典

互換性を壊さずに速度を出す

DepotはBuildKitを動かし、DockerやOCIの出力形式に対応した。

既存のdocker buildをdepot buildへ置き換える導入方法を示し、IntelとArmのbuildもnativeに扱った。出典

buildからdelivery基盤へ

その後、Depotはcontainer buildsだけでなくDepot CI、registry、test results、agent sandboxesへ領域を広げた。

2025年の振り返りでは、1年間に100 million超のbuildを高速化したと報告している。出典

2026年3月にはFelicis、Y Combinator、Pioneer Fundから$10MのSeries Aを調達し、software deliveryの次の時代をつくるための資金だと説明した。出典

今のDepot

Depotは、CIを速くする単機能toolから、開発者とAI agentがcodeをdeliveryするまでの待ち時間を短くするinfrastructureへ変わりつつある。

複雑さを利用者へ返さず、cache・compute・workflowを一つの経路にまとめる姿勢が、Depotの物語の軸だ。

DepotのPMFは、Docker buildとCIの遅さを「Dockerfileを職人芸で最適化する問題」から「共有cacheを持つ専用computeへルーティングする問題」へ置き換えた点にある。

公式launch記事では、build cacheの管理が開発者のlaptopとCIの双方で重複し、既存CIのディスク制約が速度向上を打ち消すと説明している。出典

Docker互換のCLIとGitHub Actionsからの導入を維持したことで、既存workflowを捨てずに速度だけを改善したいチームに刺さる。

2025年に100 million超のbuildを扱った実績は、単なるbenchmarkではなく反復利用の規模を示す材料だ。出典

最大の堀は、単なるrunnerの台数ではなく、Docker cache・BuildKit・CI workflow・registryを横断して蓄積される運用知識と実行基盤だ。

共有persistent cacheは、同じ組織のlocalとCIをつなぎ、使うほど切替コストを上げる。出典

ネットワーク効果は弱い。

利用者が増えても外部ユーザー同士の価値が直接増えるわけではなく、主な価値は同一organization内のcache共有に閉じる。

ただし、既存workflow・integrations・communityの増加は間接的なecosystem効果になる。出典

主な対象は、Docker imageを頻繁にbuildする開発チーム、GitHub ActionsのCIが遅くなったplatform team、AI agentの実行pipelineを高速化したいengineering organizationだ。

小規模な単発projectや完全に自前運用したいチームには、月額と外部依存が合わない可能性がある。出典

第一に、BuildKitのlayer cacheをpersistent diskへ載せ、cache管理をサービス側へ寄せたこと。

第二に、Docker CLIやGitHub Actionsとの互換性を保ち、導入の切替コストを抑えたこと。出典

第三に、Docker buildだけでなくCI、registry、test results、agent sandboxesへ拡張し、build待ち時間をdelivery全体の問題として扱ったことだ。出典

Depotは高速computeとcacheを前提にするため、利用量が少ない個人開発者には月額費用と設定の複雑さが相対的に重くなりうる。

公式pricingでもDeveloperは月$20、Startupは月$200で、無料枠だけで無制限に使える設計ではない。出典

また、CI基盤を外部サービスへ寄せるほど、障害時のbuild依存とデータ・権限管理の検討が必要になる。

Depotはsecurity文書やcustomer AWS account optionを用意しているが、各組織のcompliance適合性は個別確認が必要だ。出典

初期はDocker buildの速度という狭い痛みから入り、Docker互換CLIとGitHub Actionsで既存pipelineへ接続する。

そこからCI、test results、registry、agent向け機能を足し、build時間を削る道具からsoftware deliveryの基盤へ広げる戦略だ。出典

content、docs、changelog、developer ecosystemで導入を支える一方、専用computeを売るため、セルフサーブの低価格層とenterprise要件の両立がトレードオフになる。出典

主要チャネル: content, developer-community, github-actions-ecosystem, partner-programs

高価なcomputeを売るだけではなく、既存のDockerfile・CLI・GitHub Actionsをそのまま入口にしたことで、性能改善を移行プロジェクトにしなかった点が学びになる。

差別化は機能数ではなく、cacheのように毎回発生する摩擦を共有資産へ変えることで作れる。出典

日本で展開するなら、CIの待ち時間を人件費と開発者体験の両面で可視化し、円建ての料金・国内リージョン・監査ログを前面に出すとよい。

特に受託開発や大規模社内platformでは、build cacheの共有をチーム生産性の指標へ接続できる。

ただしデータ residencyとAWS account運用の要件は企業ごとに要確認。出典