ノンエンジニアのClaude Code奮闘記 #6 CLAUDE.mdを育てる——AIへの「自分専用の取扱説明書」のつくり方
-
Etsuko Mera - 05 Jun, 2026
はじめに
こんにちは、広報・制作担当のmeraです。
#3 ダウンロードフォルダ整理編で初めて CLAUDE.md を作りました。
あの頃のCLAUDE.mdは、こんなものでした。
# ルール
- secrets/ は触らない
- .env ファイルは触らない2行。以上。
それから約1ヶ月。
今の私のブログフォルダにある CLAUDE.md は、スクロールしないと読めない長さになっています。
「育っている」という感覚がいちばんしっくりきます。 失敗するたびにルールを追加して、うまくいったやり方を書き留めて、「自分専用のAI取扱説明書」みたいなものができていきました。
この記事は、その育て方の記録です。
この記事で学べること
- CLAUDE.mdが「なぜ必要か」の感覚的な理解
- 最初の1行から始める書き方
- 「失敗→追記」で育てていくサイクル
- 私が今使っているブログ用CLAUDE.mdの実例
- フォルダごとにCLAUDE.mdを使い分ける方法
そもそも CLAUDE.md って何をするもの?
CLAUDE.mdは、そのフォルダでClaude Codeを使うときの「事前ルール」を書いておくファイルです。
人間で言うと、「引き継ぎ資料」や「業務マニュアル」に近い。 Claude Codeを起動するたびに読み込まれ、「このフォルダではこういうルールで動いてね」と伝えてくれます。
書かなくても動きます。でも書くと、同じことを毎回言わなくていい。 「触らないで」「この形式で出して」「私の文体を真似して」——こういう指示を一度書いておけば、次からは自動的に適用されます。
最初の1ヶ月: 「とにかく禁止事項だけ書いた」時期
使い始めたばかりのころ、私はCLAUDE.mdを「危ないことを止めるストッパー」として使っていました。
ダウンロードフォルダのCLAUDE.md:
# ルール
- secrets/ フォルダは触らない
- .env ファイルは触らない
- 実行前に、変更内容のリストを出すこと
- ファイルを削除する場合は必ず確認を取ること最初はこれで十分でした。 「とにかく事故を防ぐ」フェーズ。
でも使っていると、「毎回同じ出力形式を指定するのが面倒」という不満が出てきます。 そこで次の一歩が始まりました。
2ヶ月目: 「形式」と「お願いの型」を覚えさせた
議事録をまとめてもらうとき、毎回「決定事項・TODO・次回の議題候補の形式で」と書いていました。 これをCLAUDE.mdにコピペしたら、言わなくてよくなりました。
業務フォルダのCLAUDE.md(一部):
## 議事録まとめの形式
以下の構成で出力してください。
- **日時・参加者**:1行で
- **決定事項**:番号つきリスト(各1〜2行)
- **TODO**:担当者・期限・ステータスを表形式
- **次回の議題候補**:箇条書き
禁止:
- 感想・コメントを入れない
- 「〜と思います」など推測表現を使わない
- 上記以外のセクションを追加しないこれを書いてから「議事録まとめて」だけで同じ形式が返ってくるようになりました。 「あ、CLAUDE.mdって便利なやつかも」と思い始めたのはこのあたりです。
転機: ブログ専用CLAUDE.mdを作った
このシリーズを書き続けているうちに、「ブログの仕事はブログの仕事で、専用のルールがあると便利では」と気づきました。
ブログフォルダ(/blog-i-ailab/)専用のCLAUDE.mdを作り、私の文体・トーン・禁則事項を書き込み始めたのです。
これが、いちばん育てる楽しさを感じた段階でした。
今のブログ用CLAUDE.mdの中身(実例)
現時点での私のブログ用CLAUDE.md、ほぼそのままお見せします。
# blog-i-ailab 執筆ルール(mera用)
## 基本プロフィール
- 書き手:mera(広報・制作担当、ノンエンジニア)
- 読者:AIに興味があるが専門知識がない一般の方
- ブログのトーン:親しみやすく、正直。専門用語は使わない or 使うなら必ず説明
## 文体ルール
- 語尾は「です/ます」調に統一
- 箇条書きより、文章でつなぐことを優先する
- 「〜してみました」「〜でした」という体験談の口調を大切にする
- 難しい概念は「人間で言うと〜」「身近な例えで言うと〜」で言い換える
## 禁止事項
- 「実は」「なんと」などの煽り表現は使わない
- 「〜すべき」「絶対に〜」などの断定的な言い方は避ける
- 誇張した数字・効果の表現は使わない
- アドバイス口調にしない(体験談スタイルを保つ)
## 記事の構造
- 冒頭:「こんにちは、meraです」から始める
- 「この記事で学べること」セクションを入れる
- h2 単位でCallout(info/tip/warning)を1〜2個入れる
- 末尾に「次に読むのがおすすめの記事」と「参考文献・出典」を入れる
## 触らないもの
- src/config/ 以下のJSONファイルは変更しない
- 他の著者の記事は編集しない
- draft: true の記事は読み取りのみ、変更しない
## よく使う指示
- SNS用テキスト:Xポスト140字以内、ハッシュタグ2〜3個、URL末尾に[URL]と書く
- リード文:200字以内、問いかけか情景描写で始める
- 見出し案:5案、スラッシュ区切りで出す最初の4行から始まり、失敗と発見のたびに一行ずつ増えて、今この長さになっています。
フォルダごとに使い分けるのがコツ
私は今、こんな構成でCLAUDE.mdを置いています。
| フォルダ | CLAUDE.mdの主な内容 |
|---|---|
~/Downloads/ | 触ってOK/NGの範囲、実行前確認ルール |
~/Documents/お仕事/ | 議事録フォーマット、メール文体、禁止事項 |
~/blog-i-ailab/ | 文体・トーン・記事構造・禁則語 |
~/AI実験/ | 実験フォルダなのでルールなし。なんでも試す場所 |
フォルダの性格に合わせて、内容がまったく違います。 「全部同じルール」にしないことで、それぞれの作業に最適化できました。
「CLAUDE.mdに何を書けばいいかわからない」人へ
最初は本当に何を書けばいいかわかりませんでした。 今なら、こんな順番を勧めます。
Step 1: 「触らないでほしいもの」だけ書く 最初はこれだけで十分。フォルダ名・ファイル名を書いておく。
Step 2: 「毎回言っていること」を移してくる 「毎回この形式で出してって言ってるな」と気づいたら、コピペする。
Step 3: 「失敗した原因」を書き留める 「なんか違う結果が返ってきたな」と思ったとき、その「なぜズレたか」をルールとして書く。
Step 4: 「うまくいったときの条件」を書く 失敗だけでなく、「これを言ったらピッタリな結果が出た」というときも書き留める。
CLAUDE.mdを「正解を書く場所」ではなく「自分とAIの共同メモ」だと思うと、ハードルが下がります。
「AIを育てている」という感覚について
CLAUDE.mdを書き続けていると、「AIを自分仕様にカスタマイズしている」という感覚が出てきます。
これは、ちょっと特別な体験でした。
最初は「すごいAIに従う」感覚だったのが、だんだん「私の好みに合わせて動いてくれる相棒」という感覚に変わってきた。
「あ、私の文体を覚えてる」「また全体をおさらいしなくて済んだ」——そういう瞬間が積み重なると、道具への信頼感が育ちます。
ノンエンジニアでも、コードを書かなくても、CLAUDE.mdを育てることでAIを「自分仕様」にできる。 それが、このシリーズで一番伝えたかったことのひとつかもしれません。
まとめ
- CLAUDE.mdは「AIへの事前指示」を書いておくファイル。毎回言わなくて済む
- 最初は「触ってほしくないもの」だけ書けば十分
- 「毎回言っていること」「失敗した理由」「うまくいった条件」を少しずつ追加していく
- フォルダごとに内容を使い分けると、それぞれの作業に最適化できる
- 「正解」はない。育てることがCLAUDE.mdの使い方
Claude Codeの奮闘記も、気づけば6回になりました。 インストールで緊張していた自分が、今では毎日Claudeとブログを書いている。 変わったなあ、と、少し感慨深い気持ちです。
次回以降は、「失敗した話」や「3ヶ月の振り返り」など、もう少し正直な話を書いていこうと思っています。
次に読むのがおすすめの記事
- ノンエンジニアのClaude Code奮闘記 #5 CLI・VS Code・Cowork——同じClaudeなのに何が違うの?
- ノンエンジニアのClaude Code奮闘記 #1 まずはインストール編