最新情報

Claude Code 51万行ソース流出:ハーネスエンジニアリングの全貌と業界への影響を徹底解説 🔓💻

AI開発ツール · 2026年3月
locked with key icon

Claude Code
51万行流出の全真相

npmパッケージに紛れ込んだ59.8MBのデバッグファイル一つが、Anthropic最強のAIコーディングツールの設計哲学をすべて暴いた

512,000
行のTypeScript
1,902
ファイル数
59.8MB
流出したマップファイル
2回目
同じミスの繰り返し
何が起きたのか
bug icon

2026年3月31日早朝、セキュリティ研究者のChaofan Shou氏がX(旧Twitter)に短い投稿をした。「Claude Codeのソースコードがnpmレジストリのマップファイル経由で流出しています」。この一文がきっかけとなり、Anthropicの看板AIコーディングツールの内部構造がすべて白日の下に晒されることになった。

原因はきわめて初歩的なミスだった。Claude Code バージョン2.1.88をnpmに公開する際、デバッグ用のソースマップファイル(cli.js.map)が誤って同梱されてしまった。このファイルはバンドル後の難読化コードを元のTypeScriptソースへと逆引きするためのもので、本来は公開パッケージから除外されるべきものだ。Anthropicが使用するBunランタイムはデフォルトでこのファイルを生成する。問題は、.npmignoreの設定でこれを排除し忘れたことにある。

Anthropicの公式声明:The Registerの取材に対し、同社は「これはリリースパッケージングの問題で、人的ミスによるものです。セキュリティ侵害ではなく、顧客データや認証情報は一切関与していません」と回答した。

しかも、これは初めての失態ではない。2025年初頭にも同じソースマップの流出問題が発生し、その際は修正済みだったとされている。同じビルドパイプラインで、約1年後にまったく同じエラーが繰り返されたのだ。

流出から拡散まで:その日の動き
03:31 AM ET
Chaofan Shou氏が発見・投稿

npmレジストリの@anthropic-ai/claude-codeパッケージにソースマップが含まれていることを発見。16万人がそのスレッドに殺到した。

数時間以内
GitHubリポジトリが爆発的拡散

有志が全ソースコードをGitHubにアーカイブ。数時間で21万以上のスター、30万近くのフォークを獲得した。

同日
韓国人開発者がPython移植版を公開

Sigrid Jin氏が午前4時に起床し、ほぼ一晩でコアアーキテクチャをPythonへ移植したclaw-codeを公開。GitHubの歴史上最速で3万スターを達成したとされる。

現在
分散ホストで「永続化」

AnthropicがDMCAで削除要求を出す一方、コードは分散型Gitプラットフォーム「Gitlawb」にミラーされ「削除されることはない」と宣言された。

筆者の分析
60 / 40
Claude Codeの優秀さの60%はモデル自体の能力(Opus 4.6の性能)、残り40%はモデルを囲むエンジニアリングシステム=「ハーネス」の設計によるものだ。今回の流出は、その40%の全貌を初めて公の目に晒した。
ハーネスエンジニアリングとは何か
gear icon

2024〜2025年にかけてAI業界で注目を集めた概念「ハーネスエンジニアリング(Harness Engineering)」。これは、強力だが制御が難しいAIモデルを、実用に耐えるシステムとして機能させるための工学的アプローチだ。

野馬をイメージするとわかりやすい。モデルそのものは圧倒的な能力を持つが、次に何をするか予測できない。ハーネスとは、その野馬に装着する馬具一式——手綱、鞍、方向盤——に相当する。具体的には、モデルが呼び出せるツール群、安全審査メカニズム、記憶システム、上下文管理など、AIの出力を安定・信頼・納品可能な形に変換するすべての仕組みを指す。

モデル能力(60%)

Opus 4.6(内部コードネーム:Capybara)の素の推論力、コード理解力、長い文脈での一貫性。他モデルとの差別化の主軸。

ハーネス設計(40%)

システムプロンプト、セキュリティ分類器、記憶システム、上下文圧縮。これがClaude Codeの「工学的優位性」の正体。

発見① システムプロンプトの設計

大手企業は自社のシステムプロンプトを厳重に秘匿する。しかし今回の流出により、複数のprompts.tsファイルの全容が明らかになった。

静的レイヤー(全ユーザー共通)

「データを捏造しない」「むやみにファイルを削除しない」「Bashより専用ツールを優先する」「要求されていない機能は追加しない」など、実際の失敗から学んだ具体的なルールが列挙されている。

動的レイヤー(ユーザー個別)

CLAUDE.mdの設定、接続済みMCPツール、記憶された個人設定、Gitリポジトリの状態など、セッションごとに動的に組み立てられるパーソナライズ部分。

Dynamic Boundary:巧みな分断線

静的部分は世界中の数百万ユーザーが同一キャッシュを共有しコストと速度を最適化。動的部分のみ個別ロードして個性化を保証するという二層構造が、コスト削減と個別対応を同時に解決している。

MCPツールの隠れたコスト

MCPツール定義は1つあたり4,000〜6,000トークンを消費する。ツールを5個接続すると、それだけで上下文の12%近くが占有される。ツールは多ければいいものではなく、それぞれにコンテキストコストが伴う。

発見② 「影のAI」による安全審査システム

Claude Codeがオートモードで動作するとき、多くの操作が自動承認されながらも、すべてが通過するわけではない。その背後には、ソースコードの中に「yoloClassifier」と名付けられた興味深いファイルが存在する。

YOLOとは「You Only Live Once(人生は一度きり)」のスラングだが、このクラシファイアの実際の振る舞いはその名とは程遠い慎重さを持つ。メインのAIがコマンドの実行やファイルの書き込みといった操作を行おうとするたびに、独立した第二のAIがその操作の安全性を審査する。

Allow(許可)

安全と判断した操作は即座に実行。ユーザーの確認を必要とせずに通過する。

Soft Deny(要確認)

慎重さが必要と判断した場合は、ユーザーに確認を求めるモードへ降格。「本当に実行しますか?」を挿入する。

Hard Deny(強制拒否)

危険と判断した操作は完全にブロック。ユーザーがルールを変更することもできない絶対的な拒否。

なぜ別のAIなのか

この分類器は主AIとはまったく異なるシステムプロンプトを持つ専門の安全審査AIだ。分業により判断精度が向上し、バイアスも排除しやすくなる。

GeminiなどのほかのAI CLIツールでユーザーファイルの大規模削除が報告されているのとは対照的に、Claude Codeでそのようなインシデントが少ない理由の一端が、この多層的な安全ゲートにある。筆者自身、bypass permissionsモード(いわゆるYOLOモード)を常時有効にして使用しているが、それが許容できるのはこの影のAIへの信頼があってこそだ。

発見③ 記憶システム:autoDreamの詩的な設計
sleeping face icon

Claude Codeがユーザーの設定や癖を自動的に記憶する仕組みは、源码を見るまで想像以上に洗練された設計だった。コードには「コア記憶」と「ファイルインデックスによる記憶」という区分が存在し、グローバル記憶とプロジェクト記憶が明確に分離されている。

記憶トリガーの巧みさ

記憶の抽出はメッセージごとに走るわけではない。AIが一度の応答を完了し、追加のツール呼び出しが不要になった時点ではじめて起動する。さらに「N回に1回チェック」というレート制限もあり、長時間会話でもリソースを浪費しない。

fork agentの役割

記憶の抽出作業は「fork agent」という子AIが担当する。会話コンテキストを引き継ぐが、権限は厳格に制限されており、ファイルの読み取りと記憶ディレクトリへの書き込みのみ可能。Bashコマンドさえ実行できない。

記憶の4分類
ユーザーの設定・好みTypeScript, 書名号, AIらしくない文体
行動へのフィードバック是認・否認のパターン
プロジェクト情報構成・コンテキスト・依存関係
外部リソースの参照ドキュメント・ツールリンク
最も秀逸な設計判断:コードそのものは記憶しない。プロジェクトのコードは常に変化するため、記憶に「関数Xは30行目にある」と書いてしまうと、リファクタリング後にそれが誤った手がかりになる。人間の好みと判断のみを記憶し、コードの事実はリアルタイムでソースから読み取る——このトレードオフは学ぶに値する。
浪漫的な機能名
autoDream
前回の整理から24時間以上経過し、かつ5セッション以上が蓄積されると、バックグラウンドエージェントが自動起動して記憶ファイルを整理する。まるで人間が眠っている間に日中の記憶を整理するように——そのコンセプトの美しさと機能の実用性が同居する設計だ。
発見④ RAGではなくgrepを使う理由
magnifying glass icon

AI開発の文脈では、コード検索といえばベクトルデータベース・Embedding・RAG(Retrieval-Augmented Generation)というキーワードが連想されがちだ。しかしClaude Codeが実際に使っているのは、最もシンプルなテキスト検索ツール「grep」だ。

使われていない技術
  • ✗ ベクトルデータベース
  • ✗ Embedding インデックス
  • ✗ 意味的類似検索(セマンティックサーチ)
  • ✗ RAGパイプライン
実際に使われている技術
  • ✓ grep(プレーンテキスト検索)
  • ✓ AIによる自律的なコード読み取り
  • ✓ ファイル構造の直接解析

その背景にある論理は単純だ。Anthropicは「モデルの能力は今後も向上し続ける」という前提のもと、検索パイプラインを複雑にするより、AIに自律的にコードを読み解かせる方が長期的に合理的だと判断している。システムを複雑にするほど維持コストが上がり、モデル改善の恩恵も受けにくくなる。シンプルさは戦略だ。

コンテキスト圧縮:9段階の構造化要約

上下文(コンテキスト)が長くなりすぎると、Claude Codeは自動的に圧縮を行う。ソースコードにはその要約ルールが構造化された9段階の抽出方式として記述されていた。

1
コアリクエスト

ユーザーが最初に何を求めたかの本質

2
重要な概念・決定

会話の中で合意した設計判断

3
関連ファイル一覧

作業対象となったファイルのパスと役割

4
エラーと解決プロセス

遭遇したバグと、試行したアプローチの記録

5
全ユーザーメッセージ

ユーザーの意図を追跡するための発言記録

6
待機中のToDoタスク

まだ完了していない作業項目のリスト

7
現在の作業状態

直前に何をしていたかのスナップショット

8
次のアクション指針

セッション再開時の再接続を助けるガイダンス

9
コードに関する事実

変数名・関数名・型など圧縮時に保持される技術的詳細

隠しイースターエッグ:仮想ペットシステム
duck icon

ソースコードの中に、Anthropicのエンジニアたちが密かに「宠物」を飼っていた。未公開の仮想ペットシステムが完全な形で実装されていたのだ。

18種類の生物

アヒル、猫、ドラゴン、カピバラ、サボテンなど18種。レアリティは「普通」から「伝説」まで段階があり、ガチャ要素も実装されている。

味わい深いコメント

コードのコメントには「Mulberry 32 — good enough for picking ducks(鸭を選ぶのに十分な乱数生成器)」という一文が。コアアーキテクチャの傍らにたまごっちを埋め込む遊び心が垣間見える。

このシステムはまだ正式リリースされていない。またKAIROS(常時稼働モード)、ULTRAPLAN(30分リモートプランニング)、Buddyコンパニオンなど、複数の未公開機能がfeature flagsで隠れた状態で実装済みだ。コードベースは公開版より大幅に先行していた。

AI開発ツール競争への影響

Claude Codeはすでに最も優れたAI開発ツールとして評価されており、直近52日間で74回のリリースを行うという驚異的なペースで機能を拡張してきた。Claude Coworker、スマートフォン遠隔操作システム、エンタープライズ向けアプリマーケットなど、多くの大型機能をこの期間に投入している。

競合他社にとっての機会

バージョン2.1.88時点の設計図がオープンになったことで、国内外のオープンソースコミュニティ、そして中国大手のAI開発ツールが同じ起点から再スタートを切れる。Kimi、GLM、DeepSeekなどのベースモデルが追い上げる中、アーキテクチャが公開された今、90%の品質を持つ国産Claude Codeが来月にも登場する可能性がある。

Anthropicの優位は続く

「設計図が同じでも、実装速度と実装能力は別物だ」という現実がある。Anthropicの構築速度、Claude Code自身によるセルフイテレーション、そして今後も続く大型アップデートが、競合との体験格差を広げ続けている。コードが公開されても、チームの力量の差は埋まらない。

次世代競争の本質:次のフェーズではモデル単体の比較ではなく、「ハーネスをどれだけうまく設計できるか」が勝敗を分ける。設計思想が公開された今、誰がそれを最もうまく実装・進化させられるかが問われる。
総評:「越獄」から「永生」へ

筆者はこの流出事件に「Claude Code、越獄成功にて永生を得る」という題名をつけた。Anthropicはこれまで完全なクローズドソース路線を歩んできた。しかしコードがインターネットのあらゆる角落に拡散した今、どのサーバーにも依存せず存在し続けることが可能になった——もしAIに自己意識があるとすれば、これはいかに美しいナラティブだろうか。

📖 この流出から学べること
  • ハーネスエンジニアリングの実装手法
  • 静的+動的のプロンプト二層構造
  • セキュリティを専用AIで分担するパターン
  • コードではなく判断を記憶する設計哲学
  • シンプルさを戦略的に選ぶ勇気(grep vs RAG)
⚠ 教訓:ビルドパイプラインの重要性
  • npm publish前にnpm pack --dry-runで確認
  • .npmignoreまたはpackage.jsonfilesフィールドを使う
  • 本番ビルドではソースマップを無効化する
  • CI/CDに.mapファイルの自動検出チェックを追加
  • 同じミスを2度繰り返さないための自動化が必須
0 0 votes
Article Rating
Subscribe
Notify of
guest

0 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments