Turborepo、monorepoの遅さをキャッシュで解いた開発基盤の設計

冒頭では、Turborepoはmonorepoの「全部を毎回ビルドする」問題を、タスクのキャッシュという一点から解こうとした。

現在はVercelの開発基盤に組み込まれ、localとremoteの両方で同じ考え方を使える。出典

創業のきっかけ

Jared Palmerは、複数パッケージをまたぐ開発で、変更していない処理まで繰り返す無駄に向き合った。

Turborepoはこの痛みを、巨大な統合サービスではなく開発者がCLIで導入できるbuild systemとして切り出した。出典

転機・苦労

キャッシュは速さだけでなく再現性が課題になる。

入力ファイル、環境変数、依存関係を正しく定義しないと、古い成果物を再利用する危険がある。

公式docsがpipelineとcacheの境界を細かく説明するのは、このトレードオフの裏返しだ。出典

成長・成功の要因

Vercelによる買収後、TurborepoはVercelのremote cachingと接続し、個人のローカル最適化からチームのCI共有へ広がった。出典

結び

Turborepoの示唆は、monorepo全体を速くするのではなく、再計算しなくてよい仕事を見極めることにある。

monorepoを採用したチームの痛みは、依存関係が増えるほどCIとローカル開発の待ち時間が増えることだ。

Turborepoはtask graphとcacheで、変更のない処理を再実行しない。出典

単なる高速化ではなく、設定をrepositoryに置いてチームで共有できる点がPMFを強める。

task graphとcache invalidationをrepository設定に落とし込んだ知見、そしてVercelのdeployment ecosystemとの接続が障壁になる。

ただしOSSなので基本機能の模倣は可能だ。

強いnetwork effectではない。

利用者が増えるほどcache設定やtoolingの知見は蓄積するが、価値の中心は各repository内の再利用にある。

複数packageを一つのrepositoryで管理するfrontend/backendチーム。

特にCI時間が課題で、VercelまたはNode.js ecosystemを採用している組織に向く。

単一packageの小規模案件には過剰だ。

第一にCLI導入の軽さ、第二にtask graphとcacheの説明可能性、第三にVercel Remote Cacheとの接続である。

OSSの導入障壁を下げ、チーム利用への拡張余地を残した。出典

cache keyの設計を誤ると古い成果物を使うリスクがある。

また、monorepoでない小規模プロジェクトには設定コストが便益を上回る可能性がある。

Remote Cacheの利用にはVercel側の運用理解も必要だ。

GitHubとdocsで開発者に直接届くOSS導入を入口にし、Vercel Remote CacheでチームとCIへ拡張する。

セルフホスト可能なCLIとmanaged serviceを分けることで、採用初期の摩擦を抑えつつ収益化の余地を作る。

主要チャネル: github, documentation, developerCommunity, content

高速化の本質を「処理能力」ではなく「不要な再計算の削減」に置き換えた点が学びになる。

導入時はcache hit率だけでなく、入力定義の正しさと失敗時の復旧手順まで設計すべきだ。

日本の大規模フロントエンド組織でもmonorepo化は進む一方、CI待ち時間と担当チーム間の責任分界が問題になる。

Turborepo型の導入では、まず共通pipelineを一つに絞り、cacheの可観測性を日本語の運用runbookに落とすのが現実的だ。