概要
https://zenn.dev/jtechjapan_pub/articles/c11c81bae36746
詳細内容
## LLM時代のライブラリ設計、LLMが書きやすいものにした方が良いので泣く泣く方針転換した
https://zenn.dev/jtechjapan_pub/articles/c11c81bae36746
著者は、LLMがコードを生成しやすいように、自身のC#イベントソーシングフレームワーク「Sekiban」の設計において、理想としていたRailway Oriented Programmingから、言語の「木目」に沿ったより一般的なスタイルへと方針転換した経験を詳述しています。
**Content Type**: 💭 Opinion & Commentary
**Language**: ja
**Scores**: Signal:4/5 | Depth:4/5 | Unique:4/5 | Practical:4/5 | Anti-Hype:4/5
**Main Journal**: 80/100 | **Annex Potential**: 80/100 | **Overall**: 80/100
**Topics**: [[LLM時代のライブラリ設計, Railway Oriented Programming, イベントソーシング, C#, チーム開発とLLM]]
J-Tech Creationsのtomohisa氏は、自身が開発するC#イベントソーシング/CQRSフレームワーク「Sekiban」のライブラリ設計において、LLMのコード生成効率を考慮し、当初の理想としていたRailway Oriented Programming（ROP）から方針転換した経緯を語ります。
著者は、例外処理を型システムで表現し、正常系と異常系を明示的に分離できるROPの明確さを評価し、小規模プロジェクトで成功体験を積んでいました。しかし、Sekibanのような大規模なライブラリ設計において、二つの大きな課題に直面します。一つは、チーム開発におけるメンバー間のパラダイム理解のギャップ。もう一つは、GitHub CopilotなどのLLMがROPのパターンを理解せず、従来の`try-catch`ブロックによるエラー処理に回帰してしまう点でした。LLMにROPの「書き方」を教え込むコストが極めて高いと著者は指摘します。
この課題に対し、著者はプログラミングパラダイムに関するScott Wlaschin氏の「言語の木目（grain of the language）に沿う」という考え方に着想を得ます。新しいパラダイム（イベントソーシング）を導入する際には、一度に一つの大きな変化に集中し、他の要素は言語の慣習に沿うべきだという原則に基づき、LLMが理解しやすく、C#の「木目」に沿った設計へと変更を決断しました。
具体的には、ライブラリを`WithResult`と`WithoutResult`の二つに分離。ユーザーが直接利用する`WithResult`側は、LLMが扱いやすいよう、エラー処理をより一般的なC#のスタイルに寄せることで、コード量よりも明確さを優先しました。これにより、LLMが効率的にコードを生成できるだけでなく、チームメンバー間の理解促進にも繋がったと説明します。
著者はこの経験から、技術選択は理想だけでなく、チームやLLMといった現実的なコンテキストで決定されるべきであること、言語の慣習を尊重すること、そしてLLM時代におけるフレームワーク設計の柔軟性の重要性を強調しています。今後のSekibanは、LLM視点での明確さと記述しやすさを最優先し、言語選択においてもこの視点を取り入れる方針です。