こんにちは！TechBowl の梶川(@kajitack)です。
この記事は、2026 年 1 月 9 日〜10 日に開催された BuriKaigi 2026 の登壇レポートです。
参加レポートは こちら です。
登壇内容
「例外処理とどう使い分けるか？ Result 型を使ったエラー設計」というタイトルで登壇させていただきました。
今回の登壇では、例外（try-catch）を用いる言語のプロジェクトに Result 型や関数合成による RailwayOrientedProgramming(ROP) を取り入れる設計方法を紹介しました。
Result 型 とは、処理の成功と失敗を型で表現するパターンです。例えば、決済処理の結果を Result<Payment, PaymentError> のように型で表現することで、「カード期限切れ」「残高不足」「不正検知」といった複数のエラーケースを明示的に示せます。
例外（try-catch）では、どんなエラーが発生するか関数のシグネチャからは分かりません。一方、Result 型を使えば「この処理ではどのような失敗パターンがあるのか」を型定義から明確にできます。
RailwayOrientedProgramming(ROP) は、成功と失敗の処理を鉄道の線路のように並行して進めていく考え方です。成功の場合は成功の線路を、失敗の場合は失敗の線路を進み、途中でエラーが発生したら自動的に失敗の線路に切り替わります。これにより、複数の処理を連鎖させる際のエラーハンドリングがシンプルになります。
また、プロジェクトの特性や言語の特性に応じて、どちらを選ぶべきかという使い分けの指針も解説しました。
こちらは登壇してる様子です。
登壇の背景
前回の BuriKaigi 2025 でも例外処理をテーマに登壇しました。その時は例外処理の基礎的な話をしましたが、今回は「例外処理との使い分け・設計指針」にフォーカスしました。
「Result 型 vs 例外処理」という対立構造ではなく、エラーハンドリングの歴史を遡ることから始めました。
- なぜ例外処理が生まれたのか（エラーコードによる戻り値での管理から、例外による構造化されたエラー処理へ）
- その後、なぜ Result 型が生まれたのか（例外のコストや制御フローの複雑さを解決するため）
このような背景を理解することで、Result 型は例外処理を置き換えるものではなく、補完するもの（例：ビジネスロジックの失敗は Result 型、システムの異常は例外）であることがわかります。
そのうえで、実際のアプリケーション開発における具体的な設計方法を紹介しました。
実際にやってみると使い方に悩む場面が多いため、以下のような実践的なポイントを盛り込みました。
- ドメインモデリング（ビジネスルールをコードで表現する設計手法）によってロジックの違反を定義する方法
- ドメインレイヤー（ビジネスロジックを集約する層）での Result 型の活用方法
- 各レイヤー（プレゼンテーション層、アプリケーション層など）でのエラーハンドリングやバリデーションについて
登壇の振り返り
登壇資料を公開したところ、予想以上の反響をいただきました。
感想を書いてくださる方も多く、大変嬉しかったです。
また、懇親会でも多くの方と意見交換ができ、非常に有意義な時間を過ごせました。
登壇の中では PHP を実例にしましたが、懇親会では TypeScript や C#、Java など様々な言語で Result 型を導入している話や、導入を検討している方の悩みなどを聞くことができました。
色々な言語での悩みやチームでの導入事例など、様々なバックグラウンドを持つ方と交流できるのは BuriKaigi の醍醐味です。
ただし、言語を特定しない分、抽象度を上げたり、前提認識を合わせたりと、登壇準備が大変でした...!
おわりに
登壇を聞いてくださった皆さま、そして BuriKaigi 運営スタッフの皆さま、本当にありがとうございました！
地元の富山でこういったカンファレンスが盛り上がっているのは嬉しいです。自分が学生時代だった頃は技術コミュニティの地域格差をすごく感じてたので、登壇という形で貢献できて嬉しかったです。
ぜひ来年も参加して、旬のブリと技術トークを楽しみたいです！
Discussion