モダン Scala 2026 — Scala 3.6 / 3.7 / ZIO 2 / Cats Effect 3 / Pekko / Tapir / Mill / Scala CLI 徹底ガイド

目次

1. 2026年のモダン Scala — Scala 3 定着の時代

Scala はかつて「変わった言語」と呼ばれていました。2020年代前半ですら「Scala は難しい」「Scala 2 はコンパイルが遅い」「チームに導入するには学習コストが高すぎる」という声が一般的でした。2026年の Scala はまったく違います。Scala 3 が定着し、ビルドツールは多様化し、ZIO や Cats Effect のような effect system が成熟し、Pekko が Akka の BSL ライセンス騒動を吸収しました。同時に Effect.ts のように、Scala のアイデアが TypeScript へ逆輸出される興味深い現象も起きています。

本記事は2026年5月時点での Scala エコシステムを一気に整理する徹底ガイドです。

2026年の Scala を取り巻く大きな流れ

Scala が消えない理由

「Scala は終わった」と何度も言われましたが、2026年の Scala は明確な居場所を持っています。

• Spark の中身は実質 Scala — データエンジニアリングと ML パイプラインの中核
• JVM の表現力の限界を最もよく突破する言語 — Kotlin より深い FP、Java より強い型
• Effect system (ZIO / Cats Effect) が本当に動く — 産業で実証された FP スタック
• Iron のような refined types で型安全性の最前線 — 他言語が追いつけていない
• Lichess のように一社で百万人を運用する事例 — Scala の実戦力の証明

ひとつずつ見ていきましょう。

2. Scala 3.6 (2024.12) / 3.7 (2025.3) — 新機能

Scala 3 は2021年5月の正式リリース以降、着実に進化してきました。2024年末と2025年初頭にリリースされた 3.6 と 3.7 は「Scala 3 が本当に安定した」というシグナルを送ったリリースです。

Scala 3.6 の主な変更

Scala 3.6 (2024年12月8日) では以下が核心です。

• Quotes API の安定化 — マクロの記述がずっと楽に
• Named tuples (実験的) — タプルに名前を付ける、("Alice", 30) の代わりに (name = "Alice", age = 30)
• Type ascription の警告 — 曖昧な型注釈に警告
• -Wunused の改善 — 未使用 import / var の警告が精緻に
• Capture checking の進展 — Scala 4 の主要機能のプレビュー

// Named tuples (3.6 で実験、4.0 で正式)
val person = (name = "Alice", age = 30)
val n: String = person.name   // フィールド名でアクセス
val a: Int = person.age

// 関数引数も named tuple で
def greet(p: (name: String, age: Int)): String =
  s"Hello $p.name, $p.age years old"

Scala 3.7 の変更点

Scala 3.7 (2025年3月27日) はマイナーリリースですが、実質的に重要な改善が多く入っています。

• @experimental アノテーションの整理 — 何が安定で何が実験かが明確に
• Best-effort compilation — 一部にエラーがあっても IDE 補完が効く
• コンパイル速度の改善 — Scala 2 時代の悪評が薄れつつある
• JDK 25 互換 — 最新の LTS と互換
• 新しい inline API — inline def のきめ細かいコントロール

コンパイル速度 — 最大の不満が消えつつある

Scala 2.x はコンパイル遅さで悪名高かったです。Scala 3.7 では以下のおかげで速くなりました。

依然として Java や Kotlin より遅いです。ただし「コーラを飲みながら待つコンパイル」は過去の話です。

マイグレーションツール

Scala 2 → 3 のマイグレーションは以下のツールで自動化されます。

# Scalafix - 自動リファクタリング
sbt "scalafixAll dependency:Scala3RewriteFromScala2Old@org.scalameta:scalafix-rules:0.13.0"

# Scala 3 コンパイラの自動マイグレーションモード
scalac -source:3.0-migration MyFile.scala

# scala-migrate CLI
cs install scala-migrate
scala-migrate migrate-build

ほとんどの Scala 2 コードは 80〜90% が自動マイグレーション で解決します。

3. Scala 4 preview — これから

Scala 4 はまだ正式リリースではありませんが、2025年後半から preview が活発に進んでいます。テーマは「Scala 3 で実験的に入った機能を正式化する」ことです。

Scala 4 が狙うもの

• Capture checking の正式化 — ミュータブルリソースの追跡、メモリ安全保証
• Named tuples の正式化 — 軽量レコード型
• Match types の改善 — 型レベルパターンマッチ
• 暗黙 (implicit) システムの単純化 — given / using に統一する方向
• コンパイラ内部の整理 — TASTy フォーマットの安定化

Capture checking とは

Scala 3.x で実験的に入り、Scala 4 で正式化される最大の変更です。関数が「どのリソースをキャプチャするか」を型システムが追跡します。

// Scala 4 preview
import scala.language.experimental.captureChecking

// f が io リソースをキャプチャすると宣言
def withFile[T](path: String)(f: File^ => T): T = ???
//                                ^ capability

// キャプチャされたリソースが外部に漏れないことをコンパイラが保証
val data = withFile("a.txt") { file =>
  file.readAll()
}
// コンパイルエラー: file を返してはいけない
val leaked = withFile("a.txt") { file => file }  // ERROR

これは Rust の borrow checker と似たアイデア ですが、JVM 上で動きます。実質的に ZIO / Cats Effect の Resource を言語レベルで扱うことになります。

Scala 4 のリリース時期

EPFL (Scala の生まれた場所) と Scala Center が「2026年後半〜2027年初頭」を公式目標として発表しています。ただし Scala は「メジャー番号変更でも互換性を破らない」というポリシーで進んでいるので、Scala 4 が出ても大半の Scala 3 コードはそのままビルドできます。

4. sbt 2.x / Mill / Scala CLI — ビルドツールの進化

長らく Scala のビルドツールは sbt でした。強力ですが学習コストが高く、一度壊れるとデバッグが地獄、という評判もよくありました。2026年の風景は変わっています。

sbt 2.x — 遅い移行

sbt 2.x は2024年から RC 段階にあり、2026年5月現在もまだ 1.x の完全な置き換えにはなっていません。主な変更点。

• ビルド定義を Scala 3 で書ける
• 新しい plugin model — 依存衝突の減少
• Task API の整理
• コンパイルと実行の分離 — インクリメンタルが改善

// build.sbt (sbt 2.x スタイル)
ThisBuild / scalaVersion := "3.7.0"
ThisBuild / version := "0.1.0-SNAPSHOT"

lazy val root = (project in file("."))
  .settings(
    name := "my-app",
    libraryDependencies ++= Seq(
      "dev.zio" %% "zio" % "2.1.10",
      "org.scalatest" %% "scalatest" % "3.2.19" % Test
    )
  )

Mill — Li Haoyi の代替案

Mill は Li Haoyi が作ったビルドツールです。sbt の「DSL マジック」に疲れた人のために、ビルドを純粋な Scala オブジェクト として定義します。

// build.sc
import mill._, scalalib._

object app extends ScalaModule {
  def scalaVersion = "3.7.0"
  def ivyDeps = Agg(
    ivy"dev.zio::zio:2.1.10"
  )

  object test extends ScalaTests {
    def ivyDeps = Agg(ivy"org.scalatest::scalatest:3.2.19")
    def testFramework = "org.scalatest.tools.Framework"
  }
}

Mill の強み。

• 明示的 — ビルドロジックがただの Scala メソッド。マジック無し
• 高速 — 変更検出が正確
• 理解可能なエラー — sbt よりデバッグが楽

Twitter や Databricks の一部チームが Mill に移ったと報告されています。

Scala CLI — スクリプトの正解

Scala CLI は Scala Center の公式ツール で、小さなスクリプト・POC・学習用には sbt を完全に置き換えます。

# インストール
brew install Virtuslab/scala-cli/scala-cli

# 1ファイルのスクリプト
scala-cli run hello.scala

# コード内で依存を宣言
cat > script.scala <<'EOF'
//> using scala 3.7.0
//> using dep dev.zio::zio:2.1.10

import zio._

object Main extends ZIOAppDefault:
  def run = Console.printLine("Hello from Scala CLI")
EOF

scala-cli run script.scala

# 単一バイナリにパッケージング (Scala Native)
scala-cli package --native --output myapp script.scala

Scala CLI は2024年以降、scala コマンドの公式バックエンド になっています。つまり scala myfile.scala を打つと、内部で Scala CLI が走ります。

ビルドツールの比較

5. ZIO 2 — 関数型 effect 陣営

ZIO は Scala の関数型 effect ライブラリで最も人気のあるものです。2026年5月時点で ZIO 2.1.x が標準、ZIO 3 のロードマップも公開されています。

ZIO の中核アイデア — ZIO[R, E, A]

ZIO 値は 3つの型パラメータ を持ちます。

• R (Environment) — この effect が実行されるのに必要な依存
• E (Error) — 失敗しうるエラー型
• A (Success) — 成功時に返される値型

import zio._

// Int を返すが Throwable で失敗しうる
val task1: ZIO[Any, Throwable, Int] = ZIO.attempt(42)

// DB 環境を要求し、AppError で失敗し、User を返す
val task2: ZIO[Database, AppError, User] =
  ZIO.serviceWithZIO[Database](_.getUser(123))

// 組み合わせ
val task3: ZIO[Database, AppError, String] =
  for {
    user <- task2
    _    <- Console.printLine(s"Got user: $user.name").orDie
  } yield user.name

ZIO Layer — 依存性注入

ZIO の最も強力な部分は Layer システム です。Spring DI の関数型版。

trait Database:
  def getUser(id: Int): Task[User]

class LiveDatabase(config: DbConfig) extends Database:
  def getUser(id: Int): Task[User] = ZIO.attempt(???)

object LiveDatabase:
  val layer: ZLayer[DbConfig, Nothing, Database] =
    ZLayer.fromFunction(LiveDatabase(_))

// 合成
val appLayer = DbConfig.layer >>> LiveDatabase.layer

ZIO 2 の新機能

• Scope によるリソース管理 — ZManaged を削除、より単純な API
• ZStream の安定化 — バックプレッシャ付きストリーム処理
• ZIO.attemptBlocking — ブロッキング作業の自動隔離
• ZIO.logSpan — 分散トレーシング統合

ZIO エコシステム

6. Cats Effect 3 — もう一つの関数型陣営

Cats Effect は ZIO と並ぶ Scala 関数型 effect の二大柱です。Typelevel 陣営 (Cats、Cats Effect、http4s、doobie など) が作ったライブラリで、IO[A] というシンプルな型 が中心です。

IO[A] — シンプルさの美学

import cats.effect._
import cats.implicits._

val program: IO[String] = for {
  _    <- IO.println("Enter your name:")
  name <- IO.readLine
  _    <- IO.println(s"Hello, $name!")
} yield name

object Main extends IOApp.Simple:
  def run: IO[Unit] = program.void

ZIO vs Cats Effect — どこが違うか

Cats Effect の強み

• typeclass ベース — MonadCancel、Concurrent、Async に分解されている
• Fiber による並行性 — 軽量グリーンスレッド
• Resource[F, A] によるリソース管理 — try-with-resources の関数型版
• Loom 互換 — JDK 21+ の仮想スレッドと自然に協調

// Resource で安全なリソース管理
val dbResource: Resource[IO, Connection] =
  Resource.make(IO(openConnection()))(c => IO(c.close()))

val program: IO[Unit] =
  dbResource.use { conn =>
    IO(conn.query("SELECT 1"))
  }
// 例外が出ても conn.close() は保証される

陣営選びの実際

現場では次のようなパターンが多いです。

• 新規チーム → ZIO 2 (学習資料が豊富、DI が自然)
• 既に Typelevel スタックを使っているチーム → Cats Effect 3
• どちらも使っていないチーム → Future や同期コードから始めて、必要なら導入

宗教戦争的な側面もあるため、チームが合意した側で進めればよいです。

7. Pekko (Apache、Akka fork) — BSL 騒動以降

Scala エコシステムで最も政治的で衝撃的な出来事は 2022年9月の Akka のライセンス変更 でした。

Akka が BSL 化した事件

Lightbend (Akka を作った会社) は2022年9月7日に Akka 2.7 以降を BSL (Business Source License) に転換 すると発表しました。主な条件。

• 非商用は無料
• 商用利用は年間一定の売上を超えると有料
• 3年後に Apache 2.0 へ転換 (delayed open source)

これは Scala コミュニティに衝撃を与えました。Akka は Play Framework、Lagom、Spark Streaming、そして多くの企業のバックボーンだったからです。Lightbend の立場は「会社が生き残らないとライブラリも生き残らない」 でしたが、コミュニティは「信頼が壊れた」と反応しました。

Apache Pekko の登場

2022年末、Apache Software Foundation 配下で Pekko がスタートしました。Akka 2.6.x を fork したプロジェクトで、100% Apache 2.0 ライセンスです。

// Akka (BSL)
import akka.actor.typed._
import akka.actor.typed.scaladsl._

// Pekko (Apache 2.0) - ほぼ同一
import org.apache.pekko.actor.typed._
import org.apache.pekko.actor.typed.scaladsl._

object Greeter:
  sealed trait Command
  case class Greet(name: String) extends Command

  def apply(): Behavior[Command] = Behaviors.receive { (ctx, msg) =>
    msg match
      case Greet(name) =>
        ctx.log.info(s"Hello $name")
        Behaviors.same
  }

違いは パッケージ名 akka.* → org.apache.pekko.* だけです。マイグレーションは sed 一行。

2026年の現実

• 新規プロジェクトはほぼ100% Pekko — 商用ライセンスリスクなし
• 既存 Akka ユーザは Pekko へ移行中 — Lightbend の売上は BSL で回復したが、信頼は回復できず
• Pekko のメジャーリリースが活発 — コミュニティが自力で発展
• Play Framework 3 も Pekko ベース

Pekko の使い所

• 分散システム — アクターモデルで大規模処理
• ストリーミング — Pekko Streams、Pekko Connectors (Kafka、Cassandra など)
• HTTP サーバ — Pekko HTTP
• イベントソーシング — Pekko Persistence

イベント駆動システムを作るなら、2026年では Pekko が事実上の標準です。

8. Play Framework 3 / http4s / Tapir — Web

Scala の Web フレームワークは 3つの陣営 に整理されます。

Play Framework 3 — フルスタックフレームワーク

Play 3 は Rails のようなフルスタック MVC フレームワークです。2023年末に Pekko ベースで再構築されました。

// Play 3 のコントローラ
package controllers

import javax.inject._
import play.api.mvc._

@Singleton
class HomeController @Inject() (cc: ControllerComponents)
  extends AbstractController(cc):

  def index() = Action { implicit request =>
    Ok("Hello from Play 3")
  }

  def user(id: Int) = Action.async { implicit request =>
    userService.get(id).map(u => Ok(Json.toJson(u)))
  }

メリット — フルスタック、テンプレートエンジン、フォーム検証、アセットパイプラインすべて込み。 デメリット — 「関数型っぽくない」、学習コスト。

http4s — 関数型 Web

http4s は Cats Effect ベースの純粋関数型 Web サーバ です。

import cats.effect._
import org.http4s._
import org.http4s.dsl.io._
import org.http4s.implicits._
import org.http4s.ember.server._
import com.comcast.ip4s._

val helloService = HttpRoutes.of[IO] {
  case GET -> Root / "hello" / name =>
    Ok(s"Hello, $name")
}.orNotFound

object Main extends IOApp.Simple:
  def run = EmberServerBuilder
    .default[IO]
    .withHost(ipv4"0.0.0.0")
    .withPort(port"8080")
    .withHttpApp(helloService)
    .build
    .useForever

メリット — 純粋関数型、動作が明確、Cats Effect と自然に統合。 デメリット — 最初はマジックに見える、ミドルウェア記述が難しい。

Tapir — 型安全な API 定義

Tapir は Scala コミュニティの秘密兵器です。エンドポイントを型レベルで定義 すると、コード・クライアント・OpenAPI 仕様が自動生成されます。

import sttp.tapir._
import sttp.tapir.generic.auto._
import io.circe.generic.auto._
import sttp.tapir.json.circe._

case class User(id: Int, name: String)

// エンドポイントを値として定義
val getUser =
  endpoint
    .get
    .in("users" / path[Int]("id"))
    .out(jsonBody[User])
    .errorOut(stringBody)

// http4s で配信
import sttp.tapir.server.http4s.Http4sServerInterpreter
val routes = Http4sServerInterpreter[IO]()
  .toRoutes(getUser.serverLogic(id => IO.pure(Right(User(id, "Alice")))))

// 同じ定義から OpenAPI を生成
import sttp.tapir.docs.openapi.OpenAPIDocsInterpreter
val docs = OpenAPIDocsInterpreter().toOpenAPI(getUser, "My API", "1.0")
println(docs.toYaml)

エンドポイントを一度定義すると。

• HTTP サーバルート
• 型安全クライアント
• OpenAPI / Swagger 仕様
• 自動ドキュメント

がすべて手に入ります。バックエンドインターフェース定義の最先端と言えます。

どれを選ぶか

9. Scala.js / Scala Native 0.5 — 他プラットフォーム

Scala は JVM 専用の言語ではありません。Scala.js で JavaScript、Scala Native で LLVM ベースのネイティブバイナリを作れます。

Scala.js — JavaScript へコンパイル

Scala.js は Scala コードを JavaScript にコンパイルします。2026年は 1.18.x が標準で、React、Vue といった JS ライブラリとの相互運用もきれいです。

// Scala.js + Laminar (リアクティブ UI)
import com.raquo.laminar.api.L._

val app = div(
  h1("Hello Scala.js"),
  button(
    "Click me",
    onClick --> { _ =>
      println("Clicked!")
    }
  )
)

render(dom.document.getElementById("app"), app)

メリット — Scala の型システムをそのままフロントエンドに持ち込める、dead code elimination が強力でバンドルが小さい。 デメリット — JS エコシステムとの相互運用は可能だが、型定義を自分で書く必要がある場合がある。

Scala Native 0.5 — LLVM ネイティブ

Scala Native は Scala を LLVM IR にコンパイルしてネイティブバイナリを作ります。0.5.x (2024年リリース) 以降で本当に使える ようになりました。

// Hello, Scala Native
import scala.scalanative.unsafe._
import scala.scalanative.libc._

object Main:
  def main(args: Array[String]): Unit =
    stdio.printf(c"Hello from Scala Native! PID: %d\n", unistd.getpid())

# コンパイル
scala-cli package --native --output myapp Main.scala

# 実行 — JVM なしで即起動
./myapp

メリット。

• JVM 起動時間が無い — CLI ツールに最適
• メモリ使用量が小さい — Lambda / Cloud Run のようなサーバレスに良い
• GC を選べる — Boehm、Immix、Commix
• C ライブラリを直接呼べる

デメリット。

• JVM ライブラリ全部は使えない (リフレクション依存のもの)
• LLVM を通すのでコンパイルが遅い

Scala CLI + Scala Native の組み合わせで 単一バイナリの CLI ツール が作りやすいです。coursier、sbt-pack といったツールもこの組み合わせで配布されています。

10. Spark Scala — データエンジニアリング

Scala が2026年も生き残った最大の理由の一つが Apache Spark です。Spark のコアは Scala で書かれており、Scala API が最速かつ最も表現力豊か です。

Spark の現状

• Spark 3.5.x (2024年) / Spark 4.0 (2025年リリース予定)
• Python (PySpark) がシェアは大きいが、高性能や複雑な変換は依然 Scala
• Databricks、Palantir などの大手データ会社は Scala Spark がメイン

Scala で Spark を書く

import org.apache.spark.sql.SparkSession
import org.apache.spark.sql.functions._

val spark = SparkSession.builder
  .appName("Example")
  .master("local[*]")
  .getOrCreate()

import spark.implicits._

case class Transaction(userId: Int, amount: Double, ts: String)

val df = Seq(
  Transaction(1, 100.0, "2026-01-01"),
  Transaction(1, 200.0, "2026-01-02"),
  Transaction(2, 50.0, "2026-01-01")
).toDF()

val agg = df
  .groupBy("userId")
  .agg(
    sum("amount").as("total"),
    count("*").as("tx_count")
  )
  .orderBy(desc("total"))

agg.show()

Frameless — 型安全な Spark

Frameless は Spark の DataFrame を型安全にラップし、コンパイル時にカラム名のタイポを検出します。

import frameless._
import frameless.syntax._

val ts: TypedDataset[Transaction] = TypedDataset.create(transactions)

val totals: TypedDataset[(Int, Double)] = ts
  .groupBy(ts('userId))
  .agg(sum(ts('amount)))
  .as[(Int, Double)]

// コンパイルエラー: 'amounnt' というカラムはない
val bad = ts.select(ts('amounnt))  // コンパイル不可

Scala 3 にマイグレーションされた Frameless 0.16+ が安定しています。

データエンジニアは Scala を学ぶべきか

• PySpark が60%のシェア — Python から始めて良い
• しかしインフラ/プラットフォームチームはほぼ Scala — Databricks 自体も Scala
• 性能が重要な変換は Scala が明確に速い — JVM 直呼び出しでシリアライズオーバーヘッドなし
• 結論 — データアナリストは Python、データインフラ/プラットフォームエンジニアは Scala

11. Effect.ts — TS に渡った Scala のアイデア

2020年代中頃の興味深い現象が、Scala のアイデアが TypeScript に逆輸出 されたことです。代表例が Effect.ts です。

Effect.ts とは

Effect.ts は ZIO と Cats Effect の中核アイデアを TypeScript に移植したライブラリです。

// Effect.ts (TypeScript)
import { Effect, Console } from "effect"

const program = Effect.gen(function* () {
  yield* Console.log("Enter your name:")
  const name = "Alice"  // 実際には入力を受け取る
  yield* Console.log(`Hello, ${name}`)
  return name
})

Effect.runPromise(program).then(console.log)

ZIO と比べると、事実上同じ構造です。

// ZIO (Scala)
import zio._

val program = for {
  _    <- Console.printLine("Enter your name:")
  name <- ZIO.succeed("Alice")
  _    <- Console.printLine(s"Hello, $name")
} yield name

Runtime.default.unsafeRun(program)

なぜこんなことが起こったか

• TypeScript の型システムが十分に発展した — ジェネリクス、条件型、infer で effect を追跡できる
• JS エコシステムの非同期地獄 — Promise / async-await では限界
• 関数型陣営の TS ユーザの増加 — Haskell、Scala 出身者が TS に来た
• エラーハンドリング標準化の要求 — Either、Option のようなパターンが TS でも人気に

これが Scala に与える意味

• Scala が生んだパターンが 言語を超えて生き残る という証明
• Scala ユーザが TS フルスタックをやる際、自然に Effect.ts を使える
• 逆に TS で関数型を深く学んだ人は Scala に自然に移れる

Scala コミュニティでは「私たちのアイデアが mainstream になった」と誇りに思う空気があります。

12. Iron — refined types

Iron は Scala 3 専用ライブラリで refined types を実装します。コンパイル時に型に制約を課すツールです。

Refined Type とは

「Int だが0より大きい」「String だがメール形式」のような制約を型システムにエンコードします。

import io.github.iltotore.iron._
import io.github.iltotore.iron.constraint.all._

// 正の整数
type PositiveInt = Int :| Positive
val age: PositiveInt = 30  // OK
val bad: PositiveInt = -5  // コンパイルエラー

// メール
type Email = String :| Match["""[\w.+]+@[\w.]+"""]
val email: Email = "a@b.com"  // OK
val notEmail: Email = "hello"  // コンパイルエラー

// 関数でも
def sendEmail(to: Email, body: String :| MinLength[1]): Unit = ???

Iron の強み

• ランタイム検証なしで型安全 — 通常の Int / String とメモリ互換
• Scala 3 マクロでコンパイル時チェック — リテラルはコンパイラが検証
• 任意の条件を定義可能 — ドメインルールを型で表現

// ユーザドメインの型
type UserId = Int :| Positive
type UserName = String :| (MinLength[2] & MaxLength[50])

case class User(id: UserId, name: UserName)

// コンパイル時に弾く
val u = User(0, "X")
// ERROR: 0 は Positive ではない、"X" は MinLength[2] を満たさない

他言語との比較

• TypeScript の Brand types — Iron の弱いバージョン
• Rust の newtype パターン — 同じ意図、検証は弱い
• Haskell の refined types — 最も近いパターン
• F# の units of measure — 一部重なる

Iron は 2026年に Scala が持つ最強の型安全ツール の一つです。

13. doobie / Slick — DB ライブラリ

Scala の DB ライブラリは大きく doobie (関数型) と Slick (SQL DSL) に分かれます。

doobie — 純粋関数型 JDBC

doobie は Cats Effect 上で JDBC を関数型にラップします。

import doobie._
import doobie.implicits._
import cats.effect._

val xa = Transactor.fromDriverManager[IO](
  driver = "org.postgresql.Driver",
  url = "jdbc:postgresql:test",
  user = "u",
  password = "p",
  logHandler = None
)

case class User(id: Int, name: String)

// SQL interpolation — コンパイル時に型チェック
def findUser(id: Int): ConnectionIO[Option[User]] =
  sql"SELECT id, name FROM users WHERE id = $id".query[User].option

val program: IO[Option[User]] = findUser(1).transact(xa)

メリット — SQL をそのまま書く、型安全、Cats Effect 統合が完璧。 デメリット — SQL をよく知っている必要がある、ORM の自動マッピング無し。

Slick — 型安全な SQL DSL

Slick は SQL を Scala の DSL で表現します。ORM ではなくクエリビルダに近いです。

import slick.jdbc.PostgresProfile.api._

class Users(tag: Tag) extends Table[(Int, String)](tag, "USERS"):
  def id = column[Int]("ID", O.PrimaryKey)
  def name = column[String]("NAME")
  def * = (id, name)

val users = TableQuery[Users]

// Scala コードで SQL を書く
val query = users
  .filter(_.id === 1)
  .map(_.name)
  .result

val action = query
db.run(action).map(println)

メリット — SQL を知らなくても安全なクエリ、IDE 補完。 デメリット — 複雑なクエリで DSL が限界、デバッグが難しい。

どれを選ぶか

Quill — もう一つの選択肢

Quill はコンパイル時に Scala コードを SQL に変換します。ZIO 陣営が好むオプション。

import io.getquill._

val ctx = new SqlMirrorContext(PostgresDialect, SnakeCase)
import ctx._

case class User(id: Int, name: String)

val q = quote {
  query[User].filter(_.id == 1).map(_.name)
}

println(ctx.run(q).string)
// SELECT name FROM user WHERE id = 1

14. Lichess — Scala で書かれたチェスサイト

Scala で作られた最も有名な本番システムの一つが Lichess です。100%無料、100%オープンソースのチェスサイトで、月間アクティブユーザが数百万人 います。

Lichess の規模

この効率がぶっとんでいます。同規模のサイトが数十人のエンジニアを抱える中、Lichess は少人数と Scala で運営しています。

Lichess が Scala を使う理由 (Thibault Duplessis インタビュー要約)

• 型システムでバグをコンパイル時に捕捉 — 運用人員が少ないため必須
• 関数型パラダイムで並行性を安全に — 数万同時接続を安全に
• Akka (現在は Pekko) でアクターベースのゲーム処理 — ゲーム1試合がアクター1つ
• MongoDB + reactivemongo で非同期 DB — すべて Scala フレンドリー

Lichess の技術スタック

• 言語 — Scala 3 (2024年に Scala 2 からマイグレーション完了)
• Web フレームワーク — Play Framework
• アクターモデル — Pekko (元 Akka)
• DB — MongoDB
• フロントエンド — TypeScript (Snabbdom)
• インフラ — ベアメタルサーバ (OVH)

学べる点

• Scala の表現力は 小規模チームが大きなシステムを運用するのに決定的
• 「スタートアップ = JS / Python」の公式が絶対ではない
• オープンソース運営のお手本 — コードはすべて github.com/lichess-org にある

Lichess は Scala を検討するチームに「これが可能だ」という生きた証拠を提供します。

15. 韓国 / 日本 — Toss 一部、メガゾーン、Septeni、Money Forward

Scala は韓国・日本で主流言語ではありませんが、特定の企業で積極的に活用 されています。

韓国での Scala 採用

韓国では データエンジニアリング・プラットフォーム領域 で Scala が生きており、純粋なバックエンドはほぼ Kotlin / Java に移行しています。

日本での Scala 採用

日本は韓国より Scala 採用が活発な方です。

日本は 2010年代中盤から Scala コミュニティが活発 で、ScalaMatsuri のような大きなカンファレンスが毎年開かれています。

東アジアで Scala を学ぶべきか

• 純粋なバックエンド開発者 — Kotlin が優先、Scala は選択
• データエンジニア — Spark を深く触るなら Scala は大きな武器
• 関数型を深く掘りたい人 — Scala は JVM で最高の関数型言語
• 転職市場 — 韓国は狭く、日本は東京中心に市場あり

学習リソース (韓国語 / 日本語)

• Scala School (Twitter 公式韓国語訳)
• Programming in Scala (Odersky 本、韓国語訳)
• 日本語 — Scala逆引きレシピ
• ScalaMatsuri — 東京、年1回

16. 誰が Scala を選ぶべきか — データ / FP / JVM + ML

2026年に Scala を新しく学ぶべき人と、そうでない人を率直に整理します。

Scala が向いている場合

• データエンジニア — Spark が中心の環境
• 関数型を深く — Haskell や OCaml に惹かれるが JVM エコシステムが必要な場合
• 高性能な並行性 — Pekko でアクターベースシステムを設計
• 型安全性の最前線 — Iron、refined types、capture checking
• 小規模チームで大きなシステム — Lichess 級の運用効率
• JVM 上の ML — BigDL、Smile、Frameless 活用

Scala が向かない場合

• 採用を急ぐ — Scala 開発者は比較的少ない
• シンプルな CRUD バックエンド — Kotlin / Spring の方が圧倒的に速い
• Java / Kotlin チームに新規参加したばかり — 政治的コストが大きい
• フルスタック単独開発 — JS / TS エコシステムが豊富
• Cloud Native、Kubernetes ツール — Go が事実上の標準

学習パスの提案

初心者
  ↓
Scala CLI で小さなスクリプト (1〜2週間)
  ↓
「Programming in Scala 5th」または
「Effective Programming in Scala」(Scala Center)
  ↓
case class / sealed trait / for 内包に慣れる
  ↓
選択: ZIO 陣営 or Cats Effect 陣営
  ↓
実戦プロジェクト — http4s + Tapir で小さな API
  ↓
必要に応じて Pekko、Spark、Iron、doobie などへ拡張

他 JVM 言語との位置関係

JVM 上の ML

Python が ML の標準ですが、JVM 陣営にも次があります。

「学習は Python、推論は JVM」のパターンが増えており、Scala はその推論レイヤーをきれいに処理できます。

17. 参考 / References

Scala 公式

• Scala 公式サイト
• Scala 3 Reference
• Scala 3.6 Release Notes
• Scala 3.7 Release Notes
• Scala Center

ビルドツール

• sbt 公式
• Mill ビルドツール
• Scala CLI
• Coursier

Effect システム

• ZIO
• Cats Effect
• Typelevel 陣営

アクター・並行性

• Apache Pekko
• Akka (Lightbend、BSL)
• Lightbend BSL アナウンス

Web フレームワーク

• Play Framework
• http4s
• Tapir
• Scalatra

他プラットフォーム

• Scala.js
• Scala Native
• Laminar (Scala.js UI)

データ

• Apache Spark
• Frameless
• Smile (ML)
• BigDL

型システム

• Iron (refined types)
• Magnolify (typeclass derivation)

DB

• doobie
• Slick
• Quill

テスト・ロギング

• ScalaTest
• MUnit
• Scribe (ロギング)

Effect.ts (Scala の影響)

• Effect.ts 公式
• Effect.ts vs ZIO 比較

代表的な本番事例

• Lichess (Scala で書かれたチェスサイト)
• Lichess GitHub
• Lichess Thibault Duplessis ブログ

カンファレンス・コミュニティ

• Scala Days
• ScalaMatsuri (東京)
• Scala Korea (Meetup)

書籍

• "Programming in Scala, 5th Edition" — Martin Odersky 他
• "Effective Programming in Scala" — Julien Richard-Foy (Scala Center)
• "Functional Programming in Scala, 2nd Edition" — Paul Chiusano、Runar Bjarnason
• "Zionomicon" — John A. De Goes、Adam Fraser (ZIO 本、無料)