AnthropicでさえやらかすSource Map事故
2026年4月7日、InfoQが「Anthropic Accidentally Exposes Claude Code Source via npm Source Map File」と題する記事を公開しました。AnthropicがnpmレジストリにリリースしたClaude Code CLIのバージョン2.1.88に、TypeScriptのソースマップファイル（.js.map）が同梱されており、これを辿ることで元のTypeScriptソース全体が復元できてしまったという内容です。
Claude Codeは世界中の開発者が使うAIコーディングエージェントで、そのソースコードはAnthropicにとって競合優位の源泉でもあります。それが意図しない形で流出したインパクトは小さくありません。
しかも、原因は高度なゼロデイ攻撃でも、内部犯でもありません。ビルド設定のうっかりミスです。つまり、どの開発チームでも明日起きうる事故ということ。本記事では、この事件から学ぶべき5つの具体的な設定チェックを整理します。
そもそもSource Mapとは何か
Source Mapの役割
Source Mapは、圧縮・トランスパイルされたJavaScriptと、元のTypeScript（あるいは元のJavaScript）を対応付けるファイルです。
| ファイル | 内容 |
|---|---|
index.js | トランスパイル・minify後のコード |
index.js.map | 元のソースとの対応表（元のコード含む） |
index.ts | 元のTypeScript（通常は配布しない） |
ブラウザDevToolsで「圧縮されたコードではなく元のTypeScriptをデバッグできる」のはSource Mapのおかげです。開発体験を大きく向上させる反面、配布してしまうと元コードが丸見えになるのが怖いところです。
Source Mapから何が復元できるのか
.js.mapファイルは、通常sourcesContentフィールドに元のソースコード全文を埋め込んでいます。つまり、.js.mapを1つ入手するだけで、該当のTypeScriptファイルをそのまま復元できます。
事故の経緯
何が起きたのか
InfoQの報道によると、事故の流れは以下の通りです。
- Anthropicがnpmに
@anthropic/[email protected]を公開 - 公開パッケージに
*.js.mapファイルが含まれていた - 研究者がパッケージを展開し、
.js.mapから元のTypeScriptソースを復元 - ソースコードの一部がGitHubで公開される
- Anthropicは直後のバージョンでsource mapを除外して再公開
短時間で対応したものの、一度公開されたアーティファクトは取り戻せないのがnpmの宿命。すでに復元版が出回った後でした。
なぜ見逃されたのか
Anthropicほどのセキュリティ文化を持つ組織でもこの事故は起きました。考えられる原因は以下の通りです。
- ビルド設定で
sourceMap: trueがデフォルトだった .npmignoreでのマップファイル除外が漏れていたpackage.jsonのfilesフィールドで明示的に指定していなかった- CIパイプラインに公開前の差分チェックがなかった
- リリースビルドと開発ビルドで設定が共通化されていた
つまり、チェックすべきレイヤーは1つではないということです。
Source Map誤同梱を防ぐ5つのチェックリスト
① tsconfig.jsonでプロダクションビルドを分離
開発用とリリース用のtsconfigを分け、リリース用ではsourceMapとdeclarationMapを明示的にfalseにします。
// tsconfig.build.json（リリース用）
{
"extends": "./tsconfig.json",
"compilerOptions": {
"sourceMap": false,
"declarationMap": false,
"inlineSourceMap": false,
"inlineSources": false
},
"exclude": ["test", "**/*.test.ts"]
}ビルドコマンドで明示的にこのファイルを指定します。
npx tsc -p tsconfig.build.json② package.jsonのfilesフィールドでホワイトリスト方式に
.npmignoreのブラックリスト方式ではなく、package.jsonのfilesフィールドでホワイトリスト方式にするのが鉄則です。
{
"name": "your-package",
"files": [
"dist/**/*.js",
"dist/**/*.d.ts",
"README.md",
"LICENSE"
]
}ホワイトリストに*.js.mapを書かない限り、意図的に含めない限り同梱されません。
③ .npmignoreでダブルブロック
念のため、.npmignoreでもmapファイルを除外します。
# .npmignore
*.map
*.js.map
*.d.ts.map
src/
tsconfig*.json
*.test.tsホワイトリストとブラックリストの二段構えにすることで、ビルドツールの変更や設定漏れがあっても防御層が残ります。
④ 公開前ドライラン（npm pack）
リリース直前に、実際にパッケージに含まれるファイルを確認します。
# ドライラン（実際には公開しない）
npm pack --dry-run
# tarball化して中身を確認
npm pack
tar -tzf your-package-1.0.0.tgz | grep -E '\.map$'
# 何も出力されなければOKCIパイプラインに組み込み、mapファイルが見つかったらビルドを失敗させるようにします。
# GitHub Actions例
- name: Check for source map files
run: |
npm pack --dry-run 2>&1 | grep -E '\.map$' && exit 1 || exit 0⑤ npm publishの自動化パイプライン整備
手動でのnpm publishは人為ミスの温床です。リリース手順をGitHub Actions等で完全自動化し、以下のステップを必須にします。
- プロダクション用tsconfigでクリーンビルド
npm pack --dry-runで同梱ファイル確認- テストスイート実行
- セキュリティスキャン（依存関係・秘匿情報）
- タグ打ち → 自動publish
AIレビューを組み込むのも有効です。カウシェが実践するAIレビュー自動マージのような運用を参考に、セキュリティチェックの段階からAIを組み込むと、人為ミスを大幅に減らせます。
関連するセキュリティ観点
サプライチェーン攻撃との関連
npm配布物のセキュリティは、ソース流出だけでなく悪意あるコード混入の問題も抱えています。2026年はnpm・PyPI・RubyGemsへのサプライチェーン攻撃が急増しており、詳しくはSupply Chain攻撃2026で解説しています。
秘匿情報の配布事故
Source Mapに限らず、以下のようなファイルも絶対に配布してはいけないものとして意識すべきです。
| ファイル種別 | リスク |
|---|---|
.env, .env.local | APIキー流出 |
*.pem, *.key | 秘密鍵流出 |
test/fixtures/*.json | 個人情報テストデータ流出 |
.git/ | コミット履歴流出 |
package.jsonのホワイトリスト方式なら、これらも自然と除外されます。
まとめ
AnthropicのClaude Code source map流出事故は、どれだけセキュリティ意識が高い組織でも、ビルド設定1つの見落としで重大な事故になることを示す教訓事例です。
防御の要点は5つ。
- tsconfig.jsonでプロダクションビルドを分離し
sourceMap: falseを明示 - package.jsonの
filesフィールドでホワイトリスト化 .npmignoreで*.mapのダブルブロックnpm pack --dry-runによる公開前ドライラン- GitHub Actions等での完全自動化パイプライン
どれも数分〜数時間で導入できる設定ですが、全てを重ねるレイヤー防御が事故を止めます。Anthropicの事例を「他山の石」として、自社リポジトリの設定を今日のうちに点検しておくことをおすすめします。
AIコーディング全般のセキュリティ考察はWebセキュリティ基礎ガイドも併せてご確認ください。
参考ソース
