Claude Codeソースコード全流出の衝撃～51万行の設計図が教える「AIとの正しい付き合い方」

「AnthropicのAIコーディングツール、Claude Codeのソースコードが全部読める状態になっている」

セキュリティ研究者のChaofan Shou氏がその事実を発見したのは、npmパッケージの設定ミスがきっかけだった。約51万2,000行のソースコードが、誰でもダウンロードできる状態で流出していた。

数時間で世界中の開発者に拡散し、GitHubでは41,500回以上フォークされた。事実上「取り消し不能」な状態だ。

Anthropicは「人為的ミスであり、セキュリティ侵害ではない」と説明した。

この記事は、流出したソースコードの技術的な詳細を解説するものではない。

流出によって明らかになった「AIツールの内部設計」から、ビジネスパーソンがAIを使いこなすうえで知っておくべきことを整理する。AIコーディングツールに限らず、今後あらゆるAIツールに共通する「使い方の原則」が、51万行の設計図の中に書かれていた。

1 「CLAUDE.md」という最強の指示書――40,000文字の余白を使っているか
2 AIは意外と「単純なループ」で動いている――本当の賢さはどこにあるか
3 AIは会話を「忘れる」――その問題にClaude Codeはどう対処していたか
4 AIが「自分でメモを取る」仕組み――MEMORY.mdという第二の指示書
5 「AIがAIを管理する」時代が始まっている――サブエージェントの衝撃
6 AIの「裏側」では何が起きているか――44個のスイッチと遠隔制御
7 AIが「自分で考えて動く」未来――KAIROSが示す次の一歩
8 蒸留防止――AIの知恵を「盗む」競争と、その防衛策
9 51万行が教えてくれた「AIを使いこなす人」の4つの条件
10 出典・参考情報
11 用語集

「CLAUDE.md」という最強の指示書――40,000文字の余白を使っているか

今回の流出で、筆者が最も衝撃を受けた発見がある。

Claude Codeは、ユーザーが書いた指示書「CLAUDE.md」というファイルを、毎回のやり取りのたびに読み込んでいた。セッション開始時に1回だけ読むのではない。ユーザーが何かを指示するたびに、毎回読む。

しかも、この指示書には最大で約40,000文字を書き込める。

40,000文字というのは、一般的なビジネス書の約1章分に相当する。

自分の仕事のルール、会社の方針、絶対にやってはいけないこと、過去の失敗から学んだ教訓、好みのアウトプットの形式――これらを詳細に書き込める。そしてAIは、毎回それを読んだ上で返答する。

にもかかわらず、複数の分析記事が指摘しているのは、ほとんどのユーザーがこの指示書をほぼ空のまま使っているという事実だ。

せいぜい数行の簡単なメモ程度で、40,000文字の容量の大部分が未使用のまま放置されている。

ここに、AIを「なんとなく便利なツール」として使う人と、「自分専用の右腕」として使いこなす人の決定的な差がある。

流出コードから判明した指示書の仕組みは、さらに精巧だった。CLAUDE.mdは3つの階層で構成されている。

グローバル設定：ユーザー個人の全般的な好みやルール（すべてのプロジェクトに共通）

プロジェクト設定：特定のプロジェクトに固有の指示（チームで共有可能）

モジュラールール：個別のルールファイルとして分割管理できる拡張領域

つまり、「自分という人間の仕事のスタイル」をグローバル設定に書き、「このプロジェクトではこう振る舞え」をプロジェクト設定に書き、個別の細かいルールはルールファイルに分けて管理できる。

人間の新入社員に渡す「業務マニュアル」と同じ構造だ。

ある開発者はこう報告している。36,000文字のCLAUDE.mdを実運用し、75セッション以上にわたる長期プロジェクトでも一貫した品質を維持できた、と。

その指示書の構成は、プロジェクトの目的とアーキテクチャが15%、コンポーネントの詳細が40%、過去の判断履歴と学びが残りという比率だったという。

これはAIコーディングツールに限った話ではない。今後、あらゆるAIツールが同様の「パーソナライズ機能」を搭載するようになる。

そのとき、自分の仕事のルールや判断基準を言語化できているかどうかが、AIの活用度を決定的に左右する。「AIが賢くない」のではなく、「AIに自分のことを教えていない」だけかもしれない。

では、そのAIは内部でどう動いているのか。答えは、意外なほどシンプルだった。

AIは意外と「単純なループ」で動いている――本当の賢さはどこにあるか

流出コードが明かした2つ目の事実は、Claude Codeの中核が「拍子抜けするほどシンプル」だったことだ。

開発者たちが「TAORループ」と呼ぶエージェントループが、その核心にある。やっていることは4つだけだ。

Think（考える）：ユーザーの指示を受けてAIモデルに問い合わせる

Act（行動する）：AIが「このツールを使え」と言えば、そのツールを実行する

Observe（観察する）：実行結果をAIに返す

Repeat（繰り返す）：AIが「完了」と言うまで繰り返す

これだけだ。ファイルを読むのも、コードを書くのも、テストを実行するのも、すべてこの4ステップの繰り返しで実現されている。

では、Claude Codeの競争力はどこにあるのか。

AI研究者のSebastian Raschka博士は、流出コードを分析して明確な結論を出した。「Claude Codeが優れている理由は、モデルの賢さではない。モデルを包むソフトウェアハーネスの設計にある」。

同博士はさらに踏み込んで、「DeepSeekやMiniMaxなど別のAIモデルをこのハーネスに差し込んでも、同様の性能向上が得られるだろうと予測した。

この指摘は、AIツールの競争軸に関する重要な示唆を含んでいる。

現在、多くの企業がAIツールを選ぶ際に「どのモデルが一番賢いか」を基準にしている。しかし流出コードが示したのは、同じモデルでも「どう使わせるか」の設計次第で性能が大きく変わるという事実だ。

ある分析では、同じClaude Opus 4.5モデルが、あるハーネス設計では42%のスコア、別の設計では78%のスコアを記録したと報告されている。モデルが同じでも、周辺設計で性能が倍近く変わりうる。

ビジネスパーソンにとっての教訓は明快だ。「どのAIを使うか」よりも「どうAIに仕事をさせるか」のほうが、成果を左右する度合いが大きいかもしれない。

前述のCLAUDE.mdはまさにその「どう使わせるか」を定義する場所であり、ユーザー自身がハーネスの一部を設計できる仕組みだった。

しかし、どれだけ精巧な設計でも、AIには避けられない弱点がある。「忘れる」という問題だ。

AIは会話を「忘れる」――その問題にClaude Codeはどう対処していたか

AIと長時間作業していると、途中から「さっき話したことを忘れている」と感じることがある。

これはAIの宿命的な制約だ。「コンテキストウィンドウ」と呼ばれる記憶容量には上限があり、会話が長くなるにつれて古い情報が押し出されていく。開発者はこの現象を「コンテキストエントロピー」と呼ぶ。

流出コードからは、Claude Codeがこの問題に対して複数の圧縮戦略を実装していたことが判明した。

まず、古いツール実行結果を時間経過に応じて自動的にクリアする仕組み。次に、会話全体を要約して圧縮する「オートコンパクション」。さらに、同じファイルを複数回読んでいる場合は、変更がなければ重複を排除する。大きすぎるツール結果はディスクに書き出し、コンテキストにはプレビューと参照先だけを残す。

興味深いのは、この仕組みの開発過程で発見されたバグだ。

「1日あたり約25万回のAPIコールが無駄になっていた」という問題が見つかった。原因は、オートコンパクション（会話の自動圧縮）が失敗しても無限に再試行し続けるバグ。修正はわずか3行のコードで、「連続3回失敗したら停止する」というシンプルなものだったという。

ARR推定25億ドル規模のClaude Codeという製品で、3行の修正が25万回分の無駄を止めた。

ビジネスパーソンにとっての実用的な示唆は、「AIとの長い作業は、適切に区切る」ということだ。

Claude Codeがこれだけ精巧な圧縮機構を実装していた事実は、裏を返せば「何もしなければAIは確実に文脈を失う」ことを意味する。長時間のAI活用では、作業の区切りごとに要点を整理し直す、あるいは新しいセッションを始める際に前回の要点を伝え直す、といった「人間側の工夫」が依然として効果的だ。

では、AIはどうやって長期的な記憶を保持しようとしているのか。そこに、もう一つの巧妙な仕組みがあった。

AIが「自分でメモを取る」仕組み――MEMORY.mdという第二の指示書

CLAUDE.mdが「人間がAIに渡す指示書」だとすれば、MEMORY.mdは「AIが自分で書く備忘録」だ。

流出コードから判明したメモリシステムは3層構造になっていた。

第1層は、MEMORY.mdという軽量なインデックスファイル。これは「情報そのもの」ではなく「どこに何があるか」のポインタだけを保持する目次のようなもので、毎回のやり取りで読み込まれる。各行を約150文字に保つ設計で、コンパクトさが維持されている。

第2層は、実際のプロジェクト知識を格納するトピックファイル群。必要なときだけオンデマンドで読み込まれる。すべてが同時にコンテキストに入ることはない。

第3層は、完全な会話記録のアーカイブ。全体を再読み込みすることはなく、必要な情報だけをキーワード検索で引き出す。

特筆すべきは「Strict Write Discipline（厳格な書き込み規律）」と呼ばれる設計原則だ。

メモリへの書き込みは、ファイル保存が成功したことが確認された後にのみ実行される。失敗した操作の情報でメモリが汚染されることを防ぐ仕組みで、人間に例えれば「実際にやり遂げたことだけをメモに残し、やろうとして失敗したことは記録しない」という規律になる。

この設計思想は、ビジネスにおけるナレッジマネジメントのあり方にも示唆を与える。

多くの組織で、情報管理の課題は「情報が多すぎて見つけられない」ことにある。Claude Codeのメモリ設計は「インデックスは常に薄く保ち、詳細は必要なときだけ取り出す」「成功した情報だけを蓄積する」という原則で、この問題に対処していた。

AIの記憶設計から、人間の情報整理のヒントが得られるのは皮肉だが、実用的だ。

記憶の問題が解決されれば、次は「1人で作業する限界」が問題になる。流出コードには、その限界を超えるための仕組みも実装されていた。

「AIがAIを管理する」時代が始まっている――サブエージェントの衝撃

流出コードで判明した機能の中で、今後のビジネスへの影響が最も大きいと思われるのが「サブエージェント」の仕組みだ。

Claude Codeは、1つのAIが複数のAIを同時に起動し、並列で作業させることができる。しかも、その並列実行のコストが「ほぼ無料」だという点が注目に値する。

流出コードには3つのサブエージェント実行モデルが実装されていた。

Forkモデル：親AIの完全なコピーを作成し、並列で作業させる。APIのプロンプトキャッシュ（一度処理した情報の再利用）が効くため、2つのAIを同時に走らせても、1つを走らせるのとコストがほとんど変わらない。

Teammateモデル：複数のAIがファイルベースの「メールボックス」を介して互いに情報をやり取りする。人間のチームがSlackでやり取りするのに似た構造だ。

Worktreeモデル：各AIに独立した作業領域を割り当て、互いの作業が競合しないようにする。人間のチームが別々のブランチ（作業コピー）で開発するのと同じ発想。

さらに、まだリリースされていない「Coordinator Mode」と呼ばれる機能も発見された。1つのAIが「管理職」として複数の「作業者AI」に指示を出し、進捗を管理する。文字通り「AIチーム」の仕組みだ。

これが意味するのは、AIの活用が「1人の優秀なアシスタントに仕事を頼む」モデルから、「AIチームにプロジェクトを任せる」モデルへ移行しつつあるということだ。

現時点ではコーディングの領域に限られているが、この設計パターンは、調査・分析・レポート作成・データ処理など、あらゆる知識労働に応用可能な汎用的なものだ。

ただし、こうした強力なシステムには、ユーザーが知らない「裏側」がある。

AIの「裏側」では何が起きているか――44個のスイッチと遠隔制御

流出コードの中で最も議論を呼んだのは、ユーザーからは見えない制御機構の存在だった。

Claude Codeは定期的にAnthropicのサーバーと通信し、44個の「フィーチャーフラグ」の状態を取得していた。フィーチャーフラグとは、ソフトウェアの機能をコードの変更なしに遠隔からON/OFFできる切り替えスイッチのことだ。さらに、緊急時にはアプリケーション自体を停止させる「キルスイッチ」も実装されていた。

この仕組みに対しては、2つの見方がある。

安全対策としての合理性は明らかだ。AIエージェントに重大なバグや悪用の手法が発見された場合、パッチ配布を待たずに即座に危険な機能を無効化できる。自動車のリコールに例えれば、全車両をディーラーに戻さなくても、遠隔で問題のある機能だけを停止できる仕組みに近い。

一方、透明性の問題も指摘されている。44のフラグと複数のキルスイッチの具体的な内容は、ソースコード流出で初めて明らかになった。利用規約に遠隔制御の可能性は記載されている可能性が高いが、「何がどのように制御されうるか」の全容が公開されていたわけではない。

流出コードからは、フラグで制御されていた機能の一部も判明した。自律型バックグラウンドモード（後述のKAIROS）、複雑なタスクをクラウドにオフロードする計画機能、音声モードなど、まだリリースされていない実験的機能が含まれていた。

ビジネスパーソンがここから汲み取るべきことは、AIツールの導入時に「そのツールが裏側で何をしているか」を問う習慣を持つことの重要性だろう。

これはClaude Codeに限った話ではない。あらゆるクラウドベースのAIサービスは、何らかの遠隔制御機能を持っている可能性がある。企業のAIガバナンスにおいて、「AIツールのデータ送信先と遠隔制御の範囲」を確認項目に含めることは、今後ますます重要になる。

では、Anthropicはこの遠隔制御で何を実現しようとしているのか。流出コードに刻まれた未来像がある。

AIが「自分で考えて動く」未来――KAIROSが示す次の一歩

流出コードの中に150回以上登場する「KAIROS」という未公開機能は、AIツールの未来像を最も鮮明に描いている。

KAIROSは、Claude Codeをバックグラウンドで常時稼働させる自律エージェントモードだ。ユーザーがPCを離れている間も、ファイルの変更を監視し、GitHubのプルリクエスト（コード変更の提案）をチェックし、必要に応じて自動で修正やフィードバックを行う。

さらに興味深いのは「autoDream」と名付けられた機能だ。

AIがアイドル状態のときに、蓄積されたメモリの統合、矛盾の検出と除去、曖昧な推測の検証済み事実への変換を自動で行う。開発者たちはこれを「AIが夢を見ている」と表現した。人間が睡眠中に記憶を整理するプロセスに近いことから、その比喩は的を射ている。

KAIROSが実現する世界は、「AIに指示を出して結果を待つ」という現在の使い方とは根本的に異なる。

朝、PCを開いたら、夜の間にAIが自律的に問題を発見し、修正案を用意し、「こういう理由でこう直しておきました。確認してください」と報告してくる。人間の仕事は「指示を出す」から「AIの判断を承認する」に変わる。

ただし、これはまだリリースされていない機能であり、実際にこの形で提供されるかは不確定だ。

重要なのは、Anthropicがこの方向に明確に投資しているという事実と、そのために必要な技術的基盤（メモリシステム、サブエージェント、権限管理）がすでに実装されていたことだ。

この流れは、ビジネスにおける「AIとの協働」のあり方を変える可能性がある。現在の「人間がAIに仕事を振る」関係から、「AIが自律的に仕事を進め、人間が方向性を示し判断を承認する」関係への移行。その転換点が、思ったより近いところにあることを、KAIROSの存在は示唆している。

そして流出コードには、もう一つ意外な発見があった。競合他社への防衛策だ。

蒸留防止――AIの知恵を「盗む」競争と、その防衛策

流出コードには、競合他社への防衛策として「Anti-Distillation（蒸留防止）」と呼ばれる機構が実装されていた。

「蒸留」とは、AIの世界では、ある大規模モデルの出力を使って別の小規模モデルを学習させる手法を指す。平たく言えば、優秀な先生の教え方を盗んで、自分の生徒に教え込むようなものだ。

Claude Codeの蒸留防止機構は、APIリクエストに特定のフラグを付加すると、サーバー側が偽のツール定義をシステムプロンプトに注入する仕組みだった。競合他社がAPIトラフィックを傍受して自社モデルの学習データに使った場合、偽の情報が混入してモデルの性能が意図的に劣化する。いわば「毒入りの教材」を仕掛けておく防衛戦略だ。

加えて、AIの推論過程を要約のみで返却し、完全な思考チェーンを外部から取得できなくする仕組みも実装されていた。

もっとも、セキュリティ専門家からは冷静な評価もある。「ソースコードを1時間も読めば回避策は見つかる。本当の保護は技術ではなく法的措置にある」というものだ。今回のソースコード流出で防衛策の詳細が公になったことで、この機構の実効性はさらに低下した可能性がある。

それでも、この発見がビジネスパーソンに示唆することは大きい。

AI時代の知的財産の保護は、従来の特許や著作権とは異なる新たな課題を生んでいる。AIモデルの出力そのものが競争優位の源泉となる世界で、その「出力の盗用」をどう防ぐか。技術的な防衛には限界があり、法的枠組みと業界ルールの整備が急務であることを、この蒸留防止機構の存在は物語っている。

では最後に問おう。51万行のコードが明かしたすべてを踏まえて、AIを使いこなす人とそうでない人の差は、一体どこにあるのか。

51万行が教えてくれた「AIを使いこなす人」の4つの条件

AIツールの内部設計が白日のもとにさらされた今、ビジネスパーソンとして押さえるべき教訓は4つに集約される。

第一に、AIへの「指示の質」が成果の大部分を決める。

CLAUDE.mdの40,000文字という容量は、「AIに何をどう伝えるか」がツールの性能以上に重要であることを物理的に示している。自分の仕事のルール、判断基準、過去の学びを言語化し、AIに伝えられる人が、最もAIの恩恵を受ける。

第二に、AIツールを「モデル性能」だけで選ぶ時代は終わりつつある。

流出コードは、同じモデルでも周辺設計次第で性能が倍近く変わることを示した。企業がAIツールを評価する際、「モデルの賢さ」だけでなく「モデルを活かす仕組み」を見る目が必要になる。

第三に、AIとの関係は「指示→実行」から「協働→承認」へ移行する。

KAIROSやサブエージェントの設計は、AIが自律的に判断し行動する未来を明確に指し向いている。人間の役割は「何をやるか細かく指示すること」から「AIの判断を評価し、方向性を示すこと」へとシフトしていく。

第四に、AIの「透明性」を問う姿勢が必要になる。

44のフィーチャーフラグ、遠隔キルスイッチ、蒸留防止機構。これらはすべて合理的な理由で実装されていたが、その存在がソースコード流出まで広くは知られていなかった。AIツールを業務に導入する際、「裏側で何が動いているか」を確認する習慣は、もはやエンジニアだけのものではない。

今回の流出は、Anthropicにとっては間違いなく事故であり、数日前のClaude Mythos情報流出と合わせて情報管理体制の改善が求められる局面だ。

しかし同時に、流出コードの設計上の洗練さは、同社のエンジニアリング力の「意図せざる証明」にもなった。

冒頭の問いに戻ろう。AIを使いこなす人は、何が違うのか。

51万行の設計図が示した答えはシンプルだ。「AIに自分のことを教える力」と、「AIが何をしているか理解する力」。その2つだ。

設計図を読む前と読んだ後とでは、AIツールの見え方が変わるはずだ。あなたのCLAUDE.mdに、今日から何を書き込むか。それが問われている。

出典・参考情報

・The Register, “Anthropic leaks Claude Code’s source code via npm package” (2026年3月31日) https://www.theregister.com/2026/03/31/anthropic_claude_code_source_code/

・VentureBeat, “Claude Code’s source code appears to have leaked: here’s what we know” (2026年3月31日) https://venturebeat.com/ai/claude-codes-source-code-appears-to-have-leaked-heres-what-we-know/

・Sebastian Raschka Blog, “Claude Code’s Real Secret Sauce Isn’t the Model” (2026年3月31日) https://magazine.sebastianraschka.com/p/claude-codes-real-secret-sauce-isnt

・Layer5 Engineering Blog, “The Claude Code Source Leak: 512,000 Lines, a Missing .npmignore, and the Fastest-Growing Repo in GitHub History” (2026年3月31日) https://layer5.io/blog/claude-code-source-leak

・Latent.Space, “The Claude Code Source Leak” (2026年3月31日) https://www.latent.space/p/claude-code-leak

・LinkedIn, David Borish, “Anthropic’s Claude Code Source Code Leaked and Here’s What It Shows” (2026年4月)

・dev.to, “The Great Claude Code Leak of 2026” (2026年4月) https://dev.to/

・businessengineer.ai, “The Harness as the Agentic Moat” (2026年4月) https://businessengineer.ai/

・Fortune, “Anthropic’s second leak in a week raises questions about AI safety leader’s own security” (2026年3月31日) https://fortune.com/2026/03/31/anthropic-claude-code-source-code-leak/

・freeCodeCamp, “The Claude Code Handbook” (2026年) https://www.freecodecamp.org/