2026-05-01
CLAUDE.md と skills で設定を整理した
はじめに
普段仕事でClaudeを使っていて、事前に設定していたルールを守っていないソースを見つけることがある。
Claudeに聞いてみた。
💬 ぼく
CLAUDE.mdの内容を見落とすことってあるの?
🤖 Claude
あります。
CLAUDE.md は会話の最初にコンテキストとして読み込まれますが、実装に集中しているとき禁止事項リストを一つひとつ照合せずに書いてしまうことがあります。今回がまさにそれでした。
ルールが増えるほど見落としリスクも上がるので、特に重要なものは都度指摘してもらえると助かります。
Claudeでの制作に慣れてくると、軽微な変更、特にwebのフロントまわりについては
Claude側から許可の問い合わせがあっても、よく確認もせずにOK!といった感じでyesと答えがちだ。
今回のケースは、デプロイ前に差分を見てルール違反に気づいた。
現在の時点でのベストなCLAUDE.mdの作成・設置方法について考えていく。
ファイル設置場所について
CLAUDE.mdはどこに置けばいいのか、これも聞いてみた。
💬 ぼく
CLAUDE.mdってどこに置くのがベスト?
🤖 Claude
置き場所は3つあって、用途で使い分けるのがベストです。
① ホームディレクトリ(
~/.claude/CLAUDE.md)
全プロジェクト共通のルールを書く場所。「コメントは日本語で」「絵文字は使わない」など、自分のスタイルはここに。② プロジェクトルート(
./CLAUDE.md)
そのプロジェクト固有のルールを書く場所。チームで共有したいルール、使用フレームワークの制約などはここ。③ サブディレクトリ(
./src/CLAUDE.mdなど)
特定のディレクトリだけに適用したいルールがあるときに使う。フロントとバックでルールを分けたい場合などに有効です。
つまりこんなイメージ:
| 置き場所 | 対象 | 用途例 |
|---|---|---|
~/.claude/CLAUDE.md |
全プロジェクト | 個人の作業スタイル |
./CLAUDE.md |
プロジェクト全体 | チームルール・技術スタック |
./src/CLAUDE.md |
特定ディレクトリ | ディレクトリ固有の制約 |
自分はプロジェクトルートだけで運用しているけど、個人ルールはホームに分けておくとどのプロジェクトでも使えて便利そう。
.claude/ ディレクトリで管理する
好みの問題かもしれないけど。
💬 ぼく
skillsとか使っていく場合は .claude ディレクトリをプロジェクトルートに作成して、その配下にファイル設置するのがいいような気がするけど、どう?
🤖 Claude
それが正解です。
.claude/ディレクトリはClaude Code公式の設置場所で、以下のファイルをまとめて管理できます。.claude/ ├── CLAUDE.md # プロジェクトのルール ├── settings.json # 権限・フックなどの設定 └── commands/ # カスタムスラッシュコマンドプロジェクトルートに直接
CLAUDE.mdを置く方法も動きますが、.claude/にまとめておくと管理しやすいですし、チームで共有するときもわかりやすいです。
.claude/ ディレクトリで一元管理するのがスッキリしそう。
既存プロジェクトはルートに置いているものもあったので、移行することにした。
skillsとは
skills は Claude Code に特定の処理をスラッシュコマンドとして登録できる機能だ。
.claude/commands/ 配下に Markdown ファイルを置くだけで自作コマンドを作れる。よく使う指示をコマンド化しておくと、毎回同じプロンプトを書く手間が省けて便利。
.claude/
└── commands/
└── my-review.md # → /my-review で呼び出せる
実際に使ってみると、思ったほど頻繁には使わなかった。チャットで普通に指示すれば済むことが多いからだ。ただ、チームで使う場合は話が変わってくる。レビューの観点をコマンドに統一しておけば、人によってバラつきが出にくい。そのあたりはまだ試せていない。
skillsってどう便利?
一番の便利さは毎回同じ長い指示を書かなくていい点だ。
例えばコードレビューを頼むとき、毎回こんな指示を書いていたとする。
セキュリティの観点でレビューして。
パフォーマンスの問題があれば指摘して。
このプロジェクトはLaravel 12なので...
これを /review 一発で済ませられるのが skills だ。
特に便利なのはこんなケース。
- チームで統一したい作業:
/reviewの内容をチームで合わせておけば、レビューの観点がバラけない - プロジェクト固有の手順:デプロイ前チェックリストなど、毎回同じことをやる作業
- 長いコンテキストが必要な指示:「このプロジェクトの制約を踏まえて〜」という前置きをコマンドに埋め込んでおける
「これ毎回書いてるな」という指示が出てきたらコマンド化するのがいいかもしれない。
関連した投稿
Tags
PICKUP
YEAR
MUSIC