https://www.knightli.com/ja/tags/claude.md/ Recent content in CLAUDE.md on KnightLiブログ Hugo -- gohugo.io ja Thu, 23 Apr 2026 10:43:40 +0800 https://www.knightli.com/ja/2026/04/23/claude-code-claude-md-rules-memory-hooks-guide/ Thu, 23 Apr 2026 10:43:40 +0800 https://www.knightli.com/ja/2026/04/23/claude-code-claude-md-rules-memory-hooks-guide/ <p><code>Claude Code</code> をしばらく使っていると、すぐに気づくことがあります。モデルそのものが重要なのは当然ですが、どんな環境を与えるか、どんな境界を置くか、どんなルールを持たせるかも同じくらい重要だということです。</p> <p>最初のうちは「今回の prompt をどう書くか」に意識が向きがちです。ですが、本当に <code>Claude Code</code> を使いこなすようになると、気になるのは別のことです。</p> <ul> <li>それは自分が誰かを分かっているか</li> <li>自分がどう働くかを分かっているか</li> <li>破ってはいけないルールを分かっているか</li> <li>先に確認すべきことを分かっているか</li> <li>そうした境界を長期的に覚えていられるか</li> </ul> <p><code>Claude Code</code> が成熟したツールになる理由は、単にモデルが強いからではありません。こうした働き方を仕組みとして定着させる一式があるからです。大きく分けると、その中核は次の4層です。</p> <ul> <li><code>CLAUDE.md</code></li> <li><code>Rules</code></li> <li><code>Memory</code></li> <li><code>Hooks</code></li> </ul> <p>この記事では、この4つをまとめて整理します。</p> <h2 id="なぜ単発のプロンプトより環境設定のほうが重要なのか">なぜ単発のプロンプトより環境設定のほうが重要なのか </h2><p><code>Claude Code</code> を、雇ったアシスタントだと考えてみてください。</p> <p>初日に「何か手伝って」と一言だけ伝えることはないはずです。普通は説明書を渡して、次のようなことを伝えます。</p> <ul> <li>自分はどんな立場なのか</li> <li>どんなコミュニケーションのトーンを好むのか</li> <li>どんな操作は必ず事前確認が必要か</li> <li>以前起きたどんなミスを今後は避けたいか</li> <li>重要な文書がどこにあるか</li> </ul> <p>だからこそ、長い目で見ると、環境設定は単発の prompt より重要になりやすいのです。</p> <p>prompt が解決するのは「今回は何をするか」です。環境設定が解決するのは「これから毎回どう働くか」です。</p> <h2 id="第1層claudemd">第1層：<code>CLAUDE.md</code> </h2><p>まず一番基本から始めます。<code>CLAUDE.md</code> は本質的にはただのテキストファイルです。</p> <p>そこには Claude への説明を書けます。たとえば：</p> <ul> <li>自分が誰か</li> <li>何に取り組んでいるか</li> <li>どんなコミュニケーションを好むか</li> <li>守るべきルール</li> <li>現在のプロジェクトの特殊事情</li> <li>重要な文書やディレクトリの場所</li> </ul> <p><code>Claude Code</code> が起動するたびに、この文書は自動的にコンテキストに入るので、モデルは必ず目を通します。</p> <p>私はこれを「共有された暗黙知のファイル」だと考えることが多いです。実際、それがあなたとモデルの長期協業における前提になるからです。</p> <h3 id="claudemd-に書くのに向いていること"><code>CLAUDE.md</code> に書くのに向いていること </h3><p><code>CLAUDE.md</code> に最も向いているのは、おおむね次のような内容です。</p> <ul> <li>身元や仕事上の背景</li> <li>話し方や出力の好み</li> <li>グローバルな行動ルール</li> <li>よく参照する重要なプロジェクト背景</li> <li>よくあるミスとその防ぎ方</li> </ul> <p>たとえば：</p> <ul> <li>自分のタイムゾーン</li> <li>モデルによるメールやメッセージの直接送信を許可するか</li> <li>どの操作が不可逆か</li> <li>文書やファイルの扱い方の癖</li> <li>セキュリティ方針や機密情報の境界</li> </ul> <h3 id="とても大事な原則できるだけ簡潔にする">とても大事な原則：できるだけ簡潔にする </h3><p><code>CLAUDE.md</code> には非常に大事な原則があります。それは、できるだけ簡潔に保つことです。</p> <p>理由は単純で、毎回コンテキストに強制的に入るからです。</p> <p>長くなりすぎると、大量のコンテキストを消費してしまい、本当に重要な情報が薄まります。モデルが読まないのではなく、注意が分散し、最も重要なルールを取りこぼしやすくなるのです。</p> <p>公式の目安としては、<code>400</code> 行を超えないほうがよいと言われることが多いです。</p> <p>私自身はもう少し保守的で、できるだけ <code>200</code> 行以内に収めるようにしています。</p> <h3 id="claudemd-のよくあるスコープ"><code>CLAUDE.md</code> のよくあるスコープ </h3><p><code>CLAUDE.md</code> には実際には複数の配置レベルがあり、そのレベルによって効く範囲が変わります。最もよく使うのは次の2つです。</p> <h4 id="1-user-level">1. User Level </h4><p>これはグローバルレベルです。</p> <p>ローカル環境に置かれ、そのマシン上で扱うすべてのプロジェクトに効きます。</p> <p>ここに向いているのは：</p> <ul> <li>自分の基本情報</li> <li>汎用的なコミュニケーションの好み</li> <li>プロジェクトをまたいで通用する作業習慣</li> <li>グローバルな安全ルール</li> </ul> <p>たとえば、あなたのタイムゾーンが一般的に想定されがちなものではなく、バンコク時間であるなら、それは <code>user level</code> に置くのが自然です。そうすれば、後で日時を扱うときのミスが減ります。</p> <h4 id="2-project-level">2. Project Level </h4><p>こちらはプロジェクトレベルです。</p> <p>特定のプロジェクトディレクトリの下に置かれ、そのプロジェクトにだけ効きます。</p> <p>ここに向いているのは：</p> <ul> <li>プロジェクト固有の背景</li> <li>そのプロジェクトでしか成立しないルール</li> <li>ディレクトリ構成の説明</li> <li>重要文書の入口</li> </ul> <p>たとえば、あるプロジェクトが財務を扱い、別のプロジェクトが人事を扱うなら、背景も制約も違うので、同じグローバル説明に混ぜるべきではありません。</p> <h3 id="どのレベルに置くかをどう判断するか">どのレベルに置くかをどう判断するか </h3><p>判断基準はシンプルです。</p> <p>別のプロジェクトに移っても成立するなら <code>user level</code> に置く。</p> <p>プロジェクトを変えた瞬間に成立しなくなるなら <code>project level</code> に置く。</p> <h3 id="最初の版をどう書き始めるか">最初の版をどう書き始めるか </h3><p>よくある始め方は2つあります。</p> <h4 id="1-init-を使う">1. <code>/init</code> を使う </h4><p>ターミナルで <code>/init</code> を実行して、Claude に現在のプロジェクトをスキャンさせ、基礎的な <code>CLAUDE.md</code> を自動生成してもらう方法です。</p> <h4 id="2-claude-に整理してもらう">2. Claude に整理してもらう </h4><p>他の人がどう <code>CLAUDE.md</code> を書いているかを Claude に調べてもらい、自分の状況に合わせて質問してもらった上で、最終的に自分向けの版に整理してもらうこともできます。</p> <p>多くの場合、ゼロから自分で書くよりずっと楽です。</p> <h3 id="とても実用的な習慣">とても実用的な習慣 </h3><p>長く協業していると、「これは今後も必ず覚えておくべきだ」「これは二度と繰り返してほしくない」と思うことが出てきます。そういう内容は、そのまま <code>CLAUDE.md</code> に書き足していくと便利です。</p> <p>ただし、その前に考えるべきことがあります。</p> <ul> <li>それはグローバルルールか</li> <li>それとも今のプロジェクト専用のルールか</li> </ul> <p>何でも1つのファイルに詰め込まないことが大切です。</p> <h2 id="第2層rules">第2層：<code>Rules</code> </h2><p>次が <code>Rules</code> です。</p> <p><code>CLAUDE.md</code> との最大の違いは、ファイル形式ではなくロードの仕方です。</p> <p><code>CLAUDE.md</code> は何をしていても常に読まれます。</p> <p>一方、<code>Rules</code> の強みは <strong>条件付きで読み込める</strong> ことです。</p> <p>つまり、特定のパス、ファイル、ツール、場面でだけ、そのルールを読ませることができます。</p> <h3 id="なぜ条件付きロードが重要なのか">なぜ条件付きロードが重要なのか </h3><p>コンテキスト空間は常に限られています。</p> <p>すべてのルールを無差別に毎回押し込むと、次の2つが起きます。</p> <ul> <li>モデルの負担が増える</li> <li>本当に重要なルールが埋もれる</li> </ul> <p>必要なときに必要な情報だけ読ませる。これが条件付きロードの価値です。</p> <h3 id="claudemd-から-rules-に移すべきタイミング"><code>CLAUDE.md</code> から <code>Rules</code> に移すべきタイミング </h3><p>典型的には2つあります。</p> <h4 id="1-claudemd-が長くなりすぎたとき">1. <code>CLAUDE.md</code> が長くなりすぎたとき </h4><p><code>CLAUDE.md</code> が <code>200</code> 行を超え始め、ルールが増えすぎて重要な内容が薄まってきたら、一部を切り出すタイミングです。</p> <h4 id="2-特定のルールが特定のパスにしか関係しないとき">2. 特定のルールが特定のパスにしか関係しないとき </h4><p>たとえば、あるルールが：</p> <ul> <li>Python スクリプトにだけ有効</li> <li>hooks ディレクトリにだけ有効</li> <li>特定のサブプロジェクトにだけ有効</li> </ul> <p>のように、適用対象が明確なら、それは <code>Rules</code> に移したほうが自然です。</p> <h3 id="rules-が最も向いている場面"><code>Rules</code> が最も向いている場面 </h3><p>典型的なのは「特定状況・特定パス・特定ファイル種別」です。</p> <p>たとえば：</p> <ul> <li>hook ファイルにだけ適用したい規約</li> <li>特定種類のスクリプトだけで守らせたいコーディング規則</li> <li>特定ディレクトリだけで有効な作業方針</li> </ul> <p>そうした内容を <code>CLAUDE.md</code> に入れ続けるのは、あまり効率的ではありません。</p> <h2 id="第3層memory">第3層：<code>Memory</code> </h2><p>3つ目の層が <code>Memory</code> です。</p> <p>これも <code>CLAUDE.md</code> や <code>Rules</code> と同じくコンテキストに入りますが、本質的な違いがあります。</p> <p><code>CLAUDE.md</code> はあなたが意図的に定義するものです。</p> <p><code>Memory</code> は、協業の中で Claude が自分用に残すメモに近いものです。</p> <h3 id="memory-に入るもの"><code>Memory</code> に入るもの </h3><p>Claude が「これは覚えておく価値がある」「しばらく保持したほうがよい」と判断した内容は <code>Memory</code> に入ります。</p> <p>たとえば：</p> <ul> <li>あなたが修正したやり方</li> <li>最近追加された好み</li> <li>現在のプロジェクトの一時的な状態</li> <li>今日終わらず、明日続きが必要なこと</li> <li>最近誰と協業しているか</li> <li>最近出てきた個人的な情報や文脈</li> </ul> <p>つまり、<code>Memory</code> は長期制度というより、動的な知識に近いのです。</p> <h3 id="最初の2層との違い">最初の2層との違い </h3><p>簡単に分けるなら：</p> <ul> <li><code>CLAUDE.md</code> / <code>Rules</code>：長期的、制度的、明示的なルール</li> <li><code>Memory</code>：一時的、動的、作業の中で新しく得た理解</li> </ul> <p>ここ数日しか有効でないことや、状態が継続的に変わることなら、長期ルールではなく <code>Memory</code> に向いています。</p> <h3 id="memory-は手動でも書ける"><code>Memory</code> は手動でも書ける </h3><p><code>Memory</code> は自動整理されることがありますが、こちらから明示的に指示して書かせることもできます。</p> <p>たとえば：</p> <ul> <li>明日やることを覚えておいて</li> <li>誰の状況を追う必要があるか覚えておいて</li> <li>今月のプロジェクトの重要な節目を覚えておいて</li> </ul> <p>といった内容です。</p> <p>また、<code>/memory</code> コマンドで現在の記憶を確認し、手動で編集・削除することもできます。</p> <p>ただ、私自身はあまり頻繁に手で管理しません。Claude 側でも古くなった記憶を定期的に整理できるからです。</p> <h2 id="第4層hooks">第4層：<code>Hooks</code> </h2><p>最後であり、最も重要かつ上級なのが <code>Hooks</code> です。</p> <p>ここまでの <code>CLAUDE.md</code>、<code>Rules</code>、<code>Memory</code> は、いずれも最終的には自然言語の指示です。</p> <p>ルールを書けば、モデルはたいてい従います。ですが、それでも「解釈してから実行する」ものです。</p> <p>自然言語にとどまる限り、いくつかの問題が残ります。</p> <ul> <li>ときどき見落とす</li> <li>ルールが増えると注意が分散する</li> <li>状況によっては、そのルールを重要でないと自己判断する</li> </ul> <p>これは書き方が悪いのではなく、自然言語ルールが <code>100%</code> 強制にはなりにくいという性質によるものです。</p> <h3 id="hooks-の本質"><code>Hooks</code> の本質 </h3><p><code>Hooks</code> は自然言語の説明ではありません。スクリプトです。</p> <p>イベントで発火する、プログラムレベルの強制ロジックです。</p> <p>あるイベントが起きれば、そのロジックは必ず実行されます。モデルの判断で飛ばされることはありません。</p> <p>これが <code>Hooks</code> の最大の価値です。</p> <p>「守るべき」から「必ず実行される」へ変えることです。</p> <h3 id="どんなときに-hooks-に上げるべきか">どんなときに <code>Hooks</code> に上げるべきか </h3><p>もし、あるルールをすでに <code>CLAUDE.md</code> や <code>Rules</code> に書いてあるのに、Claude がときどき守り損ねる。そして、その見落としのコストが高い。そういう場合は <code>Hooks</code> に上げるべきです。</p> <p>要するに：</p> <ul> <li>低リスクならルール</li> <li>高リスクなら <code>Hooks</code></li> </ul> <h3 id="典型的な-hooks-の場面">典型的な <code>Hooks</code> の場面 </h3><p>最も典型的なのは、絶対にミスしてほしくない操作です。たとえば：</p> <ul> <li>メール送信前の確認</li> <li>Slack、Outlook、Gmail 送信前の確認</li> <li>危険なファイル削除の遮断</li> <li>パスワードや API Key の外部送信のブロック</li> </ul> <p>こうした内容が自然言語ルールだけだと、いつか忙しいタイミングでミスが起きる可能性があります。</p> <p>でも <code>Hooks</code> にしておけば、イベント発生時に必ず止められます。</p> <p>これは本当の意味でのプログラム的な安全柵です。</p> <h3 id="hooks-のよくあるトリガー地点"><code>Hooks</code> のよくあるトリガー地点 </h3><p><code>Hooks</code> はさまざまな段階に設定できます。たとえば：</p> <ul> <li>会話開始時にリマインドを入れる</li> <li>ツール実行前に条件を確認する</li> <li>ツール実行後に結果を検証する</li> </ul> <p>専門用語を全部知っている必要はありません。</p> <p>多くの場合、「こういう要件がある」「これを hook にすべきか」と明確に説明できれば、Claude が一緒に設計してくれます。</p> <p>また、<code>/hook</code> コマンドで現在設定されている hooks を確認することもできます。</p> <h2 id="より実用的な導入順">より実用的な導入順 </h2><p>この4層をつなげて運用するなら、私なら次の順番を勧めます。</p> <h3 id="ステップ1まず-init-で基本版-claudemd-を作る">ステップ1：まず <code>/init</code> で基本版 <code>CLAUDE.md</code> を作る </h3><p>最初から完璧なルール文書を手書きしようとしないことです。</p> <p>まずは Claude にプロジェクトを見てもらい、たたき台を作ってもらって、そこから育てていくのが自然です。</p> <h3 id="ステップ2使いながら足していく">ステップ2：使いながら足していく </h3><p>協業の中で、</p> <ul> <li>今後も必ず覚えてほしい</li> <li>このミスは二度と起こしてほしくない</li> <li>この好みは毎回効いてほしい</li> </ul> <p>というものが見つかったら、<code>CLAUDE.md</code> に追加していきます。</p> <h3 id="ステップ3claudemd-が長くなったら-rules-に分ける">ステップ3：<code>CLAUDE.md</code> が長くなったら <code>Rules</code> に分ける </h3><p><code>CLAUDE.md</code> がどんどん長くなり、すべてのルールが安定して効かなくなってきたら分割します。</p> <ul> <li>何がグローバルルールか</li> <li>何が特定パス専用か</li> </ul> <p>後者を <code>Rules</code> に移し、条件付きロードにします。</p> <h3 id="ステップ4高リスクなものを-hooks-に上げる">ステップ4：高リスクなものを <code>Hooks</code> に上げる </h3><p>書いてあるのにまだ漏れる。そして漏れると危険。そういうものは自然言語のままにせず、<code>Hooks</code> に上げます。</p> <p>つまり「リマインド」を「強制実行」に変えるわけです。</p> <h3 id="ステップ5一時状態は-memory-に任せる">ステップ5：一時状態は <code>Memory</code> に任せる </h3><p>期限があるもの、変化するもの、長期制度ではないものは、何でも <code>CLAUDE.md</code> に入れないことです。</p> <p>たとえば：</p> <ul> <li>現在のプロジェクト進捗</li> <li>最近の協業相手</li> <li>最近増えた好み</li> <li>直近の計画や ToDo</li> </ul> <p>こうしたものは <code>Memory</code> に持たせたほうが、コンテキストもすっきりし、モデルの挙動も安定しやすくなります。</p> <h2 id="4層それぞれに何を入れるか">4層それぞれに何を入れるか </h2><p>手早く覚えるなら、次の整理で十分です。</p> <ul> <li><code>CLAUDE.md</code>：長期的な共通認識、グローバルな説明、プロジェクトの基礎背景</li> <li><code>Rules</code>：パスや場面ごとに読み込む専門ルール</li> <li><code>Memory</code>：動的な知識、一時状態、最近学んだこと</li> <li><code>Hooks</code>：高リスク操作をプログラム的に強制制御する層</li> </ul> <h2 id="まとめ">まとめ </h2><p><code>Claude Code</code> を「コードを書けるチャット画面」として使う人は多いですが、深く使うほど、それは長期協業のための知的な作業台に近いと分かってきます。</p> <p>重要なのは毎回の指示文だけではありません。安定していて、分かりやすく、積み重ねていける環境を与えられているかどうかです。</p> <p>この4層、</p> <ul> <li><code>CLAUDE.md</code></li> <li><code>Rules</code></li> <li><code>Memory</code></li> <li><code>Hooks</code></li> </ul> <p>をきちんと組めるようになると、あなたとモデルの協業品質はかなり大きく上がります。</p> <p>毎回ゼロから「自分が誰で、どう働いて、何をしてはいけないか」を説明し直す必要がなくなり、それらが環境の一部として定着するからです。</p> <p>それこそが、強いモデルを本当に成熟した道具として使うための重要な一歩です。</p>