Claude Code ソースコード流出の真相：npmとsource mapの落とし穴【2026年】

Claude Code ソースコード流出 という衝撃的な見出しがニュースを駆け抜けたのは2026年3月末のことです。「Anthropicがハックされた」「50万行のコードが盗まれた」と大きく報じられましたが、実態はやや異なります。Anthropic自身も「セキュリティ侵害ではなく、人的ミスによるリリース梱包の問題だった」と説明しています。（参照：The Register）

では「梱包ミス」がなぜここまで深刻なのか。その背景には、npmという配布経路の仕組みと、source mapという技術の特性があります。つまり、本記事ではこの2つを初心者向けに丁寧に解説しながら、Claude Codeを使い始めたばかりの方でも実践できる教訓を整理します。

なお、Claude Code の基本的な使い方については Claude Codeインストール方法と初期設定ガイド【2026年】 も合わせてご覧ください。

「Claude Codeがハックされた」は本当か？事件の全体像

何が起きたのか——50万行のコードが外部から見えた

2026年3月末、Claude Code のバージョン 2.1.88 のアップデートで、npm パッケージの中に本来含めるはずのなかった source map ファイルが同梱されていたことが外部研究者によって発見されました。The Vergeは、このファイルからTypeScriptのソースコード一式——50万行超・約1,900ファイル規模——が読める状態だったと報じています。（参照：The Verge）

読めてしまった内容には、通常の実装コードだけでなく、未公開機能の設計、「たまごっち型ペット」のような実験的機能、常駐エージェント的な構想なども含まれていたとされます。製品ロードマップや内部アーキテクチャが競合他社や攻撃者に見えてしまったことは、ビジネス上も深刻なリスクです。

Anthropicの公式見解：「セキュリティ侵害ではない」

Anthropicは、この件を「release packaging issue caused by human error（人的ミスによるリリース梱包の問題）」と説明し、外部からの侵入や認証情報の漏えいは一切ないと述べています。（参照：The Register）

さらに、Claude Code の作者 Boris Cherny は IT Pro の取材に対し、「本来自動化されるべきだった手動デプロイ手順があった」と認めています。（参照：IT Pro）

「侵入されて盗まれた」のではなく、「自分たちが配布した荷物に、意図せず設計図を入れてしまった」——これが今回の事件の本質です。

なぜ漏れたのか——npmとは何かから理解する

npmは「便利なインストール経路」ではなく「世界への配布経路」

npm（Node Package Manager）は、JavaScriptやNode.jsのソフトウェアをパッケージとして公開・配布・インストールするための仕組みです。npm install claude のように名前を指定するだけで、世界中のどのPCでもそのソフトウェアを入手できます。

💡 Node.jsとは：JavaScriptをブラウザ外（サーバー・CLIツールなど）で動かすための実行環境です。Claude Codeなどのコマンドラインツールの多くはNode.js上で動作します。

ここで大切な視点が1つあります。「インストールする側」として使うとき、npmは単なる便利ツールに見えます。一方で、ソフトウェアを作って公開する側の立場に立つと、npmは「自分のフォルダの中身を tarball にして世界へ配る操作」を意味します。

💡 tarballとは：複数のファイルを1つにまとめて圧縮したアーカイブファイル（.tar.gz 形式）のことです。npmパッケージは実際にはこの形式で配布されており、npm install 時に取得・展開されます。

（参照：npm公式ドキュメント npm-publish）

つまり、npm publish を実行した瞬間、指定されたファイル一式が誰でも取得できる状態でインターネット上に置かれます。「Gitにpushした」や「本番サーバーにデプロイした」とは別の、もう一つの公開経路がnpmにはあるのです。

公開内容を決める3つの設定（filesフィールド・.npmignore・.gitignore）

では、npmパッケージに「何が入るか」はどう決まるのでしょうか。npm公式ドキュメントによれば、主に次の3つによって決まります。（参照：npm公式ドキュメント package.json）

設定	役割	特徴
package.json の files フィールド	含めるファイルをallow-listで指定	未指定だとワイルドカード扱いになり広く含まれる
.npmignore	含めないファイルをblock-listで指定	書き漏らすと対象外になる
.gitignore	.npmignore がない場合の代替として参照	Git管理外のファイルは自動除外される場合あり

重要なのは、files フィールドを省略した場合、基本的には広い範囲のファイルが含まれる方向になる点です。npm公式は「your folder is pretty much exposed by default（フォルダの中身はデフォルトでほぼ公開された状態）」と直接的に警告しています。（参照：npm公式ドキュメント developers）

npm pack –dry-runで事前確認できる

実は、npmには公開前にパッケージの中身を確認できるコマンドが用意されています。

npm pack --dry-run

このコマンドを実行すると、実際に公開される tarball に含まれるファイル一覧が表示されます。意図しないファイルが含まれていないか確認できるため、公開前の必須チェックとして推奨されています。（参照：npm公式ドキュメント npm-pack）

今回の事件では、このチェックが自動化されていなかったことが原因の一つでした。

source mapとは何か——デバッグの味方が「源泉公開スイッチ」になる仕組み

TypeScript→JavaScriptの変換と「地図」の役割

TypeScriptで書かれたコードは、ブラウザやNode.jsで実行する前にJavaScriptに変換（コンパイル）されます。このとき、コードは圧縮・難読化されることが多く、変換後のJavaScriptを読んでもエラーの原因が分かりにくくなります。

💡 TypeScriptとは：Microsoftが開発したプログラミング言語で、JavaScriptに「型定義（変数の種類を明示する仕組み）」を追加したものです。大規模なプログラムを書くときにミスを減らせますが、ブラウザやNode.jsは直接実行できないため、コンパイル（別の言語形式への変換）が必要です。

💡 圧縮・難読化（ミニファイ）とは：JavaScriptの変数名を1文字に短縮したり、空白や改行を除去してファイルサイズを小さくする処理です。配信速度の向上が目的ですが、副作用として人間が読みにくくなります。エラーが起きても「どの行で何が起きたか」が分からなくなるため、source mapが必要になります。

そこで登場するのがsource mapです。MDNウェブドキュメントは、source mapを「minified or transformed code と original unmodified form の対応を持つJSON」と説明しています。（参照：MDNウェブドキュメント Source map）

わかりやすく言うと、source mapは「変換後コードと元コードを対応付ける地図ファイル」です。Chrome DevToolsなどのデバッガがこの地図を参照することで、圧縮・変換後のコードを実行中でも、元のTypeScriptの行番号でエラーを確認できるようになります。

sourcesContentとは何か——地図に元の設計図を貼り込む仕様

ここが今回の核心です。source mapの標準仕様（ECMA-426）では、sourcesContent というフィールドが定義されています。（参照：TC39 ECMA-426 Source map format specification）

sourcesContent には、元ソースコードの文字列そのものを埋め込めるのです。仕様上の用途は「元ファイルを別途ホスティングできない場合に、mapファイル単体でデバッグできるようにするため」ですが、裏を返せば——

source mapファイルを1つ取得するだけで、元のTypeScriptコード全体が読めてしまう可能性があります。

地図で例えるなら、「座標の対応表（地図）の余白に、元の設計図のコピーまで貼り付けてしまっていた」状態です。地図だけなら被害は限定的でも、設計図の本文まで入っていれば話は別です。

今回の技術的な流れ（図解）

今回の漏えいの技術的な流れを整理すると、以下のようになります。

1. ビルド段階: TypeScriptコンパイラが cli.js（実行ファイル）と cli.js.map（source map）を生成。sourcesContent に元TypeScriptが埋め込まれる
2. 梱包段階: .npmignore や files フィールドの設定漏れで、*.map ファイルがnpmパッケージに含まれてしまう
3. 公開段階: npm publish でパッケージが世界へ配布される
4. 発見段階: 外部研究者がパッケージを取得し、.map ファイルから元TypeScriptを読み出す
5. 拡大段階: 内部実装・未公開機能・設計思想が外部に公開された状態になる

The Vergeの報道では「source map file containing its TypeScript codebase（TypeScriptコードベースを含むsource mapファイル）」と表現されており、sourcesContent による元ソース内包が主な経路だったと見られます。（参照：The Verge）

なお、一部報道（Axios）では「map/デバッグファイルが外部ZIPアーカイブへの参照を含んでいた」とする説明もあり、経路の詳細については報道間で若干の差があります。少なくとも「source mapがnpmパッケージに誤って含まれたことが決定的なトリガーだった」という点は複数報道で一致しています。（参照：Axios）

初心者が学ぶべき3つの教訓

教訓1：「Gitに入っているか」ではなく「npmパッケージに入るか」で考える

プログラミングを始めると、「Gitに上げているものが公開されているもの」という感覚が自然と身につきます。しかしnpmを使う場合、公開経路はもう一つあります。

「Gitで管理していないから安全」は、npmでは通用しません。 npm tarball に入るかどうかを別で判断する必要があります。（参照：npm公式ドキュメント developers）

逆に、.gitignore に書いたファイルでも、.npmignore がない場合はnpmパッケージに入ってしまうことがあります。2つの「公開経路」を別々に意識して管理することが大切です。

教訓2：source mapはデバッグの道具——公開物に混ぜるな

source mapはローカル開発やCI環境でのデバッグに非常に便利なツールです。DevToolsでTypeScriptの元コードを確認できる恩恵は大きい。

💡 DevTools（開発者ツール）とは：ブラウザに内蔵されているデバッグ用パネルです。ChromeやEdgeでは F12 キー、macOSのSafariでは Option+Command+I で開けます。source mapがあると、DevToolsの「Sources」タブで圧縮前のTypeScriptコードを確認しながらデバッグできます。

💡 CI（継続的インテグレーション）とは：コードをGitにpushするたびに、テスト・ビルド・検査を自動で実行する仕組みです。GitHub Actionsはその代表的なサービスで、.github/workflows/ フォルダにYAMLファイルを置くだけで設定できます。「人が確認し忘れる」ミスを機械的に防ぐために使います。

しかし、公開npmパッケージ・CDN配信・フロントエンドの本番バンドルに *.map ファイルを含める場合は、sourcesContent の有無を必ず確認してください。sourcesContent が含まれていれば、そのmapファイルを入手した人は元ソースをほぼ再現できます。

まとめると：

• 社内ツール・開発環境: source map（sourcesContent含む）は有用で安全
• 公開npmパッケージ・CDN配信: *.map は除外するか、sourcesContent なしのmapのみ含める
• フロントエンド本番ビルド: 非公開コードを含む場合はmapを別ホストに置くか除外する

教訓3：人的ミスを責めても再発は防げない——自動化で設計する

Anthropicは「人的ミス」と説明しましたが、作者Boris Chernyの発言がより本質をついています。

“There was a manual deploy step that should have been better automated.”
（本来、もっとよく自動化されるべき手動のデプロイ手順があった）

— Boris Cherny, IT Pro（IT Proより）

「誰かが間違えた」ではなく「間違えられる手順が残っていた」——これは大きな違いです。手動チェックは、どんなに優秀な人でも疲労・急ぎ・見落としによって失敗します。そのため、重要なステップはCIで自動検査することで、人が介在する余地をなくすべきです。

Claude Codeを使い始めた方への実践的なアドバイスとして：「AIが書いてくれたコードをpublishする前に、自分でnpm pack –dry-runを実行してみる」習慣が身を守ります。AIは便利ですが、公開境界の設計は最終的に人間（あなた）が判断する必要があります。

💡 サプライチェーン（supply chain）リスクとは：自分が使うソフトウェアの依存関係・配布経路の連鎖を指します。たとえば「Aというツールをnpm installしたら、Aが依存しているBというパッケージに悪意あるコードが混入していた」という攻撃がサプライチェーン攻撃です。今回の事件はAnthropicが自ら配布した荷物に原因があったため攻撃とは異なりますが、「npm install するものは世界中の誰でも公開できるパッケージである」という認識は、利用者側にとっても重要な視点です。

実践的な再発防止策

package.jsonのfilesフィールドでallow-list管理

最も根本的な対策は、package.json の files フィールドを使って「含めるものだけを明示的に列挙する」allow-list方式で管理することです。具体的には、以下のように記述します。

💡 allow-list / block-listとは：セキュリティ設定の考え方の違いです。allow-list（ホワイトリスト）は「許可するものだけを列挙し、それ以外は全て拒否」する方式。block-list（ブラックリスト）は「禁止するものを列挙し、それ以外は全て許可」する方式です。npmの .npmignore はblock-list型なので、1つ書き漏らすだけで危険なファイルが含まれてしまいます。files フィールドによるallow-list型が安全な理由はここにあります。

{
  "name": "my-cli",
  "version": "1.0.0",
  "files": [
    "dist/",
    "bin/",
    "README.md"
  ]
}

この設定では、dist/・bin/・README.md だけがnpmパッケージに含まれます。*.map や *.ts は明示していないため自動的に除外されます。

.npmignore での除外（block-list方式）は、書き漏らしが致命的になります。今回のような事故を防ぐには、「デフォルトは何も含めない、含めるものだけ書く」allow-listが安全です。（参照：npm公式ドキュメント package.json）

CIでnpm pack –dry-runを検査する

GitHub ActionsなどのCIパイプラインに、以下のようなチェックを組み込むことで、意図しないファイルの混入を自動検知できます。

# CI（例：GitHub Actions）でのチェック例
npm pack --dry-run 2>&1 | grep -E "\.(map|ts|env|key|pem)$" && exit 1 || echo "OK"

このスクリプトは、npm pack --dry-run の出力に .map・.ts・.env などの拡張子が含まれていればCIを失敗させます。（参照：npm公式ドキュメント npm-pack）

source mapの用途別運用方針

source map自体は悪いものではありません。問題は「どこに置くか」です。TC39のECMA-426仕様では、source mapは sourceMappingURL コメントやHTTPヘッダで参照先を指定できます。（参照：TC39 ECMA-426）

実運用では次のような方針が考えられます：

• 開発・CI環境: フルのsource map（sourcesContent含む）を使う。デバッグ効率が最大化される
• 公開npmパッケージ: *.map は原則含めない。含める場合は sourcesContent を除いたmapのみ
• 本番フロントエンド（非公開コードあり）: mapを社内限定の別ホストに置き、本番CDN配信物には含めない

💡 CDN（コンテンツ配信ネットワーク）とは：世界各地のサーバーにファイルを分散配置し、利用者に近いサーバーから高速に配信する仕組みです。フロントエンドのJavaScriptファイルは多くの場合CDN経由で配信されます。CDNに置いたファイルは世界中から取得可能なため、.map ファイルをCDNに置くことはnpmに公開するのと同様の公開リスクがあります。

まとめ——「梱包ミス」が教えてくれたこと

Claude Codeのソースコード流出事件は、「AIの会社がハックされた」という話ではありませんでした。npmという公開配布経路と、source mapというデバッグツールが組み合わさって起きた、公開境界の設計ミスです。

初心者の方にとっての最大の学びは：

• npmはインストール経路である前に、配布（公開）経路です。何を配るかを意識して設計しましょう
• source mapはデバッグの強い味方ですが、sourcesContent があれば元ソース丸ごとになります。公開物への混入に注意しましょう
• 人的ミスは起きる前提で、自動検査で防ぐのが正しい設計です。npm pack --dry-run のCIチェックを今日から取り入れましょう

Claude Codeを使ってコードを書くのは素晴らしいことです。しかし、「AIが書いたコードを公開する前の確認責任」は常に人間側にあります。この事件が、あなたの「公開する前に確認する」習慣を育てるきっかけになれば幸いです。

Claude Code を使った開発の自動化に興味がある方は、CLAUDE.md 書き方完全ガイド も参考にしてください。CI設計と合わせて活用できます。

関連記事：Claude Code 関連記事一覧