Skip to content

필사 모드: モダン Scala 2026 完全ガイド - Scala 3.6 · ZIO 2 · Cats Effect 3 · Akka 23 → Apache Pekko · Mill · sbt · Laminar 徹底解説

日本語
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.
원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

プロローグ — 2026 年、Scala は「難しい言語」から「選べる言語」になった

2020 年の Scala にはまだ「強力だが複雑」という印象が強かった。ビルドは sbt 一択、implicit conversion で IDE が固まり、Akka が JVM の actor モデルの代名詞だった。

2026 年の風景はまったく違う。

- **Scala 3.6** が安定 LTS として定着した。Scala 2.13 から 3 への移行は `scala3-migrate` でほぼ自動化されている。

- **エフェクトシステム三国志** — Cats Effect 3.5(Typelevel)、ZIO 2.1(John De Goes)、Kyo(Flavio Brasil)—— が明確な陣営を形成した。

- **Akka が BSL ライセンスへ移行**(2022)した後、コミュニティは **Apache Pekko 1.0** へ移った。同じコード、違うガバナンス。

- **ビルドツール三つ巴** — sbt 1.10.5、Mill 0.12(Lihaoyi)、scala-cli — が用途別に住み分けた。

- **Scala.js フロントエンド** — Laminar 17、Tyrian、Outwatch — が「TypeScript の代替」として地位を確立。

- **Scala Native 0.5** と **GraalVM Native Image** で AOT コンパイルが実用段階に入った。

Scala はもう「JVM 上の関数型」の同義語ではない。道具箱だ。本稿はその全体地形を一度にまとめる。

> 一行要約: **「何を証明したいか、どこで動かすか、チームはどのパラダイムに慣れているか」**。この 3 つの問いが Scala の道具選びの 90 % を決める。

第 1 章 · Scala 3 — Dotty が生き残った話

**Scala 3** は 2021 年 5 月に安定版が出た。旧コードネーム Dotty(Martin Odersky、EPFL)は 8 年がかりの大改修で、まったく新しい型システムの上に書き直された。DOT calculus(Dependent Object Types)を基盤に、型システムの隅々まで形式的に整理した成果物だ。

2026 年時点で 3 つの LTS ラインが併存する。

| バージョン | 状態 | 特徴 |

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

| Scala 3.3 LTS | 長期サポート | 保守的安定性、ライブラリ互換 |

| Scala 3.5 | next | named tuples、インデント改善 |

| Scala 3.6 / 3.7 | latest | capture checking、`given` の明示化、Quotes 再整理 |

**Scala 2.13** も死んでいない。Spark 3.5 のような大規模ライブラリは依然 2.13 をデフォルトターゲットにする。Scala 2.13 と 3 の双方向互換(TASTy)により、1 つのプロジェクトで両バージョンを併用できる。

> Scala 3 の本当の意味は文法ではなく **型システムの大掃除** だった。implicit が `given` / `using` / `extension` に分解され、構造型が整理され、マクロが Quotes API に再設計された。

第 2 章 · Scala 3.5 / 3.6 / 3.7 の新文法 — Named Tuples から Capture Checking まで

代表的な新文法。

// named tuples (Scala 3.5+) — 匿名構造体風

val person: (name: String, age: Int) = (name = "Yuna", age = 28)

val p2 = (name = "Min", age = 31)

val nm: String = person.name

// extension methods — implicit class の後継

extension (s: String)

def shout: String = s.toUpperCase + "!"

"hello".shout // "HELLO!"

// given / using — implicit の明示化

trait Show[A]:

def show(a: A): String

given Show[Int] with

def show(a: Int): String = s"int:$a"

def render[A](a: A)(using s: Show[A]): String = s.show(a)

// enum — sealed trait の sugar

enum Status:

case Active, Paused, Closed(reason: String)

// match types — 型レベル分岐

type Elem[X] = X match

case String => Char

case Array[t] => t

// inline + macros — Quotes API

inline def log(inline msg: String): Unit =

${ logImpl('msg) }

**capture checking**(Scala 3.6+)は、関数が「どの外部リソースを捕捉するか」を型に書き込む。実験段階だが、将来のエフェクト追跡に向けた布石であり、仮想的な Scala 4 へのステップだ。

第 3 章 · Scala 2.13 → 3 移行 — 自動化の限界と現実

2026 年時点で大規模コードベースの Scala 3 移行は事実上の標準手順を踏む。

1. **`sbt-tasty-mima`** または **`mima`** でバイナリ互換性チェック。

2. **`scalafix`** のルールセット(`Procedure.scala2`、`ExplicitResultTypes` ほか)で自動書き換え。

3. **`scala3-migrate`** sbt プラグインで implicit、デフォルト引数、型パラメータの差分を自動パッチ。

4. Scala 2.13 でビルドが通る状態のまま **`-Xsource:3`** と **`-Wconf`** を有効化し、警告 0 にする。

5. コンパイラを Scala 3 に切り替え、残りのエラーを手動で直す。

// Scala 2.13 の implicit class

implicit class StringOps(val s: String) extends AnyVal {

def shout: String = s.toUpperCase + "!"

}

// Scala 3 の extension — 自動変換

extension (s: String)

def shout: String = s.toUpperCase + "!"

難所は **マクロ**(Scala 2 の def-macros から Scala 3 の Quotes API へ)、**HKT の variance**、そして **shapeless 流の typeclass derivation**(現在は `Mirror` に置換)の 3 つ。コードベースがこの 3 つに依存しているほど移行コストは倍増する。

> 実務 Tip: ライブラリから先に移行し、アプリは最後。Scala 3 が Scala 2.13 ライブラリを取り込むのは可能だが、逆は難しい。

第 4 章 · エフェクトシステム三国志 — Cats Effect 3.5 · ZIO 2.1 · Kyo

Scala 関数型陣営の中心は **エフェクトシステム** だ。副作用(IO、並行性、リソース、エラー)を型で表現し、推論とテストを可能にする。

| ライブラリ | 陣営 | 中核抽象 | 性格 |

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

| Cats Effect 3.5 | Typelevel | `IO[A]`、`Resource[F, A]`、`Ref[F, A]` | 型クラス基盤、fs2 と組む |

| ZIO 2.1 | John De Goes | `ZIO[R, E, A]` | モノリシック、R/E/A 3 トラック |

| Kyo | Flavio Brasil | algebraic effects | 最新、ハンドラ基盤 |

Cats Effect 3 はあらゆる effect を `IO` 一つに詰める。ZIO は環境 R、エラー E、成功 A を型に直接出す。Kyo は algebraic effects(Eff モナド族)でハンドラ合成を強調する。

// Cats Effect 3

val program: IO[Unit] =

for

_ <- Console[IO].println("name?")

n <- Console[IO].readLine

_ <- Console[IO].println(s"hi $n")

yield ()

// ZIO 2

val zioProg: ZIO[Any, java.io.IOException, Unit] =

for

_ <- Console.printLine("name?")

n <- Console.readLine

_ <- Console.printLine(s"hi $n")

yield ()

選択基準は単純だ。**型クラス親和 + ライブラリ互換** なら Cats Effect。**明示的環境 + 統合ライブラリ** なら ZIO。**最新のエフェクト理論 + 軽量** なら Kyo。1 つのプロジェクトで 2 つを混在させるのは推奨しない。

第 5 章 · Cats Effect 3.5 — Typelevel スタックの心臓

**Cats Effect**(Typelevel、Daniel Spiewak が主導)は `IO`、`Resource`、`Ref`、`Deferred`、`Semaphore` のような並行プリミティブと fiber スケジューラを提供する。fiber は OS スレッドより軽い協調的並行ユニットで、JVM のネイティブスレッドを譲ることができる。

object App extends ResourceApp.Forever:

def run(args: List[String]): Resource[IO, Unit] =

for

_ <- Resource.eval(IO.println("start"))

_ <- Resource.make(IO.pure(42))(_ => IO.println("close"))

yield ()

Cats Effect の強みは **型クラス合成** だ。`Sync`、`Async`、`Concurrent`、`Temporal`、`MonadCancel` といった階層が明確なので、ライブラリは「必要な能力の最小集合」だけを要求できる。Doobie、http4s、fs2 はすべて Cats Effect の上にある。

> Cats Effect は「小さな部品を合成」する美学。ZIO との最大の哲学的違いはここにある。

第 6 章 · ZIO 2.1 — モノリシック統合スタック

**ZIO**(John A De Goes、Ziverge)はエフェクト型そのものに環境を埋め込む。`ZIO[R, E, A]` は「R を受け取り、E で失敗するか A で成功」を意味する。

trait UserRepo:

def findById(id: Long): ZIO[Any, Throwable, Option[String]]

object UserRepo:

val live: ZLayer[Any, Nothing, UserRepo] = ZLayer.succeed {

new UserRepo:

def findById(id: Long) = ZIO.succeed(Some(s"user-$id"))

}

val app: ZIO[UserRepo, Throwable, Unit] =

for

repo <- ZIO.service[UserRepo]

u <- repo.findById(1L)

_ <- Console.printLine(u.toString)

yield ()

object Main extends ZIOAppDefault:

def run = app.provide(UserRepo.live)

ZIO の強みは **batteries-included**。ZIO HTTP、ZIO Schema、ZIO JSON、ZIO Streams、ZIO Test、ZIO Config と、同じ設計のライブラリ群が一つの陣営を形成する。学習コストはあるが、定着すれば「一つの思考法」でスタック全体を書ける。

> ZIO は「一つの器にすべてを盛る」美学。Cats Effect の合成主義と対をなす。

第 7 章 · Kyo — 最新のエフェクトライブラリ

**Kyo**(Flavio Brasil、元 Twitter)は algebraic effects を直接モデル化する。エフェクトを型に蓄積し、ハンドラが処理する。Idris のエフェクトシステムに近い。

def program: Int < (IO & Abort[Throwable] & Async) =

for

_ <- IO(println("start"))

n <- Async.runFiber(IO(42)).await

yield n

`A < S` は「結果 A、エフェクト S」を意味する。S はエフェクトの合成。ZIO の R/E/A 3 トラックよりも汎化された形だ。

Kyo は 2024–2025 年に急成熟し、2026 年時点では「次世代エフェクトライブラリ」と評される。ただしライブラリエコシステムはまだ Cats Effect/ZIO に届かない。

第 8 章 · Akka 23.x → Apache Pekko 1.0 — ライセンスが分けた 2 つの道

2022 年 9 月、Lightbend は **Akka 2.7 以降を BSL(Business Source License)** に変更した。非商用は無料だが商用は有料。この決定は OSS コミュニティに衝撃を与えた。

応答として ASF(Apache Software Foundation)配下で **Apache Pekko** が始まった。Akka 2.6.x のコードを fork し、パッケージ名を `akka` → `org.apache.pekko` に変えただけのものだ。

| ツール | ライセンス | ガバナンス | 状況 |

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

| Akka 23.x | BSL 1.1 + 商用 | Lightbend | 新機能が活発 |

| Apache Pekko 1.0 | Apache 2.0 | ASF | Akka 2.6 互換 + 段階的拡張 |

コード移行はほぼパッケージ名の置換に過ぎない。

// Akka

// Apache Pekko

val behavior: Behavior[String] = Behaviors.receive { (ctx, msg) =>

ctx.log.info(msg)

Behaviors.same

}

2026 年時点で新規プロジェクトはほぼ全て Apache Pekko を採用する。既存 Akka 利用企業もライセンス料と移行コストを天秤にかけ、移行する傾向が強い。

> ライブラリにとってライセンスは identity だ。この出来事は OSS コミュニティが「ガバナンスの安定性」をいかに重視するかを示した。

第 9 章 · Actor と Streams — Apache Pekko 1.0 の中核

Pekko(Akka も同じ)の二本柱は **typed actor** と **streams**。

enum Cmd:

case Inc, Dec, Get(replyTo: org.apache.pekko.actor.typed.ActorRef[Int])

def counter(n: Int): org.apache.pekko.actor.typed.Behavior[Cmd] =

Behaviors.receiveMessage {

case Cmd.Inc => counter(n + 1)

case Cmd.Dec => counter(n - 1)

case Cmd.Get(r) =>

r ! n

Behaviors.same

}

val sys = ActorSystem(counter(0), "demo")

Streams は Reactive Streams 規格の上に作られた fluent DSL。

val source: Source[Int, NotUsed] = Source(1 to 10)

val flow: Flow[Int, Int, NotUsed] = Flow[Int].map(_ * 2)

val sink: Sink[Int, scala.concurrent.Future[Int]] = Sink.fold(0)(_ + _)

val total = source.via(flow).runWith(sink)

Akka HTTP / Pekko HTTP、Akka Cluster / Pekko Cluster、Akka Persistence / Pekko Persistence — ライセンス差だけで機能対応は 1:1。

第 10 章 · http4s · Tapir · ZIO HTTP — Scala HTTP ライブラリ三つ巴

Scala HTTP の主力候補は 3 つ。

| ライブラリ | 陣営 | 性格 |

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

| http4s 0.23+ | Typelevel | `HttpRoutes[F]`、型安全、fs2 ベース |

| Tapir 1.x | softwaremill | 宣言的エンドポイント、バックエンドアダプタ |

| ZIO HTTP | ZIO | ZIO ネイティブ、高性能 |

**http4s** は関数型 HTTP の王道。

val routes = HttpRoutes.of[IO] {

case GET -> Root / "hello" / name =>

Ok(s"hi $name")

}

**Tapir** はエンドポイントをデータとして宣言し、OpenAPI / Swagger / 型安全クライアントを自動生成する。

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

val getUser = endpoint

.get

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

.out(jsonBody[User])

.errorOut(stringBody)

**ZIO HTTP** は ZIO ネイティブのルーティング + 高性能。zio-http はベンチマークでしばしば 1 位を取る。

選択は陣営に従う。Cats Effect スタックなら http4s、ZIO スタックなら ZIO HTTP、バックエンド独立性が欲しいなら Tapir。

第 11 章 · sbt 1.10.5 · Mill 0.12 · scala-cli — ビルドツール三つ巴

長らく sbt が事実上唯一の選択肢だった。2026 年は 3 つが併存する。

| ツール | 作者・組織 | 強み | 弱み |

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

| sbt 1.10.5 | Lightbend → コミュニティ | 互換性最大、プラグイン豊富 | 学習曲線、遅い |

| Mill 0.12 | Li Haoyi | 簡潔な Scala DSL、速い増分ビルド | プラグイン少なめ |

| scala-cli | Virtus Lab | 単一ファイルスクリプト向き | 大規模には不向き |

`build.sbt` 例。

// build.sbt

ThisBuild / scalaVersion := "3.6.0"

ThisBuild / organization := "example"

lazy val core = (project in file("core"))

.settings(

libraryDependencies ++= Seq(

"org.typelevel" %% "cats-effect" % "3.5.4",

"org.http4s" %% "http4s-ember-server" % "0.23.27"

)

)

Mill `build.sc`。

// build.sc

object core extends ScalaModule {

def scalaVersion = "3.6.0"

def ivyDeps = Agg(

ivy"org.typelevel::cats-effect:3.5.4",

ivy"org.http4s::http4s-ember-server:0.23.27"

)

}

scala-cli は依存をファイル冒頭に書く。

//> using scala 3.6.0

//> using dep org.typelevel::cats-effect:3.5.4

object Hello extends IOApp.Simple:

def run = IO.println("hi")

scala-cli は 2024 年に公式 Scala ランナー(`scala run`)に採用された。小さなスクリプト、データ分析、学習用途では事実上の標準。大規模プロジェクトは sbt または Mill に行く。

第 12 章 · Scala.js · Laminar 17 · Tyrian — Scala で書くフロントエンド

**Scala.js** は Scala を JavaScript にコンパイルする。2026 年時点で安定し、webpack/vite 連携も滑らか。

**Laminar 17**(Nikita Gazarov)は reactive UI フレームワーク。FRP(functional reactive programming)基盤で、signal と observable で状態を管理する。

val name = Var("")

val app = div(

input(

placeholder := "your name",

onInput.mapToValue --> name

),

span(

"hi, ",

child.text <-- name.signal

)

)

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

**Tyrian** は Elm アーキテクチャ(model-update-view)を Scala.js に移植したフレームワーク。ゲームエンジン Indigo と組み合わさる。

**Outwatch**(Cornerman)は RxJS 風の observable ベース。**Lampagne** は新興の SSR 親和フレームワーク。

選択基準:

- 「React/Solid のような宣言的 UI」 — Laminar

- 「Elm のような単方向データフロー」 — Tyrian

- 「RxJS の慣れ + 小さなバンドル」 — Outwatch

> Laminar は「Scala で書ける最良のフロントエンド」と評される。TypeScript の代替として真剣に検討する価値がある。

第 13 章 · Scala Native 0.5 + GraalVM Native Image — AOT の 2 つの道

JVM は起動が遅い。CLI やサーバーレスでは致命的だ。解決策は 2 つ。

| ツール | 仕組み | 性格 |

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

| Scala Native 0.5 | LLVM バックエンドで直接コンパイル | JVM 不要、C 相互運用、小さなバイナリ |

| GraalVM Native Image | JVM バイトコードを AOT | 標準 Java/Scala、reflection 設定が必要 |

// Scala Native

object Hello:

def main(args: Array[String]): Unit =

println("hello native")

Scala Native — 直接 LLVM コンパイル

sbt nativeLink

GraalVM Native Image — JVM バイトコードを AOT

native-image -jar app.jar

Scala Native はライブラリ互換が制限される。JVM 依存ライブラリは動かない。GraalVM はほぼ全ての Java ライブラリが動くが、reflection と動的クラスロードの扱いが難しい。

サーバーレス(AWS Lambda、GCP Cloud Run)で Scala を使うにはこのどちらかが事実上必須。コールドスタートが 100 ms 以下に落ちる。

第 14 章 · Apache Spark 3.5 · Flink Scala — ビッグデータでの Scala の位置

**Apache Spark** は Scala で書かれており、Spark API は依然 Scala で最も自然だ。

| Spark バージョン | Scala ターゲット | 備考 |

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

| Spark 3.5 | Scala 2.13 / 2.12 | 2026 年の主力 |

| Spark 4.0(プレビュー) | Scala 2.13 / 3 | Connect、Spark Connect |

val spark = SparkSession.builder

.appName("demo")

.master("local[*]")

.getOrCreate()

val df = Seq(("a", 1), ("b", 2)).toDF("k", "v")

df.filter($"v" > 1).show()

**Apache Flink** にも Scala API がある。2023 年に Flink が Scala API を best-effort に格下げしたが、コミュニティが維持している。

**Apache Beam** には独自 SDK があり、Spotify の **Scio**(Scala wrapper)が最も人気。

ビッグデータ領域で Scala 2.13 はしばらく消えない。Spark の Scala 3 正式対応にはもう少し時間が要る。

第 15 章 · JSON · Schema · Codec — circe · jsoniter-scala · upickle

JSON ライブラリも陣営が分かれる。

| ライブラリ | 陣営 | 性格 |

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

| circe | Typelevel | 関数型、型クラス derivation |

| jsoniter-scala | Plokhotnyuk | マクロ生成の最速コーデック |

| upickle | Li Haoyi | 単純、依存軽量 |

| ZIO JSON | ZIO | ZIO ネイティブ、スキーマ統合 |

// circe

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

given Encoder[User] = deriveEncoder

given Decoder[User] = deriveDecoder

// jsoniter-scala

given JsonValueCodec[User] = JsonCodecMaker.make

ベンチマークでは jsoniter-scala が圧倒的に速い(ネイティブ `JSON.parse` より速い場合さえある)。circe は他の Typelevel ライブラリとの合成が滑らか。upickle は「ただ JSON が欲しい」ときに最も軽い。

第 16 章 · DB 層 — Doobie 1.0 · Skunk · Quill · ScalikeJDBC

**Doobie 1.0**(Typelevel)— JDBC 上の関数型 wrapper。Cats Effect 上で SQL を自然に書く。

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

val xa = Transactor.fromDriverManager[IO](

driver = "org.postgresql.Driver",

url = "jdbc:postgresql:db",

user = "u",

pass = "p",

logHandler = None

)

val all: IO[List[User]] =

sql"select id, name from users".query[User].to[List].transact(xa)

**Skunk**(Typelevel)— Postgres のネイティブプロトコルを nio 上に直接実装。JDBC 無し。最も速く最も小さい。

**Quill 4.x** — クエリを Scala 式として書き、コンパイル時に SQL に変換。型安全だが学習曲線あり。

**ScalikeJDBC** — Java JDBC に最も近い薄い wrapper。慣れを取りたいときに。

// Quill

val ctx = new PostgresJdbcContext(SnakeCase, "ctx")

val users = quote { query[User].filter(_.age > 18) }

ctx.run(users)

選択基準は陣営(Cats Effect / ZIO / 独立)と「SQL を直接書くか、Scala 式で書くか」。

第 17 章 · テスト — Munit · ScalaTest 3.2 · ZIO Test · weaver-test

テストフレームワークも豊富。

| フレームワーク | 陣営 | 性格 |

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

| Munit | Scala チーム | 簡潔、JUnit 互換 |

| ScalaTest 3.2 | クラシック | 多様なスタイル(FunSuite、FlatSpec、...) |

| ZIO Test | ZIO | ZIO ネイティブ、environment 注入 |

| weaver-test | disneystreaming | Cats Effect ネイティブ、デフォルト並列 |

// Munit

class MathSpec extends munit.FunSuite:

test("add"):

assertEquals(1 + 2, 3)

// ScalaTest FunSuite

class MathSuite extends org.scalatest.funsuite.AnyFunSuite:

test("add") { assert(1 + 2 == 3) }

// weaver-test

object MathSpec extends SimpleIOSuite:

pureTest("add"):

expect(1 + 2 == 3)

Munit が標準に近い。ZIO 陣営は ZIO Test、Cats Effect 陣営は weaver-test または Munit-CatsEffect を多用する。

第 18 章 · Iron · refined — 型で値を制約する

**refined**(fthomas)と **Iron**(Iltotore)は「値に型レベルの制約」を加える。例えば「正の整数だけを受ける」型が作れる。

// Iron (Scala 3)

type Age = Int :| Positive

val a: Age = 30 // OK

// val b: Age = -1 // compile error

// refined (Scala 2/3 互換)

val x: Int Refined Positive = refineMV[Positive](42)

Iron は Scala 3 専用でより軽く IDE フレンドリー。refined は Scala 2 互換性があり、ZIO Prelude などと連携する。

API 入出力の invariants を型に刻むのは関数型 Scala の核となる美学だ。

第 19 章 · 実運用 — Twitter→X、Databricks、Twilio、Disney+、SoFi

実際に Scala を運用している代表的な企業。

| 企業 | 使い方 |

| --- | --- |

| Twitter → X | Finagle、util、Finatra。インフラの大半が Scala。2023 年に一部 Rust 化 |

| Databricks | Spark が会社そのもの。Scala 2.12/2.13 を大規模運用 |

| Twilio | メッセージング基盤の一部に Akka/Pekko |

| Foursquare | 位置データ処理に Scala |

| ING Bank | 決済基盤、Cats Effect |

| SoFi | フィンテック基盤、ZIO |

| Disney+ | ストリーミング基盤の一部。weaver-test は Disney 発 |

| Iagon | 分散ストレージ、Cats Effect |

| Apple | Siri / iCloud の一部 |

| Netflix | 推薦・ストリーミング一部(過去はもっと多く) |

「全部 Scala」の企業は減り、「特定領域に Scala」の企業が増えた。これは他の JVM 言語(Kotlin、Java 21)の成熟とも関係する。ただし **データエンジニアリング、決済基盤、分散システム** の領域での Scala の地位は揺るがない。

第 20 章 · 日韓の Scala コミュニティ

**韓国**:

- **ScalaKorea** — 韓国 Scala ユーザーグループ。Kakao、LINE、Coupang、Woowa Brothers が中核。

- **Kakao Brain / Kakao Pay** — データパイプラインに Scala/Spark。

- **LINE** — メッセージング基盤の一部に Scala/Akka。Scala 2.13/3 併用。

- **Coupang** — データエンジニアリング一部。

- **Woowa Brothers** — カタログ・バッチに Scala。

- **NHN Cloud / Naver** — Hadoop エコシステム上の Scala/Spark。

**日本**:

- **ScalaMatsuri** — 東京で毎年開催されるアジア最大の Scala カンファレンス。

- **Scala Tokyo** — 東京 Scala ユーザーグループ。

- **CyberAgent** — 広告基盤に Scala。

- **Septeni** — 広告ドメイン。

- **メルカリ / Mercari** — 決済・精算の一部。

- **DMM.com** — 一部バックエンド。

- **NTT コミュニケーション科学研究所** — 学術・研究用途。

東アジアでの Scala 採用は **データエンジニアリング・広告・決済** に重心がある。日韓ともに Spark/Akka の用途が中心で、関数型ライブラリ(Cats Effect/ZIO)は新規プロジェクトを通じて急速に広がっている。

第 21 章 · Scala 3 の落とし穴とベストプラクティス

初めて Scala 3 に移るときに落ちる罠。

| 罠 | 症状 | 対処 |

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

| `implicit` を全部 `given` に置換 | 意味が変わる | `using` / `extension` / `given` を区別 |

| Scala 2 マクロをそのまま | コンパイル失敗 | Quotes API で書き直し |

| shapeless 導入 | Scala 3 では過剰 | `Mirror` ベース derivation に置換 |

| capture checking を早く有効化 | ライブラリ互換が壊れる | LTS では無効、新規モジュールだけ有効 |

| sbt + Mill + scala-cli 全部混在 | ビルド認知不協和 | どれか 1 つに統一 |

| Akka 23 で新規コード | ライセンス負担 | 新規は Apache Pekko |

| エフェクト陣営の混在 | 変換 boilerplate が爆発 | Cats Effect ↔ ZIO は境界だけで橋渡し |

| reflective Java API 依存 | Native Image でビルド失敗 | reflect-config または `@reflective` |

| implicit conversion を多用 | IDE が遅い、デバッグ困難 | 明示的変換を推奨 |

| Iron/refined を至るところで | コンパイル時間が伸びる | ドメイン invariants にだけ |

Scala 3 は道具が良くなった分、「思慮深い単純さ」をより強く報いる。

第 22 章 · 次の 5 年 — Scala の本格的な定着

最後に今後 5 年の流れ。

1. **Scala 3.3 LTS が固まる。** 新規コードはほぼ 3 に移るが、Spark が支える 2.13 ライブラリはもう少し長生きする。

2. **エフェクト陣営が絞られる。** Cats Effect と ZIO が安定陣営となり、Kyo が将来の標準候補として浮上。

3. **Apache Pekko が事実上の標準に。** 商用 Akka ライセンスは大企業限定に縮む。

4. **ビルドは sbt + scala-cli の 2 強** — Mill は特定チームの選択肢に。

5. **Laminar/Tyrian のような Scala.js フレームワーク** が小規模 SaaS のフルスタック Scala を可能に。

6. **Scala Native + GraalVM** によりサーバーレス/CLI Scala が一般化。

7. **AI 時代の Scala** — データパイプライン(Spark)が LLM のインデキシング・埋め込み標準となり、ZIO/Cats Effect 上の LLM クライアントが登場。

8. **標準化** — TASTy 安定化、マクロ API 安定化、ライブラリ API 互換文化の定着。

Scala はもう「複雑な関数型言語」ではない。道具箱だ。そしてその道具箱は、ふつうのエンジニアが選べる選択肢になりつつある。

エピローグ — どこから始めるか

本稿で扱った道具が多すぎると感じたら、次の学習経路を勧める。

1. **言語** — Scala 3 公式チュートリアルと『Programming in Scala』(Odersky ほか)第 5 版。

2. **ビルド** — scala-cli で単一ファイルスクリプトを実験。次に sbt または Mill でマルチモジュール。

3. **エフェクト** — Cats Effect か ZIO を 1 つ選び、「Bookings」のような小さな例を書く。

4. **HTTP** — http4s か Tapir で REST API を実装。

5. **DB** — Doobie か Skunk で Postgres に接続。

6. **フロントエンド** — Scala.js + Laminar で SPA 1 ページ。

7. **実運用** — Scala Native か GraalVM で小さな CLI をビルド。

> 「何を証明したいか、どこで動かすか、チームはどのパラダイムに慣れているか。」この 3 つの問いを携えて本文を読み返すと、道具選びは案外明快になる。

— Modern Scala 2026、了。

References

1. Odersky, M. et al. "Scala 3 Reference." [https://docs.scala-lang.org/scala3/reference/](https://docs.scala-lang.org/scala3/reference/)

2. Scala Center. "Scala 3 Migration Guide." [https://docs.scala-lang.org/scala3/guides/migration/compatibility-intro.html](https://docs.scala-lang.org/scala3/guides/migration/compatibility-intro.html)

3. Typelevel. "Cats Effect 3 Documentation." [https://typelevel.org/cats-effect/](https://typelevel.org/cats-effect/)

4. Ziverge. "ZIO 2 Documentation." [https://zio.dev/](https://zio.dev/)

5. Brasil, F. "Kyo Project." [https://github.com/getkyo/kyo](https://github.com/getkyo/kyo)

6. Lightbend. "Akka License Change Announcement." [https://www.lightbend.com/blog/why-we-are-changing-the-license-for-akka](https://www.lightbend.com/blog/why-we-are-changing-the-license-for-akka)

7. Apache Software Foundation. "Apache Pekko." [https://pekko.apache.org/](https://pekko.apache.org/)

8. http4s. "http4s Documentation." [https://http4s.org/](https://http4s.org/)

9. softwaremill. "Tapir Documentation." [https://tapir.softwaremill.com/](https://tapir.softwaremill.com/)

10. dream11. "ZIO HTTP." [https://zio.dev/zio-http/](https://zio.dev/zio-http/)

11. sbt Authors. "sbt Reference Manual." [https://www.scala-sbt.org/1.x/docs/](https://www.scala-sbt.org/1.x/docs/)

12. Haoyi, L. "Mill Build Tool." [https://mill-build.org/](https://mill-build.org/)

13. Virtus Lab. "scala-cli." [https://scala-cli.virtuslab.org/](https://scala-cli.virtuslab.org/)

14. Gazarov, N. "Laminar." [https://laminar.dev/](https://laminar.dev/)

15. PurpleKingdomGames. "Tyrian." [https://tyrian.indigoengine.io/](https://tyrian.indigoengine.io/)

16. Scala Native Team. "Scala Native 0.5." [https://scala-native.org/](https://scala-native.org/)

17. Apache Spark. "Spark Scala API." [https://spark.apache.org/docs/latest/api/scala/index.html](https://spark.apache.org/docs/latest/api/scala/index.html)

18. Plokhotnyuk, A. "jsoniter-scala." [https://github.com/plokhotnyuk/jsoniter-scala](https://github.com/plokhotnyuk/jsoniter-scala)

19. Typelevel. "Doobie." [https://tpolecat.github.io/doobie/](https://tpolecat.github.io/doobie/)

20. Typelevel. "Skunk." [https://typelevel.org/skunk/](https://typelevel.org/skunk/)

21. Scalameta. "Munit." [https://scalameta.org/munit/](https://scalameta.org/munit/)

22. Disney Streaming. "weaver-test." [https://disneystreaming.github.io/weaver-test/](https://disneystreaming.github.io/weaver-test/)

23. Iltotore. "Iron." [https://iltotore.github.io/iron/](https://iltotore.github.io/iron/)

24. ScalaMatsuri. "ScalaMatsuri Conference." [https://scalamatsuri.org/](https://scalamatsuri.org/)

25. Scala Center. "Scala Toolkit." [https://docs.scala-lang.org/toolkit/introduction.html](https://docs.scala-lang.org/toolkit/introduction.html)

현재 단락 (1/392)

2020 年の Scala にはまだ「強力だが複雑」という印象が強かった。ビルドは sbt 一択、implicit conversion で IDE が固まり、Akka が JVM の actor モ...

작성 글자: 0원문 글자: 17,831작성 단락: 0/392