- Published on
モダンOCaml 2026 — OCaml 5.3 / Multicore / Effect Handlers / Dune / Opam / MirageOS / ReScript / Melange / Jane Street 徹底ガイド
- Authors
- Name
- Youngju Kim
- @fjvbn20031
- 1. 2026年のモダンOCaml — Multicoreの時代
- 2. OCaml 5.x — Multicore + Effect Handlers (GA 2022.12)
- 3. OCaml 5.3 (2025.1) — 安定化
- 4. Dune — ビルドシステムの標準
- 5. Opam — パッケージマネージャ
- 6. MirageOS — ユニカーネル
- 7. js_of_ocaml — JSコンパイル
- 8. ReScript (旧 BuckleScript, Hongbo Zhang) — JS 親和
- 9. Melange — ReScriptコンパイラをOCamlに戻す
- 10. Reason — Facebookの構文
- 11. Eio — Effectベースの並行性 (Multicore)
- 12. Lwt — 古い並行性
- 13. Cohttp / Dream — HTTP / Web
- 14. Tezos (XTZ) — ブロックチェーンのOCaml
- 15. Hack (Meta) / Flow (Meta) / Async (Jane Street) — 産業
- 16. Jane Street — 最大のOCaml会社
- 17. 韓国 / 日本 — KAIST PL lab、京都大学 PL lab
- 18. 誰がOCamlを学ぶべきか — FP / 形式検証 / コンパイラ
- 19. 参考 / References
「OCamlは産業言語としては常に来期の話だった。その来期が25年続いている」 — あるPL研究者
本稿は 2026年5月時点のOCamlエコシステム全体地図である。2022年12月にOCaml 5.0がMulticoreとEffect Handlersをもたらしたことで、「シングルコアの関数型言語」という長年の弱点が解消され、2025年1月の5.3までの安定化を経て、産業でも真剣に扱われるようになった。Jane Streetは25年間OCamlでトレーディングを回し、MetaはHackとFlowをOCamlで書き、TezosはXTZブロックチェーンの合意層をOCamlで実装して運用している。フロントエンド側ではReScriptがBuckleScriptの後継として定着し、MelangeはそのコンパイラをOCaml本流へと引き戻した。
本稿は OCaml 5.x のランタイム変化(Multicore, Effect Handlers)、Dune / Opam のツール標準、MirageOS ユニカーネル、JSコンパイル分岐(js_of_ocaml / ReScript / Melange / Reason)、並行性ライブラリ(Eio / Lwt / Async)、Webフレームワーク(Cohttp / Dream)、産業事例(Tezos / Meta / Jane Street)、アカデミア(KAIST / 京都大学 / Tokyo Tech)、そして「誰がOCamlを学ぶべきか」という意思決定ガイドまで、13章にまとめる。
1. 2026年のモダンOCaml — Multicoreの時代
OCamlは1996年にINRIAで誕生したML系関数型言語である。30年近く産業言語としては「来期」の存在だったが、2022年12月のOCaml 5.0 GAが決定的変化をもたらした。Multicoreランタイム と Effect Handlers である。それ以前は単一スレッドGCを採用する実質的なシングルコア言語だった。5.0以降は ドメイン(domain) 単位の並列実行と、effect によるユーザー定義の制御フローが可能になった。
2026年時点のOCamlエコシステムを整理するとこうなる:
- コンパイラ: OCaml 5.3 (2025-01) — 5.x multicoreラインの安定化版
- ビルド: Dune (Jane Street + コミュニティ) — 事実上の標準
- パッケージ: Opam (OCaml Package Manager) — 事実上の標準
- ユニカーネル: MirageOS — Anil Madhavapeddy + Cambridge / Tarides
- JSコンパイル: js_of_ocaml (伝統), ReScript (Hongbo Zhang, 分離), Melange (ReScriptのコンパイラをOCamlに戻す), Reason (Facebookの構文)
- 並行性: Eio (effect ベース, multicore), Lwt (伝統的イベントループ), Async (Jane Street)
- Web: Cohttp (HTTP基礎), Dream (Rails ライクなフルスタック), Opium, Httpaf
- 産業: Jane Street (世界最大のOCaml採用), Tezos (XTZブロックチェーン), Meta (Hack / Flow), Docker (初期は OCaml), Tarides (MirageOS / Tezos コンサルティング)
- アカデミア: KAIST PL lab (韓国), 京都大学 PL lab / Tokyo Tech (日本), Cambridge OCaml Labs, INRIA
興味深い事実が一つ。2024-2025年の間にCoqがRocqへとリブランドされ(Coq → Rocq、別記事で扱う)、形式検証ツール周辺のOCamlベース生態系の位置づけが再整理された。Rocqのバックエンドも依然OCamlで書かれている。Lean 4が台頭しても、OCamlは「PL研究者が実際に使う言語」の座を譲っていない。
もう一つ。2026年OCamlは AI学習インフラ の小さなニッチでも再評価され始めている。Taridesが発表したEio + multicoreベンチマークが、Tokio / async-std と比べても単一ノード throughput で十分競争力を示し、MirageOSベースのユニカーネルがsandboxed code execution環境の候補として再び話題に上がっている。「OCamlは死んだ」というジョークはもうジョークではなく、単に誤りになった。
2. OCaml 5.x — Multicore + Effect Handlers (GA 2022.12)
OCaml 5.0は2022年12月にGAした。Multicore OCamlプロジェクトは2014年からCambridgeのAnil Madhavapeddy、KC Sivaramakrishnan、Stephen Dolanを中心に進められた。約8年間OCaml本流とは別ブランチで開発され、4.14の安定化作業を経て5.0として統合された。
5.x がもたらした2つのコア:
1) Domainによる並列化。OCamlはOSスレッドの上にドメイン(domain)を作り、各ドメインが独自のminor heapを持つ。Major heapは共有だがGCはドメイン単位で同期する。結果は「本物のマルチコア実行」。Domain.spawn で新ドメインを起動し、Atomic モジュールでロックフリーの原子操作を行う。
(* domain_demo.ml *)
let count = Atomic.make 0
let worker () =
for _ = 1 to 1_000_000 do
Atomic.incr count
done
let () =
let d1 = Domain.spawn worker in
let d2 = Domain.spawn worker in
Domain.join d1;
Domain.join d2;
Printf.printf "final = %d\n" (Atomic.get count)
2) Effect Handlers。EffectはOCaml 5最大の言語レベル追加である。関数がeffectを発生(perform)させると、呼び出し側がそれをハンドル(handle)するか、上位へ伝播する。結果として、user-spaceコルーチン、generator、async/await、例外、依存性注入を、同じメカニズム1つで表現できる。他言語が機能ごとに分けて持つものを、OCamlはeffect 1つに統一する。
open Effect
open Effect.Deep
type _ Effect.t += Yield : int -> unit Effect.t
let producer () =
for i = 1 to 5 do
perform (Yield i)
done
let () =
try_with producer ()
{ effc = fun (type a) (eff : a Effect.t) ->
match eff with
| Yield n -> Some (fun (k : (a, _) continuation) ->
Printf.printf "got %d\n" n;
continue k ())
| _ -> None }
Effectの真価は Eio(次章)で発揮される。async/awaitを専用キーワード無しでライブラリ層で実装できるのが、effectの一番大きな帰結だ。
5.xの弱点:
- C FFI互換性: 5.0リリース直後はmulticoreランタイム下で動かないCバインディングがあった。2024年の5.2までにほぼ整理
- 性能リグレッション: 一部のマイクロベンチで4.14比+5%程度のシングルスレッド劣化が見られた。5.2でほぼ回復
- Effectの学習曲線: 静的型システムにeffect rowは無い(Kokaと違って)。コンパイル時に未ハンドルeffectを検出できず、ランタイム例外
Unhandledになる
それでも 5.x はOCaml史上最大の飛躍だ。2026年現在、新規プロジェクトはほぼすべて 5.x に乗っている。
3. OCaml 5.3 (2025.1) — 安定化
OCaml 5.1は2023年9月、5.2は2024年5月、5.3は2025年1月にリリースされた。5.x ラインはほぼ四半期に1回メジャー更新が回るペースに落ち着いた。
5.3 の主な変更:
- Effect handlerの静的検査改善: 5.3で
effectキーワードが正式な構文になり(以前はライブラリ層type _ Effect.t += ...だった)、一部のeffectをコンパイラがinline化してオーバーヘッド削減 - GCチューニング: マルチドメインでminor GCがより安定。ドメイン間promotionコストが5.2比で約30%削減
- Statmemprof標準化: メモリプロファイラが標準ライブラリに入る
- Domain.recommended_domain_count: システムに適したドメイン数を推薦するAPI。EioとPicosがデフォルトで採用
- ポート整理: musl libc、RISC-V 64bit、ARM 32bit big-endianのサポート強化
- 小さな関数追加:
String.starts_with/String.ends_withが標準入り、In_channel.read_linesなど
5.3 は 5.x ラインで最初のLTSクラスの安定版とみなされている。Jane Street、Tezos、Tarides はいずれも2025年中頃にプロダクションを5.3へ移行した。
# 2026年標準のOCaml インストール (Opam ベース)
opam init -y
opam switch create 5.3.0
eval $(opam env)
ocaml --version
# The OCaml toplevel, version 5.3.0
5.4 / 5.5 は2025年秋から nightly で作業中。主にKokaスタイルの effect row type 導入をめぐるRFCが活発だ。OCamlコアチームは型システムを保守的に進化させることで有名なので、5.5 に effect row が正式に入るかは未確定。
4. Dune — ビルドシステムの標準
DuneはJane Streetが作ったOCamlビルドシステム。元の名前はjbuilderで、2018年の1.0と同時にDuneへ改名した。2026年現在、ほぼすべてのOCamlプロジェクトがDuneを使う。ocamlbuild、oasis、omake は実質的にレガシーだ。
Duneの強み:
- 宣言的ビルドファイル:
duneファイルにS式でライブラリ / 実行ファイル / テストを宣言 - 依存自動抽出: ocamlfind / ocamldepベースの依存解析
- 増分ビルドとキャッシング: ファイル単位ではなくモジュール / 構成単位でキャッシュ
- 同一ディレクトリ複数ライブラリ: 1つのディレクトリに複数のライブラリ / 実行ファイルを定義可能
- Cram / インラインテスト:
let%testのようなPPXと統合 - Watchモード:
dune build -wでファイル変更検知ビルド - クロスコンパイル:
dune build --workspaceで複数コンパイラ同時ビルド
基本的なduneファイル:
(library
(name my_lib)
(public_name my_lib)
(libraries base core lwt cohttp-lwt-unix)
(preprocess (pps ppx_jane)))
(executable
(name main)
(public_name myapp)
(libraries my_lib))
dune-projectファイル:
(lang dune 3.16)
(name myapp)
(generate_opam_files true)
(package
(name myapp)
(synopsis "A demo OCaml app")
(depends
(ocaml (>= 5.3.0))
(dune (>= 3.16))
eio
cohttp-eio))
Diskuv 事例: DiskuvはWindowsでのOCaml開発環境を構築した会社だ。DuneをWindowsネイティブで動作させる取り組みを主導し、2024年のdune 3.14でWindowsサポートが第一級市民となった。それ以前はWSLなしでWindowsでOCamlを使うのは極めて困難だった。Diskuvの貢献により、2026年には winget install Diskuv.OCaml 一行でインストールが完了する。
Duneの弱点:
- エラーメッセージが巨大なS式: 初見では圧倒される
- 外部ビルドシステムとの統合が弱い: Bazel / Buck と直結しない
- モノレポ規模の限界: 巨大モノレポで増分ビルドが遅くなる事例あり。Jane Streetは内部でforkしたDune派生を使う
代替は実質的に存在しない。2026年のOCaml新規プロジェクトはDuneが正解だ。
5. Opam — パッケージマネージャ
Opamは2012年にOCamlProとINRIAが共同で立ち上げたOCamlパッケージマネージャ。名前は「OCaml Package Manager」の略。2026年現在、opam-repositoryに7,000以上のパッケージが登録されており、毎週新しいリリースが入ってくる。
Opamのコアモデル:
- Switch: コンパイラ + パッケージの束。プロジェクトごとに別のswitchを作れる。
opam switch create my-proj 5.3.0 - Repository: パッケージメタデータの集合。デフォルトは opam-repository。社内リポジトリを追加可能
- Pin: ローカルディレクトリまたは Git URL を直接パッケージとして扱う。
opam pin add my_lib . - Lockファイル:
opam lockで正確なバージョン固定。2.1から1級機能
基本コマンド:
# 新規 switch 作成
opam switch create my-proj 5.3.0
# 依存インストール
opam install dune eio cohttp-eio dream
# ローカルパッケージ pin
opam pin add my_lib .
# Lock ファイル生成
opam lock .
# パッケージ検索
opam search effect
opam-repositoryはGitHub上にあり、誰でもPRで新パッケージ / 新バージョンを追加できる。登録過程でCIがビルド / テストを自動検証する。これがOCamlエコシステムの品質を支える大きな貢献だ — 壊れたパッケージがほとんど無い。
Opamの弱点:
- 遅い: 依存解決が他のマネージャ(Cargo、npm)と比べて明らかに遅い。solverがOPL / Mancoosi学術系基盤だから
- bytestring solver の非決定性: 同じ依存ツリーでもOS / プラットフォームによって異なるバージョンが選ばれる事例
- グローバル状態: switchがグローバル状態なので、1台で多数プロジェクトを管理する際に混乱。解決策はローカル switch (
opam switch create . 5.3.0)
2026年のベストプラクティスは プロジェクトごとにローカル switch + opam lock だ。CIで lock ファイルを検査すれば再現性あるビルドになる。
6. MirageOS — ユニカーネル
MirageOSはCambridge OCaml LabsでAnil Madhavapeddyが主導したユニカーネルプロジェクト。2013年に1.0、2026年現在は4.x ラインが安定化している。
ユニカーネル(unikernel)のコンセプト:
- 1つのアプリ + 必要最小限のOS機能を単一バイナリに: Linux + コンテナ + アプリ ではなく、アプリと必要OS機能だけを選んで単一イメージへコンパイル
- ハイパーバイザ上で直接起動: KVM / Xen / Solo5などのhypervisor上で直接ブート。ゲストOS無し
- 数MBイメージ: 通常 5-20MB。起動時間は数十ミリ秒
- 攻撃面の最小化: 一般OSの99%を削除。シェル、パッケージマネージャ、不要なシステムコールは全て無い
MirageOSはOCamlで書かれたユニカーネルを生成する。モジュールシステム(functor)を活用し、「ネットワークスタック」「ファイルシステム」「TCP/IP」などのコンポーネントを抽象化し、ビルド時にターゲットに合った実装を注入する。
(* unikernel.ml *)
open Lwt.Infix
module Main (S: Mirage_stack.V4V6) = struct
let start s =
let port = 8080 in
let cb flow =
let ip, p = S.TCP.dst flow in
Logs.info (fun f -> f "client %a:%d" Ipaddr.pp ip p);
S.TCP.write flow (Cstruct.of_string "hello unikernel\n") >>= fun _ ->
S.TCP.close flow
in
S.TCP.listen (S.tcp s) ~port cb;
S.listen s
end
# ビルドと実行
mirage configure -t hvt # Solo5 hvt ターゲット
make depend
make
solo5-hvt --net:service=tap0 -- ./unikernel.hvt
2026年のMirageOS利用先:
- Robur (ドイツの非営利、MirageOSメインコントリビュータ): TLSプロキシ、DNS リゾルバ、OpenVPN などをユニカーネルとして運用
- Tarides (フランスのOCamlコンサル): MirageOSベースのsandboxedビルド / 実行環境を研究
- Tezos: 一部のノードコンポーネントをMirageOSで運用検討
- AI sandboxed execution: 2025年からLLMが生成したコードを安全に実行する環境としてMirageOSが再注目。コンテナより分離強度が高い
MirageOSの弱点:
- エコシステムの大きさ: 通常のOCamlライブラリがそのまま使えない場合が多い(POSIX前提が崩れる)
- デバッグ: 一般OSツールが効かない。リモートgdb接続などを新たに学ぶ必要
- 運用人材不足: ユニカーネルを運用したSREがほぼいない
それでもMirageOSはOCamlの最も独特な成果の一つだ。「関数型モジュールシステムでOSを組み立てる」というアイデアが、現実に運用可能な形で動いている。
7. js_of_ocaml — JSコンパイル
js_of_ocaml(jsoo)は2010年からINRIAのJérôme Vouillonが主導するOCaml-to-JavaScriptコンパイラ。OCamlバイトコードを入力として受け取り、JavaScriptを出力する。すなわちOCamlコンパイラがバイトコードまで生成した後、jsooがそのバイトコードをJSに移植する。
特徴:
- OCaml全互換: 標準ライブラリ、Lwt、Effectまでほぼ全てサポート。MLの意味論をそのまま保持
- 巨大な出力: 通常1-3MBのJSバンドル。標準ライブラリを丸ごと含めなければならないため
- Tree shaking: 5.x時代に dead code elimination が大幅改善されたが、ReScript比でバンドルは依然大きい
# 基本的な使い方
ocamlfind ocamlc -package js_of_ocaml -package js_of_ocaml-ppx \
-linkpkg main.ml -o main.byte
js_of_ocaml main.byte -o main.js
js_of_ocaml の強みは 「OCamlコードをほぼそのままブラウザで動かせる」 こと。Tezosブロックチェーンクライアントは、OCamlコードの一部をjsooでブラウザ側に持ち込む。Coq → Rocq の jsCoq のような学術ツールもjsooベースだ。
弱点は バンドルサイズ と JS親和性の不足。JavaScriptと直接相互運用する際、OCaml型をJSオブジェクトに変換する作業が手間。この弱点を埋めるために登場したのが次章のReScriptだ。
8. ReScript (旧 BuckleScript, Hongbo Zhang) — JS 親和
BuckleScriptは2016年にBloombergのHongbo Zhang(中国出身、現ReScript Association)が作ったOCaml-to-JSコンパイラ。js_of_ocaml と正反対の哲学で始まった: OCamlのASTを受け取り、人間が読めるJSを出力する。出力JSは入力OCamlとほぼ1対1に対応する。
2020年、BuckleScriptは ReScript へリブランドされた。このとき大きな決断が下された: OCaml構文との互換を断ち、ReScript独自の構文に分離する。OCamlの ;;、let rec、module などがReScriptでは別の形になった。JavaScript開発者が親しみやすい方向(中括弧ブロック、let / const 風表記)へ進化した。
// ReScript 2026 syntax
let greet = (name) => {
let msg = `Hello, ${name}!`
Js.log(msg)
}
let main = () => {
greet("ReScript")
}
main()
ReScriptの強み:
- 出力JSが小さくクリーン: 人間が読めるJS。js_of_ocaml 比でバンドル約10倍小さい
- TypeScript互換が強い:
genTypeでReScript型をTS型へエクスポート - React親和: 公式
rescript-reactがReactの第一級市民 - Hot reload が速い: コンパイラが極めて速く、変更-反映サイクルが短い
弱点:
- OCamlからの分離: ReScriptはもはやOCamlではない。依存エコシステムも分離。opamパッケージを使えない
- PPX未対応: OCamlの強力なマクロシステムを使えない
- 少数派の市場: TypeScript比でシェアは小さい
2024-2025年にReScriptはReScript 11 / 12を経て安定化し、2026年現在は日本の一部スタートアップ(Mercariの一部チーム、小さなフィンテック)やヨーロッパの小さな会社で運用されている。韓国の採用市場ではほぼ見かけない。
9. Melange — ReScriptコンパイラをOCamlに戻す
Melangeは2022年にAntonio Monteiroが始めたプロジェクト。中心的なアイデアはシンプルだ: ReScriptがBuckleScriptから分かれOCaml互換を断った今、BuckleScriptのOCaml互換コアをOCaml本流へ引き戻そう。
MelangeはBuckleScriptのOCaml-to-JSバックエンドをforkし、ReScriptとは別方向に進化させる。違いは以下:
- OCaml構文をそのまま: ReScriptの新構文ではなくOCaml構文を使用
- Dune統合: ビルドはDuneで。ReScript独自ビルダーではない
- Opam統合: パッケージマネージャにopamを使用。通常のOCamlライブラリがそのまま使えるケースが多い
- Reason構文も可: Reason(Facebookの構文)をフロントエンドとして使える
(* Melange コード — OCaml 構文 *)
let greet name =
let msg = Printf.sprintf "Hello, %s!" name in
Js.log msg
let () = greet "Melange"
; dune file for Melange
(melange.emit
(target output)
(libraries my_lib)
(preprocess (pps melange.ppx)))
Melangeのポジションは明確だ: 「OCaml開発者がJSを出力したいとき」。ReScriptがJS開発者を惹きつけるためにOCamlから離れたのに対し、MelangeはOCaml開発者がそのまま同じ言語 / ツールでフロントエンドまで進めるようにする。
2024-2025年にMelangeは1.0と2.0を経て安定化した。2026年現在、小さなOCamlフルスタック会社で使われている。Taridesが一部の内部ツールをMelangeで作り、Ahrefs(元々のOCaml会社)も一部のフロントエンドをMelangeで試している。
10. Reason — Facebookの構文
Reasonは2017年にFacebookのJordan Walke(Reactの創始者)が作ったOCaml構文。中心的な発想: OCamlの機能は素晴らしいが、構文がJavaScript開発者には馴染みにくいので、OCamlの意味論をそのまま保ちつつ構文だけJSライクに変えよう。
Reasonの例:
/* Reason syntax */
let greet = (name) => {
let msg = "Hello, " ++ name ++ "!";
Js.log(msg);
};
let () = greet("Reason");
対応するOCaml:
(* OCaml syntax — 同じ意味論 *)
let greet name =
let msg = "Hello, " ^ name ^ "!" in
Js.log msg
let () = greet "Reason"
ReasonはOCamlにコンパイルされ、さらにOCamlがBuckleScript / MelangeによってJSにコンパイルされる。すなわちReason → OCaml AST → JS の流れだ。
2017-2020年の間にReasonはFacebook社内で急速に採用された。しかし2020年にBuckleScriptがReScriptへ分離されると、Reasonの位置づけが揺らいだ — ReScriptは独自構文を採用し、Reasonの居場所が曖昧になった。Facebookも次第にReasonの使用を減らしていった。
2026年のReasonのポジション:
- 依然OCamlフロントエンドとして動作: コンパイラは生きており、Duneが対応
- MelangeでReason構文を使える: Melangeユーザーの一部はReason構文で書く
- 活発な新規採用は少ない: ReScriptまたは純OCamlへ分岐
Reasonは死んではいないが、ピークは過ぎた。新規プロジェクトならMelange + OCaml構文が合理的なデフォルトだ。
11. Eio — Effectベースの並行性 (Multicore)
EioはOCaml 5のeffect handlersを活用した新しい並行 / IOライブラリ。2022年からCambridge OCaml LabsとTaridesが主導して開発中。2026年現在は1.0直前段階で、Eio 0.17程度が実運用されている。
Eioのコア:
- Effectベース:
async/awaitのようなキーワードは無い。普通の関数のように呼び出し、effectでyield / resume - 構造化並行性:
Switch内でfiberをspawnすると、switchが閉じる時に全fiberが整理される。Trio / Kotlin Coroutines と同じ哲学 - Multicore親和: ドメインプールを作りfiberをドメインに分散スケジュール。CPU-boundワークロードも本物の並列実行
- バックエンド抽象化:
Eio_main.runがOSに合ったバックエンド(Linuxではio_uring、macOSではkqueue、WindowsではIOCP)を選択
open Eio.Std
let fetch url =
traceln "fetching %s" url;
Eio.Time.sleep (Eio.Stdenv.clock env) 1.0;
url ^ " — done"
let () =
Eio_main.run @@ fun env ->
Switch.run @@ fun sw ->
let a = Fiber.fork_promise ~sw (fun () -> fetch "https://a.example.com") in
let b = Fiber.fork_promise ~sw (fun () -> fetch "https://b.example.com") in
traceln "%s" (Promise.await_exn a);
traceln "%s" (Promise.await_exn b)
Eioの強み:
- 明示的IOリソース受け渡し:
envのようなcapabilityを通してIOリソースが渡される。任意の関数が任意のIOを行えない。セキュリティとテスト容易性 - 取り消しが第一級: fiber取り消しが明確に定義される。Lwtの弱点だった取り消し意味を明確化
- multicore活用: Lwtは単一ドメイン。Eioは複数ドメインにfiberを分散可能
弱点:
- まだ1.0前: APIが壊れる可能性。2026年後半に1.0予定
- エコシステムが小さい: Cohttp-eio、Dream-eio のような派生は増えているが、まだLwtほど多くない
- Effectのデバッグ: effect handle chain を追跡するのは慣れるまで難しい
Taridesが発表した2025年のベンチマークでは、Eio + multicore が同一ハードウェアでTokio(Rust async)とほぼ同等のthroughputを示した。単一ノードIO-heavyワークロードでOCamlが再び競争可能になった決定的証拠だ。
12. Lwt — 古い並行性
Lwt(Light-weight threads)は2003年にJérôme VouillonがつくったOCamlの伝統的並行ライブラリ。単一スレッドのイベントループ上で promise('a Lwt.t)を合成する方式。JavaScriptのPromiseとほぼ同じモデル。
open Lwt.Syntax
let fetch url =
let* () = Lwt_unix.sleep 1.0 in
Lwt.return (url ^ " — done")
let () =
Lwt_main.run
(let* a = fetch "https://a.example.com" in
let* b = fetch "https://b.example.com" in
Lwt_io.printlf "%s / %s" a b)
Lwtの強み:
- 成熟: 20年以上運用されている。ほぼ全てのOCamlネットワーク / IOライブラリがLwt版を持つ(cohttp-lwt、irmin-lwt など)
- 単一スレッドで単純: race conditionが無い。JSのasyncと同じモデル
- インフラ互換: TLS、SSH、HTTP/2など、ほぼ全てのプロトコルがLwtにある
弱点:
- 単一ドメイン: 本物のマルチコア活用ができない。CPU-boundワークロードは別プロセスへ分離する必要
promise.bindの認知コスト:let%lwt/let*ppxで緩和されたが依然明示的- 取り消しが弱い: cancellationの意味が明確でない。Eioがこれを修正
2026年時点でLwtは レガシー + 安定性、Eioは 新規 + マルチコア の構図だ。新規プロジェクトはEioを検討するが、既存運用システム(Tezos、Mirage の一部)はLwtに縛られており、マイグレーションが進行中だ。
Async(次章): Jane Street内部で作られた並行ライブラリ。Lwtに似たpromiseベースだが別コードベース。Jane Streetエコシステム専用と見て差し支えない。
13. Cohttp / Dream — HTTP / Web
CohttpはOCamlの基本HTTPライブラリ。Anil Madhavapeddyが始めたもので、MirageOSエコシステムの中核コンポーネント。Lwt、Async、Eio バックエンドをすべてサポートする。
open Lwt.Syntax
open Cohttp_lwt_unix
let server =
let callback _conn req _body =
let uri = Cohttp.Request.uri req in
Server.respond_string ~status:`OK
~body:(Printf.sprintf "you hit %s" (Uri.path uri)) ()
in
Server.create ~mode:(`TCP (`Port 8080)) (Server.make ~callback ())
let () = Lwt_main.run server
Cohttpは低レベルだ。ルーティング、ミドルウェア、テンプレートのようなものは自分で組み立てる必要がある。それを補うのが Dream だ。
Dreamは2021年にAnton Bachinが作ったOCaml Webフレームワーク。哲学は「OCamlのRails / Flask」。単一ファイルでルータ、ミドルウェア、テンプレート、WebSocket、セッションまでまとめて扱う。
let () =
Dream.run
@@ Dream.logger
@@ Dream.router [
Dream.get "/" (fun _ -> Dream.html "Hello Dream!");
Dream.get "/users/:id" (fun req ->
let id = Dream.param req "id" in
Dream.html (Printf.sprintf "user %s" id));
Dream.post "/login" (fun req ->
let%lwt body = Dream.body req in
Dream.html (Printf.sprintf "got %s" body));
]
Dreamの特徴:
- 単一ファイルで開始可能: 小さなデモは50行内でフルスタック
- WebSocket / SSEが第一級: 両方ともライブラリのコア機能
- セッション / CSRF / Cookies: セキュリティ基本を装備
- テンプレート統合: 独自の
dream-emlでHTMLテンプレート - Lwtベース: 2026年でも依然Lwt。Eioポーティング作業中
代替Webフレームワーク: Opium(Sinatraライク、軽量)、Httpaf(低レベル高性能HTTP/1.1)、H2(HTTP/2 実装)。
2026年OCaml Web開発のデフォルトは Dream + Cohttp-lwt または Dream + Eio(ポーティング時)。小規模マイクロサービスならOpiumも良い選択。
14. Tezos (XTZ) — ブロックチェーンのOCaml
Tezosは2018年にメインネットがローンチされたPoSブロックチェーン。合意層とノード全体がOCamlで書かれており、2026年現在は時価総額で上位30位圏を維持している。ティッカーはXTZ。
TezosがOCamlである理由は明確だ — オンチェーンガバナンスがプロトコル修正を自動適用する。新しいプロトコルが提案されると、ステークホルダが投票し、可決されればノードが自動的に新コードを取得して有効化する。このメカニズムは 型安全と形式検証への向きやすさ が必須で、OCamlはそれを最もよく支える産業言語だ。
Tezosノードの構造:
- Shell: ノード本体。P2P、mempool、RPC処理。Lwtベース
- Protocol: 合意 / ガバナンス / スマートコントラクトのルール。Functorで抽象化されており、修正時に差し替え可能
- Michelson: スマートコントラクトのVM言語。スタックベースで強型付け。OCaml実装
- Storage: Irmin(OCaml製のGitライク content-addressable storage)
(* Tezos スニペット — Michelson インタプリタの一部 *)
let step_instr (instr : ('bef, 'aft) Script.instr) (stack : 'bef stack) :
'aft stack tzresult Lwt.t =
match instr, stack with
| Add_int, Item (Int a, Item (Int b, rest)) ->
return (Item (Int (Z.add a b), rest))
| Push (ty, v), rest ->
return (Item (Cast.cast ty v, rest))
| _ -> fail Bad_stack
TezosのエコシステムはOCamlの最大の産業事例だ。Nomadic Labs、Marigold、Tarides、TriliTech などの企業がTezosコア開発に参加し、いずれもOCamlフルタイム採用を行う。
2024-2025年、Tezosは Adaptive Issuance(動的インフレ調整)、Smart Rollups(Layer 2)、Data Availability Layer を追加して進化した。2026年現在は Quebec → Rio → Seoul プロトコルラインで進行中。プロトコル修正の事例自体が、OCamlモジュールシステムの好例として学界で頻繁に引用される。
15. Hack (Meta) / Flow (Meta) / Async (Jane Street) — 産業
Hack (Meta): PHPに段階的型付けとgenericsとasyncを追加した言語。2014年公開。Meta内部でFacebookバックエンドの大半を回している。コンパイラと型検査器がOCamlで書かれている。HHVM(VM)はC++だが、型検査器、インタプリタの一部、静的解析はOCaml。
Flow (Meta): JavaScript向け静的型検査器。2014年公開。TypeScriptとライバルだったが2020年代後半にTypeScript優勢で市場から押し出された。それでもMeta内部のJSコードベースには依然Flowが運用されている。FlowもOCaml製。2026年現在Flowの活発な外部採用は減ったが、Meta内部では生きている。
Async (Jane Street): Jane Streetが作ったOCaml並行ライブラリ。Lwtに似たpromiseベースだが別実装。Deferred.t がLwtの 'a Lwt.t に似た役割。Jane StreetコードベースはAsyncで動いている。
open Core
open Async
let fetch url =
let%bind () = Clock.after (Time_float.Span.of_sec 1.0) in
return (url ^ " — done")
let main () =
let%bind a = fetch "https://a.example.com" in
let%bind b = fetch "https://b.example.com" in
printf "%s / %s\n" a b;
return ()
let () =
Command.async ~summary:"demo"
(Command.Param.return main)
|> Command_unix.run
3つはいずれも OCamlが産業で実際に運用されている 証拠だ。HackはMetaのトラフィックを受け、FlowはMeta内部JSを検査し、AsyncはJane Streetのトレーディングシステム全体を回す。
16. Jane Street — 最大のOCaml会社
Jane Streetは2000年設立の量的取引(クオンツ)会社。本社はニューヨーク。2026年現在約3,000名の社員、うちエンジニアは1,500名以上。世界で最もOCaml採用が多い会社。
Jane StreetのOCamlコードベースは約 2,500万行 と推定される。全トレーディングシステム、バックオフィス、データパイプライン、内部ツールがOCamlで書かれている。C++ / Python / Java といった他言語も使うが比重は小さい。
Jane Streetのオープンソース貢献:
- Dune: ビルドシステム(上述)
- Core: 標準ライブラリの代替。OCamlの stdlib より豊富で一貫したAPI
- Async: 並行ライブラリ
- ppx_jane: PPXメタプログラミングセット(deriving、expect tests、sexp など)
- Bonsai: OCaml用のReactライクフロントエンドフレームワーク(incremental computation)
- Magic Trace: Intel PTベースのバックトレース可視化ツール
- Memtrace: メモリプロファイラ
(* Jane Street スタイル — Core + ppx_jane *)
open Core
let%test_unit "list sum" =
[%test_eq: int] (List.fold ~init:0 ~f:(+) [1; 2; 3]) 6
type point = { x: float; y: float }
[@@deriving sexp, compare, equal, fields]
let () =
let p = { x = 1.0; y = 2.0 } in
printf !"%{sexp: point}\n" p
Jane Streetの採用文化:
- OCamlを知らなくても入社可: 入社後に会社が OCaml を教える。インターン / 新人向けの OCaml ブートキャンプを運営
- インターンの比重が大きい: 毎年約200名以上のインターン。米国大学(MIT、CMU、Princeton、Harvard、Stanford)から優秀な学部生を採用
- 報酬の高さで有名: 新人パッケージで50万〜100万ドルの事例が頻繁に報告される
Jane StreetはOCamlの最大のスポンサーであり、OCamlが産業で真剣に扱われる決定的理由だ。Jane StreetがOCamlを捨てればOCamlエコシステムの資金 / 人材が50%以上消えるという冗談すらある。
17. 韓国 / 日本 — KAIST PL lab、京都大学 PL lab
OCamlは産業より学界の方が強い。特にPL(Programming Languages)研究室では中核ツールだ。
韓国 — KAIST PL lab:
- KAIST Programming Languages Laboratory (Kwangkeun Yi 教授ほか): 静的解析、抽象解釈、形式検証研究。ツール実装にOCamlを使用。Sparrow 解析器などの成果物
- SNU PL lab (Chung-Kil Hur 教授ほか): コンパイラ検証(CompCert を活用)、Coq / Rocq + OCaml の組み合わせで形式証明
- POSTECH (Sungwoo Kang 教授ほか): 型システム、effect type 研究
- 韓国産業OCaml採用: ほぼ存在しない。Jane Street の韓国オフィスは無いが、リモートで働く韓国人エンジニアの事例はある
日本 — 京都大学 / Tokyo Tech:
- 京都大学 PL lab (五十嵐淳 グループ): 型理論、依存型、gradual typing 研究。OCamlベースのツール多数
- Tokyo Tech (東京工業大学、現 Institute of Science Tokyo): 関数型プログラミング / モデル検査研究。OCaml は標準ツール
- 東京大学 IPL: PL / SE 研究。Coq / Rocq + OCaml 活用
- 日本産業OCaml採用: 非常に少ない。Ahrefs(解析SaaS、元々OCaml会社)の日本リモート採用が一部、Mercariの一部実験的使用
学界でのOCaml利用は2つの理由による。(1) ML 系がPL研究の lingua franca、(2) 形式検証ツール(Rocq、F*、Why3、Cubicle など)がOCamlで書かれている。韓国 / 日本でPL博士を取るならOCamlを使わない選択肢は無い。
18. 誰がOCamlを学ぶべきか — FP / 形式検証 / コンパイラ
2026年のOCamlは全員向けの言語ではない。採用市場が狭く(特に韓国)、ライブラリエコシステムも JavaScript / Python に比べて小さい。それでも OCaml を必ず学ぶべき人 はいる。
1) PL / 形式検証 研究者: 博士課程がPL方面なら OCaml は必須。Rocq、F*、Why3、CompCert、Tezos などのツールが OCaml で書かれており、学会論文(POPL、PLDI、ICFP)の実装も多くがOCaml。
2) コンパイラ開発者: OCaml はコンパイラ作成の標準言語だ。パターンマッチ、代数的データ型、モジュールシステムが AST 処理に最適。Rust コンパイラの一部、Haskell コンパイラの一部も OCaml から着想を受けた。
3) Jane Street / Tarides / Tezos 志望者: これらの会社に行きたいなら OCaml を学ぶ。入社後に習ってもいいが、事前知識は面接で有利。特に Jane Street のインターンは OCaml の基礎を1週間かけて教えてテストする。
4) Haskell が重く感じる関数型入門者: OCaml は strict evaluation で implicit な type class を持たない。Haskell に比べて「関数型だが普通の言語」に近い。ML 系入門に良い。ただし韓国語 / 日本語学習資料は Haskell の方が多い。
5) 形式検証 / コンパイラ検証 / 静的解析 に関心ある開発者全般: 学界でなくとも、静的解析ツールを作りたい、インタプリタを作りたい、ドメイン特化言語を作りたいなら OCaml は適した道具。
OCamlをあえて学ばなくてもいい人:
- 一般的なバックエンド / Web 開発 (Go / TypeScript / Python の方が合理的)
- モバイルアプリ (Swift / Kotlin)
- 機械学習 (Python + Rust)
- 韓国でOCamlの仕事を狙うならほぼ不可能。学界か海外リモート企業が答え
学習経路の推奨:
- Real World OCaml 2nd ed (Anil Madhavapeddy, Yaron Minsky, Jason Hickey) — 無料オンライン。2022年の OCaml 4.13 ベースだが 5.x にもほぼ通用
- OCaml.org tutorials — 公式チュートリアル、5.x 対応
- Cornell CS 3110 (Michael Clarkson) — 無料の講義ノート。学部 PL 授業の標準
- Effects Unleashed (Tarides ブログシリーズ) — Eio + Effect 学習
- Jane Street Tech Blog — 実戦事例多数
19. 参考 / References
- OCaml.org — 公式サイト
- OCaml 5.3 release notes — GitHub リリースノート
- Multicore OCaml — Multicore プロジェクト
- Effect Handlers in OCaml 5 — KC Sivaramakrishnan のブログ
- Dune docs — ビルドシステム公式ドキュメント
- Opam — パッケージマネージャ
- opam-repository — パッケージリポジトリ
- Diskuv OCaml — Windows 向け OCaml ディストリビューション
- MirageOS — ユニカーネルプロジェクト
- Robur — MirageOS 運用の非営利
- Tarides — OCaml コンサル (MirageOS、Tezos、Eio)
- js_of_ocaml — OCaml-to-JS コンパイラ
- ReScript — Hongbo Zhang の OCaml 派生 JS 言語
- Melange — ReScript コンパイラを OCaml に戻したプロジェクト
- Reason — Facebook の OCaml 構文
- Eio — Effect ベース IO
- Lwt — 伝統的な OCaml 並行ライブラリ
- Cohttp — HTTP ライブラリ
- Dream — OCaml Web フレームワーク
- Tezos — OCaml ベースの PoS ブロックチェーン
- Nomadic Labs — Tezos コア開発企業
- TriliTech — Tezos / Etherlink 開発
- Hack — Meta の PHP 後継 (OCaml ベースツール)
- Flow — Meta の JS 型検査器 (OCaml)
- Jane Street — 最大の OCaml 採用先
- Jane Street Tech Blog — 実戦事例
- Real World OCaml — 2nd edition 無料オンライン
- Cornell CS 3110 — Michael Clarkson 講義ノート
- KAIST PL Lab — 韓国 PL 研究室
- Kyoto University Igarashi Lab — 京都大学 PL 研究