npmパッケージ公開時のソースコード漏洩を防ぐ方法

2026年3月のClaude Code事件から学ぶ、npmパッケージ公開時にソースコードが意図せず公開されるリスクと、.npmignoreとfilesフィールドを使った確実な防止策を解説します。

あなたのnpmパッケージ、ソースコードが丸見えになっていませんか？

開発者の皆さん、こんな不安を抱えていませんか？

• npmパッケージを公開する際、本当に必要なファイルだけが含まれているか確信が持てない
• ソースマップファイルに元のコードが含まれていることは知っているが、対策が曖昧
• .gitignoreと.npmignoreの違いがよくわからない
• 公開前にどのファイルが含まれるか確認する方法を知らない

2026年3月31日、Anthropicが開発するClaude Codeのnpmパッケージにおいて、意図しないソースコード漏洩が発生しました。原因は.npmignoreの設定漏れで、57MBのcli.js.mapファイルに全ソースコードが含まれていたのです。

この事件は、私たち開発者にとって重要な教訓となりました。「誰でも起こりうるヒューマンエラー」だからこそ、確実な防止策を講じる必要があります。

なぜnpmパッケージにソースコードが含まれてしまうのか

ソースマップとは何か

まず、今回の問題の核心であるソースマップについて理解しましょう。

ソースマップ（.mapファイル）は、ビルド後のコードと元のソースコードの対応表です。TypeScriptをJavaScriptにコンパイルした際や、webpackで圧縮した際に生成されます。

{
  "version": 3,
  "sources": ["src/main.ts", "src/utils.ts"],
  "sourcesContent": [
    "// src/main.ts の完全なソースコード",
    "// src/utils.ts の完全なソースコード"
  ],
  "mappings": "AAAA,OAAO..."
}

重要なのはsourcesContentの部分です。ここに元のソースコード全文が格納されているため、.mapファイルが公開されると、事実上すべてのソースコードが公開されることになります。

npmパッケージに含まれる仕組み

npm packはデフォルトで、プロジェクト内のほぼすべてのファイルを含めます。多くの開発者が勘違いしているのは、「.gitignoreで除外しているから大丈夫」という思い込みです。

実際には：

• .gitignoreは Git の管理対象から除外するファイルを指定
• .npmignoreは npm パッケージから除外するファイルを指定
• この2つは完全に別物

典型的な問題パターンは以下のとおりです：

project/
├── src/           # .gitignoreで除外
├── dist/          # .gitignoreで除外、ビルド後にここに出力
│   ├── main.js
│   └── main.js.map  # ← これが公開されてしまう
├── .gitignore
└── package.json

.gitignoreではdist/ディレクトリ全体を除外していますが、npm publishする前にビルドを実行すると、distディレクトリが作成されます。この時点で.npmignoreの設定がなければ、ソースマップも含めてすべてが公開されてしまいます。

防止策1: .npmignoreを正しく設定する

.npmignoreファイルをプロジェクトルートに作成し、以下の内容を記述します：

# ソースコード
src/

# ソースマップ
*.map

# テストファイル
__tests__/
*.test.js
*.test.ts
*.spec.js
*.spec.ts

# 設定ファイル
.env
.env.*
tsconfig.json
jest.config.js
vite.config.js
webpack.config.js

# 開発用ファイル
.eslintrc.*
.prettierrc
.gitignore
.gitattributes

# ドキュメント（必要に応じて）
docs/
examples/

# その他
node_modules/
.DS_Store
Thumbs.db

特に重要なのは*.mapの指定です。これにより、すべてのソースマップファイルが除外されます。

防止策2: package.jsonのfilesフィールドを使う（推奨）

.npmignoreよりも安全で確実な方法が、package.jsonのfilesフィールドを使ったホワイトリスト方式です：

{
  "name": "my-package",
  "version": "1.0.0",
  "files": [
    "dist/",
    "!dist/*.map",
    "README.md",
    "LICENSE"
  ],
  "main": "dist/index.js",
  "types": "dist/index.d.ts"
}

この方法の利点：

• 明示的: 含めるファイルを明確に指定
• 安全: 指定していないファイルは絶対に含まれない
• わかりやすい: チーム開発で意図が伝わりやすい

!dist/*.mapの記述により、distディレクトリを含めつつ、その中の.mapファイルは確実に除外できます。

防止策3: 公開前の確認方法

npm pack --dry-run

実際にパッケージを作成せず、含まれるファイルの一覧を確認できます：

npm pack --dry-run

出力例：

npm notice === Tarball Contents ===
npm notice 1.2kB LICENSE
npm notice 2.1kB README.md
npm notice 15.7kB dist/index.js
npm notice 891B dist/index.d.ts
npm notice === Tarball Details ===
npm notice name: my-package
npm notice version: 1.0.0
npm notice total files: 4

この出力に.mapファイルが含まれていないことを確認します。

npx publint

publintは npm パッケージの品質をチェックするツールです：

npx publint

潜在的な問題を検出し、改善提案を表示してくれます。

自動チェックスクリプト

package.jsonにチェック用のスクリプトを追加することをお勧めします：

{
  "scripts": {
    "prepublishOnly": "npm run check-package",
    "check-package": "npm pack --dry-run | grep -q '\.map' && echo 'ERROR: Source maps found!' && exit 1 || echo 'OK: No source maps found'"
  }
}

これにより、npm publish実行前に自動的にチェックが走ります。

防止策4: ビルド設定でソースマップを制御する

TypeScript設定

tsconfig.jsonで環境に応じたソースマップ生成を制御：

{
  "compilerOptions": {
    "sourceMap": false,
    "declaration": true,
    "declarationMap": false
  }
}

本番用ビルドではsourceMap: falseに設定します。

Vite設定

// vite.config.js
import { defineConfig } from 'vite'

export default defineConfig({
  build: {
    sourcemap: false, // 本番ビルドでソースマップを無効化
    lib: {
      entry: 'src/index.ts',
      name: 'MyLib',
      fileName: 'index'
    }
  }
})

webpack設定

// webpack.config.js
module.exports = {
  mode: 'production',
  devtool: false, // ソースマップを生成しない
  // その他の設定...
}

よくある失敗パターンと対処法

パターン1: 開発時にソースマップが必要

問題: デバッグのためソースマップが必要だが、公開時は除外したい

解決策: 環境変数で切り替える

{
  "scripts": {
    "build": "tsc",
    "build:dev": "tsc --sourceMap",
    "build:prod": "tsc --sourceMap false",
    "prepublishOnly": "npm run build:prod"
  }
}

パターン2: TypeScript宣言ファイルのソースマップ

問題: .d.ts.mapファイルも公開してしまう

解決策: declarationMapを無効化

{
  "compilerOptions": {
    "declaration": true,
    "declarationMap": false
  }
}

パターン3: モノレポでの設定漏れ

問題: 複数パッケージがあるモノレポで、一部のパッケージの設定を忘れる

解決策: 共通設定をテンプレート化

# ルートディレクトリに共通の.npmignore.templateを作成
cp .npmignore.template packages/*/npmignore

CI/CDに組み込む自動チェック

継続的な安全性確保のため、CI/CDパイプラインにチェック機能を組み込みます：

# .github/workflows/publish.yml
name: Publish Package

on:
  release:
    types: [published]

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '18'
          registry-url: 'https://registry.npmjs.org'
      
      - name: Install dependencies
        run: npm ci
      
      - name: Build
        run: npm run build:prod
      
      - name: Check for source maps
        run: |
          if npm pack --dry-run 2>&1 | grep -q '\.map'; then
            echo "ERROR: Source map files detected in package!"
            npm pack --dry-run 2>&1 | grep '\.map'
            exit 1
          fi
          echo "OK: No source map files found"
      
      - name: Publish
        run: npm publish
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

業界での実践例

大手ライブラリの対応

人気の高いnpmパッケージはどのように対策しているのでしょうか：

効果の測定

適切な設定による効果を数値で見てみましょう：

今すぐ実践すべき対策フロー

以下の手順で、あなたのプロジェクトを今すぐ安全にできます：

まとめ

npmパッケージ公開時のソースコード漏洩は、設定ミスによる「うっかり事故」です。しかし、一度公開してしまったファイルは取り消すことができません。

重要なポイントを再度確認しましょう：

1. ソースマップにはすべてのソースコードが含まれている
2. .gitignoreと.npmignoreは別物
3. filesフィールドによるホワイトリスト方式が最も安全
4. 公開前の確認は必須
5. CI/CDでの自動チェックで継続的な安全性を確保

Claude Codeの事件は明日は我が身です。この記事で紹介した対策を今すぐ実装し、安全なパッケージ公開を心がけましょう。