ビルドシステム & モノレポツール 2026 完全ガイド — Bazel 8 · Pants 2 · Buck2 · Nx 20 · Turborepo 2 · Moon · Lerna 8 · Rush · pnpm Workspaces 徹底比較

プロローグ — ビルドシステムが再び熱い理由

2026年、ある会社のプラットフォーム会議。

ジュニア: 「JS モノレポなので Turborepo で十分ですよね?」 シニア: 「じゃあバックエンドの Go とデータチームの Python はどうやって一緒にビルドする?」 ジュニア: 「...あっ。」

この短いやり取りに 2026 年が詰まっている。一方には言語固有ツール(cargo, gradle, npm scripts)、もう一方にはポリグロット(Bazel, Buck2, Pants)。そしてその間に タスクランナー + キャッシュ層(Nx, Turborepo, Moon)が割って入る。

本稿は 2026 年 5 月時点の全体地図を一気に整理する。Bazel 8 の Bzlmod デフォルト化、Buck2 の OSS 定着、Pants 2 のシェア、Nx 20 と Turborepo 2 の競合、Moon の台頭、Gradle 8.10 / Maven 4 / sbt 1.10 の JVM 陣営まで。そして韓国・日本の大手が実際に何を使っているかも。

1章 · 2026 年ビルドシステム地図 — 2 軸で分ける

「ビルドシステム」という一語にあまりに多くが詰め込まれている。最も簡単な切り方は 2 軸。

縦軸は言語カバレッジ、横軸はキャッシュ・分散の深さ。2026 年の主流れは、右下のセル(ポリグロット + リモート)が急速に埋まっていることだ。そのセル内でも 2 陣営に分かれる — Bazel/Buck2/Pants の「宣言的グラフ + 解釈型 BUILD ファイル」陣営と、Nx/Turborepo/Moon の「JSON/YAML 設定 + 影響を受けたプロジェクトだけ実行」陣営。

選択の起点は単純だ。

1. 単一言語 + 小規模チーム → その言語のネイティブツール(cargo, gradle, npm)。
2. 単一言語 + 大規模モノレポ → ネイティブ + リモートキャッシュ(Develocity, Nx Cloud)。
3. JS/TS 中心 + 複数パッケージ → pnpm workspaces / Nx / Turborepo。
4. ポリグロット + 大規模 → Bazel / Buck2 / Pants。

2章 · モノレポ vs ポリレポ — 2026 年の答え

この論争はほぼ決着した。答えは「両方使う、ただしモノレポがデフォルト」だ。

モノレポの強み: アトミックな変更(1 PR でライブラリ・サービス・テストを同時に変更)、単一の依存グラフ、共有インフラ(ビルド・CI・lint)、IDE 一本で検索・リファクタが完結。

ポリレポの強み: 権限分離、ビルド時間の分離、チームの自律性、小さなリポの単純さ。

2026 年の妥協形: 「1 つの会社に複数モノレポ」。たとえば platform-monorepo(インフラ)、product-monorepo(サービス)、data-monorepo(パイプライン)。それぞれはモノレポだが会社全体ではポリレポ。Google・Meta・Microsoft 一部組織がこの形。小さな会社ならモノレポ 1 つでいい。

Trunk-based development + feature flags + change detection(21 章参照) の 3 つが揃えば、モノレポの歴史的弱点のほぼ全てが消える。

3章 · Bazel 8 — ポリグロットビルドの標準

Bazel は Google 社内ビルド Blaze の OSS 版。2026 年 5 月の安定版は Bazel 8.x、LTS は 7.x。最大の変化は Bzlmod(MODULE.bazel)がデフォルトになり、WORKSPACE モードが deprecated になったこと。

ライセンス Apache 2.0。採用先: Google, X(旧 Twitter), Stripe, Pinterest, Spotify, Snap, Dropbox, Coupang, Mercari など。

中核概念。

• BUILD.bazel: ディレクトリごとに 1 つ、そのディレクトリのビルドターゲットを宣言。
• WORKSPACE / MODULE.bazel: リポルートで外部依存・ツールチェーンを宣言。
• Starlark: Python のサブセット、ビルドルールを書く言語。
• rules: 言語別ルール集(rules_go, rules_python, rules_js, rules_rust, rules_java)。
• sandbox: 全アクションを隔離ディレクトリで実行し hermeticity を保証。
• remote cache / remote execution: アクション結果をハッシュでキャッシュ、ミスならリモートワーカーで実行。

最もシンプルな Go バイナリ。

# BUILD.bazel
load("@io_bazel_rules_go//go:def.bzl", "go_binary", "go_library")

go_library(
    name = "hello_lib",
    srcs = ["main.go"],
    importpath = "example.com/hello",
)

go_binary(
    name = "hello",
    embed = [":hello_lib"],
)

bazel build //cmd/hello:hello
bazel test //...
bazel query 'deps(//cmd/hello:hello)' | head

Bzlmod での依存宣言。

# MODULE.bazel
module(name = "myrepo", version = "0.1.0")

bazel_dep(name = "rules_go", version = "0.55.0")
bazel_dep(name = "gazelle", version = "0.41.0")

go_deps = use_extension("@gazelle//:extensions.bzl", "go_deps")
go_deps.from_file(go_mod = "//:go.mod")
use_repo(go_deps, "com_github_pkg_errors")

Bazel の強みは グラフ + キャッシュ + リモート実行が深く統合されていること。弱みは学習曲線と BUILD ファイルを手書きする負担(Gazelle のような自動生成器で緩和)。

4章 · Buck2(Meta)— Rust で書き直された Buck

Buck1 は Meta が 2013 年に作った Bazel の従兄弟。2023 年に Meta が Rust で一から書き直して OSS 公開 — Buck2。2026 年現在 Meta 社内ビルドの標準、OSS 採用も増えている。

Bazel との比較。

最大の違いは dynamic dependencies。Bazel は BUILD 評価 → アクショングラフ → 実行が分離されていてビルド開始後にグラフを変更できない。Buck2 は一部のノードがビルド中に追加入力を宣言でき、OCaml の .ml / .mli のようにコンパイル結果に依存する関係を自然に表現できる。

# BUCK
load("@prelude//rules.bzl", "cxx_binary", "cxx_library")

cxx_library(
    name = "hello_lib",
    srcs = ["hello.cc"],
    headers = ["hello.h"],
)

cxx_binary(
    name = "hello",
    srcs = ["main.cc"],
    deps = [":hello_lib"],
)

buck2 build //cpp/hello:hello
buck2 test //...
buck2 cquery 'deps(//cpp/hello:hello)'

Bazel から移行する価値はあるか? 通常はない。新規ポリグロットモノレポ + Meta 影響圏 + 動的依存が本当に必要なときだけ検討。

5章 · Pants 2 — Python モノレポの事実上の標準

Pants v1 は 2014 年に Twitter が作った Java/Scala ビルドシステム。v2 から Toolchain Labs が一から作り直し、Python ファーストのポリグロットとして位置づけた。2026 年 5 月の安定版は Pants 2.27。

ライセンス Apache 2.0、採用先: Slack, IBM, Pico, Toolchain。

Pants 2 の差別化ポイント。

• Python ファースト: pytest, mypy, ruff, pyright, black, flake8 などをファーストクラスサポート。
• 自動依存推論: import グラフを解析し BUILD ファイルに deps を自動追加。
• Lockfile-aware: PEP 621 / pyproject.toml と lockfile を統合。
• Remote caching: BuildBuddy・EngFlow と互換。

# pants.toml
[GLOBAL]
pants_version = "2.27.0"
backend_packages = [
  "pants.backend.python",
  "pants.backend.python.lint.ruff",
  "pants.backend.python.typecheck.mypy",
  "pants.backend.docker",
]

[python]
interpreter_constraints = ["==3.12.*"]

# src/python/myapp/BUILD
python_sources(name="lib")
python_tests(name="tests", dependencies=[":lib"])
pex_binary(name="bin", entry_point="myapp.main:main")

pants tailor ::                # BUILD ファイル自動生成
pants lint test check ::       # 全体 lint/test/typecheck
pants --changed-since=main test  # 変更分だけ
pants package src/python/myapp:bin

Python モノレポなら Pants 2 がほぼデフォルト選択肢。mypy/ruff のキャッシュまで処理してくれるのが決定打。

6章 · リモート実行バックエンド — BuildBuddy / EngFlow / NativeLink

Bazel・Buck2・Pants はいずれも Remote Execution API(REAPI)という gRPC 標準に従う。キャッシュ(action result, CAS)と実行(worker)が分離されていて、クライアントはキャッシュミス時にリモートワーカーへ実行を委譲する。

2026 年の主要バックエンド。

BuildBuddy 設定例(.bazelrc)。

build --bes_results_url=https://app.buildbuddy.io/invocation/
build --bes_backend=grpcs://remote.buildbuddy.io
build --remote_cache=grpcs://remote.buildbuddy.io
build --remote_executor=grpcs://remote.buildbuddy.io
build --remote_header=x-buildbuddy-api-key=YOUR_API_KEY

このブロックだけでキャッシュ + 実行 + Build Event Stream(BES、Web UI でビルド追跡)がオンになる。大型モノレポではビルド時間が 5〜10 倍短縮されることが多い。

7章 · Nx 20 — JS/TS モノレポの強者

Nx は Nrwl(現 Nx)が作った JS/TS モノレポツール。2026 年 5 月時点で Nx 20.x。ライセンス MIT、ホスティングは Nx Cloud(有料 SaaS)。

Nx の核心 2 つ。

1. ローカル + リモートキャッシュ: タスク結果(build, test, lint 出力)をハッシュでキャッシュ。
2. affected: git diff ベースで影響を受けたプロジェクトだけ実行。

npx create-nx-workspace@latest myorg --preset=ts
cd myorg
nx g @nx/react:app web
nx g @nx/node:app api
nx g @nx/js:lib shared

// nx.json
{
  "tasksRunnerOptions": {
    "default": {
      "runner": "nx-cloud",
      "options": {
        "cacheableOperations": ["build", "lint", "test", "e2e"],
        "accessToken": "YOUR_NX_CLOUD_TOKEN"
      }
    }
  },
  "namedInputs": {
    "default": ["{projectRoot}/**/*"],
    "production": ["default", "!{projectRoot}/**/*.spec.ts"]
  }
}

nx run-many -t build       # 全プロジェクトをビルド
nx affected -t test        # 影響を受けたプロジェクトだけテスト
nx graph                   # 依存グラフを可視化
nx release                 # バージョン・changelog・publish

Nx 20 の新機能: Atomizer(テスト分割)、Custom Conformance Rules(モノレポルール検査)、Self-Healing CI(失敗した e2e を自動再試行+分析)。Lerna 買収後の統合はほぼ完了、Lerna は実質 Nx のエイリアスに近い。

8章 · Turborepo 2 — Vercel の JS モノレポツール

Turborepo は 2021 年に Jared Palmer が作ったモノレポビルドシステム。2022 年に Vercel が買収。2024 年の Turborepo 2.0 で中核が Rust 化、2026 年現在 2.x が安定。

Nx との比較。

// turbo.json
{
  "$schema": "https://turbo.build/schema.json",
  "tasks": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": [".next/**", "!.next/cache/**", "dist/**"],
      "inputs": ["src/**", "package.json", "tsconfig.json"]
    },
    "test": { "dependsOn": ["^build"], "outputs": ["coverage/**"] },
    "lint": { "outputs": [] },
    "dev": { "cache": false, "persistent": true }
  }
}

turbo run build               # 全体ビルド(キャッシュヒットはスキップ)
turbo run test --filter=...[origin/main]  # 変更分のみ
turbo run dev --parallel      # 開発サーバ並列
turbo prune --scope=web       # 特定アプリ向けに切り出し(Docker ビルド用)

Turborepo 最大の武器は シンプルさと Vercel 統合。CI で TURBO_TOKEN + TURBO_TEAM の環境変数を与えるだけで Vercel Remote Cache が自動で有効化される。Next.js / Remix 中心のチームには摩擦が最小。

9章 · Moon(moonrepo)— Rust 製のポリグロットダークホース

Moon は 2022 年登場の Rust ベースビルドシステム。作者は Lerna・Yarn 出身の Miles Johnson。ライセンス MIT。JS/TS・Python・Rust・Go・Deno・Bun を 1 つのツールで束ねるのが目標。

Nx/Turborepo との違い。

• 言語非依存: lang.toml でツールチェーン(Node, Deno, Bun, Rust, Python)のバージョンを固定。
• Project graph: Bazel のようにディレクトリ単位、ただし設定は YAML。
• Affected: Nx と同じコンセプト。
• Mise 統合: バージョン管理 Mise と組み合わせてツールチェーンをブートストラップ。

# .moon/workspace.yml
projects:
  - 'apps/*'
  - 'packages/*'

vcs:
  manager: 'git'
  defaultBranch: 'main'

runner:
  cacheLifetime: '7 days'
  archivableTargets: ['build', 'test']

# apps/web/moon.yml
language: 'typescript'
type: 'application'
dependsOn:
  - 'shared'
tasks:
  build:
    command: 'next build'
    outputs: ['.next']
  test:
    command: 'vitest run'

moon run web:build
moon ci             # 影響を受けた全タスク
moon dep-graph

Moon はまだ小さいが、Rust の速度 + ポリグロット + YAML 設定の組み合わせが魅力。Bazel は重く Turborepo は JS 専用で物足りないチームが狙う価値がある。

10章 · Lerna 8 · Rush · pnpm workspaces — 軽量 JS モノレポ 3 つの道

軽量な JS モノレポ選択肢は今でも 3 つある。

Lerna 8: 2022 年に Nrwl が買収し、実質的に Nx の一部。新規プロジェクトなら Nx を直接使う方がよいが、既存 Lerna リポは Nx のキャッシュ・affected をそのまま受けられる。

// lerna.json
{ "version": "independent", "npmClient": "pnpm", "useNx": true }

lerna run build --since=origin/main
lerna publish

Rush(Microsoft Rush Stack): pnpm の上に強いポリシー(phantom dependency 遮断、変更ファイル検査)を載せたツール。Microsoft, Office Online, Azure 一部で使用。大規模 JS モノレポで厳格さが必要なときに。

rush install
rush build
rush change         # PR 前に変更ファイルを作成
rush publish

pnpm workspaces(9.x): 最もシンプル。pnpm-workspace.yaml + package.json の workspaces フィールド。キャッシュ・affected はないが、小規模モノレポ(20 パッケージ未満)に適する。

# pnpm-workspace.yaml
packages:
  - 'apps/*'
  - 'packages/*'

pnpm install
pnpm -r build                  # 全ワークスペースをビルド
pnpm --filter=@org/web build   # 特定パッケージのみ
pnpm --filter='...[origin/main]' test  # 変更影響のみ(pnpm 9+)

選択ガイド: 小規模 + JS 専用 + シンプル志向 → pnpm workspaces。中〜大規模 + Vercel 親和 → Turborepo。中〜大規模 + 豊富なツール・ポリシー → Nx。大規模 + 厳格ポリシー + MS 親和 → Rush。

11章 · Java・Kotlin 陣営 — Gradle 8.10 + Maven 4

JVM は独自の厚いビルドツールエコシステムを持つ。2026 年 5 月時点の安定版。

Gradle 8.10+: Groovy/Kotlin DSL、依存管理、マルチプロジェクト。中核キャッシュ機能は 2 つ。

• build cache: タスク結果をキャッシュ(ローカル + リモート)。
• configuration cache: ビルド設定段階の結果をキャッシュ(大型プロジェクトで秒〜数十秒の節約)。
• Develocity(旧 Gradle Enterprise): リモートキャッシュ + ビルドスキャン + テストインサイトの SaaS。

// build.gradle.kts
plugins {
    java
    application
    id("org.springframework.boot") version "3.4.1"
}

group = "com.example"
version = "0.1.0"

repositories { mavenCentral() }
dependencies {
    implementation("org.springframework.boot:spring-boot-starter-web")
    testImplementation("org.springframework.boot:spring-boot-starter-test")
}

tasks.test { useJUnitPlatform() }

./gradlew build --build-cache --configuration-cache
./gradlew :api:test
./gradlew dependencies

Maven 4(2025 年 GA): pom.xml の安定性を保ちながらビルドグラフ・並列化・daemon(mvnd)を強化。Spring エコシステムの巨大な慣性で依然第 1 候補。mvnd(Maven Daemon)を使えば JVM ウォームアップがなく、体感速度は Gradle に近い。

./mvnw -T 1C clean install      # CPU コアあたり 1 スレッド並列
mvnd -T 1C clean install        # daemon モード

JVM モノレポなら: 新規は Gradle + Develocity、既存・SI は Maven 4 + mvnd が合理的。

12章 · sbt 1.10 · Mill — Scala 陣営

Scala は別記事でも扱うが、ビルド観点で簡単に。

sbt 1.10: Scala のデフォルト、incremental コンパイルが強み。学習曲線が急という不満は永遠。

// build.sbt
ThisBuild / scalaVersion := "3.6.0"
lazy val root = (project in file("."))
  .settings(
    name := "myapp",
    libraryDependencies ++= Seq(
      "org.typelevel" %% "cats-effect" % "3.5.4",
      "org.scalatest" %% "scalatest" % "3.2.19" % Test,
    )
  )

Mill(Lihaoyi): Scala/Java/JS ビルドを Scala で記述。sbt より明快で速いという評価。メインストリームではないが、新規 Scala チームが採用することも。

// build.mill
package build
import mill._, scalalib._
object app extends ScalaModule {
  def scalaVersion = "3.6.0"
  def ivyDeps = Agg(ivy"org.typelevel::cats-effect:3.5.4")
}

Scala モノレポが本当に大きくなれば Bazel + rules_scala がほぼ唯一の答えだが、そこまで到達するチームは少数。

13章 · C/C++ — CMake 3.31 + Ninja 1.12 / Meson / Bazel

C/C++ はビルドシステム戦国時代が最も長かった。2026 年のまとめ。

CMake 3.31 + Ninja 1.12: 事実上の標準。CMake はビルドシステムそのものではなくビルドシステムのジェネレーター(Makefile, Ninja, MSBuild を生成)。Ninja がその結果を最速で実行する。

# CMakeLists.txt
cmake_minimum_required(VERSION 3.31)
project(myapp CXX)
set(CMAKE_CXX_STANDARD 23)

add_library(mylib STATIC src/foo.cc src/bar.cc)
target_include_directories(mylib PUBLIC include)

add_executable(myapp src/main.cc)
target_link_libraries(myapp PRIVATE mylib)

cmake -S . -B build -G Ninja
cmake --build build -j
ctest --test-dir build

Meson + Ninja: CMake の従兄弟、より洗練された文法(Python ライク)。GNOME, systemd などで使用。

Bazel + rules_cc: 大規模ポリグロット C/C++ モノレポの答え。Google・Stripe・Pinterest の C++ サービスはこのルート。

GNU Make: 小規模プロジェクトでは依然第 1 候補。学習曲線が最も緩い。

14章 · Rust — Cargo workspaces + cargo-nextest

Rust モノレポはほぼ全てのケースで Cargo workspaces で十分。

# Cargo.toml (root)
[workspace]
resolver = "2"
members = ["crates/*", "services/*"]

[workspace.dependencies]
tokio = { version = "1.42", features = ["full"] }
serde = { version = "1.0", features = ["derive"] }

cargo build --workspace
cargo test --workspace
cargo nextest run --workspace        # 高速なテストランナー
cargo metadata --format-version 1    # 依存グラフ

リモートキャッシュが必要なら sccache(Mozilla)が標準。S3・GCS・Redis・memcached・ローカルディスクをバックエンド対応。

export RUSTC_WRAPPER=sccache
export SCCACHE_BUCKET=my-sccache-bucket
cargo build --release
sccache --show-stats

大規模ポリグロットに Rust が混じる場合は Bazel + rules_rust も選択肢だが、導入負担は本物。会社単位の Bazel 標準がなければ sccache + Cargo が事実上の正解。

15章 · Go — go modules + gomonorepo パターン

Go はモジュールシステムが単純なのでモノレポが自然。リポに 1 つの go.mod を置き、internal/ でパッケージ境界を引くのが標準。

myrepo/
  go.mod
  cmd/
    api/main.go
    worker/main.go
  internal/
    auth/
    storage/
  pkg/
    publicapi/

go build ./...
go test ./...
go vet ./...
go test -count=1 -run TestFoo ./internal/auth

キャッシュ・リモート実行が必要になれば Bazel + rules_go + gazelle の組み合わせが最も成熟。Gazelle は BUILD.bazel を go.mod から自動生成する。

bazel run //:gazelle
bazel run //:gazelle -- update-repos -from_file=go.mod -to_macro=deps.bzl%go_dependencies

Pinterest・Twitter・Coupang の Go サービスがこのルート。

16章 · Mise(旧 rtx)· just · Task — 軽量タスクランナー

ビルドシステムとは別に、繰り返しコマンドを短い名前で呼ぶ道具がある。シェルスクリプト・Makefile の後継。

Mise(旧 rtx): asdf 互換のバージョンマネージャー + タスクランナー。Rust 製。1 つのツールで Node・Python・Go・Rust・Ruby・Bun のバージョンを固定し、タスクも定義。

# mise.toml
[tools]
node = "22"
python = "3.12"
go = "1.23"

[tasks.build]
description = "Build all"
run = "pnpm -r build"

[tasks.test]
description = "Run tests"
depends = ["build"]
run = "pnpm -r test"

mise install        # ツールのインストール
mise run build
mise run test

just: Make の現代版。スッキリした文法、依存なし。

# justfile
default:
    @just --list

build:
    pnpm -r build

test: build
    pnpm -r test

release version:
    git tag v{{version}}
    git push origin v{{version}}

Task(taskfile.dev): YAML ベースのタスクランナー、Go 製。

# Taskfile.yml
version: '3'
tasks:
  build:
    cmds:
      - pnpm -r build
  test:
    deps: [build]
    cmds:
      - pnpm -r test

これら 3 つはビルドグラフ系のツールではなくコマンドの短縮。大型モノレポでもエントリポイントとして便利 — just ci が裏で bazel test //... や nx affected -t test を呼ぶ形。

17章 · リモートキャッシュ — Bazel BES vs Nx Cloud vs Turborepo Remote Cache

3 つのツールのリモートキャッシュ方式は異なる。

Bazel の強み: REAPI 標準、マルチバックエンド、sandboxing のおかげでキャッシュヒットがほぼ常に動作。

Nx Cloud の強み: Web UI、失敗ビルドのインサイト、Nx Agents(分散実行)統合。

Turborepo の強み: 設定が最も単純(環境変数 2 つ)、Vercel CI と自動統合。

セルフホストはいずれも可能だが、運用負担は BuildBuddy/Buildbarn >> Nx Cloud(Helm chart)>> Turborepo Server(Docker コンテナ 1 つ)の順。

18章 · Hermetic builds + content-addressed cache — 再現性の本質

「昨日通ったのに今日通らない」の根本原因は隠れた入力(環境変数、システムライブラリ、時計、ネットワーク)。これを解決するのが hermetic build と content-addressed cache。

Hermetic: ビルドアクションの入力を明示的に宣言(ソース + ツール + 環境変数)、外部アクセスを遮断(sandbox)。Bazel・Buck2・Pants はデフォルトでこれを行う。

Content-addressed: 入力ハッシュが同じなら出力も同じと仮定。入力が 1 バイトでも違えば再ビルド、同じならキャッシュヒット。

input_hash = sha256(sources + tools + env + command)
output: stored under output_hash
cache_key: input_hash -> output_hash

Nix も同じ哲学(Bazel と Nix は別のツールだが同じ発想)。再現可能な CI/CD が本当に可能になる。

19章 · コンテナビルド — BuildKit / Buildah / Kaniko / Earthly

ビルドシステムの記事がコンテナで締めくくられる理由: 2026 年は全サービスが OCI イメージで配布され、ビルドシステム出力 → コンテナイメージの変換がパイプライン最後のステップだから。

Bazel は rules_oci(旧 rules_docker の後継)で OCI イメージを hermetic に作る。イメージレイヤーは入力ハッシュが一致すればバイト同一に再現される。

# BUILD.bazel
load("@rules_oci//oci:defs.bzl", "oci_image")
oci_image(
    name = "api_image",
    base = "@distroless_base",
    entrypoint = ["/api"],
    tars = [":api_layer"],
)

20章 · グローバル大手のビルドシステム

ポリグロット + 大規模は Bazel/Buck2/Pants の 3 つに収束する。

21章 · 韓国・日本の事例

韓国

• Coupang: Bazel の広範な使用。Search・Logistics・iOS/Android 一部。C++ 検索インフラが Bazel hermeticity の上で動く。
• Toss / Viva Republica: フロントエンドは Turborepo、バックエンドは Gradle 中心。
• Naver: 広範。NHN/Naver Pay 一部 Bazel、フロントは Turborepo や Nx 多数。
• Kakao: Gradle/Maven 中心、フロントは Turborepo / pnpm workspaces。
• Woowa Brothers(出前館の母 BAEMIN): Gradle + Spring 中心。フロントは Nx/Turborepo。
• Karrot(당근): pnpm workspaces + Turborepo が標準。一部 Nx 採用。

日本

• Mercari: Bazel を広範に使用。Go/Java マイクロサービスを Bazel + BuildBuddy で。
• LINE Yahoo: Bazel(LY)、Gradle(LINE 一部)。検索・広告インフラは Bazel。
• CyberAgent / Ameba: Nx + Turborepo。広告プラットフォームの一部に Bazel。
• Recruit / Indeed: Bazel を広範に使用。Indeed は monorepo + Bazel の発信が多い。
• DeNA: Gradle 中心 + 一部 Bazel。
• Rakuten: Gradle + Maven、一部 Bazel。

注目: 日本大手の Bazel 採用率は韓国より高い。Mercari・Indeed・LY の影響。

22章 · 何をいつ選ぶか — 判断ツリー

最後に整理。

1. 小規模 JS チーム(〜5 人、〜10 パッケージ) → pnpm workspaces 単独。
2. 中規模 JS/TS チーム(〜30 人、〜50 パッケージ)+ Vercel/Next.js 中心 → Turborepo 2 + Vercel Remote Cache。
3. 中規模 JS/TS チーム + 豊富なツール・ポリシー必要 → Nx 20 + Nx Cloud。
4. JS + Python + Go ポリグロットモノレポ → Moon か Bazel。
5. Python モノレポ(データ・ML チーム) → Pants 2。
6. JVM 新規 → Gradle 8.10 + Develocity。
7. JVM レガシー・SI → Maven 4 + mvnd。
8. Rust モノレポ → Cargo workspaces + sccache + cargo-nextest。
9. Go モノレポ → 単一 go.mod、必要に応じて Bazel + Gazelle。
10. C/C++ → CMake + Ninja(小規模)または Bazel(大規模)。
11. Scala → sbt か Mill、本当に大きければ Bazel + rules_scala。
12. 巨大ポリグロット + リモート実行必須 → Bazel + BuildBuddy/EngFlow、または Buck2。

最もよくある失敗は「流行りで Bazel を導入して 6 ヶ月後に後悔」。現在チームのビルド時間が本当にボトルネックで、そのボトルネックがリモートキャッシュ/実行で解決し、メンテナンス人員がいる、この 3 条件が揃ったときだけポリグロットビルドシステムを検討すべき。そうでなければ、その言語のネイティブツールがほぼ常に正解。

参考資料

• Bazel 公式 — https://bazel.build/
• Bazel Bzlmod(MODULE.bazel)— https://bazel.build/external/module
• Buck2 公式 — https://buck2.build/
• Buck2 GitHub — https://github.com/facebook/buck2
• Pants 2 ドキュメント — https://www.pantsbuild.org/
• Nx 公式 — https://nx.dev/
• Nx Cloud — https://nx.app/
• Turborepo 公式 — https://turbo.build/repo
• Turborepo 2 発表 — https://vercel.com/blog/turborepo-2-0
• Moon(moonrepo)— https://moonrepo.dev/
• Lerna 公式 — https://lerna.js.org/
• Rush Stack — https://rushjs.io/
• pnpm Workspaces — https://pnpm.io/workspaces
• Yarn Workspaces — https://yarnpkg.com/features/workspaces
• Gradle 公式 — https://gradle.org/
• Develocity(旧 Gradle Enterprise)— https://gradle.com/develocity/
• Apache Maven — https://maven.apache.org/
• mvnd(Maven Daemon)— https://github.com/apache/maven-mvnd
• sbt — https://www.scala-sbt.org/
• Mill — https://mill-build.org/
• CMake — https://cmake.org/
• Ninja — https://ninja-build.org/
• Meson — https://mesonbuild.com/
• BuildBuddy — https://www.buildbuddy.io/
• EngFlow — https://www.engflow.com/
• NativeLink — https://www.nativelink.com/
• Buildbarn — https://github.com/buildbarn
• Mise(旧 rtx)— https://mise.jdx.dev/
• just — https://github.com/casey/just
• Task(taskfile.dev)— https://taskfile.dev/
• Cargo Workspaces — https://doc.rust-lang.org/cargo/reference/workspaces.html
• cargo-nextest — https://nexte.st/
• sccache — https://github.com/mozilla/sccache
• Remote Execution API(REAPI)— https://github.com/bazelbuild/remote-apis
• BuildKit — https://github.com/moby/buildkit
• rules_oci — https://github.com/bazel-contrib/rules_oci
• Mercari Engineering / Bazel — https://engineering.mercari.com/en/blog/

エピローグ — 「ビルドは結局グラフ」

ビルドシステム 30 年の核心を一行に縮めれば、**「入力 → 出力の有向グラフ、ノードを最大限再利用せよ」**だ。Make がやったことを Bazel は sandboxing + リモート実行で、Turborepo は JS だけのシンプルな形で、Pants は Python 親和的に書き直している。

ツールは変わっても、「自分のビルドの入力を正確に知る、出力をキャッシュする、同じ入力なら再実行しない」という原則はそのまま。2026 年のポリグロットビルドシステムは、その原則を複数言語・複数マシンにわたって適用する。小規模チームならその原則を最も近くで実装したツール(pnpm + Turborepo, Cargo, Gradle)で十分だし、大規模チームは Bazel を避けられないかもしれない。

最後にひとつ — ビルドシステムの成功は**「誰が BUILD ファイルを保守するか」**にかかっている。ツールではなく人の問題だ。Bazel を入れようが Nx を入れようが、ビルドインフラ専任 1〜2 人がいなければ半分成功で終わる。その人員予算がないなら、その会社に合うビルドシステムはもっと単純な道具である可能性が高い。