アーキテクチャ概要 — Claude Code リポジトリには何が入っているのか
前提知識
- ›Claude Code をユーザーとして使った基本的な経験(スラッシュコマンド、ツールシステムなど)
- ›GitHub リポジトリ構造についての一般的な理解
アーキテクチャ概要 — Claude Code リポジトリには何が入っているのか
github.com/anthropics/claude-code を開いたとき、Claude Code のターミナル UI やコンテキストウィンドウ管理、ツール実行エンジンのソースコードを期待していたとしたら、その期待は裏切られます。これはこのリポジトリに関する最もよくある誤解であり、同時に「このリポジトリが実際に何を含んでいるか」を理解するための出発点でもあります。
このリポジトリは、Claude Code の公開向け拡張性・運用レイヤーです。公式プラグインエコシステム、数千件の Issue を管理する GitHub 自動化インフラ、DevContainer サンドボックス構成、エンタープライズ向けのデプロイ例をまとめた場所であり、Claude Code が外の世界に接する境界面といえます。
このリポジトリが「何であるか」と「何でないか」
Claude Code 製品本体は、クローズドソースの npm パッケージ(@anthropic-ai/claude-code)とネイティブインストーラーとして配布されています。README にもその旨が明記されており、ソースファイルではなく、インストール方法と公式ドキュメントへのリンクが案内されています。
コンテキストウィンドウ管理、ターミナル UI、ツール実行サンドボックス、モデルルーティングなど、Claude Code を動かすコードは別の場所にあります。このリポジトリはあくまでコンパニオンです。拡張性の実例を示し、運用を自動化し、リファレンス構成を提供する役割を担っています。
たとえるなら、Claude Code がオペレーティングシステムだとして、このリポジトリはアプリストアのカタログ、システム管理スクリプト、コンテナ構成、エンタープライズ向けデプロイガイドに相当します。カーネルではありません。
リポジトリマップ:4 つのゾーン
リポジトリは機能的に 4 つのゾーンに分かれています。全体像を見てみましょう。
graph TD
ROOT["anthropics/claude-code"] --> PLUGINS["plugins/<br/>Extension Ecosystem"]
ROOT --> AUTOMATION[".github/workflows/ + scripts/<br/>Automation Infrastructure"]
ROOT --> SANDBOX[".devcontainer/<br/>Sandbox Environment"]
ROOT --> EXAMPLES["examples/<br/>Enterprise Configuration"]
ROOT --> COMMANDS[".claude/commands/<br/>Repo-Level Commands"]
PLUGINS --> P1["13 official plugins"]
PLUGINS --> P2["Commands, agents, skills, hooks"]
AUTOMATION --> A1["12 GitHub Actions workflows"]
AUTOMATION --> A2["TypeScript lifecycle scripts"]
AUTOMATION --> A3["Sandboxed CLI wrappers"]
SANDBOX --> S1["Dockerfile + firewall"]
SANDBOX --> S2["Network restrictions"]
EXAMPLES --> E1["3 enterprise settings profiles"]
EXAMPLES --> E2["Hook examples"]
style PLUGINS fill:#4CAF50,color:#fff
style AUTOMATION fill:#2196F3,color:#fff
style SANDBOX fill:#FF9800,color:#fff
style EXAMPLES fill:#9C27B0,color:#fff
style COMMANDS fill:#607D8B,color:#fff
| ゾーン | パス | 内容 |
|---|---|---|
| プラグイン | plugins/ |
コマンド・エージェント・スキル・フックを持つ 13 の公式プラグイン |
| マーケットプレイス | .claude-plugin/ |
プラグイン検索用のレジストリマニフェスト |
| 自動化 | .github/workflows/ + scripts/ |
12 のワークフロー、ライフサイクルスクリプト、サンドボックス化された CLI ラッパー |
| サンドボックス | .devcontainer/ |
分離実行のための Docker + iptables ファイアウォール |
| エンタープライズ | examples/settings/ |
3 つのデプロイプロファイル(lax、strict、bash-sandbox) |
| リポジトリコマンド | .claude/commands/ |
このリポジトリの運用に特化したスラッシュコマンド |
ポイント:
.claude/commands/に入っているのは、このリポジトリ自身が使うコマンド(トリアージや重複除去など)であり、プラグインのコマンドではありません。プラグインのコマンドは各プラグインのcommands/ディレクトリに置かれています。自分で環境を構築するときは、この違いを意識しておきましょう。
プラグインマーケットプレイス
.claude-plugin/marketplace.json のマーケットプレイスマニフェストには、4 つのカテゴリにまたがる 13 の公式プラグインが登録されています。
| カテゴリ | プラグイン | 目的 |
|---|---|---|
| development | agent-sdk-dev、claude-opus-4-5-migration、feature-dev、frontend-design、plugin-dev、ralph-wiggum |
機能開発、コード移行、プラグイン作成 |
| productivity | code-review、commit-commands、hookify、pr-review-toolkit |
ワークフロー自動化、PR レビュー、Git 操作 |
| learning | explanatory-output-style、learning-output-style |
教育的なコンテキストを注入する学習モード |
| security | security-guidance |
実行時のセキュリティパターン監視 |
マニフェスト内の各プラグインエントリには、name、description、source パス、category、そしてオプションで version や author のメタデータが含まれます。source フィールドには相対パス(./plugins/feature-dev)が使われており、マーケットプレイスレジストリとディレクトリ構造が密接に結びついています。
.claude-plugin/marketplace.json#L62-L71
マーケットプレイスのスキーマ("$schema": "https://anthropic.com/claude-code/marketplace.schema.json")は、このリポジトリを超えた、より広範なプラグインマーケットプレイスインフラの存在を示唆しています。プラグインのインストールは Claude Code 内の /plugin コマンドで行い、このマニフェストはその検索ソースのひとつとなっています。
プラグインのコンポーネントモデル
すべてのプラグインは「設定より規約(convention over configuration)」のアーキテクチャに従っており、5 種類のコンポーネントタイプを持ちます。プラグインは必要なコンポーネントだけを含めれば問題ありません。
flowchart LR
MANIFEST[".claude-plugin/<br/>plugin.json"] --> DISCOVERY["Auto-Discovery<br/>Engine"]
COMMANDS["commands/<br/>*.md"] --> DISCOVERY
AGENTS["agents/<br/>*.md"] --> DISCOVERY
SKILLS["skills/<br/>*/SKILL.md"] --> DISCOVERY
HOOKS["hooks/<br/>hooks.json"] --> DISCOVERY
MCP[".mcp.json"] --> DISCOVERY
DISCOVERY --> REGISTER["Component<br/>Registration"]
style MANIFEST fill:#FF5722,color:#fff
style DISCOVERY fill:#3F51B5,color:#fff
プラグインの標準的な構造は、plugins/plugin-dev/skills/plugin-structure/SKILL.md#L22-L37 の plugin-dev スキルにドキュメントとして記載されています。
plugin-name/
├── .claude-plugin/
│ └── plugin.json # Required: Plugin manifest
├── commands/ # Slash commands (.md files)
├── agents/ # Subagent definitions (.md files)
├── skills/ # Agent skills (subdirectories)
│ └── skill-name/
│ └── SKILL.md
├── hooks/
│ └── hooks.json # Event handler configuration
├── .mcp.json # MCP server definitions
└── scripts/ # Helper scripts and utilities
最小構成のプラグインは、name フィールドを持つ plugin.json だけで成り立ちます。たとえば feature-dev プラグインのマニフェストはわずか 9 行です。
plugins/feature-dev/.claude-plugin/plugin.json#L1-L9
設計上の重要なポイントとして、プラグイン内のパス参照はすべてハードコードされたパスではなく ${CLAUDE_PLUGIN_ROOT} を使用しています。この環境変数はプラグインがインストールされた場所に解決されるため、インストール方法や OS が異なっても同じプラグインが動作します。フック設定やスクリプト参照など、あらゆる場所でこのパターンが使われています。
コンポーネントタイプの概観
次の記事で各コンポーネントタイプを詳しく掘り下げる前に、まず全体像を把握しておきましょう。
| コンポーネント | フォーマット | 検出方法 | 呼び出し方 |
|---|---|---|---|
| Commands | YAML フロントマター付き .md |
commands/ 内のすべての .md |
ユーザーが /command-name と入力 |
| Agents | YAML フロントマター付き .md |
agents/ 内のすべての .md |
コマンドまたは Claude によるオーケストレーション |
| Skills | サブディレクトリ内の SKILL.md |
skills/*/ 内のすべての SKILL.md |
コンテキストに応じて自動起動 |
| Hooks | hooks/hooks.json 内の JSON |
プラグイン有効化時にロード | イベント駆動(PreToolUse、Stop など) |
| MCP Servers | .mcp.json 内の JSON |
プラグイン有効化時にロード | Claude からのツール呼び出し |
この 5 種類は、ユーザーによる明示的な操作(コマンド)から完全自動の振る舞い(スキルとフック)まで、連続したスペクトラムを形成しています。この階層的な設計により、プラグイン作者は機能ごとに適切なユーザー関与レベルを選択できます。
ドキュメントが誤解を招きやすい点
自動生成された Wiki を含む一部のドキュメントでは、このリポジトリが Claude Code の内部実装と混同されることがあります。このリポジトリには存在しないものを明確にしておきましょう。
- コンテキストウィンドウ管理のコード — クローズドソースの npm パッケージに含まれている
- ターミナル UI の実装 — 同上
- ツール実行エンジン — サンドボックスとパーミッションシステムは内部実装である
- モデルルーティングのロジック — Haiku、Sonnet、Opus の使い分けはここに存在しない
- 会話状態管理 — セッション処理は内部実装である
一方、このリポジトリで確かに見つかるのは、Claude Code が外部に公開している拡張インターフェースです。Claude Code が読み込むプラグインの書き方、Claude Code が実行するフックの設定方法、そして Claude Code が適用するエンタープライズポリシーの設定方法がここにあります。境界線は明確です。このリポジトリは「特定のコンテキストで Claude Code が何をすべきか」を定義し、クローズドソースのコアが「それをどのように実現するか」を担います。
次のステップ
全体の地図が描けたところで、いよいよ各領域の詳細を探っていきましょう。Part 2 では、プラグインシステムを深く掘り下げ、各コンポーネントタイプを詳しく解説します。コマンドとエージェントを設定する YAML フロントマター、スキルを動かす自動起動メカニズム、そして終了コードプロトコルを持つイベント駆動のフックシステムを取り上げます。13 の公式プラグインから実際の例を使いながら、並列 AI エージェントを 7 フェーズの開発プロセスでオーケストレーションする feature-dev ワークフローを起点に解説していきます。