ソースマップ（source map）とは？圧縮後コードのデバッグ

ソースマップとは何か

ソースマップ（source map）とは、圧縮や変換を経た後のコードと、元の読みやすいコードとの対応関係を記録したファイルです。一般に拡張子.mapで生成されます。

本番に配信するJavaScriptやCSSは、容量を減らすために空白や改行を削り、変数名を短くする「minify（圧縮）」が施されます。TypeScriptやSassのように、別の言語から変換（トランスパイル）されることもあります。

こうした処理の後のコードは人間には読みにくく、エラーが出た場所も特定しづらくなります。ソースマップがあれば、圧縮後の位置から元コードの行・列をたどれます。

ソースマップが解決する問題

圧縮されたコードでエラーが起きると、スタックトレースは「一行目の何文字目」のような形になり、元コードのどこかが分かりません。ソースマップはこのギャップを埋めます。

ブラウザの開発者ツールはソースマップを読み取り、圧縮後のファイルを開いても元のソースを表示してくれます。ブレークポイントを置いたり、エラー位置を元コードで確認したりできます。

つまりソースマップは「本番では圧縮・変換した軽いコードを配信しつつ、デバッグ時は元のコードで追える」という両立を可能にする仕組みです。

実務ではどこで関係する？

ソースマップは言葉の意味だけ覚えても、HTML共有の判断にはつながりません。実務では「表示に関係する話か」「検索に関係する話か」「アクセス制限に関係する話か」を分けて考えると整理しやすくなります。

ソースマップ（source map）について迷ったら、相手が安全に開けるか、検索に出してよいか、ブラウザや環境差で壊れないかを順番に確認します。用語理解は、その判断を早くするための道具として使います。手順が決まったら、HTML/ZIPをアップロードして共有URLを発行し、相手に確認してほしい観点と期限を添えて送ります。

• 表示の話: HTML/CSS/JS、パス、ブラウザ互換性を確認する
• 検索の話: noindex、canonical、sitemap、robots.txtの役割を分ける
• 制限の話: URL共有、パスワード、メール認証、会社ドメイン認証を混同しない
• 運用の話: 期限、差し替え、削除、共有メッセージまで決める

ソースマップの仕組み

ソースマップには、変換後の各位置が元のどのファイルの何行目・何列目に対応するか、という情報が圧縮された形で記録されています。

圧縮後のファイルの末尾に、対応するソースマップの場所を示すコメントが付くのが一般的です。ブラウザはこのコメントを手がかりにソースマップを読み込みます。

• 元ファイル名のリスト：どの元コードに対応するか
• マッピング情報：変換後と元コードの位置の対応
• 元のソース内容：必要に応じて元コードそのものを含められる
• 参照コメント：圧縮後ファイル末尾にマップの場所を示す

ソースマップを使う手順

ソースマップは、ビルドツールの設定で生成し、ブラウザに読み込ませて使います。基本の流れは次のとおりです。

1. ビルドツール（バンドラやコンパイラ）でソースマップ生成を有効にする
2. 圧縮後ファイルと一緒に.mapファイルを出力する
3. 圧縮後ファイル末尾の参照コメントを残しておく
4. ブラウザの開発者ツールでソースマップの利用を有効にする
5. エラー発生時に、元コードの行・列でエラー箇所を確認する

公開時の注意とソースマップの扱い

ソースマップには元のコードがそのまま含まれることがあります。一般公開のサイトにそのまま置くと、圧縮しても元のコードが読まれてしまう可能性があり、見せたくないロジックが露出することもあります。

そのため、本番では一般に公開せず、関係者だけがアクセスできる場所に置く、もしくは外部からは取得できないようにする運用が選ばれます。デバッグ用ビルドと本番用ビルドを分けるのも一つの方法です。

限られた関係者にだけソースマップ付きの確認ビルドを見せたい場合、ギガサイト便なら認証（URLのみ・パスワード・メール認証・会社ドメイン認証）を選んで共有でき、公開期限も設定できます。検索結果に出さないnoindexは付きますが、関係者以外に見せたくないときは認証を併用するのが安全です。