marketing-shibata50/github-research-tool
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

feat: 大幅にAI並列開発ワークフローガイドを充実化

Browse source 
- Phase 6とPhase 7の詳細な解説を追加
- 各時間帯での思考プロセスと理由を明記
- ドキュメント生成の重要性と手順を詳述
- 最終チェックとリリースプロセスの完全ガイド
- ユーザーが全過程をイメージできる網羅的な内容に進化

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

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
marketing-shibata50 2025-07-20 22:41:53 +09:00
parent a299881e12
commit facf3a2222
1 changed files with 659 additions and 91 deletions
Download patch file Download diff file Expand all files Collapse all files

750
workflow/ai-parallel-workflow.md
View file

@ -8,19 +8,36 @@ description: "複数AIを使って実際にWebアプリを1日で開発する具
複数のAI（Claude、GPT-4、GitHub Copilot、Cursor等）を使って、実際にWebアプリケーションを超高速で開発する具体的な手順を解説します。 複数のAI（Claude、GPT-4、GitHub Copilot、Cursor等）を使って、実際にWebアプリケーションを超高速で開発する具体的な手順を解説します。
## 💡 このガイドの読み方
このガイドでは、**「なぜそのタイミングでその作業をするのか」**を重点的に説明します。各セクションで以下の情報を提供します：
- 🎯 **目的**: なぜ今この作業をするのか
- 🤔 **思考プロセス**: 何を考えて判断しているか
- ✅ **期待する結果**: この作業で何が得られるか
- ⚠️ **注意点**: 避けるべき落とし穴
--- ---
## 🎯 プロジェクト例：タスク管理アプリを1日で作る ## 🎯 プロジェクト例：タスク管理アプリを1日で作る
### なぜタスク管理アプリなのか？
タスク管理アプリは、AI駆動開発の**理想的な練習題**です。理由：
1. **機能が明確に分離できる** - 認証、CRUD、UIなどが独立
2. **一般的なパターンが使える** - AIが学習済みのパターンを活用可能
3. **結果がすぐに確認できる** - 視覚的に動作を検証可能
### 完成イメージ ### 完成イメージ
``` ```
📱 タスク管理アプリ "TaskFlow" 📱 タスク管理アプリ "TaskFlow"
├── 認証機能（ログイン/登録） ├── 認証機能（ログイン/登録） ← Claudeが担当（UI/UXが得意）
├── タスク CRUD 機能 ├── タスク CRUD 機能 ← GPT-4が担当（ロジックが得意）
├── カテゴリ管理 ├── カテゴリ管理 ← 複数AIで分担
├── ダッシュボード ├── ダッシュボード ← Claudeがデザイン
├── リアルタイム同期 ├── リアルタイム同期 ← GPT-4がWebSocket実装
└── レスポンシブデザイン └── レスポンシブデザイン ← ClaudeがCSS最適化
``` ```
--- ---
@ -29,41 +46,78 @@ description: "複数AIを使って実際にWebアプリを1日で開発する具
### 8:00-8:30 プロジェクトセットアップ ### 8:00-8:30 プロジェクトセットアップ
#### 🎯 この30分でやることの意味
**なぜ最初にセットアップに時間をかけるのか？**
「急がば回れ」の精神です。この30分の投資が、後の8時間を2-3時間に短縮します。理由：
1. **AIの混乱を防ぐ** - 明確な構造がないとAIがバラバラな出力をする
2. **並列作業の可視化** - 誰が何をしているか一目瞭然
3. **自動化の基盤** - CI/CDが最初から動くように準備
#### 1. GitHub リポジトリ作成 #### 1. GitHub リポジトリ作成
**🤔 思考プロセス**：「どんなリポジトリ構成がAIにとって理解しやすいか？」
```bash ```bash
gh repo create taskflow-app --public --clone gh repo create taskflow-app --public --clone
cd taskflow-app cd taskflow-app
``` ```
**✅ このコマンドで起きること**：
- GitHub上に空のリポジトリが作成される
- ローカルにクローンされる
- Gitの初期設定が完了
**⚠️ 注意点**：`--public`を選んだ理由は、GitHub Actionsの無料枠を最大限活用するため
#### 2. Project ボード設定 #### 2. Project ボード設定
**🤔 思考プロセス**：「AIの作業状態をどう管理するか？」
```yaml ```yaml
# GitHub Projects で作成 # GitHub Projects で作成
カンバンボード: カンバンボード:
├── 📋 Backlog ├── 📋 Backlog # 全タスクの保管場所
├── 🤖 AI作業中 ├── 🤖 AI作業中 # AIが今取り組んでいるタスク
├── 👀 レビュー ├── 👀 レビュー # 人間の確認待ち
├── ✅ 完了 ├── ✅ 完了 # 統合済み・テスト済み
└── 🚀 デプロイ済み └── 🚀 デプロイ済み # 本番環境に反映済み
``` ```
**✅ この設定の効果**：
- 複数AIの作業が衝突しない
- 進捗がリアルタイムで把握できる
- ボトルネックをすぐに発見できる
#### 3. Issue 一括作成 #### 3. Issue 一括作成
**🤔 思考プロセス**：「タスクをどう分割すればAIが最も効率的に働けるか？」
**なぜIssueを細かく分けるのか？**
1. **AIの得意分野を活かす** - 各AIに専門分野を割り当て
2. **依存関係を最小化** - 同時並行で作業可能に
3. **レビューを簡単に** - 小さな単位で確認できる
```bash ```bash
# スクリプトで一括作成 # スクリプトで一括作成
cat << 'EOF' > create-issues.sh cat << 'EOF' > create-issues.sh
#!/bin/bash #!/bin/bash
# フロントエンド関連 # フロントエンド関連（Claudeが担当予定 - UI/UXが得意）
gh issue create -t "認証UIコンポーネント作成" -b "ログイン/登録フォーム、バリデーション含む" -l "frontend,ai-task" gh issue create -t "認証UIコンポーネント作成" -b "ログイン/登録フォーム、バリデーション含む" -l "frontend,ai-task"
gh issue create -t "タスク一覧画面UI" -b "タスクの表示、フィルタ、ソート機能" -l "frontend,ai-task" gh issue create -t "タスク一覧画面UI" -b "タスクの表示、フィルタ、ソート機能" -l "frontend,ai-task"
gh issue create -t "タスク編集モーダル" -b "CRUD操作のUI" -l "frontend,ai-task" gh issue create -t "タスク編集モーダル" -b "CRUD操作のUI" -l "frontend,ai-task"
gh issue create -t "ダッシュボード画面" -b "統計情報、チャート表示" -l "frontend,ai-task" gh issue create -t "ダッシュボード画面" -b "統計情報、チャート表示" -l "frontend,ai-task"
# バックエンド関連 # バックエンド関連（GPT-4が担当予定 - ロジックが得意）
gh issue create -t "認証API実装" -b "JWT認証、ユーザー管理" -l "backend,ai-task" gh issue create -t "認証API実装" -b "JWT認証、ユーザー管理" -l "backend,ai-task"
gh issue create -t "タスクCRUD API" -b "RESTful API、バリデーション" -l "backend,ai-task" gh issue create -t "タスクCRUD API" -b "RESTful API、バリデーション" -l "backend,ai-task"
gh issue create -t "リアルタイム同期" -b "WebSocket実装" -l "backend,ai-task" gh issue create -t "リアルタイム同期" -b "WebSocket実装" -l "backend,ai-task"
# その他 # その他（専門AIで分担）
gh issue create -t "データベース設計" -b "PostgreSQL、Prismaスキーマ" -l "database,ai-task" gh issue create -t "データベース設計" -b "PostgreSQL、Prismaスキーマ" -l "database,ai-task"
gh issue create -t "テスト作成" -b "単体テスト、統合テスト" -l "test,ai-task" gh issue create -t "テスト作成" -b "単体テスト、統合テスト" -l "test,ai-task"
gh issue create -t "ドキュメント作成" -b "README、API仕様書" -l "docs,ai-task" gh issue create -t "ドキュメント作成" -b "README、API仕様書" -l "docs,ai-task"
@ -73,25 +127,68 @@ chmod +x create-issues.sh
./create-issues.sh ./create-issues.sh
``` ```
**✅ Issue作成後の状態**：
```
Projectsボード
├── Backlog: 10件 ← すべてのタスクが可視化
├── AI作業中: 0件 ← これからAIに割り当て
└── 完了: 0件 ← 進捗を追跡
```
#### 4. ブランチ戦略準備 #### 4. ブランチ戦略準備
**🤔 思考プロセス**：「複数AIの出力をどう管理するか？」
**なぜ各AI用にブランチを分けるのか？**
これが**AI駆動開発の核心**です。理由：
1. **コンフリクト回避** - 同じファイルを複数AIが編集しない
2. **履歴の明確化** - どのAIが何を生成したか追跡可能
3. **並列マージ** - 各AIの成果を独立して評価
```bash ```bash
# 基本ブランチ作成 # 基本ブランチ作成
git checkout -b ai/claude-frontend git checkout -b ai/claude-frontend # Claude用（UI担当）
git checkout -b ai/gpt4-backend git checkout -b ai/gpt4-backend # GPT-4用（API担当）
git checkout -b ai/copilot-database git checkout -b ai/copilot-database # Copilot用（DB担当）
git checkout -b ai/cursor-tests git checkout -b ai/cursor-tests # Cursor用（テスト担当）
git checkout main git checkout main # メインに戻る
```
**✅ この時点でのリポジトリ状態**：
```
main
├── ai/claude-frontend （空）
├── ai/gpt4-backend （空）
├── ai/copilot-database （空）
└── ai/cursor-tests （空）
→ 各AIが独立して作業できる準備が整った！
``` ```
--- ---
### 8:30-9:00 AI への指示準備 ### 8:30-9:00 AI への指示準備
#### 🎯 この30分が成功の鍵
**なぜ指示準備に30分もかけるのか？**
「プロンプトの質 = 出力の質」というAIの鉄則があります。この30分の投資が：
1. **再生成を避ける** - 曖昧な指示でのやり直しを防ぐ
2. **統合をスムーズに** - 共通インターフェースで結合が簡単
3. **品質を均一化** - すべてのAIが同じレベルで出力
#### 技術スタック定義 #### 技術スタック定義
**🤔 思考プロセス**：「AIが知っている・得意な技術は何か？」
```markdown ```markdown
## 技術スタック ## 技術スタック
- Frontend: React 18, TypeScript, Tailwind CSS, Zustand - Frontend: React 18, TypeScript, Tailwind CSS, Zustand
- Backend: Node.js, Express, TypeScript, Prisma - Backend: Node.js, Express, TypeScript, Prisma
- Database: PostgreSQL - Database: PostgreSQL
- Auth: JWT + bcrypt - Auth: JWT + bcrypt
- Real-time: Socket.io - Real-time: Socket.io
@ -99,47 +196,89 @@ git checkout main
- Deployment: Vercel (Frontend) + Railway (Backend) - Deployment: Vercel (Frontend) + Railway (Backend)
``` ```
**⚠️ 重要な選定理由**：
- **React/Express**: AIが最も多くの事例を学習している
- **TypeScript**: 型定義でAI間の整合性を保つ
- **Tailwind**: スタイリングの一貫性を簡単に維持
- **Prisma**: スキーマから型を自動生成
#### 共通インターフェース定義 #### 共通インターフェース定義
**🤔 思考プロセス**：「複数AIがバラバラな型を作らないようにするには？」
**これがAI並列開発の最重要ポイント！**
このファイルが「契約書」の役割を果たします。各AIはこの型定義に従うことで、統合時の問題を避けられます。
```typescript ```typescript
// shared/types.ts（全AIに共有） // shared/types.ts（全AIに共有）
export interface User { export interface User {
id: string; id: string; // UUID v4
email: string; email: string; // ユニーク
name: string; name: string; // 表示名
createdAt: Date; createdAt: Date; // タイムスタンプ
} }
export interface Task { export interface Task {
id: string; id: string; // UUID v4
title: string; title: string; // 必須、最大100文字
description?: string; description?: string;// オプション、最大500文字
completed: boolean; completed: boolean; // デフォルトfalse
categoryId?: string; categoryId?: string; // カテゴリへの参照
userId: string; userId: string; // 所有者
dueDate?: Date; dueDate?: Date; // 期限
createdAt: Date; createdAt: Date;
updatedAt: Date; updatedAt: Date; // 更新時に自動更新
} }
export interface Category { export interface Category {
id: string; id: string;
name: string; name: string; // ユニーク（ユーザー内）
color: string; color: string; // HEX形式 #RRGGBB
userId: string; userId: string;
} }
export interface ApiResponse<T> { export interface ApiResponse<T> {
success: boolean; success: boolean;
data?: T; data?: T; // 成功時のデータ
error?: string; error?: string; // エラーメッセージ
} }
``` ```
**✅ この定義の効果**：
- Claudeが作るUIとGPT-4が作るAPIが完全に一致
- データの受け渡しでエラーが起きない
- 後から修正が必要な箇所が減る
--- ---
### 9:00-10:30 Phase 1: 並列AI開発開始 ### 9:00-10:30 Phase 1: 並列AI開発開始
#### 🎯 この1.5時間がプロジェクトの核心
**今から起きること：**
4つのAIが**同時に異なる部分**を開発します。これが従来の開発との決定的な違いです。
```
従来: 開発者A → 開発者B → 開発者C（直列）
AI駆動: Claude + GPT-4 + Copilot + Cursor（並列）
```
**この時間帯のあなたの役割：**
1. 各AIにプロンプトを送信
2. 出力を監視（但し干渉しない）
3. 問題があれば迅速に修正指示
#### 🤖 Claude（フロントエンド担当） #### 🤖 Claude（フロントエンド担当）
**なぜClaudeにフロントエンドを任せるのか？**
Claudeは以下の点で優れています：
- UI/UXのパターン認識が得意
- Reactの最新プラクティスを理解
- アクセシビリティへの配慮
```markdown ```markdown
## プロンプト ## プロンプト
以下のIssue #1, #2, #3, #4 に基づいて、React + TypeScript + Tailwind CSSでフロントエンドを実装してください。 以下のIssue #1, #2, #3, #4 に基づいて、React + TypeScript + Tailwind CSSでフロントエンドを実装してください。
@ -164,16 +303,42 @@ frontend/
│ └── utils/ │ └── utils/
``` ```
**💡 実際の操作フロー：**
```bash ```bash
# Claudeの出力をブランチにコミット # 1. Claudeのブランチに移動
git checkout ai/claude-frontend git checkout ai/claude-frontend
# Claudeが生成したコードを貼り付け
# 2. Claudeが生成したコードをコピーペースト
# （通常は複数ファイルを一度に出力するので、テキストエディタで整理）
# 3. 生成されたコードを確認
git add frontend/ git add frontend/
git status # 変更ファイルを確認
# 4. コミット（Issue番号を含めることが重要）
git commit -m "feat: Claude-generated frontend implementation #1 #2 #3 #4" git commit -m "feat: Claude-generated frontend implementation #1 #2 #3 #4"
# 5. リモートにプッシュ
git push origin ai/claude-frontend git push origin ai/claude-frontend
``` ```
**✅ この時点でGitHub上に起きること：**
- ブランチが作成される
- Issue #1-4 がこのコミットと関連付けられる
- Projectsでタスクが「AI作業中」に移動（自動化設定済みの場合）
#### 🤖 GPT-4（バックエンド担当） #### 🤖 GPT-4（バックエンド担当）
**なぜGPT-4にバックエンドを任せるのか？**
GPT-4の強み：
- ロジックの構築が得意
- セキュリティベストプラクティスの理解
- エラーハンドリングの完全性
**重要：Claudeと同時に作業している！**
```markdown ```markdown
## プロンプト ## プロンプト
Issue #5, #6, #7 に基づいて、Express + TypeScript + Prismaでバックエンドを実装してください。 Issue #5, #6, #7 に基づいて、Express + TypeScript + Prismaでバックエンドを実装してください。
@ -247,12 +412,36 @@ git push origin ai/cursor-tests
### 10:30-11:00 Phase 2: 初回統合 ### 10:30-11:00 Phase 2: 初回統合
#### 🎯 この30分の重要性
**なぜ1.5時間で一度統合するのか？**
「早期発見、早期解決」の原則です。問題を放置すると：
1. **修正コストが増大** - 後になるほど修正が困難
2. **AIの軌道修正が難しい** - 間違った方向に進んでしまう
3. **チームの不安が増す** - 「本当にうまくいくのか？」
**このタイミングでのチェックポイント：**
- 各AIの出力が期待通りか
- インターフェースは一致しているか
- 大きな方向性のズレはないか
#### 並列PRの作成 #### 並列PRの作成
**🤔 思考プロセス**：「4つのPRをどう効率的にレビューするか？」
```bash ```bash
# 各ブランチからPR作成 # 各ブランチからPR作成（並列実行がポイント）
gh pr create --base main --head ai/claude-frontend \ gh pr create --base main --head ai/claude-frontend \
--title "feat: Frontend implementation by Claude" \ --title "feat: Frontend implementation by Claude" \
--body "Implements #1 #2 #3 #4" --body "Implements #1 #2 #3 #4
## AI情報
- AI: Claude 3
- 生成時間: 1.5時間
- ファイル数: 15ファイル
- コード行数: 約2,000行"
gh pr create --base main --head ai/gpt4-backend \ gh pr create --base main --head ai/gpt4-backend \
--title "feat: Backend API by GPT-4" \ --title "feat: Backend API by GPT-4" \
@ -292,15 +481,48 @@ jobs:
### 11:00-12:00 Phase 3: 統合とデバッグ ### 11:00-12:00 Phase 3: 統合とデバッグ
#### 🎯 この1時間がプロジェクトの質を決める
**今から何が起きるか：**
4つの独立したコードベースを1つに統合します。これは「4人の音楽家が別々に演奏したものを1つのオーケストラにする」ような作業です。
**予想される問題と対策：**
1. **パッケージの重複** → package.jsonの統合
2. **ポートの衝突** → 環境変数で管理
3. **スタイルの不一致** → Prettierで統一
#### 統合ブランチ作成 #### 統合ブランチ作成
**🤔 思考プロセス**：「マージ順序を間違えると地獄を見る」
```bash ```bash
# 重要：マージ順序には意味がある！
git checkout -b integration/sprint-1 git checkout -b integration/sprint-1
git merge ai/copilot-database # まずDBスキーマ
git merge ai/gpt4-backend # 次にバックエンド # 1. データベースから（基礎となる部分）
git merge ai/claude-frontend # フロントエンド git merge ai/copilot-database
git merge ai/cursor-tests # テスト # → schema.prismaが追加される
# 2. バックエンド（DBを使う部分）
git merge ai/gpt4-backend
# → APIが追加される（DBスキーマを参照）
# 3. フロントエンド（APIを使う部分）
git merge ai/claude-frontend
# → UIが追加される（APIエンドポイントを呼ぶ）
# 4. テスト（全体をテスト）
git merge ai/cursor-tests
# → テストが追加される
``` ```
**✅ 各マージ後の確認ポイント：**
- コンフリクトは発生したか？
- ファイル構造は正しいか？
- 依存関係は解決されているか？
#### コンフリクト解決（AIに依頼） #### コンフリクト解決（AIに依頼）
```markdown ```markdown
## プロンプト（Claude or GPT-4） ## プロンプト（Claude or GPT-4）
@ -338,63 +560,300 @@ npm run dev
### 13:00-14:30 Phase 4: UIブラッシュアップ ### 13:00-14:30 Phase 4: UIブラッシュアップ
#### 複数AIでUI改善 #### 🎯 この1.5時間で何が起きるか
```markdown
## Claude への追加指示
デザインを以下の点で改善してください：
1. ダークモード対応
2. アニメーション追加（Framer Motion）
3. アクセシビリティ向上
4. パフォーマンス最適化
## GPT-4 への追加指示 **なぜランチ後にUIブラッシュアップなのか？**
バックエンドに以下を追加：
1. レート制限 ランチタイムにテストが自動実行されている間、あなたの頭も休憩してリフレッシュ。この時間に：
2. キャッシング（Redis）
3. ロギング（Winston） 1. **新鮮な目でUIを見直す** - 朝作ったUIの問題点が見える
4. メトリクス収集 2. **ユーザビリティに集中** - 機能動作の確認後、使いやすさを追求
3. **差別化要素を追加** - 競合と差をつけるポリッシュを加える
**🤔 思考プロセス**：「ユーザーがストレスなく使えるUIとは？」
#### Claude への「仕上げ」指示
**なぜClaudeに仕上げを任せるのか？**
Claudeは午前中に基本UIを作ったので、コンテキストを理解している。加えて：
- ユーザビリティの感覚が優秀
- 一貫性のあるデザインを維持
- アクセシビリティへの配慮
```markdown
## Claude への詳細指示
午前中に作成していただいたUIを以下の観点でブラッシュアップしてください：
### 🎨 デザイン改善
1. **ダークモード対応**
- システム設定に自動追従
- 目に優しい配色設計
- ローカルストレージで設定保存
2. **マイクロアニメーション追加（Framer Motion）**
- ボタンホバー効果
- ページ遷移アニメーション
- ローディング状態の表現
- リスト項目の追加・削除時のアニメーション
3. **レスポンシブ最適化**
- タブレット表示の改善
- モバイルでのタッチ操作性向上
- 画面サイズに応じたコンポーネント調整
### ♿ アクセシビリティ強化
- ARIA属性の適切な設定
- キーボードナビゲーション
- スクリーンリーダー対応
- カラーコントラスト比の確保
期待する成果：
- ユーザーが「使いやすい！」と感じるUI
- 初心者でも迷わない直感的な操作
- プロダクションレベルの完成度
```
**✅ この指示の効果**：
- 具体的すぎず、Claudeの創造性を活かす
- 技術的制約を明確に指定
- 品質基準を共有
#### GPT-4 への「パフォーマンス」指示
**🤔 思考プロセス**：「本番運用に耐えられるバックエンドとは？」
午前中にGPT-4が作ったAPIは「動く」状態。今度は「本番で使える」レベルに引き上げます。
```markdown
## GPT-4 への詳細指示
午前中のAPI実装を本番運用レベルに引き上げてください：
### 🚀 パフォーマンス最適化
1. **レート制限（Rate Limiting）**
- express-rate-limit導入
- API別の制限設定
- DDoS攻撃対策
2. **キャッシング戦略（Redis）**
- ユーザー情報のセッションキャッシュ
- よく使われるタスクリストのキャッシュ
- TTL（有効期限）の適切な設定
3. **ログ・モニタリング（Winston）**
- 構造化ログ（JSON形式）
- エラーレベルの分類
- 本番/開発環境での出力調整
### 📊 メトリクス収集
- API応答時間測定
- エラー率の追跡
- アクティブユーザー数
- データベース接続数
重要：既存のAPI仕様は変更せず、内部実装のみ強化してください。
フロントエンドからの呼び出し方は一切変わらないようにお願いします。
```
**⚠️ 重要な制約**：
この指示で最も重要なのは「既存APIの破壊的変更を避ける」こと。午前中にClaudeが作ったフロントエンドが動き続ける必要があります。
#### 並行作業の監視
**🤔 あなたの役割**：
```bash
# 13:00 - 両AIに指示送信
# 13:15 - Claude進捗確認
git checkout ai/claude-frontend
git pull origin ai/claude-frontend
# → 新しいコミットがあるか確認
# 13:30 - GPT-4進捗確認
git checkout ai/gpt4-backend
git pull origin ai/gpt4-backend
# → パフォーマンス改善コミット確認
# 13:45 - ローカルテスト
npm run dev # フロントエンド
npm run dev:api # バックエンド
# → 新機能が動作するか確認
``` ```
#### デザインシステム統合 #### デザインシステム統合
**🤔 思考プロセス**：「複数AIが作ったUIを統一するには？」
Claudeが複数のコンポーネントを改善した時、一貫性を保つためのデザインシステムが重要。
```typescript ```typescript
// AIが生成したデザイントークン // src/styles/theme.ts（Claudeが生成予定）
const theme = { export const theme = {
colors: { colors: {
primary: { /* ... */ }, primary: {
secondary: { /* ... */ }, 50: '#f0f9ff',
500: '#3b82f6',
900: '#1e3a8a'
},
semantic: {
success: '#10b981',
warning: '#f59e0b',
error: '#ef4444',
info: '#06b6d4'
}
},
spacing: {
xs: '0.25rem',
sm: '0.5rem',
md: '1rem',
lg: '2rem'
}, },
animations: { animations: {
// Framer Motion variants duration: {
}, fast: '150ms',
normal: '250ms',
slow: '350ms'
},
easing: {
out: 'cubic-bezier(0.16, 1, 0.3, 1)',
in: 'cubic-bezier(0.7, 0, 0.84, 0)'
}
}
};
// Framer Motion variants
export const fadeIn = {
initial: { opacity: 0, y: 20 },
animate: { opacity: 1, y: 0 },
exit: { opacity: 0, y: -20 }
}; };
``` ```
**✅ この設計の効果**：
- すべてのコンポーネントが統一された見た目
- 後から色やサイズを一括変更可能
- チーム開発での一貫性保持
--- ---
### 14:30-16:00 Phase 5: 本番準備 ### 14:30-16:00 Phase 5: 本番準備
#### 環境変数設定 #### 🎯 この1.5時間が成功を左右する
**なぜ本番準備に1.5時間もかけるのか？**
「開発は9割完成、本番デプロイは1割」という感覚は大きな間違い。実際は：
1. **設定ミスでサービス停止** - よくある本番障害の原因
2. **セキュリティホール** - 環境変数の扱い方が重要
3. **スケーラビリティ** - 最初から本番を想定した設計
**🤔 思考プロセス**：「本番で恥をかかないために何を準備すべきか？」
この時間で「開発者として信頼される」レベルに到達します。
#### 環境変数戦略
**なぜ環境変数が重要なのか？**
環境変数は「アプリケーションの服」のようなもの。開発環境と本番環境で「着替える」ことで、同じコードが異なる環境で動作します。
```bash ```bash
# .env.example を各AIが生成 # .env.example（テンプレート）
DATABASE_URL= # データベース
JWT_SECRET= DATABASE_URL=postgresql://user:password@localhost:5432/taskflow_dev
REDIS_URL= DATABASE_URL_TEST=postgresql://user:password@localhost:5432/taskflow_test
SOCKET_PORT=
# 認証
JWT_SECRET=your-super-secret-key-here-minimum-32-characters
JWT_EXPIRES_IN=7d
BCRYPT_ROUNDS=12
# Redis（キャッシュ・セッション）
REDIS_URL=redis://localhost:6379
REDIS_PASSWORD=your-redis-password
# WebSocket
SOCKET_PORT=3001
SOCKET_CORS_ORIGIN=http://localhost:3000
# 外部サービス
SMTP_HOST=smtp.gmail.com
SMTP_PORT=587
SMTP_USER=your-email@gmail.com
SMTP_PASS=your-app-password
# 監視・ログ
LOG_LEVEL=info
SENTRY_DSN=https://your-sentry-dsn@sentry.io/project
# 本番環境フラグ
NODE_ENV=development
PORT=3000
``` ```
#### デプロイ設定 **✅ 各変数の意味と重要度**：
- **DATABASE_URL**: 🔴 必須 - データの保存先
- **JWT_SECRET**: 🔴 必須 - セキュリティの要
- **REDIS_URL**: 🟡 推奨 - パフォーマンス向上
- **SMTP_***: 🟢 オプション - メール通知用
#### デプロイ設定の深堀り
**🤔 思考プロセス**：「どのプラットフォームが最適か？」
```
フロントエンド: Vercel
↳ なぜ？Reactに最適化、CDN自動配置、ゼロ設定
バックエンド: Railway
↳ なぜ？PostgreSQL統合、環境変数管理、スケーリング
データベース: Railway PostgreSQL
↳ なぜ？自動バックアップ、接続プール、監視
```
##### Vercel設定の詳細解説
##### Vercel（フロントエンド）
```json ```json
// vercel.json // vercel.json
{ {
"buildCommand": "npm run build", "buildCommand": "npm run build",
"outputDirectory": "dist", "outputDirectory": "dist",
"framework": "react" "framework": "react",
"functions": {
"app/api/**/*.js": {
"runtime": "nodejs18.x"
}
},
"routes": [
{
"src": "/api/(.*)",
"dest": "/api/$1"
},
{
"src": "/(.*)",
"dest": "/index.html"
}
],
"env": {
"REACT_APP_API_URL": "@api_url"
},
"build": {
"env": {
"REACT_APP_VERSION": "@version"
}
}
} }
``` ```
##### Railway（バックエンド） **📝 この設定のポイント**：
- **SPAルーティング**: すべてのURLがindex.htmlに向かう
- **環境変数**: ビルド時とランタイムで使い分け
- **APIプロキシ**: CORS問題を回避
##### Railway設定の詳細解説
```yaml ```yaml
# railway.toml # railway.toml
[build] [build]
@ -404,36 +863,145 @@ SOCKET_PORT=
[deploy] [deploy]
startCommand = "npm start" startCommand = "npm start"
healthcheckPath = "/api/health" healthcheckPath = "/api/health"
healthcheckTimeout = 30
restartPolicyType = "ON_FAILURE"
restartPolicyMaxRetries = 3
[scaling]
minReplicas = 1
maxReplicas = 10
targetCPU = 80
targetMemory = 80
``` ```
#### CI/CD パイプライン **💡 なぜこの設定か？**：
- **ヘルスチェック**: アプリが生きているか監視
- **自動復旧**: 障害時に自動再起動
- **オートスケーリング**: アクセス増加に自動対応
#### GitHub Actions: デプロイパイプライン
**🤔 思考プロセス**：「プッシュからデプロイまで完全自動化」
```yaml ```yaml
name: Deploy Production name: Production Deploy
on: on:
push: push:
branches: [main] branches: [main]
release:
types: [published]
jobs: env:
deploy-frontend: NODE_VERSION: '18'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Deploy to Vercel
env:
VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }}
run: vercel --prod
deploy-backend: jobs:
# Step 1: 品質チェック
quality-check:
runs-on: ubuntu-latest runs-on: ubuntu-latest
steps: steps:
- uses: actions/checkout@v4 - uses: actions/checkout@v4
- name: Deploy to Railway
- name: Setup Node.js
uses: actions/setup-node@v3
with:
node-version: ${{ env.NODE_VERSION }}
cache: 'npm'
- name: Install dependencies
run: npm ci
- name: Run linting
run: npm run lint
- name: Run type checking
run: npm run type-check
- name: Run tests
run: npm run test:ci
env: env:
RAILWAY_TOKEN: ${{ secrets.RAILWAY_TOKEN }} CI: true
run: railway up
- name: Run E2E tests
run: npm run test:e2e
env:
DATABASE_URL: ${{ secrets.TEST_DATABASE_URL }}
# Step 2: セキュリティチェック
security-check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run security audit
run: npm audit --audit-level=moderate
- name: Check for vulnerabilities
uses: github/super-linter@v4
env:
DEFAULT_BRANCH: main
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
# Step 3: フロントエンドデプロイ
deploy-frontend:
needs: [quality-check, security-check]
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Deploy to Vercel
uses: amondnet/vercel-action@v25
with:
vercel-token: ${{ secrets.VERCEL_TOKEN }}
vercel-org-id: ${{ secrets.VERCEL_ORG_ID }}
vercel-project-id: ${{ secrets.VERCEL_PROJECT_ID }}
vercel-args: '--prod'
working-directory: ./frontend
# Step 4: バックエンドデプロイ
deploy-backend:
needs: [quality-check, security-check]
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Deploy to Railway
uses: bervProject/railway-deploy@v1.0.0
with:
railway_token: ${{ secrets.RAILWAY_TOKEN }}
service: 'taskflow-backend'
# Step 5: デプロイ後テスト
post-deploy-test:
needs: [deploy-frontend, deploy-backend]
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Wait for deployment
run: sleep 60
- name: Health check
run: |
curl -f https://taskflow-backend.railway.app/api/health
curl -f https://taskflow.vercel.app
- name: Notify team
uses: 8398a7/action-slack@v3
with:
status: ${{ job.status }}
text: 'TaskFlow has been deployed successfully! 🚀'
env:
SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK }}
if: always()
``` ```
**✅ このパイプラインの効果**：
- **品質保証**: テスト失敗時はデプロイ停止
- **セキュリティ**: 脆弱性発見時はアラート
- **並列処理**: フロントエンド・バックエンド同時デプロイ
- **監視**: デプロイ成功/失敗をチーム通知
--- ---
### 16:00-17:00 Phase 6: ドキュメント生成 ### 16:00-17:00 Phase 6: ドキュメント生成