菜单
SaaSサービス向けのサービス仕様書を作成します。運用設計書や要件定義書をインプットとして活用し、経済産業省「SaaS向けSLAガイドライン」に準拠したサービス仕様書を生成します。ガイドライン準拠の7カテゴリ（可用性、信頼性、データ管理、セキュリティ、サポート、拡張性、コンプライアンス）に加え、サービス概要・料金・責任分界を含む全10セクションを網羅します。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Jules REST APIを使用してタスクを対話的に依頼・管理する。セッション作成・プラン承認・メッセージ送信・進捗監視をAPI経由で行い、Claudeと協調してタスクを完遂する。ベースブランチ指定とPR自動作成に対応。認証はJULES_API_KEY_OP_URI（1Passwordシークレット参照）またはJULES_API_KEYで行う。Do NOT use for 認証情報未設定の環境でのタスク実行（task-executingを使用すること）。
SDDワークフロー全体を統括するオーケストレーター。要件定義・設計・タスク計画・実装・逆順レビューの一連のフローを管理する。新規プロジェクトのSDD一括作成、複数フェーズにまたがるワークフロー管理、エラー・バグの体系的な分析と修正に使用する。Do NOT use for 個別フェーズのみの作業（requirements-defining、software-designing、task-planningを直接使用すること）。
設計書から実装タスクへの分解を行う。デフォルトで各タスクをGitHub Issueとして起票し（1タスク＝1 Issue、詳細はIssue本文に集約、ラベルでフェーズ・ステータス管理）、ユーザーがファイル管理を明示した場合のみdocs/sdd/tasks/にファイル生成する。AIエージェント向けの具体的な実装指示やTDD手順を定義する。タスク計画フェーズのみを単独で実行する際に使用する。Do NOT use for SDDワークフロー全体の管理（sdd-documentationを使用すること）。
SDDドキュメントの整合性チェック、実装同期確認、アーカイブ（CLAUDE.md同期含む）、ファイル最適化を行う。ドキュメント間の矛盾検出、実装との乖離確認、完了タスクの整理と仕様のCLAUDE.md転記、肥大化ファイルの分割が必要な場合に使用する。Do NOT use for ドキュメントの新規作成（requirements-defining、software-designing、task-planningを使用すること）。
エラー・バグ・問題を体系的に分析し修正方針を策定する。テスト失敗、ビルドエラー、実行時エラー、動作不良、バグ報告に対応し、根本原因を分析してから修正を行う。Do NOT use for 根本原因分析が不要な軽微な修正（typo、設定値変更、フォーマット修正など）。
IPA非機能要求グレード2018（可用性・性能拡張性・運用保守性・移行性・セキュリティ・システム環境）の記入済み要件を入力として、運用設計書を生成する。非機能要件定義が完了しているプロジェクトの運用設計フェーズで使用する。Do NOT use for 非機能要件の定義自体（requirements-definingを使用すること）。Do NOT use for 業界調査やヒアリングから始める運用設計（operations-designを使用すること）。
| name | saas-spec-document |
| description | SaaSサービス向けのサービス仕様書を作成します。運用設計書や要件定義書をインプットとして活用し、経済産業省「SaaS向けSLAガイドライン」に準拠したサービス仕様書を生成します。ガイドライン準拠の7カテゴリ（可用性、信頼性、データ管理、セキュリティ、サポート、拡張性、コンプライアンス）に加え、サービス概要・料金・責任分界を含む全10セクションを網羅します。 |
SaaSサービス向けのサービス仕様書を作成するスキルです。運用設計書や要件定義書などの既存ドキュメントをインプットとして活用し、経済産業省「SaaS向けSLAガイドライン」に準拠した包括的なサービス仕様書を生成します。
このスキルは以下の機能を提供します：
以下の状況でこのスキルを有効にしてください：
「サービス仕様書を作成したい」「SLA文書を作成してほしい」などと依頼されたら：
インプットドキュメントの確認
基本情報のヒアリング
カテゴリ別の情報収集・抽出
サービス仕様書の作成
一貫性チェックとレビュー
運用設計書が提供された場合、以下の項目を抽出してサービス仕様書に反映します：
| 運用設計書のセクション | サービス仕様書への反映先 |
|---|---|
| SLO/SLI定義 | 3. 信頼性 - サービスレベル目標 |
| SLA定義 | 2. 可用性 - サービス稼働率 |
| 監視項目 | 3. 信頼性 - サービスレベル指標 |
| インシデント管理 | 3. 信頼性 - 障害時の対応時間 |
| バックアップ設計 | 4. データ管理 - バックアップ |
| DR設計 | 2. 可用性 - ディザスタリカバリ |
| セキュリティ運用 | 5. セキュリティ |
| 変更管理・リリース管理 | 2. 可用性 - アップグレード方針 |
| 運用体制 | 6. サポート - サポート体制 |
要件定義書が提供された場合、以下の項目を抽出してサービス仕様書に反映します：
| 要件定義書のセクション | サービス仕様書への反映先 |
|---|---|
| 非機能要件（可用性） | 2. 可用性 |
| 非機能要件（性能） | 3. 信頼性 - SLO |
| 非機能要件（セキュリティ） | 5. セキュリティ |
| 非機能要件（拡張性） | 7. 拡張性 |
| ユーザーストーリー | 1. サービス概要 - 主要なユースケース |
| 機能要件 | 1. サービス概要 - サービスの機能 |
1. インプットドキュメントの確認
- 運用設計書の読み込み
- 要件定義書の読み込み
- 抽出可能な情報の特定
↓
2. 基本情報のヒアリング
- サービス概要
- 対象顧客
- 料金プラン
↓
3. カテゴリ別情報の収集
- インプットからの抽出
- 不足情報のヒアリング
↓
4. サービス仕様書の段階的作成
- 各セクション作成
- ユーザー確認
- 修正・承認
↓
5. 一貫性チェック
- インプットとの整合性
- セクション間の整合性
↓
6. 最終レビューと承認
- 全体確認
- 最終承認
- ドキュメント完成
コンサルタント: サービス仕様書を作成するために、既存のドキュメントを確認させてください。
以下のドキュメントはお持ちですか？
A) 運用設計書
- SLO/SLI、監視項目、インシデント対応等の情報を抽出できます
B) 要件定義書
- 非機能要件、セキュリティ要件等の情報を抽出できます
C) その他の仕様書
- システム設計書、セキュリティポリシー等
お持ちのドキュメントを共有していただけますか？
または、ファイルパスを教えてください。
ユーザー: [回答またはファイル共有]
ドキュメント読み込み時の処理:
運用設計書が提供された場合：
コンサルタント: 運用設計書を確認しました。以下の情報を抽出できます：
【抽出可能な情報】
✅ SLO定義: 可用性99.9%、レスポンスタイム500ms以下
✅ 監視項目: [項目リスト]
✅ インシデント対応時間: P1=15分、P2=30分...
✅ バックアップ: 日次フル、6時間毎差分、30日保持
✅ DR構成: [構成内容]
これらの情報をサービス仕様書に反映してよろしいですか？
コンサルタント: （AskUserQuestionツールを使用）
サービスの基本情報を確認させてください。
Q1: サービス名を教えてください
Q2: サービスの提供形態はどれですか？
A) **マルチテナント型** ⭐⭐⭐⭐⭐
- 複数顧客が共有インフラを利用
- コスト効率が高い
推奨理由: SaaSの標準的な形態
考慮事項: テナント分離のセキュリティ説明が必要
B) **シングルテナント型** ⭐⭐⭐⭐
- 顧客ごとに専用環境を提供
- カスタマイズ性が高い
推奨理由: Enterprise向けで高セキュリティ
考慮事項: コストが高くなる傾向
C) **ハイブリッド型** ⭐⭐⭐
- プランにより選択可能
推奨理由: 柔軟な提供形態
考慮事項: 両方の仕様書記載が必要
ユーザー: [回答]
3-1. 可用性（Availability）
コンサルタント: 可用性に関する情報を確認します。
[運用設計書から抽出した場合]
運用設計書から以下の情報を抽出しました：
- サービス稼働率目標: 99.9%
- 計画メンテナンス: 毎週日曜02:00-06:00
この内容でサービス仕様書に記載してよろしいですか？
変更が必要な場合は教えてください。
[情報がない場合]
サービス稼働率（SLA）について確認させてください。
A) **99.9%** ⭐⭐⭐⭐⭐
- 月間ダウンタイム: 約43分
- 一般的なSaaSの標準
B) **99.95%** ⭐⭐⭐⭐
- 月間ダウンタイム: 約22分
- ミッションクリティカルなサービス向け
C) **99.99%** ⭐⭐⭐
- 月間ダウンタイム: 約4分
- 金融・医療等の高可用性要求向け
- コストと運用負荷が大幅に増加
どれを選択しますか？
3-2. セキュリティ（Security）
コンサルタント: セキュリティに関する情報を確認します。
[要件定義書から抽出した場合]
要件定義書から以下のセキュリティ要件を抽出しました：
- 認証: SSO対応、MFA必須
- 暗号化: TLS 1.3、AES-256
- アクセス制御: RBAC
追加で確認させてください。
Q1: 取得済みのセキュリティ認証はありますか？
- ISO/IEC 27001
- ISO/IEC 27017
- SOC 2 Type II
- CSマーク
- その他
Q2: データ保存場所について
A) 日本国内のみ ⭐⭐⭐⭐⭐
B) 日本国内優先（海外バックアップ可）⭐⭐⭐⭐
C) グローバル（顧客が選択可能）⭐⭐⭐
3-3. サポート（Support）
コンサルタント: サポート体制について確認します。
Q1: サポート時間はどのように設定しますか？
A) **24時間365日対応** ⭐⭐⭐⭐⭐
- 全時間帯でサポート対応
推奨理由: グローバルサービス、ミッションクリティカル向け
考慮事項: 運用コストが高い
B) **平日営業時間（9:00-18:00 JST）** ⭐⭐⭐⭐
- 営業時間内のみ対応
- 緊急時は別途対応
推奨理由: 一般的なB2B SaaS向け
考慮事項: 緊急対応の定義が必要
C) **プラン別対応** ⭐⭐⭐⭐
- Basic: 平日営業時間
- Enterprise: 24/365
推奨理由: 柔軟な料金体系
考慮事項: プラン別の詳細定義が必要
各カテゴリの情報収集後、サービス仕様書を段階的に作成します。
コンサルタント: 収集した情報を基に、サービス仕様書の「2. 可用性」セクションを作成しました。
[作成した内容を提示]
内容を確認していただけますか？
- 承認して次のセクションに進む
- 修正が必要
ユーザー: [回答]
コンサルタント: サービス仕様書の全セクションが完成しました。
一貫性チェックを実施します。
【一貫性チェック結果】
✅ 整合性が確認できた項目:
1. SLA 99.9%に対して、運用設計書のSLOと整合
2. バックアップRPO 6時間は運用設計書の設定と一致
3. インシデント対応時間はサポートSLAと整合
⚠️ 確認が必要な項目:
1. DR構成のRTO 4時間とSLA可用性99.9%の整合性
→ 月間43分のダウンタイム許容に対して、DR発動時の
4時間復旧は許容範囲か確認が必要です
2. セキュリティ認証「ISO 27001」は取得済みとのことですが、
有効期限を確認させてください
これらの点について確認させてください。
本スキルは経済産業省「SaaS向けSLAガイドライン」に準拠し、以下の7カテゴリをカバーします（加えてサービス概要、料金・課金、責任分界の3セクションを追加）：
可用性（Availability）
信頼性（Reliability）
データ管理（Data Management）
セキュリティ（Security）
サポート（Support）
拡張性（Scalability）
コンプライアンス（Compliance）
このスキルは推測や推論を避け、事実に基づいた仕様書を作成します：
実施すること:
実施しないこと:
運用設計書や要件定義書が提供された場合：
サービス仕様書は以下の順序で段階的に作成：
すべてのSLA項目は具体的かつ測定可能な形で記載：
良い例:
悪い例:
service_specification_template_ja.md: SaaSサービス仕様書テンプレート推測や推論
一方的な進行
非現実的なSLA設定
以下の場合は作業を進めず、ユーザーに確認：
インプットドキュメントが不完全
SLA条件が未定義
矛盾する情報
このスキルは将来的に以下の機能を追加予定です：