目次

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 3 の定着 | Scala 3.6 (2024.12) / 3.7 (2025.3) 安定化、Scala 4 preview 進行中 |

| ビルドツール分化 | sbt 2.x (遅い移行)、Mill (Li Haoyi)、Scala CLI (スクリプト・POC) |

| Effect system の二大派閥 | ZIO 2 vs Cats Effect 3 — 両陣営の共存 |

| Akka 騒動の余波 | Akka が BSL 化 (2022)、Apache Pekko に fork — 事実上の標準 |

| Web フレームワークの成熟 | http4s、Tapir、Play Framework 3 — 関数型 Web スタック |

| 他プラットフォーム | Scala.js (JS)、Scala Native 0.5 (ネイティブバイナリ) |

| データエンジニアリング | Apache Spark の中核言語 — 依然として大きな市場 |

| アイデアの逆輸出 | Effect.ts (TS)、Iron (refined types)、magnolify |

| 採用状況 | Lichess、Toss 一部、メガゾーン、Septeni、Money Forward など |

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 では以下のおかげで速くなりました。

| 技法 | 効果 |

|------|------|

| インクリメンタルコンパイル (Zinc) の改善 | 変更ファイルのみ再コンパイル |

| Pickle キャッシュ | 型情報の再利用 |

| 並列コンパイル | モジュール単位で並列化 |

| `bloop` を使う | バックグラウンドコンパイルサーバ |

依然として 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

// 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](https://mill-build.com/) は Li Haoyi が作ったビルドツールです。sbt の「DSL マジック」に疲れた人のために、**ビルドを純粋な Scala オブジェクト** として定義します。

// build.sc

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

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 が走ります。

ビルドツールの比較

| 項目 | sbt 2.x | Mill | Scala CLI |

|------|---------|------|-----------|

| 対象 | 大規模プロジェクト | 中〜大規模 | スクリプト・小さなアプリ |

| ビルド定義 | `build.sbt` (DSL) | `build.sc` (Scala オブジェクト) | `using` ディレクティブ |

| 学習コスト | 高い | 中 | ほぼ無し |

| 速度 | 普通 | 速い | 非常に速い |

| プラグインエコシステム | 非常に豊富 | 普通 | 限定的 |

| 推奨用途 | 既存 sbt プロジェクト | 新規プロジェクト | 学習・POC |

5. ZIO 2 — 関数型 effect 陣営

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

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

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

- `R` (Environment) — この effect が実行されるのに必要な依存

- `E` (Error) — 失敗しうるエラー型

- `A` (Success) — 成功時に返される値型

// 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 エコシステム

| ライブラリ | 役割 |

|------------|------|

| zio-http | HTTP サーバ・クライアント |

| zio-json | JSON シリアライズ |

| zio-config | 設定管理 |

| zio-quill | コンパイル時 SQL 生成 |

| zio-kafka | Kafka 統合 |

| zio-prelude | 関数型データ型 |

| zio-schema | スキーマベースシリアライズ |

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

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

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

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 — どこが違うか

| 項目 | ZIO 2 | Cats Effect 3 |

|------|-------|---------------|

| 中核型 | `ZIO[R, E, A]` | `IO[A]` |

| エラー追跡 | 型で明示 (`E`) | すべて `Throwable` |

| 依存性注入 | `Layer` システム | typeclass + `Resource` |

| 学習コスト | 高い (3つの型パラメータ) | 緩やか (1つのパラメータ) |

| エコシステム | zio-* シリーズ | Typelevel 陣営 |

| 哲学 | 「みんなで ZIO 内で」 | 「小さなライブラリの組み合わせ」 |

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)

// Pekko (Apache 2.0) - ほぼ同一

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](https://www.playframework.com/) は Rails のようなフルスタック MVC フレームワークです。2023年末に Pekko ベースで再構築されました。

// Play 3 のコントローラ

package controllers

@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](https://http4s.org) は **Cats Effect ベースの純粋関数型 Web サーバ** です。

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](https://tapir.softwaremill.com) は Scala コミュニティの秘密兵器です。**エンドポイントを型レベルで定義** すると、コード・クライアント・OpenAPI 仕様が自動生成されます。

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

// エンドポイントを値として定義

val getUser =

endpoint

.get

.in("users" / path[Int]("id"))

.out(jsonBody[User])

.errorOut(stringBody)

// http4s で配信

val routes = Http4sServerInterpreter[IO]()

.toRoutes(getUser.serverLogic(id => IO.pure(Right(User(id, "Alice")))))

// 同じ定義から OpenAPI を生成

val docs = OpenAPIDocsInterpreter().toOpenAPI(getUser, "My API", "1.0")

println(docs.toYaml)

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

- HTTP サーバルート

- 型安全クライアント

- OpenAPI / Swagger 仕様

- 自動ドキュメント

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

どれを選ぶか

| シチュエーション | 推奨 |

|------------------|------|

| フルスタック Web アプリ (テンプレート込み) | Play 3 |

| 関数型マイクロサービス | http4s + Tapir |

| 大きな API + スキーマファースト | Tapir + 任意のバックエンド |

| アクターベースの並行性 | Pekko HTTP |

| 新規チーム、学習コスト低め | Tapir + http4s |

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

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

Scala.js — JavaScript へコンパイル

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

// Scala.js + Laminar (リアクティブ UI)

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](https://scala-native.org) は Scala を LLVM IR にコンパイルしてネイティブバイナリを作ります。**0.5.x (2024年リリース) 以降で本当に使える** ようになりました。

// Hello, Scala Native

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 を書く

val spark = SparkSession.builder

.appName("Example")

.master("local[*]")

.getOrCreate()

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](https://typelevel.org/frameless/) は Spark の `DataFrame` を型安全にラップし、コンパイル時にカラム名のタイポを検出します。

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](https://effect.website) です。

Effect.ts とは

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

// Effect.ts (TypeScript)

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)

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](https://github.com/Iltotore/iron) は Scala 3 専用ライブラリで **refined types** を実装します。コンパイル時に型に制約を課すツールです。

Refined Type とは

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

// 正の整数

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](https://medium.com/@KevinBGreene/typescript-branded-types-and-the-pattern-for-domain-modeling-d016eb71affd) — 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](https://typelevel.org/doobie/) は Cats Effect 上で JDBC を関数型にラップします。

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](https://scala-slick.org) は SQL を Scala の DSL で表現します。ORM ではなくクエリビルダに近いです。

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 が限界、デバッグが難しい。

どれを選ぶか

| シチュエーション | 推奨 |

|------------------|------|

| SQL をよく知るチーム | doobie |

| ORM に慣れたチームからの移行 | Slick |

| Cats Effect スタック | doobie (自然な相性) |

| 複雑な動的クエリ | doobie (raw SQL の自由度) |

| マイグレーション自動化と一緒に | Slick (codegen が強力) |

Quill — もう一つの選択肢

[Quill](https://zio.dev/zio-quill/) はコンパイル時に Scala コードを SQL に変換します。ZIO 陣営が好むオプション。

val ctx = new SqlMirrorContext(PostgresDialect, SnakeCase)

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](https://lichess.org) です。100%無料、100%オープンソースのチェスサイトで、**月間アクティブユーザが数百万人** います。

Lichess の規模

| 指標 | 値 (2025年時点) |

|------|------------------|

| 日間ゲーム数 | 700万+ |

| 月間アクティブユーザ | 1億+ ページビュー |

| 同時接続 | 数万人 |

| スタッフ数 | フルタイム3〜4人 |

| 運用コスト | 月1万ドル程度 (寄付頼み) |

| コードベース | 100% Scala (バックエンド) |

この効率がぶっとんでいます。同規模のサイトが数十人のエンジニアを抱える中、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](https://github.com/lichess-org) にある

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

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

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

韓国での Scala 採用

| 企業 | 使い所 | 備考 |

|------|--------|------|

| Toss Payments | 一部バックエンド (精算・統計) | 中核は Kotlin、一部 Scala |

| メガゾーンクラウド | データプラットフォーム | Spark ベース |

| LINE 一部 | データエンジニアリング | Spark 中心 |

| Kakao 一部 | 検索・推薦システム | Spark + Scala |

| 多くのデータ会社 | Spark ベースの ETL | Scala が事実上の標準 |

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

日本での Scala 採用

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

| 企業 | 使い所 | 備考 |

|------|--------|------|

| Septeni (CyberAgent グループ) | 広告プラットフォームバックエンド | 大規模 Scala 利用 |

| Money Forward | 家計簿・B2B 会計 | Scala + Rails 混在 |

| freee | 会計 SaaS 一部 | 一部 Scala モジュール |

| Chatwork | チャット SaaS | Scala + Pekko |

| CyberAgent (AbemaTV) | 動画プラットフォーム一部 | Scala + Go |

| ドワンゴ | ニコニコ動画 | Scala 利用の歴史 |

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

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

- **純粋なバックエンド開発者** — Kotlin が優先、Scala は選択

- **データエンジニア** — Spark を深く触るなら Scala は大きな武器

- **関数型を深く掘りたい人** — Scala は JVM で最高の関数型言語

- **転職市場** — 韓国は狭く、日本は東京中心に市場あり

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

- [Scala School (Twitter 公式韓国語訳)](https://twitter.github.io/scala_school/ko/index.html)

- [Programming in Scala (Odersky 本、韓国語訳)](http://www.acornpub.co.kr/book/programming-in-scala-4e)

- 日本語 — [Scala逆引きレシピ](https://www.shoeisha.co.jp/book/detail/9784798125411)

- [ScalaMatsuri](https://scalamatsuri.org) — 東京、年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 言語との位置関係

| 言語 | 位置 | Scala との関係 |

|------|------|-----------------|

| Java | 豊富、企業数が多い | Scala が補完 — 難しい部分だけ Scala |

| Kotlin | バックエンドの新しい強者 | Scala より軽量、FP は弱い |

| Clojure | Lisp 系、動的 | Scala と非常に異なる哲学 |

| Groovy | DSL 用途 | Scala の方が強力 |

JVM 上の ML

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

| ライブラリ | 役割 |

|------------|------|

| BigDL | Spark 上の分散ディープラーニング |

| Smile | 統計・ML ライブラリ |

| Frameless | 型安全 Spark |

| Deeplearning4j | DL on JVM (Java 寄り) |

| ONNX Runtime Java | Python で学習 → JVM で推論 |

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

17. 参考 / References

Scala 公式

- [Scala 公式サイト](https://www.scala-lang.org)

- [Scala 3 Reference](https://docs.scala-lang.org/scala3/reference/)

- [Scala 3.6 Release Notes](https://www.scala-lang.org/news/3.6.0/)

- [Scala 3.7 Release Notes](https://www.scala-lang.org/news/3.7.0/)

- [Scala Center](https://scala.epfl.ch)

ビルドツール

- [sbt 公式](https://www.scala-sbt.org)

- [Mill ビルドツール](https://mill-build.com)

- [Scala CLI](https://scala-cli.virtuslab.org)

- [Coursier](https://get-coursier.io)

Effect システム

- [ZIO](https://zio.dev)

- [Cats Effect](https://typelevel.org/cats-effect/)

- [Typelevel 陣営](https://typelevel.org)

アクター・並行性

- [Apache Pekko](https://pekko.apache.org)

- [Akka (Lightbend、BSL)](https://akka.io)

- [Lightbend BSL アナウンス](https://www.lightbend.com/blog/why-we-are-changing-the-license-for-akka)

Web フレームワーク

- [Play Framework](https://www.playframework.com)

- [http4s](https://http4s.org)

- [Tapir](https://tapir.softwaremill.com)

- [Scalatra](https://scalatra.org)

他プラットフォーム

- [Scala.js](https://www.scala-js.org)

- [Scala Native](https://scala-native.org)

- [Laminar (Scala.js UI)](https://laminar.dev)

データ

- [Apache Spark](https://spark.apache.org)

- [Frameless](https://typelevel.org/frameless/)

- [Smile (ML)](https://haifengl.github.io/)

- [BigDL](https://bigdl.readthedocs.io)

型システム

- [Iron (refined types)](https://github.com/Iltotore/iron)

- [Magnolify (typeclass derivation)](https://github.com/spotify/magnolify)

DB

- [doobie](https://typelevel.org/doobie/)

- [Slick](https://scala-slick.org)

- [Quill](https://zio.dev/zio-quill/)

テスト・ロギング

- [ScalaTest](https://www.scalatest.org)

- [MUnit](https://scalameta.org/munit/)

- [Scribe (ロギング)](https://github.com/outr/scribe)

Effect.ts (Scala の影響)

- [Effect.ts 公式](https://effect.website)

- [Effect.ts vs ZIO 比較](https://effect.website/docs/why-effect)

代表的な本番事例

- [Lichess (Scala で書かれたチェスサイト)](https://lichess.org)

- [Lichess GitHub](https://github.com/lichess-org)

- [Lichess Thibault Duplessis ブログ](https://lichess.org/blog)

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

- [Scala Days](https://scaladays.org)

- [ScalaMatsuri (東京)](https://scalamatsuri.org)

- [Scala Korea (Meetup)](https://www.meetup.com/scala-korea/)

書籍

- "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 本、無料)