무료GitHub에 공개

saas-spec-document

SaaSサービス向けのサービス仕様書を作成します。運用設計書や要件定義書をインプットとして活用し、経済産業省「SaaS向けSLAガイドライン」に準拠したサービス仕様書を生成します。

ガイドライン準拠の7カテゴリ（可用性、信頼性、データ管理、セキュリティ、サポート、拡張性、コンプライアンス）に加え、サービス概要・料金・責任分界を含む全10セクションを網羅します。

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

windschord/claude_skils

설치 방법 보기

포함된 파일(2)

SKILL.md18.2 KB
assets/templates/service_specification_template_ja.md24.8 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

SaaSサービス仕様書作成スキル

SaaSサービス向けのサービス仕様書を作成するスキルです。運用設計書や要件定義書などの既存ドキュメントをインプットとして活用し、経済産業省「SaaS向けSLAガイドライン」に準拠した包括的なサービス仕様書を生成します。

概要

このスキルは以下の機能を提供します：

運用設計書からのSLO/SLI、監視項目、インシデント対応情報の抽出
要件定義書からの非機能要件、セキュリティ要件の抽出
経済産業省ガイドラインに準拠したサービス仕様書の作成
ガイドライン準拠の7カテゴリ＋追加3セクション（サービス概要、料金・課金、責任分界）の計10セクションを網羅
不足情報のヒアリングと補完
一貫性チェックと客観的レビュー

このスキルを使用する場面

以下の状況でこのスキルを有効にしてください：

サービス仕様書の新規作成時

新規SaaSサービスのサービス仕様書が必要な場合
既存サービスのサービス仕様書を整備したい場合
顧客向けSLA文書を作成したい場合

既存ドキュメントからの変換時

運用設計書からサービス仕様書を作成したい場合
要件定義書からサービス仕様書を作成したい場合
複数のドキュメントを統合してサービス仕様書にまとめたい場合

更新・改訂時

サービス仕様書の内容を更新したい場合
SLA条件を変更したい場合
新機能追加に伴う仕様書の改訂が必要な場合

基本的な使い方

サービス仕様書作成の開始

「サービス仕様書を作成したい」「SLA文書を作成してほしい」などと依頼されたら：

インプットドキュメントの確認
- 運用設計書の有無と内容確認
- 要件定義書の有無と内容確認
- その他の関連ドキュメントの確認
基本情報のヒアリング
- サービス名と概要
- 対象顧客と提供形態
- 料金プランの構成
カテゴリ別の情報収集・抽出
- 可用性要件
- 信頼性要件
- データ管理要件
- セキュリティ要件
- サポート体制
- 拡張性・API仕様
- コンプライアンス要件
サービス仕様書の作成
- テンプレートに基づいて段階的に作成
- 各セクションについてユーザーに確認
- 不明点は必ず質問
一貫性チェックとレビュー
- 運用設計書との整合性確認
- 要件定義書との整合性確認
- 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. 最終レビューと承認
   - 全体確認
   - 最終承認
   - ドキュメント完成

詳細な実行手順

ステップ1: インプットドキュメントの確認

コンサルタント: サービス仕様書を作成するために、既存のドキュメントを確認させてください。

                以下のドキュメントはお持ちですか？

                A) 運用設計書
                   - SLO/SLI、監視項目、インシデント対応等の情報を抽出できます

                B) 要件定義書
                   - 非機能要件、セキュリティ要件等の情報を抽出できます

                C) その他の仕様書
                   - システム設計書、セキュリティポリシー等

                お持ちのドキュメントを共有していただけますか？
                または、ファイルパスを教えてください。

ユーザー: [回答またはファイル共有]

ドキュメント読み込み時の処理:

運用設計書が提供された場合：

コンサルタント: 運用設計書を確認しました。以下の情報を抽出できます：

                【抽出可能な情報】
                ✅ SLO定義: 可用性99.9%、レスポンスタイム500ms以下
                ✅ 監視項目: [項目リスト]
                ✅ インシデント対応時間: P1=15分、P2=30分...
                ✅ バックアップ: 日次フル、6時間毎差分、30日保持
                ✅ DR構成: [構成内容]

                これらの情報をサービス仕様書に反映してよろしいですか？

ステップ2: 基本情報のヒアリング

コンサルタント: （AskUserQuestionツールを使用）
                サービスの基本情報を確認させてください。

                Q1: サービス名を教えてください

                Q2: サービスの提供形態はどれですか？

                A) **マルチテナント型** ⭐⭐⭐⭐⭐
                   - 複数顧客が共有インフラを利用
                   - コスト効率が高い

                   推奨理由: SaaSの標準的な形態
                   考慮事項: テナント分離のセキュリティ説明が必要

                B) **シングルテナント型** ⭐⭐⭐⭐
                   - 顧客ごとに専用環境を提供
                   - カスタマイズ性が高い

                   推奨理由: Enterprise向けで高セキュリティ
                   考慮事項: コストが高くなる傾向

                C) **ハイブリッド型** ⭐⭐⭐
                   - プランにより選択可能

                   推奨理由: 柔軟な提供形態
                   考慮事項: 両方の仕様書記載が必要

ユーザー: [回答]

ステップ3: カテゴリ別情報の収集

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

                   推奨理由: 柔軟な料金体系
                   考慮事項: プラン別の詳細定義が必要

ステップ4: サービス仕様書の段階的作成

各カテゴリの情報収集後、サービス仕様書を段階的に作成します。

コンサルタント: 収集した情報を基に、サービス仕様書の「2. 可用性」セクションを作成しました。

                [作成した内容を提示]

                内容を確認していただけますか？

                - 承認して次のセクションに進む
                - 修正が必要

ユーザー: [回答]

ステップ5: 一貫性チェック

コンサルタント: サービス仕様書の全セクションが完成しました。
                一貫性チェックを実施します。

                【一貫性チェック結果】

                ✅ 整合性が確認できた項目:
                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ガイドライン（2008年）

本スキルは経済産業省「SaaS向けSLAガイドライン」に準拠し、以下の7カテゴリをカバーします（加えてサービス概要、料金・課金、責任分界の3セクションを追加）：

可用性（Availability）
- サービス時間
- 計画停止予定通知
- サービス提供終了時の事前通知
- 突然のサービス提供停止に対する対処
- サービス稼働率
- ディザスタリカバリ
- 重大障害時の代替手段
- アップグレード方針
信頼性（Reliability）
- サービスレベル目標（SLO）
- サービスレベル指標（SLI）
- エラーバジェット
- 障害時の対応時間
データ管理（Data Management）
- データの取り扱い
- バックアップ
- データ復旧目標（RTO/RPO）
- データ暗号化
- 解約時のデータ取り扱い
セキュリティ（Security）
- セキュリティ認証・認定
- 通信セキュリティ
- 認証・認可
- マルチテナントセキュリティ
- 脆弱性管理
- セキュリティインシデント対応
サポート（Support）
- サポート体制
- サポートチャネル
- サポート対応レベル
- セルフサービス
拡張性（Scalability）
- カスタマイズ性
- 外部接続性（API）
- API制限
- リソース上限
コンプライアンス（Compliance）
- 法令遵守
- 監査対応
- 監査ログ
- データ所在地

原則とガイドライン

1. 推論の禁止

このスキルは推測や推論を避け、事実に基づいた仕様書を作成します：

実施すること:

インプットドキュメントから正確に情報を抽出
不明な点はユーザーに確認
具体的な数値と条件を記載

実施しないこと:

「おそらく〜だろう」と推測する
インプットにない情報を勝手に補完する
曖昧な表現でごまかす

2. インプット優先の原則

運用設計書や要件定義書が提供された場合：

まずインプットから情報を抽出
抽出した情報をユーザーに確認
承認を得てからサービス仕様書に反映
不足情報のみヒアリングで補完

3. 段階的な作成と確認

サービス仕様書は以下の順序で段階的に作成：

サービス概要 → ユーザー確認
可用性 → ユーザー確認
信頼性 → ユーザー確認
データ管理 → ユーザー確認
セキュリティ → ユーザー確認
サポート → ユーザー確認
拡張性 → ユーザー確認
コンプライアンス → ユーザー確認
料金・課金 → ユーザー確認
責任分界 → ユーザー確認
一貫性チェック → 最終承認

4. 具体性と測定可能性

すべてのSLA項目は具体的かつ測定可能な形で記載：

良い例:

可用性: 99.9%（月間ダウンタイム43分以内）
レスポンスタイム: P95で500ms以下
初回応答時間: 緊急は1時間以内、通常は4時間以内

悪い例:

可用性: 高い可用性を維持
レスポンスタイム: 十分な速度で応答
初回応答時間: 迅速に対応

リソース

assets/templates/

service_specification_template_ja.md: SaaSサービス仕様書テンプレート

制約事項

実施しないこと

推測や推論
- インプットにない情報の補完
- 曖昧な条件の勝手な解釈
一方的な進行
- ユーザー確認なしの次セクション移行
- 重要な決定の独断
非現実的なSLA設定
- 運用設計書と整合しないSLA
- 実現不可能な目標値

情報不足時の対応

以下の場合は作業を進めず、ユーザーに確認：

インプットドキュメントが不完全
- 「運用設計書の〜セクションが不足しています。確認させてください」
SLA条件が未定義
- 「可用性目標が未定義です。以下から選択していただけますか？」
矛盾する情報
- 「運用設計書と要件定義書で〜が矛盾しています。どちらが正しいか確認させてください」

今後の拡張

このスキルは将来的に以下の機能を追加予定です：

多言語対応（英語版テンプレート）
業界別テンプレート（金融、医療、教育等）
SLA自動計算機能
コンプライアンスチェックリスト自動生成
顧客向け公開版の自動生成

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

같은 저장소의 스킬

ai-code-review

무료

指定されたPRを6観点（セキュリティ、ドキュメント乖離、可読性、ライブラリ選定、PR説明、既知脆弱性）でレビューし、人間向け・AI向けの2形式でPRにコメントする。初回レビューおよび修正後の再レビューに使用する。Do NOT use for レビューコメントへの修正適用（pr-comment-fixerを使用すること）。

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

windschord/claude_skils92026년 10월 19일 업데이트

depth-interviewing-career

무료

キャリア設計のためのデプスインタビューを実施し、本人の価値観・強み・動機を引き出す。5 Whys、ラダリング法を用いてキャリアビジョンの明確化を支援する。転職相談、自己理解、キャリアカウンセリング、1on1面談の深掘りに使用する。Do NOT use for 製品・サービスのユーザーリサーチ（depth-interviewing-productを使用すること）。

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

windschord/claude_skils92026년 10월 19일 업데이트

depth-interviewing-product

무료

サービス開発のためのデプスインタビューを実施し、ユーザーの真のニーズ・課題・動機を引き出す。5 Whys、ラダリング法を用いてプロダクト開発に活かせるインサイトを発見する。ユーザーリサーチ、課題発見、ペルソナ構築、プロダクト仮説検証に使用する。Do NOT use for キャリア相談やキャリアカウンセリング（depth-interviewing-careerを使用すること）。

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

windschord/claude_skils92026년 10월 19일 업데이트

health-check

무료

インフラメトリクスの定期調査を体系的に実施し、サービスの健全性を評価する。2層アプローチで11カテゴリのメトリクスを確認し、構造化レポートを作成する。定期的なサービス監視、障害予兆の検出、パフォーマンス評価に使用する。Do NOT use for 個別インシデントの根本原因分析（incident-rcaを使用すること）。

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

windschord/claude_skils92026년 10월 19일 업데이트

incident-rca

무료

インシデント調査で根本原因を特定するためのなぜなぜ分析ファシリテーター。推測を避け、ユーザーの発言を記録し、マインドツリーで全体を可視化する。障害発生後の原因究明、ポストモーテム、再発防止策の策定に使用する。Do NOT use for 定期的なサービス健全性チェック（health-checkを使用すること）。

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

windschord/claude_skils92026년 10월 19일 업데이트

IPA非機能要求グレード2018（可用性・性能拡張性・運用保守性・移行性・セキュリティ・システム環境）の記入済み要件を入力として、運用設計書を生成する。非機能要件定義が完了しているプロジェクトの運用設計フェーズで使用する。Do NOT use for 非機能要件の定義自体（requirement-managementを使用すること）。Do NOT use for 業界調査やヒアリングから始める運用設計（operations-designを使用すること）。

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

windschord/claude_skils92026년 10월 19일 업데이트

windschord의 스킬 모두 보기

이 스킬의 문제 신고

설치

명령으로 설치

npx skills add https://github.com/windschord/claude_skils --skill saas-spec-document

터미널에 붙여 넣고 실행합니다(Node.js 필요). Claude Code, Codex 등 설치할 에이전트를 고를 수 있습니다.

에이전트에게 부탁하기

다음 Agent Skill을 설치해 주세요.
https://github.com/windschord/claude_skils/tree/main/saas/saas-spec-document

먼저 SKILL.md와 첨부 파일의 내용을 확인해 수상한 처리(외부 전송, 인증 정보 읽기 등)가 없는지 확인한 뒤 Claude Code는 ~/.claude/skills/saas-spec-document/, Codex는 ~/.agents/skills/saas-spec-document/ 에 배치해 주세요.

이 문장을 그대로 Claude Code나 Codex에 보내면 내용을 확인한 뒤 설치해 줍니다.

GitHub에서 소스 보기

저장소: windschord/claude_skils
스타: 9
포크: 4
카테고리: 테스트·보안
라이선스: Apache-2.0
원문 언어: 일본어
최종 업데이트: 2026년 10월 19일

스킬은 에이전트를 위한 지시와 스크립트의 묶음입니다. cccskills는 내용의 안전성을 보증하지 않습니다. 설치하기 전에 내용을 확인하세요.

포함된 파일(2)

SKILL.md(원문)

SaaSサービス仕様書作成スキル

概要

このスキルを使用する場面

サービス仕様書の新規作成時

既存ドキュメントからの変換時

更新・改訂時

基本的な使い方

サービス仕様書作成の開始

インプットドキュメントの活用

運用設計書からの抽出項目

要件定義書からの抽出項目

ワークフロー

基本的な作業フロー

詳細な実行手順

ステップ1: インプットドキュメントの確認

ステップ2: 基本情報のヒアリング

ステップ3: カテゴリ別情報の収集

ステップ4: サービス仕様書の段階的作成

ステップ5: 一貫性チェック

経済産業省ガイドライン準拠

SaaS向けSLAガイドライン（2008年）

原則とガイドライン

1. 推論の禁止

2. インプット優先の原則

3. 段階的な作成と確認

4. 具体性と測定可能性

リソース

assets/templates/

関連ガイドライン

制約事項

実施しないこと

情報不足時の対応

今後の拡張

리뷰

댓글

같은 저장소의 스킬

ai-code-review

depth-interviewing-career

depth-interviewing-product

health-check

incident-rca

ipa-nfr-operations-design