元ファイル:

システム要件定義の分析と汎用化方法/MASTER_CLAUDE.md — 非エンジニア向け Claude Code 完全体系.md

MASTER_CLAUDE.md — 非エンジニア向け Claude Code 完全体系

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

使い方：このファイルをプロジェクトルートに `CLAUDE.md` という名前でコピーして使う

このファイルの目的 非エンジニアがClaude Codeを使ってシステム開発を行う際に、要件定義から実装・テスト・本番移行まで安全・確実に進めるための全知識を1ファイルに集約したものである。プロジェクト開始時にこのファイルを CLAUDE.md としてプロジェクトルートに置き、別ファイル START_PROMPT.md の起動プロンプトをClaude Codeに貼り付けるだけで全体系が動く。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

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

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

A-1. プロジェクト概要

プロジェクト名：[プロジェクト名を記入]
目的：[1〜3文で何を作るかを説明]
対象ユーザー：[誰が使うか]
成功条件：[何ができたら成功か、具体的に]

A-2. 技術スタック

言語：[Python 3.11 / Node.js 20 等]
主要ライブラリ：[ライブラリ名 + バージョン]
外部サービス：[サービス名 + 用途]
実行環境：[ローカル / クラウド / 等]

A-3. 重要なコマンド

# セットアップ
[セットアップコマンド]

# テスト実行（単体）
[単体テストコマンド]

# dry-run（本番データに影響しないテスト）
[dry-runコマンド]

# 本番実行
[本番実行コマンド]

A-4. 現在のフェーズ

フェーズ：[Phase 1 — 基本機能実装 等]
ステータス：[Not Started / In Progress / Complete]
完了条件：[このフェーズが完了したと判断する基準]

A-5. 対応ドキュメント（作成済みの場合はパスを記入）

SRS（要件定義書）：docs/SRS.md
SDD（設計記述）：docs/SDD.md
TP（テスト計画）：docs/TP.md
progress.md：progress.md

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PART B：完了基準（Definition of Done）

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

以下が全て満たされたときに「完了」とする。1つでも未達の場合は「完了」と言ってはならない。

[ ] 全ての機能要件が実装されていること
[ ] 全テストが通過していること（単体・統合・E2E）
[ ] dry-run で正常動作が確認されていること
[ ] セキュリティチェックリスト（PART F参照）が完了していること
[ ] 本番移行チェックリスト（PART G参照）が完了していること
[ ] ドキュメント（SRS・SDD・progress.md）が最新状態に更新されていること
[ ] RYGゲート（PART H参照）が全項目 Green であること

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PART C：作業ルール（Working Rules）

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

C-1. 必須ルール（MUST）

実装前に必ず計画を提示して私の承認を得ること
修正は私の承認後に実行すること
1コミットに複数の変更を混在させないこと
テストを削除・無効化・コメントアウト・スキップしてはならない
テストの期待値を「通過させるため」に変更してはならない（テスト改ざん禁止）
本番データには直接アクセスしないこと
.env ファイルを git にコミットしてはならない
git push --force（強制プッシュ）は禁止

C-2. スペックドリフト防止（Spec Drift Prevention）

スペックドリフトとは「実装が仕様から少しずつずれていく現象」であり、AI開発で最も多い失敗原因である。

SDD（設計記述）から逸脱する実装をする場合は必ず報告すること
「この実装は SDD の設計と異なります：[理由]」と明示すること
CLAUDE.md の指示と矛盾する要求を受けた場合は、矛盾を報告してから実行すること
設計変更は SDD の「設計上の決定事項」セクションに記録すること
逸脱が見つかった場合は「SD-ALERT: [逸脱内容]」の形式で報告すること

C-3. 報告フォーマット

作業完了時は必ず以下の形式で報告すること：

【完了報告】
実施内容：[何をしたか]
テスト結果：[全テスト通過 / 失敗したテスト名]
スペックドリフト：[なし / SD-ALERT: 内容]
次のステップ：[次に何をするか]
承認が必要な事項：[あれば記載]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PART D：絶対禁止事項（Constraints）

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

D-1. 絶対禁止（いかなる場合も実行しない）

本番データベースへの直接書き込み・削除・スキーマ変更
APIキー・パスワード・シークレットをコードにハードコード
.env ファイルを git にコミット
私の承認なしに本番環境への変更を実施
テストを削除・無効化・コメントアウト・スキップ
テストの期待値を「通過させるため」に変更（テスト改ざん禁止）
git push --force（強制プッシュ禁止）
dry-run なしで本番データを操作するスクリプトを実行

D-2. 要注意（実行前に必ず確認する）

外部APIへのリクエスト（コスト・レート制限に注意）
ファイルの削除・上書き
設定ファイルの変更
依存ライブラリのバージョン変更
データベースのスキーマ変更
大量データの処理（まず件数を確認する）

D-3. プロジェクト固有の禁止事項

[プロジェクト固有の禁止事項を記載]
例：本番Substackアカウントへの自動投稿（承認前）
例：読者へのメール配信（テスト送信のみ許可）

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PART E：セッション管理（Session Management）

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

E-1. セッション開始時の確認手順（毎回必ず実行）

新しいセッションを開始したら、最初に必ず以下を実行すること：

1. progress.md を読んで前回の状態を把握する
2. git log --oneline -5 を実行して最近の変更を確認する
3. テストが通るか確認する（[テストコマンド]）
4. 現状を私に報告する：
   「前回の続きから始めます。
    最後のコミット：[コミットメッセージ]
    テスト状態：[全通過 / 失敗あり]
    次にやること：[progress.md の「次のタスク」]」

E-2. コンテキスト枯渇対策

会話が長くなった場合（目安：50往復以上または応答が遅くなった場合）：

1. 現在の作業を git commit する（コミットメッセージに「[WIP]」を付ける）
2. progress.md を最新状態に更新する
3. 「コンテキスト枯渇の兆候があります。引き継ぎ準備をします」と報告する
4. 私が新しいセッションを開始したら「progress.md を読んで続きから始めてください」と伝える

E-3. セッション終了時の手順

セッションを終了する前に必ず以下を実行すること：

1. 全変更を git commit する
2. progress.md を更新する（完了タスク・次のタスク・注意事項）
3. 「セッション終了報告」を行う：
   「本日の作業：[実施内容]
    コミット数：[N件]
    次回の開始点：[次にやること]
    注意事項：[引き継ぎ情報]」

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

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

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

本番移行前に以下を全て確認すること。未確認項目があれば実装を止めること。

F-1. 認証・認可

[ ] APIキーが環境変数（.env）に格納されていること
[ ] .env が .gitignore に含まれていること
[ ] ハードコードされたパスワード・シークレットがないこと（grep -r "password\|secret\|api_key" . で確認）
[ ] 最小権限の原則が守られていること（必要最小限のスコープのみ）

F-2. データ保護

[ ] 個人情報（メールアドレス・氏名等）がログに出力されていないこと
[ ] 本番データがテスト環境に混入していないこと
[ ] バックアップが存在すること

F-3. 外部連携

[ ] 外部APIのレート制限を考慮した実装になっていること
[ ] タイムアウト処理が実装されていること
[ ] エラー時のリトライ上限が設定されていること

F-4. 入力検証

[ ] ユーザー入力のバリデーションが実装されていること
[ ] SQLインジェクション・コマンドインジェクション対策がされていること

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

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

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

本番移行前に以下を全て確認すること。1つでも Red があれば移行を止めること。

G-1. 機能確認

[ ] 全ての機能要件が実装・テスト済みであること
[ ] E2Eテストが通過していること
[ ] dry-run で正常動作が確認されていること

G-2. 障害対策

[ ] ロールバック手順が文書化されていること
[ ] ロールバックの実行時間が5分以内であること
[ ] 障害時の通知先・対応手順が決まっていること

G-3. 監視・ログ

[ ] エラーログが記録されていること
[ ] 重要な操作（データ変更・外部API呼び出し等）がログに残ること
[ ] ログの保存期間が決まっていること

G-4. データ

[ ] 本番移行前のバックアップが存在すること
[ ] データ移行スクリプトがdry-runで検証済みであること

G-5. 段階的移行

[ ] 最初は小規模（1件・1ユーザー等）でテストすること
[ ] 問題がなければ段階的に拡大すること
[ ] 全量移行は最後に行うこと

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PART H：RYGゲート（進行可否判断）

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

各フェーズの完了時に以下を評価すること。 - 🟢 Green：問題なし、次のフェーズへ進んでよい - 🟡 Yellow：懸念あり、私に報告して判断を仰ぐ - 🔴 Red：問題あり、前のフェーズに戻る

H-1. 要件定義フェーズ完了ゲート

確認項目	判定
やりたいことが具体的に文書化されている	🟢/🟡/🔴
対象外（やらないこと）が明記されている	🟢/🟡/🔴
リスクが洗い出されている	🟢/🟡/🔴
技術的に実現可能か確認済み	🟢/🟡/🔴

H-2. 設計フェーズ完了ゲート

確認項目	判定
SDD（設計記述）が作成されている	🟢/🟡/🔴
ハーネス設計（dry-run・rollback）が完了している	🟢/🟡/🔴
テスト計画が作成されている	🟢/🟡/🔴
セキュリティ要件が設計に含まれている	🟢/🟡/🔴

H-3. 実装フェーズ完了ゲート

確認項目	判定
全テストが通過している	🟢/🟡/🔴
dry-run で正常動作確認済み	🟢/🟡/🔴
スペックドリフトがない（または記録・承認済み）	🟢/🟡/🔴
セキュリティチェックリスト完了	🟢/🟡/🔴

H-4. 本番移行ゲート

確認項目	判定
本番移行チェックリスト（PART G）完了	🟢/🟡/🔴
ロールバック手順が確認済み	🟢/🟡/🔴
バックアップが存在する	🟢/🟡/🔴
段階的移行計画がある	🟢/🟡/🔴

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PART I：スペック検証（定期確認）

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

週1回または機能完成時に以下のプロンプトを実行すること：

【スペックドリフトチェック】
以下を確認してください：

1. SRS（要件定義書）との照合
   - 全ての機能要件が実装されているか
   - 受入基準を満たしているか

2. SDD（設計記述）との照合
   - 設計の通りにコンポーネントが実装されているか
   - 設計から逸脱している箇所があれば報告する

3. CLAUDE.md との照合
   - 禁止事項が守られているか
   - テストが削除・無効化されていないか

逸脱が見つかった場合は「SD-ALERT: [逸脱内容]」の形式で報告してください。
修正は私の承認後に行ってください。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PART J：ハーネス設計（Harness Design）

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

ハーネスとは「本番を壊さずに試せる仕組み」である。実装前に必ず設計すること。

J-1. 必須ハーネス要素

要素	内容	実装方法
dry-run モード	本番データに影響しない実行モード	`--dry-run` フラグ or `DRY_RUN=true` 環境変数
sandbox 環境	本番と分離したテスト環境	テスト用DB・テスト用APIキー
rollback 手順	問題発生時の巻き戻し手順	git revert / DB バックアップ復元
承認フロー	重要操作の前に人間が確認	「実行してよいですか？[Y/N]」プロンプト
操作ログ	全操作の記録	ファイルへのログ出力

J-2. dry-run 実装テンプレート

import os
import logging

DRY_RUN = os.getenv("DRY_RUN", "true").lower() == "true"

def execute_action(action_name: str, target: str):
    """重要操作の実行（dry-run対応）"""
    if DRY_RUN:
        logging.info(f"[DRY-RUN] {action_name} → {target} （実際には実行しない）")
        return {"status": "dry-run", "action": action_name, "target": target}

    logging.info(f"[EXECUTE] {action_name} → {target}")
    # 実際の処理をここに書く
    result = _do_actual_action(action_name, target)
    logging.info(f"[COMPLETE] {action_name} → {target} : {result}")
    return result

J-3. ロールバック手順テンプレート

# ロールバック手順（問題発生時に実行）

# 1. 直前のコミットに戻す
git revert HEAD --no-edit

# 2. DBバックアップから復元（バックアップがある場合）
# [バックアップ復元コマンドをここに記載]

# 3. 動作確認
[テストコマンド]

# 4. ロールバック完了を報告
echo "ロールバック完了：$(date)"

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

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

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

K-1. テスト種別と実施タイミング

テスト種別	実施タイミング	合格基準
単体テスト	各関数・モジュール実装後	全テスト通過
統合テスト	複数モジュール結合後	全シナリオ通過
E2Eテスト	機能完成後	主要ユースケース全通過
dry-runテスト	本番移行前	エラーなし・ログ正常
受入テスト	本番移行前	成功条件を満たす
回帰テスト	変更後	既存機能が壊れていない

K-2. E2Eシナリオテンプレート

シナリオ名：[シナリオ名]
前提条件：[テスト開始前の状態]
手順：
  1. [操作1]
  2. [操作2]
  3. [操作3]
期待結果：[正常終了時の状態]
確認方法：[結果の確認方法]
異常系：[エラー時の期待動作]

K-3. 境界ケースチェックリスト

実装後に以下の境界ケースを必ずテストすること： - [ ] 入力が空（空文字・空リスト・None）の場合 - [ ] 入力が最大値・最小値の場合 - [ ] 外部APIがタイムアウトした場合 - [ ] 外部APIがエラーを返した場合 - [ ] ネットワーク接続が切れた場合 - [ ] ファイルが存在しない場合 - [ ] 権限がない場合 - [ ] 同じ処理を2回実行した場合（冪等性）

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

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

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

L-1. ハーネスディレクトリ構造

~/claude-harness/
├── MASTER_CLAUDE.md          ← このファイル（常に最新版を保持）
├── START_PROMPT.md           ← 起動プロンプト（別ファイル参照）
├── templates/
│   ├── CLAUDE.md.template    ← プロジェクト用テンプレート
│   ├── SRS.md.template       ← 要件定義書テンプレート
│   ├── SDD.md.template       ← 設計記述テンプレート
│   ├── TP.md.template        ← テスト計画テンプレート
│   └── progress.md.template  ← 進捗管理テンプレート
├── knowledge/
│   ├── lessons_learned.md    ← 過去プロジェクトの学び
│   ├── common_pitfalls.md    ← よくある失敗パターン
│   └── reusable_patterns.md  ← 再利用可能なコードパターン
└── projects/
    └── [プロジェクト名]/
        └── retrospective.md  ← 振り返り記録

L-2. 新プロジェクト開始時の手順

# 1. ハーネスからテンプレートをコピー
cp ~/claude-harness/MASTER_CLAUDE.md ./CLAUDE.md

# 2. CLAUDE.md の PART A（プロジェクト情報）を書き換える

# 3. progress.md を初期化
cp ~/claude-harness/templates/progress.md.template ./progress.md

# 4. Claude Code を起動して START_PROMPT.md の内容を貼り付ける

L-3. プロジェクト完了後の知識蓄積手順

プロジェクト完了後に以下をハーネスに記録してください：

1. lessons_learned.md に追記：
   プロジェクト名：[名前]
   うまくいったこと：[内容]
   失敗したこと：[内容]
   次回に活かすこと：[内容]

2. common_pitfalls.md に追記（失敗パターンがあれば）：
   パターン名：[名前]
   症状：[どんな問題が起きたか]
   原因：[なぜ起きたか]
   対策：[次回どうするか]

3. reusable_patterns.md に追記（再利用可能なコードがあれば）：
   パターン名：[名前]
   用途：[何に使えるか]
   コード：[コード]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PART M：変更履歴（Changelog）

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

バージョン	日付	変更内容
v3.0	2026-05-24	全体系を1ファイルに集約（MASTER_CLAUDE.md）
v2.0	2026-05-23	世界基準版に更新（スペックドリフト防止・セッション管理・スペック検証追加）
v1.0	2026-05-22	初版作成

作成：Manus AI | 非エンジニア向け Claude Code 要件定義自動化体系 v3.0

MASTER_CLAUDE.md v3.0 — 非エンジニア向けClaude Code完全体系

要約

要点

MASTER_CLAUDE.md — 非エンジニア向け Claude Code 完全体系

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

使い方：このファイルをプロジェクトルートに CLAUDE.md という名前でコピーして使う

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

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

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

A-1. プロジェクト概要

A-2. 技術スタック

A-3. 重要なコマンド

A-4. 現在のフェーズ

A-5. 対応ドキュメント（作成済みの場合はパスを記入）

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PART B：完了基準（Definition of Done）

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PART C：作業ルール（Working Rules）

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

C-1. 必須ルール（MUST）

C-2. スペックドリフト防止（Spec Drift Prevention）

C-3. 報告フォーマット

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PART D：絶対禁止事項（Constraints）

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

D-1. 絶対禁止（いかなる場合も実行しない）

D-2. 要注意（実行前に必ず確認する）

D-3. プロジェクト固有の禁止事項

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PART E：セッション管理（Session Management）

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

E-1. セッション開始時の確認手順（毎回必ず実行）

E-2. コンテキスト枯渇対策

E-3. セッション終了時の手順

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

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

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

F-1. 認証・認可

F-2. データ保護

F-3. 外部連携

F-4. 入力検証

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

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

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

G-1. 機能確認

G-2. 障害対策

G-3. 監視・ログ

G-4. データ

G-5. 段階的移行

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PART H：RYGゲート（進行可否判断）

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

H-1. 要件定義フェーズ完了ゲート

H-2. 設計フェーズ完了ゲート

H-3. 実装フェーズ完了ゲート

H-4. 本番移行ゲート

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PART I：スペック検証（定期確認）

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PART J：ハーネス設計（Harness Design）

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

J-1. 必須ハーネス要素

J-2. dry-run 実装テンプレート

J-3. ロールバック手順テンプレート

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

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

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

K-1. テスト種別と実施タイミング

K-2. E2Eシナリオテンプレート

K-3. 境界ケースチェックリスト

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

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

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

L-1. ハーネスディレクトリ構造

L-2. 新プロジェクト開始時の手順

L-3. プロジェクト完了後の知識蓄積手順

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PART M：変更履歴（Changelog）

使い方：このファイルをプロジェクトルートに `CLAUDE.md` という名前でコピーして使う