CLAUDE.mdに作業ルールを書く

この記事で学ぶこと

• 恒常的な条件だけを残す
• 曖昧な注意を具体的な操作へ変える
• 出力を使ってルールを検証する

共通ルールと今回の依頼を分ける

CLAUDE.mdは、プロジェクトで繰り返し使う指示を記述するファイルです。

配置場所によって適用範囲が変わるため、公式資料を確認し、まず対象プロジェクトのルールとして使います。

ここに書くのは、読者、用語、検証方法など、次回も変わらない条件です。

今日だけの締切や修正箇所は、その都度の依頼に残します。

例えば「記事は初学者の社会人向けに、です・ます調で書く」は共通条件です。

「今週は導入を200字程度へ直す」は今回の条件です。

両方を同じ場所へ蓄積すると、過去の依頼が現在も有効に見えます。

その結果、別の記事まで短縮するなど、作業の目的と合わない修正につながります。

期限付きの指示は完了後に残す必要を判断します。

内容を選ぶ基準は、これを知らない人が次の仕事を始めたら困るかどうかです。

迷ったら、過去の依頼を3件見て共通部分を抜き出します。

一度だけ起きた失敗の細部より、何を正本として扱うか、どの条件なら止めるかを残します。

作業の再現性を高める文章であり、過去の会話の保管庫ではありません。

共通ルールには、守る理由を短く添えると保守しやすくなります。

「実績はfacts.mdにあるものだけ使用。公開前に担当者が確認した資料のため」と書けば、別の資料へ移す際に何を引き継ぐべきか分かります。

単なる禁止の一覧より、判断の基準を残せます。

共通化の候補を選ぶときは、例外が多すぎないかも見ます。

「すべて200字以内」と固定すると、説明に必要な条件を削る恐れがあります。

長さは目安とし、必要な根拠を保つなど、仕事の目的に結び付いた基準を優先します。

規則を守るために成果が悪くなる条件は、そのまま残さないでください。

目的と参照順を固定する

目的は「高品質にする」ではなく、誰が何をできるようになるかまで書きます。

架空の教材制作なら「初学者が、本文だけで小さな実務課題を実行できる状態にする」です。

この目的があれば、見栄えの良い説明でも手順が欠けている場合に修正できます。

文章の好みだけで合否を決めないための基準になります。

次に、参照する資料の順番を書きます。

依頼条件はbrief.md、表記はstyle.md、事実はsources内の指定資料、というように役割を分けます。

複数の資料が食い違う場合は、更新日や担当者による確認が必要です。

「新しい日付を必ず優先」といった単純な規則では、確定版と下書きを取り違えることがあります。

正本の所在を明記します。

参照先は実際に存在するかを確かめてください。

移動済みのファイル名を残すと、AIが別の資料を代わりに探す可能性があります。

まず、参照先が読めなければ不足として報告する条件を置きます。

その上で追加の資料を探す必要があるときだけ範囲を広げます。

ルールの中のリンクやファイル名も、保守する対象です。

資料の優先順位が衝突する例でも確認します。

過去記事に古い料金があり、正本には新しい料金がある場合、どちらを使うかが明確である必要があります。

両方の数字を平均するなど、資料にない処理をしないよう、食い違いは確認事項として報告する条件を置きます。

正本同士が矛盾する場合の報告は、資料名と該当する記載を対にします。

「資料が違います」だけでは確認者が探し直すためです。

価格の例なら旧案と確定表の値を示し、採用判断を保留します。

どちらを選ぶかの責任を明確にすると、AIが文章の自然さで決める余地を減らせます。

禁止事項を行動へ翻訳する

「事故を起こさない」「慎重に進める」だけでは、何を止めるかが分かりません。

「元資料は編集しない」「公開操作は担当者の確認後に行う」「数値に根拠がなければ未確認と記す」のように、操作や出力に結び付けます。

判断できる言葉へ変えることで、作業後にも守れたか確認できます。

禁止事項と許可事項は対にして書くと運用しやすくなります。

例えば「資料は変更しない。原稿の誤字と構成は編集できる」です。

何もかも止めるルールでは、毎回確認が必要になり、繰り返し作業の利点が薄れます。

逆に「すべて任せる」では、公開や削除まで含むのか不明になります。

実務で困る境界に絞って条件を置きます。

ここで書く指示は、システムの権限設定そのものではありません。

ファイルに禁止事項があっても、技術的なアクセス制限が設定されたとは限りません。

秘密情報へのアクセスや外部連携は別途管理します。

ルールは判断の指針、権限は実行可能な範囲と区別し、両方が仕事の目的に合っていることを確かめます。

曖昧な禁止を見つけたら、具体的な入力と期待する対応を書きます。

「誇張しない」なら、根拠のない利用者数を加えないことが一例です。

どの表現を許すかを無限に列挙せず、事実を裏付ける資料が必要という原則と代表例を組み合わせてください。

承認条件は、許可の対象が再現できる形にします。

「担当者確認後」と書くなら、原稿の内容なのか公開先なのかを特定します。

確認済みの内容が後から大きく変わったときは、その差を判断材料へ戻します。

承認という言葉だけで仕事が安全になるのではなく、確認した対象が一致していることが必要です。

検証と報告を短く定義する

完成条件は、読む人が確かめられる形で記述します。

「分かりやすくする」なら、対象読者、専門語の説明、具体例、次の行動の有無へ分解します。

記事制作では、事実と引用元が対応することや、指定した出力先に保存されることも含められます。

必要な条件だけを共通化し、題材固有の採点は依頼側へ置きます。

報告形式には、変更箇所、行った確認、残った問題を入れます。

長い作業日誌は通常必要ありません。

架空の例なら「導入と第2節を修正。数値3件を資料と照合。引用許諾1件は未確認」で十分です。

「確認済み」とだけ書くより、何を確認したかが分かり、担当者が次に判断する対象も見えます。

確認できなかった項目を成功へ含めないことも書きます。

外部資料が開けなかった場合、AIの知識で数字を埋めても検証したことにはなりません。

保留を報告できる仕組みにすると、無理に完成へ寄せる動きを減らせます。

ルールの目的は報告を立派にすることではなく、人が成果物を採用できる材料を揃えることです。

報告の見本には、失敗した場合も用意します。

「参照資料が開けないため数値は変更せず、確認箇所を残しました」と書ける形です。

作業を止めたことだけでなく、完成した部分と残る判断が分かると、次の担当者が途中から再開しやすくなります。

成果物の保存先も完成条件へ含めると、作業後に探す手間を減らせます。

会話に文章があるだけでよい仕事と、指定ファイルへ保存されている必要がある仕事は違います。

今回の業務で必要な状態を選んでください。

保存したと報告された場合も、ファイルを開いて内容を確認する工程は残します。

小さな依頼でルールを試す

作成したCLAUDE.mdは、一度の実行で理解されたかを確認します。

「読みました」という返事だけでは不十分です。

見本原稿を直してもらい、元資料が変わっていないか、指定の文体か、未確認の情報が明記されているかを見ます。

実際の出力で検証すると、曖昧な指示を発見できます。

例えば「出典を付ける」と書いたのに、記事末尾へURLが並ぶだけだったとします。

必要なのが主張ごとの対応なら、「数値と引用には、根拠の資料名と該当箇所を添える」へ直します。

失敗を責める表現や、同じ禁止文の繰り返しは不要です。

解釈が分かれた箇所を具体化する方が、次回の改善につながります。

運用後は、現在使っていないルールや矛盾した記述を見直します。

複数の場所にルールがある場合は、適用範囲と重複も調べます。

本教材では、小さなプロジェクト用の1枚から始めることを提案します。

案件や用途が増えた時点で分割を検討し、読み手が参照順を説明できる量に保ちます。

更新後は、以前うまくできた依頼も再度試してください。

一つの失敗に合わせた追加条件が、通常の編集まで止める場合があります。

良い例と例外を小さな組で残しておくと、ルールを増やした結果、別の仕事が進めにくくなっていないかを確かめられます。

まとめ

CLAUDE.mdは、次の依頼でも使う前提を共有するための文書です。

目的、正本、操作の境界、検証を短く揃えます。

一度書いて終わりにせず、見本の作業結果から解釈が分かれた箇所を直してください。

• 恒常的な条件だけを残す
• 曖昧な注意を具体的な操作へ変える
• 出力を使ってルールを検証する