Article by: Sergiy Dybskiy
要約：Next.jsでTurbopackがデフォルトとなったため、バンドラーに依存しないようにSDKを再構築しました。その結果、コード量の削減、ビルドの高速化、そしてこれまでどおりのテレメトリーを実現しました。このブログでは、その過程を説明します。
何年もかけてツールを構築してきたのに、支えていたものが突然非推奨になり、アプローチ全体を見直さなければならなくなる。そんな経験はありますか？
そして念のためですが、これは Ralph Wiggum の話ではありません。私たちのコミュニティで合意してその名前で続けることにした、再帰エージェントプラクティスについての話でもありません。
これは、Next.js が Turbopack を展開し、Webpack を非推奨にしたこと（Next.js v16 からは Turbopack がデフォルトになっています）、SDK におけるテレメトリアプローチを見直したことについてです。
以前の状況
以前は next build を実行すると、Webpack ローダーがすべてのページ、API ルート、ミドルウェア、サーバーコンポーネントを横取りしていました。
このローダーは次のことを行っていました。
- ファイルを解析し、タイプを判定する
- Rollup を使用し、 Sentry ラッパーテンプレートとバンドルする
- 元のコードを計装済みのバージョンに置き換える
これはうまくいきました。しかし、それには6種類のラッパーテンプレート、360行の Webpack ローダー、約1,667行の計測コードを維持する必要がありました。Next.js の新機能が追加されるたびに、サーバーコンポーネントやルートハンドラー、App Routerといったものに対して新しいテンプレートを書く必要があり、Webpackの内部が最後に確認したときから変更されていないことを祈るしかありませんでした。
私たちは、すべてのファイルに「Sentryでラップされたドッペルゲンガー」が存在する並行世界を構築していました。こういったアーキテクチャはうまく機能する時には良いのですが、うまくいかなくなると、どの層が壊れたのかを追うのは至難です。
現在の取り組み
Next.js には、組み込みの OpenTelemetry 計装機能があります。これにより、すべてのリクエスト、ミドルウェアの実行、レンダー処理ごとにルート情報つきの スパン を出力します。コードをラップする代わりに、それを受け取るようにしています。
上のスニペットは「きれいなバージョン」です。実際には、標準の Next.js OTel 構成を Sentry 向けの要素（スパンプロセッサ、コンテキストマネージャーなど）で上書きし、HTTP インテグレーションをカスタマイズして、Next.js が生成する受信側の span を無効化しています。そうすることで、私たち自身でスパンをエンリッチできます。それでも、Rollup テンプレートを 6 つ維持するよりはシンプルです。
Turbopack 専用のコードは約164行で、Webpack 方式と比べて10分の1に削減されています。その大半は設定処理で、計装ロジックではありません。
ビルドへの実際の影響
Next.js SDKチームのエンジニアである Charly が、実際に Sentry Changelog リポジトリを対象にテストを行い、その違いを確認しました。
アプリケーションのコンパイル時に、SDKがすべてのファイルでRollupを実行することはなくなりました。next build に時間がかかる理由を不思議に思ったことがあるなら、その一部は私たちのせいでした。（すみません。）
SDKは、Turbopack と Webpack のどちらを使っているかを自動で検出し、それに応じて調整します。Next.js 15.4.1以降を使用している場合、Turbopackはそのまま動作します。Sentryで確認できるトレースデータの見え方も同じです。ルートハンドラ、ミドルウェア、サーバーコンポーネント、データフェッチ。すべて残っています。
変更点
Turbopackを使用する場合、いくつかのWebpack設定オプションは適用されなくなります。
特定のルートを計装から除外していた場合、SentryのbeforeSendTransactionフックでフィルタリングする必要があります。SDKはNext.jsのOpenTelemetry 計装に依存しているため、ビルド時にラップ処理がなく、そこからオプトアウトすることはできません。
Server Actions は引き続き手動での計装が必要です。
Server Actions は私たちがフックできるOTel スパンを発行しません。Next.js の動向を注視しており、テレメトリーが公開されれば、自動計装を追加する予定です。
コードベースを超えて重要な理由
すべてのAPMベンダーが独自のビルドプラグインやローダー、バンドラー統合を維持する代わりに、フレームワーク側が OpenTelemetry を標準テレメトリーインターフェースとしてOpenTelemetryを採用し始めています。Next.js はスパンを発行し、私たちはそれを取り込みます。フレームワークが「どのように」を担い、私たちは「どこに送るか」を担います。
これがフレームワーク計装の向かう先です。私たちはコードを増やすのではなく、削ることでそこにたどり着きました。
要件
- Turbopack の本番ビルドには Next.js 15.4.1 以上が必要
- ネイティブ Debug IDs には Next.js 15.6 以上が必要（ソースマップ解決が改善されます）
- instrumentation.ts / instrumentation-client.ts は変更不要
Next.js 16 では、Turbopack がデフォルトのバンドラーとなり、SDKも対応しています。
15か月にわたる「Turbopack: 未対応」から「Turbopack: デフォルト」への道のりは、19件のPR、アーキテクチャの全面的な見直し、そして新しいバンドラーをサポートする最良の方法が、バンドラーに依存しないことだという気づきに至りました。このアプローチが現在の Next.js SDKを支えています。
Original Page: Less code, faster builds, same telemetry: Turbopack support for the Next.js SDK
IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。
