
sbtはScala Build Toolの略で、2008年頃にマーク・ハラビン氏(Mark Harrah)が開発を始めたScala向けのビルドツールです。Scala界の事実上の標準として広く使われており、build.sbtというDSLでビルド定義を書き、対話型シェルからcompileやtestを実行できる点が特徴です。ファイル変更を監視して差分コンパイルを行う「インクリメンタルコンパイラ」と、~testのようなトリガーモードによって、ScalaやAkka・Play Framework・Sparkプロジェクトの日常開発で高い生産性を発揮します。
この記事の目次
- build.sbtによる宣言とScala DSL
- 対話型シェルとインクリメンタルコンパイル
- マルチプロジェクトと依存集約
- MavenやGradleとの選び分け
- まとめ
build.sbtによる宣言とScala DSL

sbtの設定はプロジェクト直下のbuild.sbtに集約され、scalaVersion := "3.4.0"のようなScala構文で書きます。ライブラリはlibraryDependencies += "org.typelevel" %% "cats-core" % "2.10.0"のように、%%演算子でScalaバイナリ互換版数を自動付与できる仕組みが組み込まれています。project/ディレクトリにはビルド自体をScalaで書くためのファイル群を置けて、巨大プロジェクトでは設定をScalaコードとして分割管理できます。
プラグインはproject/plugins.sbtに宣言し、sbt-assembly(fat JAR作成)・sbt-native-packager(Docker・debパッケージ生成)・sbt-scoverage(カバレッジ)など多彩なエコシステムが揃います。Scala固有の機能としてクロスビルド(複数のScala版数を同時にビルド)が組み込まれており、ライブラリ作者はcrossScalaVersions := Seq("2.13.13", "3.4.0")の一行で2系・3系両対応のJARを公開できます。この機能はScalaのバイナリ非互換問題を運用面で吸収する重要な仕組みです。
対話型シェルとインクリメンタルコンパイル

sbtコマンドを起動するとプロジェクトを読み込んだ対話型シェルが立ち上がり、compile・test・run・consoleなどをコマンドとして次々に実行できます。毎回のJVM起動コストを支払わないため、コマンドの即応性が高く、テストドリブン開発との相性がよい点が支持されています。Scala REPLをconsoleコマンドで開けば、ビルド済みのプロジェクトクラスパスを使ったままScala REPLで実験できます。
シェルでコマンドの頭に~を付けると、ファイル変更を監視して自動再実行するトリガーモードに切り替わります。~testを打っておけばエディタで保存するたびに差分コンパイル+テストが走るため、ライブリロード的な開発体験が得られます。sbtは内部にZincというインクリメンタルコンパイラを抱えており、Scalaの遅いコンパイル時間を入力単位のキャッシュで圧縮しています。Zincは現在Scala Centerが保守を引き継ぎ、Scalaコンパイラと足並みをそろえて改良が続けられています。
マルチプロジェクトと依存集約

sbtでマルチプロジェクトを組むときは、build.sbtにlazy val core = project.in(file("core"))のようなサブプロジェクトを並べてdependsOnでモジュール間依存を表現します。共通設定はvalにまとめてsettingsに渡すことで、scalaVersionやライブラリ版数をプロジェクト全体で揃えられます。Akka・Lagom・Playのような大規模Scalaプロジェクトはこの仕組みで数十のサブモジュールを管理しています。
依存解決にはApache Ivyが長年使われてきましたが、近年は高速なCoursierに切り替える設定が普及しています。Coursierはアレクサンドル・アルキエ氏らが開発したScala製の依存解決器で、並列ダウンロードとキャッシュ管理が洗練されており体感速度が大きく上がります。社内Nexus等を使う場合はresolvers += "Internal" at "https://nexus.example.com/repository/maven-public/"と書くだけで、社内ライブラリと公開ライブラリを混在して解決できます。
MavenやGradleとの選び分け

Scalaを書く場面ではsbtが依然として標準ですが、近年はLi Haoyi氏が開発するMillや、Bleepといった軽量代替も登場しています。Millはbuild.scファイルをScalaで書き、よりシンプルで予測しやすい設定を目指す設計、Bleepはコンパイル速度を最優先に据えた新興プロジェクトです。とはいえコミュニティの大半とライブラリ作者のCI構成は今もsbtを前提としており、sbtを覚えておけばScalaエコシステム全体に手が届きます。
JVMプロジェクトでScala以外も多用するならMavenやGradleにまとめる選択もあり、Spring BootをScalaで書きたいような場合はMaven Scala Pluginという折衷案もあります。新規Scalaサービス・ライブラリならsbtを第一候補にして問題なく、必要に応じてMillへ乗り換える、という運用が実情に合います。
まとめ
sbtは2008年から続くScala Build Toolで、build.sbt・対話型シェル・Zincによる差分コンパイルでScala開発を支えてきました。クロスビルドとCoursier連携によりライブラリ作者・利用者の双方に最適化されています。MillやBleepといった代替も登場していますが、Scalaエコシステムの中核ビルドツールとしての地位は引き続き堅固です。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。

コメント