Claude Codeコード流出事件を徹底解説｜npmソースマップ混入で51万行が公開状態に

npmソースマップ混入で51万行が公開状態になった経緯と発覚までの時系列

2026年3月31日、AIコーディングツール「Claude Code」のソースコードがインターネット上に流出しました。原因はハッキングでも内部犯行でもなく、npmパッケージへのビルド成果物の同梱ミスという、開発現場では珍しくない初歩的な設定漏れです。しかし、その結果として公開されたのは約51万2,000行・1,906ファイルにおよぶTypeScriptの全ソースコードであり、AI業界を代表する商用コーディングエージェントの内部構造が白日のもとにさらされる事態となりました。本セクションでは、流出の技術的メカニズムから発覚後の拡散、Anthropicの対応、そして過去の類似事故との関連まで、時系列に沿って詳細を整理します。

v2.1.88のビルドで.npmignore未設定が招いた約57MBマップファイル同梱

今回の流出の起点は、Claude Codeバージョン2.1.88のnpmパッケージに含まれた1つのソースマップファイルです。ソースマップとは、本番用に圧縮・難読化されたJavaScriptコードを元のソースコードに紐づけるための開発者向けデバッグ資産で、通常はプロダクション環境には含めません。Claude CodeはBunランタイムを使用してビルドされており、Bunはデフォルト設定でソースマップを自動生成する仕様です。問題は、公開パッケージからソースマップを除外するための設定が抜け落ちていた点にあります。

npmでは、パッケージに含めるファイルの制御方法として、除外対象を指定する.npmignore（ブラックリスト方式）と、package.jsonのfilesフィールドで含めるファイルだけを指定するホワイトリスト方式の2つが存在します。Anthropicはブラックリスト方式を採用していたとされますが、ソースマップファイルの除外指定が漏れていたため、約57MBにおよぶcli.js.mapファイルがそのまま公開パッケージに同梱されました。このファイルにはsourcesContentが含まれており、圧縮前のTypeScriptソースを完全に復元できる状態だったのです。

Chaofan Shou氏のX投稿から数時間で4万超フォークに達した異例の拡散速度

流出を最初に公表したのは、セキュリティ研究者のChaofan Shou氏です。2026年3月31日の早朝（米国東部時間午前4時23分頃）、同氏はXにダウンロードリンクとともに「Claude code source code has been leaked via a map file in their npm registry!」と投稿しました。この投稿は瞬く間に拡散し、閲覧数は1,600万回を超えたと報じられています。

投稿からわずか数時間のうちに、流出したソースコードはGitHub上に複数のミラーリポジトリとして公開されました。代表的なものとしてinstructkr/claude-code、Kuberwastaken/claude-code、nirholas/claude-codeなどが確認されており、最も注目を集めたリポジトリは公開から数時間で1,100以上のスターと1,900以上のフォークを獲得し、その後も急速に拡大して最終的には41,500以上のフォークに達したと報じられています。開発者コミュニティの関心の高さを如実に示す数字であり、AI業界における「事件」としてのインパクトの大きさがうかがえます。この急速な拡散は、一度インターネットに公開された情報を事後的に回収することの困難さを改めて証明する結果となりました。

R2バケットのZIPアーカイブから1906ファイルが復元できた技術的メカニズム

ソースマップファイル内には、AnthropicのCloudflare R2ストレージバケットへの参照URLが含まれていました。このURLにアクセスすると、難読化されていない元のTypeScriptソースコード一式が格納されたZIPアーカイブを直接ダウンロードできる状態になっていたのです。つまり、npmパッケージを入手してソースマップの中身を確認するだけで、誰でもワンクリックで全ソースを取得できました。

復元されたコードベースは、src/ディレクトリ全体にあたる1,906ファイル・51万2,000行超のTypeScriptで構成されています。さらに、57MBのcli.js.mapには合計4,756個のソースファイルへの参照が含まれており、そのうち1,906個がClaude Code自体のソースコード、残りの約2,850個はnode_modulesの依存関係でした。コメントや型定義も完全に保持された状態であり、本番で使われているプロダクションコードそのものが外部から丸見えになっていたことになります。R2バケットの公開設定がデフォルトでパブリックアクセスを許可していた点も、流出規模を拡大させた要因の一つです。

Anthropicが旧バージョン削除とソースマップ除去を完了するまでの対応手順

Anthropicは流出の発覚後、迅速に対応を開始しました。まずソースマップファイルを除去した修正版のnpmパッケージをプッシュし、続いて問題のあったv2.1.88を含む旧バージョンをnpmレジストリから削除しています。同社の広報担当者は複数のメディアに対し、「本日のClaude Codeリリースに一部の内部ソースコードが含まれていた。顧客データや認証情報は関与・露出しておらず、これはヒューマンエラーによるリリースパッケージングの問題であり、セキュリティ侵害ではない」と説明しました。

ただし、対応のスピードにもかかわらず、流出コードの回収は事実上不可能な状況です。GitHub上のミラーリポジトリに対してはDMCA（デジタルミレニアム著作権法）に基づく削除要請が行われましたが、フォーク数が数万単位に達しており、分散型プラットフォームへのミラーも確認されています。npmのキャッシュインフラストラクチャにも旧バージョンが残存しており、ローカル環境にダウンロード済みの開発者も多数にのぼるとみられます。Anthropicは「再発防止策を展開中」としていますが、その具体的内容は本稿執筆時点では公表されていません。

2025年2月のv0.2.8流出と今回で3度目となるビルドパイプライン事故の共通点

実は、Claude Codeのソースマップがnpmパッケージに混入する事故はこれが初めてではありません。2025年2月にリリースされた初期バージョンv0.2.8およびv0.2.28でも、同様にソースマップが同梱された状態で公開されていたことが確認されています。当時Anthropicは問題が指摘された後にレジストリからバージョンを削除しましたが、キャッシュされたコピーはnpmのミラーインフラやローカルの開発者環境に残り続けました。

今回の事故は、同じ種類のビルドパイプライン障害が3度目の発生となるため、単発的なヒューマンエラーではなく構造的な問題が存在する可能性を強く示唆しています。とりわけ注目すべきは、Anthropicが自社の知的財産保護に対して積極的な姿勢を見せてきた企業であるという点です。リバースエンジニアリングに対する法的措置や、非公認のClaude互換ハーネスのブロックなど、コード保護に相当のリソースを投じてきたにもかかわらず、その保護対象であるソースコード自体が繰り返し流出するという皮肉な結果が生じています。ビルドプロセスのセキュリティ検証が自動化されていないか、検証が形骸化している可能性を、開発チームは真剣に検討すべき状況でしょう。

流出したTypeScript1900ファイルから判明したClaude Codeの内部アーキテクチャ全容

Claude Codeは単なる「ターミナル上で動くAIチャット」ではなく、パーミッション管理、メモリ層、バックグラウンドタスク、IDE連携、マルチエージェントオーケストレーションなどを備えた、ソフトウェア開発向けの統合プラットフォームとしての側面を持っていることが、流出したソースコードから明らかになりました。本セクションでは、コードベースの構造から技術選定の意図、そして競合製品との差別化ポイントまでを、アーキテクチャの各レイヤーに分けて解説します。

Bunランタイム採用でNode.jsを大幅に上回る起動速度を実現した設計判断の背景

流出したソースコードから、Claude CodeのランタイムにNode.jsではなくBunが採用されていることが判明しました。Bunは2025年12月にAnthropicが買収したJavaScriptランタイムで、Node.jsと比較して起動速度が大幅に速く、メモリ消費量も抑えられる特徴を持っています。CLIツールにとって起動速度はユーザー体験に直結する要素であり、コマンドを入力してから応答が返るまでの体感を最小化するための戦略的な選定だったといえるでしょう。

また、Bunはバンドラー機能を内蔵しており、外部ツールに依存せずにTypeScriptのビルドとバンドルを完結できます。しかし皮肉なことに、今回の流出はまさにこのBunバンドラーがデフォルトでソースマップを生成する仕様に起因していました。高速化と開発効率を優先したランタイム選定が、パッケージング段階でのセキュリティリスクを生むという、技術選定における「便利さと安全のトレードオフ」を象徴する事例といえるでしょう。開発チームにとっては、ランタイムやバンドラーを変更した際のデフォルト設定の確認が不可欠であるという教訓になります。

QueryEngine.ts4万6000行が担うLLM API通信・ストリーミング・キャッシュの三層構造

流出コードの中でも特に注目を集めたのが、46,000行に達するQueryEngine.tsです。このファイルはClaude CodeのLLM API通信の中核を担っており、Claudeモデルへのリクエスト送信、レスポンスのストリーミング処理、トークン追跡、そしてキャッシュ管理を一手に引き受けています。単一ファイルとしてはきわめて大規模であり、Claude Codeの「頭脳」にあたる部分といえます。

特筆すべきは、このエンジンが「洗練されたオーケストレーション」機能を内包している点です。単純なAPI呼び出しの抽象化にとどまらず、リクエストのバッチ処理、レスポンスの部分的な再利用、ストリーミング中のエラーハンドリング、そしてトークン使用量のリアルタイム追跡など、商用AIエージェントとして求められる堅牢性が多層的に実装されています。なお、流出直後にはClaude Codeのプロンプトキャッシュを破壊する2つのバグも同日に報告されており、API利用料が10〜20倍に跳ね上がる問題が発生していたことも併せて把握しておくべき重要な情報です。

Tool.ts2万9000行に定義された約40種パーミッションゲート付きツール群の全体像

Claude Codeの実行能力を支えるのが、Tool.tsに定義された約40種類のビルトインツール群です。ファイルの読み書き、シェルコマンドの実行、コードの検索・置換、Git操作、IDE連携など、ソフトウェア開発で必要とされる操作が網羅的にカバーされています。このファイルだけで29,000行に達しており、各ツールの型定義、パーミッション制御ロジック、入出力のバリデーションが詳細に記述されていました。

重要な設計思想として、すべてのツールにパーミッションゲートが設けられている点が挙げられます。Claude Codeはファイルシステムへの書き込みやシェルコマンドの実行といった危険な操作を行える強力なエージェントであるため、各操作に対して明示的なユーザー承認を要求する仕組みが組み込まれているのです。Anthropicの公式ドキュメントでも強調されている「パーミッションプロンプト」「読み取り専用デフォルト」「サンドボックス化」といったセキュリティ原則が、このツール定義の中にコードレベルで実装されていることが確認できます。ただし、パーミッション制御の詳細が公開されたことで、バイパス手法の発見が加速するリスクも指摘されているところです。

React＋Inkによるターミナル描画がCLIツールとしては異例と評される理由

多くのCLIツールがテキストベースの出力を直接標準出力に書き込むのに対し、Claude CodeはReactとInkを組み合わせたコンポーネントベースのUI描画モデルを採用しています。Inkは、Reactのコンポーネントモデルをターミナル上で再現するライブラリで、状態管理やレイアウト制御をReactの宣言的な記法で記述できます。この選択はCLIツールとしては異例であり、コミュニティでも議論の的となりました。

この設計の利点は、複雑なインタラクティブUIをターミナル上で実現できる点にあります。ストリーミングレスポンスのリアルタイム表示、ツール実行の進捗表示、パーミッション確認ダイアログなど、Claude Codeには従来のCLIツールにはない豊富なUI要素が含まれます。これらをReactコンポーネントとして設計することで、UIの再利用性と保守性を高めているわけです。一方で、React＋Inkの導入はバンドルサイズの増大や起動時のオーバーヘッドにつながる側面もあり、それを補うためにBunの高速起動が活きてくるという、技術選定間の相互依存関係が見て取れます。

Zod v4スキーマ検証を全統合に適用する多層防御アプローチの実務的意味

Claude Codeのデータ整合性を支える基盤技術として、Zod v4によるランタイムスキーマ検証が全統合ポイントに適用されていることがソースコードから確認されました。Zodは、TypeScriptのスキーマ宣言とランタイム検証を一体化するライブラリで、APIレスポンス、ツール入出力、設定ファイルの読み込みなど、外部データが流入するすべての箇所で型の正しさをランタイムに保証します。

この設計は「多層防御（defense-in-depth）」の考え方に基づくものです。TypeScriptの静的型チェックはコンパイル時に不正を検出しますが、ランタイムで受け取るデータの形式までは保証しません。たとえばLLMから返されるJSONレスポンスやMCPサーバーからのツール応答は、実行時に初めてその構造が確定します。Zodを用いることで、これらの動的データに対してもスキーマレベルでの検証を自動的に行い、不正なデータの侵入を多段で防ぐ仕組みが構築されているのです。AI環境では予測不能なデータ構造に対応する必要があるため、この多層検証は商用エージェント設計における重要な参考事例として評価されています。

KAIROS・BUDDY・Undercover Modeなど未公開機能フラグが示す開発ロードマップ

流出したソースコードには、現行の公開ビルドには含まれていない多数の未公開機能が埋め込まれていました。コンパイル時のフィーチャーフラグによってゲートされたこれらの機能は、Anthropicが今後Claude Codeをどの方向に進化させようとしていたかを示す、いわば内部ロードマップのような位置づけです。107個ものフィーチャーフラグが確認されたとの分析もあり、セッション型のコーディング補助から、常駐型の自律的開発環境への転換を強く志向している様子がうかがえます。

KAIROSが実現する常駐バックグラウンドデーモンと夜間ナレッジ統合の仕組み

未公開機能の中でも特に注目されたのが、「KAIROS」というプロジェクトコードネームで呼ばれるシステムです。KAIROSはClaude Codeを常駐型のバックグラウンドデーモンとして動作させる仕組みで、ユーザーがアイドル状態にあるときもClaude Codeが作業を継続できるように設計されています。Axiosの報道によれば、これは「persistent assistant」として位置づけられており、ユーザーがターミナルを閉じている間もバックグラウンドで処理を進める機能を想定しているとのことです。

さらに興味深いのが、「夜間ドリーミング」と呼ばれるナレッジ統合プロセスの存在です。KAIROSはメモリログを蓄積し、一定のタイミングで過去のセッション情報を統合・圧縮することで、会話をまたいだ学習の転移を可能にする設計を目指しているとみられます。現在のClaude Codeは各セッションが独立しており、過去のやり取りを次のセッションに持ち越す機能は限定的です。KAIROSが実現すれば、プロジェクト全体の文脈を長期にわたって保持し続ける「記憶を持つ開発パートナー」へと進化することになります。

たまごっち型AIペットBUDDYの18種族・レアリティ階層・4月リリース計画

流出コードの中でコミュニティが最も盛り上がったのが、buddy/ディレクトリに格納されていた「BUDDY」機能です。これはターミナルの入力ボックスの横に常駐する、たまごっちスタイルのAIコンパニオンペットシステムで、18種族・レアリティ階層・シャイニーバリアントを備え、デバッグ力・忍耐力・カオス度・知恵といったステータスが手続き的に生成される仕組みになっています。

BUDDYはBUDDYというコンパイル時フィーチャーフラグで完全にゲートされており、現行ビルドには一切含まれていません。しかしコード内のタイムラインによると、2026年4月1日〜7日がティーザー期間、5月が本格ローンチとして設定されていたことが読み取れます。シード値のソルトに含まれる「401」は4月1日を示唆しており、エイプリルフール企画として開始し、反応次第で正式機能化する段取りだったのではないかとの見方が大勢を占めています。一見すると遊び心の産物ですが、ターミナルで長時間孤独に作業するエンジニアの心理的安全性を高める設計実験として、開発者体験への深い洞察がうかがえる機能といえるでしょう。

Undercover Modeがコードネーム漏洩を防ぐシステムプロンプト注入の具体的手法

流出コードの中でも特に皮肉だと指摘されたのが、「Undercover Mode」の存在です。これは、Claude Codeがオープンソースリポジトリへの貢献など外部向けの出力を行う際に、Anthropicの内部コードネームやプロジェクト名を誤って漏洩しないように設計された保護メカニズムです。具体的には、Claudeのコンテキストにシステムプロンプトを動的に注入する方式で、そのプロンプトには「Do not blow your cover」という指示が含まれていました。

Undercover Modeが保護対象としていたのは、「Tengu」などのプロジェクトコードネームやSlackの社内チャンネル名といった社内情報です。数時間から数日をかけて設計された機密保護の仕組みが、package.jsonの設定ファイル1行の欠落によって全世界に公開されたという事実は、多くのメディアやコミュニティで「情報漏洩を防ぐためのコードが情報漏洩で露呈した」と報じられました。技術的には妥当な設計ですが、それを守るための運用基盤が脆弱だったことが露呈したかたちです。

マルチエージェントswarm機能によるタスク並列処理が示す自律化の方向性

コードベースからは、1つのClaude Codeインスタンスが複数のワーカーエージェントを生成・管理し、タスクを並列に処理する「マルチエージェントスウォーム（群れ）」の概念が見つかっています。このアーキテクチャでは、親エージェントがタスクを分割して子エージェントに配分し、各エージェントが独立してツールを実行した結果を統合する仕組みが想定されていました。

この機能が実装された場合、たとえば大規模なコードリファクタリングにおいて、複数のファイルを同時に修正しながら整合性を保つといった作業が可能になります。また、JWT認証付きのIDEブリッジも確認されており、ターミナルだけでなくVS Codeなどの統合開発環境からリモートでClaude Codeを操作する基盤も準備されていたようです。「ULTRAPLAN」と呼ばれる機能フラグも関連すると見られ、長期にわたる自律タスクの計画・実行・評価を一貫して管理するオーケストレーション層を構成する意図がうかがえます。セッション単位の対話型アシスタントから、プロジェクト単位で動き続ける自律型エージェントへの転換を、Anthropicが本気で推進していたことを示す証拠です。

107個のフィーチャーフラグから読み取れるOpus上位の新ティアCapybaraの実装段階

流出コード内には、Anthropicの次世代モデルを示すコードネーム「Capybara」への参照が複数箇所で見つかっています。このCapybaraは、数日前に別の経路（CMS設定ミスによるドラフトブログポスト流出）で存在が明らかになっていた「Mythos」モデルの内部ティア名とみられています。流出したドラフトブログポストでは、Capybaraは「Opusモデルよりもさらに大規模かつ高性能な新しいモデルティア」と位置づけられており、既存のOpus・Sonnet・Haikuの3段階を超える第4の階層として設計されていることが判明しました。

セキュリティ研究者Roy Paz氏の分析によると、Capybaraはより大きなコンテキストウィンドウを活用し、「高速版」と「低速版」の2つのバリエーションでリリースされる可能性が推定されています。107個のフィーチャーフラグの中にはCapybaraの各機能に対応するものも含まれており、モデル切り替えロジック、コンテキスト長の動的調整、新しいツール連携の有効化など、段階的なロールアウトを想定した開発プロセスが垣間見える構成となっています。

安全第一を標榜するAnthropicが初歩的ミスを繰り返す構造的リスクの正体

Anthropicは設立当初から「責任あるAI開発」を企業理念の中核に据え、安全性を最大の差別化要因として打ち出してきた企業です。しかし、2026年3月末の1週間だけで、未発表モデル情報の漏洩とソースコード全体の流出という2つの重大なインシデントが連続して発生しました。高度なサイバー攻撃ではなく、いずれも基本的な設定ミスに起因する点が、かえって深刻な問題を提起しています。

3月26日のMythos情報漏洩と5日後のnpm事故が連続した運用管理体制の盲点

npm事故のわずか5日前となる2026年3月26日、Anthropicは別の経路でも情報を漏洩していました。CMS（コンテンツ管理システム）の設定ミスにより、約3,000件のファイルが公開アクセス可能な状態になっており、その中には未発表の次世代モデル「Mythos」（内部名称「Capybara」）の詳細を記したドラフトブログポストが含まれていたのです。このモデルは「前例のないサイバーセキュリティリスクを呈する」と内部文書に記載されていたと報じられています。

1週間以内に異なるシステム（CMSとnpmパッケージング）で連続してインシデントが発生した事実は、特定のチームや個人のミスというよりも、組織横断的なリリース管理体制の構造的な弱点を示す兆候といえるでしょう。CMSのパブリックアクセス設定、R2バケットの公開設定、npmの除外設定と、いずれも「セキュアなデフォルト」の原則が守られていなかった点で共通しています。急速に成長する組織において、プロダクト開発のスピードとセキュリティ検証のバランスが崩れている可能性を、経営層レベルで直視すべき局面といえるでしょう。

ホワイトリスト方式を採用しなかったpackage.json設定が生んだ除外漏れの教訓

今回のnpm流出の直接的原因は、パッケージに含めるファイルの制御方法にあります。npmでは、package.jsonのfilesフィールドに公開したいファイルだけを明示的に列挙するホワイトリスト方式が推奨されていますが、Anthropicは.npmignoreによるブラックリスト方式を採用していました。ブラックリスト方式では、除外すべきファイルを漏れなく指定する必要があり、新たにビルド成果物が追加されたとき（今回のケースではBunバンドラーが自動生成するソースマップ）に除外指定の追加を忘れると、そのままパッケージに含まれてしまいます。

ホワイトリスト方式であれば、意図的に追加しない限り新規ファイルが公開パッケージに混入することはありません。「含めないものを指定する」アプローチよりも「含めるものだけを指定する」アプローチのほうが、予期しないファイルの漏洩に対して根本的に堅牢です。npmの公式ドキュメントでもfilesフィールドの利用が推奨されており、今回の事故はこのベストプラクティスを遵守していれば防げた可能性が極めて高いといえます。ビルドツールチェーンの変更時には、公開成果物の内容を必ず検証するプロセスを組み込むことが不可欠です。

CVE-2025-59536など過去のClaude Code脆弱性報告と今回の事故の根本的な違い

Claude Codeに対しては、今回のソースマップ流出以前にも複数のセキュリティ脆弱性が報告されています。2025年10月には、セキュリティ研究者のJohann Rehberger氏がFiles APIの情報窃取脆弱性をAnthropicに報告し、悪意のある攻撃者がClaude Codeを利用して開発者環境から機密データを盗み出せることを実証しました。この脆弱性は2026年1月に公開されています。また、CVE-2025-59536やCVE-2026-21852といった脆弱性識別番号が割り当てられた問題も過去に存在しています。

これらの脆弱性と今回のソースマップ流出の根本的な違いは、前者がプロダクトの設計や実装に内在する技術的欠陥であるのに対し、後者はリリースプロセスにおける運用上の不備である点です。技術的な脆弱性は、コードレビューやペネトレーションテストで発見・修正するものですが、リリースプロセスの不備は組織のガバナンスとCI/CDパイプラインの品質に依存します。セキュリティリサーチへの対応能力と、基本的なリリース管理の成熟度が乖離しているという現状は、Anthropicの組織的課題として今後も注視されるでしょう。

セキュリティモジュールを販売する企業が自社コードを流出させた信頼毀損の構造

Anthropicは、Claude Code Securityモジュールを通じて企業顧客にAI導入時の脆弱性検出サービスを提供しています。つまり、他社のAI運用におけるセキュリティリスクを評価・低減するサービスを販売している企業が、自社のコアプロダクトのソースコードを基本的な設定ミスで流出させたかたちです。この矛盾は業界内で広く指摘され、Anthropicのブランド価値に対する信頼毀損の要因として議論されています。

ただし、冷静に見れば、ソースコードの流出と顧客データの漏洩は本質的に異なるインシデントです。Anthropic自身も「顧客データや認証情報は含まれていなかった」と明言しており、ユーザーへの直接的な被害は確認されていません。また、Claude Codeのクライアントロジック自体は以前からリバースエンジニアリングによって解析されており、ソースマップの流出は「縮小されたコードをきれいに出力した」に近いという見方も一部にはあります。とはいえ、AI安全性を企業の存在意義として掲げる以上、運用面での安全管理も同等の水準で求められることは避けられません。

Check Pointが2026年2月に公開した悪意あるリポジトリ設定悪用との複合リスク

セキュリティ企業Check Pointは2026年2月25日、Claude Codeに対する攻撃ベクトルとして、悪意のあるリポジトリ設定ファイルを利用した同意バイパスの手法を公開しました（脆弱性自体は2025年7月〜10月に同社からAnthropicへ報告済み）。CVE-2025-59536およびCVE-2026-21852として追跡されるこれらの脆弱性は、攻撃者が細工したリポジトリにClaude Codeを接続させることで、リモートコード実行やAPIキーの窃取を可能にするものです。

今回のソースコード流出により、Claude Codeのパーミッション制御の内部実装が詳細に公開されたことで、このような攻撃手法の洗練化が加速するリスクが指摘されています。可読なかたちで利用可能になった情報は多岐にわたり、攻撃者がバイパス手法を体系的に探索しやすくなったといえるでしょう。

• パーミッションゲートの判定ロジックと各ツールに設定された権限レベルの全容
• サンドボックスの境界条件およびファイルシステムアクセス制御の実装詳細
• OAuth 2.0認証フローのトークン管理と内部APIクライアントの接続仕様
• マルチエージェント間の権限委譲メカニズムと通信プロトコルの構造

Anthropicが公式ドキュメントで強調してきた「パーミッションプロンプト」「読み取り専用デフォルト」「サンドボックス化」の各防御層について、その実装の妥当性を外部から検証できるようになった点は、防御と攻撃の両面で影響を及ぼし得る事態です。Claude Codeを業務に導入している組織は、Anthropicの公式セキュリティアドバイザリを継続的に監視し、修正パッケージへの速やかな更新を徹底しなければなりません。

DMCA削除要請とPythonクリーンルーム移植が突きつけたAI時代の著作権問題

ソースコード流出後、AnthropicはGitHub上のミラーリポジトリに対してDMCA削除要請を迅速に発行しました。しかし、この法的措置はかえって新たな展開を引き起こすことになります。削除要請から数時間以内に、流出コードを元にした「クリーンルーム移植」のPython版が公開され、DMCA回避が成立するかどうかという著作権法上の根本問題が浮上しました。AI生成コードの法的保護が不透明な現状と相まって、今回の事件はAI時代の知的財産権のあり方に一石を投じています。

GitHubミラー即時削除に対しSigrid Jin氏がPython移植を数時間で完成させた経緯

Anthropicが最初のDMCA削除要請を発行した直後、韓国人開発者のSigrid Jin氏が動きました。Wall Street Journalにも取り上げられたことのあるこの開発者は、Claude Codeのトークンを250億トークン以上消費した実績を持つ著名なヘビーユーザーです。午前4時に流出のニュースを知った同氏は、AIオーケストレーションツール「oh-my-codex」を使用して、Claude CodeのコアアーキテクチャをゼロからPythonに移植する作業を開始しました。

その成果物である「claw-code」は、日の出前にはGitHubに公開されていたと報じられています。このリポジトリは公開後、史上最速ペースで30,000スターを記録しました。注目すべきは、claw-codeがAnthropicのTypeScriptコードを直接コピーしたものではなく、アーキテクチャの概念を参照しつつPythonでゼロから書き直した「クリーンルーム実装」であるという点です。Jin氏自身は、Anthropicから法的責任を問われることを懸念した恋人の助言がきっかけだったと語っており、技術的野心と法的リスクの狭間で生まれた成果物として話題を集めました。

claw-codeが史上最速3万スターを記録しDMCA回避が成立した法的根拠

claw-codeがDMCAの適用を免れた根拠は、「クリーンルーム設計」の原則にあります。クリーンルーム設計とは、既存のソフトウェアの機能や動作を参考にしつつ、元のソースコードを直接参照せずに独立した実装を行う手法です。この手法で作成されたソフトウェアは、元のコードの著作権を侵害しない新たな創作物として扱われるのが一般的な法的解釈となっています。

技術系ニュースレター「The Pragmatic Engineer」の創設者であるGergely Orosz氏は、Xへの投稿で「これは見事か恐ろしいかのどちらかだ」と評しました。同氏はclaw-codeを「クリーンルーム書き直しであり、新たな創作物であり、設計上DMCAを回避できる」と分析しています。ただし、法的な決着はまだついていません。流出したソースコードを「参照」しながらの移植が、厳密な意味でのクリーンルーム設計に該当するかどうかは、今後の訴訟や判例で争われる可能性が残されています。Anthropicが法的措置をさらに進めるかどうかの判断も、この分野の先例形成に大きな影響を与えるでしょう。

AI生成コードの著作権保護がDC巡回裁判所2025年判決で否定された判例の意味

今回の流出にまつわる著作権問題をさらに複雑にしているのが、AI生成コードの法的地位に関する近年の判例です。2025年3月、米国のDC巡回控訴裁判所は、AIが生成した作品には著作権が自動的には認められないとする判断を支持しました。その後、米国最高裁判所はこの判決に対する上訴審理を棄却しており、現時点では「AI生成物は著作権保護の対象外」という立場が米国法の下で事実上確定しています。

この判例が重要なのは、Anthropic自身のCEOがClaude Codeの相当部分がClaude自身によって書かれたことを示唆している点との関連です。もしClaude Codeのソースコードの重要な部分がAIによって生成されたものであるならば、その部分に対する著作権の主張自体が法的に不安定になる可能性があります。DMCA削除要請は著作権の存在を前提としますが、保護対象のコードが著作権で保護され得るかどうか自体が争点となりうるわけです。AI開発企業がAI自身を開発に使用するという構造が、自社の知的財産保護と矛盾しかねないというジレンマは、業界全体に共通する課題として今後さらに顕在化するでしょう。

CEOが示唆するClaude自身による開発とクリーンルーム原則の矛盾点

AnthropicのCEOであるDario Amodei氏は、過去の発言でClaude Codeの開発プロセスにClaude自身が関与していることを示唆しています。もしこれが事実であれば、Claude Codeのコードベースには「人間が書いた部分」と「AIが書いた部分」が混在していることになり、著作権保護の範囲を確定すること自体が技術的に困難になります。

クリーンルーム設計の原則は、本来「人間の著作物であるソースコードの著作権を侵害しない」ことを保証するための手法です。しかし、元のコードがAI生成物を含んでいる場合、何を「保護すべき著作物」と見なすかの線引きが曖昧になります。これはClaude Codeに限った問題ではなく、AIを活用したソフトウェア開発が普及するにつれて、業界全体が直面する構造的な課題です。コードの著作権性をファイル単位やコミット単位で判定することは現実的に困難であり、新たな法的枠組みやライセンスモデルの整備が急務とされています。

Gitlawb分散型ミラーが象徴する削除不可能な時代のIP保護戦略の限界

DMCA削除要請に対抗する動きとして、@gitlawbというアカウントがClaude Codeの流出コードを分散型Gitプラットフォーム「Gitlawb」にミラーリングし、「永久に削除されない」というメッセージとともに公開しました。GitHubのような中央集権型プラットフォームであればDMCA要請による削除が可能ですが、分散型プラットフォームには単一の管理主体が存在しないため、法的措置による削除は事実上不可能です。

この動きは、デジタル時代における知的財産保護の根本的な限界を象徴しています。一度インターネットに公開されたコードは、ミラー、フォーク、キャッシュ、ローカルコピーを通じて無限に複製され、いかなる法的措置をもっても完全な回収は実現できません。Anthropicのようなクローズドソース戦略を採用する企業にとって、コードの秘匿性そのものを競争優位の源泉とすることのリスクが露呈したかたちです。今後は「流出しても競争力を失わない」ビジネスモデルの構築が、AI企業のIP戦略における重要な論点として浮上するでしょう。

競合他社への無料アーキテクチャ公開がAIコーディングエージェント市場に与える影響

Claude Codeのソースコード流出は、単なるセキュリティインシデントにとどまらず、AIコーディングエージェント市場全体の競争構造に影響を及ぼす可能性があります。商用製品のアーキテクチャが詳細に公開されること自体が前例に乏しく、競合他社の製品開発、オープンソースコミュニティの活動、そしてAnthropic自身の事業戦略に対して、短期・長期の両面で多層的な影響が予想されます。

OpenAI Codex CLIのオープンソース戦略と今回の意図せぬ公開の決定的な差異

Claude Codeの流出を語るうえで欠かせないのが、OpenAIのCodex CLIとの対比です。OpenAIは2025年5月にCodex CLIを「軽量なオープンソースコーディングエージェント」として公開し、その後もGPT-5-Codexの開発において「オープンソースのエージェント実装を基盤としている」と繰り返し説明してきました。つまり、OpenAIはコーディングエージェントのハーネス層を意図的にオープンソース化する戦略を採っています。

対照的に、Anthropicはハーネス層を含めた全体をクローズドに保つ戦略を維持してきました。この違いは、各社が何を「堀（moat）」と見なしているかの差異を反映しています。OpenAIがモデル性能・製品開発速度・エコシステムに競争優位の源泉を置いているのに対し、Anthropicはオーケストレーション層自体を知的財産の核心と位置づけていたとみられます。今回の流出は、その核心部分が「意図せず公開された」点でOpenAIの戦略的公開とは本質的に異なり、競合に無償で詳細な設計知見を提供する結果となりました。

エージェントハーネス設計がモデル性能以上に差別化要因となる市場構造の変化

今回の流出が明らかにしたのは、Claude Codeが「ターミナル上のClaude」ではなく、パーミッション管理・メモリ層・バックグラウンドタスク・マルチエージェント連携を備えた統合的なソフトウェア開発プラットフォームであるという事実です。Anthropicは2026年3月の技術記事で、長時間稼働するアプリケーションの成否は「モデル単体よりもハーネス設計に大きく依存する」と明言しています。

この認識は業界全体に広がりつつあるのが現状です。AIコーディングエージェントの競争軸は、「どれだけ賢いモデルを持っているか」から「どれだけ堅牢な実行環境を構築できるか」へとシフトしています。パーミッション制御、ツール連携、コンテキスト管理、エラー回復、セキュリティサンドボックスといったハーネス層の設計品質が、ユーザー体験と信頼性を直接左右するのです。Claude Codeのアーキテクチャが公開されたことで、この「ハーネスこそが本体」という設計思想が業界標準として認知される契機になると考えられます。

年間経常収益が年初来で2倍超の25億ドルに到達したClaude Codeへの短期的・長期的影響

Claude Codeは2025年11月に年間経常収益（ARR）10億ドルを達成し、2026年2月時点では25億ドルに到達したと複数の報道が伝えています。年初来で2倍以上の成長率であり、大企業を中心に急速な導入が進んでいることを裏づける数字です。この成長フェーズでソースコードが流出したことの影響は、短期と長期で異なる様相を呈するでしょう。

短期的には、企業顧客からのセキュリティ監査要求の増加や、導入検討中の企業における慎重姿勢の強まりが予想されます。特に、金融機関や医療機関など規制の厳しい業界では、ベンダーの運用管理体制に対する審査基準が引き上げられる可能性が否定できません。一方、長期的には影響は限定的との見方もあります。Claude Codeの真の競争優位はハーネス設計の知見にとどまらず、基盤となるClaudeモデルの性能、製品のアップデート速度、エンタープライズサポート体制などの複合要因にあるためです。ソースコードが公開されたからといって、同等の品質とスケールのプロダクトを即座に再現できるわけではない点は、冷静に評価する必要があります。

オーケストレーション層を堀と見る思想が露呈したことで加速するOSS再現の動き

流出直後から、Claude Codeのアーキテクチャを参考にしたオープンソースプロジェクトの立ち上げが相次いでいます。claw-codeのPython移植に加え、コミュニティ主導のクリーンルーム再現プロジェクトや、既存のオープンソースエージェントフレームワークへのClaude Code流アーキテクチャの統合なども進行中です。Hacker News上では「Claude Codeのアーキテクチャが広く知られること自体は、最終的に業界全体にとってプラスだ」という声も見られます。

Anthropicがクローズドに保ってきたオーケストレーション層の詳細が公開されたことで、開発者コミュニティはプロダクショングレードのAIコーディングエージェントがどのように設計されるべきかの具体的な参照実装を手に入れました。パーミッション管理の粒度、ツール連携のインターフェース設計、メモリ層のアーキテクチャなど、これまで各社が独自に試行錯誤していた領域に共通の設計パターンが生まれる土壌が形成されたといえるでしょう。競争の舞台が「何を作るか」から「どれだけ速く・安全に作るか」へと移行する転換点となる可能性があります。

Android公開当時との類似性から予測するエコシステム拡大と収益モデルの転換点

一部のアナリストは、今回の流出をGoogleがAndroidをオープンソース化した時期と比較しています。Androidの公開は短期的にはGoogleの競争優位を削ぐように見えましたが、長期的にはモバイルエコシステムの爆発的な拡大を促し、Google自身にも巨大な広告収益とプラットフォーム支配力をもたらしました。Claude Codeのアーキテクチャが公開されたことで、同様の「エコシステム拡大」効果が生じるかどうかが注目されています。

ただし、AnthropicのケースではAndroidとの重要な違いがあります。Googleは戦略的にオープンソース化を選択しましたが、Anthropicの場合は意図せぬ流出です。したがって、エコシステム拡大を前提としたビジネスモデルの設計が行われていません。もし今回の事態を契機にAnthropicがハーネス層のオープンソース化に方針転換すれば、モデルAPIの利用量拡大を収益の柱とする戦略への移行が考えられます。しかし、IPO（新規株式公開）を準備中とされる同社にとって、知的財産の毀損と受け取られかねない方針転換は投資家への説明が困難であり、短期的には従来のクローズド戦略を維持しつつ再発防止に注力する公算が大きいでしょう。

開発チームが今日から実践すべきnpmパッケージ公開時のソースマップ対策

Claude Codeの流出事故は、高度なAIセキュリティ以前に「ビルドパイプラインの基本的な設定確認」が不十分だったことに起因しています。この教訓は、npmパッケージを公開するすべての開発チームに当てはまるものです。本セクションでは、同種の事故を確実に防止するための具体的な設定方法とCI/CDパイプラインの組み込み手順を、実務で即座に適用できるレベルで解説します。

npm pack –dry-runによる公開前ファイル一覧確認を必須化する運用フロー

最も即効性のある対策は、npmパッケージの公開前に含まれるファイルの一覧を必ず確認するプロセスを導入することです。npm pack --dry-runコマンドを実行すると、実際にパッケージを作成することなく、公開時に含まれるファイルの一覧とサイズを表示できます。このコマンドの出力に.mapファイルやsrc/ディレクトリが含まれていないかを目視またはスクリプトで検証します。

運用フローとしては、公開担当者がnpm publishを実行する前に必ずnpm pack --dry-runの結果を確認するルールを設ける方法が最もシンプルです。ただし、人的確認に依存するフローは見落としのリスクが残るため、後述するCI/CDパイプラインへの自動化組み込みと併用することが推奨されます。チーム内のルールとして「dry-runの結果をプルリクエストに貼り付けてからマージする」といった手順を定めておくと、レビュー工程での検証漏れも防止できます。特にビルドツールやバンドラーを変更した直後は、生成物が想定通りかを重点的に確認すべきタイミングです。

package.jsonのfilesフィールドでホワイトリスト方式に切り替える具体的設定例

今回の事故の根本原因は、.npmignoreによるブラックリスト方式を採用していた点にあります。より安全なアプローチは、package.jsonのfilesフィールドでホワイトリスト方式に切り替えることです。以下のように、公開対象のファイルだけを明示的に列挙します。

具体的には、package.jsonに"files": ["dist/cli.js", "README.md", "LICENSE"]のようにビルド成果物と必要なドキュメントだけを列挙します。この方式であれば、ビルドツールの変更で新たなファイルが生成されても、filesに追加しない限りパッケージに含まれることはありません。.npmignoreとfilesの両方が存在する場合はfilesが優先されるため、移行作業は段階的に進められます。

CI/CDパイプラインにソースマップ検出ステップを組み込む3つの実装パターン

人的確認を超えて確実性を担保するには、CI/CDパイプラインに自動化された検証ステップを組み込む必要があります。具体的な実装パターンとしては、以下の3つが代表的です。

1. ビルド完了後にfind dist/ -name "*.map"を実行してソースマップの存在を検出し、見つかった場合にビルドを失敗させるシンプルな方式
2. npm pack --dry-run --jsonの出力をパースし、ファイルサイズや拡張子のチェックリストと照合する方式（ソースマップ以外の想定外ファイルも検出可能）
3. パッケージングされた成果物を一時ディレクトリに展開し、ファイルの内容レベルでsourceMappingURLやsourcesContentへの参照が含まれていないかをgrepで検査する方式

3番目の方式が最も厳密であり、ソースマップ本体がパッケージに含まれていなくても、バンドルされたJSファイル内に外部ソースマップへの参照URLが残存するケースも検出できます。今回のClaude Codeのケースでは、ソースマップ内にR2バケットへのURLが含まれていたことが流出の直接的経路だったため、参照URLの残存チェックは特に重要な検証項目として位置づけるべきでしょう。

Bunバンドラーのデフォルト生成設定を無効化する際に見落としやすい2つの項目

Claude CodeはBunランタイムを使用してビルドされており、Bunのバンドラーはデフォルト設定でソースマップを自動生成します。Bunでソースマップの生成を無効化するには、ビルド設定でsourcemap: "none"を明示する必要がありますが、見落としやすいポイントが2つあります。

1つ目は、Bunの設定ファイル（bunfig.toml）とビルドスクリプト（Bun.build()のオプション）の両方でソースマップ設定が指定可能であり、競合した場合の優先順位を把握しておく必要がある点です。ビルドスクリプト側の設定が優先される場合が多いものの、設定ファイルの指定が意図せず残っていると予期しない動作を招きます。2つ目は、sourcemap: "external"設定の場合、ソースマップは別ファイルとして生成されるため、バンドル本体には含まれませんが、ビルド出力ディレクトリには残存します。このファイルが.npmignoreのブラックリストから漏れると、まさに今回と同じ事故が再現されるのです。根本的な解決策としては、プロダクションビルドではsourcemap: "none"を明示的に指定し、CI/CDで生成物のチェックを自動化する二重防御が推奨されます。

セキュアバイデフォルト原則に基づくCloudflareバケット公開設定の見直し手順

今回の流出では、ソースマップ内の参照URLが指していたCloudflare R2ストレージバケットがパブリックアクセスを許可する設定になっていたことも、被害拡大の一因となりました。たとえソースマップがパッケージに混入しても、参照先のストレージが適切にアクセス制限されていれば、元のソースコードを直接取得することは困難だったはずです。

「セキュアバイデフォルト（secure by default）」の原則は、システムの初期設定が最も安全な状態であるべきだという考え方です。Cloudflare R2バケットの場合、デフォルトではパブリックアクセスは無効ですが、CDN経由のコンテンツ配信やビルド成果物の共有のために意図的にパブリックアクセスを有効化するケースがあります。こうした設定変更を行う際には、バケット内に機密性の高いファイルが混在しないよう、ビルドプロセスの出力先を公開用と内部用で明確に分離することが不可欠です。さらに、定期的なバケット内容の監査スクリプトを導入し、想定外のファイルがパブリックバケットに配置されていないかを自動検出する仕組みを構築することも重要な対策となります。Anthropicの事例は、クラウドストレージの設定確認がビルドパイプラインの安全性と表裏一体であることを改めて示しました。