everything-claude-codeの設計思想 - 「考え方」をわかりやすく解説
こんにちは、とまだです。
「Claude Codeをもっと使いこなしたい」と思っていませんか。
Anthropicハッカソン優勝者が公開した設定集「everything-claude-code」が話題になっています。90万view以上、1万以上のブックマークを獲得した注目のリポジトリです。
ただ、設定ファイルの一覧を見ても、何が大事なのかピンと来ない方も多いのではないでしょうか。
今回伝えたいことの要点は 「コンテキストを最適化する」 という考え方です。一言で言えば、AIに渡す情報を整理し、必要なときに必要なものだけを提供する仕組みを作るということ。これがeverything-claude-codeの本質だと私は考えています。
この記事では、設定ファイルの詳細ではなく「なぜそうするのか」という設計思想を解説します。たとえ話を交えながら、概念レベルで理解できるようにお伝えしていきますね。
忙しい人のために要約
この記事で伝えたいポイントを5つにまとめました。
- 専門家チームを作る - 一人で全部やらせない、専門特化したエージェントに委譲するから効率が上がる
- マニュアルを整備する - 暗黙知を明文化しておくと毎回説明する手間が省けるため生産性が向上
- 自動化で確実に - AIの判断に頼らず機械的に実行する仕組みがあれば漏れがなくなる
- リソースを節約する - 使わないMCPは外してコンテキストウィンドウを守ることが重要
- 本質はコンテキストエンジニアリング - 情報の断捨離がすべての基盤になっている
全体像：要するに何をやっているのか
everything-claude-codeには6種類のファイルがあります。具体的には、agents、skills、commands、rules、hooks、mcp-configsの6つです。
「種類が多くて覚えられない」と感じる方もいるかもしれません。そこで、会社組織にたとえてみると理解しやすくなるでしょう。
| ファイル種別 | 会社組織でたとえると |
|---|---|
| agents | 専門部署（設計部、品質管理部、セキュリティ部） |
| skills | 業務マニュアル・手順書 |
| commands | よく使う操作のショートカット |
| rules | 社訓・ポリシー・行動指針 |
| hooks | 自動チェック機構・警報装置 |
| mcp-configs | 外部取引先との連携設定 |
つまり、会社組織と同じように、全員がなんでもやるのではなく、役割分担して効率的に動く仕組みを作っているわけです。
これらの6種類のファイルの使い分けについては、別な記事で詳しく整理しています。
Claude Code の6つの拡張機能、結局どう使い分ければいいの？
ポイント1：専門家チームのように使う
everything-claude-codeで最も特徴的なのは、サブエージェントの活用です。
考え方としては「なんでも屋」より「専門家チーム」を選ぶということ。
建築現場をイメージしてみてください。設計士、大工、電気工事士、配管工がそれぞれの専門分野を担当していますよね。一人で全部やろうとするより、専門家に任せた方が品質も効率も上がるからです。
具体的には、everything-claude-codeでは以下のようなエージェントが定義されています。
- planner - 実装計画を立てる設計士
- code-reviewer - コード品質をチェックする品質管理担当
- security-reviewer - 脆弱性を検出するセキュリティ専門家
- tdd-guide - テスト駆動開発を指導するコーチ
ここで重要なのは、各エージェントに「最小限のツールだけを与える」という点です。なぜなら、50個のツールを持つエージェントより、5個に絞ったエージェントの方が集中して動作するからです。
一方で、エージェントを増やしすぎると管理が複雑になるデメリットもあります。そのため、最初から全部作る必要はありません。自分のワークフローで繰り返し発生するタスクを見つけて、徐々に追加していくのがよいでしょう。
サブエージェントの仕組みや作成方法については、別な記事で詳しく解説しています。
Claude Codeのサブエージェントとは？並列処理とコンテキスト分離の仕組み
ポイント2：マニュアルを整備する
rulesとskillsは、暗黙知を明文化するためのファイルです。
新人研修マニュアルを想像してみてください。「うちの会社ではこうやる」という暗黙のルールがあるはずですよね。それを文書化しておけば、毎回説明する手間が省けるわけです。
具体的には、everything-claude-codeでは以下のようなルールが定義されています。
- security.md - コミット前にチェックすべきセキュリティ項目
- coding-style.md - イミュータビリティ、ファイル構成のルール
- testing.md - TDDワークフロー、80%カバレッジ要件
これらを一度整備しておけば、Claude Codeは常にそのルールに従って動いてくれます。つまり、「前も言ったけど、テストは先に書いてね」と毎回指示する必要がなくなるのです。
ただし、ルールファイルが巨大になりすぎるとコンテキストを圧迫してしまいます。そのため、everything-claude-codeでは関心事ごとにファイルを分割し、モジュラーに管理することを推奨しているのでしょう。
Claude Codeには、特定のファイル操作時にのみルールを読み込む「動的ルール読み込み」機能があります。ルール整備に興味がある方は、別な記事で詳しく解説しています。
Claude Codeの動的ルール読み込み機能（.claude/rules/）でCLAUDE.mdの肥大化を解決！
ポイント3：自動化で確実に
CLAUDE.mdに「ファイル編集後はフォーマットして」と書いても、実行されるかどうかはAIの判断次第です。
対応してくれる時もあれば、忘れる時もありますよね。これを「不安定だな」と感じた方もいるかもしれません。
そこでhooksの出番です。hooksは特定のイベントで確実に発火する自動化の仕組みになっています。工場のセンサーや警報装置のようなものと考えてください。温度が一定を超えたら警報が鳴るように、人間の判断を介さず機械的に実行されるからです。
例えば、everything-claude-codeで定義されているフックには以下のようなものがあるのです。
- TypeScriptファイル編集後にPrettierで自動フォーマット
- console.logが残っていたら警告を表示
- git push前にレビュー確認で一時停止
- 開発サーバーをtmux外で起動しようとしたらブロック
「確実に」実行される安心感こそが、hooksの価値ではないでしょうか。
一方で、自動実行されるため設定を間違えると意図しない動作が発生するリスクもあります。そのため、最初はシンプルなフック（console.log警告など）から始めて、徐々に追加していくのが賢明でしょう。
Hooksの基本的な仕組みや設定方法については、別な記事で詳しく解説しています。
Claude CodeのHooksとは？ライフサイクルイベントで処理を自動化する
ポイント4：リソースを管理する
ご存じない方のために補足すると、MCPはClaude Codeを外部サービスに接続するプロトコルで、GitHub、Supabase、Vercelなど様々なサービスと連携できる仕組みになっています。
ただし、ここに最も重要な注意点があるのです。
MCPを有効にしすぎると、コンテキストウィンドウが大幅に縮小してしまいます。なぜなら、200kあったコンテキストが70kまで減少する可能性があるからです。
「そんなに減るの？」と驚く方もいるかもしれません。そこで、スマホのアプリ整理をイメージしてみてください。使わないアプリをたくさんインストールしていると、ストレージを圧迫してパフォーマンスが落ちますよね。そのため、使うアプリだけ残して、あとは削除するか無効化しておくわけです。MCPも同じ考え方になります。
そのため、everything-claude-codeでは以下の運用を推奨しているのです。
- 設定ファイルには20〜30個のMCPを登録
- プロジェクトごとに10個以下を有効化
- 有効なツールは80個以下に抑える
実際、著者自身も14個のMCPを設定しながら、有効化しているのは5〜6個だけとのこと。この割り切りが重要なのでしょう。
設計思想の本質：コンテキストエンジニアリング
ここまで4つの概念を見てきましたが、すべてに共通するのは「コンテキストを最適化する」という考え方です。
- エージェント分割 → タスクごとに必要な情報だけを渡す
- ルール整備 → 毎回説明する情報を事前に与えておく
- フック自動化 → AIの判断領域を減らしてコンテキストを節約
- MCP管理 → 不要なツール情報でコンテキストを圧迫しない
つまり、これはAnthropic社が提唱する「コンテキストエンジニアリング」の実践そのものなのです。
コンテキストエンジニアリングとは？AI駆動開発で成果を出すための新しいスキル
プロンプトの書き方だけでなく、AIに渡す情報全体を管理する。必要な情報を必要なタイミングで渡す。この考え方がeverything-claude-codeの設計思想の根底にあると私は考えています。
自分なりの使い方のヒント
everything-claude-codeをそのまま全部コピーする必要はありません。
まずは自分のワークフローを振り返ってみてください。
- 毎回同じ指示を出していることはないか？ → ルール化の候補
- 繰り返し行うタスクはないか？ → エージェント化の候補
- 忘れがちなチェックはないか？ → フック化の候補
おすすめの最初の一歩は、console.logの警告フックです。なぜなら、シンプルで効果がわかりやすく、本番環境へのデバッグコード混入を防げるからです。
一度に全部やろうとせず、徐々に追加していくのがコツだと思います。設定が増えすぎると逆にコンテキストを圧迫するという、ある種の皮肉な状況に陥ることもありますしね。
まとめ
everything-claude-codeの設定ファイルは、単なる「道具」ではなく「思想」の体現です。
核心にあるのは「コンテキストを最適化する」という考え方。まずは1つ、試してみてください。
Claude Codeを体系的に学びたい方へ
Claude CodeやCLAUDE.mdの使い方をさらに深く学びたい方向けに、Udemyで講座を公開しています。
CLAUDE.md、ルールファイル、カスタムコマンド、サブエージェント、Skills、Hooksなど、この記事で紹介した概念を実践的に学べる内容になっています。
Discussion