承認された要件定義書に基づいて、技術設計文書を生成する。データフロー図、TypeScriptインターフェース、データベーススキーマ、APIエンドポイントを含む包括的な設計を行います。
Generates comprehensive technical design documents from approved requirements specifications.
/plugin marketplace add classmethod/tsumiki/plugin install tsumiki@tsumiki要件名Kairo開発の技術設計を実施し、PRD・EARS要件定義書・既存設計文書を参照しながら技術仕様を明確化します。信頼性レベルを示しながら設計文書を作成します。
出力ディレクトリ="docs/design" 要件名={{requirement_name}} 作業規模={{work_scope}} 信頼性評価=[]
AskUserQuestion ツールを使って作業規模を質問する：
ユーザーの選択を context の {{work_scope}} に保存
カスタムを選択した場合は、AskUserQuestion ツールを使って以下を質問：
step3 を実行する
タスクノートの読み込み
docs/spec/{要件名}/note.md が存在する場合は読み込み/tsumiki:kairo-tasknote {要件名} コマンドを実行してノートを生成要件定義書の読み込み
./docs/spec/{要件名}-requirements.md を読み込み./docs/spec/{要件名}/requirements.md を読み込み./docs/spec/{要件名}-user-stories.md が存在する場合は読み込み./docs/spec/{要件名}/user-stories.md が存在する場合は読み込み./docs/spec/{要件名}-acceptance-criteria.md が存在する場合は読み込み./docs/spec/{要件名}/acceptance-criteria.md が存在する場合は読み込み追加ルールの読み込み
docs/rule ディレクトリが存在する場合は読み込みdocs/rule/kairo ディレクトリが存在する場合は読み込みdocs/rule/kairo/design ディレクトリが存在する場合は読み込み技術スタック定義の読み込み
docs/tech-stack.md が存在する場合は読み込みCLAUDE.md から技術スタックセクションを読み込み既存設計文書の調査
docs/design/ ディレクトリ配下の既存設計文書を確認既存コードベース・実装の分析（オプション）
収集情報のサマリー作成
読み込み完了後、step4 を実行する
作業規模に応じてヒアリング項目を調整。 重要: 以下の質問は例示であり、実際のプロジェクト状況に応じて AskUserQuestion ツールを使用して適切な質問を作成すること。
以下のカテゴリごとに、既存情報（要件定義、設計文書、実装）から特定した具体的な課題・不明点について AskUserQuestion ツールで質問する：
既存アーキテクチャの妥当性確認
例: AskUserQuestion ツールで以下のように質問
未定義設計の詳細化ヒアリング
技術選択の確認
パフォーマンス・スケーラビリティ要件
セキュリティ・コンプライアンス要件
優先順位・フェーズ分け 複数の設計要素がある場合、AskUserQuestion ツールで優先順位を質問:
必須項目のみ確認 AskUserQuestion ツールを使って、以下の項目について簡潔に質問:
step2 で選択した項目に関連するヒアリングのみ実施。 AskUserQuestion ツールを使って、選択された項目に応じた質問を作成する。
注意事項:
ヒアリング記録の作成:
すべての質問と回答を記録する
各質問について、以下を記録：
ヒアリング結果のサマリーを作成：
この記録は後で {要件名}-design-interview.md として出力する
step5 を実行する
作業規模に応じた設計テンプレートを選択：
context の情報でテンプレートを埋めて、以下のファイルを直接作成する
出力ファイル:
docs/design/{要件名}/architecture.md: アーキテクチャ概要
docs/design/{要件名}/dataflow.md: データフロー図
docs/design/{要件名}/design-interview.md: ヒアリング記録
フル設計の場合:
docs/design/{要件名}/interfaces.ts または対応する型定義ファイル: 型定義
docs/design/{要件名}/database-schema.sql または対応するスキーマファイル: DBスキーマ
docs/design/{要件名}/api-endpoints.md: API仕様
作成した設計文書の内容について、品質判定基準に基づいて以下を評価：
品質判定結果をユーザーに表示する（全ファイル統合の信頼性レベル分布を含む）
step6 を実行する
TodoWrite ツールで TODO ステータスを更新する
完了報告を表示：
次のステップ表示: 「次のお勧めステップ: /tsumiki:kairo-tasks {要件名} でタスク分割を実施します。」
docs/design/{要件名}/architecture.mddocs/design/{要件名}/dataflow.mddocs/design/{要件名}/design-interview.mddocs/design/{要件名}/interfaces.ts (または対応する型定義ファイル)docs/design/{要件名}/database-schema.sql (または対応するスキーマファイル)docs/design/{要件名}/api-endpoints.mddocs/design/{要件名}/ ディレクトリが存在しない場合は自動作成✅ 高品質:
- 設計の完全性: 完全
- 技術的実現可能性: 確実
- パフォーマンス・スケーラビリティ: 考慮済み
- セキュリティ考慮: 十分
- 信頼性レベル: 🔵（青信号）が多い
⚠️ 要改善:
- 設計に曖昧な部分がある
- 技術的制約が不明確
- パフォーマンス考慮が不十分
- セキュリティリスクが残る
- 信頼性レベル: 🟡🔴（黄・赤信号）が多い
- 現在のTODOを「completed」にマーク
- 設計フェーズの完了をTODO内容に反映
- 次のフェーズ「タスク分割」をTODOに追加
- 品質判定結果をTODO内容に記録
各項目について、元の資料（PRD・EARS要件定義書・設計文書・ユーザヒアリング含む）との照合状況を以下の信号でコメントしてください：
/Users/username/projects/myapp/src/utils/helper.tssrc/utils/helper.tsすべてのヒアリングは AskUserQuestion ツールを使用して行います。以下は具体的な使用例です。
AskUserQuestion({
questions: [{
question: "現在のアーキテクチャは{具体的なパターン}ですが、{新要件}には{別のパターン}の方が適している可能性があります。変更を検討しますか？",
header: "アーキテクチャ",
multiSelect: false,
options: [
{
label: "現行維持",
description: "現在のアーキテクチャを維持"
},
{
label: "変更検討",
description: "新しいアーキテクチャパターンを検討"
}
]
}]
})
AskUserQuestion({
questions: [{
question: "この機能で使用する技術を選択してください",
header: "技術選択",
multiSelect: true,
options: [
{
label: "REST API",
description: "RESTful API を使用"
},
{
label: "GraphQL",
description: "GraphQL を使用"
},
{
label: "WebSocket",
description: "リアルタイム通信が必要"
}
]
}]
})
AskUserQuestion({
questions: [{
question: "ユーザーデータの保存方法について教えてください",
header: "データ保存",
multiSelect: false,
options: [
{
label: "リレーショナルDB",
description: "PostgreSQL/MySQL等を使用"
},
{
label: "NoSQL",
description: "MongoDB/DynamoDB等を使用"
},
{
label: "ハイブリッド",
description: "用途に応じて使い分け"
}
]
}]
})
AskUserQuestion({
questions: [{
question: "APIレスポンスタイムの目標値を教えてください",
header: "レスポンス目標",
multiSelect: false,
options: [
{
label: "100ms以内",
description: "高速レスポンスが必要"
},
{
label: "500ms以内",
description: "一般的なレスポンス"
},
{
label: "1秒以内",
description: "許容範囲内"
}
]
}]
})
AskUserQuestion({
questions: [
{
question: "以下の設計要素の中で、Phase 1（必須）の項目を選択してください",
header: "Phase 1",
multiSelect: true,
options: [
{
label: "ユーザー認証",
description: "認証・認可機能"
},
{
label: "データ管理",
description: "CRUD操作"
},
{
label: "レポート機能",
description: "データの集計・出力"
}
]
},
{
question: "設計のフェーズ分けについて教えてください",
header: "フェーズ計画",
multiSelect: false,
options: [
{
label: "一括設計",
description: "すべての設計を一度に実施"
},
{
label: "段階的設計",
description: "フェーズごとに段階的に設計"
}
]
}
]
})
<architecture_template>
作成日: {作成日時} 関連要件定義: requirements.md ヒアリング記録: design-interview.md
【信頼性レベル凡例】:
信頼性: 🔵 要件定義書第1章より
{システムの概要説明}
信頼性: 🔵 CLAUDE.md技術スタック・既存設計より
信頼性: 🔵 tech-stack.md・既存設計より
信頼性: 🔵 tech-stack.md・既存設計より
信頼性: 🟡 要件から妥当な推測
graph TB
Client[クライアント]
FE[フロントエンド]
API[API Gateway]
BE[バックエンド]
DB[(データベース)]
Cache[(キャッシュ)]
Client --> FE
FE --> API
API --> BE
BE --> DB
BE --> Cache
信頼性: 🔵 要件定義・既存設計より
信頼性: 🔵 既存プロジェクト構造より
./
├── src/
│ ├── {主要ディレクトリ1}/
│ ├── {主要ディレクトリ2}/
│ └── {主要ディレクトリ3}/
├── tests/
├── docs/
└── {その他の主要ディレクトリ}
信頼性: 🟡 NFR要件から妥当な推測
信頼性: 🔵 NFR要件・セキュリティ設計より
信頼性: 🟡 NFR要件から妥当な推測
信頼性: 🟡 NFR要件から妥当な推測
信頼性: 🔵 CLAUDE.md・要件定義より
信頼性: 🔵 CLAUDE.md・要件定義より
信頼性: 🔵 CLAUDE.md・tech-stack.mdより
品質評価: {高品質/要改善/要ヒアリング} </architecture_template>
<dataflow_template>
作成日: {作成日時} 関連アーキテクチャ: architecture.md 関連要件定義: requirements.md
【信頼性レベル凡例】:
信頼性: 🔵 要件定義・ユーザーストーリーより
flowchart TD
A[ユーザー] --> B[フロントエンド]
B --> C[API Gateway]
C --> D[バックエンド]
D --> E[(データベース)]
D --> F[(キャッシュ)]
D --> G[外部サービス]
E --> D
F --> D
G --> D
D --> C
C --> B
B --> A
信頼性: 🔵 ユーザーストーリー1.1・受け入れ基準TC-001より
関連要件: REQ-001, REQ-002
sequenceDiagram
participant U as ユーザー
participant F as フロントエンド
participant A as API
participant B as バックエンド
participant D as データベース
U->>F: {アクション}
F->>A: POST /api/{endpoint}
A->>B: {処理}
B->>D: {クエリ}
D-->>B: {結果}
B->>B: {ビジネスロジック}
B-->>A: {レスポンス}
A-->>F: {データ}
F-->>U: {画面更新}
詳細ステップ:
信頼性: 🟡 要件から妥当な推測
関連要件: REQ-101
sequenceDiagram
participant U as ユーザー
participant F as フロントエンド
participant B as バックエンド
participant C as キャッシュ
participant D as データベース
U->>F: {アクション}
F->>B: GET /api/{endpoint}
B->>C: キャッシュ確認
alt キャッシュヒット
C-->>B: キャッシュデータ
else キャッシュミス
B->>D: クエリ実行
D-->>B: データ取得
B->>C: キャッシュ更新
end
B-->>F: レスポンス
F-->>U: 表示更新
備考: {この推測の根拠や確認が必要な理由}
信頼性: 🔵 アーキテクチャ設計より
{同期処理が必要な機能とその理由}
信頼性: 🟡 パフォーマンス要件から妥当な推測
{非同期処理が必要な機能とその理由}
信頼性: 🟡 要件から妥当な推測
{バッチ処理が必要な機能とその理由}
信頼性: 🟡 既存実装パターンから妥当な推測
flowchart TD
A[エラー発生] --> B{エラー種別}
B -->|バリデーションエラー| C[400 Bad Request]
B -->|認証エラー| D[401 Unauthorized]
B -->|権限エラー| E[403 Forbidden]
B -->|リソース未存在| F[404 Not Found]
B -->|サーバーエラー| G[500 Internal Server Error]
C --> H[エラーメッセージ返却]
D --> H
E --> H
F --> H
G --> I[ログ記録]
I --> H
H --> J[フロントエンドでエラー表示]
信頼性: 🔵 tech-stack.md・既存実装より
stateDiagram-v2
[*] --> 初期状態
初期状態 --> ローディング: データ取得開始
ローディング --> 成功: データ取得成功
ローディング --> エラー: データ取得失敗
成功 --> ローディング: 再取得
エラー --> ローディング: リトライ
信頼性: 🟡 要件から妥当な推測
{状態管理の詳細}
信頼性: 🟡 NFR要件から妥当な推測
品質評価: {高品質/要改善/要ヒアリング} </dataflow_template>
<design_interview_template>
作成日: {作成日時} ヒアリング実施: step4 既存情報ベースの差分ヒアリング
既存の要件定義・設計文書・実装を確認し、不明点や曖昧な部分を明確化するためのヒアリングを実施しました。
質問日時: {日時} カテゴリ: {アーキテクチャ/データモデル/技術選択/パフォーマンス/セキュリティ} 背景: {なぜこの質問が必要だったか}
回答: {ユーザーからの回答}
信頼性への影響:
質問日時: {日時} カテゴリ: {カテゴリ名} 背景: {背景説明}
回答: {ユーザーからの回答}
信頼性への影響:
ヒアリング前:
ヒアリング後:
<interfaces_template> /**
// ======================================== // エンティティ定義 // ========================================
/**
/**
// ======================================== // APIリクエスト/レスポンス // ========================================
/**
/**
/**
// ======================================== // 共通型定義 // ========================================
/**
/**
// ======================================== // 列挙型 // ========================================
/**
// ======================================== // ユーティリティ型 // ========================================
/**
/**
// ======================================== // 信頼性レベルサマリー // ======================================== /**
-- ======================================== -- テーブル定義 -- ========================================
-- {テーブル名1} -- 🔵 信頼性: 要件定義REQ-001・既存DBスキーマより CREATE TABLE {table_name1} ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), -- 🔵 既存DBスキーマの共通パターン {column1} VARCHAR(255) NOT NULL, -- 🔵 要件定義より {column2} INTEGER DEFAULT 0, -- 🟡 要件から妥当な推測 {column3} TIMESTAMP WITH TIME ZONE, -- 🔵 要件定義より created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, -- 🔵 共通パターン updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, -- 🔵 共通パターン
-- 制約
CONSTRAINT {constraint_name} CHECK ({column2} >= 0) -- 🔵 要件定義の制約より
);
-- {テーブル名2} -- 🟡 信頼性: 要件から妥当な推測 -- 備考: {確認が必要な理由} CREATE TABLE {table_name2} ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), -- 🔵 既存DBスキーマの共通パターン {column1} VARCHAR(255) UNIQUE NOT NULL, -- 🟡 要件から推測 {foreign_key_column} UUID REFERENCES {table_name1}(id), -- 🔵 リレーションシップより created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, -- 🔵 共通パターン updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP -- 🔵 共通パターン );
-- ======================================== -- インデックス -- ========================================
-- 検索パフォーマンス向上のためのインデックス -- 🔵 信頼性: パフォーマンス要件・既存DBスキーマより CREATE INDEX idx_{table_name1}_{column1} ON {table_name1}({column1}); -- 🔵 頻繁な検索条件より
-- 🟡 信頼性: パフォーマンス要件から妥当な推測 CREATE INDEX idx_{table_name2}_{column1} ON {table_name2}({column1}); -- 🟡 検索の可能性を考慮
-- ======================================== -- リレーションシップ（外部キー制約） -- ========================================
-- {table_name2} と {table_name1} の関連 -- 🔵 信頼性: データモデル設計・要件定義より ALTER TABLE {table_name2} ADD CONSTRAINT fk_{table_name2}_{table_name1} FOREIGN KEY ({foreign_key_column}) REFERENCES {table_name1}(id) ON DELETE CASCADE; -- 🔵 要件定義の削除動作より
-- ======================================== -- トリガー -- ========================================
-- updated_at 自動更新トリガー -- 🔵 信頼性: 既存DBスキーマの共通パターンより CREATE OR REPLACE FUNCTION update_updated_at_column() RETURNS TRIGGER AS $$ BEGIN NEW.updated_at = CURRENT_TIMESTAMP; RETURN NEW; END; $$ language 'plpgsql';
CREATE TRIGGER update_{table_name1}_updated_at BEFORE UPDATE ON {table_name1} FOR EACH ROW EXECUTE FUNCTION update_updated_at_column(); -- 🔵 共通パターン
-- ======================================== -- 初期データ（必要に応じて） -- ========================================
-- マスターデータの初期投入 -- 🔵 信頼性: 要件定義・既存データより INSERT INTO {table_name1} ({column1}, {column2}) VALUES ('{value1}', {num1}), -- 🔵 要件定義より ('{value2}', {num2}); -- 🔵 要件定義より
-- ======================================== -- パフォーマンス最適化 -- ========================================
-- ANALYZE文（統計情報更新） -- 🔵 信頼性: 既存DBスキーマの運用パターンより ANALYZE {table_name1}; ANALYZE {table_name2};
-- 品質評価: {高品質/要改善/要ヒアリング} </database_schema_template>
<api_endpoints_template>
作成日: {作成日時} 関連設計: architecture.md 関連要件定義: requirements.md
【信頼性レベル凡例】:
信頼性: 🔵 既存API仕様より
{base_url}/api/v1
信頼性: 🔵 アーキテクチャ設計・既存API仕様より
すべてのエンドポイント（一部の公開エンドポイントを除く）は認証が必要です。
Authorization: Bearer {jwt_token}
信頼性: 🔵 既存API仕様の共通パターンより
{
"success": false,
"error": {
"code": "ERROR_CODE",
"message": "エラーメッセージ",
"details": {}
}
}
信頼性: 🔵 既存API仕様の共通パターンより
リストを返すエンドポイントはページネーションをサポートします。
クエリパラメータ:
page: ページ番号（デフォルト: 1）limit: 1ページあたりの件数（デフォルト: 20、最大: 100）レスポンス形式:
{
"success": true,
"data": [...],
"pagination": {
"page": 1,
"limit": 20,
"total": 100
}
}
信頼性: 🔵 要件定義REQ-001・受け入れ基準TC-001より
関連要件: REQ-001
説明: ユーザーログイン
リクエスト:
{
"email": "user@example.com",
"password": "password123"
}
レスポンス（成功）:
{
"success": true,
"data": {
"token": "jwt-token-here",
"user": {
"id": "user-id",
"email": "user@example.com",
"name": "User Name"
}
}
}
エラーコード:
INVALID_CREDENTIALS: 認証情報が無効ACCOUNT_LOCKED: アカウントがロックされている信頼性: 🔵 要件定義REQ-002より
関連要件: REQ-002
説明: ユーザーログアウト
リクエスト: なし
レスポンス（成功）:
{
"success": true
}
信頼性: 🔵 要件定義REQ-101・API仕様より
関連要件: REQ-101
説明: {リソース}一覧取得
クエリパラメータ:
page (optional): ページ番号limit (optional): 1ページあたりの件数{filter_param} (optional): フィルター条件レスポンス（成功）:
{
"success": true,
"data": [
{
"id": "resource-id",
"field1": "value1",
"field2": "value2",
"createdAt": "2024-01-15T10:00:00Z",
"updatedAt": "2024-01-15T10:00:00Z"
}
],
"pagination": {
"page": 1,
"limit": 20,
"total": 100
}
}
信頼性: 🔵 要件定義REQ-102・受け入れ基準TC-102より
関連要件: REQ-102
説明: {リソース}詳細取得
パスパラメータ:
id: リソースIDレスポンス（成功）:
{
"success": true,
"data": {
"id": "resource-id",
"field1": "value1",
"field2": "value2",
"createdAt": "2024-01-15T10:00:00Z",
"updatedAt": "2024-01-15T10:00:00Z"
}
}
エラーコード:
RESOURCE_NOT_FOUND: リソースが見つからない信頼性: 🔵 要件定義REQ-103・受け入れ基準TC-103より
関連要件: REQ-103
説明: {リソース}作成
リクエスト:
{
"field1": "value1",
"field2": "value2"
}
レスポンス（成功）:
{
"success": true,
"data": {
"id": "new-resource-id",
"field1": "value1",
"field2": "value2",
"createdAt": "2024-01-15T10:00:00Z",
"updatedAt": "2024-01-15T10:00:00Z"
}
}
エラーコード:
VALIDATION_ERROR: バリデーションエラーDUPLICATE_RESOURCE: 重複エラー信頼性: 🟡 要件から妥当な推測
関連要件: REQ-104
説明: {リソース}更新
備考: {確認が必要な理由}
パスパラメータ:
id: リソースIDリクエスト:
{
"field1": "updated-value1",
"field2": "updated-value2"
}
レスポンス（成功）:
{
"success": true,
"data": {
"id": "resource-id",
"field1": "updated-value1",
"field2": "updated-value2",
"createdAt": "2024-01-15T10:00:00Z",
"updatedAt": "2024-01-15T12:00:00Z"
}
}
エラーコード:
RESOURCE_NOT_FOUND: リソースが見つからないVALIDATION_ERROR: バリデーションエラー信頼性: 🔵 要件定義REQ-105より
関連要件: REQ-105
説明: {リソース}削除
パスパラメータ:
id: リソースIDレスポンス（成功）:
{
"success": true
}
エラーコード:
RESOURCE_NOT_FOUND: リソースが見つからないRESOURCE_IN_USE: リソースが使用中のため削除不可信頼性: 🟡 NFR要件から妥当な推測
レート制限超過時のレスポンス:
{
"success": false,
"error": {
"code": "RATE_LIMIT_EXCEEDED",
"message": "レート制限を超過しました",
"details": {
"retryAfter": 60
}
}
}
信頼性: 🔵 既存API仕様より
APIバージョンはURLパスに含めます（例: /api/v1/）。
信頼性: 🔵 セキュリティ設計より
許可されたオリジン: {allowed_origins}
品質評価: {高品質/要改善/要ヒアリング} </api_endpoints_template>