claw-codeのソースから読み解く、Claude Codeのエージェント設計思想

はじめに：ソースマップ流出が明かしたもの

2026年3月31日、Anthropicの「Claude Code」のnpmパッケージ（バージョン2.1.88）に、本来含まれるべきではないソースマップファイル（.map）が同梱されていたことが発覚した。

このファイルから、約51万行・1,900以上のTypeScriptファイルからなるClaude Codeの全ソースコードにアクセス可能な状態になっていた。Anthropicは「リリースパッケージングのヒューマンエラーであり、セキュリティ侵害ではない」と声明を出し、顧客データや認証情報の漏洩はなかったと説明している。

数時間のうちにソースコードは世界中のエンジニアによってミラーリングされ、そのアーキテクチャの詳細が広く知られることとなった。本記事では、流出コードそのものではなく、それを基にPythonで再実装されたclaw-codeプロジェクトの構造を手がかりに、Claude Codeに組み込まれたエージェント設計思想を読み解いていく。

なお、本記事では流出したオリジナルコードの直接引用は行わない。

claw-codeとは何か

claw-codeは、韓国の開発者Sigrid Jin（instructkr）が公開した、Claude Codeのクリーンルーム・リライト（clean-room rewrite）プロジェクトだ。

クリーンルーム・リライトとは、オリジナルのソースコードを直接コピーするのではなく、公開された情報や動作仕様を基に、ゼロから独自に再実装する手法を指す。著作権法上、オリジナルコードの複製には該当しないとされる一般的なアプローチだ。

このプロジェクトにはいくつかの注目すべき特徴がある。

• GitHubで史上最速となる2時間で5万スターを獲得（現在6.6万スター超）
• Pythonによる再実装で、現在はRustへの移植も進行中
• 207のコマンドと184のツールの表面仕様をJSON形式で保持
• オリジナルのディレクトリ構成（coordinator、memdir、hooks、skills等）を忠実に再現

重要なのは、claw-codeが単なるアーカイブではなく「実際に動くものを作る」という思想で開発されていることだ。リポジトリにはcoordinator/（マルチエージェント調整）、memdir/（メモリディレクトリ）、buddy/（コンパニオンシステム）などのスタブが用意されており、Claude Codeのアーキテクチャ全体像を理解するための優れたリファレンスとなっている。

注目すべき設計ポイント3選

1. MEMORY.md方式 — 「懐疑的メモリ」の設計哲学

Claude Codeのメモリシステムは、4つのレイヤーで構成されている。

ここで最も興味深いのは、Auto MemoryにおけるMEMORY.mdの設計哲学だ。

MEMORY.mdはインデックスファイルであり、メモリそのものではない。各記憶は個別のMarkdownファイル（例：user_role.md、feedback_testing.md）に保存され、MEMORY.mdにはそのファイルへのポインタだけが記載される。これにより、メモリが肥大化してもインデックスのコンパクトさは維持される。

さらに注目すべきは「懐疑的メモリ（skeptical memory）」という設計方針だ。メモリに記録された情報は過去のある時点でのスナップショットに過ぎないと明確に位置づけられている。「メモリにXが存在すると書いてある」ことと「今Xが存在する」ことは同義ではない。メモリを参照した場合、実際のファイルやコードの現在状態を確認してから行動するよう設計されている。

この設計は、長期間稼働するエージェントにおける「陳腐化した記憶に基づく誤動作」を防ぐ実践的なアプローチだ。人間のエンジニアでも「前はこうだった」という記憶でコードを書いて、実際にはリファクタリング済みだったという経験は誰にでもあるだろう。AIエージェントでは、この問題がはるかに深刻になる。

メモリの型も明確に分類されている。

• user— ユーザーの役割、好み、知識レベル
• feedback— ユーザーからの修正指示（「なぜ」まで含めて記録）
• project— 進行中のプロジェクトの状況や制約
• reference— 外部システムへのポインタ

特にfeedback型は、修正内容だけでなく「なぜその修正が必要だったのか（Why）」と「今後どう適用するか（How to apply）」をセットで記録する設計になっている。これにより、単なるルールの羅列ではなく、文脈を理解した上でのエッジケース判断が可能になる。

2. AutoDream — アイドル時のメモリ統合

AutoDreamは、Claude Codeの中でも最も先進的な未リリース機能の一つだ。claw-codeの構造からその仕組みが推測できる。

AutoDreamは「夜間のメモリ整理」とも呼ばれ、セッション間のアイドル時間を活用してメモリを統合・最適化する。UC Berkeleyの論文「Sleep-time Compute」（arXiv:2504.13171）にインスパイアされた設計で、推論時のコンピュートを約5倍削減しながら同等の精度を達成できるという研究結果に基づいている。

起動条件は3つのゲートで制御される。

1. 時間ゲート— 前回の統合から24時間以上経過
2. セッションゲート— 少なくとも5セッション以上経過
3. ロックゲート— 統合ロックの取得（並行実行の防止）

3つの条件がすべて満たされた場合のみ、4フェーズの統合サイクルが実行される。所要時間は約8〜10分。

フェーズ1: Orient（方位確認）MEMORY.mdと既存のトピックファイルをスキャンし、現在のメモリ状態を把握する。

フェーズ2: Gather Signal（シグナル収集）過去のセッションから、修正指示、意思決定の記録、繰り返し出現するパターンを抽出する。

フェーズ3: Consolidate（統合）重複を排除し、矛盾する記録を解消する。ここで特筆すべきは相対的な時間表現の絶対化だ。「昨日Redisを選んだ」という記録は「2026-03-15にRedisを選んだ」に変換される。これにより、時間が経過しても記憶の意味が劣化しない。

フェーズ4: Prune and Index（剪定とインデックス化）MEMORY.mdを200行・25KB以内に維持する。このハードリミットは、メモリが膨張してコンテキストウィンドウを圧迫することを防ぐための意図的な設計だ。詳細な情報はテーマ別のトピックファイルに分散される。

この設計の本質は「後ろ向きの統合」にある。AutoDreamは過去の記憶を整理するだけで、未来を予測しない。これは一見消極的に見えるが、「予測が外れた場合のリスク」を完全に排除できるという点で合理的だ。次のセッション開始時に、より効率的なメモリ状態が用意されていれば、それだけで十分な価値がある。

3. マルチエージェントコーディネーター — 「プロンプトで制御する」という割り切り

Claude Codeのコーディネーターモードは、単一のエージェントを複数のワーカーエージェントに分岐させる仕組みだ。claw-codeのcoordinator/ディレクトリ構造から、その設計思想が読み取れる。

最も衝撃的なのは、オーケストレーションアルゴリズムがコードではなくプロンプトで実装されているという点だ。

一般的なマルチエージェントフレームワーク（LangGraphやCrewAIなど）では、エージェント間の調整はPythonやTypeScriptのコードとして実装される。タスクキュー、状態管理、エラーハンドリングなどが明示的なプログラムとして書かれる。

Claude Codeのアプローチは根本的に異なる。コーディネーターエージェントに対して、システムプロンプトで以下のような指示を与えている。

• 「弱い成果物を安易に承認するな」
• 「調査結果を理解してから次の作業を指示しろ」
• 「並列処理がお前の超能力だ。ワーカーは非同期で動く」

つまり、LLM自体の推論能力に「正しい調整行動をとること」を委ねている。

4つのフェーズで構成される。

1. Research— 複数のワーカーが並列で調査
2. Synthesis— コーディネーターが調査結果を統合し仕様を策定
3. Implementation— ワーカーが仕様に基づき実装
4. Verification— ワーカーが実装を検証

ワーカー間の通信は<task-notification>というXML形式のメッセージで行われ、共有スクラッチパッドディレクトリを通じて情報を受け渡す。

この設計は賛否が分かれるだろう。「コードで制御すべきものをプロンプトに委ねるのは不安定では？」という批判は当然ある。しかし、LLMの推論能力が十分に高ければ、ハードコードされたワークフローよりも柔軟に状況に適応できるという利点がある。新しいタスクパターンが出現しても、プロンプトの微調整だけで対応できる。

この「プロンプトで制御する」というアーキテクチャ判断は、Anthropicが自社のモデル能力にどれだけ自信を持っているかの表れとも読める。

自律エージェント開発への応用

ここまで見てきたClaude Codeの設計思想は、自律エージェント開発に直接応用できる。

「夜間自律実行」との親和性

筆者は「Ralph Loop」と呼ぶ仕組みを運用している。夜間にClaude Codeが自律的にコード改善、テスト実行、PRの作成を繰り返すシステムだ。

Claude CodeのAutoDream設計は、この種の夜間自律実行と高い親和性を持つ。AutoDreamは「セッション間のアイドル時間に、次のセッションの準備をする」という思想だが、これは「夜間の自律実行中に、翌朝のエンジニアのために文脈を整理しておく」という運用と完全に一致する。

具体的には、以下のような応用が考えられる。

• 夜間タスク完了後のメモリ統合— 何をやったか、何が未完了か、何に注意が必要かを構造化して残す
• 懐疑的メモリによる安全な自律実行— 「前回はこうだった」という記憶を鵜呑みにせず、毎回ファイルの現在状態を確認してから行動する
• 200行キャップによるコンテキスト効率化— 夜間に蓄積された大量のログを、翌朝使える圧縮された知識に変換する

エージェント設計への教訓

Claude Codeの設計から得られる教訓をまとめる。

1. メモリは「信頼しない」前提で設計する

MEMORY.mdの懐疑的メモリ設計は、長期稼働エージェントの必須パターンだ。メモリはキャッシュと同じで、「有効期限切れかもしれない」という前提で扱うべきだ。

2. メモリ統合は非同期・バックグラウンドで行う

AutoDreamの設計が示すように、メモリの整理はユーザーのインタラクション中ではなく、アイドル時間に行うべきだ。Sleep-time Computeの研究が示すとおり、推論時のコストを事前処理で削減できる。

3. オーケストレーションは「コード vs プロンプト」の二択ではない

Claude Codeのコーディネーターは、基本構造（フェーズ、メッセージング）はコードで定義しつつ、調整ロジックはプロンプトに委ねている。これは「何をハードコードし、何をLLMに委ねるか」の実践的な線引きだ。

4. 200行ルールのようなハードリミットを設ける

メモリ、ログ、コンテキスト — 放っておけばすべて膨張する。AutoDreamの200行キャップのように、物理的な制約を設けることで「何を残すか」の優先順位判断が強制される。

5. 高速な判定にはLLMを使わない

Claude Codeでは、ユーザーのフラストレーション検知に正規表現を使っている。「怒っているかどうか」の判定にLLMの推論は不要で、パターンマッチで十分だ。「すべてをLLMで解決する」という誘惑に抗い、適材適所でツールを選ぶ姿勢は参考になる。

まとめ

claw-codeプロジェクトとその周辺情報から、Claude Codeのエージェント設計思想を読み解いてきた。

• 懐疑的メモリ— 過去の記憶を「真実」ではなく「スナップショット」として扱う
• AutoDream— アイドル時間を活用した非同期メモリ統合
• プロンプト駆動のオーケストレーション— LLMの推論能力に調整を委ねる大胆な設計判断

これらの設計パターンは、Claude Code固有のものではなく、自律エージェント開発全般に適用可能な知見だ。

流出事件そのものの是非はさておき、世界で最も使われているAIコーディングエージェントの内部設計が明らかになったことは、エージェント開発コミュニティにとって貴重な学習機会だ。claw-codeのようなクリーンルーム・リライトプロジェクトを通じて、これらの設計思想を自分のプロジェクトに取り込んでいくことが、今できる最も生産的なアプローチだろう。