BazelはGoogle社内で長年使われてきた「Blaze」というビルドシステムを2015年3月に外部公開したオープンソース版で、超巨大なモノレポでも数秒〜数十秒でビルドを返すことを目指して設計されています。Googleが日々扱う数億行規模のソースに対して安定して動く実績を持ち、宣言的なBUILDファイルと「同じ入力なら必ず同じ出力になる」という再現性（Hermetic Build）を強く打ち出している点が特徴です。外部公開後はJava・C++・Go・Python・Kotlin・Swiftなど多言語に対応するルールが整備され、UberやTwitterなど大規模モノレポ運用企業を中心に採用が広がっています。
この記事の目次
- BUILDファイルとStarlarkによる宣言
- 再現性を担保するHermeticビルド
- 多言語対応とルールセット
- MavenやGradleとの位置取り
- まとめ
BUILDファイルとStarlarkによる宣言
Bazelのビルド定義はWORKSPACE（外部依存）とBUILD.bazel（ターゲット）の2種類のファイルに分かれ、それぞれStarlarkというPythonサブセット言語で書かれます。java_binary・cc_library・go_testといった言語別ルールに対し、srcsとdepsを明示的に列挙する形式で、暗黙の依存や副作用が入り込まないように設計されています。Starlarkはチューリング完全ではなく決定論的に評価されるため、評価結果がビルド機ごとに揺らがない点が再現性を支えています。
BUILDファイルにはターゲット単位の依存関係を細かく書く必要があり、書き始めの手間はMavenやGradleより重めです。その代わりにビルドグラフが厳密にわかるため、変更したファイルが影響するターゲットだけを正確に再ビルドできます。Googleが社内で数億行のコードを扱えている理由のひとつが、この厳格な依存宣言にあります。
再現性を担保するHermeticビルド
Bazelはコンパイラやツールチェーンの版数までWORKSPACEで指定し、ビルド中はサンドボックス内で外部の環境変数やシステムライブラリに触れない構成を取ります。これがHermetic Build（密閉ビルド）と呼ばれる仕組みで、開発者のMacでもCIのLinuxでも同じハッシュの成果物が得られることを目指しています。結果として「自分の環境では動くのに同僚の環境で失敗する」というよくある問題を構造的に減らせます。
Bazelは各アクション（コンパイル・リンク・テスト）の入力ハッシュを計算し、ローカルとリモートのキャッシュを引きにいきます。リモートキャッシュとリモート実行（Remote Execution）に対応するBuildBuddyやEngFlowといった商用サービスを組み合わせれば、CIでの再ビルドが大幅に短縮できます。巨大モノレポで全員が共有キャッシュを使う運用が、Bazelが大手企業に選ばれる最大の理由の1つです。
多言語対応とルールセット
Bazel本体は最小限のコアに留め、各言語のサポートは独立した「ルールセット」として配布されます。公式にはrules_java・rules_cc・rules_pythonがあり、コミュニティ製のrules_go・rules_rust・rules_nodejs・rules_swiftなどでGoやRust、Node.js、Swiftにも対応します。rules_dockerやrules_ociを使えばコンテナイメージのレイヤをBazelのアクションとして生成でき、再現性ある形でDocker Hubに公開できます。
多言語モノレポでは「Goのマイクロサービス」「Java製バッチ」「Reactフロント」「iOS/Androidアプリ」を1つのBazelビルドで扱えるのが大きな利点です。ただしルールセットによって成熟度に差があり、最新言語仕様への追随はMavenやGradleより遅れることもあります。言語が単一でモノレポでないプロジェクトでは、MavenやCargoの方が運用コストは軽くなる傾向です。
MavenやGradleとの位置取り
Bazelの源流であるBlazeはGoogle社内で2006年頃から使われ、同じ思想を持つビルドツールとしてMeta（旧Facebook）のBuck、Twitterが開発したPants、Microsoftの一部社内ツールなどが続きました。これらはいずれも「巨大モノレポ向け」「ハーメティック」「多言語対応」という共通点を持ち、業界では総じて「Blaze系」と呼ばれることがあります。MavenやGradleが「言語コミュニティ標準」を目指すのに対し、Bazel系は「企業内モノレポの効率化」を狙う設計思想の違いがあります。
そのためBazelは中小規模のJava/Kotlinアプリには明らかに過剰で、MavenやGradleで十分回ります。一方、コードベースが数千万行を超えてビルド時間が日常業務の大きな割合を占め始めると、Bazelとリモートキャッシュ・リモート実行への投資が回収しやすくなります。選定の判断材料はモノレポの規模・チーム数・CI時間で、目的が明確なら強力な武器になります。
まとめ
Bazelは2015年にGoogleがBlazeをベースに公開したビルドツールで、Hermeticビルドと厳密な依存宣言で再現性の高いビルドを実現します。BUILDファイル・Starlark・リモート実行を組み合わせることで、巨大モノレポでも開発生産性を維持できる設計です。中小規模プロジェクトでは過剰になりがちですが、組織横断モノレポでは強力な選択肢として有力です。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント