CC for Biz
2026/03/29Claude Code
Skills活用AI活用

Claude Codeプロジェクト管理|実務で使う構造化の全手順

Claude Codeプロジェクト管理|実務で使う構造化の全手順

Claude Codeでプロジェクト管理を効率化したいと考えている方に向けて、私が実務で使っているプロジェクト構造化の全手順を公開します。

Claude Codeは単なるコード生成ツールではありません。CLAUDE.md、rules/、skills/、learnings/、data/というディレクトリ構成を正しく設計すれば、プロジェクト全体の知識を構造化し、セッションをまたいで一貫した品質の成果物を出し続ける仕組みが作れます。

この記事では、私が実際に運用しているプロジェクトの構成を具体例として紹介しながら、Claude Codeでプロジェクトを管理するためのベストプラクティスをお伝えします。

なぜClaude Codeでプロジェクト管理が必要なのか

AIコーディングツールを使ったことがある方なら、こんな経験があるのではないでしょうか。

  • 毎回同じルールを説明し直す手間がかかる
  • 前回のセッションで学んだことが次のセッションに引き継がれない
  • プロジェクトが大きくなるほど、AIの出力がブレる

これらの問題は、プロジェクトの知識が構造化されていないことが原因です。Claude Codeには、プロジェクトの知識を永続化し、セッション間で引き継ぐための仕組みが最初から用意されています。それがCLAUDE.mdを中心としたファイル構成です。

実務で使っているディレクトリ構成

私が実際に運用しているプロジェクトのディレクトリ構成を紹介します。

project/
├── CLAUDE.md              ← プロジェクトの概要・ディレクトリマップ
├── .claude/
│   ├── rules/             ← ルール群(記事執筆・コーディング・ビジネス等)
│   ├── skills/            ← 業務を自動化するスキル定義
│   ├── learnings/         ← セッション中に得た知見の蓄積
│   └── settings.json      ← 権限・モデル設定
├── data/                  ← ビジネスデータ・素材
│   ├── 実績データベース.md
│   ├── ツール知見データベース.md
│   └── seo-keyword/       ← キーワード・既存記事CSV
└── website/               ← アプリケーションコード
プロジェクト構成図 — CLAUDE.mdを起点とした.claude/、data/のディレクトリ構造

この構成には明確な設計思想があります。それぞれの役割を順に解説します。

CLAUDE.md — プロジェクトの司令塔

CLAUDE.mdはClaude Codeが最初に読み込むファイルです。ここに書かれた内容がセッション全体の振る舞いを決定します。

200行以下の原則

私が実運用で得た最も重要な知見は、CLAUDE.mdは200行以下に抑えるべきという原則です。

ある調査によると、CLAUDE.mdへの記載量が一定以上増えると、コンテキスト量の増加により逆に作業精度が下がることが報告されています。私自身も、CLAUDE.mdに大量のルールを詰め込んでいた時期がありましたが、指示の遵守率が明らかに低下しました。

CLAUDE.mdに書くべき内容は以下の3つに絞ります。

  • プロジェクトの概要(何のプロジェクトか、技術スタック)
  • ディレクトリマップ(どのファイルが何の役割か)
  • 禁止事項(絶対にやってはいけないこと)

それ以外の詳細なルールは、すべてrules/に分離します。

CLAUDE.mdの実例

私のプロジェクトのCLAUDE.mdは、概要・ディレクトリ構成・外部参照先・Webサイトの構造・データソース一覧・禁止事項・ルールファイルへの参照、という構成になっています。ポイントは「ここを見ればプロジェクト全体の地図がわかる」というインデックスの役割に徹していることです。詳細な記事執筆ルールやコーディング規約は、rules/配下のファイルへのリンクで参照させています。

rules/ — ルールの分離と自動読み込み

.claude/rules/配下に置いたMarkdownファイルは、Claude Codeが自動的に読み込みます。CLAUDE.mdから詳細ルールを分離することで、CLAUDE.mdを軽量に保ちつつ、必要なルールを確実に適用できます。

私が運用しているルールファイル

  • article-writing.md — 記事執筆ルール(一人称の表記、CTA禁止、クライアント特定防止、SEOルール)
  • coding.md — コーディング規約(LP設計、画像キャッシュ方針)
  • business-context.md — ビジネスコンテキスト(サービス体系、料金、今後の予定)
  • knowledge-accumulation.md — 知見の蓄積ルール(どの情報をどのファイルに振り分けるか)

ルール分離のメリット

ルールをファイル単位で分離すると、以下のメリットがあります。

  • メンテナンスが容易:記事ルールだけ変えたいとき、そのファイルだけ編集すればよい
  • コンテキストの効率化:Claude Codeは関連するファイルを操作するときに、対応するルールを優先的に参照する
  • チーム共有が可能:rules/をgitで管理すれば、チーム全員が同じルールで作業できる

skills/ — 繰り返し業務の自動化

skills/は、繰り返し行う業務をスキルとして定義するディレクトリです。スキルを一度作ってしまえば、/スキル名のスラッシュコマンドで呼び出すだけで、複雑な業務フローを自動実行できます。

実例:SEO記事作成スキル

私が実務で最も頻繁に使っているのが、SEO記事を作成してMicroCMSに投稿するスキルです。このスキルは以下の一連の業務を自動化しています。

  • キーワードCSVと既存記事CSVを読み込み、書くべき記事を提案
  • 実績・知見データベースから関連する一次情報を自動収集
  • SEOルールに従って記事を執筆
  • サムネイル画像を生成
  • MicroCMSにAPI経由で投稿
  • 既存記事CSVを自動更新

このスキルがなければ、1記事あたり数時間かかる作業が、キーワードを指定するだけで完了します。

learnings/ — セッション知見の蓄積

learnings/は、セッション中に得た一時的な知見を月単位で蓄積するディレクトリです。

知見の振り分けテーブル

私のプロジェクトでは、知見の種類に応じて蓄積先を明確に振り分けています。

  • 案件実績・エピソード → 実績データベース
  • AIツールの使用知見 → ツール知見データベース
  • 記事の投稿記録 → 既存記事CSV
  • コーディング規約の変更 → rules/coding.md
  • 分類しにくい一時的な知見 → learnings/YYYY-MM.md

learnings/に蓄積された知見は月末に棚卸しを行い、重要なものは正式なファイル(rules/やデータベース)に昇格させます。不要なものは削除します。この運用により、プロジェクトの知識が自然と整理されていきます。

data/ — ビジネスデータの一元管理

data/ディレクトリには、記事執筆やビジネス判断に必要なデータを集約しています。

  • 実績・経験データベース:案件の実績、成果、「自分しか書けない」要素のリスト
  • AI開発ツール知見データベース:各AIツールの使用体験、比較知見、活用哲学
  • SEOキーワードデータ:キーワードの検索ボリューム、競合性、既存記事の一覧

このデータ群がスキルやルールと連携することで、データに基づいた一貫性のある成果物が生まれます。たとえばSEO記事作成スキルは、実績データベースから一次情報を自動で引用し、既存記事CSVで重複を防ぎ、キーワードデータで検索ニーズを把握した上で記事を執筆します。

settings.json — 権限とモデルの制御

.claude/settings.jsonはClaude Codeの動作設定を管理するファイルです。CLAUDE.mdにはプロジェクトの知識を、settings.jsonには技術的な設定を、という使い分けが重要です。

settings.jsonで主に設定するのは以下の項目です。

  • permissions:どのツール(Bash、Read、Write、MCP等)を許可するか
  • model:使用するモデル(opus、sonnet等)
  • thinking:拡張思考の有効化

ワイルドカードを使った権限設定(例:mcp__microcms__*)で、MCP経由の操作をまとめて許可できるのも実務で便利なポイントです。

プロジェクト構造化の3つの原則

ここまでの内容を踏まえて、Claude Codeでプロジェクトを構造化する際の3つの原則をまとめます。

原則1:CLAUDE.mdはインデックスに徹する

CLAUDE.mdには概要・地図・禁止事項だけを書きます。200行以下を目安に、詳細は必ずrules/に分離します。書きすぎると精度が下がるという実体験に基づいた原則です。

原則2:ルール・スキル・データを分離する

プロジェクトの知識を「ルール(rules/)」「業務フロー(skills/)」「データ(data/)」の3層に分離します。それぞれが独立してメンテナンス可能で、組み合わせて動作する設計です。

原則3:知見の蓄積フローを設計する

セッションごとに得られる知見を、どのファイルに振り分けるかのルールを最初に決めておきます。knowledge-accumulation.mdのような振り分けテーブルを作ることで、プロジェクトの知識が自然に成長していきます。

まとめ

Claude Codeでプロジェクトを管理する際のポイントをまとめます。

  • CLAUDE.mdは200行以下でプロジェクトの地図に徹する
  • rules/に詳細ルールを分離して自動読み込みさせる
  • skills/で繰り返し業務を自動化する
  • learnings/で一時知見を蓄積し、月末に正式ファイルへ昇格させる
  • data/にビジネスデータを集約し、スキルから参照させる
  • settings.jsonで権限とモデルを制御する

この構造を一度作ってしまえば、セッションをまたいでも一貫した品質の成果物が出続けます。私自身、この構成でSEO記事の執筆からWebサイト開発、ビジネスデータの管理まで、ほぼすべての業務をClaude Codeと協働で進めています。

プロジェクト管理の構造化は、Claude Codeを「ただのAIツール」から「チームの一員」に変える最も効果的なアプローチです。

← 記事一覧に戻る

御社の業務に合わせたClaude Code導入支援

「AIツールを導入したが、現場で使われない」を終わらせる。
業務課題のヒアリングから設計、ハンズオン実践、運用定着まで一貫して支援します。

無料AI活用診断を受けるサービス詳細を見る →
© 2025 Fyve Inc. All rights reserved.