Claw Codeとは？Claude Codeリライトの全貌
claw-codeは、Claude CodeのエージェントハーネスをクリーンルームでPythonに書き直したものです。その概要、経緯、そして開発者が知っておくべきことを解説します。
みなさん、こんにちは。Doraです。信じられますか？私は**claw-code**リポジトリが公開された朝から、ずっと観察し続けていました。使う予定があったからではなく、その誕生にまつわる経緯が、エージェント型コーディングエコシステムの実態——あらゆる喧噪の奥にあるもの——を浮き彫りにするからです。
何が起きたのか、claw-codeとは何か、そして本当に注目すべき人は誰なのかを順を追って説明します。
何が起きたか：Claude Codeのソースコード流出
ソースマップ漏洩はなぜ起きたか
2026年3月31日、セキュリティ研究者のChaofan Shouがnpmレジストリに奇妙なものを発見しました。@anthropic-ai/claude-codeのバージョン2.1.88に、59.8 MBのJavaScriptソースマップファイルが同梱されていたのです。
ソースマップはデバッグ用の成果物です——難読化されたプロダクションコードを読みやすいTypeScriptに変換し、スタックトレースを解読できるようにするものです。公開パッケージに含まれるべきものではありません。
この仕組み自体は珍しくありません。Claude Codeが内部で使用しているBunのバンドラーは、明示的に無効化しない限りデフォルトでソースマップを生成します。oven-sh/bun#28001（3月11日提出）というBunのバグ報告では、本来生成されるべきでない状況でもプロダクションビルドにソースマップが含まれると報告されています。これが漏洩の原因だとすれば、Anthropic自身のビルドツールチェーンが既知の問題を抱えたまま自社製品を公開したことになります。誰もハッキングする必要はありませんでした。ファイルはただそこに存在し、AnthropicのCloudflare R2ストレージバケットに置かれたzipアーカイブを指し示していただけです。
Anthropicはこの件を「セキュリティ侵害ではなく、人的ミスによるリリースパッケージングの問題」と認めました。注目すべきは、これが2回目の出来事であるという点です——2025年2月にも旧バージョンでほぼ同様のソースマップ漏洩が起きています。
その朝にnpm経由でClaude Codeを更新した方にもう一つ。同日UTC 00:21〜03:49の間、axiosパッケージへのサプライチェーン攻撃が実行されていました。AxiosはClaude Codeの依存パッケージです。その時間帯に更新した場合は、依存関係を監査し、認証情報をローテーションしてください。
実際に何が露出したか
**顧客データ、APIクレデンシャル、モデルの重みは含まれていません。**露出したのは約1,900ファイルにわたる約512,000行のTypeScript——クエリエンジン、ツールシステム、マルチエージェントオーケストレーションロジック、コンテキスト圧縮、そして未出荷の機能をカバーする44個のフィーチャーフラグです。
フィーチャーフラグが戦略的に最も機密性の高い部分です。外部ビルドではfalseに評価されるフラグの背後に隠れたコンパイル済みコードは、単なる実装の詳細ではありません——それは製品ロードマップそのものです。競合他社はAnthropicが何を構築し、何を出荷しようとしているかを知ることができます。その戦略的な驚きは、もはや取り返しがつきません。
claw-codeとは何か？
アーカイブではなく、クリーンルームによる再実装
流出から数時間のうちに、ミラーリポジトリがGitHub上に続々と登場しました。AnthropicはDMCAテイクダウンを出し始めました。インターネットは待ちませんでした。
Sigrid Jin（@instructkr）——2月にサンフランシスコで開催されたClaude Codeの1周年パーティーに参加した韓国人開発者——が、claw-codeとして知られるようになるものを公開しました。リポジトリは2時間で50,000スターを獲得し、GitHubが記録した中でも最速クラスの蓄積速度を叩き出しました。
重要な区別があります：claw-codeは漏洩したTypeScriptのアーカイブではありません。 Anthropicの独自ソースをコピーすることなく、元のハーネス構造を読み解き、アーキテクチャパターンを再実装した、クリーンルームによるPythonの書き直しです。Jinはoh-my-codex（OpenAIのCodex上のオーケストレーションレイヤー）を使い、並列コードレビューと持続的な実行ループを組み合わせて、一晩で構築しました。
クリーンルームによる再実装が著作権上の問題を完全に回避できるかどうかは、技術的な問題ではなく法的な問題です。その答えはまだ出ていません。リポジトリは明示しています：「このリポジトリは元のClaude Codeソース素材の所有権を主張しません。」しかし、表現と法的結果は同じではありません。
現状：今はPython、後でRust
2026年4月時点で、メインのソースツリーはPythonファーストです。構造はClaude Codeのコアモジュールを反映しています：CLIエントリ、クエリエンジン、ランタイムセッション管理、ツール実行、パーミッションコンテキスト、セッション永続化、そして元の実装との差分を明示的に追跡するparity_audit.py。
最後のファイルは注目に値します。再実装がまだ追いついていない部分について、誠実に記録した組み込みの会計簿です。完全であるふりをするよりも、この種の透明性の方がはるかに有用です。
Rustへの移植が進行中です——READMEでは次の方向性として説明されています。安定版リリースも、確定したタイムラインもありません。
アーキテクチャが明らかにするもの
ここでビルダーにとっての本当の価値は、ドラマではありません。露出したアーキテクチャが、プロダクション品質のエージェント型コーディングシステムが実際にどう構成されているかを教えてくれることです。
マルチエージェントオーケストレーションのパターン
Claude Codeは単一のチャットボットループではありません。漏洩後に広く拡散したコミュニティ分析はそのコアを描写しています：1つのエージェントループ、40以上の独立したツール、オンデマンドのスキルロード、コンテキスト圧縮、サブエージェントのスポーン、依存グラフを持つタスクシステム、並列実行のためのワークツリー分離。
サブエージェントのパターンは理解する価値があります。タスクがプライマリのコンテキストウィンドウを埋め尽くすリスクがある場合、Claude Codeは独自のコンテキストとタスクスコープを持つ独立したエージェントインスタンスをスポーンします。探索的な作業がメインスレッドを汚染しません。タスクはお互いをブロックすることなく並列に実行されます。
注目すべきは、オーケストレーションレイヤーがいかにミニマルかです。厳格なワークフローを押し付けません。ツールを提供し、パーミッションとコンテキストを管理し、あとは邪魔をしない。推論はモデルが行います。ハーネスはその推論が有用になる条件を作り出します。
パーミッションレイヤーとツールのサンドボックス化
40以上のツール——bash実行、ファイル読み取り、Webフェッチ、LSPインテグレーション、git操作——はそれぞれ個別にパーミッションゲートされています。&&、||、;、またはパイプで連結された複合bashコマンドは、サブコマンドごとに評価されます。いずれかの部分が拒否される場合、コマンド全体がブロックされます。
拒否リストは常に許可リストより優先されます。任意のシェルコマンドを実行するものにとって、これは正しい設計です。
このアーキテクチャ的な直観は、エコシステム全体で収束しつつあります。OpenClawのマルチエージェントルーティングドキュメントは、エージェントごとのツールポリシー、セッション分離、個別の認証プロファイルを説明しています——同じパターンが、異なるホストプラットフォームに適用されています。広範な権限を持ちサンドボックス化されていないエージェントは、実際の作業を任せられないエージェントです。この業界はそれを理解しつつあります。
ビルダーはclaw-codeに注目すべきか？
実験的利用 vs. プロダクション利用
エージェント型ハーネス設計を研究しているなら——ツールパーミッションの構造化方法、コンテキスト圧縮の仕組み、サブエージェントスポーンの調整方法——claw-codeは本当に有用です。 PythonによるImplementationは読みやすく、parity_audit.pyは元の実装からの乖離を示すマップを提供し、アーキテクチャは複数の独立した分析によって今や詳細に文書化されています。
出荷するものや依存するものを構築しているなら、状況は異なります。 Pythonによる書き直しは1週間も経っていません。Rustへの移植は志望段階です。バージョニングの安定性も、メンテナンスのコミットメントも、法的な露出がプロジェクトの継続性にどう影響するかの明確さもありません。claw-codeをプロダクションで依存することは、あなたのコントロール外の要因によって大きく変化——あるいは消滅——する可能性のあるプロジェクトに賭けることを意味します。
今のほとんどのビルダーにとって：コードを読む、プロダクションで動かさない。
考慮すべき法的・安定性のリスク
元のTypeScriptのアーカイブに対するAnthropicのDMCAアクションは現在も続いています。クリーンルームによる書き直しとしてのclaw-codeの法的地位は本当に不明確です。クリーンルームによる再実装には、プロジェクトを守ることもあれば守らないこともある法的な前例があり、具体的な内容によって結果が変わります。これに基づいて構築する人は、その不確実性を誠実に考慮すべきです。
安定性の問題は別です。 プロジェクトが妨げなく継続したとしても、一晩のセッションで構築されたコードベースは、それがモデルとしているものとは同等ではありません。parity_audit.pyはギャップを追跡しています——しかしギャップを追跡することとギャップを埋めることは同じではありません。
よくある質問
Q: claw-codeはClaude Codeと同じですか？ いいえ。**Claude Code**はAnthropicの公式TypeScript CLIで、積極的にメンテナンスされ、npm経由で配布されています。claw-codeはアーキテクチャパターンを反映した独立したPythonの書き直しです。設計思想は同じですが、まったく別のプロジェクトです。
Q: Claude Codeをclaw-codeに置き換えられますか？ 今日時点では無理です。claw-codeはフィーチャーパリティに達しておらず、Rustへの移植は安定していません。未解決の法的問題も抱えています。実際のコーディング作業には、Claude Codeが依然としてプロダクションツールです。
Q: AnthropicのDMCAアクションはプロジェクトにどんな意味を持ちますか？ Anthropicは元の漏洩TypeScriptをホストするリポジトリを標的にしています。claw-codeはその防御としてクリーンルームの地位を主張しています。それが法的に通用するかどうかは未解決です。プロジェクトはいずれにせよ圧力に直面する可能性があります。
Q: claw-codeはオープンソースですか？ パーミッシブライセンスの下でGitHubに公開されています。「オープンソース」と「依存しても安全」がここでは同じことを意味するのかは、立ち止まって考える価値のある問いです。
この事件から明らかになったアーキテクチャの露出は、claw-code自体よりも私には重要です。Claude Codeの内部設計——サブエージェントのスポーン、ツールのサンドボックス化、コンテキスト圧縮、パーミッションレイヤリング——は、リバースエンジニアリングがこれまでに明らかにしていた以上のものを、今や公開された分析として文書化されています。これはこの分野でものを作るすべての人のベースラインを引き上げます。
claw-codeが法的にも技術的にも安定した足場を見つけられるかどうか、私には本当にわかりません。今のところ：読んでください、デプロイしないでください。
過去の投稿：
