JavaScriptにおける関数型プログラミングの価値：複雑さとどう向き合うか

2025年11月27日のイベント「プロによる本気の攻略本『JavaScript/TypeScript実力強化書』 - FL#115」で発表した内容です。近年、関数型プログラミングへの注目が高まっています。JavaScript は関数型プログラミング専用の言語ではありませんが、「純粋関数」「イミュータブルなデータ」「関数合成」といった考え方を取り入れることで、コードをより局所的に理解し、複雑な処理にも向き合いやすくなります。
また、こうした関数型プログラミングのエッセンスが宣言的 UI の設計思想とどのようにつながっているのかを、コード例を交えながら解説します。

Transcript

1. JavaScriptにおける 関数型プログラミングの価値： 複雑さとどう向き合うか 株式会社Derail 代表 佐藤 遼平 (thesugar) プロによる本気の攻略本『JavaScript/TypeScript実力強化書』 - FL#115 2025/11/27
2. ・佐藤遼平（さとう りょうへい） ・X: @_thesugar_ （←前と後ろにアンダースコア） ・銀行でIT開発 → フリーランス → 　現在は法人化して活動（株式会社Derail） ・主にWebフロントエンドを担当 ・書籍では「JavaScriptで関数型プログラミング 　を理解する」という章を書いた 自己紹介 2
3. ・そもそも JavaScript で関数型プログラミングって・・・？ ・JavaScript は関数型プログラミング専用の言語ではない ・「JavaScriptで関数型プログラミングをする」というのを 　 ゴールにするのではなく、 　「JavaScriptでも関数型プログラミングの発想を取り入れることで 　　いいことがあるよ」という内容 今日の発表の位置付け 3
4. ・関数型プログラミングにおける重要な概念はいろいろあるけど… ・今日は特に以下の 3 つを強調したい 　1. 純粋関数 　2. イミュータブルなデータ 　3. 関数合成 強調したい関数型プログラミングの 3 つのエッセンス 4
5. ・同じ入力 → 同じ出力 ・外部状態に依存しない ・副作用を持たない → テストしやすい & 読みやすい 1. 純粋関数 5
6. 2. イミュータブルなデータ ・値を変更せず、新しい値を生成 ・「どこで変わったか」を追う必要がなくなる ・デバッグやロールバック、Undo が容易になる 6
7. 3. 関数合成 ・小さな純粋関数を組み合わせて 　処理を構築 ・依存関係が明確になる → 修正しやすい、テストしやすい 7
8. 1. 純粋関数 → 外部状態を読まない、外部状態を書き換えない。関数内部で完結。 2. イミュータブルなデータ → データ構造が後から書き換わらない。 　 ある時点のデータはその時点で固定される（その時点だけ考えればよい）。 3. 関数合成 → プログラムを意味単位で理解できる。 　 それぞれのステップは局所的に完結している。 局所性という軸 local reasoning（局所的推論）: 何かを理解しようとするときに、 　　　　　　　　　　　　　　それ以外のことを考えなくてよい状態 8
9. ・ユーザーの入力や操作、API 通信、 　時間経過など、外部世界との 　やり取り（副作用） が発生する 　→その結果、アプリ内部の「状態」が 　変化し、それが UI に影響する 　→「状態」と「副作用」の管理が、 　　 アプリの複雑さの源泉（のひとつ） アプリ開発の話…なぜ複雑になるのか 画⾯1 画⾯2 画⾯3 9
10. SICP 3.1 引用: "An object is said to “have state” if its behavior is influenced by its history." （あるオブジェクトの振る舞いが自身の履歴に影響されるとき、それは 「状態」を持つと言える） → ・銀行口座の例。 　 ・`withdraw 25` という、25ドル引き出す計算を行う際、その結果は 　　 過去の預け入れと引き出しの履歴に依存している（=状態を持っている）。 「状態」とは withdraw の計算は実行ごとに結果（返り値）が変わる（複雑）
 10 出典: Structure and Interpretation of Computer Programs (sicp) Harold Abelson, Gerald Jay Sussman, and Julie Sussman
11. 命令的UIと宣言的UI 命令的 UI ・“どうやって UI を変えるか 　 　(HOW)” を書く ・DOM への手続き的操作が中心 宣言的 UI ・“UI がどうあるべきか (WHAT)” 　を書く ・状態を渡すと UI が決まるモデル 11
12. ・状態更新と UI 更新ロジックが混在する 　→ボタンクリック→ count++ → DOM 更新のように一連の手続きが密結合 ・状態遷移がコード全体に散らばりがち →ある UI の変化がどこで行われているか追跡が必要。 ・UI の最終形がコードから読み取りづらい 　→ UI が手続きの履歴に依存するため、count = ◦ という状態だけでは 　　 （基本的には）UI を再現できない。 　　　　 　Point：UI がそのときどきの状態ではなく“履歴（どう変わったか）”に依存する 命令的 UI の課題 12
13. ・UI を `UI = f(state)` として表すモデル 　　すなわち UI は状態に対する純粋関数として記述される。 ・f は純粋関数として扱われる 　　同じ state → 同じ UI、レンダー中に副作用を起こさない ・state はイミュータブルな値として扱われる（スナップショット） 宣言的 UI: `UI = f(state)` 13
14. ・予測可能性とテストの容易さ 　→ある時点の state を見るだけで UI が確定する ・状態とロジックを分離できる 　→ロジック側は「state をどう遷移させるか」を担当、 　　UI 側は「state がどう見えるか」を担当 ・副作用を隔離できる：レンダー中は純粋関数として副作用を分離 　→ たとえば React は useEffect やイベントハンドラで副作用を実行 ・関数合成が効く 　→ UI の部分を小さな純粋関数として積み上げられる 14 宣言的 UI の恩恵
15. ・`handleClick` 関数の中身が `count++`（変数の直接変更）でなく 　`setCount(prev => prev+1)` だからイミュータブルと言われるが… ・学び始めの頃は 　正直ピンと来ていなかった state ってイミュータブルなの？ 15
16. ・ある state を入力として UI を作る ・state が変わったら、次の state を入力として UI を作り直す ・各瞬間（＝レンダーごと）に state はイミュータブル つまり UI = f(state) とは…？ +1ボタン カウント: 0 +1ボタン カウント: 1 +1ボタン カウント: 2 state count=0 count=1 count=2 作り直し 作り直し 16
17. ・UI（DOM / View）は 1 つを維持し続ける ・状態変数（count）はミュータブル ・開発者が書いた「命令」により UI が更新されていく ちなみに命令的 UI だと…？ +1ボタン カウント: ? count=0 count=1 count=2 ・・・ 画面は作り直されず、`count` という変数がミューテーション されていく（count: 0 → 1 → 2 → …） 17
18. あらためて比較 +1ボタン カウント: 0 +1ボタン カウント: 1 +1ボタン カウント: 2 state count=0 count=1 count=2 作り直し 作り直し +1ボタン カウント: ? count=0 count=1 count=2 ・・・ 宣言的 UI ・UI：毎回 “新しく生成される” 　　（イミュータブル的） ・状態：スナップショットとして扱われる　　　 （イミュータブルなstate） 命令的 UI ・UI：同じ DOM をミュータブルに 　　　書き換え続ける ・状態：ミュータブルに変化していく変数 局所的に考えられる 18
19. ステートってイミュータブルなの？の疑問に対して +1ボタン カウント: 0 +1ボタン カウント: 1 +1ボタン カウント: 2 state count=0 count=1 count=2 作り直し 作り直し +1ボタン カウント: ? count=0 count=1 count=2 ・・・ 宣言的 UI ・命令的UIで出てきたミュータブルな「単一のス トア」としての状態は存在する ・それを、イミュータブルなスナップショットの 列（state_t, state_{t+1}, ...）としてモデル化して いる 命令的 UI ・状態：ミュータブルな「単一のストア」 19
20. ・関数型プログラミングで強調したいポイント： 　① 純粋関数、② イミュータブル、③ 関数の合成 ・いずれも局所性を高めることで問題の複雑さに対処する考え方と言える ・状態とは「プログラムの振る舞いを決める可変情報」であり、 　これがアプリケーションの複雑さにつながる ・命令的コードでは状態の更新と UI ロジックが混在するため、局所性が失われやすい ・一方、宣言的 UI では `UI = f(state)`という形に変換し、 　ミュータブルな状態をレンダーごとのイミュータブルなスナップショット列として 　扱うことで、局所性を回復している ・そしてその背景には、純粋関数・イミュータブル・合成可能性といった 　関数型プログラミングの原則が働いている まとめ 20 ご清聴ありがとうございました！ X: @_thesugar_ フォローお願いします！