🔍

AIネイティブ開発フロー

概要

Asana/Slack/GitHubと連携し、要件定義から実装・PRまでを自動化する開発フローです。

フェーズ一覧

フェーズ コマンド 概要
A. 要件定義 /requirement 情報収集 → requirement.md 生成
B. 設計 /design 設計書群 + タスク分解 生成
C. 構築 /build 実装 → ルールチェック → PR作成

フェーズ A: 要件定義 (/requirement)

実行コマンド

/requirement [Asanaタスク名またはURL]

フロー

A-1: 初期確認
├── 新規機能 or 既存機能の編集を確認
└── Asanaタスク情報の特定
    ↓
A-2: 並列情報取得
├── Asana MCP: タスク詳細、コメント
├── Slack MCP: 関連スレッド、議論履歴
└── GitHub MCP: 関連コード、既存実装
    ↓
A-3: ドキュメント生成
└── requirement.md を作成
    ↓
A-4: 確認ループ
└── エンジニア承認まで修正

出力物

doc_draft/requirement/
└── [Asana依頼名]/
    └── requirement.md

requirement.md 構成

  • 基本情報（Asanaタスク、種別、依頼者、担当者）
  • 背景・目的
  • 機能要件 / 非機能要件
  • 関連情報（既存コード、Slack議論）
  • 制約事項
  • 承認欄

フェーズ B: 設計 (/design)

実行コマンド

/design [Asana依頼名]

フロー

B-1: 設計開始
└── requirement.md を読み込み
    ↓
B-2: 設計書作成
├── 新規機能: テンプレートから新規作成
└── 追加機能: 既存設計書をコピーし差分修正
    ↓
B-3: 担当エンジニア確認
└── エンジニアがローカルで設計書を確認・修正
    ↓
B-4: タスク分解
└── 担当割り当て（ai-agent / エンジニア）
    ↓
B-5: 工数入力（Asana自動連携）
├── タスク分解で算出したエンジニア合計工数を確認
└── Asana MCP で「予定時間」に自動入力
    ↓
B-6: レビュアー選択
└── 設計書レビューを依頼する上長を選択
    ↓
B-7: PR作成
├── 設計書のPRをGitHubに作成
└── 選択した上長をレビュアーに指定
    ↓
B-8: Asana・Slackでレビュー依頼
├── Asanaタスクにコメント（PRリンク付き）
├── Slackに通知（スレッド形式）
└── Asanaセクション移動 → 設計書承認
    ↓
B-9: 設計レビュー
├── 上長がPR上でレビュー・コメント
├── 修正依頼 → 修正 → 再レビュー
└── 承認 → PRマージ
    ↓
B-10: 設計書承認（/approve-design）
├── 対象の設計書を特定
├── doc_draft/ → doc/ にファイル移動（git mv）
├── ファイル内の相対パスを更新
├── インデックス（README.md）を更新
├── Asanaセクションを「構築待ち」に移動
├── Asana/Slack通知
└── コミット & プッシュ

B-5: 工数入力（Asana自動連携）

タスク分解で算出したエンジニア合計工数を Asana MCP で「予定時間（Estimated time）」に自動入力:

  • フィールドGID: 1203561023086990（単位: 分）
工数（時間） 入力値（分）
0.5h 30
1h 60
2h 120
3h 180
4h 240
8h 480

B-6: レビュアー選択

設計書レビューを依頼する上長を選択:

名前 Asana GID GitHub Slack ID
平井 1210193551915917 thirai-classlab U07B6BQ8Y8Z
古谷圭吾 1209044134340755 classlab-ltd-fk U086CTXGF2R
棟安拓未 1207940793230770 t-muneyasu-classlab U07FNRT78HW

B-7: PR作成

設計書のPRをGitHubに作成し、選択した上長をレビュアーに指定:

gh pr create --title "[設計書] {Asana依頼名}" \
  --body "設計書のレビューをお願いします。" \
  --reviewer "{GitHubユーザー名}"

B-8: Asana・Slackでレビュー依頼

Step 内容
Step 1 Asanaタスクにコメント（PRリンク付き、メンションなし）
Step 2 AsanaコメントURLを取得
Step 3 Slackに通知（親メッセージ + スレッド返信でメンション）
Step 4 Asanaセクション移動 → 設計書承認

Slack通知

  • 通知先チャンネル: C07JMC480EA
  • 形式: スレッド形式（親メッセージ + スレッド返信）

親メッセージ:

{Asanaタスク名} の設計書PRを作成しました。

スレッド返信（メンション付き）:

@{上長}
{Asanaタスク名} - PRコメント: {AsanaコメントURL}
上記でPRを作成しました。

確認し、承認 or 却下を実施してください。

セクション移動

  • 移動先: 設計書承認
  • セクションGID: 1212857002747714

B-10: 設計書承認（/approve-design）

PRマージ後、/approve-design コマンドを実行:

Step 内容
D-1 対象の設計書を特定
D-2 移動対象ファイルを確認
D-3 doc_draft/ → doc/ にファイル移動（git mv）
D-4 ファイル内の相対パスを更新
D-5 インデックス（README.md）を更新
D-6 Asanaセクションを「構築待ち」に移動
D-7 Asanaにコメント追加
D-8 Slack通知
D-9 コミット & プッシュ

ディレクトリマッピング

移動元（doc_draft/） 移動先（doc/）
basic-design/[依頼名]/ domains/[依頼名]/
detailed-design/apex/ detailed-design/apex/
detailed-design/trigger/ detailed-design/trigger/
detailed-design/lwc/ detailed-design/lwc/
detailed-design/flow/ detailed-design/flow/

注意: doc_draft/requirement/ は移動対象外（参照用として残す）

自動連携まとめ

連携先 処理内容
Asana 予定時間入力、コメント追加、セクション移動
Slack スレッド形式で通知（メンション付き）
GitHub PR作成、レビュアー指定

出力物

既存のディレクトリ構造（doc_draft/STRUCTURE.md）に準拠:

doc_draft/
├── requirement/
│   └── [Asana依頼名]/
│       └── requirement.md           ← /requirement で生成済み
│
├── basic-design/
│   └── [Asana依頼名]/
│       ├── readme.md                ← 概要設計書（システム全体像、アーキテクチャ）
│       ├── feature/
│       │   └── 01_[機能名].md       ← 機能設計書（機能詳細、画面設計、API設計）
│       └── task-breakdown.md        ← タスク分解
│
└── detailed-design/
    ├── apex/
    │   └── [クラス名].md            ← Apex クラス詳細設計
    ├── trigger/
    │   └── [トリガー名].md          ← トリガー詳細設計
    ├── lwc/
    │   └── [コンポーネント名].md    ← LWC 詳細設計
    ├── flow/
    │   └── [フロー名].md            ← Flow 詳細設計
    └── objects/
        └── [オブジェクト名].md      ← オブジェクト定義

タスク分解.md フォーマット

# タスク 担当 工数 状態
1 API設計 ai-agent - 未着手
2 DB設計レビュー エンジニア 2H 未着手
3 実装: Controller ai-agent - 未着手
4 コードレビュー エンジニア 1H 未着手

使用テンプレート

.ai/templates/ 配下:

  • apex_class.template.md
  • apex_trigger.template.md
  • apex_batch.template.md
  • apex_controller.template.md
  • lwc.template.md
  • flow.template.md
  • 他

フェーズ C: 構築 (/build)

実行コマンド

/build [Asana依頼名]

フロー

C-1: 構築開始
├── タスク分解.md を読み込み
└── 実装計画を確認
    ↓
C-2: Asanaサブタスク作成
├── 予定時間を設定
└── 担当者を割り当て
    ↓
C-3: ai-agent担当タスク実行
├── .ai/rules/ のコーディングルールを読み込み
│   ├── apex-naming.md（命名規則）
│   ├── apex-documentation.md（ドキュメンテーション規則）
│   └── security-checklist.md（セキュリティチェックリスト）
├── 設計書に基づき実装（ルール準拠）
├── テストコード作成（ルール準拠）
└── コミット
    ↓
C-4: エンジニア担当タスク通知
└── 手動タスクをSlack通知
    ↓
C-5: コーディングルールチェック
├── /lint-rules 相当のチェック実行
├── 違反があれば自動修正
└── 修正後に再コミット
    ↓
C-6: PR作成
├── PRをGitHubに作成
└── エンジニアへSlack通知
    ↓
C-7: コードレビュー
├── 修正依頼 → 修正 → 再レビュー
└── 承認 → マージ

コーディングルールチェック項目（C-5）

カテゴリ チェック内容
命名規則 クラス名（PascalCase）、メソッド名（camelCase）、変数名
ドキュメンテーション クラス/メソッドのJavadocコメント、@description、@param、@return
セキュリティ SOQLインジェクション対策、XSS対策、with sharing、CRUD/FLSチェック

出力物

force-app/main/default/
├── classes/
│   ├── [実装クラス].cls
│   └── [テストクラス].cls
├── triggers/
│   └── [トリガー].trigger
└── lwc/
    └── [コンポーネント]/

GitHub
└── Pull Request

Asana
└── サブタスク（予定時間付き）

コミットメッセージ規約

<type>: <subject>

<body>

Refs: Asana#<task-id>
type 用途
feat 新機能
fix バグ修正
refactor リファクタリング
test テスト
docs ドキュメント

実装ガイドライン

Apex

// バルク処理を考慮
// SOQL ループ禁止、コレクション化
// CRUD/FLS/Sharing を明示的に考慮

LWC

// コロケーション（コンポーネントとテストを同一フォルダに配置）
// @wire と imperative 呼び出しを適切に使い分け
// アクセシビリティを考慮

テスト

// テスト名は日本語で明確に
// 正常系・異常系・境界値をカバー
// @isTest アノテーション使用

PRテンプレート

## 概要
<!-- 変更内容の概要 -->

## 関連タスク
- Asana: [タスク名](URL)
- 設計書: `doc_draft/basic-design/[Asana依頼名]/`

## 変更内容
- [ ] 機能1
- [ ] 機能2

## テスト
- [ ] 単体テスト
- [ ] 統合テスト

## レビュー観点
- [ ] ガバナ制限の考慮
- [ ] バルク処理対応
- [ ] CRUD/FLS/Sharing

注意事項

  • 実装は必ず設計書に基づく
  • テストカバレッジ75%以上を維持
  • セキュリティ脆弱性を導入しない
  • 既存コードを勝手に変更しない

完了条件

  1. 全タスクが完了
  2. PRがマージされる
  3. Asanaサブタスクが完了

全体フロー図

┌─────────────────────────────────────────────────────────────────┐
│                    AIネイティブ開発フロー                        │
└─────────────────────────────────────────────────────────────────┘

   Asanaタスク
       │
       ▼
┌──────────────────┐
│ /requirement     │  フェーズA: 要件定義
│                  │
│ ・情報収集       │  Asana/Slack/GitHub MCP
│ ・requirement.md │
│ ・エンジニア承認 │
└────────┬─────────┘
         │
         ▼
┌──────────────────┐
│ /design          │  フェーズB: 設計
│                  │
│ ・概要設計書     │
│ ・機能設計書     │
│ ・詳細設計書     │
│ ・タスク分解     │
│ ・工数承認       │
└────────┬─────────┘
         │
         ▼
┌──────────────────┐
│ /build           │  フェーズC: 構築
│                  │
│ ・ルール読込     │  .ai/rules/*
│ ・実装（準拠）   │
│ ・テスト作成     │
│ ・ルールチェック │  /lint-rules
│ ・PR作成        │
│ ・コードレビュー │
└────────┬─────────┘
         │
         ▼
      マージ完了

MCP連携一覧

MCP /requirement /design /build
asana ○ ○ ○
slack ○ ○ ○
github ○ ○ ○
salesforce - - ○

設計書の更新履歴管理

目的

設計書と要件定義書を紐づけて変更追跡を可能にし、「いつ・誰が・なぜ変更したか」を明確にする。

更新履歴セクションのフォーマット

各設計書には「更新履歴（要件定義書との紐づけ）」セクションを含める:

## 改訂履歴

### 更新履歴（要件定義書との紐づけ）

| 日付 | 更新者 | 要件定義書 | 変更内容 |
|------|--------|-----------|----------|
| 2026-01-19 | 山田太郎 | [不備解消業務可視化](../../requirement/不備解消業務可視化/requirement.html) | 初版作成 |
| 2026-02-15 | 鈴木花子 | [エラー通知機能追加](../../requirement/エラー通知機能追加/requirement.html) | エラーハンドリング追加 |

記録項目

項目 説明
日付 変更日（YYYY-MM-DD形式）
更新者 変更した担当者名
要件定義書 変更の根拠となる要件定義書へのリンク
変更内容 何を変更したかの概要

運用ルール

  1. 新規作成時: 要件定義書へのリンクを含め「初版作成」を記録
  2. 変更時: 新しい要件定義書を参照し、変更内容を追記
  3. リンク形式: 相対パスで要件定義書を参照

メリット

  • 変更追跡が可能（いつ・誰が・なぜ）
  • 要件と設計の紐づけが明確
  • レビュー効率化
  • 監査対応

関連ファイル

パス 内容
.claude/commands/requirement.md /requirement コマンド定義
.claude/commands/design.md /design コマンド定義
.claude/commands/approve-design.md /approve-design コマンド定義
.claude/commands/build.md /build コマンド定義
.claude/commands/lint-rules.md /lint-rules コマンド定義
.ai/rules/apex-naming.md Apex命名規則
.ai/rules/apex-documentation.md ドキュメンテーション規則
.ai/rules/security-checklist.md セキュリティチェックリスト
.ai/templates/ 設計書テンプレート群

更新履歴

日付 更新者 内容
2026-01-19 - 初版作成
2026-01-21 - B-10: 設計書承認（/approve-design）を追加