SaaSサービス向けのサービス仕様書を作成します。運用設計書や要件定義書をインプットとして活用し、経済産業省「SaaS向けSLAガイドライン」に準拠したサービス仕様書を生成します。
ガイドライン準拠の7カテゴリ（可用性、信頼性、データ管理、セキュリティ、サポート、拡張性、コンプライアンス）に加え、サービス概要・料金・責任分界を含む全10セクションを網羅します。
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
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条件が未定義
矛盾する情報
このスキルは将来的に以下の機能を追加予定です：
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
指定されたPRを6観点（セキュリティ、ドキュメント乖離、可読性、ライブラリ選定、PR説明、既知脆弱性）でレビューし、人間向け・AI向けの2形式でPRにコメントする。初回レビューおよび修正後の再レビューに使用する。Do NOT use for レビューコメントへの修正適用（pr-comment-fixerを使用すること）。
The English summary is being prepared. Showing the original description.
キャリア設計のためのデプスインタビューを実施し、本人の価値観・強み・動機を引き出す。5 Whys、ラダリング法を用いてキャリアビジョンの明確化を支援する。転職相談、自己理解、キャリアカウンセリング、1on1面談の深掘りに使用する。Do NOT use for 製品・サービスのユーザーリサーチ（depth-interviewing-productを使用すること）。
The English summary is being prepared. Showing the original description.
サービス開発のためのデプスインタビューを実施し、ユーザーの真のニーズ・課題・動機を引き出す。5 Whys、ラダリング法を用いてプロダクト開発に活かせるインサイトを発見する。ユーザーリサーチ、課題発見、ペルソナ構築、プロダクト仮説検証に使用する。Do NOT use for キャリア相談やキャリアカウンセリング（depth-interviewing-careerを使用すること）。
The English summary is being prepared. Showing the original description.
インフラメトリクスの定期調査を体系的に実施し、サービスの健全性を評価する。2層アプローチで11カテゴリのメトリクスを確認し、構造化レポートを作成する。定期的なサービス監視、障害予兆の検出、パフォーマンス評価に使用する。Do NOT use for 個別インシデントの根本原因分析（incident-rcaを使用すること）。
The English summary is being prepared. Showing the original description.
インシデント調査で根本原因を特定するためのなぜなぜ分析ファシリテーター。推測を避け、ユーザーの発言を記録し、マインドツリーで全体を可視化する。障害発生後の原因究明、ポストモーテム、再発防止策の策定に使用する。Do NOT use for 定期的なサービス健全性チェック（health-checkを使用すること）。
The English summary is being prepared. Showing the original description.
IPA非機能要求グレード2018（可用性・性能拡張性・運用保守性・移行性・セキュリティ・システム環境）の記入済み要件を入力として、運用設計書を生成する。非機能要件定義が完了しているプロジェクトの運用設計フェーズで使用する。Do NOT use for 非機能要件の定義自体（requirement-managementを使用すること）。Do NOT use for 業界調査やヒアリングから始める運用設計（operations-designを使用すること）。
The English summary is being prepared. Showing the original description.