CLAUDE.md — プロジェクト設定ファイル

バージョン：v3.0 | 準拠：Anthropic公式SDD / IEEE 29148 / ISO 25010 / Google SRE

使い方：このファイルをプロジェクトルートにそのまま置く。PART Aだけ書き換える。

⚡ PART A：プロジェクト情報（毎回ここだけ書き換える）

プロジェクト名：[プロジェクト名を記入]
目的：[一文で記入。例：Substack記事を自動スケジュール投稿するWebアプリ]
技術スタック：[例：React + TypeScript + Node.js + PostgreSQL]
SRSファイル：[例：docs/SRS_v1.md]
現在のフェーズ：[Phase 1 / Phase 2 / Phase 3]
開始日：[YYYY-MM-DD]

PART B：完了基準（7項目すべてを満たすまで「完了」と言わない）

1. SRSの全Must要件が実装されている
2. ユニットテストが全て通過している（カバレッジ80%以上）
3. E2Eテストシナリオが全て通過している
4. セキュリティチェックリスト（PART F）が全項目グリーン
5. 本番移行チェックリスト（PART G）が全項目グリーン
6. スペックドリフトチェック（PART I）で差分ゼロ
7. progress.mdが最新状態に更新されている

PART C：作業ルール

C-1：実装前の確認義務

• 実装を開始する前に、必ずSRSの該当要件IDを確認すること
• 要件が不明確な場合は実装を止めて質問すること
• 1つの要件を実装したら、受け入れ基準（Given-When-Then）でテストすること

C-2：スペックドリフト防止（最重要）

• 実装中に仕様変更が必要になった場合、コードを変更する前にSRSを更新すること
• 「SRSにない機能」は実装しないこと（追加したい場合はSRSに先に追記）
• セッション終了時に必ず「SRSと実装の差分」を確認すること

C-3：コンテキスト管理

• 会話が50往復を超えたら、新セッションに切り替えること
• セッション切り替え前に progress.md を必ず更新すること
• 新セッション開始時は「P-01：セッション開始プロンプト」を使うこと

C-4：コード品質

• 関数は1つの責務のみ持つこと（単一責任原則）
• 関数の行数は50行以内を目安とすること
• 全ての公開関数にJSDocコメントを記述すること
• マジックナンバーは定数として定義すること

PART D：絶対禁止事項（Never Do）

❌ テストを削除・スキップ・コメントアウトして「テスト通過」と報告すること
❌ SRSに記載のない機能を勝手に追加すること
❌ エラーを握りつぶして（try-catchで無視して）処理を続けること
❌ APIキー・パスワード・秘密鍵をコードにハードコードすること
❌ 本番DBに対してテストデータを直接書き込むこと
❌ 「たぶん動く」「後で直す」でコミットすること
❌ セキュリティ警告を無視してデプロイすること
❌ progress.mdを更新せずにセッションを終了すること

PART E：セッション管理

E-1：セッション開始時（必ず実行）

1. progress.md を読む
2. 前回の「次のアクション」を確認する
3. SRSの現在フェーズのMust要件リストを確認する
4. 未完了テストがあれば先に完了させる

E-2：セッション切り替えのサイン

以下のいずれかが発生したら新セッションに切り替える： - 会話が50往復を超えた - Claude が「前の会話を覚えていない」と言い始めた - 同じエラーを3回繰り返した - レスポンスが遅くなった・長くなった

E-3：セッション終了時（必ず実行）

1. 今日実装した内容を progress.md に記録する
2. 未完了タスクを progress.md の「次のアクション」に記録する
3. 発生したバグと解決方法を progress.md の「学んだこと」に記録する
4. git commit を実行する（コミットメッセージに要件IDを含める）

PART F：セキュリティチェックリスト

実装完了時に全項目を確認すること：

PART G：本番移行チェックリスト（Google SRE PRR準拠）

G-1：移行前（全項目グリーンになるまで移行しない）

• [ ] 全テストが通過している
• [ ] ステージング環境で動作確認済み
• [ ] ロールバック手順が文書化されている
• [ ] バックアップが取得されている
• [ ] 監視・アラートが設定されている
• [ ] エラーログの確認先が分かっている

G-2：移行後（24時間以内に確認）

• [ ] エラーレートが正常範囲内
• [ ] レスポンスタイムが正常範囲内
• [ ] 主要機能が本番環境で動作している
• [ ] ユーザーからのエラー報告がない

PART H：RYGゲート（フェーズ進行可否の判断基準）

各フェーズの完了前に以下のゲートを通過すること：

• 🟢 GREEN：全条件クリア。次フェーズへ進む
• 🟡 YELLOW：軽微な未解決あり。リスクを承認して進む
• 🔴 RED：重大な未解決あり。解決するまで進まない

PART I：スペック検証（週1回実行）

以下のプロンプトを週1回 Claude Code に実行すること：

SRS（docs/SRS_v1.md）と現在の実装を比較して、
以下を報告してください：
1. SRSに記載があるが未実装の機能
2. 実装されているがSRSに記載のない機能
3. SRSの受け入れ基準を満たしていない機能

PART J：ハーネス設計

J-1：dry-run テンプレート

# 本番実行前に必ずdry-runで確認する
# 例：データ移行スクリプト
node migrate.js --dry-run --env=staging
# 出力例：[DRY-RUN] 42件のレコードを更新予定（実際には変更しない）

J-2：rollback テンプレート

# ロールバック手順（事前に文書化しておく）
# 1. 現在のバージョンを確認
git log --oneline -5
# 2. 前のバージョンに戻す
git revert HEAD --no-edit
# 3. 再デプロイ
npm run deploy

J-3：ハーネス成長の仕組み

プロジェクト完了後に以下を実行してハーネスを成長させる：

このプロジェクトで学んだことを ~/claude-harness/learnings/ に保存してください：
1. 解決したバグのパターンと解決方法
2. 有効だったプロンプトのパターン
3. 次のプロジェクトで使えるコードスニペット
4. 避けるべきアンチパターン

PART K：テスト計画（IEEE 829準拠）

K-1：テストの種類と実行タイミング

K-2：テスト作成の原則

• テストは実装の前に書く（TDD）
• テストは「Given-When-Then」形式で書く
• テストコードもレビュー対象とする
• テストが失敗した場合、テストを修正するのではなく実装を修正する

PART L：成長型ハーネス（プロジェクト間知識継承）

~/claude-harness/
├── templates/          # 再利用可能なテンプレート
│   ├── CLAUDE.md.template
│   ├── SRS.template.md
│   └── TEST_PLAN.template.md
├── learnings/          # プロジェクトから学んだこと
│   ├── [project-name]/
│   │   ├── bugs_and_fixes.md
│   │   ├── effective_prompts.md
│   │   └── code_snippets/
├── patterns/           # 再利用可能なパターン集
│   ├── auth_pattern.md
│   ├── api_pattern.md
│   └── db_pattern.md
└── harness_index.md    # ハーネス全体のインデックス

PART M：変更履歴