🙄

Claude Code開発手法論 - 大規模システム継続開発のベストプラクティス

2025/06/15に公開

Claude

Vibe Coding

記事投稿コンテスト「TypeScriptでやってみた挑戦・学び・工夫」

claudcode

tech

🎯 概要

このドキュメントは、Claude Codeの特性と制約を活用した効率的な大規模システム開発手法論です。実際のプロジェクトを通じて確立された実証済みの方法論を体系化し、誰でも適用できるベストプラクティスとして整理しています。

🔍 Claude Code特有の制約と対策

1. コンテキスト制約（文字数制限）

制約の影響:

大規模ファイルの一括読み込み不可
長時間セッションでのコンテキスト継承困難
複数ファイル同時参照の限界

対策手法:

✅ **効果的なアプローチ**
- 実装プロンプトを段階的に分割（機能別・モジュール別）
- 重要情報の集約ドキュメント作成
- 継承用サマリーの定期作成
- 小さなファイル単位での作業分割

❌ **避けるべきアプローチ**
- 単一の巨大プロンプトファイル
- 全機能を一度に説明する試み
- 詳細すぎる実装手順の羅列

2. セッション継続性制約

制約の影響:

セッション間でのコンテキスト消失
前回作業内容の把握困難
実装状況の確認作業が必要

対策手法:

# セッション開始時の状況確認パターン
git log --oneline -5  # 直近のコミット確認
git status           # 現在の変更状況
npm run build        # ビルド状態確認（プロジェクトに応じてビルドコマンドを調整）
find . -name "*.md" -exec grep -l "TODO\|FIXME\|進捗" {} \;  # ドキュメント状況

📚 推奨ドキュメント体系

1. 階層化されたプロンプト設計

PROJECT_IMPLEMENTATION_GUIDE.md          # メインプロンプト（概要・現状）
├── docs/MODULE_A_IMPLEMENTATION.md      # モジュール別詳細手順
├── docs/MODULE_B_IMPLEMENTATION.md
├── docs/MODULE_C_IMPLEMENTATION.md
├── docs/INTEGRATION_GUIDE.md            # モジュール間連携
├── docs/UI_COMPONENT_GUIDE.md           # UI/UX実装
└── docs/DEPLOYMENT_GUIDE.md             # デプロイ・運用

メインプロンプトの推奨構成要素:

1. 現在の進捗状況（完了モジュール・残タスク）
2. 既存システム完全把握（重複実装防止）
3. 絶対厳守事項（システム破壊防止）
4. 次の実装ステップ（具体的指示）
5. 緊急時対応手順

2. 知識継承ドキュメント

docs/DEVELOPMENT_KNOWLEDGE.md             # 躓きポイント・解決策
docs/ARCHITECTURE_OVERVIEW.md            # 全体アーキテクチャ
docs/CODING_STANDARDS.md                 # コーディング規約
docs/TROUBLESHOOTING.md                  # よくある問題と解決法

3. データ・設定管理

scripts/setup-environment.js             # 環境セットアップ
scripts/seed-data.js                     # テストデータ投入
config/development.json                  # 開発環境設定
data/sample-data.json                    # サンプルデータ

🔄 開発プロセス・フロー

ステップ 1: セッション開始・状況把握

# 1. 基本状況確認
git log --oneline -3
git status
[ビルドコマンド]  # npm run build, yarn build, make build等

# 2. ドキュメント確認
cat PROJECT_IMPLEMENTATION_GUIDE.md | head -50

# 3. システム状況確認（例：データベース、API、サービス等）
# データベース使用の場合
[DB接続確認コマンド]
# API使用の場合  
curl -X GET "http://localhost:[PORT]/api/health"

ステップ 2: タスク計画・優先順位決定

TodoWrite活用パターン:

// 複雑なタスクは必ずTodoWriteで計画
{
  "todos": [
    {
      "content": "[新機能名]実装",
      "status": "pending",
      "priority": "high",
      "id": "module_01"
    },
    {
      "content": "[API/エンドポイント]作成",
      "status": "pending", 
      "priority": "high",
      "id": "module_02"
    }
  ]
}

ステップ 3: 段階的実装

安全な実装パターン:

# 1. 新規ファイル作成（既存に影響なし）
[プロジェクト構造]/services/new-feature.[拡張子]

# 2. 新規APIエンドポイント追加（Webアプリケーションの場合）
[API階層]/new-endpoint.[拡張子]

# 3. 既存ファイルの拡張（破壊的変更回避）
# ❌ 既存関数の変更
# ✅ 新規関数の追加

# 4. UIコンポーネント追加（フロントエンドの場合）
[コンポーネント階層]/NewFeatureComponent.[拡張子]

ステップ 4: 検証・テスト

# 型チェック（TypeScriptの場合）
npx tsc --noEmit
# または言語固有のリンター
[linter/静的解析コマンド]

# ビルド確認
[ビルドコマンド]

# 機能動作確認
# API確認例
curl -X GET "http://localhost:[PORT]/api/new-endpoint"
# または言語・フレームワーク固有のテストコマンド

# 既存機能回帰テスト
[既存機能のテストコマンド]

ステップ 5: コミット・ドキュメント更新

コミットのタイミング:

# ✅ 適切なコミットタイミング
- 1つのモジュール・機能が完全に完了した時
- 新機能が動作確認できた時
- 既存機能に影響がないことを確認した時

# ❌ 避けるべきコミットタイミング
- 実装途中・動作未確認
- ビルドエラーが残っている
- 既存機能に影響する可能性がある

コミットメッセージパターン:

git commit -m "$(cat <<'EOF'
[モジュール名]完了: [実装した機能の概要]

- [具体的な実装内容1]
- [具体的な実装内容2]
- [検証結果・テスト結果]

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>
EOF
)"

🔧 継承・引き継ぎプロトコル

セッション引き継ぎチェックリスト

## 前任者への確認事項

### 1. 実装状況確認
- [ ] 最新のコミットハッシュ: `git log --oneline -1`
- [ ] 現在のモジュール進捗: 何が完了し、何が残っているか
- [ ] 既知の問題・制限事項はあるか

### 2. 技術的状況確認
- [ ] ビルドエラーの有無: `[ビルドコマンド]`
- [ ] 静的解析エラーの有無: `[リンター/型チェックコマンド]`
- [ ] テストデータの状況: システムの状態・内容

### 3. 次の作業内容確認
- [ ] 優先実装機能の明確化
- [ ] 使用すべきドキュメント・ファイルの指定
- [ ] 避けるべき作業・変更の明確化

新任者の作業開始プロトコル

# Step 1: 環境確認
pwd  # 作業ディレクトリ確認
git branch  # ブランチ確認
[ビルドコマンド]  # ビルド状態確認

# Step 2: 実装状況把握
cat PROJECT_IMPLEMENTATION_GUIDE.md | head -30
git log --oneline -5

# Step 3: システム状況確認
ls -la *.json  # 設定・データファイル確認
[システム状況確認コマンド]  # DBカウント、サービス状態等

# Step 4: 次タスク確認
# TodoReadツールで現在のタスク状況を確認

# Step 5: 作業開始
# 確認した内容に基づいて実装開始

🎯 効率的な Tool 活用パターン

1. 並行処理による高速化

// ✅ 効率的 - 複数ツールの並行実行
[
  Bash("git status"),
  Bash("[ビルドコマンド]"), 
  Read("/path/to/file1.[拡張子]"),
  Read("/path/to/file2.[拡張子]")
]

// ❌ 非効率 - 逐次実行
Bash("git status") → 結果待ち → Bash("[ビルドコマンド]") → 結果待ち...

2. Task tool の効果的活用

// 大規模検索・複数ファイル横断調査で使用
Task({
  description: "Find authentication logic",
  prompt: "プロジェクト全体から認証関連のコードを探して、どのファイルでどのような実装がされているかをまとめてください"
})

// 単一ファイルの読み取りでは使わない
// ❌ Task("Read specific file content")
// ✅ Read("/path/to/specific/file.[拡張子]")

3. 段階的な情報収集

// Phase 1: 全体把握
Glob("**/*.[主要拡張子]")  // ファイル構造把握

// Phase 2: 特定領域調査  
Grep("[検索キーワード]", {include: "*.[拡張子]"})  // 関連ファイル特定

// Phase 3: 詳細読み取り
[
  Read("/path/to/file1.[拡張子]"),
  Read("/path/to/file2.[拡張子]")
]  // 並行読み取り

📊 品質保証・チェックポイント

実装品質チェックリスト

### コード品質
- [ ] 静的解析エラー0件 (`[リンター/型チェックコマンド]`)
- [ ] 未定義型・危険な型使用なし
- [ ] 適切な型定義・インターフェース使用

### API/インターフェース品質  
- [ ] 適切なエラーハンドリング
- [ ] レスポンス形式の一貫性
- [ ] 入力値検証の実装

### データ層品質
- [ ] ORM/クエリビルダー使用（生SQL回避）
- [ ] 適切なリレーション定義
- [ ] データ整合性確保

### UI品質（フロントエンドの場合）
- [ ] レスポンシブ対応
- [ ] CSSフレームワーク準拠
- [ ] 既存デザインパターン準拠

システム影響範囲チェック

# 既存機能への影響確認
[既存機能テストコマンド1]
[既存機能テストコマンド2]
[既存機能テストコマンド3]

# 新機能動作確認
[新機能テストコマンド]

# パフォーマンス確認
time [重い処理のテストコマンド]  # 応答時間測定

🚨 よくある問題と対処法

1. セッションコンテキスト不足

症状: 「このファイルの内容がわからない」「前回の作業内容が不明」

対処法:

# 状況把握コマンド実行
git log --oneline -5
cat PROJECT_IMPLEMENTATION_GUIDE.md | head -30
find . -name "*.[拡張子]" -exec grep -l "[実装中の機能名]" {} \;

2. 実装重複・競合

症状: 「似たような機能が既に存在している」

対処法:

# 既存実装の調査
grep -r "[機能名]" [ソースディレクトリ]/
find . -name "*[機能名]*"

3. ビルド・コンパイルエラー解決

症状: 型エラー・ビルドエラー

対処法:

# エラー内容を正確に把握
[静的解析コマンド]

# 段階的修正
# 1. import/include文確認
# 2. 型定義確認  
# 3. 既存コードパターン参照

📈 成功指標・KPI

開発効率指標

### セッション効率
- セッション開始から実装開始まで: 目標 5分以内
- 1モジュール完了までの時間: 目標 2-3セッション
- コミット間隔: 目標 1-2時間に1回

### 品質指標  
- 静的解析エラー率: 目標 0%
- ビルド成功率: 目標 100%
- 既存機能影響率: 目標 0%

### 継承効率
- 引き継ぎ理解時間: 目標 10分以内
- 状況把握完了時間: 目標 15分以内

🎯 この手法論の適用範囲

効果的な対象プロジェクト

✅ **適用推奨**
- Webアプリケーション・APIサーバー
- デスクトップアプリケーション  
- 段階的機能追加が必要なシステム
- 複数人・長期間での開発
- レガシーシステムの拡張

✅ **特に効果的**
- 大規模なプロジェクト（100ファイル以上）
- 複雑なビジネスロジック
- 頻繁な仕様変更が発生する環境
- 型安全性が重要なシステム

適用困難な場合

❌ **適用非推奨**
- 小規模な単発プロジェクト（10ファイル未満）
- プロトタイプ・概念実証レベル
- 全面的な作り直しが必要なシステム
- リアルタイム性が極めて重要なシステム

🚀 今後の発展・改善案

手法論の進化ポイント

### Version 2.0 構想
1. **AI支援の拡張**
   - 自動テストケース生成
   - コード品質自動チェック
   - 最適な実装パターン提案

2. **ドキュメント自動化**
   - コミット内容からの自動ドキュメント更新
   - API仕様書の自動生成
   - アーキテクチャ図の自動更新

3. **品質保証の強化** 
   - 自動回帰テスト
   - パフォーマンス監視
   - セキュリティチェック自動化

4. **言語・フレームワーク対応拡張**
   - Python/Django, FastAPI対応
   - Java/Spring Boot対応
   - Go/Gin対応
   - その他モダンフレームワーク対応

📝 技術スタック別の適用例

Web アプリケーション

**Next.js + TypeScript**
- ビルドコマンド: `npm run build`
- 型チェック: `npx tsc --noEmit`
- API テスト: `curl http://localhost:3000/api/...`

**Django + Python**  
- ビルドコマンド: `python manage.py check`
- 型チェック: `mypy .`
- API テスト: `curl http://localhost:8000/api/...`

**Spring Boot + Java**
- ビルドコマンド: `./mvnw compile`
- 型チェック: `./mvnw compile`
- API テスト: `curl http://localhost:8080/api/...`

デスクトップアプリケーション

**Electron + TypeScript**
- ビルドコマンド: `npm run build`
- 型チェック: `npx tsc --noEmit`

**Tauri + Rust**
- ビルドコマンド: `cargo tauri build`
- 型チェック: `cargo check`

📝 まとめ

この手法論は、Claude Codeの制約を逆手に取った効率的開発アプローチです。実際のプロジェクトを通じて実証された内容であり、様々な技術スタック・プロジェクト規模に適用可能です。

核心原則:

段階的・安全優先 - 既存システムを壊さない
継承性重視 - 次の開発者が理解しやすい
制約活用 - Claude Codeの特性を最大限活用
実証主義 - 実際の開発で効果が確認された手法のみ採用
汎用性 - 特定技術に依存しない普遍的なアプローチ

この手法論に従うことで、Claude Codeを使った大規模システム開発の成功確率を大幅に向上させることができます。

🚀 実装開始チェックリスト

このベストプラクティスを適用して開発を開始する前に、以下のチェックリストを確認してください。

必須ドキュメントの確認

以下のファイルが存在するかチェックしてください：

# メインガイドドキュメント
[ ] PROJECT_IMPLEMENTATION_GUIDE.md

# アーキテクチャ・知識ドキュメント  
[ ] docs/ARCHITECTURE_OVERVIEW.md
[ ] docs/DEVELOPMENT_KNOWLEDGE.md
[ ] docs/CODING_STANDARDS.md
[ ] docs/TROUBLESHOOTING.md

# モジュール別実装ガイド
[ ] docs/[MODULE_A]_IMPLEMENTATION.md
[ ] docs/[MODULE_B]_IMPLEMENTATION.md
# (プロジェクトの主要モジュール分だけ)

# セットアップ・データ
[ ] scripts/setup-environment.[拡張子]
[ ] config/development.json (または適切な設定ファイル)

既存ドキュメントがある場合

既に上記ドキュメントが存在する場合：

内容確認: ドキュメントが最新の状態か確認
ユーザー承認: 「既存ドキュメントを確認しました。このまま実装作業を開始してよろしいですか？」
状況把握: 現在の進捗状況を把握してから作業開始

ドキュメントがない場合のセットアップ

重要: 必須ドキュメントが不足している場合は、以下の手順で作成を開始します

📋 初回セットアップガイド（ドキュメント未整備の場合）

このプロジェクトでClaude Code開発を効率的に進めるため、必要なドキュメント群を作成しましょう。

ステップ 1: プロジェクト情報の収集

まず、以下の情報を教えてください：

### プロジェクト基本情報
- **プロジェクト名**: 
- **技術スタック**: (例: Next.js + TypeScript, Django + Python, Spring Boot + Java等)
- **プロジェクト規模**: (ファイル数の概算、開発期間)
- **主要機能モジュール**: (3-5個程度の主要な機能群)

### 現在の状況
- **開発段階**: (新規開発 / 機能追加 / リファクタリング / バグ修正)
- **既存コードベース**: (あり / なし)
- **チーム体制**: (個人開発 / チーム開発)
- **継続開発の予定**: (あり / なし)

### 技術詳細
- **ビルドコマンド**: (例: npm run build, mvn compile等)
- **テストコマンド**: (例: npm test, pytest等) 
- **リンター/型チェック**: (例: tsc --noEmit, mypy等)
- **主要ディレクトリ構造**: (src/, app/, components/等)

ステップ 2: ドキュメント生成計画

情報を確認後、以下のドキュメントを順次作成します：

PROJECT_IMPLEMENTATION_GUIDE.md - メインガイド（最優先）
docs/ARCHITECTURE_OVERVIEW.md - アーキテクチャ概要
docs/CODING_STANDARDS.md - コーディング規約
モジュール別実装ガイド - 各機能の詳細手順
セットアップスクリプト - 環境構築自動化

ステップ 3: 作業開始

ドキュメント作成完了後、実際の実装作業を開始します。

🎬 このドキュメントの使い方

開発開始時の手順

このドキュメント全体を確認
上記チェックリストでドキュメント状況確認
ドキュメントが揃っている場合: 直接実装開始
ドキュメントが不足している場合: セットアップガイドに従ってドキュメント作成から開始

継続開発時の手順

セッション開始時: 「🔄 開発プロセス・フロー」の手順に従って状況把握
実装作業: 「🎯 効率的な Tool 活用パターン」を参考に効率的に実装
品質確認: 「📊 品質保証・チェックポイント」で品質確保
セッション終了時: 適切なコミットと次回への引き継ぎ情報更新

トラブル発生時

「🚨 よくある問題と対処法」を確認
継承プロトコルに従って状況整理
必要に応じてドキュメント更新

🚀 自動セットアップ・実行プロトコル

以下のコマンドを自動実行して、プロジェクトの状況を把握し適切なアクションを決定します：

Phase 1: プロジェクト状況の自動調査

# 1. 基本情報収集
pwd
git status 2>/dev/null || echo "Git未初期化"
ls -la

# 2. 必須ドキュメント存在確認
echo "=== ドキュメント状況 ==="
ls -la PROJECT_IMPLEMENTATION_GUIDE.md 2>/dev/null && echo "✅ メインガイド存在" || echo "❌ メインガイド不在"
ls -la docs/ 2>/dev/null && echo "✅ docsディレクトリ存在" || echo "❌ docsディレクトリ不在"
find . -name "*IMPLEMENTATION*.md" -o -name "*GUIDE*.md" | head -5

# 3. 技術スタック推定
echo "=== 技術スタック推定 ==="
ls package.json 2>/dev/null && echo "Node.js系" || echo ""
ls requirements.txt 2>/dev/null && echo "Python系" || echo ""
ls pom.xml 2>/dev/null && echo "Java/Maven系" || echo ""
ls Cargo.toml 2>/dev/null && echo "Rust系" || echo ""
ls go.mod 2>/dev/null && echo "Go系" || echo ""

# 4. プロジェクト規模推定
echo "=== プロジェクト規模 ==="
find . -name "*.ts" -o -name "*.js" -o -name "*.py" -o -name "*.java" -o -name "*.rs" -o -name "*.go" | wc -l

Phase 2: 自動判定・アクション決定

// 上記の調査結果に基づいて自動的に以下を判定・実行：

if (メインガイドドキュメント存在) {
  // 既存プロジェクト継続開発モード
  console.log("📋 既存ドキュメント確認済み - 継続開発モードで開始");
  
  // 現在の進捗状況確認
  git log --oneline -5
  
  // 最新の実装状況把握
  Read("PROJECT_IMPLEMENTATION_GUIDE.md") 
  
  // 作業開始準備完了
  console.log("🎯 実装作業開始準備完了");
  
} else {
  // 初回セットアップモード
  console.log("🔧 初回セットアップモード - ドキュメント作成から開始");
  
  // セットアップガイドに従ってドキュメント作成開始
  console.log("📝 PROJECT_IMPLEMENTATION_GUIDE.md作成開始");
}

Phase 3: 実行判定・アクション決定

パターンA: 継続開発（ドキュメント存在）

# 状況把握・作業継続準備
echo "📋 継続開発モード - 既存ドキュメント確認済み"
[ビルドコマンド実行]
[状況確認コマンド実行]
git log --oneline -5

# ✅ 確認プロセス
echo "🎯 実装作業開始準備完了"
echo "現在の状況を把握しました。実装作業を開始してもよろしいですか？"
echo "作業内容: [現在の進捗に基づいた次のステップを提示]"

パターンB: 初回セットアップ（ドキュメント不在）

echo "🔧 初回セットアップモード - プロジェクト基盤構築支援開始"

# 🎯 包括的アシストプログラム開始
echo "📋 以下のプロセスでプロジェクトを整備します："
echo "1. 要件定義・目標設定アシスト"
echo "2. アーキテクチャ設計支援"  
echo "3. フェーズ分割・タスク計画"
echo "4. 実装ガイドドキュメント作成"
echo "5. 開発環境セットアップ"

# ✅ 確認プロセス
echo "🤝 プロジェクト基盤構築アシストを開始してもよろしいですか？"
echo "※要件定義から一緒に進めて、効率的な開発基盤を整備します"

🤝 プロジェクト基盤構築アシストプログラム

ドキュメントが不在の場合に実行される包括的な支援プロセス:

ステップ 1: 要件定義・目標設定アシスト

## 一緒に整理する項目

### プロジェクト概要
- 何を作りたいのか？（1-2文での簡潔な説明）
- 誰が使うのか？（ターゲットユーザー）
- なぜ作るのか？（解決したい課題）

### 機能要件
- 必須機能（MVP: Minimum Viable Product）
- 追加したい機能（優先度付き）
- 将来的な拡張予定

### 技術的要件
- 希望する技術スタック（理由も含めて）
- パフォーマンス要件
- セキュリティ要件
- 運用・保守要件

### プロジェクト制約
- 開発期間
- チーム体制
- 予算・リソース制約

ステップ 2: アーキテクチャ設計支援

## 設計支援内容

### システム構成
- フロントエンド/バックエンド分離
- データベース設計
- API設計方針
- 外部連携仕様

### 技術選定理由
- 各技術の選定根拠
- 代替技術との比較
- 学習コスト・開発効率の考慮

### ディレクトリ構造
- プロジェクトの標準的な構造提案
- 拡張性を考慮した設計
- 保守性の高い構成

ステップ 3: フェーズ分割・開発計画

## 段階的開発計画作成

### フェーズ分割方針
- MVP（最小機能）から段階的拡張
- 各フェーズの目標・成果物明確化
- リスク・依存関係の考慮

### 具体的フェーズ設計
- Phase 1: 基盤・コア機能
- Phase 2: 主要機能実装  
- Phase 3: 拡張機能・改善
- Phase 4+: 追加機能・最適化

### タスク詳細化
- 各フェーズのタスクブレイクダウン
- 見積もり・優先度設定
- 前提条件・完了条件の明確化

ステップ 4: 実装ガイド作成

## ドキュメント群自動生成

### 作成ドキュメント
- PROJECT_IMPLEMENTATION_GUIDE.md
- docs/ARCHITECTURE_OVERVIEW.md  
- docs/PHASE_[N]_[FEATURE_NAME].md（各フェーズ）
- docs/CODING_STANDARDS.md
- docs/DEVELOPMENT_KNOWLEDGE.md

### セットアップ自動化
- 環境構築スクリプト
- データベース初期化
- 設定ファイル雛形
- 開発ツール設定

ステップ 5: 実装開始準備

## 開発開始前最終確認

### 環境確認
- 開発環境構築完了
- 必要ツール・ライブラリ導入
- ビルド・テスト環境動作確認

### ドキュメント完成確認  
- 全必要ドキュメント作成完了
- 実装手順明確化
- トラブルシューティング準備

### 実装計画確定
- 次のタスク明確化
- 作業時間見積もり
- 成果物・完了条件確認

🎯 自動実行プロトコル

このドキュメントがプロンプトとして使用された場合の実行手順:

1. 調査フェーズ（自動実行）

# Phase 1の調査コマンドを全て自動実行
# - ディレクトリ構造確認
# - 技術スタック推定  
# - ドキュメント存在確認
# - プロジェクト規模推定

2. 判定フェーズ（自動実行）

// 調査結果に基づく自動判定
if (必須ドキュメント存在) {
  mode = "継続開発"
  nextAction = "実装作業継続"
} else {
  mode = "初回セットアップ"  
  nextAction = "プロジェクト基盤構築アシスト"
}

3. 確認フェーズ（ユーザー確認必須）

## 📋 状況報告・開始確認

**[調査結果サマリー表示]**
- モード: [継続開発 | 初回セットアップ]
- 技術スタック: [推定結果]
- プロジェクト規模: [ファイル数等]

**[提案する作業内容]**
- 継続開発の場合: 次の実装ステップ
- 初回セットアップの場合: アシストプログラム内容

**✅ 開始確認**
上記の内容で作業を開始してもよろしいですか？

4. 実行フェーズ

# ユーザー確認後に実行
# - 継続開発: 実装作業開始
# - 初回セットアップ: アシストプログラム開始

🚀 実行指示

プロンプト実行時は以下の順序で自動実行：

調査・判定フェーズ完全自動化（質問なし）
状況報告・提案内容明示
開始確認（必須）
確認後に適切なアクション実行

このプロトコルにより、どのような状況でも適切なサポートを提供し、効率的な開発を開始できます。

最終更新: 2025-06-15
適用技術スタック: Web・デスクトップアプリケーション全般
実証済み規模: 小規模（10ファイル）〜大規模（1000ファイル以上）
推奨プロジェクト期間: 1週間〜数ヶ月の継続開発

🎯 概要

🔍 Claude Code特有の制約と対策

1. コンテキスト制約（文字数制限）

制約の影響:

対策手法:

2. セッション継続性制約

制約の影響:

対策手法:

📚 推奨ドキュメント体系

1. 階層化されたプロンプト設計

メインプロンプトの推奨構成要素:

2. 知識継承ドキュメント

3. データ・設定管理

🔄 開発プロセス・フロー

ステップ 1: セッション開始・状況把握

ステップ 2: タスク計画・優先順位決定

TodoWrite活用パターン:

ステップ 3: 段階的実装

安全な実装パターン:

ステップ 4: 検証・テスト

ステップ 5: コミット・ドキュメント更新

コミットのタイミング:

コミットメッセージパターン:

🔧 継承・引き継ぎプロトコル

セッション引き継ぎチェックリスト

新任者の作業開始プロトコル

🎯 効率的な Tool 活用パターン

1. 並行処理による高速化

2. Task tool の効果的活用

3. 段階的な情報収集

📊 品質保証・チェックポイント

実装品質チェックリスト

システム影響範囲チェック

🚨 よくある問題と対処法

1. セッションコンテキスト不足

2. 実装重複・競合

3. ビルド・コンパイルエラー解決

📈 成功指標・KPI

開発効率指標

🎯 この手法論の適用範囲

効果的な対象プロジェクト

適用困難な場合

🚀 今後の発展・改善案

手法論の進化ポイント

📝 技術スタック別の適用例

Web アプリケーション

デスクトップアプリケーション

📝 まとめ

🚀 実装開始チェックリスト

必須ドキュメントの確認

既存ドキュメントがある場合

ドキュメントがない場合のセットアップ

📋 初回セットアップガイド（ドキュメント未整備の場合）

ステップ 1: プロジェクト情報の収集

ステップ 2: ドキュメント生成計画

ステップ 3: 作業開始

🎬 このドキュメントの使い方

開発開始時の手順

継続開発時の手順

トラブル発生時

🚀 自動セットアップ・実行プロトコル

Phase 1: プロジェクト状況の自動調査

Phase 2: 自動判定・アクション決定

Phase 3: 実行判定・アクション決定

パターンA: 継続開発（ドキュメント存在）

パターンB: 初回セットアップ（ドキュメント不在）

🤝 プロジェクト基盤構築アシストプログラム

ステップ 1: 要件定義・目標設定アシスト

ステップ 2: アーキテクチャ設計支援

ステップ 3: フェーズ分割・開発計画

ステップ 4: 実装ガイド作成

ステップ 5: 実装開始準備

🎯 自動実行プロトコル

1. 調査フェーズ（自動実行）

2. 判定フェーズ（自動実行）

3. 確認フェーズ（ユーザー確認必須）

4. 実行フェーズ

🚀 実行指示

Discussion