Claude Code のソース流出から学べること：System Prompt、権限分離、Memory 設計
Claude Code のソースコード流出をめぐる話題は、単なる製品ニュースを越えて大きく広がりました。
きっかけは、Anthropic が公開した npm package にデバッグ関連ファイルが含まれ、source map を通じて内部実装の一部が外から読める状態になったことです。その後 GitHub 上にも mirror が現れ、コミュニティで急速に分析が進みました。
ただ、この件で私が一番興味を持ったのは「Anthropic が失敗した」という部分ではありません。
普段 Claude Code を使っていて感じる「全体として安定して使いやすい」という体験が、モデルだけでなく、どれだけ周囲の engineering によって作られているのか。その一端が見えたことです。
私は普段から Claude Code を有料で使い、コード、文章、ブログ、workflow の整理などで複数ターミナルを同時に動かしています。
そのため今回注目したのは、高性能モデルをどうやって毎日使える製品に変えているのかでした。
まず確認できる事実として、Axios の報道では Anthropic も内部ソースが公開 package に含まれたことを認めています。一方で customer data や credential の流出ではないとされています。
また npm の公開バージョンを確認すると、話題の中心だった 2.1.88 は現在の version list から見えず、前後の version が並ぶ状態になっていました。
npm view @anthropic-ai/claude-code versions --json例として末尾は次のような形です。
[
"2.1.87",
"2.1.89"
]ネット上ではファイル数やコード行数、star 数など様々な数字が出ていますが、そうした値は短時間で変わるため、私は構造を見る材料として扱う方が良いと思っています。
今回の分析から見えてくる一番重要な点は、Claude Code の使い勝手はモデルだけでは説明できないということです。
モデルを engine とするなら、その外側に steering、brake、instrument panel、limit、frame のような仕組みがあります。
AI coding tool の差は、すでに benchmark score だけでは測りにくくなっています。
System Prompt は巨大な一枚岩ではなく、分層された仕組み
公開分析で特に参考になったのは、Claude Code が「一つの巨大な静的 system prompt ですべてを処理する」形ではないことです。
大きく見ると、
- 全ユーザー共通の行動ルール
- ユーザーや project によって変わる context
が分離されています。
共通層には、例えば次のような制約があります。
- 根拠なく作らない
- 不要なファイル削除をしない
- 専用 tool があるなら優先する
- 過剰な engineering を避ける
- ユーザーが求めていない機能を勝手に増やさない
その下に、
CLAUDE.md- user preference
- MCP
- repository state
- project-specific rule
といった動的 context が入ります。
この分け方は大規模製品としてかなり合理的です。
すべてを毎回新しい context として詰め込むのではなく、共通部分を安定させ、現在の task に必要な情報だけを追加する。
これは prompt の文章力よりも、限られた context budget をどこへ使うかという engineering の問題です。
この考え方は、Skills が「MCP tool を大量に常時読み込む」より軽く感じる理由にもつながります。
tool definition 自体が context を消費するなら、すべての能力を最初から入れるより、必要なときに発見して使う設計の方が効率的です。
実行 Agent と Permission 判断を分ける
二つ目に重要なのは、安全性を主 Agent の判断だけに任せていないことです。
公開分析では yoloClassifier のような独立した安全判断層が話題になりました。
名前はともかく、考え方は明確です。
「できるか」と「してよいか」を別に判断する。
例えば、
- Allow
- Soft Deny
- Hard Deny
のように段階を分ければ、主 Agent が操作能力を持っていても、すべての操作が同じ信頼度で通るわけではありません。
AI coding tool の事故は「コードを書けない」ことより、「触る必要のないものまで大胆に触る」ことで起きる場合があります。
同じ Agent に reasoning、editing、permission judgement をすべて集中させると、体験は速い一方で事故時の影響が大きくなります。
私は日常利用でも、モデルの回答がきれいかどうかより、
- どこまで権限を渡せるか
- 連続実行を任せられるか
- 既存ファイルを壊さないと信じられるか
の方を重視するようになりました。
高い権限を安心して渡せる製品には、表面の Agent 以外にも「ブレーキ」が必要です。
Memory は「何を覚えないか」が重要
三つ目は memory です。
興味深いのは、記憶を増やすことではなく、変化しやすい事実を記憶へ固定しないという考え方です。
例えば次のようなものは長期 memory と相性が良いです。
- user preference
- behavioral feedback
- project-level convention
- stable external reference
一方、コードの現在位置や関数の実装内容は変化します。
- 何行目に関数があるか
- module の構造
- 現在の実装
を長期 memory に固定すると、refactor 後に古い情報がむしろ誤誘導になります。
そのため、
好みや判断基準は記憶し、コードの事実は source から読み直す
という分離は非常に合理的です。
「たくさん覚えている AI」が常に賢いわけではありません。長期運用では、間違った記憶の方が厄介です。
検索も必ずしも複雑にする必要はない
もう一つ参考になるのは、コード検索のすべてを vector database や巨大 RAG に寄せているわけではないことです。
公開分析では、Claude Code が text search、つまり grep 的な素朴な探索をかなり活用していることも話題になりました。
これは独立開発者にとって重要な示唆です。
モデルが強くなるほど、周囲のすべてを複雑化する必要はありません。
- text search で十分な場所
- structured metadata が必要な場所
- semantic retrieval が本当に必要な場所
を分ける方が、system 全体は保守しやすくなります。
AI Coding Tool の競争は Harness Engineering へ広がっている
今回見えたのは「Claude Code の CLI がどう書かれているか」だけではありません。
より重要なのは、すでに実運用で評価されている AI coding product が、
- prompt architecture
- tool boundary
- permission
- context compression
- memory extraction
- safety
- logging
- workflow
をどう組み合わせているかです。
これまで「モデルは同じくらい強いのに、なぜ製品ごとの使い心地がこんなに違うのか」と感じることがありました。
答えの一つは、モデルとユーザーの間にある harness の厚さです。
公開された構造を見れば、後発チームや OSS が設計上の遠回りを減らせる可能性はあります。
ただし、ソースが見えたからといって、すぐ同等製品を複製できるわけではありません。
- iteration speed
- model integration
- product judgement
- release cadence
- operational feedback
はディレクトリ構造をコピーするだけでは手に入りません。
構造を真似できても、製品を改善し続ける速度まで真似できるとは限りません。
それでも独立開発者にとって、この事件は一つの判断をはっきりさせました。
次の AI coding tool の競争は「どのモデルが強いか」だけではなく、誰が agent の tool、permission、memory、context、安全境界を最もうまく設計できるかです。
モデルの外側をどう作るかが、日常的に任せられる開発ツールとの差になります。
この「モデル外の engineering layer」に興味があるなら、新しい Codex は何が変わったのか と AI Agent Orchestration とは何か も同じ流れで読めます。
前者は product / workflow layer、後者は multi-agent system layer の話です。