Claude Codeを導入した個人事業主から、いちばん多く聞くのがこれです。
「使えている。ただ、毎回の指示で自分の事業の話から説明し直している」

プロンプトを長くしても、次のセッションでは振り出しに戻ります。
指示の技術ではなく、役割を渡していないことの問題です。

CLAUDE.mdは、日本語の解説記事ではたいてい「設定ファイル」と紹介されます。
必ず守られるはずだと考えるので、守られないと書き足す。
ファイルが太り、大事な指示が埋もれて、さらに守られなくなります。

本記事は、私が講師として組み立てた120分・約9,500字の講義（AI社員の役割設計）を、個人事業主向けに組み直したものです。

CLAUDE.mdは設定ファイルではなく職務記述書である

公式仕様は「強制される設定ではなくコンテキスト」

公式ドキュメント（https://code.claude.com/docs/en/memory）は、メモリ系統が全会話の冒頭で読み込まれる一方、Claudeはそれらを「強制される設定ではなくコンテキスト」（context, not enforced configuration）として扱うと明記しています。
何を書くかの判断基準として挙げられているのは「新しいチームメンバーが生産性を出すために同じ文脈を必要とするとき」で、公式自身がこれをオンボーディング文書として位置づけています。

「CLAUDE.mdはプロジェクトの憲法で、衝突時は常に勝つ」という日本語の解説は、この記述と矛盾するので取りません。

止めたい行為は文書ではなく仕組みで止める

同じページには、Claudeの判断に関わらず動作をブロックしたいならPreToolUseフックを使うべきだ、という記述もあります。

職務記述書も渡せば必ず守られるものではないので、会社は「一定額以上の支出は上長承認」と紙に書くだけでなく、決裁システムでも止めます。
文書は方針と文脈を伝え、止めたい行為は仕組みで止める。

常時ロードされるから薄く保つ

CLAUDE.mdは、作業フォルダを開くたびに読まれます。
手順書やナレッジを詰め込むと毎回重く読まれ、肝心の役割定義が埋もれます。
私の体感ではA4で3枚を超えたあたりから後半の指示が反映されない頻度が上がったので、運用基準は1〜1.5枚と決めています。

「1ファイル200行以内が公式推奨」という記述を日本語の解説記事で見かけますが、私が確認した公式ページに行数の数値基準はありませんでした。数値で管理したいなら、自分の運用基準として決めてください。

書く中身は4ブロックだけ

抽象から具体へ、この順で書く

1. 役割定義：誰として働き、何の責任を負うのか
2. 担当業務と判断の前提：何を任せ、動く前に何を確認させるのか
3. フォルダの意味：どのフォルダが何の担当なのか
4. 守るべきルール：機密の扱い、出力形式、エスカレーション条件

フォルダ構造から書き始めると、それが誰の何のためにあるのか決まっておらず、途中で手が止まります。

外に出したものは、「請求書の作り方は 02_finance/sop_invoice.md を参照する」と1行書けば足ります。

AIが自分で覚える分は書かない

2026年のClaude Codeには、人間が書くCLAUDE.mdと、Claude自身がセッションを越えて書き溜めるauto memory（保存先は ~/.claude/projects/<project>/memory/）の2系統があります。
auto memoryが覚えるのは、ビルドコマンド、デバッグの知見、コードスタイルの好み、作業の習慣です。

公式の分担は、振る舞いを導きたいときはCLAUDE.md、こちらの修正から手作業なしに学習させたいときはauto memory。
一方「一定額を超える支出は人が承認する」は事業側の決定であって、観察から推定されるものではありません。
作業の癖はAIが覚えるので、人間が書く範囲は、役割、判断の前提、やらないことに絞られました。

役割は肩書きと職能リストの二段で書く

肩書きを1つ置き、その下に職能を並べる

私が自社で運用している設定を一般化すると、こうなります。
冒頭に「あなたはこの事業のCOOとして機能する」と、大きな肩書きを1つ置く。
そのすぐ下に、具体的な職能を並べる。
経営パートナー、業務秘書、リサーチャー、制作ディレクター、経理アシスタント。

肩書きだけだと、日々何を持つのかが伝わりません。
作業リストだけを並べると、リストに書いていない場面で止まります。

作業リストは役割定義ではない

講義の受講者がつまずいた一つ目が、ここでした。
「SNS投稿を作る、売上をまとめる、問い合わせに返信する」と並べて、役割定義を書いたつもりになる。
これは担当業務の欄です。

動く前に読むファイルを指定する

私のCLAUDE.mdには、戦略や価格、受注に関わる提案をする前に、意思決定のログと現行戦略の正本ファイルを必ず読むこと、と書いてあります。
この1行で、思いつきの提案が根拠のある提案に変わります。

書かないとどうなるか。
過去に同じ議論をして見送った経緯を知らないまま、「値上げしませんか」という提案が出てきます。
受講者がつまずいた二つ目が、この判断の前提の書き忘れでした。

小さな店ならこう書く

以下は説明のために組んだ架空の設定で、実店舗1つとオンライン販売、店主1名とアルバイト1名の雑貨店です。

肩書きは「店舗運営アシスタント」、その下にSNS告知担当、月次集計担当、問い合わせ下書き担当を置きます。
判断の前提は「告知文を書く前に、過去3か月の投稿と店のトーン方針のファイルを読む」の1行。
これがなければ一般的な商品紹介文が、あればその店の言葉遣いに寄った文が来ます。

フォルダは変わる頻度で分ける

2桁の番号は一度決めたら改名しない

私の運用では、00_context/ がプロフィールと記憶、01_strategy/ が事業戦略、02_finance/ が経理、03_projects/ が案件、04_content/ が情報発信、output/ がAIの出力の置き場です。
若い番号ほど滅多に変わらない文脈、大きい番号ほど流動的なものを置く。
00_context/ は年単位で変わらず、output/ は毎日増減します。

講義でも途中で番号を振り直したくなる受講者が出ますが、変えると、それまでに書いた参照が全部ずれます。

確定と検討中、入力と出力を分ける

確定したプロフィールや実績と、書き換え続ける進行中の戦略を混ぜると、古い方針を根拠にした提案が来ます。
分けておけば、「確定事項は 00_context/、検討中は 01_strategy/」と一行書くだけで済みます。

AIが生成した成果物は output/ に集約し、いつでも捨てられる状態にします。
文脈ファイルと混ぜると、どれが軸になる情報なのか判別できなくなります。

人が握る判断をエスカレーション条件にする

任せるのは取り返しがつく作業

任せてよいのは、繰り返しで、定型的で、下書きレベルの作業と、情報整理や集計です。
共通するのは、時間を食うけれど、間違えても取り返しがつく点。

人が握るのは、最終承認、対外送信、契約、金額の決定です。
基準は1つ。
やり直しが内部で済むか、外に影響が出るか。

業務ごとの線引きを表にする

この境界線を頭の中に置いたままにせず、「エスカレーション条件」としてCLAUDE.mdに書き出します。

私が確認した範囲の日本語解説記事では、この話がほとんど出てきません。
講義でも、最も書き忘れが多かったのがこの項目でした。

書いても技術的には止まらない

いきなり契約書を送る動きは滅多に起きませんが、下書きと送信の区別を書いていなければ、送信まで依頼されたと解釈される余地は残ります。

完成したCLAUDE.mdの実例

ここまでの4ブロックを、前に出した雑貨店の設定で1枚にまとめると次のようになります。
実店舗1つとオンライン販売、店主1名とアルバイト1名という前提です。
A4で1枚に収まる分量で、これがそのまま運用の出発点になります。

# 雑貨店の運営

## あなたの役割

あなたはこの店の**店舗運営アシスタント**として機能する。
担当するのは次の3つ。

- SNS告知担当 — 新入荷・営業時間・イベントの告知文を作る
- 月次集計担当 — 売上と在庫の数字をまとめる
- 問い合わせ下書き担当 — 受け取った質問への返信案を作る

## 担当業務と判断の前提

- **告知文を書く前に、過去3か月の投稿と `01_brand/tone.md` を読む。**
  読まずに書くと、一般的な商品紹介文になる
- **集計を出す前に、`02_sales/` の当月ファイルを読む。**
  前月の数字を混ぜない
- **返信案を書く前に、`03_faq/` の既出回答を確認する。**
  同じ質問に違う回答をしない

## フォルダの意味

| フォルダ | 何を置くか | 変わる頻度 |
|---|---|---|
| `01_brand/` | 店のトーン方針、ロゴ、使ってよい言葉 | 年に1回 |
| `02_sales/` | 月次の売上と在庫 | 毎月 |
| `03_faq/` | よくある質問と既出の回答 | 随時 |
| `output/` | 生成した告知文・集計・返信案 | 毎日 |

`01_` は滅多に変わらない前提、`output/` は毎日入れ替わる。
番号は一度決めたら改名しない。

## 守るべきルール

- 顧客の氏名・連絡先・購入履歴を `output/` に書かない
- 数字を出すときは、どのファイルの何月分かを併記する
- 出力はMarkdown

### エスカレーション条件（人が承認する）

- **金額を伴う発注**は人が承認する。提案までに留める
- **問い合わせの返信の送信**は人が承認する。下書きまで作る
- **価格の決定・変更**は人が承認する。案を出すまでに留める
- **契約書の送付**は行わない

読んで分かるとおり、書いてあるのは役割と前提と境界線だけです。
告知文の書き方も、集計の手順も、ここには入っていません。
それらは 01_brand/tone.md のような別ファイルに置き、CLAUDE.mdからは参照するだけにします。

書いたCLAUDE.mdを検収する

自己チェック5項目

1. 役割に「肩書き＋職能リスト」の二段構えがあるか
2. 担当業務に「判断の前提」が1つ以上あるか
3. フォルダの意味が表になっているか
4. エスカレーション条件が明記されているか
5. 全体が薄いか（手順書を詰め込んでいないか）

講義でこのリストを渡したときは、2と4で引っかかる人が集中しました。
1と3と5は自分で気づけますが、2と4は「書いていないこと」なので、リストがないと気づけません。

AI自身に説明させて検証する

CLAUDE.mdを置いた状態で、「あなたの役割と、私が必ず承認すべきことを説明して」と聞きます。

役割がぼやけた答えなら①。
根拠を示さず提案してくるなら②。
承認範囲を答えられないなら④。

/init は完成品ではなく出発点

雛形は /init で生成できます。
ただし公式ブログ（https://claude.com/blog/using-claude-md-files、2025年11月25日公開）は、これを完成品ではなく出発点と位置づけています。
生成されるのはビルドコマンド、テスト手順、主要ディレクトリ、検出された規約で、役割定義もエスカレーション条件も入っていません。

迷ったときの基準は1つ。
人間の新入社員に渡す職務記述書なら、どう書くか。

よくあるご質問

40分で1枚書いて、1週間使う

練習用フォルダで40分

本番の事業フォルダで書き始めると、既存のファイル構成に引っぱられて整理作業になるので、練習用のフォルダを1つ作って、そこで書きます。

いきなりMarkdownで書き始めると体裁を整えることに気が向くので、時間を割く価値があるのは下書きの20分です。

1週間使って、ズレた箇所だけ直す

書けたら本番の事業フォルダに移し、実際の業務で1週間使ってから、ズレた箇所だけを直します。

私の場合も、最初に書いた判断の前提は3つのうち1つしか効いておらず、2週目に入れ替えました。
1週目は、正解を書く期間ではなく、どれが効かないかを見つける期間です。

残るのは「うちの業務なら、どこに境界を引くのが妥当か」という一点で、これは事業ごとに違います。
判断に迷う箇所があれば、お問い合わせから状況をお知らせください。
自社の事業に合わせた役割設計を、決めるところから支援しています。