関数型まつり2026参加記

7/11 ~ 7/12 に開催された関数型まつり2026に参加してきました。
実は弊社（HERP）もスポンサーをやっておりその流れで行けました。やったぜ。

既に1ヶ月経っており参加レポートを書くにはやや遅いんですが、マジオタクばかりが参加しているカンファレンスなだけあって多くのマジ学びが得られたのでいくつかピックアップして話します。

面白かったセッション

本物のプログラマーは unsafe と型システムを使う 〜拡張可能レコードを作って学ぶ黒魔術入門〜

拡張可能レコードの実装を題材に、安全な言語機能だけを用いた効率度外視の実装を unsafe を用いて高速化していくという内容。

自分は Rust を少しかじっているので unsafe に対する基本的な理解¹はあったが、この発表を通してより深い理解が得られた気がする。

まず、最初の方で安全・危険とは何かという話がなされていたのがよかった²。
unsafe とは本来コンパイラが保証すべき「安全性」を代わりにプログラマーが保証しますよとコンパイラに対して宣言するマーカーのようなものだが、そもそも安全・危険は2つの尺度に分けて考えることができる:

正当性（correctness）：プログラムが仕様を本当に満たしているか？

健全性（soundness）：今考えているAPIが天から与えられたとして、「型システムなどの言語処理系が当然保証すべき安全性」が破れないか？

型システムを念頭に置く場合は後者を型安全性とも言う。

例えば Haskell (や Rust) には配列にランダムアクセスする API があるが、これらは範囲外アクセスによって実行時エラーを引き起こしうる。
範囲外アクセスを起こさないことを型レベルで保証することも可能だが、型推論のコストが高すぎるとかプログラムを書くのが大変になってしまうとかそういったトレードオフがあるので保証しないという選択がなされている。
正当性の尺度では防ぎたいが健全性の尺度では許容している誤りの代表例としてよく挙げられる。

自分のホームグラウンドである TypeScript コミュニティでは「型安全」という言葉がバズワードとして乱用されているが、重要なのは何が安全・危険で型システムを用いて何が安全になるのかという点であり、それをちゃんと定義せずに型安全と主張してもあまり意味がないなぁという気持ちになった。

また個人的には、「安全」な実装（今回のケースでは Haskell の型レベルプログラミングによる実装）が得られる場合はそれをテストの Ground Truth として用いることができるという話がアツかった。
自分は仕事で度々 Property Base Test を利用しているのだが、テストオラクルを用いた PBT はかなり強力である（e.g. データベースへのクエリが意図したものであることを検証するためにインメモリの配列を用いたフェイク実装をオラクルにする）。
テストオラクルを用いる際の最大の懸念はオラクル自体の実装が正しいことを何をもって保証するのかという点だが、今回の発表の例のように十分な表現力を有した型システムで適切に制約をエンコードしてやれば強力な保証を与えることができそうだ。

---

これは完全に与太話なのだが、Haskell という表現力の高い型システムを活用した実装例を見てペアノの公理やラムダ計算を思い出した。
両方ともごく少数のプリミティブからとても複雑な構造を表現することができ、その性質を帰納的に証明できる。これが形式的証明や Curry–Howard 対応の話に繋がってくるわけだが、自分が言いたいのはペアノの公理やラムダ計算で算術やプログラムを表現するのは超面倒くさいという点で、何よりその記述の面倒さ以上に、これらで表現されたものを物理的な計算機上で評価するのはとても非効率な気がしてくる。

形式的に健全な世界を構成するためのプリミティブだけで実装することも可能だが、我々はコンピューターという物理的制約が課された存在を利用しているのでモデルの世界と実際の挙動の世界を分離したい。そのために unsafe のような仕組みがあると考えるとなんだかしっくりきた。

継続モナドとリアクティブプログラミング

まず Data があり、それを購読する Process があり、Data を更新する Event があるという、React ユーザーなら Flux でお馴染みのリアクティブプログラミングを型で表現していくと…？という内容。前半はリアクティブプログラミング向けの開発中の言語 Quon³を軸に話が展開されていた。

個人的な関心として、React (や同等の機能を有する最近の UI フレームワーク) は JavaScript/TypeScript の表現力の限界を超えてしまっており本当はもっとイカしたモデルを与えることができるのではないかという気になりがあったので聴講した。

まず、リソースの初期化・解放の対からなる Routine 型がある。
これを bind するとリソースの解放処理が逆順に合成、つまり親を解放しようとすると子が先に解放されるようになっておりリソース安全性が担保されている。
React で言うなら、コンポーネントがマウント・アンマウントの対からなる Routine に対応し、コンポーネントツリーが Routine の合成に対応する感じだろうか。依存配列が空（= マウント時に1回だけ実行される）の useEffect はコンポーネントの子 Routine になりそうだ⁴。

次に reactivity を実現する中核的存在として Source 型というリソースを購読する構造がある。
これは React のイベントリスナー（on*）や Solid.js の <For>, <Show> に対応しそうだ⁵。
Source はリスナーを受け取るとその購読状態自体を Routine として返すようになっているのが面白くて、例えば React ならコンポーネントのマウント・アンマウントとそのコンポーネントに紐づくイベントリスナーの登録・削除は同期するわけだが、Routine と Source で表現するとするなら、コンポーネントを表す Routine と、Source にイベントリスナーを渡して得た Routine を合成することで同等のライフサイクル管理を実現できる（はず）。
そして Source 型の構造はそのまま継続モナドに対応する（！）。

また内部状態を表現するために Row と Patch というものを検討しているとのことだった。前者は変化する連続値、後者はそれに対するリスナーを表す。
現状は状態の連続的な変化は新しいリソースを作成して置き換えることで表現されるが、例えば取得に時間がかかるリソースがあった時に、新しいリソースを取得し切り替えるまでの間は古いリソース（= 前回の状態）を表示しておきたい。なんだか React の transition と useDeferredValue みたいな話だが、Routine だと状態が独立したリソースとして表現されるためそれぞれの関係性を把握できない。
そこで Patch という React で言う state のような内部状態を表現する仕組みが必要になってくる。

面白いのが Source と違って Patch はモナドの構造を満たさない。
内部状態を持つ Patch では条件分岐に気を遣わなければならず、条件分岐そのものをなくして毎回同じ Patch を実行するようにするか、条件分岐が発生した際に内部状態を破棄して再構築する必要がある。今回のケースでは条件分岐をなくして計算グラフを静的にするのが適しているらしい。
これは Haskell の型クラスの語彙を借りると ArrowChoice なしの Arrow と見做せて、React の Rules of Hooks (条件分岐の中で hook を呼び出してはならない) に対応する（！）。

最小限の規則・構造で複雑なものを表現したり、抽象化・一般化していくことで意外な共通の構造を見出したりするのは関数型プログラミングに触れると得られる感動の1つだと思っており、よかった（小並感）。

最後の方では応用例として AI エージェントを定義するための言語 Katari⁶ の紹介とその言語で実装された Discord Bot のデモがあった。代数的エフェクトや Coeffect 的仕組みまで備えているらしくなかなか面白かった。
最近 v0.1 をリリースしたとのことなので試してみたい。

LLMに書かせる前提で設計された言語の設計について議論して｡

既存の Human-Oriented 言語と LLM を前提として設計された LLM-Oriented 言語でバトルさせてみるという内容。
やはりオタクたるもの自作言語の1つや2つは作っておきたいが LLM が盛り上がっている昨今どうなのよということで聴講した。

既存の有名な言語と LLM-Oriented 言語: Moonbit, AILANG, Zerolang, Nexus (自作) で同じアルゴリズムを実装させ、その実装成功率とトークン効率の調査が主体となっている。
当たり前のように自作言語にエフェクトシステムと線形型が備わっているところにウケつつ、ベンチマークの結果を見ると、LLM-Oriented 言語（Zerolanng 除く）の実装成功率自体は Human-Oriented 言語と同じ水準だが、トークン効率がかなり悪いということが分かった（絶望ポイント）。やはりモデル自体に言語の知識が埋め込まれているというのは相当なアドバンテージなようだった。

一方で意外だったのが Moonbit のトークン消費量が他の LLM-Oriented 言語よりずっと少ないことだった。新しいマイナーめの言語であっても LLM の知識のカットオフに入りさえすれば Human-Oriented 言語のトークン効率にかなり近づくらしい（希望ポイント）。
また、既存のソースコード（stdlib など）を読ませるのもなかなか効果的らしく、LLM の next token 予測マシンとしての特質を見た気がした。LLM の知識に入っていない新しい言語であっても、それで実装したコードベースが一定以上大きくなれば周辺コードを読むついでに勝手に事後学習してくれそうだ。

また、LLM-Oriented 言語の中でも Zerolang だけ異様に実装成功率が低いのも面白かった。これは型エラーを1回の検査で1件しか出さないのが原因と考えられるらしい。プログラムを構成する過程で LLM に十分なフィードバックを与えてイテレーションが回るようにするのはやはり重要らしい。
ｴｰｱｲで覇権を取ろうと躍起になっている Vercel 謹製の言語なだけに悲哀があるね…。

スライドを通して、

言語を作るのに今は (も) 時期が良い！

世はまさに大 LLM 言語時代

というアツい主張がなされていたが、実際関数型まつりでは自作言語に関する発表が複数あり、いずれも LLM を活用して実装されているようだったので、本当に今は言語を作るのに時期が良いらしい。
オレも作るぞ！！！

全体の感想

前述のテーマ以外にも OCaml をプロダクションで利用している話や TS や PHP で関数型プログラミングの考えを導入する話、定理証明支援系の話、代数的エフェクトや圏論などの理論的な話など様々な発表があった。これまで自分が参加したこのある勉強会・カンファレンスの中で最もオタク度が高かったのではないかと思う。
登壇者の方から直接教えを乞ったり、インターネットで知ってる人と話したり、オフラインの有意義な交流もあった。

また実は、関数型まつりの後に Effect-TS「継続」と「撤退」の境界線 というイベントで Effect-TS の話をした。
コイツは TypeScript 上でエフェクトシステム⁷を実現するライブラリであり、弊社の一部プロダクトでガッツリ利用している。
関数型まつり2026では代数的エフェクトに関する発表が多く、実は代数的エフェクトまつりなのではないか？という節があったが、エフェクトシステムがあるとこういう嬉しさがあるぜ！というリアルなトークはなかなか少ない。
そういう意味で割と自分も話せることあるなぁという気持ちになれたのもよかった。

仕事の話

ここでちょっと仕事脳になる。
普段仕事では TypeScript という型システムの表現力が妙に高いキモ言語を扱っているわけだが、型システムを活用した設計・実装に関してはまだまだ学習・実践・教育の余地があると感じた。
ドメインモデルを ADT で定義したり branded types を用いて smart constructor 的な設計パターンを持ち込んでみたりと前々から実践してはいたが、今回の関数型まつりを通して型システムを活用することの価値を改めて認識できたので、さらにモチベーションが上がっている。

ということでソフトウェアをいい感じに作る技法に関心のあるオタクの方は是非カジュアル面談しましょう。

脚注

1. 少なくとも、 unsafe を使用することが型システムの存在を無意味にしたりエルフの村を焼いたりすることにはならないと知っている。 ↩

2. 質のいい発表は定義や前提の共有にしっかり時間を割いていることが多い。関数型まつりではそのような発表が多かった。 ↩

3. ロゴがかっこいい。後で話を聞いたところ漢字の「久」がモチーフらしい。 ↩

4. 依存配列に空でない場合は値の変化に応じて処理が実行されるので後述の Source になるかも？ ↩

5. この発表におけるリアクティブプログラミングは Solid.js のような Fine-grained reactivity 的なので などのメンタルモデルの方が近い ↩

6. こちらのロゴは「語」がモチーフらしい。 ↩

7. 代数的エフェクトではなさそう。 ↩