【2026年8月最新】CLAUDE.md チーム運用完全ガイド｜AIエージェントの「就業規則」を非エンジニア組織に定着させる方法
aikanri-admin
「CLAUDE.mdを作ってみたけれど、社員によって使い方がバラバラ」「せっかく書いたルールを誰も更新しない」「AIが指示を守ってくれない気がする」──この記事にたどり着いたあなたは、おそらくそんな悩みを抱えているのではないでしょうか。
CLAUDE.mdとは、AnthropicのAIコーディングエージェント「Claude Code」に対して、プロジェクトやチームが守ってほしいルールを書き込んでおくファイルのことです。一度作れば終わりではなく、チーム全員が同じ前提でAIを使い続けられるように運用し続けることこそが本当の難所です。
この記事では、CLAUDE.mdを「個人のメモ」から「組織の資産」に変えるための運用設計を、非エンジニアの経営者・管理職にもわかる言葉で解説します。ポイントは、CLAUDE.mdを「AIチームの就業規則」という比喩で捉え直すことです。就業規則が「会社の決まりごとを明文化し、誰が読んでも同じ行動基準になるようにする」ものであるように、CLAUDE.mdは「AIの決まりごとを明文化し、誰が使っても同じ品質の仕事をしてもらう」ためのものだからです。
代表菅澤
AI鬼管理山崎
この記事を最後まで読むと、次の6つが明確になります。
01 WHAT IS CLAUDE.MD CLAUDE.mdとは何か──「AIチームの就業規則」を経営者視点で理解する コードの話ではなく、組織運営の話として捉え直す
CLAUDE.mdは、Claude Codeがプロジェクトのフォルダを開いたときに自動的に読み込むテキストファイルです。中身はただの文章（Markdown形式）で、プログラミング言語ではありません。「敬語で話す」「経費は3万円以上なら要承認」といった社内ルールをWordファイルに書くのと同じ感覚で、「顧客への返信は必ず敬体で書く」「本番環境のファイルは事前確認なしに編集しない」といったAIへの指示を書き込みます。
📚 用語解説
CLAUDE.md：Claude Codeがプロジェクトフォルダを開いた際に自動で読み込む指示書ファイル。プログラミングの知識は不要で、日本語の文章でAIに「守ってほしいルール」を伝えられる。就業規則や業務マニュアルの位置づけに近い。
多くのチームが誤解しているのは、CLAUDE.mdを「AIへの1回きりの命令文」だと捉えていることです。しかし実態は逆で、CLAUDE.mdは会社の就業規則と同じように、事業やチームの実態に合わせて何度も改定していくものです。就業規則を一度作ったら二度と見直さない会社がないのと同様に、CLAUDE.mdも「作って終わり」ではなく「運用し続けるもの」として設計しなければ、すぐに形骸化してしまいます。
1-1. なぜチーム運用でCLAUDE.mdが崩れやすいのか
個人でClaude Codeを使っている場合、CLAUDE.mdは「自分専用のメモ」で済みます。しかしチームで使う場合、事情が変わります。担当者ごとに「守ってほしいルール」の理解がズレる、誰かが追記したルールに他のメンバーが気づかない、ルールが増えすぎてAIが逆に迷子になる──こうした問題は、個人利用では起きなかった「組織特有の課題」です。
AI鬼管理山崎
いきなり完璧なCLAUDE.mdを目指す必要はありません。就業規則も「入社時オリエンテーションで必ず伝えること」から始まったはずです。まずは「これだけは絶対に守ってほしい」ルールを5〜10行書くところから始めるのが、崩れない運用の第一歩です。
1-2. 「就業規則」との対応関係で理解する
CLAUDE.mdの各要素は、会社の就業規則・社内規程の仕組みとほぼそのまま対応させて理解できます。この対応関係を押さえておくと、ITの専門知識がなくても「今から何を決めようとしているか」が直感的にわかります。
| 会社の仕組み | CLAUDE.mdでの対応 | 共通する目的 |
|---|---|---|
| 就業規則本体 | プロジェクト共有スコープのCLAUDE.md | 組織全体が守るべき基本ルールの明文化 |
| 部署ごとの業務マニュアル | 部署別プロジェクトのCLAUDE.md | 現場に即した具体的な手順・基準の共有 |
| 個人の業務メモ | User・Localスコープ | 個人の作業スタイルに閉じた設定 |
| 規程の改定履歴・議事録 | バージョン管理の変更履歴 | 「なぜそうなったか」の経緯を追跡可能にする |
| 人事部・総務部（規程の管理責任者） | ルールごとの所有者 | 誰が最終的に責任を持つかの明確化 |
こうして並べてみると、CLAUDE.mdのチーム運用は「特別な技術」ではなく「これまで会社がやってきた規程管理を、AI向けに応用しているだけ」だとわかります。経営者・管理職にとって、実は最も土地勘のある領域だと言えるでしょう。
02 SCOPE DESIGN 適用範囲を制する者がCLAUDE.md運用を制する──4段階スコープの考え方 どこに置くかで、誰に・どこまで効くかが変わる
CLAUDE.mdは、置き場所によって適用される範囲が変わります。就業規則にも「全社共通の就業規則」「部署ごとの業務マニュアル」「個人の作業メモ」があるように、CLAUDE.mdにも4段階の適用範囲（スコープ）が存在します。これを理解せずに1つのファイルに全ルールを詰め込むと、必ず運用が破綻します。
| スコープ | 経営比喩 | 効く範囲 | 主な用途 |
|---|---|---|---|
| Managed policy（組織管理ポリシー） | IT部門・経営が全社に強制配布する規程 | 組織が配布したすべての端末・全プロジェクト | 全社で絶対に破らせたくない安全ルールの一律配布 |
| User（個人設定） | 個人の作業手帳 | その人のPC上で開くすべてのプロジェクト | 個人の作業スタイル・言語設定など横断ルール |
| Project（プロジェクト共有） | 部署の業務マニュアル | そのプロジェクト（フォルダ）に関わる全員 | チームで共有すべき業務ルール・禁止事項 |
| Local（個人のプロジェクト専用） | 現場の申し送りメモ | 自分のPC上のそのプロジェクトのみ（非共有） | 一時的な注意事項・共有前の下書き |
📚 用語解説
スコープ（適用範囲）：ルールがどこまで効くかの範囲のこと。CLAUDE.mdは置く場所によって「組織全体」「自分のPC全体」「特定プロジェクトのチーム全員」など、効く範囲が変わる。全社ルールと部署ルールを分けて管理するのと同じ発想。なお、複数スコープのCLAUDE.mdは上書きではなく連結してAIに読み込まれる仕様のため、内容が矛盾する場合にどちらが優先されるかは保証されない点に注意が必要（詳細は第8章）。
2-1. チーム運用で最も重要なのは「Project共有スコープ」
チームでCLAUDE.mdを運用する場合、最も重要になるのがプロジェクト直下に置く「Project共有スコープ」のファイルです。これはGit等のバージョン管理に含めることで、チーム全員が同じルールを同じタイミングで参照する状態を作れます。個人のUser設定やLocalメモは、あくまで補助的な位置づけに留めるのが基本方針です。
「個人のUser設定（そのPC全体に効く個人用ファイル）に業務ルールを書いてしまう」ケースが非常に多く見られます。これは「チームのルールを自分の手帳にだけメモしている」状態と同じで、他のメンバーには一切共有されません。チームに関わるルールは、必ずプロジェクト直下のProject共有ファイルに書くことを徹底してください。
2-2. 部署・プロジェクトが複数ある場合の分割設計
営業・経理・広告など複数の業務領域でClaude Codeを使う場合、すべてを1つの巨大なCLAUDE.mdに詰め込むのは避けるべきです。部署ごとにプロジェクトフォルダを分け、それぞれに専用のCLAUDE.mdを置くことで、「経理の担当者が営業用の細かいルールまで読まされる」といった無駄を防げます。全社で本当に一律強制したい原則はManaged policyでの配布を検討し、部署固有のルールは各プロジェクトのProjectスコープに分散させるのが基本設計です。
代表菅澤
2-3. 1プロジェクトで始めるか、複数プロジェクトに分けるかの判断基準
「最初から部署ごとに分けるべきか、まずは1つにまとめておくべきか」は、導入初期によく出る疑問です。結論としては、業務の担当者が重ならない場合は早めに分割し、同じメンバーが複数業務を兼務している場合はしばらく1つにまとめておくのが実務的な判断基準になります。分割の判断を先延ばしにしすぎると、後から「どのルールをどちらに移すか」の仕分け作業が発生し、かえって手間が増えます。
| 状況 | 推奨構成 | 理由 |
|---|---|---|
| 担当者が業務ごとに完全に分かれている | 早期に部署別プロジェクトへ分割 | 関係ないルールを読まされる無駄を最初から避けられる |
| 少人数で複数業務を兼務している | しばらく1つにまとめて運用 | 分割しても参照するメンバーが同じで、管理コストだけが増える |
| 将来的に部署が増える見込みがある | 共通ルールと固有ルールを最初から分けて書く | 増員・分割のタイミングでファイルを移すだけで済む |
「このルールを知らなくてよい人が半数以上いるか」を基準にすると判断しやすくなります。半数以上が無関係なら、そのルールは別プロジェクトに切り出すべきサインです。
03 OVER-WRITING RISK 「書きすぎ」がルールを形骸化させる──4つの失敗パターン 分厚い就業規則ほど、誰にも読まれなくなる
CLAUDE.mdの運用に慣れてくると、多くのチームが陥る罠があります。それは「念のため」でルールを追記し続け、ファイルがどんどん分厚くなっていくことです。分厚い就業規則が誰にも読まれなくなるのと同じように、長すぎるCLAUDE.mdはAI自身が本当に重要なルールを見落とす原因になります。ここでは、実際によく見られる4つの失敗パターンを紹介します。
3-1. 【パターン1】例外処理を全部書き込んでしまう
「先週こういうミスがあったから」という理由で、個別の例外事象への対処を1つずつ追記していくと、ファイルはあっという間に肥大化します。例外は個別対応が本質であり、すべてを恒久ルール化しようとすると、次の例外にはまた対応できないという悪循環に陥ります。
3-2. 【パターン2】社内の全業務知識を移植しようとする
CLAUDE.mdを「社内wikiの代わり」にしてしまうケースです。業務マニュアル全体をコピー&ペーストすると、AIが毎回大量の文章を読み込むことになり、本当に重要な「守るべきルール」が埋もれてしまいます。業務知識の解説と、AIに守ってほしい行動ルールは、明確に分けて管理すべきです。
3-3. 【パターン3】禁止事項ばかりを積み上げる
「〜してはいけない」という禁止ルールばかりが並ぶCLAUDE.mdは、就業規則で言えば懲罰規定だけが延々と並んでいる状態に近く、何を目指して仕事をすればいいのかが伝わりません。禁止事項と同じくらい、「こういう時はこう判断してほしい」という判断基準・方針を書くことが重要です。
3-4. 【パターン4】誰も削除しないまま増え続ける
追記だけが行われ、不要になったルールが一度も削除されない状態です。担当者が変わった、業務フローが変わった、といった理由でルールの前提が崩れても、誰も気づかずに古いルールが残り続けます。結果として、矛盾したルールが同居する状態になり、AIの判断がぶれる原因になります。
AI鬼管理山崎
厳密な上限があるわけではありませんが、1つのCLAUDE.mdが数百行を超えてきたら黄色信号です。「新しく入ったメンバーが5分で読み切れるか」を1つの基準にすると、書きすぎを防ぎやすくなります。
3-5. 肥大化のサインと、そのときの対処法
ここまでの4パターンに共通する「肥大化のサイン」を早期に見つけられれば、大がかりな整理をせずに済みます。以下は、実務でよく見られるサインと、その場での対処法を整理したものです。
| 肥大化のサイン | 考えられる原因 | その場での対処法 |
|---|---|---|
| 同じような内容の項目が何箇所にもある | 追記のたびに全体を見返さず、末尾に足している | 追記前に既存項目を検索し、統合できないか確認する |
| 「〜の場合は」という条件分岐が増え続けている | 個別の例外を全部ルール化しようとしている | 3回以上繰り返した例外だけを昇格させる運用に切り替える |
| 新メンバーが「結局何が一番大事か分からない」と言う | 禁止事項ばかりで優先順位が示されていない | 最重要ルールを先頭にまとめ、優先度を明記する |
| 半年前の担当者名や旧サービス名が残っている | 棚卸しのタイミングが決まっていない | 定例の棚卸しをカレンダーに登録し、更新日を記録する |
04 OPERATING PRINCIPLES チームでCLAUDE.mdを運用するための7つの設計原則 「誰が」「どう変更し」「どう伝わるか」を仕組み化する
CLAUDE.mdの中身（何を書くか）よりも、実は「どう運用し続けるか」という仕組み設計のほうが、チーム導入の成否を大きく左右します。ここでは、弊社の運用経験から見えてきた7つの設計原則を紹介します。
4-1. 原則1：ルールごとに「所有者」を決める
CLAUDE.mdの各項目について、「誰が責任を持ってメンテナンスするか」を決めておくことが最も重要な原則です。所有者が曖昧なルールは、環境が変わっても誰も更新せず、いつの間にか実態と乖離していきます。
4-2. 原則2：変更は必ずレビューを通す
誰か一人が気づかないうちにルールを書き換えられる状態は避けるべきです。変更内容を他のメンバーが確認してから反映するフローを設けることで、独断による改変や、意図しない既存ルールの上書きを防げます。
4-3. 原則3：変更履歴を残す
「なぜこのルールが追加されたのか」という経緯が分からなくなると、後から見た人がそのルールを削除していいのか判断できません。バージョン管理の仕組みを使い、変更のたびに理由をひとことでも記録しておくことで、ルールの背景が追跡可能になります。
📚 用語解説
バージョン管理：ファイルの変更履歴を「誰が」「いつ」「何を」変えたかとセットで記録・保存する仕組み。GitというツールがIT業界の標準として広く使われている。就業規則の改定履歴を台帳で管理するのと同じ発想。
変更案を
担当者が作成
所有者・関係者が
内容を確認
理由を添えて
履歴に反映
チーム全員に
変更を通知
4-4. 原則4：新人オンボーディングに組み込む
新しくチームに入ったメンバーに対して、CLAUDE.mdの存在と読み方を最初に案内するステップを、入社時研修や業務引き継ぎのフローに組み込みます。「知らなかった」を防ぐ最も確実な方法は、知る機会を仕組みとして用意することです。
4-5. 原則5：定例で棚卸しする
月次や四半期など、定期的にCLAUDE.mdの中身を見直すタイミングを事前に決めておくことが重要です。「気になったときに見直す」という運用は、忙しさに負けてほぼ実行されません。就業規則の年次改定と同じように、カレンダーに組み込んでおくのが確実です。
4-6. 原則6：例外対応はその場限りで指示し、ルール化は選別する
その場限りの例外は、CLAUDE.mdに書かずに都度の指示（チャット上での一言）で対応し、同じ例外が繰り返し発生した場合にのみ恒久ルールとして昇格させます。この選別のプロセスがあることで、第3章で紹介した「書きすぎ」を未然に防げます。
4-7. 原則7：部署・プロジェクト別に分割する
第2章で触れた通り、全社共通のルールと部署固有のルールを分けて管理することも、長期運用を安定させる重要な原則です。共通ルールは変更頻度を低く保ち、現場に近い固有ルールは各チームが機動的に更新できる体制にすることで、変更のたびに全社を巻き込む重さを避けられます。
4-8. 番外編：AIに「なぜ」を説明する文化を作る
7つの原則に加えて、意外と見落とされがちなのが「ルールの理由まで書く」文化です。「〜してはいけません」とだけ書かれたルールは、状況が少し変わった途端に応用が利きません。一方で「〜してはいけません。なぜなら◯◯だからです」と理由まで書かれたルールは、AIも人間も、似た状況に遭遇したときに理由に立ち返って適切に判断できます。就業規則で言えば、条文だけでなく「趣旨説明」が添えられているようなイメージです。
📚 用語解説
オンボーディング：新しく組織に加わったメンバーが、業務に必要な知識・ルール・環境にスムーズに慣れるための一連のプロセスのこと。CLAUDE.mdの案内も、この一環として組み込むことで「知らなかった」を防げる。
代表菅澤
05 GENAI CASE STUDY 【独自データ】GENAI社内のCLAUDE.md運用実例 全社でClaude Codeを使う会社は、ルールをどう回しているか
ここでは、弊社（株式会社GENAI）が実際にCLAUDE.mdを運用している状況を公開します。弊社ではClaude Max 20xプラン（月額約30,000円）を契約し、経営・営業・広告・開発・経理・秘書業務・個人業務まで社内のあらゆる業務にClaude Codeを組み込んでいます。
| 項目 | 内容 |
|---|---|
| 契約プラン | Claude Max 20x（月額約30,000円） |
| 利用開始 | 2025年後半〜 |
| CLAUDE.md構成 | 全社共通ルール（各プロジェクトのCLAUDE.mdに共通記載）＋業務領域ごとのプロジェクト別ルール |
| 更新頻度 | 不具合・認識ズレが起きるたびに随時反映、加えて定期的な棚卸し |
弊社のCLAUDE.mdには、全社共通で守ってほしい原則──たとえば「顧客に直接届く操作は必ず事前承認を得る」「認証情報を画面に表示しない」「実データで裏取りしてから判断する」といった、業務領域をまたいで共通する安全基準を記載しています。一方で、営業資料の文体ルールや、広告レポートのフォーマットといった各業務固有のルールは、それぞれのプロジェクトファイルに分散させています。
1業務だけ
試しにルール化
（例: 議事録作成）
運用しながら
ズレを検知
再発するズレだけ
ルールに昇格
他業務にも
同じ型で横展開
この4ステップを繰り返すことで、CLAUDE.mdは「最初から完璧な規則集」を目指すのではなく、実際の失敗・認識ズレから逆算して育てていく形になっています。就業規則も、実際のトラブル事例をもとに条文が追加されていくのと同じ発想です。
本章の運用内容は弊社の実例であり、業種・組織規模・担当者のITリテラシーによって最適な設計は変わります。あくまで「全社でClaude Codeを回す会社は、CLAUDE.mdをどう扱っているか」の参考情報としてご覧ください。
AI鬼管理山崎
5-3. 業務領域ごとに何をルール化しているか（骨子レベル）
弊社での運用の骨子を、業務領域別に紹介します。具体的な文面は非公開ですが、「何を対象に、何を明文化しているか」という骨子は多くの組織で参考にしていただけるはずです。
| 業務領域 | ルール化している主な内容 |
|---|---|
| 営業 | 提案書・見積の文体統一、顧客固有情報の取り扱い方、資料のフォーマット |
| 広告運用 | レポートの指標定義、異常値を検知した際のエスカレーション基準 |
| 経理 | 仕訳の勘定科目ルール、証憑の確認手順、金額の閾値に応じた承認要否 |
| 秘書業務 | 日報・議事録のフォーマット、社外に送る文面のトーン、確認が必要な操作の線引き |
| 全社共通 | 本番環境・顧客に届く操作の事前確認、認証情報の非表示、実データでの裏取り |
この骨子からもわかる通り、業務固有のルールは「フォーマット」「基準」「エスカレーションの線引き」に集中させ、全社共通ルールは「安全」「機密情報の扱い」といった一線を越えてはいけない事項に絞っています。この住み分けが、第4章で述べた「7原則」を実際の業務に落とし込んだ形です。
06 OVERCOMING BARRIERS 【独自】非エンジニア組織がCLAUDE.mdを定着させる3つの壁 ITの知識がなくても運用は回せる
「CLAUDE.mdなんて、エンジニアがいない会社には無理では」と感じる方も多いはずです。しかし実際には、CLAUDE.mdはただのテキストファイルであり、プログラミングの知識は一切不要です。ここでは、非エンジニアの組織がつまずきやすい3つの壁と、その越え方を紹介します。
6-1. 【壁1】「ルールを書く」ことへの心理的抵抗
最初の壁は、「AIへの指示書を書く」という行為自体への抵抗感です。しかし実際にやることは、就業規則の草案を作るのとほぼ同じです。ゼロから書き起こす必要はなく、既存の業務マニュアルや口頭で伝えている注意事項を、そのまま箇条書きにするだけで最初のCLAUDE.mdとして機能します。
「いつも新人に口頭で説明していること」を思い出して、それを箇条書きで書き出すところから始めてください。それだけで、多くの組織にとって十分に機能する最初のCLAUDE.mdになります。
6-2. 【壁2】「守られているか分からない」という不安
ルールを書いても、AIが本当に守っているかを逐一確認するのは現実的ではありません。この不安への対策は、「守ってほしい理由」もセットで書くことです。理由を理解した上での指示は、単なる禁止事項の羅列よりも遵守率が上がる傾向があります。加えて、重要な操作については人間の承認を挟む仕組み（後述する自動チェック機構）を併用することで、AI任せにしすぎないバランスを取れます。
6-3. 【壁3】「属人化したルールが放置される」問題
CLAUDE.mdを整備した担当者が異動・退職すると、誰もメンテナンスしなくなり、実態と乖離したルールが残り続けるケースがあります。これは第4章で紹介した「原則1：所有者を決める」を組織のルールとして徹底することでしか防げません。「担当者が変わってもルールは会社の資産として引き継ぐ」という意識づけが重要です。
代表菅澤
07 ROLE SEPARATION CLAUDE.mdと「業務手順書」「自動チェック機構」の使い分け 就業規則・業務手順書・自動チェックは、それぞれ役割が違う
Claude Codeには、CLAUDE.md以外にも「Skills（業務手順書のように使える機能）」や「Hooks（特定の操作を自動的にチェック・制御する仕組み）」といった関連機能があります。これらを混同すると運用が複雑になるため、経営の比喩で役割を整理しておきましょう。
📚 用語解説
Skills（Agent Skills）：「この業務をするときの具体的な手順」をAIに覚えさせておく機能。就業規則が「方針・原則」を書くものだとすれば、Skillsは「作業マニュアル・業務手順書」に近い。手順が複雑で毎回同じ流れで進める業務に向いている。
📚 用語解説
Hooks：特定の操作が行われる前後に、自動的にチェックや制御を挟む仕組み。「本番ファイルを編集する前に必ず確認を挟む」といった、人間の判断を待たせる強制力のある仕組みを作れる。就業規則が「守ってほしいお願い」だとすれば、Hooksは「物理的に止める仕組み」に近い。
| 機能 | 経営比喩 | 役割 | 向いている用途 |
|---|---|---|---|
| CLAUDE.md | 就業規則 | 方針・原則・判断基準を示す | 全体の行動指針、チームで共有すべき前提 |
| Skills | 業務手順書 | 具体的な作業の手順を教える | 複雑だが毎回同じ流れの定型業務 |
| Hooks | 自動チェック機構 | 特定の操作を強制的に制御する | 本番環境の保護など、絶対に守らせたい一線 |
この3つの関係を整理すると、「方針はCLAUDE.mdで示し、複雑な手順はSkillsに任せ、絶対に譲れない一線はHooksで機械的に止める」という役割分担になります。すべてをCLAUDE.mdに詰め込もうとするから「書きすぎ」の問題が起きるのであり、性質の異なるルールは、性質に合った置き場所に振り分けることが運用を軽くする鍵です。
AI鬼管理山崎
08 TROUBLESHOOTING よくあるトラブルと対処法 「ルールを書いたのに」を解消する
8-1. AIがCLAUDE.mdのルールを守ってくれない
最も多い相談です。原因の多くは、ルールが多すぎて重要な指示が埋もれているか、指示があいまいで解釈の余地が大きすぎるかのどちらかです。第3章の「書きすぎ」対策を実施したうえで、特に重要なルールは文章の冒頭に配置する、具体的な行動レベルまで書く（「丁寧に」ではなく「敬体で、結論から先に書く」など）といった調整が効果的です。
CLAUDE.mdは「絶対に100%守られる契約書」ではなく、AIへの「強い推奨事項」に近い性質を持ちます。100%の強制力が必要な操作（本番データの削除など）は、CLAUDE.mdの記述だけに頼らず、Hooksのような機械的な制御と組み合わせることが安全です。
8-2. 長い作業をしているうちにルールが薄れたように感じる
会話ややり取りが長くなると、AIが過去の文脈を要約・整理する処理が入ることがあり、その際に細かい指示のニュアンスが薄まったように感じられることがあります。対策としては、長時間の作業では区切りのタイミングでCLAUDE.mdの内容を再確認させる、あるいは重要な作業は都度セッションを分けるといった運用上の工夫が有効です。
8-3. チームの誰かが勝手にCLAUDE.mdを書き換えてしまう
これは第4章の「原則2：変更はレビューを通す」を徹底することでしか根本解決しません。技術的な対策としては、変更履歴が残るバージョン管理の仕組みを使い、誰がいつ何を変えたかが誰の目にも見える状態にしておくことが最低限の予防線になります。
8-4. 複数のCLAUDE.mdの内容が矛盾している場合はどうなるか
第2章で紹介した複数のスコープを併用していると、「User設定とProject設定で、書いてあることが食い違っている」という状態が起こり得ます。Claude Codeの仕様では、各スコープのCLAUDE.mdは上書きではなく連結されてAIに読み込まれます。つまり、狭い範囲の記述が自動的に優先されるような仕組みはなく、内容が矛盾した場合にAIがどちらを優先するかは保証されません。これは就業規則と部署マニュアルが矛盾したまま放置され、読む人（この場合はAI）の解釈に委ねられてしまっている状態に近いと理解してください。
「優先順位は自動でどうにかなるはず」と考えて矛盾したルールを放置すると、「どちらが正しいか」で毎回AIの判断がぶれる原因になります。矛盾に気づいた時点で、第4章の原則2（レビュー）に沿ってどちらかに統一し、矛盾する記述を残さないことが唯一の確実な対応です。
09 GETTING STARTED 導入チェックリストと運用の始め方 完璧を目指さず、まず1つのプロジェクトから
最後に、これからチームでCLAUDE.mdを導入する際の実践的な進め方をまとめます。第1章から第8章までの内容を踏まえ、「いきなり全社導入」を狙わず、小さく始めて広げるアプローチを推奨します。
最も頻度が
高い業務を1つ
口頭の注意事項を
書き出す
プロジェクト直下＋
バージョン管理
所有者・レビュー
棚卸しを回す
9-1. チェックリスト（導入前に確認すること）
9-2. 組織規模別・目的別のテンプレート方針
CLAUDE.mdの中身は業種・組織によって大きく異なりますが、「どんな骨子で組み立てるか」という型はある程度共通化できます。以下は、組織の状態別に見た骨子の目安です。
| 組織の状態 | テンプレートの骨子 | 重点ポイント |
|---|---|---|
| 個人〜数名の小規模チーム | 安全ルール＋文体・トーン＋業務の優先順位の3項目のみ | とにかく短く。まずは運用を止めないことを優先する |
| 複数部署のある中規模組織 | 全社共通の安全原則（Project共通ファイル／Managed policy）＋部署別の業務ルール（Project） | 共通と固有を最初から分けて設計し、後からの分割コストを避ける |
| 顧客対応・機密情報を扱う組織 | 安全ルールを最上位に配置し、理由の説明を必ずセットにする | 守られなかった場合の影響が大きいため、優先度の明示を徹底する |
どのテンプレートを選ぶ場合でも共通するのは、「最初から完成形を目指さない」という姿勢です。第9-1節のチェックリストを1つずつ実行していくだけで、多くのチームが陥る「書いたけど使われない」「書きすぎて誰も読まない」という2大失敗を回避できます。実際の業務の中で育てていくという姿勢が、結局は最短ルートです。
代表菅澤
10 CONCLUSION まとめ ── ルールを「文化」に変えるために CLAUDE.mdは書くものではなく、育てるもの
この記事では、CLAUDE.mdを「AIチームの就業規則」という比喩で捉え直し、4段階のスコープ設計、書きすぎを防ぐ原則、チーム運用のための7つの設計原則、弊社GENAIの実運用例、非エンジニア組織が越えるべき壁、関連機能との使い分け、よくあるトラブルまでを整理しました。最後にポイントを振り返ります。
最も重要なメッセージをお伝えします。CLAUDE.mdの価値は「何を書いたか」ではなく「どれだけ組織に定着し、育ち続けているか」で決まります。就業規則が形骸化した会社に良い組織文化が根付かないのと同じように、放置されたCLAUDE.mdはAIの品質にも、チームの生産性にも寄与しません。
弊社では、CLAUDE.mdの設計から運用の仕組み化まで、Claude Codeを使った業務自動化の一環として支援しています。「ルールを書いたけれど、どう運用すればいいか分からない」という方は、ぜひ以下のAI鬼管理までお気軽にご相談ください。
AI鬼管理山崎
CLAUDE.mdを「作って終わり」にせず、組織に定着させる設計を一緒に
チームでClaude Codeを使い始めたものの、ルールが定着しない・運用が属人化している。
弊社の実運用ノウハウをベースに、御社に合ったCLAUDE.md運用設計をご相談いただけます。
代表菅澤
NEXT STEP
この記事の内容を、あなたのビジネスで
実践してみませんか？
よくある質問
Q. CLAUDE.mdとAGENTS.mdは何が違いますか？
A. AGENTS.mdは特定ベンダーに依存しない共通フォーマットとして提案されているファイルで、CLAUDE.mdはAnthropic（Claude Code）専用の設定ファイルです。両者は似た目的を持ちますが、対応するAIツールの範囲が異なります。詳しい違いや併用方法については、別記事「agents.mdとは？CLAUDE.mdとの違い」で解説していますので、そちらもあわせてご覧ください。
Q. CLAUDE.mdに書いたのにAIが指示を守ってくれません。なぜですか？
A. ルールが多すぎて重要な指示が埋もれている、または指示があいまいで解釈の幅が大きいことが主な原因です。重要なルールは文章の冒頭付近に配置し、「丁寧に対応する」ではなく「敬体で結論から先に書く」のように、具体的な行動レベルまで落とし込んで書くことで改善するケースが多くあります。
Q. CLAUDE.mdはどれくらいの長さで書くべきですか？
A. 厳密な文字数の上限はありませんが、目安として「新しく入ったメンバーが5分程度で読み切れるか」を基準にするとよいでしょう。数百行を超えてくると、AI自身が重要なルールを見落としやすくなる傾向があります。長くなってきたら、業務ごとに複数ファイルへ分割することを検討してください。
Q. チームの誰かがCLAUDE.mdを勝手に書き換えてしまいます。どう防げばいいですか？
A. 変更内容を他のメンバーが確認してから反映するレビューフローを設けることが根本対策です。加えて、バージョン管理の仕組みを使って「誰が」「いつ」「何を」変更したかが可視化される状態にしておくことで、無断での改変を抑止しやすくなります。ルールごとに所有者を決めておくことも有効です。
Q. 新しく入ったメンバーに、CLAUDE.mdの存在をどう伝えればいいですか？
A. 入社時のオリエンテーションや業務引き継ぎのフローに、CLAUDE.mdの案内を組み込むのが最も確実です。「知っていて当然」という前提を置かず、就業規則の説明と同じように、最初に必ず案内する項目としてチェックリスト化しておくことをおすすめします。
Q. 部署やプロジェクトごとにCLAUDE.mdの内容を分けるべきですか？
A. はい、業務領域が複数にまたがる場合は分けることを推奨します。全社共通で守ってほしい原則はManaged policyでの配布や共通ファイルへの記載でまとめ、部署固有の細かいルールは各プロジェクトのファイルに分散させることで、担当外のルールを読まされる無駄を減らせます。
Q. CLAUDE.mdの見直しはどれくらいの頻度で行うべきですか？
A. 明確な正解はありませんが、四半期に1回など、あらかじめカレンダーに組み込んでおくことをおすすめします。「気になったときに見直す」という運用は実行されないことが多いため、定例のタイミングとして仕組み化することが継続のコツです。
Q. エンジニアがいない会社でも、CLAUDE.mdの運用は始められますか？
A. はい、始められます。CLAUDE.mdはプログラミング言語ではなく、日本語の文章で書くファイルです。普段口頭で新人に伝えている業務上の注意事項を箇条書きにするところから始めれば、多くの組織にとって十分に機能する最初のCLAUDE.mdになります。
Q. ルールを書きすぎているかどうかは、何を基準に判断すればいいですか？
A. 「新しく入ったメンバーが5分程度で読み切れるか」「半数以上のメンバーにとって無関係な内容が混ざっていないか」の2つが実務的な目安です。どちらかに当てはまり始めたら、業務ごとにファイルを分割する、あるいは繰り返し発生していない例外を削除するタイミングです。
Q. CLAUDE.mdと、Skills・Hooksはどう使い分ければいいですか？
A. 方針や判断基準はCLAUDE.md、複雑だが毎回同じ手順を踏む業務はSkills、本番環境の保護など絶対に守らせたい一線はHooksに任せる、という役割分担が基本です。すべてをCLAUDE.mdに詰め込もうとすると肥大化するため、性質の異なるルールは置き場所を分けることが運用を軽くするコツです。
Claude Codeで業務自動化を90日で叩き込む
経営者向けの伴走型パーソナルトレーニング
AI鬼管理／AIBPO by AI鬼管理へのお問い合わせ
この記事を読んで気になった方へ。
専門スタッフが、御社に最適な
業務自動化・業務代行プランを無料でご提案します。
- AI業務自動化サービス「AI鬼管理」を運営 — Claude Code を活用し、経営者の業務を「AIエージェントに任せる仕組み」へ転換するパーソナルトレーニングを 伴走構築 で提供。日報・採用・問い合わせ対応・経費精算・議事録・データ集計・営業リスト等の定型業務を、AIに代行させる体制を経営者と一緒に作り込む
- Claude Code 実装ノウハウを 経営者・法人クライアント に直接指導。生成AIを「便利ツール」ではなく 「業務を任せる存在」 として運用する手法を体系化
- 「やらせ切る管理」メソッドの開発者。シンゲキ株式会社（2021年設立・鬼管理専門塾運営）にて累計3,000名以上の学習者を志望校合格に導いた管理メソッドを、AI × 経営者支援 に転用
- 著書『3カ月で志望大学に合格できる鬼管理』(幻冬舎)、『親の過干渉こそ、最強の大学受験対策である。』(講談社)
- メディア出演: REAL VALUE / カンニング竹山のイチバン研究所 / ええじゃないかBiz 他
- 明治大学政治経済学部卒
