関数型言語 2026 陣営マップ — Haskell, OCaml, Elm, Gleam, Roc, Unison, Lean 4, F#, Clojure を一冊で読むメタサーベイ

• プロローグ — もう一度関数型の地図を描く理由
• 1. 関数型という一語が隠す、五つの違う宇宙
• 2. 家 vs 特性のマトリクス
• 3. ML 系 — Jane Street が 2026 年に OCaml を支える
• 4. Haskell 系 — 拠点はより硬く、学習需要は減った年
• 5. BEAM 系 — 最も活発な陣営、内部に対立軸が一つある
• 6. Lisp 系 — Clojure のエンタープライズ、Racket の教育、CL の生きた博物館
• 7. 新興系 — Roc、Unison、Lean 4、Koka の異なるベット
• 8. 関数型だが実用的 — Effect-TS が fp-ts を吸収した意味
• 8.5. コード一枚で見る五つの家の違い
• 8.6. 採用・ツール・生態系で見た家ごとのスコアカード
• 9. 2026 年のスタートアップが関数型言語を選ぶのは合理的か
• 9.5. 家ごとの短い採用ガイド — 半年でチームを埋められるか
• 9.6. 関数型の思想は主流言語に流れていった痕跡
• 10. 一つだけ挙げるなら — 家ごとのキラー機能を一行で
• エピローグ — 次の判断のためのチェックリスト
• 参考 / References

プロローグ — もう一度関数型の地図を描く理由

このブログにはすでに Erlang/Elixir と Actor モデルの記事、Haskell のモナドを噛み砕いた記事、Effect-TS と Gleam を別々に扱った記事がある。それらは全部「一つの家の内側からの地図」だった。2026 年 5 月時点で、一度くらいは上から景色を眺める時間が必要だ。ML 系が Jane Street の手で OCaml 5 に乗り換える間、Haskell 系は Mercury と Standard Chartered が下支えし、BEAM 系では Gleam 1.16 がマイナー単位で出続け、新興系の Roc、Unison、Lean 4、Koka はそれぞれ違うベットをしている。陣営全体を見ないと、どの言語が生きているのかを取り違える。

この記事は一つの家を深く掘らない。代わりに同じ物差しで全部の家を測る。すべての陣営に同じ六つの問いを投げる。

1. 2026 年に誰が実戦で使っているか
2. 何が伸び、何が縮んでいるか
3. 一つだけ挙げるなら、その言語のキラー機能は何か
4. 採用は可能か、ライブラリは足りているか
5. どんな状況なら選ぶのが合理的か
6. どんな状況なら選ぶのが非合理か

結論を一行で。関数型言語は「ユーザーが減っている」のではなく、「家のあいだの比重が再編成されている」。2026 年は BEAM 系が最も活発で、ML 系がインフラの内側で静かに大きくなり、Haskell 系は学習者は減ったが拠点はより硬くなる。Elm は止まり、その隙間に Roc と Lamdera が入った。

価格やバージョン番号はすぐ動く。本稿の数字は 2026 年 5 月時点。構造そのものは半年経っても大きくは揺れないはずだ。

1. 関数型という一語が隠す、五つの違う宇宙

まず全体像を押さえる。「関数型言語」と聞くと一つの部族のように響くが、実際には互いにほとんど会話しない五つの家が別々に住んでいる。

ML 系は 1973 年エディンバラ発。Standard ML、OCaml、ReScript、ReasonML、F# がこの一本。特徴は strict evaluation、module system、関数型 + 軽い副作用許容の実用主義。Hindley-Milner 型推論はここで生まれた。アカデミアより産業の内側で最も静かに回っている家だ。

Haskell 系は 1990 年に Haskell 1.0 で分岐した。Haskell、PureScript、Elm、Idris、Idris2、Agda。特徴は lazy evaluation、monadic effects、純粋性への非妥協。アカデミアとの結びつきが強く、産業では fintech の拠点に集中する。

BEAM 系は 1986 年に Ericsson で Erlang として始まった。Erlang、Elixir、Gleam。特徴は actor model、let it crash、分散と fault tolerance。関数型だが家の中に「型を入れるか動的のままか」というもう一つの軸がある。通信、メッセージング、リアルタイム系で最強。

Lisp 系は 1958 年の LISP から続く最古の流れ。Common Lisp、Scheme、Racket、Clojure、ClojureScript。特徴は homoiconicity(コードがデータ)と REPL 駆動開発。関数型より大きな範疇だが、現代の Lisp はほぼ関数型を推している。

新興系は 2010 年代中盤以降に出てきた別の流れ。Roc(2022 アルファ)、Unison(2025 で 1.0)、Lean 4(証明器がシステム言語に進化)、Koka(MS Research)。特徴は algebraic effects、content-addressable code、dependent types as a tool、memory model の刷新。産業採用はほぼないが、研究と一部マニア層が積極的に使う。

五つの家が共有するのは「first-class function、immutable by default、algebraic data type、pattern matching」くらい。それ以外は設計哲学もコミュニティ文化も採用市場も違う。一つの家で通じる助言は別の家では通じない。

2. 家 vs 特性のマトリクス

比較を一目で押さえるため、六つの軸で広げる。

この表を週に一回読み直すと、どの家が生きていて、どの家が博物館入りしたか感覚がつかめる。次節からは家ごとに節を立てて広げる。

3. ML 系 — Jane Street が 2026 年に OCaml を支える

ML 系の 2026 年の核心は単純だ。Jane Street が本番サーバーを OCaml 5 ランタイムに移した。2025 年の ICFP/SPLASH で Yaron Minsky が発表し、社のブログでも整理されている。トリリオン単位の資金が回るシステムが OCaml 5 の上で動いているという意味だ。この事件は ML 系全体の信号だ。lazy evaluation なしでも、モナドの追跡なしでも、関数型が産業を支えられることを最もよく示す事例。

OCaml は 2026 年 5 月時点で 5.4.x を安定ラインとし、4.x LTS もまだ生きている。5.4 では 4.x シリーズとの機能パリティが初めて達成され、multicore ランタイムに付随する効果ハンドラ(Eio)が日常的に使われるようになった。Jane Street は独自コンパイラ分岐の OxCaml を運用している。modal types、ownership、parallelism extension が組み込まれ、本家 OCaml にも一部が流れ込んでいる。つまり「Rust の所有権を OCaml に持ち込む」実験が産業現場で同時進行している。

OCaml のキラー機能を一つだけ挙げるなら、モジュールシステムだ。他の関数型言語が関数合成で抽象化するのに対し、OCaml は functor(モジュールを受け取りモジュールを返す関数)でそれを行う。大きなコードベースを整理する道具としてこれに匹敵するものは少ない。Jane Street が OCaml から離れない最大の理由がここにある。

F# は .NET 10 と一緒に F# 10 が 2025 年 11 月にリリースされた。大きな新機能というより、コンパイル並列化(ParallelCompilation property)、IDE の応答性、小さな文法改善に集中したリリースだ。利用先は分散している。英国・北欧の金融、一部ゲーム周りのツール、.NET エンタープライズの内側のドメインモデル。C# 利用者が関数型思考を試すときに自然に出会う入口。Microsoft は派手に推さないが、殺してもいない。安定した博物館に近い。

ReScript / ReasonML は分かれた。ReasonML は事実上 ReScript に吸収され、ReScript は React 生態系の中で非常に狭く生き残った。日本の一部企業が大きなコードベースを運用し、米国の一部スタートアップが使う。ただし 2024 年以降の TypeScript の進化(特に satisfies、const generics、Effect-TS)が ReScript の口実を削った。新規プロジェクトで ReScript を選ぶには強い理由が要る。

ML 系が合理的になるのはいつか。第一に、大きな関数型コードベースを整理するとき(OCaml の functor)。第二に、.NET の内側でドメインモデルを強く固めたいとき(F#)。第三に、JIT/GC なしで速い単一バイナリが必要なとき(OCaml のネイティブコンパイラ)。非合理なのは、「フロントエンドに ML 系を使う」という決定を採用やライブラリの検討なしに下すとき。ReScript は今や非常に狭い選択だ。

4. Haskell 系 — 拠点はより硬く、学習需要は減った年

Haskell 系の 2026 年の絵は二本立てだ。拠点はより硬くなり、入門者は減った。

拠点側で最も目立つ会社は Mercury だ。Mercury は 30 万社以上にサービスを提供する米国のビジネスバンキング系スタートアップで、2025 年の取引規模は 2,480 億ドル、売上は年換算 6.5 億ドル規模。コードベースは Haskell でおよそ 200 万行。Mercury のブログ(blog.haskell.org)に掲載された「A Couple Million Lines of Haskell」がこの規模を公式に確認した。彼らの中心的な主張は単純だ。「エンジニアの大半は入社前に Haskell を一行も書いたことがない」。つまり Haskell はもはや「天才博士の言語」ではなく、「一般の開発者が学んで使う道具」であることが産業事例で裏付けられた。

Standard Chartered も依然として中核の quant ライブラリ Cortex を Mu/Haskell で保守している。およそ 650 万行のコードが、資産クラス全般の価格・リスクエンジンを動かす。サーバー側のバッチからデスクトップ GUI まで同じ言語が通る。Anduril、Juspay などの会社も Haskell をコアの一部で使う。Well-Typed(Haskell コンサル)の 2026 年 1Q レポートがこの関係性を再確認した。

GHC は 2026 年も四半期リリースを維持する。GHC 9.x が安定ライン、10.x が RC 段階。Cabal と stack は共存する。コンパイラ内部のモジュール性、typed Template Haskell、そして linear types の産業利用拡大が動きの中心。Effects ライブラリは effectful、polysemy、fused-effects の三つに事実上整理され、新規コードの多数派は effectful だ。

Haskell のキラー機能を一つ挙げるなら、型で副作用を追跡する能力だ。関数の型に IO という型(本記事ではコードフェンス内でのみ使う)が現れた瞬間、その関数が外界に触れることがコンパイラに明示される。逆にその型がなければ純粋。この単純な規則が、大きなコードベースのリファクタリングをほぼ怖さなしに可能にする。

Elm は同じ家の中で最も複雑な位置にある。0.19.1 が 2019 年以降事実上止まっている。Evan Czaplicki は別の作業に集中し、公式リポジトリの PR は非常にゆっくり動く。この空白を二つの動きが埋めている。第一は Lamdera。Elm をフルスタックに拡張した商用分岐で、サーバーとクライアントの同期、マイグレーションを一つのモデルで扱う。第二は elm-pages や gren-lang のようなコミュニティ努力。とはいえ Elm 自体を新規プロジェクトのデフォルトに勧めるのは難しくなった。保守中のコードベースには依然として優秀だが、新規には後述する Roc が自然な後継となる。

PureScript は生きている。コンパイラは活発に改善され、Halogen も動く。だがコミュニティの内側でも「新規には React を勧めよう」という流れが固まった。PureScript は「JS の上で Haskell を書きたい」という非常に狭い要望にのみ合理的。

Idris2 は dependent types を産業に持ち込む最も真剣な試みだ。Edwin Brady の Type-Driven Development with Idris が依然として標準入門書。2026 年 5 月時点で産業採用は事実上ゼロ、研究室と一部マニアのプロジェクトが回る。とはいえ「型を仕様として使う」思想は他の言語(Haskell の linear types、Rust の const generics、TypeScript の template literal types)に流れ込んでいる。

Haskell 系が合理的になるのはいつか。第一に、fintech の複雑なビジネスルールを型で強制したいとき。第二に、コンパイラ、静的解析器、ドメイン DSL を作るとき。第三に、大きなコードベースを小さなチームで安定して維持したいとき(Mercury の中核主張)。非合理なのは「フロント + Elm + 新規プロジェクト」の組み合わせと、「型博士一人に依存した導入」だ。

5. BEAM 系 — 最も活発な陣営、内部に対立軸が一つある

BEAM 系は 2026 年に関数型の中で最も活発だ。理由は単純で、分散と fault tolerance への需要が減っていないこと、そして BEAM ほどその問題を綺麗に解くランタイムが他にないからだ。ただし内側に対立軸がある。「型を入れるか、動的のまま行くか」。

Erlang は依然として生きている。WhatsApp バックエンドの中核は 2016 年買収以降も Erlang のままだ。RabbitMQ、ejabberd、CouchDB は Erlang で動き、これらは 2026 年も活発に維持される。OTP 27、28 が安定ライン。新しく Erlang を選ぶチームはほぼないが、既存の Erlang システムから人が流出することもない。「安定保全領域」だ。

Elixir がこの家の動力源。2024 年に José Valim が set-theoretic types の作業を本格化させ、2025 年の 1.18、2026 年初頭の 1.19 シリーズで段階的に型推論が入りつつある。つまり動的 BEAM 言語として出発した Elixir が漸進的型付けで広がっている。Phoenix LiveView は 2026 年も 1.x 安定ラインを維持し、Phoenix 1.8 と組み合わせて Server-Driven UI の標準例になった。Fly.io がインフラの一部を LiveView で運用し、Discord はメッセージルーティングに Elixir を使う。Pinterest、Bleacher Report、PepsiCo のような大手も一部サービスで Elixir を維持する。

Elixir のキラー機能を一つ挙げるなら、OTP の上の fault tolerance だ。Supervisor ツリー、link、monitor、restart strategy。この四つが組み合わさると、「一部が死んでもシステム全体は生きる」という保証がコードレベルで作られる。分散システムを最初から信頼性の高い形で組まないといけないチームに、これに匹敵する道具は少ない。

Gleam が BEAM 系の新星だ。2024 年の 1.0 以降マイナー単位で素早く進化し、2026 年 4 月に 1.16.0 が出た。GitHub スターは 21,000 を超えた。Gleam の差別化点は正確に二つ。第一に、型安全な BEAM 言語という枠。Erlang/Elixir が動的で Dialyzer による補強だったところを、Gleam は最初から静的型を入れる。第二に、単純さ。文法は小さく、マクロはなく、マニュアルは一冊で読める。Elm の「単純さ第一」の哲学を BEAM 系が持ち帰った形。

2026 年に新規 BEAM サービスを始めるチームが Gleam を真剣に検討する。ただし採用プールはまだ小さく、ライブラリは Elixir に比べ薄い。Erlang/Elixir との FFI が綺麗なので、「Gleam でドメインモデル、Elixir でインフラ」という混成パターンがよく見られる。

BEAM 系が合理的になるのはいつか。第一に、メッセージング、リアルタイム、マルチプレイヤーのバックエンド。第二に、分散システムで fault tolerance をコードレベルで保証したいとき。第三に、LiveView でフルスタックの単純化を狙うとき。非合理なのは CPU バウンドの計算(Rust や Go の方がよい)、または単一ノードの CRUD(普通の Rails/Django の方が早く立ち上がる)。

6. Lisp 系 — Clojure のエンタープライズ、Racket の教育、CL の生きた博物館

Lisp 系は関数型の原点だが、2026 年は一つの拠点の重みで見るのがよい。

Clojure が事実上 Lisp 系の産業代表。2026 年 5 月に 1.12.5 がリリースされ、同年 3 月に Clojure Documentary が公開された。Rich Hickey、Alex Miller、Stuart Halloway が出演する 1 時間 30 分の映像。このドキュメンタリーの登場自体が信号だ。「Clojure は一つの章を整理し次の章へ移る言語」になったということ。Nubank が 2020 年に Cognitect を買収して以来 Clojure 開発を支援しており、自社の中核システムも Clojure と Datomic で回している。

Clojure のキラー機能を一つ挙げるなら、persistent data structure だ。immutable な vector/map/set が O(log32 n) 時間で更新を行い、その上に STM と atom が乗る。この組み合わせが「並行性 + データ中心思考」という Lisp の現代化を可能にした。エンタープライズのデータパイプライン、fintech のコア、EDM(Event-Driven Microservice)で依然強い。

ClojureScript は生きているが、新規プロジェクトの多数派ではない。shadow-cljs のツールは安定し、re-frame が標準の状態管理だが、TypeScript の進化速度が ClojureScript の口実を削った。

Racket は教育と DSL 研究の拠点。How to Design Programs が標準入門書で、マクロシステムは最も強力。産業採用はほぼゼロ。

Common Lisp は生きた博物館。SBCL は依然速く、ASDF/Quicklisp は動き、一部の企業(特にグラフィック、園芸自動化、宇宙系の一部レガシー)が依然として中核システムを運用する。ただし新規プロジェクトで CL を選ぶ合理的な理由は非常に少ない。

Lisp 系が合理的になるのはいつか。第一に、データパイプライン + JVM 生態系の活用 + 関数型思考が同時に必要なとき(Clojure)。第二に、DSL を強く使うとき。非合理なのは「動的型 + 小さなチーム + 静的解析への強い要求」。この場合は Gleam や OCaml の方がよい。

7. 新興系 — Roc、Unison、Lean 4、Koka の異なるベット

新興系は産業採用はほとんどないが、最も面白い実験が起きている場所だ。四つの言語が四つの違うベットをしている。

Roc は Elm の後継。作者は Richard Feldman で、彼は以前 Elm in Action を書いた。2026 年 5 月時点で Roc はまだ pre-1.0。最後のタグリリースは alpha4(2024 年 8 月)で、2026 年中に 0.1.0 を出すのが目標だと Feldman が The Changelog 645 回で語った。新コンパイラが Advent of Code 2025 で使える水準になるのが直近の目標で、すでに一部の人が実験的に使っている。

Roc の差別化点は二つ。第一に、platform と application の分離。Roc プログラムは「platform」(例: web server、CLI、AWS Lambda)が提供する effects のみを使える。つまりどの副作用が可能かは platform 側で決まる。第二に、速いコンパイル + 速いランタイム。Roc は morphic solver(static dispatch + monomorphization の高度化)を使い、関数型の速いビルドと速い実行を同時に狙う。NoRedInk がこの作業を後援してきた。

Roc はまだ production には使えない。とはいえ Elm を好きだった人が「フロント + サーバー + CLI を一つの言語で」という夢を持つなら、最も近い候補だ。

Unison は 2025 年 11 月に 1.0 が発表された。差別化点は content-addressable code。関数の識別子は名前ではなく AST のハッシュだ。同じ関数は同じハッシュを持ち、一度コンパイルした結果はコードベース全体でキャッシュされる。つまり「ビルド時間がほぼゼロに近い強型付け言語」という位置。さらに distributed runtime(Unison Cloud)を最初から想定して設計され、関数を「別マシンに送って実行」がコード一行で可能だ。

Unison の ability system は、algebraic effects を産業化した最も綺麗な試みの一つだ。関数の型にどの ability を要求するかが明示され、ハンドラが ability を解釈する。Haskell の effects ライブラリ群が追っていたものを、言語レベルで一段階単純にした。

Unison 1.0 は出たが、産業採用は依然小さい。最大の利用先は Unison Cloud のベータユーザーで、一部のデータパイプラインやサーバーレスワークロードに実験的に使われる。採用可能性はほぼゼロ。

Lean 4 は陣営の中で最も変化が速い言語だ。Microsoft Research で始まったが、2024 年から Leonardo de Moura が Amazon に移り、Lean FRO(Functional Reservation Organization)が別の非営利として運営される。Lean 4 のアイデンティティは二つを同時に持つ。第一に、theorem prover。数学者が sphere packing のような定理の形式化に使っている。第二に、systems language。Lean 4 自身が Lean 4 で書かれており、in-place 関数型というパラダイム(immutable に見えるが reference count で in-place 更新する)を持つ。

2026 年 3 月に Mistral が Leanstral という Lean 4 専用 AI エージェントをオープンソース公開した。AI がコード正確性を形式証明で検証するというシナリオの最初の実用ツールだ。Lean 4 の産業利用は依然ほぼゼロだが、「AI 時代にコード検証を形式化する」という大きな流れの拠点になりつつある。

Koka は Microsoft Research の Daan Leijen が主導する関数型言語。2024 年 1 月に 3.0 が出て、その後マイナー単位で毎月リリースが続く。差別化点は row-polymorphic effect types。関数の型に可能な副作用が row(集合)として明示される。効果ハンドラで async、exception、確率的プログラミングをライブラリレベルで定義する。さらに FBIP(functional but in-place)と reference counting ベースのメモリ管理も差別化点。

Koka の産業利用はほぼゼロ。しかし algebraic effects が他言語に流れ込む通路の役割を果たしている。OCaml 5 の effect handler は Koka の影響を受け、Unison の ability system も思想的な親戚だ。

新興系が合理的になるのはいつか。正直に言って、2026 年の production には非合理。学習用、サイドプロジェクト、R&D 実験、そして次の産業標準の思想を先に吸収するため、くらいが合理的な範囲。半年以内に成果を出さねばならないチームが新興系を選ぶと失敗確率が高い。

8. 関数型だが実用的 — Effect-TS が fp-ts を吸収した意味

2025 年末の大事件の一つは Giulio Canti の fp-ts が Effect-TS 組織に合流したことだ。Effect-TS は事実上 fp-ts v3 のスロットに収まり、fp-ts の今後の開発は Effect の内側で続く。Effect-TS は自らを「TypeScript の Haskell」と呼ぶが、実際には ZIO(Scala)や Cats Effect、IO monad ライブラリの TypeScript 版だ。

Effect-TS は一つの大きな意味を持つ。関数型の家に入らずに 主流言語に関数型の道具をライブラリとして注入する。TypeScript は main stream で、React は標準、Node/Bun がインフラ。その上に Effect、Schema、Layer、Context、Fiber を載せれば、「関数型の家の思想を借りつつ採用を諦めない」ことができる。

似た流れは他の言語にもある。Rust の thiserror + anyhow + tokio は事実上 Result/Either + structured concurrency の産業版。Swift は async/await + Result + actor が全て関数型のアイデア。Kotlin は Arrow が fp-ts と同じ位置に立つ。Java は vavr と jOOλ があり、JEP 466 の stream gatherer も関数型パターンを取り込む。Scala は最初から Cats Effect と ZIO が拠点。

この流れの結論は明確だ。関数型の家を選ばなくても関数型の 90% は持ち込める。一つのチームの立場では、Haskell を導入して採用を狭めるより、TypeScript + Effect を使う方が合理的なケースが増えた。ただし Effect-TS の学習コストは急だ。fp-ts も難しかったが、Effect はもっと大きな表面積を持つ。すべてのチームに勧められはしない。

関数型だが実用的な道が合理的になるのはいつか。第一に、採用を狭めたくないが関数型の思想は強く使いたいとき。第二に、既存の TypeScript/Rust/Swift コードベースに関数型パターンを段階的に導入するとき。第三に、「半分は命令型、半分は関数型」という現実的な妥協を受け入れるとき。非合理なのは「Haskell のすべてを TypeScript で再現しようとする」試み。その道はしばしば大きな学習負担だけ残して終わる。

8.5. コード一枚で見る五つの家の違い

言葉だけだと抽象化しすぎる。「同じ仕事を五つの家がどう違って書くか」をコード一枚で比較する。題材は固定。ユーザー ID を受け取り、残高を引き、無ければ型付きエラーを返す。最も単純なビジネスロジックだが、各家の哲学が最もはっきり出る。

OCaml。明示的なモジュール、Result 型、パターンマッチ。

module Balance = struct
  type error = NotFound | Frozen
  type t = { user_id : string; amount : int }

  let find_balance db id : (t, error) result =
    match Db.get db id with
    | None -> Error NotFound
    | Some r when r.frozen -> Error Frozen
    | Some r -> Ok { user_id = id; amount = r.amount }
end

Haskell。monad transformer か effects ライブラリ(ここでは effectful)。

findBalance :: (Reader Db :> es, Error AppError :> es) => UserId -> Eff es Balance
findBalance uid = do
  db <- ask
  row <- liftIO (Db.get db uid)
  case row of
    Nothing -> throwError NotFound
    Just r | rowFrozen r -> throwError Frozen
    Just r -> pure (Balance uid (rowAmount r))

Elixir。with 構文、パターンマッチ、メッセージパッシングは GenServer の内側で。

def find_balance(db, uid) do
  with {:ok, row} <- Db.get(db, uid),
       false <- row.frozen do
    {:ok, %Balance{user_id: uid, amount: row.amount}}
  else
    :error -> {:error, :not_found}
    true -> {:error, :frozen}
  end
end

Gleam。網羅的マッチをコンパイラが強制、Result が標準。

pub fn find_balance(db: Db, uid: String) -> Result(Balance, Error) {
  case db.get(db, uid) {
    Error(_) -> Error(NotFound)
    Ok(row) if row.frozen -> Error(Frozen)
    Ok(row) -> Ok(Balance(user_id: uid, amount: row.amount))
  }
}

Clojure。動的 + spec 検証、multimethod や cond で分岐。

(defn find-balance [db uid]
  (let [row (db/get db uid)]
    (cond
      (nil? row) [:error :not-found]
      (:frozen? row) [:error :frozen]
      :else [:ok {:user-id uid :amount (:amount row)}])))

五つの家が同じ仕事を五つの書き方で書く。どれが優れているとは断じがたいが、各家が何を強調しているかは明確だ。OCaml はモジュールで境界を引き、Haskell はすべての副作用を型に刻み、Elixir は with で happy path を平らに伸ばし、Gleam はコンパイラがすべての分岐を強制し、Clojure は動的 + データ中心だ。

8.6. 採用・ツール・生態系で見た家ごとのスコアカード

産業的な意思決定で重要なのは思想ではなく採用・ツール・生態系だ。同じ物差しで見ると家ごとの差が正確に見える。下は 2026 年 5 月時点の主観的なスコアカード(5 点満点)。

この表は絶対の神託ではなく「一枚の写真」と思おう。採用プールは LinkedIn 英語圏検索の相対量、ツールは LSP/デバッガ/フォーマッタの成熟度、ライブラリは標準的作業(HTTP、DB、JSON、認証)の充実度、学習資料は本と公式ドキュメントの深さ、カンファ・コミュは 2025-2026 の活動頻度を基準にしている。

総合点が高いから優位、というわけではない。小さくても噛み合う採用プールなら合理的になる。Gleam のプールは小さいが集まる人の質感が揃っており、Haskell のプールも小さいが Mercury が示したように一般開発者にも学習可能だ。

9. 2026 年のスタートアップが関数型言語を選ぶのは合理的か

正直に答えよう。答えは「家ごとに、合理的な場合と非合理な場合がある」。家単位に分けないと意味がない。

合理的ケース 1 — Elixir + Phoenix LiveView でフルスタックを単純化。1〜3 人のチームが素早く MVP を作り、リアルタイム機能が核で、分散信頼性も最初から確保したい。このときの LiveView はほぼ unfair advantage。採用プールは小さいが Ruby on Rails 出身者と互換だ。Fly.io、Felt、Cars Commerce、Brex が実際にこのパターンを運用している。

合理的ケース 2 — Haskell で fintech コア。ビジネスルールが複雑で、型で不変条件を強制したく、小さなチームで大きなコードベースを保守する。Mercury がこのパターンの標準例。採用は難しいが、「Haskell を初めて使う一般の開発者」を採っても回るという Mercury の主張が裏付けられている。

合理的ケース 3 — OCaml でコンパイラやインフラツール。Tezos の一部、Coq の一部、Docker for Mac の一部が OCaml で書かれている。速い単一バイナリ + 強い型 + functor のモジュール化。インフラツールに合う。

合理的ケース 4 — Gleam で新規 BEAM サービス。Elixir の思想は好きだが静的型が必要なチーム。2026 年に新しい BEAM プロジェクトを始めるなら Gleam は十分真剣な候補だ。ただし採用は非常に狭い。

非合理ケース 1 — Elm で新規フロントエンド。2019 年以降 0.19 が止まり、採用はほぼゼロ、ライブラリは増えない。保守中のコードベースはよく回るが、新規には勧めない。Roc が 1.0 に達するまでは React + Effect-TS の方がはるかに合理的。

非合理ケース 2 — Roc、Unison、Lean 4、Koka で production。どれも魅力的だが 2026 年に production に使うのはリスクが大きい。半年以内に成果を出さねばならないチームが新興系を選ぶと失敗確率が高い。

非合理ケース 3 — PureScript / Idris2 でフルスタック。PureScript には React が立ちはだかり、Idris2 は採用がゼロ。学習目的でないなら勧めない。

非合理ケース 4 — Common Lisp で新規 SaaS。一人の天才エンジニアの会社でない限り、一般チームには勧められない。

この結論を一文に圧縮すると。「家単位で見れば関数型は依然合理的な選択だ。ただしすべての陣営に同じ答えはない」。

9.5. 家ごとの短い採用ガイド — 半年でチームを埋められるか

スタートアップの最初の半年で最大のリスクは人だ。だから家の選択は採用可能性と直結する。家ごとの率直なガイド。

• Elixir — Ruby 出身 + ElixirSchool/Pragmatic コース修了者のプールが厚い。半年で 3-5 人のフルスタックチームは現実的。ただしシニアは少なめ。
• Haskell — Mercury が示したパターンが正解。「Haskell 経験者だけ」ではなく「Haskell を学ぼうとする一般開発者 + 1-2 名のシニア」。シニア採用は半年から 9 か月見ておくと安全。
• OCaml — シニア採用は本当に難しい。Jane Street/Tezos/Coq 周辺以外は市場が薄い。学習意欲ある OCaml 未経験者をシニアに育てる方が現実的。
• F# — C# 開発者からの社内移動が最も簡単な経路。外部採用は狭いが、社内 C# 開発者を F# に動かすコストは小さい。
• Clojure — Nubank の重力でラテンアメリカ(特にブラジル)のコミュニティが大きくなった。米国市場は狭いが安定している。
• Gleam — 採用プールは事実上「BEAM 家出身 + Gleam 学習者」。つまり Elixir 経験者を採用し、社内オンボーディングで Gleam を入れるのが現実的。
• Erlang — 採用は非常に狭いが、中核通信会社からシニアを引き抜くのは可能。ただしその経歴は高い。
• ReScript — 日本・米国一部企業出身者を除けば採用はほぼ無い。社内学習が事実上唯一の道。
• Roc/Unison/Lean 4/Koka — 採用ゼロ。学習可能な一般開発者をシニアに育てる以外に道がない。1 年以上の学習コストを覚悟する必要がある。

このガイドの核は単純だ。「経験者だけ採る」戦略は関数型のほぼすべての家で失敗する。Mercury が明示的に述べた事実であり、他の関数型産業会社も実質的に同じパターンだ。学習意欲ある一般開発者 + 少数のシニア + 充実した社内教育資料。この組み合わせが半年で人を埋める唯一の現実的な道。

9.6. 関数型の思想は主流言語に流れていった痕跡

最後に大きな視点をひとつ。2026 年の真実の一つは 「関数型言語を選ばなくても、関数型はほぼ勝利した」 だ。主流言語のほとんどが関数型の思想を吸収した。

• Rust の Result、Option、ownership、パターンマッチ、match 式、? 演算子、lifetime 追跡 — すべて ML/Haskell 家から来た。
• Swift の Optional、Result、async/await、actor、Sendable、if let — Apple が ML 家の思想を吸収した結果。
• Kotlin の Result、sealed class、when 式、scope function、Flow — Scala/Haskell の影響が強い。
• TypeScript の union types、narrowing、discriminated unions、satisfies、as const、template literal types — Haskell 家の思想が段階的に導入された結果。
• Java の Optional、sealed class、switch expression、pattern matching、record — 関数型 + オブジェクト指向の融合。最も保守的な言語ですら吸収した。
• C# の record、pattern matching、Nullable<T>、async/await — F# の影響が直接流れる。
• Python の typing.Protocol、match 構文、data classes — ゆっくりだが吸収中。

この流れの意味は何か。第一に、関数型言語を使わなくても関数型の 90% を持ち込める。Effect-TS が TypeScript で行ったのはある種の「最後の 10% まで持ってこよう」という試みだ。第二に、関数型家の本当の価値は思想そのものではなく「思想を強制する環境」にある。Haskell の真価はモナドではなく「関数シグネチャを嘘つけなくするコンパイラ」、Elixir の真価は actor モデルではなく「OTP が fault tolerance をコードレベルで強制する環境」だ。

この視点で整理すると家の選択が明確になる。思想だけ必要なら主流言語 + Effect/Arrow/Cats、強制が必要なら関数型家。

10. 一つだけ挙げるなら — 家ごとのキラー機能を一行で

最後に家ごとのキラー機能を一行で整理する。採用、ライブラリ、ツールは時間とともに変わるが、「この家が他の家に贈れる最大のもの」はあまり変わらない。

• OCaml — モジュールシステムと functor。大きなコードベースを抽象化する最良の道具。
• F# — .NET 生態系の上で関数型ドメインモデリング。C# 利用者の関数型入口。
• Haskell — IO 型で副作用を追跡。大きなリファクタリングを怖くなくする。
• Elm — 「単純さこそ信頼性」という命題の最も純粋な例。思想は生き続けている。
• PureScript — Haskell 思想を JS に持ち込んだ真剣な試み。狭いが深い。
• Idris2 — 型は仕様である。産業化はされなかったが思想は他言語に流れた。
• Erlang / OTP — Supervisor ツリー。分散 fault tolerance の標準。
• Elixir — LiveView + OTP。1〜3 人チームのフルスタック unfair advantage。
• Gleam — 小さな文法 + BEAM。「単純さ第一」が BEAM の上で再び生きた。
• Clojure — persistent data structure + REPL。データ中心思考の標準。
• Racket — マクロ + DSL。教育と研究の拠点。
• Common Lisp — ランタイム変更。生きた博物館だが教えてくれることが多い。
• Roc — platform/application の分離。どの副作用が可能かを platform が決める。
• Unison — content-addressable code。名前ではなくハッシュで識別される関数。
• Lean 4 — dependent types + AI。コード証明の産業化拠点。
• Koka — row-polymorphic effects。副作用を型の中に row として集める。
• Effect-TS — 関数型の家を選ばずに関数型の道具を持つ道。

エピローグ — 次の判断のためのチェックリスト

関数型言語を陣営単位で見るメタサーベイを締めくくるにあたり、次の判断に使えるチェックリストとアンチパターンを整理する。

選定時チェックリスト

• ドメインが分散・リアルタイム・メッセージング → BEAM 系を優先検討
• ドメインが複雑なビジネスルール(fintech、保険、会計) → Haskell、OCaml、F# 候補
• ドメインがコンパイラ・静的解析器・インフラツール → OCaml、Haskell 候補
• ドメインがデータパイプライン + JVM 生態系 → Clojure 候補
• ドメインがフルスタック + 1〜3 人チーム → Elixir + Phoenix LiveView 優先
• ドメインが新規 BEAM サービス → Gleam vs Elixir 比較
• ドメインが学習・R&D → Roc、Unison、Lean 4、Koka を試せる
• ドメインが普通の CRUD なら → 関数型の家を選ばなくてよい。TypeScript + Effect か普通の主流

アンチパターン

• 「Haskell が格好いいから」導入 → 採用が狭まる + 学習コスト + ライブラリ不足の三重苦
• 「Elm で新規フロントエンド」 → 2026 年には非合理。Roc 1.0 を待つか React へ
• 「Lisp で SaaS を一から」 → 1 人天才の会社でない限りリスク
• 「関数型博士一人に依存した導入」 → その人が抜けるとチームが崩れる
• 「関数型という理由で採用プールを無視」 → 半年で人が足りずに失敗
• 「思想学習なしに Effect-TS を全面導入」 → 学習コストは fp-ts より急
• 「Roc、Unison、Lean 4 を production に導入」 → 1.0 が出ても生態系は薄い

次回予告

次回はこの記事で短く触れた「関数型だが実用的」の実戦を深く扱う。テーマは Effect-TS 実戦ガイド 2026 — Schema、Layer、Context、Fiber を一つのプロジェクトに導入する段階別手順。fp-ts から Effect への実際の移行手順、Schema でランタイム検証を行う方法、Layer で DI を綺麗に組む方法、そして「TypeScript + Effect」が実際の産業でどこまで通用するかへの honest take を扱う予定。

参考 / References

• Gleam programming language — official site
• Gleam Gathering 2026 reflections — Alembic
• Roc programming language — official site
• Richard Feldman on Roc — The Changelog Interviews 645
• Unison — official site
• Unison: A friendly programming language from the future — GitHub
• Jane Street and Docker on moving to OCaml 5 at ICFP/SPLASH 2025 — Anil Madhavapeddy
• Introducing OxCaml — Jane Street Blog
• Oxidizing OCaml: Rust-Style Ownership — Jane Street Blog
• Technology at Jane Street
• A Couple Million Lines of Haskell: Production Engineering at Mercury — blog.haskell.org
• Haskell in Production: Mercury — Serokell
• Haskell in Production: Standard Chartered — Serokell
• Haskell ecosystem activities report: Q1 2026 — Well-Typed
• Elm Software Foundation — Elmcraft
• Elm language — Wikipedia
• Lamdera — Full-stack Elm
• PureScript Halogen — GitHub
• Idris 2 — official site
• The Koka Programming Language
• Daan Leijen at Microsoft Research
• Koka project — Microsoft Research
• Lean 4 — official site
• The Lean 4 Theorem Prover and Programming Language — Microsoft Research
• Clojure documentary trailer — clojure.org
• Clojure 1.12.5 release notes
• Introducing F# 10 — .NET Blog
• What's new in F# 10 — Microsoft Learn
• F# 10 Brings Performance Improvements — InfoQ
• Effect-TS vs fp-ts — Effect Documentation
• fp-ts joins Effect-TS — GitHub
• Why We Love Functional Programming but Don't Use Effect-TS — Harbor
• Elixir set-theoretic types — José Valim blog
• Phoenix Framework — official site
• WhatsApp Engineering on Erlang — Code BEAM talks