@takuma-hirai/hirai-method 0.1.0

package/.claude/commands/design.md

@@ -0,0 +1,807 @@
+---
+name: design
+description: "設計開始 - 概要設計書・機能設計書・詳細設計書・タスク分解を生成"
+category: workflow
+complexity: enhanced
+model: opus
+mcp-servers: [asana, slack, github]
+---
+
+# /design - 設計フェーズ
+
+## 概要
+
+AIネイティブ開発フローのフェーズB「設計」を実行するコマンド。
+要件定義書に基づき、設計書群とタスク分解を自動生成します。
+
+## トリガー
+
+- `/requirement` 完了後
+- 要件定義書の承認後
+
+## 使用方法
+
+```
+/design [Asana依頼名]
+```
+
+または
+
+```
+/design
+# → doc_draft/requirement/ から最新の要件を自動検出
+```
+
+## 実行フロー
+
+### B-0: 事前確認（Git認証）
+
+**最初に必ず実行**: GitHub CLIの認証状態を確認
+
+```bash
+gh auth status
+```
+
+#### 認証済みの場合
+
+```
+✓ Logged in to github.com account {ユーザー名}
+```
+
+→ B-0.5へ進む
+
+#### 未認証の場合
+
+```
+You are not logged into any GitHub hosts.
+```
+
+→ 以下のメッセージを表示し、認証を実行:
+
+```
+⚠️ GitHub CLIの認証が必要です。
+PRを作成するためにGitHub認証を行います。
+
+以下のコマンドを実行してください:
+gh auth login
+
+手順:
+1. GitHub.com を選択
+2. HTTPS を選択
+3. Yes（Authenticate Git with your GitHub credentials）
+4. Login with a web browser を選択
+5. ブラウザで認証を完了
+```
+
+認証完了後、再度 `gh auth status` で確認してからB-0.5へ進む。
+
+### B-0.5: 事前確認（要件定義書・Slack URL）
+
+`/design` の最初に、要件定義の完了確認と必須項目のチェックを行う。
+
+#### Step 1: 要件定義書の完了確認
+
+`doc_draft/requirement/[依頼名]/requirement.md` が存在するか確認する。
+
+- **存在する場合**: requirement.md を読み込み、Step 2 へ進む
+- **存在しない場合**: 以下のメッセージを表示し、`/requirement` の実行を促す
+
+```
+⚠️ 要件定義書が見つかりません。
+先に /requirement を実行して要件定義書を作成してください。
+
+→ /requirement を実行しますか？（はい/いいえ）
+```
+
+「はい」の場合は `/requirement` フローに戻る。「いいえ」の場合は理由を確認し、要件定義なしで進めるか判断する。
+
+#### Step 2: SlackスレッドURL の確認（必須）
+
+Asana MCPでタスクの「【APP】SlackのスレッドURL - 1」フィールドを確認する。
+
+**カスタムフィールドGID**: `1212822906463960`
+
+- **URLが入力済みの場合**: Step 3 へ進む
+- **URLが未入力の場合**: 以下のメッセージを表示し、登録を促す
+
+```
+⚠️ SlackのスレッドURLが未登録です（必須項目）。
+
+AsanaタスクのカスタムフィールドにSlackスレッドURLを登録してください:
+  フィールド名: 【APP】SlackのスレッドURL - 1
+
+→ SlackのスレッドURLを入力してください:
+```
+
+エンジニアがURLを入力したら、Asana MCPで該当フィールドを更新する:
+
+```
+asana_update_task:
+  task_id: {AsanaタスクID}
+  custom_fields: {"1212822906463960": "{入力されたSlackURL}"}
+```
+
+> **注意**: SlackスレッドURLは必須です。未登録の場合は登録完了まで設計フェーズに進まないこと。
+
+Step 2 完了後、B-1（設計開始）へ進む。
+
+#### カスタムフィールドGID一覧
+
+| フィールド名                  | GID                | タイプ | 用途                      |
+| ----------------------------- | ------------------ | ------ | ------------------------- |
+| 【APP】SlackのスレッドURL - 1 | `1212822906463960` | text   | Slackスレッド必須チェック |
+
+### B-1: 設計開始
+
+1. 要件定義書（requirement.md）を読み込み（B-0.5で取得済み）
+2. 新規機能 or 追加機能かを判定
+3. **Itandi連携判定**（自動）
+
+#### Itandi連携の自動判定
+
+要件定義書・設計対象の内容から、以下のキーワード・条件に該当する場合は **Itandi連携あり** と判定する:
+
+| 判定条件                                                       | 例                                                    |
+| -------------------------------------------------------------- | ----------------------------------------------------- |
+| 要件定義書にItandi/イタンジ/いたんじへの言及がある             | 「イタンジBB連携」「Itandi CSV」等                    |
+| 対象オブジェクト・項目にItandi関連のAPI名が含まれる            | `itandiPropSyncID__c`, `ItandiPreviewStartDate__c` 等 |
+| Itandiとのデータ連携（CSV取込、API連携）に関する仕様変更がある | インポートバッチ、連携フロー等                        |
+| Itandi側の仕様（BB、内見予約等）に影響する変更がある           | BB連携の制御変更等                                    |
+
+**判定結果の記録**: 概要設計書（readme.md）に以下を記載する:
+
+```markdown
+## 外部連携影響
+
+- **Itandi連携**: あり / なし
+- **影響内容**: （ありの場合、どのような仕様変更があるかを記載）
+- **documentリポジトリ更新**: 必要（`classlab-inc/document` の `Inside/Itandi/` 配下）
+```
+
+> **Itandi連携ありの場合**: B-4（タスク分解）で、documentリポジトリの仕様ドキュメント更新タスクが自動追加される。
+
+### B-2: 設計書作成
+
+#### 新規機能の場合
+
+- `.ai/templates/` からテンプレートを使用して新規作成
+
+#### 追加機能の場合
+
+- 既存の設計書をコピーし、差分を修正
+
+生成する設計書:
+
+1. **概要設計書.md** - システム全体像、アーキテクチャ
+2. **機能設計書.md** - 機能詳細、画面設計、API設計
+3. **詳細設計書.md** - クラス設計、メソッド仕様
+
+### B-2.5: 干渉チェック（自動実行・必須）
+
+設計書が生成された後、設計内容と既存の自動化処理（入力規則・トリガー・フロー）の干渉を自動チェックする。
+
+#### 手順
+
+**Step 1: 設計書から対象情報を抽出**
+
+B-2で生成した設計書（概要設計書・詳細設計書）を読み取り、以下を特定する:
+
+| 抽出項目         | 抽出元                            | 例                               |
+| ---------------- | --------------------------------- | -------------------------------- |
+| 対象オブジェクト | 設計書内のオブジェクト参照        | `MoveIn__c`                      |
+| 対象項目         | 設計書内の項目参照・更新項目      | `Satus__c`, `ReasonForReCall__c` |
+| 操作種別         | 設計書内のDML操作・処理タイミング | `update`                         |
+
+**Step 2: Pythonスクリプトを実行**
+
+抽出した情報で干渉チェックスクリプトを実行する。**必ず実行すること（スキップ禁止）。**
+
+```bash
+python3 scripts/tools/impact-check.py \
+  --object [対象オブジェクト] \
+  --fields [対象項目をカンマ区切り] \
+  --operation [操作種別] \
+  --output json
+```
+
+対象オブジェクトが複数ある場合は、オブジェクトごとに実行する。
+
+**Step 3: 結果を設計書に反映**
+
+スクリプトの出力（JSON）を解釈し、概要設計書（`readme.md`）に「干渉チェック結果」セクションを追記する:
+
+```markdown
+## 干渉チェック結果
+
+実行日: YYYY-MM-DD
+対象: [オブジェクト名] / [項目名] / [操作種別]
+
+### サマリー
+
+| 自動化種別   | 総数 | Active | 干渉リスクあり |
+| ------------ | ---- | ------ | -------------- |
+| 入力規則     | X件  | X件    | X件            |
+| Apexトリガー | X件  | X件    | X件            |
+| フロー       | X件  | X件    | X件            |
+
+### 高リスク項目
+
+（HIGH リスクの項目を記載。なければ「なし」）
+
+### 依頼者への確認事項
+
+（確認が必要な事項を記載。なければ「なし」）
+
+### 対策方針
+
+（高リスク項目に対する設計上の対策を記載）
+```
+
+**Step 4: 高リスク項目への対応**
+
+- **HIGH リスクが0件**: そのままB-3へ進む
+- **HIGH リスクが1件以上**: エンジニアに高リスク項目を提示し、設計書に対策方針を追記してからB-3へ進む
+
+#### 注意
+
+- 設計書に記載されている**すべてのDML操作対象オブジェクト**に対してチェックを実行する
+- 新規トリガー・フローを設計した場合、そのトリガー・フローが操作する対象オブジェクトもチェック対象に含める
+- スクリプトの出力はそのまま貼るのではなく、AIが業務的な文脈を加えて要約する
+
+### B-3: 担当エンジニア確認
+
+担当エンジニアがローカルで設計書を確認・修正（干渉チェック結果含む）
+
+### B-4: タスク分解
+
+設計書に基づきタスクを自動分解
+
+1. 設計書の内容からタスクを洗い出し
+2. タスク一覧を生成（この時点では工数は空欄）
+3. **レビュータスクを自動追加**（末尾に工数なしで追加）
+
+```markdown
+## タスク分解（工数未入力）
+
+| #   | タスク           | 工数 |
+| --- | ---------------- | ---- |
+| 1   | API設計          |      |
+| 2   | DB設計           |      |
+| 3   | 実装: Controller |      |
+| 4   | 実装: Service    |      |
+| 5   | テストコード     |      |
+| 6   | コードレビュー   |      |
+```
+
+#### レビュータスク自動追加ルール
+
+タスク分解の末尾に、以下のレビュータスクを **自動追加** する。工数は空欄のままでよい。
+
+| タスク名       | 工数 | 説明                                 |
+| -------------- | ---- | ------------------------------------ |
+| コードレビュー | -    | 実装後のコードレビュー（エンジニア） |
+
+- エンジニアへの工数質問は不要
+- Asanaサブタスクとして登録する際も予定時間なしで作成する
+
+#### Itandi仕様ドキュメント更新タスク自動追加ルール
+
+B-1でItandi連携ありと判定された場合、タスク分解に以下のタスクを **自動追加** する。
+コードレビューの直前に追加し、工数はエンジニアが見積もりを入力する。
+
+| タスク名                   | 工数               | 説明                                                                               |
+| -------------------------- | ------------------ | ---------------------------------------------------------------------------------- |
+| Itandi仕様ドキュメント更新 | （エンジニア入力） | `classlab-inc/document` リポジトリの `Inside/Itandi/` 配下の関連ドキュメントを更新 |
+
+**タスク説明に含める内容**:
+
+- 更新が必要と推定されるファイル（設計内容から判断: `api.md`, `batch.md`, `data.md`, `flow.md` 等）
+- 変更の概要（どのような仕様追加・変更があるか）
+- documentリポジトリのPR作成も含む
+
+**タスク分解の例（Itandi連携ありの場合）**:
+
+```markdown
+## タスク分解（工数未入力）
+
+| #   | タスク                     | 工数 |
+| --- | -------------------------- | ---- |
+| 1   | API設計                    |      |
+| 2   | DB設計                     |      |
+| 3   | 実装: Controller           |      |
+| 4   | 実装: Service              |      |
+| 5   | テストコード               |      |
+| 6   | Itandi仕様ドキュメント更新 |      |
+| 7   | コードレビュー             |      |
+```
+
+> **注意**: Itandi仕様ドキュメント更新タスクは工数入力対象（レビュータスクとは異なる）。B-4.5でエンジニアに見積もりを確認する。
+
+### B-4.5: 工数入力（エンジニア入力）
+
+タスク分解後、**レビュータスク以外の**各タスクの見積もり工数をエンジニアに質問:
+
+```
+タスク分解が完了しました。各タスクの見積もり工数を入力してください。
+※ コードレビューは工数入力不要です。
+
+タスク1: API設計
+→ 見積もり工数（例: 1h, 2h, 0.5h）:
+
+タスク2: DB設計
+→ 見積もり工数（例: 1h, 2h, 0.5h）:
+
+タスク3: 実装: Controller
+→ 見積もり工数（例: 1h, 2h, 0.5h）:
+
+...
+```
+
+#### 入力形式
+
+| 入力例              | 解釈  |
+| ------------------- | ----- |
+| `1h` または `1H`    | 1時間 |
+| `0.5h`              | 30分  |
+| `2h`                | 2時間 |
+| `30m` または `30分` | 30分  |
+
+#### 入力完了後
+
+全タスクの工数入力が完了したら:
+
+1. **タスク分解.md を更新**
+
+```markdown
+## タスク分解
+
+| #   | タスク           | 工数 | 状態   |
+| --- | ---------------- | ---- | ------ |
+| 1   | API設計          | 1H   | 未着手 |
+| 2   | DB設計           | 2H   | 未着手 |
+| 3   | 実装: Controller | 1H   | 未着手 |
+| 4   | 実装: Service    | 1H   | 未着手 |
+| 5   | テストコード     | 0.5H | 未着手 |
+| 6   | コードレビュー   | -    | 未着手 |
+
+**合計工数: 5.5H**
+```
+
+2. **合計工数を計算し、自動的にB-5（Asana同期）へ進む**
+
+```
+工数入力が完了しました。
+
+合計工数: 5.5H（330分）
+→ Asanaの予定時間に自動同期します...
+→ 同期完了 ✓
+```
+
+### B-5: 工数入力（Asana自動同期）
+
+**B-4.5完了後、自動実行される**
+
+#### Step 1: 親タスクに合計工数を設定
+
+1. 合計工数を分単位に変換（例: 6.5H → 390分）
+2. Asana MCPで親タスクの「予定時間（Estimated time）」に自動入力
+
+```
+asana_update_task:
+  task_id: {親タスクID}
+  custom_fields: {"1203561023086990": {合計工数（分）}}
+```
+
+#### Step 2: 分解したタスクをサブタスクとして登録
+
+各タスクをAsanaのサブタスクとして作成する。工数ありのタスクは予定時間を設定、工数なし（`-`）のタスクは予定時間なしで作成。
+
+**重要: Asanaではサブタスクが上から追加されるため、タスク一覧の逆順（末尾→先頭）で作成すること。**
+
+```
+# 逆順で作成する（例: タスク6 → タスク5 → ... → タスク1）
+
+# 工数ありのタスク
+asana_create_task:
+  name: {タスク名}
+  parent: {親タスクID}
+  custom_fields: {"1203561023086990": {工数（分）}}
+
+# 工数なしのタスク（コードレビュー等）
+asana_create_task:
+  name: {タスク名}
+  parent: {親タスクID}
+  # custom_fields の予定時間は設定しない
+```
+
+#### 実行例
+
+```
+工数入力が完了しました。
+
+合計工数: 5.5H（330分）
+
+Asanaに同期中（逆順で作成）...
+  ✓ 親タスクに合計工数を設定（330分）
+  ✓ サブタスク作成: コードレビュー（工数なし）     ← 6番目を最初に
+  ✓ サブタスク作成: テストコード（30分）
+  ✓ サブタスク作成: 実装: Service（60分）
+  ✓ サブタスク作成: 実装: Controller（60分）
+  ✓ サブタスク作成: DB設計（120分）
+  ✓ サブタスク作成: API設計（60分）                 ← 1番目を最後に
+
+同期完了 ✓
+```
+
+#### 実行例（Itandi連携ありの場合）
+
+```
+工数入力が完了しました。
+
+合計工数: 6.5H（390分）
+
+Asanaに同期中（逆順で作成）...
+  ✓ 親タスクに合計工数を設定（390分）
+  ✓ サブタスク作成: コードレビュー（工数なし）
+  ✓ サブタスク作成: Itandi仕様ドキュメント更新（60分）
+  ✓ サブタスク作成: テストコード（30分）
+  ✓ サブタスク作成: 実装: Service（60分）
+  ✓ サブタスク作成: 実装: Controller（60分）
+  ✓ サブタスク作成: DB設計（120分）
+  ✓ サブタスク作成: API設計（60分）
+
+同期完了 ✓
+```
+
+#### Asana構造
+
+```
+📋 [親タスク] {Asana依頼名}（合計: 5.5H）
+  ├─ サブタスク: API設計（1H）
+  ├─ サブタスク: DB設計（2H）
+  ├─ サブタスク: 実装: Controller（1H）
+  ├─ サブタスク: 実装: Service（1H）
+  ├─ サブタスク: テストコード（0.5H）
+  └─ サブタスク: コードレビュー（工数なし）
+```
+
+#### Asana構造（Itandi連携ありの場合）
+
+```
+📋 [親タスク] {Asana依頼名}（合計: 6.5H）
+  ├─ サブタスク: API設計（1H）
+  ├─ サブタスク: DB設計（2H）
+  ├─ サブタスク: 実装: Controller（1H）
+  ├─ サブタスク: 実装: Service（1H）
+  ├─ サブタスク: テストコード（0.5H）
+  ├─ サブタスク: Itandi仕様ドキュメント更新（1H）
+  └─ サブタスク: コードレビュー（工数なし）
+```
+
+#### 工数変換表
+
+**注意**: 工数は**分単位**で指定
+
+| 工数（時間） | 入力値（分） |
+| ------------ | ------------ |
+| 0.5h         | 30           |
+| 1h           | 60           |
+| 2h           | 120          |
+| 3h           | 180          |
+| 4h           | 240          |
+| 8h           | 480          |
+
+### B-6: レビュアー選択
+
+設計書レビューを依頼する上長を選択（`.ai/config/reviewers.md` 参照）
+
+| 名前     | Asana GID        | GitHub              | Slack ID    |
+| -------- | ---------------- | ------------------- | ----------- |
+| 平井     | 1210193551915917 | thirai-classlab     | U07B6BQ8Y8Z |
+| 古谷圭吾 | 1209044134340755 | classlab-ltd-fk     | U086CTXGF2R |
+| 棟安拓未 | 1207940793230770 | t-muneyasu-classlab | U07FNRT78HW |
+
+### B-6.5: ベースブランチ指定
+
+レビュアー選択後、PRのマージ先（ベースブランチ）のURLを入力してもらう:
+
+```
+PRを作成するブランチURLを教えてください。
+
+例: https://github.com/classlab-inc/cl-crm-salesforce/tree/STG
+```
+
+#### URL解析
+
+入力されたURLからブランチ名を抽出:
+
+```
+https://github.com/{owner}/{repo}/tree/{branch}
+                                       ^^^^^^^^
+                                       この部分を抽出
+```
+
+**例**:
+
+- `https://github.com/classlab-inc/cl-crm-salesforce/tree/STG` → `STG`
+- `https://github.com/classlab-inc/cl-crm-salesforce/tree/main` → `main`
+- `https://github.com/classlab-inc/cl-crm-salesforce/tree/feature/xxx` → `feature/xxx`
+
+### B-6.6: PR確認期日の確認
+
+ベースブランチ指定後、PR確認の希望期日を確認:
+
+```
+PR確認の期日は何日を希望しますか？
+
+例: 2026-01-25、明日、今週金曜日
+```
+
+#### 入力形式
+
+| 入力例       | 解釈         |
+| ------------ | ------------ |
+| `2026-01-25` | 指定日付     |
+| `明日`       | 翌日の日付   |
+| `今週金曜日` | 今週の金曜日 |
+| `3日後`      | 3日後の日付  |
+
+### B-7: PR作成
+
+1. 設計書のPRをGitHubに作成
+2. 選択した上長をレビュアーに指定
+3. 指定されたベースブランチにマージするよう設定
+
+```bash
+gh pr create --title "[設計書] {Asana依頼名}" \
+  --body "設計書のレビューをお願いします。" \
+  --base "{ベースブランチ}" \
+  --reviewer "{GitHubユーザー名}"
+```
+
+#### ベースブランチ指定例
+
+```bash
+# STGブランチへのPR（デフォルト）
+gh pr create --title "[設計書] 不備解消業務可視化" \
+  --body "設計書のレビューをお願いします。" \
+  --base "STG" \
+  --reviewer "thirai-classlab"
+
+# mainブランチへのPR
+gh pr create --title "[設計書] 緊急対応" \
+  --body "設計書のレビューをお願いします。" \
+  --base "main" \
+  --reviewer "thirai-classlab"
+```
+
+### B-8: Asana・Slackでレビュー依頼
+
+#### Step 1: Asanaタスクにコメント（メンションなし）
+
+```
+{上長の名前}さん
+{PRのURL}
+上記で設計書のPRを作成しました。
+ご確認お願いいたします。
+
+PR確認希望期日は {期日} です。
+可能な限り期日を尊重し、リソースに空きがない場合はPR確認日を回答してください。
+```
+
+#### Step 2: AsanaコメントURLを取得
+
+コメント作成後、以下の形式でURLを生成:
+
+```
+https://app.asana.com/0/0/{タスクID}/{コメントID}
+```
+
+#### Step 3: Slackに通知（スレッド形式）
+
+**通知先チャンネル**: `C07JMC480EA`
+
+**親メッセージ**:
+
+```
+{Asanaタスク名} の設計書PRを作成しました。
+```
+
+**スレッド返信**（メンション付き）:
+
+```
+<@{上長のSlack ID}>
+{Asanaタスク名} - PRコメント: {AsanaコメントURL}
+上記でPRを作成しました。
+
+PR確認希望期日は {期日} です。
+可能な限り期日を尊重し、リソースに空きがない場合はPR確認日を回答してください。
+
+確認し、承認 or 却下を実施してください。
+```
+
+#### Step 4: Asanaタスクのセクション移動
+
+PR作成・通知完了後、タスクを「設計書承認」セクションに移動:
+
+```bash
+curl -X POST "https://app.asana.com/api/1.0/sections/1212857002747714/addTask" \
+  -H "Authorization: Bearer {{ASANA_PERSONAL_ACCESS_TOKEN}}" \
+  -H "Content-Type: application/json" \
+  -d '{"data": {"task": "{AsanaタスクID}"}}'
+```
+
+**移動先**: 設計書承認（GID: `1212857002747714`）
+
+### B-9: 設計レビュー
+
+上長がPR上でレビュー・コメント
+
+- 修正依頼 → 修正 → 再レビュー
+- 承認 → PRマージ
+
+### B-10: 設計書承認（/approve-design）
+
+PRマージ後、`/approve-design` コマンドを実行:
+
+1. `doc_draft/` → `doc/` に設計書を移動
+2. インデックスを更新
+3. Asanaセクションを「構築待ち」に移動
+4. Slack通知
+
+詳細は `/approve-design` コマンドを参照。
+
+## 出力物
+
+既存のディレクトリ構造（`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      ← オブジェクト定義
+```
+
+### 出力先の決定ルール
+
+| 設計書種別            | 出力先                                                   |
+| --------------------- | -------------------------------------------------------- |
+| 概要設計書            | `doc_draft/basic-design/[依頼名]/readme.md`              |
+| 機能設計書            | `doc_draft/basic-design/[依頼名]/feature/XX_[機能名].md` |
+| 詳細設計書（Apex）    | `doc_draft/detailed-design/apex/[クラス名].md`           |
+| 詳細設計書（Trigger） | `doc_draft/detailed-design/trigger/[トリガー名].md`      |
+| 詳細設計書（LWC）     | `doc_draft/detailed-design/lwc/[コンポーネント名].md`    |
+| 詳細設計書（Flow）    | `doc_draft/detailed-design/flow/[フロー名].md`           |
+| タスク分解            | `doc_draft/basic-design/[依頼名]/task-breakdown.md`      |
+
+### タスク分解.md フォーマット
+
+```markdown
+## タスク分解
+
+| #   | タスク           | 工数 | 状態   |
+| --- | ---------------- | ---- | ------ |
+| 1   | API設計          | 1H   | 未着手 |
+| 2   | DB設計           | 2H   | 未着手 |
+| 3   | 実装: Controller | 1H   | 未着手 |
+| 4   | 実装: Service    | 1H   | 未着手 |
+| 5   | テストコード     | 0.5H | 未着手 |
+| 6   | コードレビュー   | -    | 未着手 |
+
+**合計工数: 5.5H**
+```
+
+### 工数入力ルール
+
+- 全タスクの工数はエンジニアが見積もりを入力
+- AIがタスクを分解した後、1タスクずつ工数を質問
+- 入力形式: `1h`, `0.5h`, `30m` など柔軟に対応
+- 合計工数はAsanaの「予定時間」に自動連携
+
+## MCP連携
+
+| MCP      | 用途                             |
+| -------- | -------------------------------- |
+| `asana`  | タスク通知、承認依頼             |
+| `slack`  | レビュー依頼通知（スレッド形式） |
+| `github` | PR作成、レビュー依頼             |
+
+### Asanaカスタムフィールド参照
+
+| フィールド名                  | GID              | タイプ | 用途                      |
+| ----------------------------- | ---------------- | ------ | ------------------------- |
+| Estimated time                | 1203561023086990 | number | 工数（分）の設定          |
+| 【APP】SlackのスレッドURL - 1 | 1212822906463960 | text   | Slackスレッド必須チェック |
+| 【APP】SlackのスレッドURL - 2 | 1212822906463962 | text   | -                         |
+| 【APP】SlackのスレッドURL - 3 | 1212822906463964 | text   | -                         |
+| 【APP】Git開発ブランチ - 1    | 1212822927674553 | text   | -                         |
+| 【APP】Git開発ブランチ - 2    | 1212822927674555 | text   | -                         |
+| 【APP】Git開発ブランチ - 3    | 1212822927674557 | text   | -                         |
+| 依頼者                        | 1203361292498361 | people | 依頼者メンション          |
+| 【App】要件定義者             | 1213356665471536 | people | 参考情報                  |
+
+### Slack通知設定
+
+| 項目             | 値                                                 |
+| ---------------- | -------------------------------------------------- |
+| 通知先チャンネル | `C07JMC480EA`                                      |
+| チャンネルURL    | https://mgr-1j56202.slack.com/archives/C07JMC480EA |
+
+## テンプレート参照
+
+設計書テンプレートは以下を参照:
+
+- `.ai/templates/apex_class.template.md`
+- `.ai/templates/apex_trigger.template.md`
+- `.ai/templates/lwc.template.md`
+- `.ai/templates/flow.template.md`
+
+## 更新履歴の記録ルール
+
+設計書には必ず「更新履歴（要件定義書との紐づけ）」セクションを含めること。
+
+### 記録項目
+
+| 項目       | 説明                                 | 例                                                  |
+| ---------- | ------------------------------------ | --------------------------------------------------- |
+| 日付       | 変更日（YYYY-MM-DD形式）             | 2026-01-19                                          |
+| 更新者     | 変更した担当者名                     | 山田太郎                                            |
+| 要件定義書 | 変更の根拠となる要件定義書へのリンク | `[依頼名](../../requirement/依頼名/requirement.md)` |
+| 変更内容   | 何を変更したかの概要                 | 初版作成、エラーハンドリング追加                    |
+
+### フォーマット
+
+```markdown
+## 改訂履歴
+
+### 更新履歴（要件定義書との紐づけ）
+
+| 日付       | 更新者   | 要件定義書                                                                | 変更内容               |
+| ---------- | -------- | ------------------------------------------------------------------------- | ---------------------- |
+| 2026-01-19 | 山田太郎 | [不備解消業務可視化](../../requirement/不備解消業務可視化/requirement.md) | 初版作成               |
+| 2026-02-15 | 鈴木花子 | [エラー通知機能追加](../../requirement/エラー通知機能追加/requirement.md) | エラーハンドリング追加 |
+```
+
+### 運用ルール
+
+1. **新規作成時**: 要件定義書へのリンクを含め「初版作成」を記録
+2. **変更時**: 新しい要件定義書を参照し、変更内容を追記
+3. **リンク形式**: 相対パスで要件定義書を参照（`../../requirement/[依頼名]/requirement.md`）
+
+## 注意事項
+
+- 設計書は必ずエンジニアのレビューを経る
+- 既存アーキテクチャとの整合性を確認
+- Salesforce ガバナ制限を考慮した設計
+
+## 次のステップ
+
+1. 設計書PRがマージされたら → `/approve-design` で設計書を承認（doc/ に移動）
+2. 設計書承認後 → `/build` コマンドで構築フェーズへ進む
+
+```
+/design → 設計書PR作成 → レビュー → マージ
+    ↓
+/approve-design → doc/ に移動 → 承認完了
+    ↓
+/build → 実装開始
+```