Claude Codeのソースコード分析：なぜ他のAIプログラミングツールより優れているのか？

元のタイトル：「AnthropicのClaude Codeソースコードを1記事で理解する：なぜ他より優れているのか？」

元の著者：Yuker、AI研究者

2026年3月31日、セキュリティ研究者のChaofan Shou氏は、AnthropicのClaude Codeパッケージのnpmリリースにおいて、ソースマップファイルが削除されていないことを発見しました。

つまり、Claude Codeの全TypeScriptソースコード（51万2000行、1903ファイル）がインターネット上に公開されていたことになります。

もちろん、数時間でこれほどのコードを読み通すことは不可能ですが、私は以下の3つの疑問を持ってこのソースコードにアプローチしました。

1. Claude Codeと他のAIプログラミングツールの根本的な違いは何なのか？

2. なぜそのコード作成の「感覚」が他より優れているように思えるのか？

3. 51万行のコードには一体何が隠されているのか？

読み終えた後の私の最初の反応は、「これは単なるAIプログラミングアシスタントではなく、オペレーティングシステムだ」というものでした。

I. ストーリーから始めよう：リモートプログラマーを雇うとしたら

リモートプログラマーを雇い、あなたのコンピュータへのリモートアクセス権を与えたと想像してください。

あなたならどう扱いますか？

Cursorなら：隣に座らせ、コマンドを入力するたびにあなたが横から見て「許可」をクリックします。簡単ですが、常に目を光らせておく必要があります。

GitHub Copilot Agentなら：自由に遊べる真っさらな仮想マシンを与えます。作業が終わったらコードを提出させ、あなたがレビューしてマージします。安全ですが、彼らはあなたのローカル環境を見ることができません。

Claude Codeなら：

コンピュータを直接使わせますが、極めて高度なセキュリティシステムを装備させます。何ができて何ができないか、どの操作にあなたの承認が必要か、どれを自分で実行できるか。たとえrm -rfを実行したくても、実行前に9段階のレビューを通過しなければなりません。

これらは3つの全く異なるセキュリティ哲学です：

なぜ did Anthropicは最も困難な道を選んだのでしょうか？

そうして初めて、AIがあなたのターミナル、環境、設定と連携できるからです。これこそが「クリーンルームでコードを書いてコピーする」のではなく、「真にコーディングを助ける」ということの意味だからです。

しかし、その代償は何でしょうか？彼らはそのために51万行のコードを書いたのです。

II. あなたが認識するClaude Code vs 実際のClaude Code

多くの人は、AIプログラミングツールが次のように動作すると考えています：

ユーザー入力 → LLM API呼び出し → 結果取得 → ユーザーに表示

実際のClaude Codeは次のように動作します：

ユーザー入力
→ 7層のシステムプロンプトを動的に組み立て
→ Gitの状態、プロジェクトの慣習、履歴メモリを注入
→ 42個のツールそれぞれにマニュアルを付随
→ LLMが使用するツールを決定
→ 9層のセキュリティレビュー（AST解析、ML分類器、サンドボックスチェック...）
→ 権限競合の解決（ローカルキーボード/IDE/フック/AI分類器が同時に競合）
→ 200msのアンチ疲労遅延
→ ツール実行
→ ストリーミング形式で結果を返す
→ コンテキストが制限に近づいているか？ → 3段階圧縮（マイクロ圧縮 → 自動圧縮 → 完全圧縮）
→ 並列処理が必要か？ → サブエージェントの群れを生成
→ タスク完了までループ

皆さんも上記について非常に興味があると思いますが、心配しないでください。一つずつ紐解いていきましょう。

III. 第一の秘密：プロンプトは書かれるのではなく、「組み立てられる」

src/constants/prompts.tsを開くと、この関数が見えます：

SYSTEM_PROMPT_DYNAMIC_BOUNDARYに注目してください。

これはキャッシュの区切り文字です。区切り文字より上の内容は静的であり、Claude APIによってキャッシュされ、トークンコストを節約できます。区切り文字より下の内容は動的です。現在のGitブランチ、CLAUDE.mdプロジェクト設定、以前に提供された好みの記憶など、各対話はユニークです。

これは何を意味するのでしょうか？

Anthropicは、最適化のためにキューワードをコンパイラの出力として扱います。静的部分は「コンパイル済みバイナリ」であり、動的部分は「ランタイムパラメータ」です。このアプローチの利点は：

1. コスト削減：静的部分はキャッシュされ、冗長な課金を回避

2. 速度：キャッシュヒットにより、それらのトークンの処理を直接スキップ

3. 柔軟性：動的部分により、各対話が現在の環境を認識可能

各ツールには独自の「ユーザーマニュアル」がある

さらに驚くべきことは、各ツールディレクトリにprompt.tsファイルが含まれていることです。これはLLM専用に調整されたユーザーマニュアルです。

BashTool（src/tools/BashTool/prompt.ts、約370行）を見てください：

これは人間向けの文書ではなく、AIの行動規範です。Claude Codeが起動するたびに、これらのルールがシステムプロンプトに注入されます。

これが、Claude Codeが勝手にgit push --forceを強制しない理由です。他のツールではそうするかもしれませんが、モデルが賢いからではなく、キューがすでにルールを明示しているからです。

さらに、Anthropicの内部バージョンはあなたが使っているものとは異なります

コードにはこのようなブランチが多数あります：

antはAnthropicの内部スタッフを指します。彼らのバージョンには、より詳細なコードスタイルガイドライン（「WHYが明白でない限りコメントを書くな」）、より積極的な出力戦略（「逆ピラミッドライティング」）、およびまだA/Bテスト中の実験的機能（Verification Agent、Explore & Plan Agent）が含まれています。

これは、AnthropicがClaude Codeの最大のユーザーであることを示しています。彼らは自社製品を開発するために自社製品を使っているのです。

四. 第二の秘密：42個のツール、しかしあなたは氷山の一角しか見ていない

src/tools.tsを開くと、ツールレジストリが見えます：

42個のツールがありますが、そのほとんどをあなたは直接見たことがないはずです。なぜなら、多くのツールは遅延ロードされるからです。LLMが必要とするときにのみ、ToolSearchToolを通じてオンデマンドで注入されます。

なぜそうするのでしょうか？

ツールが増えるごとにシステムプロンプトの説明が必要になり、トークンコストがかさむからです。Claude Codeにコードを1行変更するのを手伝ってほしいだけなら、「Cron Task Scheduler」や「Team Collaboration Manager」をロードする必要はありません。

さらに賢い設計があります：

CLAUDE_CODE_SIMPLE=trueに設定すると、Claude CodeにはBash、Read File、Modify Fileの3つのツールしか残りません。これはミニマリストのためのバックドアです。

すべてのツールは同じ工場から生まれる

デフォルト値に注目してください。isConcurrencySafeはデフォルトでfalse、isReadOnlyはデフォルトでfalseです。

これはフェイルクローズ設計と呼ばれます。ツールの作成者が安全属性を宣言し忘れた場合、システムはそれを「安全ではなく書き込み可能」と見なします。リスクを一つ見逃すよりは、過剰に慎重である方が良いのです。

「書き込み前の読み取り」の鉄則

FileEditToolは、FileReadToolを使用してそのファイルをすでに読み取ったかどうかを確認します。読み取っていない場合、直接エラーをスローし、変更を許可しません。

これが、Claude Codeが他のツールのように「魔法のようにコードスニペットを書いてファイルを上書きする」ことがない理由です。**変更前に理解することが求められているのです**。

5. 第三の秘密：メモリシステム—なぜ「あなたを覚えている」のか

Claude Codeを使ったことがある人なら誰でも感じるはずです：それは本当にあなたを知っているようです。

「テストでデータベースをモックしないで」と言えば、次の対話でもモックしません。「私はバックエンドエンジニアで、React初心者です」と言えば、バックエンドの例えを使ってフロントエンドのコードを説明してくれます。

その背後には完全なメモリシステムがあります。

AIを使って記憶を検索する

Claude Codeは別のAI（Claude Sonnet）を使用して、「現在の対話に関連する記憶はどれか」を判断します。

キーワードマッチングでもベクトル検索でもありません。小さなモデルにすべてのメモリファイルのタイトルと説明を高速スキャンさせ、最も関連性の高い最大5つを選択し、その全内容を現在の対話コンテキストに注入します。

戦略は「再現率より精度」です。コンテキストを汚染する無関係な記憶を注入するよりは、潜在的に有用な記憶を見逃す方がマシだという考えです。

KAIROSモード：夜間の「夢」

これは私にとって最もSF的な部分です。

コード内にKAIROSという機能フラグがあります。このモードでは、長い対話からの記憶は構造化ファイルではなく、日付が付加されたログのようなエントリに保存されます。そして、「夜間」（低アクティビティ時）に実行される/dreamスキルがあり、これらの生のログを構造化されたテーマ別ファイルに蒸留します。

AIは「睡眠中」に記憶を整理します。これはもはやエンジニアリングではなく、バイオニクスです。

6. 第五の秘密：エージェントではなく、グループである

Claude Codeに複雑なタスクを実行させると、静かにこれを行うことがあります：

サブエージェントを生成します。

そして、サブエージェントには、再帰的にサブエージェントを生成し続けるのを防ぐための厳格な「自己認識」注入があります：

このコードはこう言っています：「あなたは労働者であり、マネージャーではない。人を雇うことを考えるな、自分で仕事をしろ。」

コーディネーターパターン：マネージャーパターン

コーディネーターパターンでは、Claude Codeはタスクを委任するだけの純粋なタスクオーケストレーターになり、自分自身では作業を行いません：

コードコメントに書かれた中核原則：

読み取り専用の研究タスクには「並列処理はあなたのスーパーパワー」：並列実行。ファイル書き込みタスクには：ファイルグループごとに直列実行（競合を回避）。

プロンプトキャッシュの極限までの最適化

サブエージェントのキャッシュヒット率を最大化するため、すべてのフォークされたサブエージェントのユーティリティ結果は同じプレースホルダーテキストを使用します：

"Fork開始—バックグラウンドで処理中"

なぜか？ClaudeのAPIプロンプトキャッシュはバイトレベルのプレフィックスマッチングに基づいているからです。10個のサブエージェントのプレフィックスバイトが同一であれば、最初の1つだけが「コールドスタート」を必要とし、残りの9つは直接キャッシュにヒットします。

これは呼び出しごとに数セントを節約する最適化ですが、大規模に行えばかなりのコストを節約できます。

七、第六の秘密：「制限を超えない」対話を保証する3層圧縮

すべてのLLMにはコンテキストウィンドウの制限があります。対話が長くなり、履歴メッセージが増えるほど、最終的には制限を超えてしまいます。

Claude Codeは、そのために3層圧縮を設計しました：

層1：マイクロ圧縮 — 最小コスト

マイクロ圧縮は古いツール呼び出し結果のみに触れます。「10分前に読み取った500行のファイルの内容」を[古いツール結果の内容をクリア]に置き換えます。

プロンプトワードと対話スレッドは完全に保持されます。

層2：自動圧縮 — プロアクティブな縮小

トークン消費量がコンテキストウィンドウの87%（ウィンドウサイズ - 13,000バッファ）に近づくと、自動的にトリガーされます。回路遮断器があり、ループを避けるために3回連続で圧縮に失敗した場合は試行を停止します。

層3：完全圧縮 — AI要約

AIに対話全体の要約を生成させ、すべての履歴メッセージを要約に置き換えます。要約生成中には厳格な教訓があります：

なぜこれほど厳格なのか？要約プロセス中にAIが追加のツール呼び出しを行うと、さらなるトークン消費が発生し、逆効果になるからです。このプロンプトは本質的に「あなたのタスクは要約することであり、他のことはするな」と言っています。

圧縮トークン予算：

· ファイル復旧：50,000トークン

· ファイルごとの上限：5,000トークン

· スキルコンテンツ：25,000トークン

これらの数字は恣意的なものではなく、「作業を継続するのに十分なコンテキストを保持する」ことと「新しいメッセージを受け取るのに十分なスペースを空ける」ことのバランス点を示しています。

8. このソースコードを読んで学んだこと

AIエージェントの仕事の90%は「AI」の外にある

51万行のコードのうち、実際にLLM APIを呼び出している部分は5%未満でしょう。残りの95%は何でしょうか？

· セキュリティチェック（BashTool単体だけで18ファイル）

· 権限システム（許可/拒否/質問/パススルーの二次決定）

· コンテキスト管理（3層圧縮 + AIメモリ検索）

· エラー復旧（回路遮断器、指数バックオフ、トランスクリプト永続化）

· マルチエージェント調整（群れオーケストレーション + メールボックス通信）

· UIインタラクション（140個のReactコンポーネント + IDEブリッジ）

· パフォーマンス最適化（プロンプトキャッシュの安定性 + 起動時の並列プリフェッチ）

AIエージェント製品を構築しているなら、これらが解決すべき真の問題です。モデルがどれほど賢いかではなく、足場がどれほど堅牢かが重要なのです。

優れたプロンプトエンジニアリングはシステムエンジニアリングである

単に良いプロンプトを作成するだけではありません。Claude Codeのプロンプトには以下が含まれます：

· 7層の動的組み立て

· 各ツールにはスタンドアロンのユーザーマニュアルが付属

· キャッシュ境界が正確に区切られている

· 内部バージョンと外部バージョンで命令セットが異なる

· キャッシュの安定性を維持するためにツールの順序が固定されている

これは職人技ではなく、エンジニアリングされたプロンプト管理です。

失敗を前提に設計する

すべての外部依存関係には対応する失敗ポリシーがあります：

AnthropicはClaude Codeをオペレーティングシステムとして扱っている

42個のツール = システムコール権限システム = ユーザー権限管理スキルシステム = App Store MCP プロトコル = デバイスドライバエージェントの群れ = プロセス管理コンテキスト圧縮 = メモリ管理トランスクリプト永続化 = ファイルシステム

これは「チャットボットにいくつかのツールを追加したもの」ではなく、LLMを核としたオペレーティングシステムです。

まとめ

51万行のコード。1903ファイル。Bashツール単体だけで18個のセキュリティファイル。

AIにコマンド入力を安全に手伝ってもらうためだけの9層の精査。

これがAnthropicの答えです：AIを真に役立つものにするには、ケージに閉じ込めることも、野放しにすることもできません。その周りに完全な信頼フレームワークを構築しなければならないのです。

そして、この信頼システムのコストが51万行のコードなのです。

元の投稿