はじめに
7/11(土)・12(日)に中野セントラルパークで開催された、関数型まつり2026の参加レポートです。
10分セッションで「美しいコードを書くためにF#を学んでみた話」をしてきました
昨年の関数型まつりで基調講演をされていたScott Wlaschinの著作である「関数型ドメインモデリング」を題材にお話してきました。
（思いの外TypeScriptのBranded Typeの話に偏ってしまった気もします）
10分という時間的制約の中だと、どうすれば情報をできる限り齟齬なくまとめられるかであったり、「スライドにあってもあえて語らないこと（あるいは一枚のスライドにするほどではないが、口頭で補足すべきこと）」など伝え方の強弱に非常に悩まされました。前日の夜に何度も素振りを繰り返して（読み上げ用のスクリプトを削ったり加えたりして）、ほぼ10分ジャストで収めることができたのでほっととしています。
また「型を集合として捉える」という文脈の中でいくつかの記事を参考文献として掲載させていただいたのですが、発表が終わった直後に、「あの記事書いたの僕です」とまさかの筆者ご本人に声かけてもらって、色々お話できたのが感慨深かったです。
その他にも、何人かの方から直接感想を伝えていただくことができて、アウトプットに対する感度の高いフィードバックを即時いただけるのはカンファレンス登壇の醍醐味だな......と強く実感しました。
印象に残ったセッション
この2日間、拝聴したどのセッションも学びが深く魅力的な内容でしたが、中でも特に印象に残ったセッションをいくつかピックアップしてご紹介します。
なぜ関数型プログラミングで「型」と「証明」が語られるのか
- 関数型プログラミング（FP）と型システムは、どちらもラムダ計算を起点として共に発展してきた歴史がある
- 副作用のない世界（参照透過性）では、関数は純粋に入力から出力を生成する。「型＝命題」「プログラム＝証明」として読み替えることが可能になり、型検査が正しさの機械的な検証になる
- Result や直和型、スマートコントラクトなどは、「あり得ない状態」を機械に検査させ、排除するための強力な道具である
この後の2日間で登場するキーワードや、関数型プログラミングを歴史的な時間軸からなぞることができる、カンファレンスの始まりに聴けてよかったセッションだったと感じます。
型推論入門 ― Hindley-Milnerの仕組みと実装の違い
- 型推論の本質は、確定している型からコード上の未知の型を導き出す仕組み
- HM（Hindley-Milner）型推論は、式に型変数を割り当て、構造を再帰的にたどりながら制約を定義し、単一化（Unification）を行うアルゴリズム（Algorithm Wなど）
- Flix、Elm、Gleamなどの言語にベースとして採用されており、Elmなどの多相型は「let一般化（let-generalization）」によって実現されている。
- 基本は「型同士の等価性（同じ型であること）」の制約しか扱えないが、拡張によって他の制約にも対応できるため、言語の実装アイデアとして非常に魅力が高い。
一口に型推論と言ってもさまざまな手法があるのだなと。中でもピックアップされていたHM型推論が多くの関数型言語の基盤となっているのだと知れて、知的好奇心をくすぐられるセッションでした。
型は壁、Rustでもバグを直すな、表現できなくせよ
- バグを後から直すのではなく、「起きない形（燃えない素材）で最初から建てる」という設計アプローチ
- 状態を型で守る4つのパターン
- 状態ごとに型を分ける
- 同じデータ型（数値など）でも意味ごとに分ける（newtype パターン）
- 検証付き生成関数などを使い、不整合なデータの「作り方」自体を限定する
- 正しい組み合わせだけを enum で定義し、match で考慮漏れを防ぐ（フラグと Option を分離しない）
- 型はコンパイル時のユニットテストであり、文脈を名前や型に込めればAIもそこから推論できる。それでも何を正しい振る舞いとするかを規定して最後に検証する責任は人間に残る
Rustが題材でしたが、型で形を守り、正しい振る舞いを文脈に乗せる考え方は、使用する言語に関わらず非常に勉強になるお話でした。
フェーズで分割して、依存からライフサイクルやデータでデザインすべき寿命を観察する。音楽のための関数型プログラミング言語mimiumにおける多段階計算の活用
- 音楽土木工学の専門知見から生まれた、ラムダ計算ベースのドメイン特化言語（DSL）mimiumのお話
- RustにTranspileできるWebエディタがあったり、関数の中で「その関数の1時刻前の返り値」を取り出すことができたりする（音響信号処理におけるフィードバックの記述などに有用）
- 過去の値を参照する行為は一見すると不純（副作用があるよう）に思えるが、時間的な規則性として捉えれば純粋である、というアプローチが面白い
- ハウリングの合間にあるエフェクトをリアルタイムに書き換えるような高度な処理を実現し、言語デザインそのものを探索の道具としている
コードの変更が音に即時反映されるのすごい…#fp_matsuri_b pic.twitter.com/b1NnhU3o4S
— 0yu (@yud0uhu) 2026年7月12日
扱っているドメイン知識の幅広さと、さらっとコードの変更が音に即時反映されるデモの凄さに圧倒されました。
パッケージマネージャー Nix はなぜ純粋関数型言語で設定を記述するのか
- Nixはビルドプロセスを「参照透過性を持つ関数」のように扱う
- 入力（依存関係）を derivation として明示し、その参照関係からビルド順序を決定する。生成された Nix Store は不変（Immutable）であるため、同じ入力からは常に同じ出力が得られる
- Nix言語自体は動的型付け言語。derivation を生成するDSLとして機能する（ファイルI/Oを伴うため関数自体は不純だが、ビルドの純粋性を担保するための道具）
Nixは「入力が同じなら出力は絶対に同じになる」という参照透過性を「ファイルの不変性（ImmutableなNix Store）」というアーキテクチャ的な制約で実現している、というお話（だと解釈しました）。 Nixをパッケージ管理・ビルドシステムの仕組みから学ぶことで、純粋関数型プログラミングのパラダイムを表現していることが理解できる、学び深いセッションでした。
