こんにちは、現場の最前線でオブザーバビリティの構築に心血を注いでいるシニアアーキテクトです。
日々、モダンなフロントエンド開発に励む皆さんは、「本番環境でエラーが起きたけれど、難読化（Minify）されたコードのせいで、どこで何が起きたかさっぱりわからない……」という絶望を味わったことはありませんか？
そんな暗闇に光を差すのが、エラートラッキングツールRollbarと、そのSourcemaps APIです。これらを正しく使いこなせば、本番のエラー箇所をローカルの開発環境さながらに、TypeScriptの元の行数で特定できます。
今回は、特に難易度の高い「モノレポ（TurborepoやNxなど）での複数環境設定」に焦点を当て、設定の神髄を優しく、かつ徹底的に解説します。これをマスターすれば、あなたのデバッグ作業は劇的に楽になりますよ。
—
1. なぜ「Sourcemapの自動アップロード」が不可欠なのか
通常、WebpackやViteでビルドされたJavaScriptは、パフォーマンスのために圧縮・難読化されます。エラーが発生した際、ブラウザからRollbarに送られるスタックトレースは、この「圧縮後」の状態です。
RollbarにSourcemap（ソースマップ）を事前に渡しておくと、Rollbarが裏側で「圧縮後のn行目」を「元のソースコードのm行目」に翻訳してくれます。
しかし、手動でアップロードするのは現実的ではありません。
- ビルドのたびに中身が変わる
- モノレポだと複数のパッケージでパスが混在する
- 環境（Staging / Production）ごとに異なるマップが必要
これらを解決するために、ビルドプロセスの中で自動的にRollbarへマップを転送する設定が必要不可欠なのです。
—
2. 土台を作る：Rollbar Webpack Pluginの導入
まずは、ビルド成果物をRollbarへ紐付けるための武器を揃えましょう。今回はWebpackを例に説明しますが、Vite（Rollup）でも考え方は同じです。
インストール
Webpackを使用しているパッケージのディレクトリで実行
npm install –save-dev @rollbar/webpack-plugin
—
3. 【最重要】モノレポにおける「紐付け」の黄金法則
モノレポ環境で最も多い失敗は、「Rollbarに送られたエラー情報」と「アップロードしたソースマップ」のバージョンやパスが一致しないことです。
これを防ぐための3つの神器を設定しましょう。
1. Code Version: Gitのコミットハッシュ（SHA）を使用する。
2. Public Path: ブラウザでロードされるJSの完全なURLを指定する。
3. Access Token: 「post_client_item」ではなく、アップロード用の「post_server_item」トークンを使う。
Webpack設定の極意（`webpack.config.js`）
モノレポ内の各アプリで使い回せる、堅牢な設定例をご覧ください。
const RollbarSourceMapPlugin = require(‘@rollbar/webpack-plugin’);
const { execSync } = require(‘child_process’);
// 現在のGitのコミットハッシュを取得（これが最強のバージョン管理になります）
const GIT_VERSION = execSync(‘git rev-parse HEAD’).toString().trim();
module.exports = {
// …省略（他のビルド設定）
devtool: ‘hidden-source-map’, // ソースマップを生成するが、ブラウザには公開しない設定
plugins: [
new RollbarSourceMapPlugin({
// Rollbarのプロジェクト設定 > Access Tokens > post_server_item のトークンを使用
accessToken: process.env.ROLLBAR_SERVER_TOKEN,
// エラー発生時のバージョンと完全に一致させる
version: GIT_VERSION,
// 重要：ブラウザから見えるJSのURLのベース
// 例: https://static.example.com/assets/
publicPath: `https://${process.env.CDN_DOMAIN}/assets/`,
// モノレポの場合、ビルド済みのファイルがどこにあるかを正確に伝える
// Turborepo等の場合は dist や build フォルダを指定
include: [‘./dist’],
// 環境ごとにタグ付けを変える（production / staging）
// Rollbar上で環境をフィルタリングするのに役立ちます
ignoreErrors: false,
silent: false, // 最初のうちはfalseにして、アップロード成功を確認しましょう
}),
],
};
—
4. クライアント側（React/Next.jsなど）の初期化
ビルド時にマップを上げただけでは不十分です。アプリが動く際にも「私はこのバージョンのコードですよ！」とRollbarに自己紹介させる必要があります。
import Rollbar from ‘rollbar’;
// 環境変数から情報を取得（モノレポなら .env ファイルで管理）
const rollbarConfig = {
accessToken: process.env.NEXT_PUBLIC_ROLLBAR_CLIENT_TOKEN,
captureUncaught: true,
captureUnhandledRejections: true,
payload: {
// 【重要】Webpack Pluginで指定した version と完全に一致させること！
code_version: process.env.NEXT_PUBLIC_GIT_SHA,
environment: process.env.NEXT_PUBLIC_ENV, // production, staging 等
},
};
const rollbar = new Rollbar(rollbarConfig);
—
5. 精度を高めるための「プロの知恵」
① 環境変数差異の防ぎ方
モノレポでは、`apps/web` と `apps/admin` で環境変数が混ざりがちです。ビルドスクリプト（`package.json`）で明示的に環境を指定する癖をつけましょう。
{
“scripts”: {
“build:prod”: “export NODE_ENV=production && turbo run build”
}
}
② `server.root` の設定
Rollbarのダッシュボードで見づらい場合、プロジェクト設定の「Source Control」でリポジトリのルートパスを設定してください。これにより、スタックトレースから直接GitHubのコードへジャンプできるようになります。
—
6. 「Hello World」的動作確認の儀式
設定が終わったら、本当に紐付いているか確認しましょう。これが成功すれば、あなたの設定は完璧です。
1. ビルドを実行: `npm run build` を行い、コンソールに `Rollbar: Source map upload completed successfully` と出るか確認します。
2. デプロイ: 実際にホスティング先に上げます。
3. 故意にエラーを起こす:
// どこかのボタンのクリックイベントなどに忍ばせる
const triggerError = () => {
throw new Error(“Rollbar Test: Sourcemap Linking Success!”);
};
4. Rollbarを確認:
- エラー詳細を開きます。
- 「Minified」ではなく、あなたの書いたオリジナルのコード（TypeScriptなど）が表示されていますか？
- もし表示されていなければ、Rollbar画面上の「Source Map status」をチェックしてください。バージョン名やURLの不一致が指摘されているはずです。
—
最後に
オブザーバビリティ（可観測性）の第一歩は、「今、何が起きているかを正しく知る」ことです。
モノレポという複雑な構造の中でも、このRollbar Sourcemapsの設定を一度カチッと決めてしまえば、バグ調査の時間は10分の1に短縮されます。それは、あなたがより創造的な開発に集中できる時間が増えることを意味します。
もし設定で迷ったら、「`code_version` は一致しているか？」「`publicPath` はブラウザのURLと同じか？」という2点に立ち返ってください。
あなたのエンジニアライフが、この設定一つでより快適になることを願っています。頑張ってくださいね！