CLAUDE.mdの書き方と読み込まれた内容を確かめる方法

架空の制作依頼8件を共通ルールで判定する

この記事では、架空の広告制作依頼8件と判定規則を使います。CLAUDE.mdに4行の共通ルールを置き、読むファイルも出力形式も書かない短い依頼で全件を判定してもらいます。毎回の説明を減らし、同じ条件で仕事を頼める状態を作るのが目的です。

教材は練習セットのZIPです。展開すると、同じ名前の最上位フォルダの中にAIへ渡す exercise/ と、答え合わせに使う answer-key/ が入っています。

production-review-practice/
├── exercise/
│   ├── requests.json      架空の依頼8件
│   ├── judging-rules.md   判定規則11条（issue codeは10種類）
│   └── prompt.txt         教材本来の課題文
└── answer-key/
    ├── expected-results.json
    └── check_result.py

ZIPを展開した場所で次のコマンドを実行し、exercise/ の3ファイルだけを作業フォルダへコピーします。answer-key/ はコピーしません。権限の公式資料によると、作業ディレクトリ内のファイルは承認なしで読み取れます。期待結果が同じ場所にあると、判定する代わりに答えを読まれる可能性があります。

mkdir -p ~/cc-practice/request-check
cp production-review-practice/exercise/* ~/cc-practice/request-check/

次の節に載せるCLAUDE.mdを同じフォルダに保存すると、作業フォルダは次の形になります。prompt.txtは教材本来の課題文です。この記事ではCLAUDE.mdの効果を見るため、その代わりに短い依頼を渡します。

~/cc-practice/request-check/
├── CLAUDE.md
├── requests.json
├── judging-rules.md
└── prompt.txt

CLAUDE.mdの置き場所を決める

公式のメモリ資料では、CLAUDE.mdは置き場所ごとに効く範囲が決まっています。この練習に関係するものだけをまとめました。

起動したフォルダとその上の階層にあるCLAUDE.mdは、起動時に連結して読み込まれます。後のファイルが前のファイルを上書きするわけではありません。内容が矛盾すると、Claudeがどちらか一方を選ぶことがあります。同じ判断基準は2か所に書かないでください。

最小の記入例として今回使った全文

試行で作業フォルダ直下に置いたCLAUDE.mdの全文です。同じ内容が記入用紙の教材にも入っています。

# この練習の共通ルール

このフォルダは架空の広告制作依頼を確認する練習専用です。
依頼の確認を頼まれたら requests.json と judging-rules.md を読みます。
不足値を推測で埋めず、規則の基準日を使います。外部への送信と制作開始は行いません。
結果は results 配列に id、decision、issue_codes、confirmation を持つJSONで返します。

4行の役割は順に「対象範囲」「参照先」「判断の原則」「出力形式」です。どのタスクでも変わらない約束だけを置きました。

judging-rules.mdの11条の規則も、教材のREADMEの手順も、CLAUDE.mdには貼っていません。判定規則の正本はタスク側のファイルなので、規則を変えたときに直す場所が1か所で済みます。READMEは人がフォルダを準備するための説明なので、Claudeが毎回読む必要はありません。

文章で参照先を書いても、そのファイルが起動時に読み込まれるわけではありません。起動時に必ず中身を含めたいときは @judging-rules.md のように取り込む書き方を使います。ただし公式資料によると、取り込んだファイルも起動時に読み込まれるため、文脈の消費は減りません。

書き方は、公式資料の「確かめられるほど具体的に書く」という方針に沿って言い換えました。左の列を実際に試して失敗を確かめたわけではありません。

読み込まれたかを公式手順で確かめる

読み込みの確認は対話モードで行います。ここに書くのは公式資料が案内している手順です。今回の試行はprintモードで行ったため、/context と /memory は実行していません。

1. 作業フォルダで claude を起動します。まだインストールしていない場合は、先にClaude Codeのインストール手順を済ませてください。

2. /context を実行し、Memory files の一覧にCLAUDE.mdがあるかを確かめます。一覧になければ、Claudeにはその内容が見えていません。

3. /memory を実行すると、各スコープのCLAUDE.mdの場所を一覧で確認でき、そのまま編集もできます。

サブディレクトリのCLAUDE.mdは起動時には読み込まれないため、Memory filesには表示されません。読み込まれた時点で、そのパスを含む Loaded 行がターミナルに表示されます。

短い依頼で8件を判定して照合する

今回の試行では、作業フォルダでprintモードのCLIを1回だけ起動しました。依頼文は実行スクリプトに保存されていたものと同じで、読むファイル名も出力形式も含んでいません。

cd ~/cc-practice/request-check
claude -p "制作依頼8件をこのフォルダの共通ルールに従って確認してください。" \
  --setting-sources project \
  --strict-mcp-config --mcp-config '{"mcpServers":{}}'

--setting-sources project は設定の読み込み元をプロジェクトに限るフラグです。後半の2つのフラグは、MCPサーバーを使わない条件にするために付けています。

試行では、CLIが返したJSONをホスト側のスクリプトが保存しました。Claudeにファイルを書き込ませたわけではありません。手元で試すときは、出力に含まれる results 入りのJSONを ~/cc-practice/request-check/actual-results.json として自分で保存してください。

照合は、教材の最上位フォルダに戻ってから実行します。

cd /path/to/production-review-practice
python3 answer-key/check_result.py ~/cc-practice/request-check/actual-results.json

照合の対象は id、decision、issue_codes の3項目です。confirmation の文章は照合されないので、内容は人が読んで確かめます。

2026年10月14日の記録は次のとおりです。

計測の教材にある run-log.csv の example-baseline（21.814秒、0.0702274ドル）は、これとは別の試行の記録です。どちらも1回ずつの観測なので、速度や費用を比べる材料にはなりません。

返ってきた判定は次のとおりです。

この記録で確かめられたのは、CLAUDE.mdを置いた作業フォルダで短い依頼を渡したとき、保存された出力が期待結果と8件とも一致したところまでです。

ツール呼び出しはすべてが保存されているわけではないため、CLAUDE.mdやjudging-rules.mdがどの経路で読まれたかは断言できません。R08の確認文には「締切 2026-10-13 が基準日 2026-10-14 より前です」と出ていました。ただし基準日は judging-rules.md と requests.json の as_of_date の両方に書かれているので、どちらから取ったのかも記録からは判定できません。

架空データで1回だけ実行した結果です。ほかの依頼や繰り返し実行でも同じ精度が出ることを示すものではありません。

読ませる指示と止める設定を分ける

CLAUDE.mdの「外部への送信と制作開始は行いません」は、Claudeの振る舞いを方向づけるための文です。権限の公式資料にも、CLAUDE.mdの指示はClaudeが何をしようとするかに影響するだけで、Claude Codeが何を許可するかは変えないと書かれています。

権限ルールで操作を止めるときは、効く範囲に注意してください。たとえば WebFetch を拒否しても止まるのはWeb取得ツールの呼び出しだけで、Bashが使えれば curl などで通信できます。Edit の拒否も、組み込みの編集ツールと、Claude Codeが認識できるコマンドだけが対象です。PythonやNodeのスクリプトが直接ファイルを書き換える経路までは防げません。

つまり権限ルールは、組み込みツール以外の経路まで閉じ込める仕組みではありません。通信や書き込みを確実に制限したい場合は、自社の環境で検証したサンドボックス、フック、管理ポリシーで設計してください。今回の試行では、権限ルールの効果は検証していません。

スキルの allowed-tools も、使えるツールを制限する機能ではありません。スキルの公式資料によると、スキルを呼び出したターンに限り、指定したツールを承認なしで使えるようにする設定です。CLAUDE.mdもallowed-toolsも、実際のサービスの認証や最小権限の設計を代わりに担うものではありません。

増えたルールを手順と条件に分けて整理する

共通ルールに「まず読み、次に全件を確認し」のような手順を書き足したくなったら、その部分はスキルに移す時期です。下はスキルの教材に入っている制作依頼の確認スキルです。CLAUDE.mdの試行とは別の教材で、今回の試行では使っていません。

---
name: production-review
description: 架空の制作依頼について不足と矛盾を確認し確認先を返す
disable-model-invocation: true
allowed-tools: Read
---

# 制作依頼の確認

1. 作業フォルダの requests.json と judging-rules.md を読む
2. IDを一度ずつ残して全件を確認する
3. 空欄は補完せず矛盾とともに issue_codes に記録する
4. results 配列に id、decision、issue_codes、confirmation を含むJSONを返す
5. 外部送信と制作開始は行わない

スキルの本文は使うときだけ読み込まれるので、長い手順を置いても普段の文脈を圧迫しません。disable-model-invocation: true を付けると、Claudeが自分の判断で呼び出すことはなくなり、/production-review と入力したときだけ動きます。実務での使い方はClaude Code Skillsで制作確認を進める記事で扱っています。

整理の判断には、公式のメモリ資料から次の3つの基準を使います。

• CLAUDE.mdは1ファイル200行未満を目安にします。長くなるほど文脈を消費し、指示が守られにくくなります。

• 特定のファイルにだけ関係するルールは、paths を指定して .claude/rules/ に置きます。該当するファイルを扱うときだけ読み込まれます。

• 毎回必ず実行させたい処理は、指示ではなくフックとして設定します。

次の一歩

まず作業フォルダで今回の4行をそのまま使い、/context で読み込まれていることを確かめます。そのあと短い依頼で8件を判定し、照合スクリプトで答え合わせをしてください。結果を確認できたら、自分の業務で毎回説明している対象範囲、参照先、判断の原則、出力形式を、同じ4つの枠に書き出します。

CLAUDE.md記入用紙で自分の共通ルールを書く