Claude Codeを使うなら最初にCLAUDE.mdを作ろう。開発効率が上がった私の運用方法

最近はClaude Codeを使って開発する機会が増えました。

AIにコードを書いてもらうことで開発スピードは確実に上がります。

ただ、使ってみて感じたのは「AIに全部任せればいい」というものではなく、最初のルール作りがとても重要だということです。

私は新しいプロジェクトを作るたびに、最初にCLAUDE.mdを作成しています。

今回は、実際に私が意識していることをまとめてみます。

---

CLAUDE.mdとは？

簡単に言うと、Claude Codeへ渡す「プロジェクトの仕様書」です。

プロジェクトの目的やルールを書いておくことで、AIが前提を理解した状態で開発を進めてくれるようになります。

人に開発をお願いするときに仕様書を書くように、AIにも最初にルールを伝えるイメージです。

例えば、新しくWebサービスを開発する場合は、このような内容から始めています。

# プロジェクト概要

AIを活用したWebサービス

ユーザーの入力内容をもとに情報を整理・提案するWebアプリケーション。

---

# 技術スタック

- Next.js
- TypeScript
- Tailwind CSS
- Supabase
- Claude API

このくらいシンプルに書くだけでも、Claude Codeの回答精度はかなり変わると感じています。

---

実装前に必ず計画を出してもらう

個人的に一番重要だと思っているルールです。

3ステップ以上の実装になりそうな場合は、いきなりコードを書いてもらうのではなく、まず実装計画を提示してもらいます。

計画を確認して問題なければ、そのまま実装をお願いする流れにしています。

これだけでも、「思っていたものと違う」ということがかなり減りました。

---

バイブコーディングはしない

最近は「バイブコーディング」という言葉もよく聞きます。

AIが生成したコードを、そのまま動けばOKという使い方はしていません。

便利なツールだからこそ、最終的な責任を持つのは開発者です。

AIは開発をサポートしてくれる存在ですが、設計や品質の判断まで丸投げすることはしないようにしています。

---

自分でも必ずレビューする

Claude Codeはとても優秀ですが、100%正しいとは限りません。

そのため、生成されたコードは必ずレビューしています。

• なぜこの実装になっているのか
• もっとシンプルに書けないか
• 保守しやすいコードになっているか

このあたりを確認してから採用するようにしています。

---

理解できないコードは採用しない

AIは時々、とても高度な実装を提案してきます。

でも、

「動くけど意味が分からない」

そんなコードは採用しません。

分からない部分はClaude Codeに質問したり、自分で調べたりして理解してから採用します。

半年後、1年後に保守するのは自分なので、「動くコード」より「理解できるコード」を大切にしています。

---

実装後は必ず検証する

実装が終わったら、そのまま完了にはしません。

少なくとも、

• TypeScriptエラー
• ESLint
• テスト（ある場合）

は実行してもらうようにしています。

AIも人間と同じでミスをすることがあります。

最後の確認は欠かせません。

---

コードスタイルは書かない

最初は、

• シングルクォートを使う
• インデントは2スペース

などもCLAUDE.mdに書こうと思っていました。

でも、それらはESLintやPrettierが管理してくれます。

CLAUDE.mdには、プロジェクト独自のルールだけを書くようにしています。

---

禁止事項よりも「行動」を書く

最近知って納得したことの一つです。

例えば、

schema.prismaを編集しない

よりも、

schema.prismaを変更する必要がある場合は、必ず確認してください。

というように、「〇〇したい時は△△してください」と書いた方が、AIはルールを守ってくれる印象があります。

禁止事項だけを書くよりも、具体的な行動を書いた方が効果的でした。

---

CLAUDE.mdは長くしすぎない

ルールはたくさん書けば良いというわけではありません。

長くなりすぎると、重要なルールが埋もれてしまうこともあります。

目安としては150〜200行、多くても300行以内に収めるのが良いと言われています。

細かいルールは別ファイルへ分け、本当に重要な内容だけを書くようにしています。

---

ルールは分割する

最近は、CLAUDE.mdにすべてを書くのではなく、ルールを分割する方法も取り入れようと思っています。

例えば、

.claude/
└── rules/
    ├── common.md
    ├── nextjs.md
    ├── react.md
    ├── supabase.md
    └── testing.md

共通ルールはcommon.md、Next.js固有のルールはnextjs.mdというように分けておくと、管理もしやすそうです。

まだ試行錯誤中ですが、今後はこちらの運用も試してみようと思っています。

---

CLAUDE.mdはプロジェクトと一緒に育てていく

最初は「完璧なCLAUDE.mdを作ろう」と考えていました。

でも、いろいろ調べたり実際に使ってみたりすると、そうではないことが分かりました。

CLAUDE.mdは最初から完璧に作るものではなく、プロジェクトと一緒に育てていくものなんだと思っています。

例えば、

• Claude Codeが同じミスを繰り返した
• 毎回同じ指示を出している
• 「これ毎回言ってるな」と感じた

そんなタイミングで、その内容を1行ずつ追記しています。

逆に最初からルールを詰め込みすぎると、本当に重要なルールが埋もれてしまいます。

なので私は、

「AIが同じミスをしたら、そのミスを防ぐルールを1行追加する」

という運用が、一番現実的なんじゃないかなと感じています。

---

まとめ

Claude Codeを使い始めて感じたのは、「AIの性能」よりも「最初にどんなルールを渡すか」の方が重要だということです。

私が今意識していることは、

• プロジェクトごとにCLAUDE.mdを作成する
• 実装前に必ず計画を提示してもらう
• バイブコーディングはしない
• AIが書いたコードも必ずレビューする
• 理解できないコードは採用しない
• 実装後は必ず検証する
• コードスタイルはESLintやPrettierに任せる
• 禁止事項よりも具体的な行動を書く
• CLAUDE.mdは長くしすぎない
• 共通ルールと技術別ルールを分割する
• ミスが起きたらCLAUDE.mdを少しずつ育てていく

AIの進化は本当に速いので、半年後には今とは違う運用になっているかもしれません。

この記事も、自分の運用方法が変われば、その都度アップデートしていこうと思っています。

もし「こんなルールを入れているよ」というものがあれば、ぜひ教えてください。