タグ: CLAUDE.md

  • auto-memory ー 私の口癖、勝手に覚えていてくれた

    auto-memory ー 私の口癖、勝手に覚えていてくれた


    気づいたら使ってた

    同じ説明を3回した。「Windows 使ってます」「PowerShell で動かしたいです」「日本語でお願いします」。テンプレ自己紹介、もはや営業の名刺交換みたいでした。4回目の朝、私がまだ何も言ってないのに、Claude が PowerShell コマンドを並べて出してきた。何これ、誰が教えた。下手な探偵より私のことを知っている。トースターが昨日のこんがり度を覚えていたような、ちょっと嬉しいけれど不気味さもある朝でした。


    結論マップ(ビフォー/アフター)

    並べてみると、昨日までの自分がちょっと気の毒です。

    項目auto-memory なし(私の昨日まで)auto-memory あり(私の今)
    自分のプロフィール会話の冒頭で毎回口頭で説明1回言えば次回から覚えている
    プロジェクトのクセ毎回 CLAUDE.md に追記Claude が適宜 markdown に保存
    「前にこう言ったよね」履歴を遡って自分で探すClaude が勝手に持ち出してくる

    要するに何ができるか

    auto-memory(オートメモリー)は、Claude がセッションをまたいで「あなたとの会話で得た学び」を自分で markdown ファイルに書き残してくれる機能です。専門用語に翻訳すると「セッション間でユーザー固有情報を永続化する仕組み」、人間の言葉に翻訳すると「私の口癖と好みを Claude が勝手にメモる」。後者のほうが10倍わかりやすい、と書きながら思いました。Claude Code v2.1.59 以降は最初から ON で、プロジェクトごとに ~/.claude/projects/<project>/memory/ 以下に保存されます。中身はぜんぶ markdown なので、私が直接読めるし、編集も削除もできる。「AIに記憶される」と聞いたとき頭に浮かんだ、何かこう、暗号化された謎ファイルみたいなものは一切なし。拍子抜けするくらい開けっぴろげです。

    💡 「全部 markdown」というのが地味に効く。AI が裏でこっそり何か覚えているのではなく、フォルダを開けば全部見えるところに置いてある。怖さの正体は「見えないこと」だったんだなと、覗いてみて気づきました。


    とりあえずやってみる

    1. ターミナルで claude --version を実行し、バージョンが v2.1.59 以上 か確認する(古ければ npm install -g @anthropic-ai/claude-code で更新。私はここで更新を3日先延ばしにした人間です)
    2. Claude のセッション内で /memory と打つ
    3. 表示されるメニューで「Auto memory」が ON になっていることを確認する(デフォルト ON。ここでオフにしたら振り出しに戻ります。人生ゲームみたいですね)
    4. あとは普通に会話する。私の好み・作業習慣・つまずきパターンを Claude が「これは次回も役立ちそう」と判断したときだけ自動で保存する。判断は Claude 任せです。「これも覚えて!」と叫んでも基本スルー(経験談)
    5. 数日経ったらもう一度 /memory を開いて、Auto memory フォルダの中身を覗く。ここで自分の口癖と再会します

    こう書いたら動いた

    ある朝、何気なく ~/.claude/projects/my-recipe-app/memory/ を覗いたら、こんなファイルが転がっていました。私は頼んでいない。Claude が勝手に書いていた。プライバシーの侵害だと思ったけど、内容を見たら正論しか書かれていなかったので何も言えなくなりました。

    ---
    name: User PowerShell preference
    description: ユーザーは Windows + PowerShell ユーザー
    type: feedback
    ---
    ユーザーは PowerShell をメインシェルとして使用している。
    bash や zsh の構文を提示するたびに「PowerShell で書き直して」と依頼されるため、
    ターミナルコマンドは最初から PowerShell 構文で提示すること。
    例:
    - NG: `ls -la`
    - OK: `Get-ChildItem -Force`

    💡 私の3回分の小言が、フィードバック型のメモにきれいにまとまっていた。鳥肌が立ったというより、上司にこっそり手帳を覗かれた気分でした。でもこの上司、メモを取っておいてくれるおかげで明日の私の朝食の手間が減る。許す。


    私が間違えたこと

    • 「これ覚えて」と言えば全部覚える、ではない: Claude が「次回も使えそう」と判断したものだけが保存されます。完璧な秘書ではなく、ややマイペースなメモ魔の同僚に近い。覚えてほしいなら明示的に「これメモしておいて」と頼むほうが確実です。私は「絶対忘れないで!」と3回叫んで、3回ともスルーされました
    • 記憶は勝手に消えない: markdown ファイルはユーザーが消すまで残ります。半年前の古い情報を Claude が信じて間違ったコマンドを出してくることもあるので、月に1回はフォルダを覗いて掃除する。冷蔵庫の奥のタッパーと同じです
    • CLAUDE.md と auto-memory を混同しない: CLAUDE.md は私が手で書く「ルール」、auto-memory は Claude が自動で書く「学び」。書き換える場所を間違えると、せっかくのメモを上書きしてしまう。役割分担、ここ大事です(試験に出ます)

    使ってみての正直な感想

    同じ説明を3回繰り返している自分に気づいたら、auto-memory が動いているか覗いてみる価値があります。私はもう「Windows です、PowerShell です、日本語で」のテンプレ自己紹介を毎朝しなくて済むようになりました。ボルヘスの「フネス」みたいに何でも覚えていたら逆に動けなくなりそうですが、Claude の auto-memory は「忘れる」ほうも上手です——本当に必要なものだけ拾ってくれる。怖いと思っていた「AIに記憶される」も、フォルダを開けば全部 markdown で見えるとわかった瞬間、急に気が楽になりました。秘密にされるより、見えるところに置いてくれるほうがずっと信用できる。下手な探偵に追われる気分から、有能な秘書を雇った気分に、3週間で進化した話でした。


    関連リンク

  • Hooks ー Claudeの動きの「前後」に、自分の指示を差し込む

    Hooks ー Claudeの動きの「前後」に、自分の指示を差し込む

    ずっと「お願い」していた

    毎回 CLAUDE.md に「ファイルを編集したら必ず prettier をかけて」と書いていた。Claude は気が向くとやってくれるし、気が向かないと忘れる。私と犬のしつけが同じ進捗を辿っているのを見て、これは依頼ではなく自動化の話だと気づいた。

    そこで出会ったのが Hooks(フック)だった。「Claude が動いた瞬間に、私の用意したスクリプトを横から差し込める」という、要するに 「お願い」を「実行」に格上げする仕組みである。


    結論マップ(ビフォー/アフター)

    場面Hooks を知る前Hooks を入れたあと
    編集後の整形毎回「prettier かけて」と頼むファイル編集 → 自動で prettier が走る
    危ないコマンドrm -rf を打つ前に祈る設定で問答無用ブロックされる
    終わったら通知画面を見続けて待つ終了の瞬間にデスクトップ通知が出る

    3行で済んだ。Claude にいちいちお願いするより、Claude の周りに自動ドアを設置するほうが結局は早い、というだけの話だった。


    Hooks って何

    公式ドキュメントによれば、Hooks は Claude Code のライフサイクルの特定タイミングで自動的に走る、ユーザー定義のシェルコマンド・HTTP エンドポイント・LLM プロンプト のこと。日本語で言えば「Claude の動作の前後に、自分の処理を割り込ませる栓抜き」だ。

    たとえばツール(Bash や Edit)を使う直前に走らせれば、危険なコマンドを止められる。直後に走らせれば、編集したファイルを自動で整形できる。会話が始まるとき、終わるとき、ユーザーがプロンプトを送ったとき、それぞれにフックポイントがある。

    💡 似た言葉だが、いわゆる「Webhook(外部から呼ばれる仕組み)」ではない。Hooks は自分のマシンの中で動くしかけ。つまり LINE スタンプを送るのではなく、自分の家の玄関に自動センサーライトを付ける、くらいのスケール感。


    どこに書くのか

    設定ファイルは置き場所で 適用範囲(スコープ) が変わる。これは公式ドキュメントの記載どおり:

    置き場所適用範囲共有
    ~/.claude/settings.json自分の全プロジェクト自分のマシン内のみ
    .claude/settings.jsonそのプロジェクトのみgit にコミット可
    .claude/settings.local.jsonそのプロジェクトのみgitignored

    このほか、プラグインに同梱したり、スキルやサブエージェントの frontmatter(YAML のメタ情報部分)に書く方法もある。「自分専用なら ~/.claude/、チームで共有するなら .claude/settings.json」と覚えると整理しやすい。


    どんなイベントにフックできるのか

    公式リファレンスに載っているイベントはかなり多いが、初心者がまず触りそうなのは以下:

    • SessionStart / SessionEnd — セッションの開始・終了
    • UserPromptSubmit — 私が Enter を押した直後、Claude が読む前
    • PreToolUse / PostToolUse — Claude がツール(Bash, Edit, Write, etc.)を呼ぶ直前・直後
    • PostToolUseFailure — ツールが失敗したあと
    • Stop — Claude が応答を終えた瞬間
    • Notification — Claude が通知を出すとき(権限確認など)
    • PreCompact / PostCompact — 会話圧縮の前後
    • FileChanged / CwdChanged — 監視対象ファイルが変わった/作業ディレクトリが変わった

    このほかにも SubagentStart・InstructionsLoaded・WorktreeCreate など細かいものが並んでいて、要は 「Claude が何かする」ほぼ全タイミングに切れ目が用意されている。映画の隙にどこでも CM が入れられる、と思うと近い。


    実例1:ファイル編集後に自動 prettier

    公式ガイドにそのまま載っている、いちばん腑に落ちる例。.claude/settings.json に書く:

    {
    "hooks": {
    "PostToolUse": [
    {
    "matcher": "Edit|Write",
    "hooks": [
    {
    "type": "command",
    "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write"
    }
    ]
    }
    ]
    }
    }

    matcher で「Edit か Write のとき」と絞り込み、Claude が編集したファイルパスを jq(JSON を取り出すコマンド)で抜き出して prettier に渡す。「お願い」の文言を CLAUDE.md に何行書くより、これ1つ置くほうが効く。これは私の犬の食事よりも確実に動く。

    💡 公式が jq を前提にしているので、Mac なら brew install jq、Ubuntu なら apt-get install jq を先に入れておく。私はここで30分溶かした(jq が入っていないと、フックは静かに失敗する)。


    実例2:危ないコマンドを問答無用で止める

    PreToolUse に「Bash で rm 系のコマンドが来たら止める」スクリプトを差し込む。.claude/hooks/protect-files.sh を作って中身は公式の例から拝借(exit 2 でブロックする):

    #!/bin/bash
    INPUT=$(cat)
    COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command')
    if echo "$COMMAND" | grep -qE 'rm -rf'; then
    echo "Blocked: rm -rf は禁止です" >&2
    exit 2
    fi
    exit 0

    実行権限を付けて(chmod +x .claude/hooks/protect-files.sh)、.claude/settings.json に登録:

    {
    "hooks": {
    "PreToolUse": [
    {
    "matcher": "Bash",
    "hooks": [
    {
    "type": "command",
    "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/protect-files.sh"
    }
    ]
    }
    ]
    }
    }

    ポイントは exit 2。終了コード 2 は「ブロッキングエラー」と決まっていて、これを返すとツール呼び出し自体が止まり、stderr の文字列が Claude にエラーとして渡る(公式ドキュメント「Exit code output」セクション)。Claude には「あ、それはダメだったのね」と伝わるので、別の手を考えてくれる。父親の「ダメ」と母親の「いいよ」が衝突したとき、強いほうが通るアレ、と説明したい。


    実例3:Claude が止まった瞬間に通知

    長いタスクを投げて待っている間、私は別の作業をしている。気がついたら Claude は10分前に終わっていた、というのを何度かやらかしたので、Stop イベント(Claude が応答を終えた瞬間)にデスクトップ通知を出す:

    {
    "hooks": {
    "Stop": [
    {
    "matcher": "",
    "hooks": [
    {
    "type": "command",
    "command": "osascript -e 'display notification \"Claude が応答を終えました\" with title \"Claude Code\"'"
    }
    ]
    }
    ]
    }
    }

    これは Mac の例(osascript を使う)。Linux なら notify-send、Windows なら powershell.exe 経由でメッセージボックスを出す例が公式ガイドに載っている。要は 「終わり」の瞬間を取れるということ。私のスマホがピンと鳴るたび、Claude のタスクが終わっていて、Pavlov の犬のようになる未来が見えた。


    ここで止まりそうなポイント

    • 設定の置き場所を間違える:~/.claude/settings.json(自分の全体)と .claude/settings.json(プロジェクト用)は別物。間違えるとフックが動かない or 全プロジェクトで暴走する。私は「家の鍵と会社の鍵を同じキーホルダーに付けたまま、うっかり会社の鍵で家を開けようとした」レベルで混乱した
    • exit 2 以外はブロックしない:終了コード 1 は「ノンブロッキングエラー」。Unix の慣習で 1 を返したくなるが、フックを「拒否」として使いたいなら必ず 2 にする。これは公式ドキュメントの「Exit code output」セクションに明記されている
    • /hooks で確認できる:今どんなフックが効いているのか分からなくなったら、Claude Code 内で /hooks と打つと、設定済みのフックが一覧で読める。私はこれで「設定したつもりで動いていなかった」ことに気づいた

    セキュリティの話(ここは飛ばさず読んでほしい)

    公式ドキュメントの「Security considerations」に明記されているとおり、Hooks は私のユーザー権限で任意のシェルコマンドを実行する。つまり、信頼できないフック設定をうっかり共有リポジトリから取り込むと、ファイルを消されたり、認証情報を盗まれたりする可能性がある。

    ⚠️ 要するに、人がくれた .claude/settings.json の中身は、見知らぬ人がくれた USB を挿す前と同じ気持ちで一度開いて読む。コマンドが読める範囲かどうか確認してから取り込むこと。便利な道具ほど、初対面の相手から黙って受け取ってはいけない。

    公式が挙げているベストプラクティスは「入力を信用せず検証する」「シェル変数は必ずクォートする("$VAR")」「絶対パスを使う」「.env や .git/ には触らない」など。家の鍵を二重ロックするのと同じ感覚で、フックも二重に守る。


    全部止めたいとき

    設定を1個ずつ消す前に、disableAllHooks: true を settings.json に書けば、その階層のフックを丸ごと黙らせられる(公式リファレンス「Disable or remove hooks」セクション)。トラブルシュート時にまずこれで切り分けると早い。ブレーカーを落としてから配線を見る、あの感じ。


    まとめ/次に試したいこと

    Hooks は 「Claude が動く瞬間の前後に、自分の処理を差し込める仕組み」。お願い文を増やすより、設定1つで自動化したほうが早い場面が確実にある。

    • PostToolUse + Edit|Write … 編集後の自動フォーマット
    • PreToolUse + Bash … 危険コマンドのブロック
    • Stop … 終了通知
    • SessionStart + compact … 圧縮後にプロジェクトの大事なルールを再注入

    私が次に試したいのは、コミット前に自動でテストを走らせる PostToolUse と、ログを残す SessionEnd の組み合わせ。気がつけばリポジトリの周りに自動ドアと監視カメラと宅配ロッカーが揃っていて、私は寝ていても進捗が出る家になっているはず(は、言いすぎた)。

    なお、本記事の設定例・コマンド・イベント名は2026-04-27 時点の公式ドキュメントに基づく。Claude Code の更新頻度は高いので、実際に組む前に必ず一次情報を確認してほしい。


    関連リンク(一次情報)

  • /init ー CLAUDE.md、3日かけて手書きしてた私の話

    /init ー CLAUDE.md、3日かけて手書きしてた私の話

    ずっと、白紙から書いてた

    CLAUDE.md(Claude が会話のたびに最初に読むメモ書きのようなファイル)を、私は3日かけて手書きしていた。プロジェクトの構成を眺め、命名規則を書き写し、テストの動かし方を思い出して並べて、最後に誤字を直して、また並べ替えた。エジプトのピラミッドを建てたファラオたちもこんな気持ちだったのかもしれない(まあ彼らの時代に重機などないのだが)。

    そして昨日、/init というスラッシュコマンドの存在を知った。

    「Claude が勝手にプロジェクトを読んで CLAUDE.md の下書きを作ってくれる」と公式ドキュメントには書いてある。3日。私の3日。返してほしい。


    結論マップ(ビフォー/アフター)

    場面/init を知る前/init を打ったあと
    CLAUDE.md の作り方手で1から書く(私は3日溶かした)1コマンドで下書きが出てくる
    プロジェクト把握自分でフォルダを眺めて思い出すClaude がスキャンして要点を抜く
    仕上げ「これ書き忘れてた…」を3日後に発見出てきた下書きを「足す・削る」だけ

    ピラミッドが3秒で建った気分。ただし完成形ではなく下書きである、という1点だけ最後に詳しく書く。


    /init って何をするコマンド

    公式ドキュメントによれば、/init は Claude Code の対話モード(ターミナルで claude と打って起動した状態)の中で打つスラッシュコマンド で、いま開いているプロジェクトを Claude が自分で歩き回って CLAUDE.md の下書きを生成してくれる機能だ。

    具体的には Claude が以下を自分で見に行く:

    • フォルダ構成(どこに何があるか)
    • package.json / pyproject.toml などの設定ファイル(使っているフレームワーク・依存ライブラリ)
    • 既存のドキュメント(README など)
    • ソースコードの命名規則・スタイル

    これらを材料に、「ビルド方法」「テスト方法」「主要ディレクトリの説明」「コーディング規約」などを箇条書きにした CLAUDE.md の下書き を1つ書き出してくれる。

    💡 「Claude が読みやすいように、Claude が自分の取扱説明書を自分で書く」と説明すると近い。私は最初これを聞いて「自分で履歴書書く AI、強い」と思った。


    実際に打つ手順(最小5ステップ)

    1. ターミナルで対象プロジェクトのフォルダに移動する(cd my-project のような移動コマンドを使う)
    2. claude と打って Claude Code を起動する
    3. 起動後のプロンプトに /init と入力して Enter
    4. Claude がプロジェクトを読んで下書きを生成する(数秒〜数十秒)
    5. 生成された CLAUDE.md を自分の目で読み、足りない部分・誤った部分を編集する

    ポイントは 5番。/init はあくまで下書きを置いてくれるだけで、完成版を作ってくれるわけではない。Claude 公式の解説記事にも「think of /init as a starting point, not a finished product(出発点であって完成品ではない)」とはっきり書かれている(公式 Best Practices にも同主旨の記述がある)。


    生成される CLAUDE.md のイメージ

    たとえば、私が書いている架空の家計簿アプリ(仮に kakebo-app という名前のNode.jsプロジェクト)で /init を打つと、こんな雰囲気の下書きが出てくる:

    # kakebo-app
    A personal finance tracker built with Node.js and Express.
    ## Build & Run
    - Install: `npm install`
    - Dev server: `npm run dev`
    - Production build: `npm run build`
    ## Test
    - Unit tests: `npm test`
    - E2E tests: `npm run test:e2e`
    ## Project Structure
    - `src/routes/`  ... API endpoints
    - `src/models/`  ... Database models (using Prisma)
    - `src/views/`   ... EJS templates
    - `tests/`       ... Jest test suites
    ## Conventions
    - Indent: 2 spaces
    - Quotes: single quotes for JS, double for JSON
    - File naming: kebab-case
    

    「あ、これでいい」と思うところと「いや、ここは違う」と思うところが混じった下書きになる。たとえば私の場合、Conventions 欄に「絶対 commit 前に lint を回す」を足したり、「src/views/ は EJS じゃなくて Pug を使ってる」を直したりする。プロの料理人がレシピ本のレシピを試食して「醤油を足したい」と言うのと同じ手つき。

    💡 上の例は架空のプロジェクトのもの。あなたのプロジェクトでは中身がぜんぜん違う形で出てくる。それで正しい。


    新しい /init(対話モード)も来ている

    公式ブログと Best Practices によると、2026年3月から 対話型の新しい /init が試験的に提供されている。CLAUDE_CODE_NEW_INIT=1 という環境変数(プログラムに渡す設定値のこと)を立てて Claude を起動すると、こちらに切り替わる。

    CLAUDE_CODE_NEW_INIT=1 claude
    

    何が違うか。従来版はファイルを勝手に読んで下書きを書く(ボトムアップ:素材から作る)。新版はファイルを読まず、AskUserQuestion(Claude が選択肢付きで質問してくる仕組み・以前の記事で取り上げた)を使って私に質問しながら作っていく(トップダウン:意図から作る)。

    💡 「私の作業のうち、よく繰り返している作業は?」「危ないからフックで止めたい操作は?」のような質問に答えていくと、CLAUDE.md だけでなくスキルや Hooks の雛形まで一緒に整えてくれる、というしくみ。インタビュー上手なフリーランスのコンサルが、私の机を見ずに私の話だけで業務マニュアルを書いてくれる、と思うと近い。

    なお新版はまだフラグ付きの実験的機能なので、通常の /init だけ覚えれば、明日からの作業は十分カバーできる。


    ここで止まりそうなポイント

    • 対話モードで打つ:/init はターミナルから claude --init のような呼び方では打てない。claude を起動して対話画面に入ってから、その中で /init と打つ。私は最初これを「シェルコマンド」と勘違いし、シェルに直接打って怒られた(家のリモコンを冷蔵庫に向けて押していた)
    • 既存の CLAUDE.md は上書きされる可能性:すでに CLAUDE.md がある状態で /init をもう一度回すと、内容が書き換わるか・差分が提示される(Claude のバージョンで挙動が変わる)。実行前に既存ファイルをバックアップすることをおすすめする。私は「これ、賢く merge してくれるはず…」と祈ったが、祈りで Git の履歴は残らない
    • 生成内容を信じすぎない:/init はファイルを「見た」結果で書くので、まだコードに書かれていないルール(たとえば「PR は必ず2人レビューする」のような運用ルール)は当然書かれない。出てきた下書きをスタート地点に、自分の頭で足す工程は必ず必要

    まとめ

    /init は CLAUDE.md の下書きを Claude 自身に書かせるスラッシュコマンド。手で1から書くより圧倒的に早く、しかも基本骨格は埋まった状態で出てくる。

    • まずは claude を起動 →/init を1回打つ
    • 出てきた下書きを読み、削り、足す(ここが本番)
    • 余裕が出てきたら CLAUDE_CODE_NEW_INIT=1 の対話版も試す

    私が次にやりたいのは、すでに育っている既存プロジェクトに /init をぶつけて、私が3日かけて書いた CLAUDE.md と Claude が30秒で書いた CLAUDE.md を並べて比較すること。たぶん私が負ける。負けても勉強になる、という意味で負けても勝ちという不思議な構図。

    なお本記事の挙動・コマンド名は 2026-04-28 時点の公式ドキュメントに基づく。Claude Code は更新が早いので、実行前に必ず一次情報を確認してほしい。


    関連リンク(一次情報)


  • CLAUDE.md ー 毎回同じ口頭説明、ついに卒業した

    CLAUDE.md ー 毎回同じ口頭説明、ついに卒業した

    あれ、これだったのか

    「口調はやわらかめで」「コードは書かないで」「日本語で返事して」。
    私はこの3行を、3日連続でClaudeに口頭でお願いしていた。
    3日目に思い出した。「これ、ファイルに書いておけるやつなんじゃ?」

    そのファイルが CLAUDE.md だった。


    結論マップ(ビフォー/アフター)

    改善前(Before)改善後(After)
    毎回チャットの冒頭に「日本語で・優しく・コードは省いて」と打ち込むプロジェクトを開いた瞬間、Claudeが既にそのルールで動いている
    Claudeが急に英語で返事してきて「あれ?」となる口調も言語もブレない。プロジェクト全体で一貫する
    「言ったよね?」と何度もリマインドする手間1回書いて保存。そのあとは存在を忘れていい

    これが本体

    CLAUDE.md(クロード・ドット・エムディー)は、Claudeに毎回読ませたい指示を書いておくテキストファイルだ。
    拡張子の .md は「マークダウン」。名前だけ強そうだが、要は見出しが書けるだけのただのメモ。メモ帳でもVS Codeでも開ける。身構えなくていい。

    公式ドキュメントの言い方を借りるなら、毎セッション開始時に自動で読まれる、Claude宛の置き手紙。
    枕草子なら「春はあけぼの」のあたりに「敬語多め」って書いておくイメージだ(清少納言、ごめん)。
    口頭で毎回お願いしていたことをファイルに書き写すだけで、Claudeはそれを前提にして話し始めてくれる。

    しかも置き場所が用途で使い分けられる。

    • ~/.claude/CLAUDE.md … 全プロジェクト共通の自分ルール(要は私の取扱説明書)。口調・言語・禁止事項などをここに書く
    • プロジェクト直下の CLAUDE.md … そのプロジェクトだけのルール(このフォルダ独自の方言)。チームで共有もできる
    • @path/to/file 構文での import … 別ファイルを CLAUDE.md から読み込む書き方。長くなりがちなルールを別ファイルに分割できる(昔は CLAUDE.local.md というローカル専用ファイルもあったが、現在は import 構文が推奨されている)

    これらは作業フォルダから上の階層に向かって順に読み込まれて、まとめてClaudeに渡される。「全体ルール+プロジェクト固有ルール」をきれいに分けて書ける。


    とりあえずやってみる

    迷いどころを全部スキップした最小手順がこれ。

    1. プロジェクトの一番上のフォルダ(自分が作業しているフォルダ)を開く
    2. その中に CLAUDE.md という名前の空ファイルを作る(メモ帳で「名前を付けて保存」でOK)
    3. 「Claudeに毎回伝えていたこと」を3〜5行書く(ここで完璧主義が顔を出すが無視。ファイル名すら最初に間違えた私が言うんだから間違いない)
    4. 保存して、Claude Codeを開き直す(または新しいセッションを始める)
    5. Claudeに「今回のルールわかってる?」と聞いて、書いた内容を返してくれたら成功

    ポイントは 「毎回伝えてた1行」を1つだけでいい こと。完璧を目指して長文を書こうとすると、たいてい書き終わる前に挫折する。私は最初の1行を書くだけで5分粘った。原稿用紙を前にした夏休み最終日の小学生だった。


    動いた設定をそのまま

    私が試しに作った、架空の「旅レシピ管理」プロジェクト用の CLAUDE.md がこれ。中身は本物のテキストとしてそのまま動く。

    # 旅レシピ管理プロジェクト
    このフォルダは、旅行先で食べた料理を再現するためのレシピメモ集です。
    ## 私の好み
    - 返答は日本語で。専門用語が出たら必ず1行で意味を補足してください
    - 文字数は1メモあたり300字以内におさめる
    - 材料の分量は2人分を基準にする
    ## ファイルの場所
    - 完成したレシピは `recipes/` フォルダに `国名_料理名.md` で保存
    - 試作中のメモは `drafts/` フォルダに置く(公開前なので触らないで)
    ## やらないでほしいこと
    - レシピの手順を勝手に省略しないでください
    - 「お好みで」など曖昧な表現は使わず、数値で書いてください
    

    💡 ポイント: 見出し(##)で「好み」「ファイルの場所」「やらないでほしいこと」を分けると、Claudeが「該当箇所だけ」を意識して動いてくれる。長く書くより、見出しでの分類のほうが効く。


    最初で詰まった4つ

    1. 置き場所を間違えた … デスクトップに置いて「読まれない!」と騒いでいた。CLAUDE.md は 作業しているプロジェクトフォルダの直下 に置かないと反応しない。場所を変えただけで治った。
    2. 長すぎて自分が読めなくなった … 良いことを書こうとして30行を超え、自分でも何を書いたか覚えてなかった。ファイル全体が毎セッションで読まれる仕組みなので、長くなりすぎたら別ファイルに分割するのが安全。公式の Best Practices にも「短く・人間が読める長さに保つ」と書かれている。
    3. 「禁止事項」だけ並べた … 「〜しないで」ばかりだと、Claudeはやってもいいことの判断に迷う。「これはやって・これはやらないで」をペアで書く と動きが安定する。「コードを書かないで」より「コードは書かず、手順だけ箇条書きにしてください」のほうが伝わる。
    4. ファイル名に小文字が混入 … 最初は Claude.md という名前で作ってしまい、「読まれない、なぜ?」と30分溶かした。正しくは すべて大文字の CLAUDE.md(拡張子の .md だけ小文字)。Mac・Linux など大文字小文字を区別する環境では、一文字でもケースが違うと完全に別ファイル扱いで無視される。リネームしただけで動いた。

    使ってみての正直な感想

    CLAUDE.md を作る前と後で、Claudeとの会話の冒頭5分が完全に消えた。
    「いつもの前提を伝える時間」が0になっただけで、いきなり本題に入れる。

    書くのに迷ったら、「直近3回、Claudeに同じ注意をしたこと」をそのまま書き写す のがいちばん早い。
    それは「私が毎回伝えたいルール」の動かぬ証拠だから。

    3回同じことを言ったら、ファイルに書く。3歳児に同じ質問をされ続けた育児ベテランの先輩が言ってたやつだ。
    Claudeも、3歳児だったらしい。


    関連リンク