Claude Codeのソースコード51万行が流出。Anthropicに何が起きたのか
2026年04月02日

Claude Codeのソースコード51万行が流出。Anthropicに何が起きたのか

金曜の夜、ふと思い立ってClaude Codeのnpmパッケージを覗いてみた開発者がいた。
いつもなら難読化されたJavaScriptが並んでいるだけなのに、その日は違った。
ソースマップがまるごと残っている。たどっていくと、TypeScriptの元コードがずらり。
1,906ファイル、51万行。社内のフィーチャーフラグから未公開機能の名前まで、全部読める状態だった。
「これ、公開しちゃってるよね……?」——その発見が、週末のAI界隈を騒然とさせることになる。

ニュース

AnthropicがnpmレジストリにClaude Code v2.1.88を公開した際、ビルド成果物にソースマップ(難読化前の元ソースに戻すための変換ファイル)が混入していたことが判明した。
これにより1,906本のTypeScriptファイル、約51.2万行のソースコードが誰でも閲覧・復元できる状態に。
さらに44個のフィーチャーフラグ(機能のON/OFFを切り替える内部スイッチ)から、未公開機能「Kairos」をはじめとする複数の開発中機能が見つかり、GitHub上には8,000件以上のコピーが拡散した。

これはつまり、AI企業が「ツールの中身を丸ごと見せてしまった」事件であり、顧客データの漏洩ではないが、開発のロードマップが意図せず世界に公開されたということだ。

3行まとめ

  • npmパッケージにソースマップが混入し、Claude Codeの全ソースコード51.2万行が復元可能に
  • フィーチャーフラグから常駐エージェント「Kairos」やマルチエージェント調整など未発表機能が判明
  • コミュニティはソースを解析して「Claw Code」としてPython版を再構築。GitHub上で数万スターを集めている

ポイント

今回の流出は「顧客データ」ではなく「製品のソースコード」。
怖いのは中身が漏れたことそのものより、「なぜこんなミスが起きたのか」というプロセスの方かもしれない。
同時に、フィーチャーフラグから見える未公開機能がかなり面白い——Claude Codeヘビーユーザーとしては正直ワクワクする部分もある。


用語の整理

用語 意味
ソースマップ 難読化・圧縮されたJavaScriptから元のソースコードに逆変換するためのファイル。開発時のデバッグ用で、本番環境には含めないのが鉄則
フィーチャーフラグ ソフトウェア内部に埋め込まれた機能のON/OFFスイッチ。リリース前の機能を隠しておいたり、段階的に公開したりするために使う
npmレジストリ JavaScriptパッケージの公開リポジトリ。開発者が npm install でインストールする先。ここに公開されたものは基本的に誰でもダウンロードできる

詳細

何が起きたのか——「ソースマップの消し忘れ」という初歩的ミス

2026年3月末、AnthropicはClaude Code v2.1.88をnpmレジストリに公開した。
Claude Codeは普段、難読化されたJavaScriptとして配布されていて、中身のロジックは外からは読めない。
ところがこのバージョンでは、ビルド時に生成されるソースマップファイルがそのまま同梱されていた。

ソースマップがあると何が起きるかというと、難読化を「巻き戻し」てTypeScriptの元コードを復元できてしまう。
つまり、Claude Codeの内部構造——アーキテクチャ、認証フロー、API呼び出しのロジック、そしてまだ公開されていない機能のコード——が丸見えになった。

私もClaude Codeを毎日のように使っているので、最初にこのニュースを見たときは「えっ」となった。
でも冷静に考えると、ソースマップに含まれるのはクライアントサイドのコードであって、サーバー側のモデルやAPIキー、顧客データが含まれるわけではない。
セキュリティリスクという意味では、そこまで深刻ではないのかなと思っている( ;ㅿ; )

Anthropic側は「人為的なミスであり、顧客データの漏洩はない」とコメント。
すぐにv2.1.89を公開してソースマップを除去したが、すでに時遅し。
GitHub上には8,000件以上のフォークやコピーが拡散しており、「インターネットに一度出たものは消せない」という教訓をそのまま体現する事態になった。

フィーチャーフラグが語る未来——「Kairos」とは何者か

今回の流出で最も注目を集めたのは、ソースコード内に埋め込まれていた44個のフィーチャーフラグ
これはいわば「開発中の機能リスト」で、Anthropicがこれから何をやろうとしているかが垣間見える。

中でも話題になったのが**「Kairos」**と呼ばれる機能。
コードの分析によると、Kairosは常駐型エージェント(デーモン)として設計されていて、バックグラウンドで動作しながらプロジェクトの継続メモリと統合する仕組みらしい。
つまり、Claude Codeを閉じてもエージェントが裏で仕事を続け、プロジェクトのコンテキストを覚えたまま次のセッションに引き継ぐ——そんなイメージ。

Claude Codeをめちゃくちゃ使っている身としては、これは本当に待ち望んでいた方向性だと感じる。
今のClaude Codeは、セッションが切れるたびにコンテキストを再構築する必要があって、そこが地味にストレスだったりする。
Kairosが実現すれば、「常にプロジェクトを理解した状態の相棒」が隣にいる感覚になるはず。

フィーチャーフラグから読み取れた主な未公開機能を整理すると、こんな感じ。

機能名 推測される概要 注目度
Kairos 常駐型エージェント(デーモン)。バックグラウンド動作+プロジェクト継続メモリ統合 最注目
Coordinator Mode 複数のエージェントを同時に走らせて協調させるマルチエージェント調整機能
たまごっち風AIバディ AI育成的なインタラクション。詳細は不明だが、エージェントに「個性」を持たせる方向か ユニーク
Undercover Mode 社内利用向けのモード。外部には見せない用途と推測
Auto Mode ファイル操作やコマンド実行の権限を自動承認する設定。毎回の承認クリックが不要に 実用的
capybara-v2-fast 新しいClaude系モデル名。高速推論モデルの可能性 気になる

Auto Modeなんかは、Claude Codeユーザーなら「それ早く欲しい」って思う機能なんじゃないかなと(´ ˘ `)
毎回のツール使用承認は安全のために必要だとわかりつつも、信頼できるプロジェクトでは煩わしいと感じることもある。

コミュニティの反応——「Claw Code」という皮肉

面白いのは、流出したソースコードを元にコミュニティが動き出したこと。
TypeScriptで書かれたClaude CodeのロジックをPythonに移植した「Claw Code」というプロジェクトがGitHub上に登場し、数万スターを集めている。

Anthropicとしては頭の痛い話だろうけど、裏を返せばそれだけClaude Codeのアーキテクチャが「参考にしたい」と思われるほど洗練されていたということでもある。
コードが読みやすかった、設計が上手かった——だからこそ再実装が早かった、という見方もできる。

ただし、ソースコードを元にした派生プロジェクトはライセンスや知的財産の問題を含むので、今後Anthropicが法的措置を取る可能性はあると思う。

なぜ起きたのか——プロセスの問題が一番気になる

個人的に一番引っかかっているのは、「なぜソースマップが混入したのか」というプロセスの部分。

普通、本番ビルドでソースマップを含めないのはフロントエンド開発の基本中の基本。
CI/CDパイプライン(コードを自動でビルド・テスト・公開する仕組み)にチェックを入れていれば防げる類のミスだし、npmに公開する前のレビューでも気づけるはず。

推測にはなるが、いくつかの可能性が考えられる。
ビルド設定の変更時にソースマップ除外のフラグが外れた、公開プロセスの自動チェックにソースマップの検出が含まれていなかった、あるいはリリースを急いで手動で公開した——など。

先日のClaude Mythos漏洩もCMSの設定ミスが原因だった。
短期間に2回、「人為的ミス」による情報流出が起きていることになる。
Anthropicの技術力を疑うわけではないけれど、リリースプロセスまわりの運用体制は改善の余地がありそうだなと感じる。

影響の整理——深刻度はどのくらいか

改めて整理すると、今回の流出の影響はこうなる。

セキュリティリスク: 限定的。クライアントサイドのコードであり、サーバー側のAPIキーや顧客データ、モデルの重みは含まれていない。ただし認証フローやAPI呼び出しパターンが見えることで、攻撃の手がかりにはなりうる。

ビジネスリスク: 中程度。未公開のロードマップが競合他社に見える状態になった。Kairosのような機能が事前に知られることで、OpenAIやGoogle DeepMindが対抗機能の開発を加速させる可能性はある。

レピュテーションリスク: ここが一番痛い。「責任あるAI」を掲げるAnthropicが、自社ツールのリリースプロセスで基本的なミスを犯したという事実は、信頼に関わる。

とはいえ、対応の速さは評価できる。
すぐに修正版を公開し、ステートメントを出し、「顧客データは含まれていない」と明確にした。
完璧な予防はできなかったが、事後対応としては妥当だったのかなと思う。

今日の1アクション

もし自分のプロジェクトでnpmパッケージを公開しているなら、ビルド成果物にソースマップが含まれていないか1回だけ確認してみてほしいです。
package.jsonfiles フィールドや .npmignore を見て、.map ファイルが除外されているかチェックするだけ。
パッケージを公開していない人も、「本番に出すものから開発用ファイルを除外する」という視点は、どんな仕事でも応用がきく考え方だと思います:)

出典

著者

neco. 🐈‍⬛
AI活用コンサル/ITエンジニア歴20年。会社員として400人規模のAIリスキリング研修を統括しつつ、副業で経営者・個人事業主向けにAI導入〜実装をサポート中(経営3年目)。
毎月AIの仕事活用をテーマに勉強会も開催しています。
「AIを"知ってる"から"使える"へ」がモットー。
プロンプト700本以上を無料公開中 → ai-neco