CLAUDE.mdの書き方。会社の前提をAIに毎回読ませる1枚

CLAUDE.mdとは、Claude Codeが起動のたびに読み直す指示ファイルで、会社の前提・判断の優先順位・やらないことを書いておく1枚です。この記事は、コーディング規約を書く開発者向けではなく、「会社の前提をAIに毎回読ませたい」経営者と非エンジニアの側から、CLAUDE.mdの書き方を書きます。

僕はAIVESTという会社を経営していて、Claude Codeを毎朝のブログ記事便やリサーチ便の母艦として動かしています。その運用はCLAUDE.mdに支えられていて、手元では役割ごとに分けた5枚が入れ子になって毎回読まれています。検索上位は、Claude Codeの設定ファイルの1つとして「配置場所4階層・コマンドと規約を書く・200行以下」を説く、エンジニア向けガイドで埋まっていて、それ自体は正しい。ただ、そこには「会社の前提や禁止事項を誰が何階層で書くのか」「判断そのものや毎回変わる指示はどこへ分けるのか」「誰がいつ更新するのか」がありません。この空白を、自社の運用の実物で埋めます。

CLAUDE.mdとは？Claude Codeが毎回読み直す「会社の前提」を書く1枚

設定ファイルではなく、毎回読み直される「前提の文章」

Claude Codeは、起動するとまず作業フォルダとその上位フォルダにあるCLAUDE.mdを読み込みます（Anthropic公式ドキュメント、2026年9月15日確認）。中身は普通のMarkdown（見出しと箇条書きで書く文章ファイル）で、プログラムの設定値ではありません。

公式ドキュメントは、CLAUDE.mdをこう位置づけています。

CLAUDE.mdは「そうでなければ毎回説明し直すことになる内容」を書き留めておく場所として扱う（Anthropic公式ドキュメント「How Claude remembers your project」、2026年9月15日確認・僕の訳）

つまり、「毎回口で言い直している前提」がCLAUDE.mdの正体です。会社の言葉の定義、どちらを優先するか、絶対にやらないこと。開発者にとってのビルドコマンドや命名規約と同じ位置に、経営者にとっては会社の前提が入ります。

昨日決めた前提が翌朝消える問題への実務解

僕がX（旧Twitter）で追っている範囲では、2026年9月14日時点で「1セッションで終わらない仕事の要件や決定事項を、次のセッションにどう引き継ぐのか」という質問が4件確認でき、いずれもリプライはゼロでした。質問側に「何をどのファイルに、誰が更新するか」の実務手順は付いていません。

セッション（Claude Codeを起動して閉じるまでの1回の作業）をまたぐと、会話の中で決めたことは残りません。残る場所はファイルだけで、その中で毎回自動で読まれるのがCLAUDE.mdです。だから答えは単純で、前提はCLAUDE.mdへ、判断の記録は別ファイルへ、と置き場所を最初に決める。以下でその置き方を説明します。

CLAUDE.mdはどこに置く？全社→部門→業務の3階層と「矛盾時は具体側が勝つ」

公式の4スコープを、会社の言葉で3つの役割に翻訳する

公式ドキュメントは、CLAUDE.mdの置き場所を4つのスコープ（効く範囲）で説明しています。組織全体に配る管理ポリシー、ユーザー個人のホームフォルダ、プロジェクトのフォルダ、そのプロジェクトで自分だけが使うローカルの4つです（2026年9月15日確認）。上位3本のガイドもこの分類をなぞっています。

僕はこれを、会社の言葉で3つの役割に翻訳して運用しています。

実体は5枚が入れ子になっていて、フォルダを1段下がるごとに1枚追加で読まれます。ただし読者が真似するなら、枚数ではなく「普遍・部門・業務」の3つの役割が分かれているかを見てください。

矛盾したらどちらが勝つかを、上位の階層に先に書く

階層を分けると必ず起きるのが、上と下で書いてあることが食い違う場面です。僕は全社の普遍ルールの3行目に、こう書いています。

プロジェクト固有の構成・配置・ツール詳細は各プロジェクトのCLAUDE.mdを参照。矛盾時はより具体的なプロジェクト側を優先する。（僕の全社ルール層の冒頭文）

矛盾のたびにAIが解釈で決めると、朝と夜で違う結論が出ます。「矛盾時は具体側が勝つ」を上位の階層に先に書いておくだけで、下の階層は「上を読まなくても、上と違うことを書いてよい」と安心して書けるようになります。部門層には「共通ルールは親を参照」と1行書き、繰り返しません。

CLAUDE.mdに書く4つ。優先順位つき原則・正本の所在表・禁止事項・機械で検査できる手順

上位のガイドは「コマンド・規約・構成」を書けと言います。開発では正しいのですが、会社の前提を書く側の記事として、僕の業務層のCLAUDE.mdは次の4節でできています。書く順番もこの通りです。

この4つの共通点は、どれも「毎回読まれる価値がある」もので、「今日だけ必要」なものが1つも無いことです。翌朝も同じ文が必要かどうかが、CLAUDE.mdに入れるかどうかの判定基準です。

CLAUDE.mdに書いてはいけない4つ。毎回変わる作業指示・長文の背景・判断そのもの・秘密情報

判断は記録ファイルへ、仮説は台帳へ、事故の教訓は申し送りへ

この4つを外へ出すと、CLAUDE.mdの周りに3種類のファイルが育ちます。僕のブログ記事の運用では次の3つで、いずれもCLAUDE.md本体には入れていません。

• 判断の記録（decisions）。記事1本ごとに「なぜこの企画を採用し、他の案を捨てたか」を日付つきで残す。本体からは所在表で「記事パッケージの中」と指すだけ

• 仮説台帳（hypotheses）。記事ごとの狙いと結果を1行ずつ追記する表。没になった行も削除しないと冒頭に書いてあり、外れた仮説が次の企画の学習データになる

• 申し送り（memory）。事故や失敗から「次はこうする」に昇格した短文の索引。2026年9月15日時点で11件。1件ごとに「なぜ」と「どう適用するか」を添えている

上位ガイドの「Auto Memory（Claude Codeが自動で覚える機能）との使い分け」はツールの機能の話で、ここで言う「人が書く判断の記録をどこへ置くか」とは別物です。

関連記事AIに仕事を任せるプロンプトの設計。完了・検品・上限の書き方AIに仕事を任せるプロンプトは「何ができたら終わりか」「誰が検品するか」「何回で打ち切るか」を先に書くと期待どおりに止まります。同じ型で39件の指示文を書いてきた現物と、毎朝の記事便がコードの判定で止まる実例で設計の書き方を解説します。→

非エンジニアが最初に書く1枚は3節で足りる。会社の言葉の定義・やらないこと・確認してほしいこと

サジェスト（検索窓に出る候補語）を2026年9月15日に取得すると、「claude.md 書き方」の派生で「非エンジニア」「例」「テンプレート」が並んでいました。上位ガイドのテンプレートは技術スタック・コマンド・規約の欄で構成されていて、非エンジニアには埋められません。最初の1枚は、次の3節で足ります。開発の欄は要りません。

3節目が特に効きます。「分からないときは聞け」を書いてあるかどうかで、AIが推測で埋めるか、止まって確認するかが分かれるからです。僕の全社ルール層でも「不確実なことを断定しない。確認した事実と推測を区別する」が対話姿勢の節に入っていて、これは開発の話ではなく、会社の前提の話です。

CLAUDE.mdは誰がいつ更新する？事故が起きた便が申し送りを書き、週次で昇格を判定する

「気づいた人が直す」では、昨日の学びが翌朝には無い

上位ガイドの更新論は「定期的に棚卸しする」までで、誰が、どの契機で書き足すかは決まっていません。決まっていないと、事故のたびに口で言い直す運用に戻ります。

僕の運用では、更新の主体と契機を2段に分けています。

• 事故が起きた便（その日の自動実行の1回）が、その場で申し送りを書く。原因と回避策を短文で、日付を付けて。CLAUDE.md本体は触らない

• 週に1回の診断で、申し送りが繰り返し効いているかを見て、本体の原則や禁止事項へ昇格するかを判定する。1回きりの事故は申し送りのまま置く

2026年9月13日の実例。ワークフローの構文エラーが申し送りになった

2026年9月13日の朝、僕のブログ記事のワークフローが構文エラーで起動しませんでした。前日に直したプロンプトの中に、記号の取り扱いミスがあったのが原因です。直したあとも同じエラーが続いて、起動の指定方法を変えると通る、という回避策が見つかりました。この「直した後は起動方法を変える」を、その日のうちに申し送りへ書き、索引にも1行足しました。本体のルールは1文字も変えていません。

このやり方の利点は、CLAUDE.md本体が事故のたびに太らないことです。申し送りは日付と理由を持った短文で、昇格してはじめて本体の禁止事項に1行増えます。逆に、本体に直接書き足す運用だと、半年後には「なぜこの行があるのか誰も知らない」禁止事項が並びます。

CLAUDE.mdが長くなったらどうする？肥大は読まれない。詳細は別ファイルへ移して所在表だけ残す

公式ドキュメントは、1枚あたり200行未満を目安にすると書いています（2026年9月15日確認）。上位3本のガイドも「書きすぎは逆効果」を共通して挙げています。僕はこの数値の効果を自分で測っていないので、目安として引くだけにします。

実務で効いているのは、数値より運用の型です。長くなったら、詳細を別ファイルへ移して、本体には「何がどこにあるか」の1行だけ残す。僕の業務層では、記事の書式仕様、声と文体、検査基準はそれぞれ別ファイルで、本体の所在表から名前で指しているだけです。本体は「原則・所在表・禁止・検査手順」の4節を保ち、それ以外が増えたら外へ出す。この繰り返しで、本体の節の数は変わりません。

手順を部品化して呼び出す仕組み（スキル）も、本体を細くする手段の1つです。CLAUDE.mdは毎回読まれる前提、スキルは必要なときだけ読まれる手順、と役割が違います。

関連記事Claude Codeスキルの作り方。繰り返し業務を自作で任せるClaude Codeのスキルは、繰り返し業務の手順をSKILL.md1枚に固定してAIに任せる再利用部品です。作り方の最小手順から、スキル化する業務の選定3基準、誤発動を防ぐ書き方まで、数十本を実運用する僕の実例で解説します。→

CLAUDE.mdのよくある質問

まとめ。書く4つ・書かない4つ・3階層・更新の主体

CLAUDE.mdは、Claude Codeが毎回読み直す「会社の前提」を書く1枚です。この記事の要点を4つに畳みます。

• 書く4つ。優先順位つき原則・正本の所在表・禁止事項・機械で検査できる手順。この順番で

• 書かない4つ。毎回変わる作業指示・長文の背景・判断そのもの・秘密情報。判断は記録ファイル、仮説は台帳、事故の教訓は申し送りへ分ける

• 置き方は3階層。全社の普遍ルール・部門の追加ルール・業務単位の作業ルール。上位に「矛盾時は具体側が勝つ」を先に書く

• 更新の主体。事故が起きた便が申し送りを書き、週次で本体への昇格を判定する。本体に直接書き足さない

非エンジニアなら、最初の1枚は「会社の言葉の定義・やらないこと・確認してほしいこと」の3節から始めてください。

関連記事ChatGPTのメモリ機能を業務で使う。覚えさせない線引きの設計ChatGPTのメモリ機能は会話をまたいで文脈を記憶する仕組みです。業務利用の鍵はオンオフ操作ではなく、何を覚えさせ何を覚えさせないかの設計。AIに会社の文脈を持たせて毎日運用する僕が、3層設計と鮮度管理の実務を解説します。→

出典

置き場所の4スコープ・読み込みの仕組み・200行の目安はAnthropic公式ドキュメントに、書く項目と書かない項目の分類の骨格は下記の上位3本に依っています。一方、「全社・部門・業務の3階層の役割分け」「書く4つと書かない4つ」「判断記録・仮説台帳・申し送りをCLAUDE.md本体から分離する構造」「事故が起きた便が申し送りを書き週次で昇格を判定する更新の主体」は、僕の運用から書いたもので、上記の出典には無い部分です。

• Anthropic: How Claude remembers your project（Claude Code公式ドキュメント）（2026年9月15日確認）

• サーバーワークス: CLAUDE.md の書き方ガイド（blog.serverworks.co.jp/claude-code-claudemd-guide）

• Zenn farstep: 効果的なCLAUDE.mdの書き方（zenn.dev/farstep/articles/how-to-write-a-great-claude-md）

• fyve: CLAUDE.mdとは？書き方テンプレート付き（fyve.co.jp/claude-code/articles/claude-code-claude-md-guide）