# Claude Code のソース流出から学べること：System Prompt、権限分離、Memory 設計

> Canonical: https://vxi.me/ja/posts/claude-code-source-leak-harness-engineering/
> Locale: ja-jp
> Published: 2026-04-01
> Updated: 2026-04-01
> Markdown: https://vxi.me/ja/posts/claude-code-source-leak-harness-engineering.md

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 が並ぶ状態になっていました。

```bash
npm view @anthropic-ai/claude-code versions --json
```

例として末尾は次のような形です。

```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 は何が変わったのか](/ja/posts/what-changed-in-the-new-codex/) と [AI Agent Orchestration とは何か](/ja/posts/ai-agent-orchestration-after-assistants/) も同じ流れで読めます。

前者は product / workflow layer、後者は multi-agent system layer の話です。

## 関連資料

- [Axios: Anthropic accidentally leaked source code for its AI coding assistant](https://www.axios.com/2026/04/01/anthropic-claude-code-source-code)
- [npm: @anthropic-ai/claude-code](https://www.npmjs.com/package/@anthropic-ai/claude-code)
- [新しい Codex は何が変わったのか](/ja/posts/what-changed-in-the-new-codex/)
- [AI Agent Orchestration とは何か](/ja/posts/ai-agent-orchestration-after-assistants/)