Claude CodeのCLAUDE.mdに書くこと｜作業の条件と確認手順を残す

CLAUDE.mdは、毎回必要な前提を伝える場所

Claude Codeでは、CLAUDE.mdにプロジェクトの指示を書けます。公式資料が説明するのは、Claudeが参照する文脈であり、文章自体が操作を強制的に制限する設定ではありません。重要な制限は、必要に応じて利用環境の権限設定などと組み合わせるものです。

相談受付サイトなら、受付条件の現行資料、変更後に通す操作、公開の判断をする担当者といった情報を残せます。コードだけでは分からない理由や例外も、仕事を知る人に尋ねたうえで書けます。

表は横にスクロールできます。

一回限りの依頼と、繰り返す約束を分ける

来週の相談会の日時変更は、その回だけの作業です。日時を変えるたびに一覧と詳細を照合する手順は、次回も使います。同じ共通指示に混ざると、終わった催しの条件まで現在のルールに見える場合があります。

一回限りの条件を仕様書や作業メモに置き、共通指示から必要な資料を参照する構成なら、情報の役割を区別できます。次の仕事でも使う内容かどうかが、置き場所を考える目安になります。

入れる例｜繰り返し直していること

本文の相談窓口だけ新しくなり、ボタンが古いままという見落としが続くなら、「関連する入口から同じ窓口へ到達するか」という確認項目にできます。経緯の長い説明より、次の変更にも使える条件を残す方法です。

分ける例｜今だけの数値や作業経緯

今月の開催枠、検討中のデザイン、終了した修正の会話は、その状態が分かる場所に保管できます。共通指示から分かれていれば、古い数値を現行の受付条件として使いにくくなります。

短く書くために、判断できる表現へ直す

「丁寧に作る」だけでは、作業の内容が分かりません。「相談条件は現行資料と照合し、未確認のまま掲載しない」「窓口の変更後は本文とボタンの行き先を照合する」なら、対象が具体的です。

検証コマンドも、そのプロジェクトで実行できる内容が前提になります。技術担当のREADMEや手順があるなら、存在しないコマンドを新しく書くより、そこを参照できます。

プロジェクトの目的：紹介を受けた人が、支援内容と相談方法を理解できるサイト。
業務の前提：受付条件・窓口は現行資料と照合する。分からない条件は補わず確認事項にする。
変更の考え方：依頼の目的に関係する範囲を直す。別の改善は今回の作業と分け、その理由を説明する。
確認：既存の検証手順を参照し、変更した入口から相談までの動きを確かめる。
報告：変更内容、実行した確認と結果、残った事項を示す。
公開：確認用の成果物を運営担当へ渡し、公開判断を分ける。

チームで運用する四つの手順

新しい担当者に、指示からどんな確認を想定したか説明してもらうと、言葉の解釈の違いが分かる場合があります。Claude Codeにも今回参照する指示を短く出してもらえます。小さな変更で実際に使うと、文章では自然でも作業には役立たない箇所が表れます。

1. 既存資料を読み、現在の仕事と異なる箇所を直す。
2. 繰り返し必要な目的・判断・確認方法を短く書く。
3. 担当者同士で読み、用語や条件の解釈をそろえる。
4. 実際の小さな変更で使い、役立たない記述を直す。

表は横にスクロールできます。

約束が増えたら、矛盾と期限を見直す

注意を追加し続けると、「自由に提案する」と「提案を増やさない」が同時に残る場合があります。対象や作業段階を説明できなければ、どちらに従うべきか分かりません。一回の失敗への対処を、すべての仕事に広げていないかも検討できます。

指示の変更理由と担当者が残っていると、運用が変わった際にも見直せます。古い手順は削除、別保管、書き換えのいずれかが要る場合があります。読み方に迷った箇所を実際の作業例に当てはめると、足りない説明も具体的になります。

よくある質問

書いておけば、必ず守られますか？

すべての行動が保証されるわけではありません。CLAUDE.mdの文章と、権限などによる操作の制御は別です。重要な制限には仕組みの設定を組み合わせ、実際の結果も確かめる必要があります。

自分一人の仕事でも必要ですか？

同じ説明や修正が繰り返されるなら、一人の仕事でも残す意味があります。最初から大きな文書にせず、次の仕事にも使う数項目から始められます。参照しなくなった記述を残す理由があるかも、後から検討できます。