型安全なエラー処理の基盤にEffect-TSが選ばれる理由｜fp-tsとの違い

TypeScript でアプリケーションが育ってくると、エラー処理が最初に破綻しやすい箇所になります。try-catch で囲んだ範囲から何が投げられるのかは型に現れず、catch (e) の e は unknown か any のまま扱われます。関数シグネチャを読んでも「この処理は何で失敗しうるのか」が分からないため、障害対応のたびに実装を遡ることになります。

対策として型付きエラー（Result 型・Either 型）を導入したい、という話にはなりやすいものです。ただ候補を並べてみると、Result<T, E> だけを足す最小構成のライブラリから、依存注入や並行処理まで含めてアプリ全体の設計に踏み込むものまで選択肢の幅が広く、どのスコープを選ぶべきかの判断材料が揃いません。

この領域で選択肢として挙がるのが、GitHub の Effect-TS/effect です。公式のブランド表記は「Effect」で、npm のパッケージ名も effect ですが、日本語圏では GitHub 組織名由来の「Effect-TS」という呼称でも流通しています（本記事では以降、リポジトリ・ライブラリ全体を指す場合に Effect-TS と Effect を併用します）。型付きエラーだけでなく、依存注入・構造化並行処理・観測性までを Effect<Success, Error, Requirements> という 1 つの型に載せる設計を取っており、2026 年 10 月時点では 4.x が LTS（長期サポート）リリースとして提供されています。

本記事では、公式 README・公式ドキュメント・公式ブログと、gh api で取得したリポジトリメタデータの範囲で、以下の 3 点を短時間で判断できるように整理します。

• Effect-TS が何を解決するライブラリで、Effect 型がどう機能するのか
• fp-ts / neverthrow とのスコープの違いと、選定時に見るべき軸
• 4.x の LTS 方針・ランタイム要件から見た、長期運用プロダクトへの採用可否

なお本記事はドキュメントベースの調査記事です。執筆時点で Effect-TS のインストール・実行・ベンチマークの再現は行っておらず、記載する内容はすべて公式ソースからの引用と整理に基づきます。

Effect-TSとは｜TypeScriptの型安全なエラー処理を担うOSS

Effect-TS は、公式 README の表現では「robust, maintainable, type-safe, and production grade applications in TypeScript」を構築するためのライブラリです。リポジトリの description は Build production-ready applications in TypeScript で、公式サイトは effect.website にあります。

公式ドキュメントの Introduction では、コンセプトとして「One ecosystem. Zero dependencies.」が掲げられています（出典: Effect 公式ドキュメント Introduction）。単機能のユーティリティ集ではなく、アプリケーションのランタイムに関わる関心事をひとつのエコシステムとして揃える方向性のライブラリ、という位置づけになります。

Effect-TSが扱う6つの領域

公式ドキュメントの Introduction では、Effect が解決対象とする領域が次の 6 つとして整理されています（出典: Effect 公式ドキュメント Introduction）。

型付きエラーだけを目的に探していた場合、この一覧は「必要以上に広い」と映るかもしれません。逆に、エラー経路と依存関係と並行処理を別々のライブラリで組み合わせている状況であれば、同じ語彙で揃えられる点が利点になります。この広さをどう評価するかが、後述する fp-ts / neverthrow との選定の分かれ目になります。

リポジトリの基本情報とライセンス

執筆時点のリポジトリメタデータは次のとおりです（出典: gh api /repos/Effect-TS/effect の 2026 年 10 月 7 日時点の取得値）。

スター数・フォーク数は変動するため、最新値は リポジトリ本体で確認してください。採用判断の観点で押さえておきたいのは次の 3 点です。

• アーカイブされていない（archived=false）: 開発が終了したリポジトリではなく、最終 push も取得時点の同日です
• フォークではない（fork=false）: 本家リポジトリであり、上流との差分を気にする必要がありません
• MIT ライセンス: ライセンス未設定のリポジトリではないため、商用利用・改変・再配布の条件が明確です

リポジトリは 2019 年 11 月に作成されており、モノレポとしてコアの effect パッケージと統合パッケージ群が管理されています。GitHub 上の topics にも error-handling / dependency-injection / concurrency / observability / schema / opentelemetry といった語が並び、先述の 6 領域と対応しています。

Effect型の仕組み｜成功値・エラー・依存関係を1つの型に載せる

Effect-TS を理解する上で中心になるのが Effect 型です。公式ドキュメントでは、Effect 型を「遅延実行される（lazily executed）ワークフローや操作の記述」と定義しています（出典: The Effect Type）。値を作った時点では何も起きず、ランタイムに渡した時点で実行される、という設計です。

Effect<Success, Error, Requirements>が表すもの

Effect 型は 3 つの型パラメータを取ります。

Effect<Success, Error, Requirements>

（出典: The Effect Type）

Result<T, E> 型との差は、第 3 パラメータの Requirements にあります。Result 型は「成功値とエラー」の 2 つを型に載せますが、Effect 型は「この処理を実行するには何が必要か」までを型に載せます。依存注入が型システム側で表現されるため、依存の差し替えやテスト時のモック置き換えが型チェックの対象になります。

一方で、これは関数のシグネチャにアプリケーション構造の情報が乗ることでもあります。局所的に 1 関数だけ型付きエラーにしたい、という目的に対しては過剰になりやすい設計です。

最初のコード例（Effect.genとEffect.runPromise）

公式の Onboarding ページには、最初のプログラムとして次のコードが掲載されています。

import { Effect } from "effect"

const program = Effect.gen(function* () {
  const name = yield* Effect.succeed("world")
  yield* Effect.log("Hello, " + name + "!")
})

Effect.runPromise(program)

（出典: Effect 公式ドキュメント Onboarding。公式原文からの抜粋であり、改変していません）

Effect.gen はジェネレータ関数を使って Effect を組み立てる構文で、yield* が async/await の await に相当する位置を占めます。program を定義した時点ではログは出力されず、Effect.runPromise に渡した時点で実行されます。公式の Onboarding では学習パスが「理念の理解 → プロジェクトセットアップ → 最初のプログラム → エラーハンドリング → 並行処理」の 5 段階として示されており、導入時の学習順序の目安になります。

型から成功値・エラー・依存を取り出す

Effect 型に載った 3 つの情報は、型レベルで個別に取り出せます。公式ドキュメントには次の例が掲載されています。

import { Effect, Context } from "effect"

class SomeContext extends Context.Service<SomeContext, {}>()("SomeContext") {}

declare const program: Effect.Effect<number, Error, SomeContext>

type A = Effect.Success<typeof program>  // number
type E = Effect.Error<typeof program>    // Error
type R = Effect.Services<typeof program> // SomeContext

（出典: The Effect Type。公式原文からの抜粋であり、改変していません）

Effect.Error でエラー型だけを取り出せるという性質は、「この処理は何で失敗しうるのか」をコードから追えるようにしたいという最初の課題に直接応える部分です。エラー型がユニオンとして型に現れるため、新しいエラーを足した側ではなく、受け取って処理する側で網羅性の漏れを型チェックが指摘します。

Effect-TSとfp-ts・neverthrowの違い｜選定の判断軸

型安全なエラー処理のライブラリを探すと、Effect-TS 以外に fp-ts と neverthrow が候補として挙がります。この 3 つは「どれが優れているか」ではなく「どのスコープを採用するか」で分かれます。

3ライブラリのスコープ比較

まず各リポジトリの状態を揃えて見比べます（いずれも gh api による 2026 年 10 月 7 日時点の取得値）。

機能範囲と対象領域を整理すると次のようになります。

エラー処理の型安全化だけが目的で、既存コードに段階的に入れたいのであれば neverthrow のスコープで足ります。逆に、エラー経路と依存関係と並行処理を同じ語彙で統制したい場合に Effect-TS のスコープが噛み合います。fp-ts については、後述するとおり Effect-TS エコシステムへの統合が公式に表明されているため、新規採用の比較軸ではなく「既存 fp-ts コードベースの移行検討」として読むのが実態に合います。

neverthrowとの具体的な書き方の違い

Effect の公式ドキュメントには neverthrow との比較ページが用意されており、移行を検討する際の観点が列挙されています（出典: Effect vs neverthrow）。

ただしこの比較ページは v3 向けのドキュメントです。ページ上部のバージョンセレクタは v3 が選択された状態で、サイドバーのリンクも /docs/v3/ 配下を指します。執筆時点では v4 側に同等の比較ページは用意されておらず、/docs/v4/additional-resources/effect-vs-neverthrow/ は 404 を返します。本記事は 4.x を前提にしているため、以下では比較の観点を v3 のページから引きつつ、API 名は v4 のドキュメントで確認できた表記に合わせて示します。

比較の読み替えで影響が大きいのは、型付きエラーを表すデータ型の名称です。v3 で Either と呼ばれていた型は、v4 では Result になっています。v4 のドキュメントでは「Result<A, E> は Success または Failure のいずれかを表す」と説明され、生成は Result.succeed / Result.fail、パターンマッチは Result.match を使う例が掲載されています（出典: Result（v4 ドキュメント））。

import { Result } from "effect"

const foo = Result.succeed(42)

const message = Result.match(foo, {
  onFailure: (failure) => `The failure value is: ${failure}`,
  onSuccess: (success) => `The Success value is: ${success}`,
})

console.log(message)

（出典: Result（v4 ドキュメント）。公式原文からの抜粋であり、改変していません）

これを踏まえて、公式が挙げている差分を整理すると次のようになります。

• API スタイル: neverthrow はインスタンスメソッド（result.map(...)）、Effect は関数スタイルの API と pipe 構文を使います。後者は未使用コードがバンドルから落ちやすく、ツリーシェイキングに有利とされています（v3 比較ページの記載）
• 値の生成: neverthrow の ok(value) / err(error) に対し、v3 比較ページでは Either.right(value) / Either.left(error) が示されています。v4 では Result.succeed(value) / Result.fail(error) が相当します
• パターンマッチ: neverthrow は引数 2 つの .match(onSuccess, onFailure)、Effect はハンドラを名前付きのオブジェクトで渡します（v3 は Either.match({ onLeft, onRight })、v4 は Result.match(result, { onFailure, onSuccess })）
• 非同期の合成: Effect では Promise を Effect.andThen のようなコンビネータに渡すと自動的に Effect に持ち上げられます。ただし Promise が reject した場合は UnknownException に変換され、エラー型が広がる点が v3 比較ページで明示されています
• ジェネレータ: neverthrow の safeTry(function* () { ... }) に対し、Effect ではジェネレータ構文を使います（v3 は Either.gen、v4 は Result.gen。非同期はいずれも Effect.gen）。Effect.gen ではジェネレータの戻り値がそのまま Success になるため、最終値を Effect.succeed で包む必要がありません
• エラーを成功チャネルに移す操作: v3 の Effect.either に相当する API は、v4 では Effect.result として整理されています（出典: Expected Errors（v4 ドキュメント））

実務上の判断材料として重みがあるのは「非同期の合成」です。既存の Promise ベースのコードを Effect に取り込む際、reject が UnknownException として入ってくるため、せっかく絞ったエラー型が広がります。既存コードとの境界をどこに置き、どこで UnknownException を自前のエラー型に変換するかは、移行計画を立てる段階で決めておく論点になります。

なお、比較ページ自体が v3 前提である以上、v4 で導入する場合は API 名・挙動の両方を v4 のドキュメントで確認してください。上記のように型名・関数名が変わっている箇所があるため、v3 向けの記事やサンプルコードをそのまま 4.x に持ち込むと型エラーになります。

fp-tsとの関係｜関数型の基盤かアプリ全体のランタイムか

fp-ts は description が Functional programming in TypeScript で、型クラスやモナドといった関数型プログラミングの抽象を TypeScript で使えるようにするツールキットです。Either や Option といったデータ型は提供しますが、依存注入のランタイム・並行処理のスケジューラ・観測性といったアプリケーション側の仕組みは対象外です。

この 2 つの関係は、二次情報で推測するまでもなく fp-ts 側の一次情報で明示されています。fp-ts の README には「fp-ts is officially merging with the Effect-TS ecosystem.」と記載され、さらに「Effect-TS can be regarded as the successor to fp-ts v2 and embodies what would be considered fp-ts v3.」と続きます。つまり fp-ts は Effect-TS エコシステムへ統合される方針であり、Effect-TS が fp-ts v2 の後継（fp-ts v3 に相当する位置づけ）として公式に案内されているということです。README では、この統合を「より堅牢で型安全かつスケーラブルな関数型プログラミングに向けた機能統合」と位置づけています。

Effect-TS 側も、関数型の語彙を内部に持ちながらスキーマ検証（Schema）や関数型ユーティリティをモノレポに内包し、ランタイム側まで揃えています。fp-ts でカバーしていた領域と用途が重なるのは、両者が別系統で発展した結果ではなく、後継として引き継ぐ関係にあるためです。

この事実は、新規採用と既存コードベースで意味が変わります。

• 新規に関数型の基盤を選ぶ場合: fp-ts を起点に選ぶ理由は薄くなります。後継として案内されている Effect-TS を評価対象にするのが素直です
• 既に fp-ts を使っているコードベースの場合: 「いずれ移行先を検討する」前提で考える材料になります。ただし移行は自動ではないため、fp-ts のリポジトリの更新状況と、自プロジェクトが依存している API の範囲（Either / Option だけなのか、型クラスの抽象まで使っているのか）を棚卸しした上で、移行規模を見積もる順序が安全です

移行の難所になりやすいのは命名の変更です。先述のとおり、v3 の Either に相当する型は v4 では Result になっています。fp-ts の Either を広く使っているコードベースでは、型名・関数名の対応付けを先に整理しておくと見積もりの精度が上がります。

RxJS・Zodとの重なりをどう捉えるか

検索の過程で RxJS や Zod が候補に挙がることもありますが、これらは Effect-TS と置き換え関係にはありません。

UI のイベント合成が主な関心事なら RxJS、API 境界のバリデーションだけが課題なら Zod のスコープで足ります。Effect-TS の採用を検討する動機は、これらを個別に組み合わせた結果として生じる「エラー経路と依存関係が型に現れない」問題を解消したい場合に生まれます。

Effect 4.0のLTSとパフォーマンス｜メンテナンス健全性の見方

長期運用するプロダクトにライブラリを入れる場合、機能よりもサポート方針のほうが重い判断材料になります。Effect-TS はこの点を README と公式ブログで明文化しています。

4.xのLTS方針とサポート期間

README の冒頭には、Effect 4.x が LTS（long-term support）リリースであることと、3.x からの移行は MIGRATION.md を参照する旨が明記されています。LTS の内容は次のとおりです（出典: README の Long-term support 節）。

• 最低 3 年間のサポート（バグ修正・セキュリティ修正を含む）
• 次のメジャーリリースから 1 年間はバグ修正を継続
• 次のメジャーリリースから 2 年間はセキュリティ修正を継続
• 安定 API の破壊的変更はメジャーリリースに限定。unstable とマークされた API はマイナーで、experimental な API はパッチで変わりうる

公式ブログではさらに具体的な期限が示されており、バグ修正は 2029 年 9 月まで（または 5.0 リリースの 1 年後のいずれか遅い方）、セキュリティ修正は 2029 年 9 月まで（または 5.0 リリースの 2 年後のいずれか遅い方）とされています（出典: Effect 4.0 リリースブログ）。

採用判断の観点で重要なのは、期限が年月で明示されていることと、「安定 API の破壊的変更はメジャーに限る」という線引きがあることです。unstable / experimental マークの API を使う場合はマイナー・パッチでの変更を受け入れる前提になるため、プロダクションコードでどの API を使うかの線引きをチーム内で決めておく必要があります。

v4で公表されたパフォーマンス・バンドルサイズの改善

公式ブログの Effect 4.0 リリース記事には、3.x からの改善として次の数値が掲載されています（出典: Effect 4.0 リリースブログ）。

同記事では、コアがゼロ依存設計でサードパーティの依存チェーンを持たないこと、複数パッケージを effect に統合して単一バージョンで運用できるようにしたことも挙げられています。採用状況としては、2026 年 9 月 21 日の週で週間 npm ダウンロード 43.9M、ダウンロードのうち 4.x が 56%、3.x が 44% という数値が記載されています。

これらはいずれも公式ブログの記載値であり、前掲のスター数などの gh api 取得値とは別系統の情報です。バンドルサイズやスループットは計測条件に依存するため、自プロジェクトの要件に照らして評価する場合は、リリース記事に記載されている計測の前提を確認してください。

v3からの移行と並行メンテナンス体制

バージョン移行の観点では、次の 2 点が README に記載されています。

• 3.x から 4.x への移行手順は MIGRATION.md にまとめられている
• v3 のソースは v3 ブランチで維持され、v3 向けの issue / PR は同ブランチが対象になる

既に 3.x を使っているコードベースにとっては、「移行ガイドが用意されている」ことと「旧メジャーのブランチが残っている」ことの両方が確認できる状態です。新規に採用する場合は 4.x を前提にすればよく、移行コストの論点は発生しません。

導入前に確認する前提条件とエコシステムの広さ

Effect-TS は TypeScript の型システムに強く依存する設計のため、ランタイムとコンパイラのバージョン要件が明示されています。採用可否を判断する前に、この条件を自プロジェクトと突き合わせるのが最短です。

TypeScript・Node.jsのバージョン要件とstrict必須という前提

README の Requirements 節には次の条件が記載されています（出典: Effect-TS/effect README）。

実務上のブロッカーになりやすいのは strict の要件です。strict が無効なレガシーコードベースでは、Effect-TS の導入前に strict 化そのものが先行タスクとして発生します。この順序が見えていないまま導入を決めると、想定よりも作業範囲が広がります。

インストール自体は npm パッケージ 1 つで始められます。

npm install effect

（出典: Effect-TS/effect README。公式原文からの抜粋であり、改変していません）

統合パッケージのカテゴリ（Platform / SQL / AI / UIバインディング / 観測性・テスト）

リポジトリはモノレポ構成で、コアの effect と統合パッケージ群がバージョン同期でリリースされます。パッケージ数は 30 本以上あるため、ここではカテゴリと代表例に絞って整理します（出典: Effect-TS/effect README）。

この構成は、採用の粒度を選べることを意味します。コアの effect だけを入れて型付きエラーと依存注入から始める段階的な採用も、OpenTelemetry 連携やデータベースアクセスまで含めて標準を揃える採用も、同じエコシステム内で選択できます。ただし統合パッケージごとにランタイム要件が異なるため、使う予定のパッケージについては個別に要件を確認する必要があります。

Effect-TSの採用が向くプロジェクト・向かないプロジェクト

ここまでに整理した事実から、採用判断の軸を条件の形で並べます。どちらが優れているかではなく、自プロジェクトに揃っている条件がどちらに近いかで判断する材料として読んでください。

採用が噛み合いやすい条件

• 長期運用が前提で、エラー経路・依存関係・並行処理を型で統制したい: Effect<Success, Error, Requirements> によって 3 つの関心事が同じ型に載るため、関数シグネチャだけで失敗条件と必要な依存が追えます
• 観測性やスキーマ検証まで含めて標準を揃えたい: OpenTelemetry 連携や Schema がエコシステム内にあるため、個別ライブラリの組み合わせで生じる接続部分の設計を減らせます
• strict が有効な新規コードベースである: 前提条件を満たしているため、導入の前段タスクが発生しません
• LTS の期限が明示されたライブラリを選びたい: バグ修正・セキュリティ修正の期限が年月で公開されており、サポート終了のリスクを見積もれます
• MIT ライセンスで商用利用の条件を明確にしたい: ライセンスが設定済みで、商用利用・改変・再配布の条件が確認できます

段階導入または他の選択肢を検討したい条件

• 既存コードに局所的に型付きエラーだけ入れたい: neverthrow のように Result<T, E> に絞ったライブラリのほうがスコープが合います。関数単位の置き換えで済み、アプリケーション全体の構造に影響しません
• TypeScript 5.9 未満、または strict が未適用: Effect-TS の導入前に TypeScript のアップグレードまたは strict 化が先行タスクになります。この作業量を見積もってから判断する順序が安全です
• Node.js のバージョンを上げられない: コアは Node.js 18 以降が下限ですが、使いたい統合パッケージがより新しいランタイムを要求する場合があります
• 関数型の語彙を持ち込む学習コストを今は払えない: Effect.gen の yield* や Either.match の書き方はチーム全体の学習対象になります。短期のデリバリー優先局面では、最小構成のライブラリから始めて後から範囲を広げる段階的な進め方も選択肢になります
• 既存の Promise ベースコードとの境界が広い: reject が UnknownException に変換されてエラー型が広がるため、境界での変換方針を決めずに入れるとエラー型を絞り込めません

執筆時点でリポジトリは archived=false / fork=false / disabled=false の状態にあり、最終 push も 2026 年 10 月 7 日と直近です（出典: gh api /repos/Effect-TS/effect の取得値）。メンテナンス状況の観点では、採用可能な状態が維持されていると判断できます。

情報源の確認先

採用判断を進める際の一次情報は次の場所に集まっています。

• 概念の理解から最初のプログラムまでは公式サイト effect.website の Onboarding
• 型の意味と API の詳細は公式ドキュメント
• 他ライブラリとの比較は公式ドキュメントの比較ページ
• 質問・相談は README に記載されている Discord と Community Hub。商用の導入支援は公式の adoption partners ページで案内されています

まとめ

本記事では、TypeScript で型安全なエラー処理の基盤を検討する際の候補として Effect-TS/effect を取り上げ、公式ドキュメント・README・公式ブログとリポジトリメタデータの範囲で以下を整理しました。

• 仕組み: Effect<Success, Error, Requirements> という 1 つの型に成功値・エラー・必要な依存を載せる設計で、型付きエラー・依存注入・構造化並行処理・リソース管理・観測性・データパイプラインの 6 領域をひとつのエコシステムとして扱う
• fp-ts / neverthrow との違い: neverthrow は Result<T, E> に絞った最小構成で局所導入に向く。fp-ts は関数型の抽象を提供する基盤ライブラリだが、README で Effect-TS エコシステムへの統合が表明され、Effect-TS が fp-ts v2 の後継（fp-ts v3 相当）と位置づけられている。そのため fp-ts との比較は「新規にどちらを選ぶか」ではなく「既存 fp-ts コードベースをどう移行するか」の論点になる
• メンテナンス健全性: 4.x が LTS リリースで、バグ修正・セキュリティ修正の期限が年月で明示されている。3.x からの移行ガイドがあり、v3 ブランチも維持されている
• 導入前の確認事項: TypeScript 5.9 以降（7 推奨）・Node.js 18 以降・strict 有効が前提。統合パッケージによってはより新しいランタイムを要求する

採用可否は「エラー処理だけを型安全にしたいのか、エラー・依存・並行処理を同じ語彙で統制したいのか」で分かれます。前者であれば最小構成のライブラリで足り、後者であれば Effect-TS のスコープが噛み合います。判断材料が揃った段階で、自プロジェクトの TypeScript バージョン・strict 設定・チームの学習コスト許容度と照合してください。

関連情報

TypeScript での型安全な設計方針の策定や、既存システムのエラー処理・保守性の改善をご検討中の方は、お問い合わせフォーム からご相談ください。要件の整理段階からご相談いただけます。