RPC メソッドが投げたエラー、またはメソッドが返した Promise を拒否したエラーは、呼び出し側へ新しいエラーオブジェクトとして伝播します。拡張エラーシリアライズでは、実効的な name と message、およびシリアライズ可能な独自プロパティを保持します。列挙不可のプロパティ（cause ↗ など）も含みます。
拡張エラーシリアライズ は、enhanced_error_serialization 互換性フラグを使います。互換日が 2026-04-21 以降なら既定で有効です。それより前の互換日では、RPC の提供側と利用側の両方にフラグを追加します。オプトアウトするには legacy_error_serialization を使います。拡張エラーシリアライズがない場合、RPC はレガシーなエラー再構築を使い、カスタムの独自プロパティは保持しません。
提供側は、エラーとその独自プロパティ値をシリアライズできる必要があります。公開するエラープロパティは小さく、シリアライズ可能なものにしてください。独自プロパティにシリアライズできない値が入っていると、拡張エラーの詳細が利用側に届くことは保証されません。
利用側では、エラーのシリアライズ可能なフィールドを RPC 契約として扱います。Workers は次のものを保持・保証しません。
- 元オブジェクトの同一性、カスタムプロトタイプ、コンストラクタ
instanceofチェックの結果。とくにカスタムエラークラス- プロトタイプメソッドやプロパティディスクリプタ
- 提供側の元のスタックトレース。利用側では、エラー再構築による新しいスタックが見えることがあります
- シリアライズできないプロパティ値
たとえば、ProviderError extends Error のインスタンスは、name が "ProviderError" で、code などのシリアライズ可能な独自フィールド付きで届くことがあります。ただし、利用側の ProviderError クラスのインスタンスではありません。クラスの同一性に頼らず、name や code など文書化されたフィールドを確認してください。
一部のリモート例外では、ランタイムが伝播した例外にプロパティを追加することがあります。リトライや Durable Object のメタデータなどです。これらは提供側のカスタムプロパティとは別です。詳細は Durable Object のエラーハンドリング を参照してください。