仕様書の作成

${input:SpecPurpose} 用の新しい仕様ファイルを作成することが目標です。

仕様ファイルは、ソリューション コンポーネントの要件、制約、およびインターフェースを、生成 AI による効果的な使用に適した明確で曖昧さのない構造化された方法で定義する必要があります。確立されたドキュメント標準に従い、コンテンツが機械可読で自己完結していることを確認してください。

AI 対応仕様書のベストプラクティス

• 正確で明示的で曖昧さのない言語を使用してください。
• 要件、制約、推奨事項を明確に区別してください。
• 構造化されたフォーマット (見出し、リスト、表) を使用して、解析しやすくしてください。
• 慣用句、隠喩、または文脈依存の参照を避けてください。
• すべての頭字語およびドメイン固有の用語を定義してください。
• 該当する場合は、例とエッジ ケースを含めてください。
• ドキュメントが自己完結していることを確認し、外部のコンテキストに依存しないようにしてください。

仕様ファイルは /spec/ ディレクトリに保存し、以下の規則に従って命名してください: spec-[a-z0-9-]+.md。名前は仕様書の内容を説明する必要があり、高レベルの目的で始まります。目的は [schema, tool, data, infrastructure, process, architecture, または design] のいずれかです。

仕様ファイルは、整形式の Markdown でフォーマットされている必要があります。

仕様ファイルは下記のテンプレートに従う必要があり、すべてのセクションが適切に入力されていることを確認してください。Markdown のフロント マターは、以下の例に従って適切に構造化する必要があります:

---
title: [仕様書の焦点を説明する簡潔なタイトル]
version: [オプション: 例: 1.0, 日付]
date_created: [YYYY-MM-DD]
last_updated: [オプション: YYYY-MM-DD]
owner: [オプション: この仕様書の責任者となるチーム/個人]
tags: [オプション: 関連するタグまたはカテゴリのリスト。例: `infrastructure`, `process`, `design`, `app` など]
---

# 序文

[仕様書の簡潔な紹介と、それが達成することを意図した目標。]

## 1. 目的と範囲

[仕様書の目的とその適用範囲の明確で簡潔な説明。意図する対象者と想定を述べてください。]

## 2. 定義

[この仕様書で使用されているすべての頭字語、略語、およびドメイン固有の用語をリストアップして定義してください。]

## 3. 要件、制約、およびガイドライン

[すべての要件、制約、ルール、およびガイドラインを明示的にリストアップしてください。わかりやすくするために箇条書きまたは表を使用してください。]

- **REQ-001**: 要件 1
- **SEC-001**: セキュリティ要件 1
- **[3 LETTERS]-001**: その他の要件 1
- **CON-001**: 制約 1
- **GUD-001**: ガイドライン 1
- **PAT-001**: 従うべきパターン 1

## 4. インターフェースとデータ契約

[インターフェース、API、データ契約、または統合ポイントを説明してください。スキーマと例には表またはコード ブロックを使用してください。]

## 5. 受け入れ基準

[各要件の明確でテスト可能な受け入れ基準を、必要に応じて Given-When-Then フォーマットを使用して定義してください。]

- **AC-001**: [コンテキスト] が与えられたとき、[アクション] が実行されると、[期待される結果] となる
- **AC-002**: システムは [条件] の場合に [特定の動作] を実行しなければならない
- **AC-003**: [必要に応じて追加の受け入れ基準]

## 6. テスト自動化戦略

[テストアプローチ、フレームワーク、および自動化要件を定義してください。]

- **テスト レベル**: ユニット、統合、エンドツーエンド
- **フレームワーク**: MSTest、FluentAssertions、Moq (.NET アプリケーション用)
- **テスト データ管理**: [テスト データ作成およびクリーンアップのアプローチ]
- **CI/CD 統合**: [GitHub Actions パイプラインでの自動テスト]
- **カバレッジ要件**: [最小コード カバレッジ閾値]
- **パフォーマンス テスト**: [負荷およびパフォーマンス テストのアプローチ]

## 7. 根拠と文脈

[要件、制約、およびガイドラインの背後にある理論的根拠を説明してください。設計判断の文脈を提供してください。]

## 8. 依存関係と外部統合

[この仕様書に必要な外部システム、サービス、およびアーキテクチャ上の依存関係を定義してください。実装方法ではなく、必要なもの に焦点を当ててください。特定のパッケージまたはライブラリのバージョンを避けてください。アーキテクチャ上の制約を表す場合を除きます。]

### 外部システム
- **EXT-001**: [外部システム名] - [目的と統合タイプ]

### サードパーティ サービス
- **SVC-001**: [サービス名] - [必要な機能と SLA 要件]

### インフラストラクチャ依存関係
- **INF-001**: [インフラストラクチャ コンポーネント] - [要件と制約]

### データ依存関係
- **DAT-001**: [外部データ ソース] - [フォーマット、頻度、およびアクセス要件]

### テクノロジー プラットフォーム依存関係
- **PLT-001**: [プラットフォーム/ランタイム要件] - [バージョン制約と根拠]

### コンプライアンス依存関係
- **COM-001**: [規制またはコンプライアンス要件] - [実装への影響]

**注**: このセクションは、特定のパッケージ実装ではなく、アーキテクチャおよびビジネス依存関係に焦点を当てるべきです。例えば、「Microsoft.AspNetCore.Authentication.JwtBearer v6.0.1」ではなく「OAuth 2.0 認証ライブラリ」と指定してください。

## 9. 例とエッジ ケース

    ```code
    // エッジケースを含め、ガイドラインの正しい適用を示すコード スニペットまたはデータ例
    ```

## 10. 検証基準

[この仕様書への準拠のために満たす必要がある基準またはテストをリストアップしてください。]

## 11. 関連仕様 / 参考資料

[関連仕様 1 へのリンク]
[関連する外部ドキュメントへのリンク]