実践 レッスン 2 / 7

CLAUDE.md

ほとんどの人は CLAUDE.md を完全に無視するか、 ゴミで埋め尽くすかのどちらかです。 この一つのファイルが、Claude とコードベースのすべてのインタラクションを形作ります。

「悪い CLAUDE.md は新入社員向けのドキュメントのよう。
良い CLAUDE.md は明日記憶喪失になると分かっている自分へのメモのよう。」

CLAUDE.md とは？

CLAUDE.md は毎セッションで Claude が最初に読むものです。 自動的なオンボーディング資料—会話をまたいで持続するコンテキストです。 Markdown で書きましょう。Claude はそれをうまく処理します。

ルール

  • 短く保つ：最大約150〜200行。システムプロンプトは既に約50トークン使用。ここの各行は全メッセージでコンテキストを消費します。
  • あなたのプロジェクト固有に：「components」フォルダが何かを説明しないで。Claude は知っています。あなたのプロジェクトの何がユニークかを伝えて。
  • WHY を伝える：「型変換によるバグが本番で起きたから strict モードを使う」は「strict モードを使う」より良い。
  • 常に更新する：#を押して即座に指示を追加。良い CLAUDE.md は進化します。

良い例 vs 悪い例

悪い

このプロジェクトはフロントエンドに React を使用。コンポーネントは components フォルダに。TypeScript を使用。API は api フォルダに。

良い

レガシー API は snake_case（変更禁止）。新エンドポイントは camelCase。認証トークンは1時間で期限切れ—API呼び出し前に期限確認。TypeScript で any 禁止。

悪い例は Claude がコードを読めば分かることを伝えています。 良い例は Claude が推測できないことを伝えています—規約、落とし穴、 シニアエンジニアに聞かなければ分からないコンテキスト。

何を含めるか

  • デフォルトと異なるプロジェクト固有の規約
  • 既知の落とし穴とその理由
  • 一般的なパターンの例がある場所
  • やってはいけないこと（とその理由）
  • テスト要件と実行方法

こう考えてください：「明日記憶喪失になって、このファイルだけが ガイドだったら、何かを壊さないために何を知る必要があるか？」

重要なポイント

  • CLAUDE.md は全メッセージで読まれる—簡潔に
  • Claude に明らかなことではなく、ユニークなことを伝える
  • WHAT だけでなく WHY を含める
  • 新しい落とし穴を発見したら常に更新