Claude Codeアーキテクチャ詳解：流出ソースが明かす内部構造
Claude Codeの流出ソースは51万2千行の本番TypeScriptコードを公開した。ツールシステム、クエリエンジン、マルチエージェントパターン、コンテキスト圧縮まで、アーキテクチャを完全に解説する。
こんにちは、みなさん。Doraです。2026年3月、私はそんな深みにはまるつもりはありませんでした。こんなメッセージが目に飛び込んできたのです：「Claude Codeのソースコードが、npmレジストリのマップファイル経由でリークされた。」
開いていたタブを閉じて、振り返ることもなく進みました。
その後に続いたのは、実際に本番運用されているAIツールがどのように構築されているかを研究した、本当に興味深い午後のひとときでした。リークのドラマが目的ではありません——それはすぐに飽きます——むしろ、このコードが稀有なものだからです：実際に出荷され、商業的に支配的なエージェント型CLIが512,000行の詳細で検証できるのです。
気づいたことをご紹介します。
リークされたソースが貴重なアーキテクチャ研究の機会である理由
Claude Codeのリーク後、ソースが公開されました——Anthropic自身のnpmパッケージに誤って設定された.mapファイルを通じて露出したもので——開発者たちはすぐにこれがチャットAPIのラッパーではないと気づきました。cybersecuritynews.comによるインシデントの分析によると、露出した内容は約1,900ファイル、厳格なTypeScriptで512,000行以上に及び、主要エントリポイントだけで785KBもありました。
スタック自体もすでに興味深いものです：ランタイムにBun（Node.jsではなく）、ターミナルUIレンダリングにInkを使ったReact、そしてスキーマバリデーションにZod v4が全体的に使われています。CLIでReactコンポーネントパターンを使うということは、ターミナル内で状態管理、再レンダリング、コンポーザブルなUIコンポーネントが動いているということです。意図的で大胆な選択です。
ミームを超えてこれを研究する価値がある理由：ここにあるClaude Codeアーキテクチャのパターンは、真剣にエージェント型システムを構築するあらゆるチームに適用できます。
ツールシステム——40以上の独立したパーミッションゲート付きモジュール
最初に目を引いたのは、ツールシステムがいかにクリーンに分離されているかでした。すべてのツールは独自の入力スキーマ、パーミッションレベル、実行ロジックを——独立して——定義します。ツール間で共有されるミュータブルな状態はひとつもありません。
BashToolとFileReadToolは同じレジストリに存在しますが、本質的に異なるリスクプロファイルを持ちます。Bash実行はシステム状態を変更できますが、ファイル読み取りは読み取り専用です。このアーキテクチャはそれに応じた扱いをしており、一律のポリシーを適用するのではなく、それぞれ独自のパーミッションレベルの後ろにゲートしています。この分離は本番のエージェント型システムにおいて非常に重要です——ツール間でパーミッションモデルが漏れると、セキュリティと信頼性の問題を引き起こす時限爆弾になりかねません。
AgentToolが巧みです。システムがサブエージェントを単なる別のツール呼び出しとしてスポーンできるようにします——特別なオーケストレーション層も、別プロセスモデルも不要です。サブエージェントは同じツールレジストリのファーストクラス市民です。その設計上の決定がアーキテクチャをフラットで予測可能なものに保っています。
ベースのツール定義だけで約29,000行のTypeScriptに及びます。これは肥大化ではありません——厳格なスキーマバリデーション、パーミッション強制、エラーハンドリングがこの規模で実際に行われているとこうなるということです。AnthropicのClaude Code公式ドキュメントはこのツール中心の哲学を確認しています：ツールこそがシステムをエージェント的にするものです。
46,000行のクエリエンジン——Claude Codeの真の頭脳
QueryEngine.tsは46,000行です。少し考えてみてください。
これはすべてのLLM API呼び出し、ストリーミング、キャッシング、オーケストレーションを処理するモジュールです。単一ファイルで。これはレッドフラグのように聞こえるかもしれません——コードベースの慣習によっては、疑問に思うのは正当です——しかし理由は一貫しています：モデルAPIに触れるものがすべて一か所にあり、リトライロジック、レート制限処理、コンテキストバジェット管理、ストリーミングエラーがすべて一緒に考慮されているということです。
自己修復クエリループが私を驚かせた部分です。コンテキストバジェットが上限に近づいても、エンジンはクラッシュしたり助けを求めたりしません。自動的に圧縮をトリガーし、上限の前にバッファを確保して、これまでの議論の構造化されたサマリーを生成します。これはハックではなく——設計された動作です。長時間稼働するエージェントセッションを構築する人にとって、このパターンは直接学ぶ価値があります。
マルチエージェントオーケストレーション——コーディネーター、ワーカー、そしてメールボックスパターン
マルチエージェントシステムは、危険な操作に対してリークされたソースがメールボックスパターンと呼ぶものを使用します。実際にどういう意味かというと：タスクを実行しているワーカーエージェントは、高リスクな操作を独立して承認できません。代わりに、コーディネーターのメールボックスにリクエストを送り、待機します。コーディネーターが評価して承認または拒否します。
アトミッククレームメカニズムは、2つのワーカーが同じ承認を同時に処理することを防ぎます——並列実行を持つあらゆるシステムで微妙だが重要な詳細です。すべてのエージェント間で共有されるメモリ空間により、チームは冗長な再フェッチなしに一貫したコンテキストを維持します。
これは、すべてのエージェントが完全な自律性で動作するナイーブなマルチエージェント設計からの意味のある逸脱です。承認ゲート付きのコーディネーター/ワーカー分割は、混乱なく並列処理を実現する方法です。独自のエージェント型システム向けにオーケストレーション層を構築するチームは、Anthropicのエージェントパターンドキュメントを設計前に読むとよいでしょう。
三層コンテキスト圧縮——長時間セッションのためのエンジニアリング
これはおそらく、本番AIアプリケーションを構築する人にとって、コードベース全体で最も直接的に有用なエンジニアリングです。
Claude Codeは3つの異なる圧縮戦略を使用し、それぞれ異なるポイントでトリガーされます：
MicroCompactはキャッシュされたコンテンツをローカルで編集し、APIコールはゼロです。古いツール出力は直接トリムされます。高速、低コスト、透明。
AutoCompactは会話がコンテキストウィンドウの上限に近づいたときに発火します。13,000トークンのバッファを確保し、最大20,000トークンのセッション構造化サマリーを生成します。組み込みのサーキットブレーカーがあり——3回連続して圧縮が失敗した後は、リトライを止めます。無限ループはありません。
Full Compactは会話全体を圧縮し、最近アクセスされたファイル（ファイルあたり5,000トークン上限）、アクティブなプラン、関連するスキルスキーマを再インジェクトします。圧縮後、作業バジェットは50,000トークンにリセットされます。
注目すべきは、このアーキテクチャが圧縮を完全にスキップするツールに何を意味するかです。コンテキストバジェットを管理しないエージェント型ツールは、単純にスケールで失敗します——静かに劣化するか、ハードエラーに当たるかのどちらかです。三層アプローチは、後から付け足すのではなく、最初からセッション長寿命のために設計する稀有な例です。
アーキテクチャとしてのフィーチャーフラグ——本番環境には存在しない108モジュール
リークされたソースからの、あまり議論されていない発見のひとつ：108のフィーチャーゲート付きモジュールが、BunのコンパイルタイムデッドコードエリミネーションによってExternal ビルドから取り除かれています。
KAIROS、VOICE_MODE、DAEMON——これらはインストールするバージョンには存在しません。ソースにはコードがありますが、Bunはフィーチャーフラグの設定に基づいてコンパイルタイムにそれを除去します。本番バンドルはクリーンに出荷されます。これが、ユーザーの手元にあるものに触れることなく新しい機能を繰り返し開発する方法です。
皮肉はよく記録されています：内部のコードネームがgitコミットや出力に現れることを防ぐために設計されたサブシステム、Undercover Modeが、リークされたソースに存在していました。リークを防ぐために構築されたシステムがリーク自体を防げなかったのです。壊滅的なセキュリティ上の失敗ではありませんが、ソフトウェアデリバリーパイプラインでリスクが実際にどこに蓄積するかについての教訓的なものです。
コアループに組み込まれたテレメトリ
リークされたソースの2つのテレメトリシグナルが気になっています：
フラストレーション指標は、UXシグナルとして罵り言葉の頻度を追跡します。ユーザーがツールに悪態をついているなら、何かが壊れています——遅延指標ではなく先行指標です。
「continue」カウンターは、ユーザーがセッション中に「continue」という単語を入力する頻度を追跡します。エージェント型CLIにとって、これはストール——エージェントが勢いを失い、人間が前に進めるために促さなければならなかった瞬間——の代理指標です。
どちらも虚栄指標ではありません。どちらも標準的なアナリティクスでは見逃すような特定の失敗モードを表面化します。拡張されたインタラクションセッションを持つAI製品を構築しているなら、このようにエージェントの動作を計測することはエンジニアリング時間の価値があります。
これがビルダーにスタック決定について何を示すか
このClaude Codeアーキテクチャを研究した正直な結論：本番のエージェント型CLIをゼロから構築することは、かなりのエンジニアリング上のコミットメントです。ツールシステム、クエリエンジン、マルチエージェントオーケストレーション、コンテキスト圧縮、テレメトリは合わせて、月ではなく年単位の反復を表しています。
これはビルドに反対する議論ではありません。何を引き受けるかについて明確にするための議論です。メールボックス承認システムや三層圧縮のようなパターンは移植可能です——コアのアイデアを実装するのに512,000行は必要ありません。
ビルド対バイの計算が変わるのは、モデルアクセスと集約においてです。このアーキテクチャは単一のモデルプロバイダーへの直接アクセスを前提としています。複数のモデルプロバイダーで作業するチーム、またはモデルに依存しない状態を保つ必要がある製品を構築するチームは、まったく異なるトレードオフに直面します。
ここにあるパターンは借用する価値があります。複雑さは、複製にコミットする前に理解する価値があります。
FAQ
Claude Codeのツールシステムは標準的なファンクションコーリングとどう違うのですか？
標準的なファンクションコーリングはツールをフラットなリストとして扱います。Claude Codeはツールごとのパーミッションゲート、分離された実行コンテキスト、すべての境界でのスキーマバリデーションを追加します——BashToolがシステム状態を変更できる場合に重要な、ツール間の状態漏洩を防ぎ、最小権限アクセスを強制します。
メールボックスパターンとは何で、ビルダーはいつ使うべきですか？
危険な操作をワーカーエージェントから承認のためにコーディネーターにルーティングし、自律的に実行するのではなくします。並列エージェント実行があり、高リスクなアクションにヒューマンインザループや階層的な承認メカニズムが必要な場合はいつでも使用してください。スループットのコスト、安全性の向上。
Claude Codeはスケールでのコンテキストウィンドウの制限をどのように処理しますか？
三層圧縮：MicroCompact（ローカル編集、APIコストなし）、AutoCompact（上限近くでトリガー、予約済みトークンバッファで構造化サマリーを生成）、Full Compact（選択的ファイル再インジェクション付きの会話全体の圧縮）。手動介入なしの長時間セッションのために設計されています。
コンパイルタイムフィーチャーフラグとは何で、なぜ本番AIツールはそれを使用するのですか？
未リリースの機能のコードをソースに存在させながら、本番ビルドには現れないようにします。Bunはコンパイルタイムにフラグオフされたコードを削除するため、外部ユーザーは準備ができていない機能に遭遇しません——出荷と準備状態を分離します。
アーキテクチャのインスピレーションのためにリークされたソースを研究・参照することは合法ですか？
慎重に扱う価値があります。リークされたソースはAnthropicの知的財産です。教育目的でアーキテクチャのパターンを研究することは、コードを直接コピーすることとは異なる領域にあります。Anthropicの公式ドキュメントは、彼らのシステムの上に構築するものに対して適切なリファレンスのままです。疑問がある場合は、独自の法律顧問に相談してください。
私が繰り返し考えることは、このアーキテクチャがいかに優雅に失敗を管理することについてのものかということです。圧縮のサーキットブレーカー、危険な操作のためのメールボックスパターン、ツール間のパーミッション分離——これらは楽観的な設計ではありません。物事がうまくいかないのを見て、それを回避するためにエンジニアリングすることを決めた人々によって構築されています。
それは機能速度とは異なる種類の成熟度です。
今日のシェアはここまでです。またお会いしましょう。
