필사 모드: モダンOCaml 2026 — OCaml 5.3 / Multicore / Effect Handlers / Dune / Opam / MirageOS / ReScript / Melange / Jane Street 徹底ガイド
日本語> 「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](https://github.com/ocaml/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の仕事を狙うならほぼ不可能。学界か海外リモート企業が答え
学習経路の推奨:
1. **Real World OCaml 2nd ed** (Anil Madhavapeddy, Yaron Minsky, Jason Hickey) — 無料オンライン。2022年の OCaml 4.13 ベースだが 5.x にもほぼ通用
2. **OCaml.org tutorials** — 公式チュートリアル、5.x 対応
3. **Cornell CS 3110** (Michael Clarkson) — 無料の講義ノート。学部 PL 授業の標準
4. **Effects Unleashed** (Tarides ブログシリーズ) — Eio + Effect 学習
5. **Jane Street Tech Blog** — 実戦事例多数
19. 参考 / References
- [OCaml.org](https://ocaml.org/) — 公式サイト
- [OCaml 5.3 release notes](https://github.com/ocaml/ocaml/releases) — GitHub リリースノート
- [Multicore OCaml](https://github.com/ocaml-multicore) — Multicore プロジェクト
- [Effect Handlers in OCaml 5](https://kcsrk.info/) — KC Sivaramakrishnan のブログ
- [Dune docs](https://dune.readthedocs.io/) — ビルドシステム公式ドキュメント
- [Opam](https://opam.ocaml.org/) — パッケージマネージャ
- [opam-repository](https://github.com/ocaml/opam-repository) — パッケージリポジトリ
- [Diskuv OCaml](https://diskuv.com/) — Windows 向け OCaml ディストリビューション
- [MirageOS](https://mirage.io/) — ユニカーネルプロジェクト
- [Robur](https://robur.coop/) — MirageOS 運用の非営利
- [Tarides](https://tarides.com/) — OCaml コンサル (MirageOS、Tezos、Eio)
- [js_of_ocaml](https://ocsigen.org/js_of_ocaml/latest/manual/overview) — OCaml-to-JS コンパイラ
- [ReScript](https://rescript-lang.org/) — Hongbo Zhang の OCaml 派生 JS 言語
- [Melange](https://melange.re/) — ReScript コンパイラを OCaml に戻したプロジェクト
- [Reason](https://reasonml.github.io/) — Facebook の OCaml 構文
- [Eio](https://github.com/ocaml-multicore/eio) — Effect ベース IO
- [Lwt](https://ocsigen.org/lwt/latest/manual/manual) — 伝統的な OCaml 並行ライブラリ
- [Cohttp](https://github.com/mirage/ocaml-cohttp) — HTTP ライブラリ
- [Dream](https://aantron.github.io/dream/) — OCaml Web フレームワーク
- [Tezos](https://tezos.com/) — OCaml ベースの PoS ブロックチェーン
- [Nomadic Labs](https://www.nomadic-labs.com/) — Tezos コア開発企業
- [TriliTech](https://trili.tech/) — Tezos / Etherlink 開発
- [Hack](https://hacklang.org/) — Meta の PHP 後継 (OCaml ベースツール)
- [Flow](https://flow.org/) — Meta の JS 型検査器 (OCaml)
- [Jane Street](https://www.janestreet.com/) — 最大の OCaml 採用先
- [Jane Street Tech Blog](https://blog.janestreet.com/) — 実戦事例
- [Real World OCaml](https://dev.realworldocaml.org/) — 2nd edition 無料オンライン
- [Cornell CS 3110](https://cs3110.github.io/textbook/) — Michael Clarkson 講義ノート
- [KAIST PL Lab](https://prl.kaist.ac.kr/) — 韓国 PL 研究室
- [Kyoto University Igarashi Lab](https://www.fos.kuis.kyoto-u.ac.jp/) — 京都大学 PL 研究
현재 단락 (1/425)
本稿は **2026年5月時点のOCamlエコシステム全体地図**である。2022年12月にOCaml 5.0がMulticoreとEffect Handlersをもたらしたことで、「シングルコアの関...