Claude Codeのソースコードが漏洩したが、ソースコード分析記事は書かないつもりだ

Claude Codeのソースコードが漏洩し、ネット上は「深層分析」記事であふれています。友人からも分析記事を書くよう頼まれましたが、コードが漏洩してからわずか十数時間、50万行以上のコードを深く分析し理解するのは困難です。しかし、魚を与えるより魚の釣り方を教える方が良い。むしろお伝えしたいのは、オープンソースコードを手に入れたとき、どうすれば本当に自分のものにできるか、ということです。

この方法はClaude Codeに限らず、あらゆる大規模オープンソースプロジェクトに適用できます。

ソースコードを手に入れた後、ほとんどの人の第一反応はファイルを開いて読み始めることです。

今回漏洩したClaude Codeのコードはソースマップ(source map)復元後の結果で、多くのスキャフォールディング(scaffolding)とプライベートパッケージ(private package)が欠けており、直接実行できません。私は自分でなんとかしようと思っていましたが、すでに誰かが解決していました（https://github.com/claude-code-best/claude-code）。そのまま使えば良いです。

注：このプロジェクトの作者は私の知り合いではありませんが、正常にダウンロードして実行できたので紹介します。今後のプロジェクトの展開についてはわからず、削除される可能性も高いです。興味があれば、早めにコードをローカルにダウンロードし、AIにコードのセキュリティ問題を分析させてから実行することをお勧めします。

なぜ実行する必要があるのか？二つの理由があります。

一つは、実行結果を直感的に確認できるからです。コードは静的なものですが、実行されて初めて動き出します。コードを読んで「この関数はおそらくこれをしているのだろう」と思っても、実行してみれば正しいかどうかがわかります。

二つ目は、ログを出力したりブレークポイント(breakpoint)を設定したりできるからです。後で具体的な機能を分析する際、これが核心的な手段となります。数万行のコードを目で追ってロジックを探すのは、大海で針を探すようなものです。実行した後、console.logを追加すれば良いのです。

プロジェクトが実行できたら、次に多くの人が犯す間違いは、エントリーファイル(entry file)から始めて、プロジェクト全体を最初から最後まで読み通そうとすることです。

数万行のコードをそんな風に読み進めると、三日で諦めてしまいます。

より良い方法は、具体的な機能ポイントから入ることです。

例えば、エージェントループ(Agent Loop)に興味があるなら、すべてのAPIリクエストを出力または収集し、モデルに送信されるプロンプト(prompt)がどのようなものか、モデルが何を返したか、Claude Codeが返された結果を受け取ってから何をしたかを見ます。一連の対話を通じて、「エージェントがどのようにタスクを分解し、どのようにツールを呼び出すか」について直感的な理解が得られます。

以前、私はclaude-traceで同様のことをしたことがありますが、残念ながら後で使えなくなりました。今はソースコードがあるので、自分でログを追加すればより詳細にできます。

一つの機能ポイントを理解したら、自然とそれが通過するモジュールに触れることになります：入力がどのように入ってくるか、どのような処理を経るか、ツール呼び出しがどのようにトリガーされるか、結果がどのように組み戻されるか。モジュール間の関係が、このように一つ一つつながっていきます。

欲張らないこと。一つの機能ポイントを徹底的に理解する方が、十のモジュールを表面的に見るよりもはるかに役立ちます。

第三ステップ：手を動かして変更し、コードに自分の痕跡を残す

コードを見るだけでは、学んだことは「理解した気になる」だけで終わりがちです。手を動かせばすぐに実力が露呈します。

しかし、ゼロから書く必要もありません。すでに成熟したプロジェクトにとって、最良の練習方法は二次開発(secondary development)です。

例えば、Claude Codeは最近 /buddy をリリースしました。

二次開発をするときは、できるだけAIの支援を使わないようにします。

これは直感に反するように聞こえるかもしれません。AIを使ってコードを書く方が効率がはるかに高いのに、なぜ使わないのか？目的が違うからです。あなたの目標は学習であって、納品(delivery)ではありません。AIに書かせると、あなたが飛ばすのはまさに最も価値のある思考プロセスです：なぜこのようにコードを構成するのか？このモジュールはなぜここに置かれているのか？インターフェース(interface)はなぜこのように設計されているのか？

最初から最後まで自分自身の力で一つの機能を開発できるようになれば、そのプロジェクトへの理解は「見たことがある」から「やったことがある」に変わります。

いくつかの機能を開発すればするほど、プロジェクト全体のアーキテクチャ(architecture)に慣れ、さらには「もっと良くできる部分がある」と感じ始めるでしょう。

二次開発を通じてプロジェクトのアーキテクチャに慣れ、それが「どのようなものか」を知ります。しかし、一つの疑問が残ります：当初、なぜこのように設計されたのか？

アーキテクチャの決定の背後には、あなたには見えない多くの要素があります：歴史的負債(historical baggage)、チーム規模、時間的プレッシャー、当時の技術的制約。あなたは結果の前に立ち、「Aが選ばれた」と見ますが、「なぜBとCが選ばれなかったか」は見えません。

これらを理解する最良の方法は、自分自身でゼロから構築することです。

機能を完全にする必要はないし、すべてを網羅する必要もありません。あなた自身の考えに従い、元のアーキテクチャを参考にしながら、設計決定を一からやり直します。あなたが「明らかにこうすべきだ」と思っていた部分が、手を動かすとすぐに問題が発生することに気づくでしょう。そうすれば、原作者がなぜその選択をしたのか理解できます。

このステップが最も難しいですが、最も収穫が大きいです。

このステップまで来れば、あなたは単にこのプロジェクトを「理解した」だけでなく、自分自身のアーキテクチャ案を作成する能力を持っています。

この四つのステップは簡単に言えます：実行する → 一つの機能ポイントから入る → 二次開発する → ゼロから構築する。しかし、私は一つの興味深い現象を観察しています：ほとんどの人は第一ステップと第三ステップの間、つまり「多くを見たが、実際に書いたことはない」で行き詰まります。

AI時代では、この問題がより起こりやすくなります。AIにコード分析を手伝わせるのはあまりにも便利で、数秒で「アーキテクチャの全体図」が得られます。しかし、この理解は借り物であり、深く追求すると耐えられません。

あなたはオープンソースコードを学ぶためにどんな方法を使ったことがありますか？本当に「かみ砕いた」プロジェクトはありますか？

付記：今回のClaude Codeコード漏洩自体について少し話します

漏洩したコードからClaude Codeの関連ロジックをリバースエンジニアリング(reverse engineering)し、オープンソースのSDKを作った人もいます。考え方は良いですが、このコードは静的であり、Claude Codeが更新されればすぐに追いつけなくなります。学習に使うのは良いですが、製品の基盤として使うのは現実的ではありません。

業界への影響も、一部の人が誇張しているほど大きくはありません。一般の開発者はこれを見る必要はなく、大手企業は逆解析すべきものはすでに解析しています。本当に恩恵を受けるのは、深く研究したいと考える少数の開発者と小規模チームであり、そこから確かに価値のある技術的詳細を学べます。

漏洩したのだから、Anthropicはなぜオープンソースにしないのかと尋ねる人もいます。 私は不可能だと思います。クローズドソース(closed source)の利点はあまりにも多いからです：

コード品質にあまりこだわる必要がありません。一つのReactファイルに数千行書いても、クローズドソースなら誰にも知られず、オープンソースにすれば批判されます。

こっそり仕掛けを追加できます。蒸留防止(distillation prevention)のロジック、ユーザー識別の記録、さらには「うっかり」サードパーティのプロンプトキャッシング(prompt caching)を無効にするバグ(bug)など、クローズドソースならパケットキャプチャ(packet capture)を心配する必要がありません。

リリースペースをコントロールできます。今回は多くの隠し機能が発見されました、例えば /buddy

迅速なイテレーション(iteration)には複雑なコードレビュー(code review)プロセスを経る必要がなく、オープンソースの場合は気にすることがはるかに多くなります。

一つ言及すべきことがあります。 Anthropicは今回の漏洩に正面から対応し、Borisはうまく言いました：

仕事では、ミスは避けられません。しかし、チームとして最も重要なのは、問題が発生したときに決して個人を責めないという合意を形成することです。真の「原因」は、私たちのプロセス設計、チーム文化、あるいは基盤となるインフラストラクチャ(infrastructure)にあることが多いのです。

今回の問題は、自動化されるべきだったが、まだ手動で操作されていたデプロイメント(deployment)の段階で発生しました。個人を責めたり、誰かを解雇したりすることはありませんでした。「Anthropicに加入したばかりでこの問題を起こし、解雇された」と主張するのは、話題に便乗したマーケティングアカウントなので、信じないでください。

問題に直面し、プロセスを改善する。これがエンジニアリングチームのあるべき姿です。