実務30+ルールのCLAUDE.md設計パターン2026 — 大規模運用の実践ガイド
Claude Codeの性能はCLAUDE.mdの設計で決まる。同じモデル（Opus 4.6）を使っていても、CLAUDE.mdの構造次第で生産性が3〜5倍変わることは珍しくない。
Qiitaの公式ニュースコラムでもCLAUDE.mdの設計記事が取り上げられ、開発者コミュニティで大きな注目を集めている。しかし既存の記事の多くは「こう書くとよい」という理論的なアドバイスに留まり、実際に大規模運用しているCLAUDE.mdの構造を公開しているものは見当たらない。
本記事では、30以上のルール・20以上のSkills・複数のMCPサーバーを統合し、開発からコンテンツ制作・ビジネスオペレーションまでを1つのCLAUDE.mdで管理している筆者の運用経験から、実践的なCLAUDE.mdの書き方とベストプラクティスを解説する。
この記事の対象読者: Claude Codeのルールが10個を超え、CLAUDE.mdの管理に限界を感じ始めた開発者・チームリーダー。5ルール以下の方はまずClaude Code実践ガイドで基礎を押さえてほしい。
※ この記事にはアフィリエイトリンクが含まれています
目次
- なぜCLAUDE.mdの「設計」が必要なのか
- CLAUDE.mdのアーキテクチャ：3層分離モデル
- Skills設計パターン
- マルチエージェント統制
- 失敗駆動型のルール進化
- MCP統合
- 非開発ワークフローへの拡張
- 起動時タスクとセッション管理
- アンチパターン集
- 実践テンプレート
- まとめ
1. なぜCLAUDE.mdの「設計」が必要なのか
Claude CodeはセッションごとにCLAUDE.mdをシステムプロンプトとして読み込む。ここに書かれた内容がAIの行動を制御する「憲法」になる。
問題はスケールだ。ルールが5個なら箇条書きで十分だが、実務で運用するとルールは増え続ける：
- セキュリティルール（認証情報のハードコード禁止）
- 品質ルール（テスト必須、レビュー必須）
- 運用ルール（デプロイ手順、通知先）
- ビジネスルール（顧客対応、コンプライアンス）
30を超えたあたりで「全部CLAUDE.mdに書く」は破綻する。Claude Codeには150〜200の有効instructionという実質的な上限があるためだ（HumanLayerの研究による）。
この記事で解説するのは、制限の中で最大の効果を得る設計パターンだ。
2. CLAUDE.mdのアーキテクチャ：3層分離モデル
2.1 全体構造
CLAUDE.mdを「ルーティングテーブル」として設計する。詳細は外部ファイルに委任し、CLAUDE.md本体は参照と判断基準だけを持つ。この構造はTypeScriptの設計パターンと同じ「関心の分離」の発想だ。
CLAUDE.md（ルーティングテーブル）
├── 絶対ルール（15-20行） ← 常に遵守すべき不変のルール
├── ドキュメント索引（30-40行） ← 業務別に参照先を提示
├── 起動時タスク（5-10行） ← セッション開始時の初期化処理
└── コーディング規約（10行） ← 技術スタック・スタイル2.2 ルーティングテーブル方式の実例
## 絶対ルール
| # | ルール | 参照 |
|---|--------|------|
| 1 | テスト必須（TDD） | `docs/guides/tdd-guide.md` |
| 2 | 認証情報ハードコード禁止 | `docs/guides/credential-management.md` |
| 3 | デプロイ前にレビュー必須 | `docs/guides/review-criteria/code.md` |
## 業務別ドキュメント索引
### 開発
| ドキュメント | パス |
|-------------|------|
| デザインシステム | `docs/design/design-system.md` |
| API設計規約 | `docs/guides/api-design.md` |
### コンテンツ制作
| ドキュメント | パス |
|-------------|------|
| ブログ運用ガイド | `docs/guides/blog-guide.md` |
| SEO最適化計画 | `docs/guides/seo-plan.md` |ポイント: CLAUDE.mdには「何をすべきか」と「どこを見ればよいか」だけを書く。「どうやるか」は参照先のドキュメントに書く。
2.3 .claude/ ディレクトリの活用
Claude Code v2.1以降、.claude/ ディレクトリが標準構造として認識される：
.claude/
├── settings.json ← 許可コマンド・MCP設定
├── rules/ ← 自動読み込みルール（CLAUDE.mdから分離）
│ ├── security.md
│ └── testing.md
└── skills/ ← 業務別プロンプト
├── deploy/
│ └── SKILL.md
├── review-pipeline/
│ └── SKILL.md
└── project-blog/
└── SKILL.md.claude/rules/ に置いたMarkdownファイルはCLAUDE.mdと同様に自動的に読み込まれる。これにより、ルールをカテゴリごとに分離してもClaude Codeの認識漏れがない。セキュリティルールの具体例はWebセキュリティ OWASP対策ガイドも参考にしてほしい。
3. Skills設計パターン：業務をモジュール化する
3.1 Skillsとは
Skills（.claude/skills/*/SKILL.md）は「特定業務のためのプロンプトテンプレート」だ。ユーザーが /skill-name と入力するか、Claude Codeが自動で判断して呼び出す。
3.2 スキルの粒度設計
経験上、最も効果的なスキルの粒度は**「1つのスキル = 1つの判断フロー」**だ：
# deploy/SKILL.md
## 必須フロー
1. テストスイート実行（全パス必須）
2. ビルド確認（エラーゼロ）
3. 差分確認（意図しない変更がないか）
4. プレビューデプロイ → 動作確認
5. 本番デプロイ
## 判断基準
- テスト失敗 → デプロイ中止
- 新しい依存関係追加 → セキュリティ確認
- DB変更あり → マイグレーション手順書を先に作成3.3 スキル間の依存管理
スキルが増えると依存関係が生まれる。これを管理するパターン：
# project-blog/SKILL.md
## 必読スキル・ドキュメント
| 必読 | パス |
|------|------|
| コンテンツ共通マニュアル | `docs/guides/content-common-manual.md` |
| サムネイル生成 | `.claude/skills/generate-image/SKILL.md` |
| デプロイ | `.claude/skills/deploy/SKILL.md` |
| レビューパイプライン | `.claude/skills/review-pipeline/SKILL.md` |
## 必須フロー（この順番を厳守）
1. 競合分析 → 記事テーマ確定
2. 執筆 → 下書き保存
3. **別エージェントでレビュー（80点必須）**
4. サムネイル生成
5. デプロイ「必読スキル・ドキュメント」セクションを各スキルの冒頭に置くことで、Claude Codeが関連スキルのコンテキストを自動で把握する。
4. CLAUDE.mdでマルチエージェント統制：レビューパイプライン
4.1 なぜ「別エージェント」でレビューするのか
Claude CodeのAgentツールを使うと、メインのClaude Codeからサブエージェントを起動できる。重要なのは実行者とレビュアーを分離すること：
## レビュールール
- 全実行結果は別エージェント（Agent tool）でレビュー必須
- 自分自身でのレビューは禁止
- レビュースコア80点未満 → 修正して再レビュー自己レビューは甘くなる。AIも例外ではない。コードを書いたエージェントと、それをレビューするエージェントを分離することで、品質が目に見えて向上する。
4.2 レビュータイプの設計
業務によってレビュー基準は異なる：
| 業務 | レビュータイプ | 主要チェック項目 |
|---|---|---|
| 開発 | code + test | 正確性・セキュリティ（OWASP）・テストカバレッジ |
| ブログ | content + revenue | ペルソナ適合・SEO・収益導線 |
| 顧客対応 | customer | 15項目チェックリスト・トーン・正確性 |
| デザイン | design-comp | カンプとの7項目照合 |
各レビュータイプの基準は docs/guides/review-criteria/ に独立ファイルとして管理する。
4.3 worktree分離による並列実行
複数のサブエージェントを並列実行する場合、ファイル操作の競合を防ぐためworktree分離を使う（Auto Modeと組み合わせるとさらに効果的）：
## 並列実行ルール
Agent並列委任にworktree分離推奨。
特にファイル書き込みが発生するAgent同士は
必ず isolation: "worktree" を指定する。これはgitのworktree機能を使い、各エージェントに独立したファイルシステムコピーを与える仕組みだ。
5. 失敗駆動型のルール進化
5.1 インシデントからルールを生む
CLAUDE.mdのルールの多くは「失敗から生まれた」ものだ。理論的に完璧なルール体系を事前に設計するのではなく、実際のインシデントを分析し、再発防止のためのルールを追加する。
例：
インシデント: 送信先URLの確認を怠り、別のクライアントにメッセージを誤送信
追加されたルール:
| 14 | CDP/ブラウザ送信前は必ず別エージェントで
| | 送信先URL・宛名を三重確認 |5.2 lessons-learned.mdパターン
インシデントを体系的に管理するため、lessons-learned.mdに失敗パターンをID付きで蓄積する：
## P-010: 送信先誤り
- **発生日**: 2026-02-XX
- **原因**: 送信先URLの事前検証を省略
- **対策**: 三重確認ルール追加（URL・宛名・内容の整合性）
- **CLAUDE.mdへの反映**: Rule 14に追加済みこのファイルをレビューパイプラインが自動参照することで、過去の失敗パターンがすべてのレビューに自動注入される。
6. MCP統合：CLAUDE.mdからツールを制御する
6.1 MCPサーバーとの連携パターン
MCP（Model Context Protocol）サーバーを使うと、Claude Codeに外部ツールの操作能力を追加できる。CLAUDE.mdでの管理パターン：
## ブラウザ操作ルール
| # | ルール |
|---|--------|
| 30 | browser-manager MCP第一優先で使用 |
| 30 | 失敗時のみフォールバックスクリプト使用 |
## MCPプロファイル
| プロファイル | ポート | 用途 |
|-------------|-------|------|
| main | 9222 | メイン業務 |
| secondary | 9223 | サブアカウント |
| sns | 9224 | SNS管理 |6.2 ツール優先順位の明示
外部ツールが複数ある場合、CLAUDE.mdで優先順位を明示する：
ブラウザ操作:
① browser_* MCPツール（第一優先）
② scripts/openclaw-exec.sh（MCP失敗時）
③ Playwright MCP直接使用（最終フォールバック）これにより、Claude Codeは最適なツールを自動選択できる。
MCPサーバーを安定稼働させるにはClaude Codeを常時起動できるLinuxサーバーが必要だ。筆者はXServer VPS（2GBプラン・月830円）でClaude Codeを24時間稼働させ、上記のMCPプロファイル3つを含む複数エージェントを常時処理している。
XServer VPS — root権限付きLinux VPS。tmux + Claude Codeで自律エージェントを24時間稼働。月830円から。
7. 非開発ワークフローへの拡張
7.1 CLAUDE.mdは開発専用ではない
多くの記事がCLAUDE.mdを「開発プロジェクトの設定ファイル」として扱っているが、実際にはあらゆる業務を制御できる：
- コンテンツ制作: ブログ記事の品質基準・SEOルール・公開フロー
- 営業: 提案テンプレート・品質チェックリスト
- 顧客対応: 返信ルール・承認フロー・コンプライアンス
- 収益管理: 収支記録ルール・KPI追跡
7.2 ビジネスルールのコード化例
## 顧客対応ルール
| # | ルール |
|---|--------|
| 13 | クライアントからの連絡は即通知→指示待ち |
| 14 | 返信は必ずデュアルエージェントレビュー後に送信 |
| 15 | 交渉要素を含む返信は必ずオペレーター確認後 |
| 16 | 署名は会社名のみ・個人名禁止 |ビジネスルールをCLAUDE.mdに書く最大の利点は一貫性だ。チームの誰が（またはどのAIエージェントが）作業しても、同じルールが適用される。
CLAUDE.mdの設定を効率化: DevToolBox のJSON整形ツールで
.claude/settings.jsonのバリデーション、Diff比較でCLAUDE.mdの変更履歴を確認。開発者向けツールが無料で使えます。
8. 起動時タスクとセッション管理
8.1 セッション開始を自動化する
CLAUDE.mdに起動時タスクを設定すると、Claude Codeの起動時に自動実行される。筆者の環境では以下の3ステップをセッション開始時に毎回実行している：
## 起動時タスク
1. `node system/cli.mjs health` でシステムヘルスチェック
- DB接続・MCP接続・ディスク容量を確認
2. `node system/cli.mjs alerts` で未処理アラート確認
- P0/P1アラートがあれば他のタスクより先に対応
3. `node system/cli.mjs tasks` で進行中タスクの状態確認
- 前セッションからの引き継ぎタスクを把握ポイント: 起動時タスクはCLIコマンドの具体的な記載が効果的。「ヘルスチェックを実行」だけだとClaude Codeが何を実行すべきか判断に迷うが、コマンドを書いておけば迷わず実行する。
8.2 Hooksによるイベント駆動
Claude Code v2.1のHooks機能を使うと、ツール実行の前後にシェルスクリプトを自動実行できる。.claude/settings.jsonで設定する：
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": ["scripts/pre-bash-check.sh"]
}
],
"PostToolUse": [
{
"matcher": "Write",
"hooks": ["scripts/post-write-lint.sh"]
}
]
}
}これにより「Bashコマンド実行前にセキュリティチェック」「ファイル書き込み後に自動Lint」等のガードレールを自動化できる。
8.3 状態管理のSSoT（Single Source of Truth）
プロジェクトの状態はSQLiteなどのデータベースで管理し、CLIツールで操作する。CLAUDE.mdにはコマンドリファレンスを書いておく：
# CLAUDE.mdに書くCLI例
node system/cli.mjs report # 全体レポート
node system/cli.mjs alerts # アラート一覧
node system/cli.mjs tasks # タスクキュー
node system/cli.mjs health # ヘルスチェックMarkdownファイルに状態を書く方法は小規模では機能するが、30以上のタスクを並行管理する段階ではデータベースに移行すべきだ。SQLiteは軽量・ゼロ設定でClaude Codeとの相性が良い。WALモードを有効にすれば、読み書きの競合も回避できる。
9. アンチパターン集
❌ 全部をCLAUDE.mdに書く
150行を超えたCLAUDE.mdは、Claude Codeの注意力を分散させる。ルーティングテーブル方式に移行せよ。
❌ /init の出力をそのまま使う
claude /init が生成するCLAUDE.mdは汎用テンプレートであり、プロジェクト固有の知識は含まれない。あくまで出発点として使い、運用しながら育てる。
❌ Linterで制御すべきルールを書く
「インデントはスペース2つ」「セミコロン必須」はCLAUDE.mdではなくESLint/Prettierで制御する。CLAUDE.mdには「なぜ」を書き、「何」はツールに任せる。
❌ 具体的な失敗理由なしにルールを追加する
「コードレビューを厳しくする」は漠然としていて効果が薄い。「P-010: 送信先誤りの再発防止のため、送信前に三重確認」のように、具体的なインシデントに紐づけることでルールが記憶に定着する。
❌ 一度書いたルールを放置する
状況は変わる。月1回のCLAUDE.mdレビューで、形骸化したルールを削除・更新する。
10. 実践テンプレート
10.1 小規模プロジェクト向け（〜50行）
# CLAUDE.md
## プロジェクト概要
[プロジェクト名] — [一行の説明]
## 技術スタック
- フロントエンド: React + TypeScript
- バックエンド: Node.js + Express
- DB: PostgreSQL
- ホスティング: [サーバー名]
## 絶対ルール
1. テスト必須 — テストなしのPRは禁止
2. 認証情報は .env のみ — ハードコード禁止
3. main ブランチへの直接push禁止
## コマンド
- `npm run dev` — 開発サーバー起動
- `npm test` — テスト実行
- `npm run build` — ビルド10.2 中規模プロジェクト向け（〜150行）
上記に加えて：
## ドキュメント索引
| 領域 | パス |
|------|------|
| API仕様 | `docs/api-spec.md` |
| DBスキーマ | `docs/db-schema.md` |
| デプロイ手順 | `docs/deploy-guide.md` |
## Skills
| スキル | 用途 |
|--------|------|
| `/deploy` | デプロイ実行 |
| `/review` | コードレビュー |
## レビュールール
- コード変更後は `/review` で品質チェック
- スコア80点未満はマージ禁止10.3 大規模プロジェクト向け（200行+Skills分離）
本記事で解説したフルパターン：
- ルーティングテーブル方式のCLAUDE.md
.claude/rules/にカテゴリ別ルール.claude/skills/に業務別スキルdocs/guides/review-criteria/にレビュー基準lessons-learned.mdに失敗パターン蓄積- SQLiteベースの状態管理
テンプレートをさらに活用したい方へ: 本記事のテンプレートを含む開発者向けのチートシートやツールはBOOTHでも公開している。また、Claude Codeの実践的な運用ノウハウはnoteの技術記事シリーズでも詳しく解説中だ。
11. まとめ：CLAUDE.mdは「育てる」もの
CLAUDE.mdの設計で最も重要なのは、最初から完璧を目指さないことだ。
- 小さく始める — 5つのルールから始め、必要に応じて追加
- 失敗から学ぶ — インシデントが起きたらルール化
- 定期的に棚卸し — 月1回の見直しで形骸化を防止
- スケールしたら分離 — 30ルールを超えたらSkills/rules/docsに委任
- 非開発にも拡張 — ビジネスルールもCLAUDE.mdで管理できる
この記事で紹介したパターンが、あなたのClaude Code運用の参考になれば幸いだ。
Claude Codeを24時間稼働させるサーバー選び
本記事で紹介したSkills・MCP・マルチエージェント統制を最大限活用するには、Claude Codeをリモートサーバーで常時稼働させるのが効果的だ。tmux + Claude Codeの組み合わせで、自律エージェントが24時間タスクを処理し続ける環境を構築できる。
ここでは、SSH対応でClaude Codeを直接実行できるサーバーを紹介する。筆者はXServer VPSの2GBプランで運用しており、tmux 3セッションにClaude Codeエージェントを常駐させている。月830円で24時間自律処理が動く環境は十分にROIが出る。
| サーバー | 月額目安 | 特徴 | 選ぶ基準 |
|---|---|---|---|
| XServer VPS ★推薦 | 830円〜 | root権限・Linuxフル管理・メモリ2GB〜 | Claude Code常時稼働ならこれ一択。root+tmux+十分なメモリ |
| さくらのVPS | 643円〜 | 安定性と老舗の信頼・石狩DC | コスト最優先 or 既にさくらアカウントがある場合 |
| XServer for WordPress | 990円〜 | SSH対応・WP特化 | WPサイト＋Claude Codeを1台でまとめたい場合 |
| さくらのレンタルサーバ | 500円〜 | 安価・root権限なし | サブプロジェクトのWebホスティング用途のみ |
VPS（Claude Code常時稼働に最適）
XServer VPS ★筆者使用中 — root権限付きLinux VPS。tmux + Claude Codeで自律エージェントを24時間稼働。月830円から。
さくらのVPS — 老舗の安定性とコスパ。石狩DCの低レイテンシでClaude Code応答も快適。月643円から。
レンタルサーバー（Webプロジェクト＋SSH開発用）
XServer for WordPress — 国内シェアNo.1。SSH対応でClaude Codeからの直接デプロイも可能。初期費用無料。
さくらのレンタルサーバ — 月500円からの低コスト。サブプロジェクトのホスティングに。
関連記事:
- Claude Code実践ガイド2026 — 導入からCI/CD統合まで
- Claude Code Auto Mode完全ガイド — 安全な自律実行の仕組み
- AIコーディングツール完全ガイド2026 — GitHub Copilot・Cursor・Claude Code比較
- Vibe Coding入門ガイド2026 — AIと対話しながら開発する新常識