関数型の考えを TypeScript に持ち込んで、テストしやすい純粋関数を増やす / Pure at the Core, Effects at the Edge: Bringing Functional Thinking into TypeScript

関数型まつり2026
https://2026.fp-matsuri.org/

関数型の考えを TypeScript に持ち込んで、テストしやすい純粋関数を増やす

Shimmy
ソフトウェアエンジニア

Transcript

1. 関数型の考えを TypeScript に持ち込んでテ ストしやすい純粋関数を増やす 関数型まつり2026 株式会社カミナシ Shimmy(@naoya7076)
2. 経歴 ⾃⼰紹介 株式会社カミナシ Software Engineer 清水 那音也 ヤフー株式会社でエンジニアとして開発に従事。 freee株式会社で新規プロダクト開発を行った後、ソフトウェア 品質の改善に携わる。 2024年 株式会社カミナシに ⼊社し既存プロダクトの開発を 行った後 2026年から新規プロダクトの立ち上げを行っている。
3. アジェンダ 1. 純粋関数と副作用 2. TypeScriptについて、型で表現できないこと 3. FCISという考え 4. アプローチ 1: Result型でエラーを値として扱う 5. アプローチ 2: FCISをディレクトリ構造で表現する a. ガードレールを敷く 6. まとめ
4. ターゲット 関数型は知ってるけど TypeScript は書いてない TypeScript は書いてるけど関数型は知らない
5. 第 1 部 純粋関数と副作用
6. ⾔葉の定義 純粋関数(pure function)とは 純粋関数 => ①参照透過性 + ②副作用がない
7. ⾔葉の定義 参照透過性とは 同じ入力に対して、常に同じ出力を返すこと。 • 引数だけで結果が決まる ◦ 外部の状態(グローバル変数、現在時刻など)に依存しない • 式を戻り値に置き換えても意味が変わらない ◦ f(x) をその実⾏結果の値で書き換えても、プログラム全体の 動作は変わらない
8. ⾔葉の定義 副作⽤(side effect)とは 関数の内部で完結せず、関数の外の世界とやりとりす る、または外の世界の影響を受けること。 • 外部I/O:DBへの読み書き、HTTPリクエスト、ファイル操作 • 実⾏タイミング‧回数に依存:現在時刻、乱数、ID⽣成 • 状態変更:グローバル変数の書き換え、引数のミューテーション • 例外を投げる
9. コード例 純粋関数 calculateReturnRate(5,100)は「いつ」「何回」読んでも 必ず5を返す。
10. コード例 副作⽤を含むコード • 外部I/O(外部書き込み)と例外の副作⽤を持つ • 呼ぶ度にDBを書き換える
11. 1. 純粋関数(の割合)を増やす 2. 副作⽤を”分離”する 副作用をゼロにするのは 不可能なので ⽅針
12. 第2部 TypeScriptと型の限界
13. TypeScript TypeScriptという⾔語 型システムが豊かで様々な表現ができる • JavaScriptのスーパーセット ◦ JavaScriptに型を追加した • 構造的型付け • Union型 / 交差型 / リテラル型 etc...
14. TypeScriptの限界 限界もある 両⽅とも(x: number) => number という同じ型
15. TypeScriptの限界 TypeScriptには IO 型がない 純粋関数と副作⽤を持つ関数を 型レベルで区別できない
16. TypeScriptの限界 言語 純粋関数 副作用を持つ関数 Haskell Int -> Int Int -> IO Int Scala A => B A => IO[B] TypeScript (x: number) => number (x: number) => number 多⾔語との⽐較
17. TypeScriptの限界 TypeScriptには モジュール境界を⾔語レベルで 強制する仕組みがない e.g. Javaのpackage
18. TypeScriptの限界 制約があるなかで 関数型の考えを TypeScriptに どのように持ち込むか
19. 第3部 解決方法: FCISについて
20. ⽅針1 TypeScriptの”⽊⽬”に沿って解決する 木を彫るとき、木目に逆らうと手間がかかる 言語思想(木目)に逆らわないことが長期的な保守性につ ながる TypeScript の⾔語思想には逆らわず 副作⽤と純粋関数を分離する
21. ⽅針2 FCIS(Functional Core, Imperative Shell) https://javiergonzalez.io/blog/functional-core-imperative-shell/ Functional Core: 純粋関数 Imperative Shell: I/O、副作⽤、外界 純粋関数を中に、副作用は端に
22. FCISとは I/O -> 純粋関数 -> I/O https://youtu.be/GYCofVVDaok?si=GWN1mbrkYtD49O4s&t=3428
23. 事例 今⽇紹介する2つの事例 Result 型でエラーを 値として扱う FCISを ディレクトリ構造で実現 1 2
24. 第4部 Result 型でエラーを 値として扱う
25. 何が起きていたか 既存プロダクトのバリデーション • ユーザーがフォームを定義できる ◦ Google Formのようなもの • フォームの種類でバリデーションが20種類近く • 判定ロジック、エラー判定フラグ、 dispatch が密結合 • 誰も⼿をつけられない状態
26. 何が起きていたか
27. 何が起きていたか 問題点 • 判定ロジックと副作⽤が密結合 • フラグ変数での状態管理 ◦ isValidatedを数百⾏追い続ける • テストにモックと巨⼤な params が必要 1つの関数の中に副作用と 純粋な計算が混ざり合っていた
28. アプローチ 純粋関数を増やし、副作⽤を端に追い出す 1. 「Result型」でエラーの場合も”値”で返す a. バリデーションロジックを切り出す 2. 副作⽤は端(最初や最後)に置く
29. Result型とは エラーを throw せず成功/失敗を型で表す
30. Result型とは Result型の特徴 • エラーを throw せず、「値」として返す • バリデーションロジックを純粋関数として書ける • 「失敗しうる」ことが型シグネチャに現れる Result<Email, ValidationError> のように 成功時と失敗時の型が現れる
31. 1. 純粋関数を増やせた
32. 解決策2 副作⽤を端に押し出す ⼊⼒ バリデータ 失敗抽出 dispatch 結果 • ⻘ = Functional Core：Result 型を返す純粋関数 • ⾚ = Imperative Shell：副作⽤はここだけ
33. 副作⽤は最後に 純粋関数でエラーを集め、最後に副作⽤
34. 副作⽤は最後に 純粋関数でエラーを集め、最後に副作⽤
35. 全体像
36. テストはどう変わったか
37. 副作用の局在化 影響範囲の縮小 結果 得られたもの モック不要のテスト 3 バリデータが、モック不要で ユニットテスト可能 1 2 副作用がパイプラインの “端”にだけある 配列に1行足すだけで新し いバリデーションが増やせ る 変更が簡単
38. なぜライブラリを使わなかったか TypeScriptの"⽊⽬"に沿うと ⻑期(数年単位)でメリットがある ライブラリを使う • neverthrow, fp-ts • 独自の語彙の学習コスト ◦ .map / .andThen • 依存を抱える • TypeScriptの進化の恩恵を受 けづらい ｆff TypeScriptをそのまま活用する • 人の知識に依存しない • ライブラリに依存しない • 言語の進化に乗れる
39. 第5部 FCIS をディレクトリ構 造で実 現する
40. How なぜディレクトリで分けるのか • TypeScriptにはIO型がない • モジュール境界を⾔語レベルで強制する仕組みもない ◦ e.g. Javaのpackage ディレクトリ構造で 副作用が入らない場所と入る場所を分ける
41. How 配置と依存で守る 1. ディレクトリの配置を決める a. domain/ infrastructure/ usecase/ という3層構造 2. ディレクトリ間の依存関係を制限する a. domain/ から infrastructure/ や usecase/ への importを禁⽌ 3. domain層で呼べるものも制限 a. I/Oライブラリなどの呼び出しも制限
42. 全体像 配置と依存で守る
43. メリット この構造で得られるもの 1 モック不要のテスト 2 副作用の局在化 2 読みやすさ domain 層は 純粋関数だけになる 何をするところななのかが ディレクトリで一目でわか る domain 層は 純粋関数だけになる
44. 第5-a部 境界を強制する
45. • ディレクトリで分けただけでは意味がない • TypeScriptコンパイラは何も⾔わない • ⼈間のレビューで守る？ • AIがコードが書く時は？ ➡ 機械にチェックさせる なぜ強制するのか
46. How dependency-cruiser ファイルから別のファイルへのimportを パスのパターンで許可‧禁⽌するツール アーキテクチャのルールを 設定ファイルとしてコードでかける https://github.com/sverweij/dependency-cruiser
47. dependency-cruiserの設定例 domain/ から infrastructure/ や usecase/ へのimportを禁⽌
48. 違反したら何が起きるか どのファイルが、どのルールに違反して どこに依存しているかが一目でわかる。
49. Lefthookで強制する pre-commit, pushで必ず動くようにする https://github.com/evilmartians/lefthook
50. 第6部 まとめ
51. 2つのアプローチ アプローチ 1 アプローチ 2 背景 既存プロダクト 新規プロダクト 範囲 関数、パイプライン プロジェクト全体 アプローチ Result 型でエラーを値に ディレクトリで 層を分ける
52. まとめ FCIS: 純粋関数を中に、副作⽤は端に TypeScriptの⽊⽬に沿って3つの⽅法で実現した 1. 型で守る … Result 型でエラーを値に 2. 配置で守る … domain / infrastructure / server 3. 機械で守る … dependency-cruiser × pre-commit
53. 株式会社カミナシ https://kaminashi.jp