Cloudflare Workersで動かしているサイトやAPIで、ログに出たエラーの行番号がビルド後のコードを指していて、元のソースのどこか分からない。Wranglerの4.150.0からは、この不便が設定なしで解消されます。その代わり、デプロイのたびに元のソースコードを含むファイルがCloudflareへ送られるようになりました。
Wranglerは、Cloudflare Workersのビルドとデプロイに使う公式のCLIです。2026年10月13日にnpmで公開された4.150.0の変更履歴には、次の変更が「Minor Changes」として載っています。
Upload source maps by default for
wrangler deploy,wrangler versions uploadandwrangler preview
この記事では、変更履歴の原文と、編集部の検証環境で4.149.0と4.150.0のアップロード内容を比べた結果をもとに、Workersでサイトや業務システムを運用する担当者が版上げの前に確かめておくことを整理します。
何が変わったのか
ソースマップは、ビルド後のJavaScriptと元のソース（TypeScriptなど）の位置を対応づけるファイルです。Cloudflareに送っておくと、ログや wrangler tail に出るエラーの位置が、元のソースの行で表示されます。
これまでは、設定ファイルの upload_source_maps を true にした場合だけ送られていました。4.150.0からの扱いは、変更履歴によると次のとおりです。
| 設定 | 4.150.0での動き |
|---|---|
| 指定なし | ソースマップを作って送る。解決できないもの（インラインの data: 形式、独自のビルドで .map がないなど）は飛ばして、アップロードは失敗させない |
upload_source_maps = true | これまでどおり厳格に扱う |
upload_source_maps = false、または --no-upload-source-maps | 送らない（--no-upload-source-maps は deploy と versions upload で使える） |
対象のコマンドは wrangler deploy・wrangler versions upload・wrangler preview です。実験機能の wrangler build --experimental-cf-build-output は4.150.0では変わらず、upload_source_maps = true のときだけソースマップを含めていました。ただし翌日（2026年10月14日）公開の4.151.0で、こちらも既定で含めるように変わりました（upload_source_maps = false で止められます）。10月19日時点のnpmの最新版は4.151.1です。
4.149.0と4.150.0で、送られる中身を比べた
編集部では、検証用の小さなWorker（TypeScriptで書いた数行の関数。upload_source_maps は指定しない）を用意し、WranglerのAPIの送り先をローカルのスタブ（Cloudflare APIの代わりに決まった応答を返し、届いた内容を記録する検証用のサーバー）に向けて、wrangler versions upload を実行しました。実際のCloudflareのアカウントには接続していません。
| 条件 | アップロードに含まれたファイル |
|---|---|
| 4.149.0、指定なし | index.js のみ |
| 4.150.0、指定なし | index.js と index.js.map（application/source-map） |
4.150.0、--no-upload-source-maps | index.js のみ |
4.150.0、"upload_source_maps": false | index.js のみ |
4.150.0で送られた index.js.map を開くと、sourcesContent に元の src/index.ts の全文が、型の注釈も含めてそのまま入っていました。ソースマップには、位置の対応だけでなく元のコードそのものが含まれうる、ということです。
Wranglerのコード（npmで公開された wrangler-dist/cli.js）でも違いを確かめられます。4.149.0では「uploadSourceMaps が真のときだけ読み込む」、4.150.0では「false のとき以外は読み込み、true のときだけ厳格に扱う」という条件に変わっています。
送ってよいかを判断する
ここからは編集部の整理です。ソースマップを送ると、本番のエラーを元のコードの行で追えるため、障害の調査は速くなります。一方で、元のコードがCloudflareの側に保存されることになります。Cloudflareのドキュメント（Source maps and stack traces、2026年10月12日更新）によると、送ったソースマップは、Workerで捕捉されなかった例外が起きたときにスタックトレース（エラーが起きるまでの関数の呼び出し経路）を元のコードの行に置き換えるために使われ、その結果はリアルタイムログ、Tail Workers、Workers Issuesで見られます。Workerの実行中にコードからソースマップを読むことはできず、サイズの上限はgzip圧縮後で15MBです。保持期間や、アカウント内の誰が中身を見られるかは、ドキュメントに書かれていません。また、このドキュメントは10月19日時点でまだ「upload_source_maps を true にすると送る」という以前の書き方のままで、既定の変更を反映する修正は準備中です。
次のどれかに当てはまる場合は、版上げの前に送るかどうかを決めておきます。
- 受託案件で、ソースコードの保管場所や第三者への提供について、契約や発注元の規程に決まりがある
- コードの中に、本来は書くべきでない情報（社内のURL、テスト用の認証情報、コメントに残した顧客名など）が残っている可能性がある
- 社内のセキュリティの規程で、外部サービスに送ってよい情報の範囲が決まっている
2つ目に当てはまる場合は、ソースマップを止めるより先に、コードからその情報を取り除くのが本筋です。ビルド後の index.js も同じくCloudflareへ送られているためです。Viteなど独自のビルドで .map を出力する場合は、ドキュメントにあるとおり、サーバー側のソースマップを静的アセット（公開ファイル）のディレクトリに置かないようにします。そこに置くと、Cloudflareへの送信とは別に、誰でもダウンロードできる状態になりえます。npmのパッケージにソースマップを入れて公開し、元のコードが読める状態になった事例は、Claude Codeソース流出事故から学ぶで取り上げています。今回の変更は公開範囲の話ではありませんが、ソースマップに何が入るかを知っておく点は共通です。
版上げの前に確認すること
package.jsonの指定を確かめる。"wrangler": "^4.x"のような範囲指定でロックファイルを更新すると、意図せず4.150.0以降が入ります。版を固定している場合は、上げるときに確認します- 方針を設定ファイルに書く。 送るなら
"upload_source_maps": true（解決できないソースマップがあるとアップロードが失敗する厳格な扱い）、送らないならfalseをwrangler.jsonc（またはwrangler.toml）に明記します。既定の動きに任せず、方針をレビューできる形で残せます - CIのデプロイも同じ設定か確かめる。 CIで
--upload-source-mapsなどのフラグを付けている場合は、設定ファイルとの関係を見直します - Cloudflareの新しいCLIへの移行と分けて考える。 4.150.0では、Cloudflareの新しいCLI（
cf）でビルドした出力（.cloudflare/output）が残っているプロジェクトで、wrangler deployなどが止まるようにもなりました。cfへの移行はCloudflareの新CLI「cf」ベータで整理しています
制作会社や外部の開発者にWorkersの操作を任せる場合の権限の分け方は、Cloudflare Workers、制作会社にはWorker単位で権限をを参照してください。
確認した範囲
2026年10月17日に、Wranglerの変更履歴（cloudflare/workers-sdk リポジトリの
packages/wrangler/CHANGELOG.mdの4.150.0）と、npmに公開されたwranglerの公開日時を確認しました（資料調査）。10月19日に、変更履歴（4.151.0・4.151.1を含む）、npm、Cloudflareのソースマップのドキュメントを開き直し、4.151.0でのwrangler build --experimental-cf-build-outputの変更と、ドキュメントの記載を追記しました。あわせて、編集部の検証環境（Linux、Node.js v22.22.0、wrangler4.149.0と4.150.0）で、検証用のWorkerをwrangler versions uploadでローカルのスタブへアップロードし、送られたファイルとソースマップの中身を確認しました（実機検証）。wrangler deployとwrangler previewでの送信、実際のCloudflareのアカウントへのアップロード、Cloudflare上でのソースマップの保存・表示、Workers Buildsなどのビルド環境での動きは確認していません。
Cloudflare Workersで動かすサイトやAPIの運用・デプロイの見直しは、開発・AI・自動化のご相談からお問い合わせください。
