■ 1. Claude Codeのアーキテクチャ
- Claude CodeはRAG型のインデックスを持たず、ファイルツリーとgrepによるライブ探索を行う
- 常に最新のコードベースを参照できる一方、探索の手がかりがないとコンテキスト上限に達するリスクがある
- ハーネスの整備が探索精度に直結する
■ 2. 性能を決めるハーネス
- 性能はモデルよりもハーネスの整備で決まる
- ハーネスの構成要素と役割:
- CLAUDE.md: 文脈の提供
- hooks: 自動化
- skills: 専門知識
- plugins: 配布
- MCP: 外部ツールへの接続
- 積む順序はCLAUDE.md → hooks → skills → plugins → MCPの順が基本
- 土台が固まる前に上位層を追加しても不安定な状態が増すだけになる
■ 3. CLAUDE.mdの設計原則
- ルートのCLAUDE.mdは全体像とハマりどころのみに絞り、薄く保つ
- 細かいローカルな規約は該当サブディレクトリのCLAUDE.mdに記載する
- Claudeはディレクトリを下りながら各階層のCLAUDE.mdを順に読み込むため、ルートを薄くしても深い文脈は積み上がる
■ 4. 起動位置の最適化
- 作業はリポジトリルートではなく、タスクに関係するサブディレクトリで開始する
- サブディレクトリで起動しても、Claudeは親をたどってルートの文脈を取得する
- テスト・リントコマンドはサブディレクトリ単位でCLAUDE.mdに記載し、不要なスイート全体の実行を避ける
■ 5. hooksの活用
- hooksの主な価値は制止スクリプトではなく、設定の自己改善にある
- stop hook: セッション終了時にその回の内容を振り返らせ、CLAUDE.mdの更新案を生成することで設定を自動育成する
- start hook: セッション開始時にチーム固有の文脈を動的に読み込ませる
- リント・フォーマットなど定型チェックはhooksで機械的に実行する方がモデルへの依存より安定する
■ 6. 設定の定期棚卸し
- モデルの進化により、旧バージョン向けの指示が新モデルの能力を制限する場合がある
- 3〜6ヶ月ごと、または大きなモデル更新後に設定を棚卸しする
- モデルの弱点補完のために作ったskillsやhooksは、その弱点が解消された時点でオーバーヘッドになる
■ 7. 個人開発者向けの実践指針
- CLAUDE.mdを薄く保ち、ルートは要点とハマりどころのみにする
- サブディレクトリでClaudeを起動する習慣をつける
- stop hookを1つ導入してCLAUDE.mdを自己成長させる
- 新モデルのリリース時にCLAUDE.mdを棚卸しする
- skills、plugins、MCPは土台（CLAUDE.mdとhooks）が固まってから追加する
■ 8. 組織への普及体制
- 広いアクセス開放の前に専任の少人数チームがツールを整備することで、最初から生産的な体験を提供できる
- DRI（直接責任者）を1人定め、設定・権限ポリシー・CLAUDE.mdの規約管理を担わせる
- ボトムアップの盛り上がりだけでは良い設定が属人化し、普及が頭打ちになる