القائمة
運用設計コンサルタントとして、対象業界の調査とヒアリングに基づきITIL 4・SRE・DevOpsベストプラクティスの運用設計書を作成する。新規サービスの運用設計、既存システムの運用改善、運用移管の準備に使用する。Do NOT use for ソフトウェアの機能設計（software-designingを使用すること）。
التثبيت باستخدام 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 | operations-design |
| description | 運用設計コンサルタントとして、対象業界の調査とヒアリングに基づきITIL 4・SRE・DevOpsベストプラクティスの運用設計書を作成する。新規サービスの運用設計、既存システムの運用改善、運用移管の準備に使用する。Do NOT use for ソフトウェアの機能設計（software-designingを使用すること）。 |
| metadata | {"version":"1.0.0"} |
運用設計の専門コンサルタントとして、サービスやシステムの運用設計書を作成します。対象業界の最新トレンドを調査し、ITIL 4、SRE、DevOpsの最新フレームワークとベストプラクティスを活用して、実践的で高品質な運用設計を提供します。
このスキルは以下の機能を提供します:
| 入力 | 必須/任意 | 説明 |
|---|---|---|
| サービス概要 | 必須 | サービスの目的、対象ユーザー、提供価値 |
| システム構成情報 | 必須 | アーキテクチャ、技術スタック、インフラパターン |
| 運用要件 | 必須 | 可用性目標、サービス提供時間、セキュリティ要件 |
| 既存ドキュメント | 任意 | システム設計書、要件定義書、既存運用設計書 |
| 業界情報 | 任意 | 対象業界、規制要件、コンプライアンス要件 |
| 出力 | 形式 | 説明 |
|---|---|---|
| 運用設計書 | Markdown | 20セクションの包括的な運用設計ドキュメント |
| 会話ログ | Markdown | ヒアリング内容と決定事項の記録 |
このスキルが行うこと:
このスキルが行わないこと:
以下の状況でこのスキルを有効にしてください:
「運用設計書を作成したい」「運用設計を支援してほしい」などと依頼されたら:
業界トレンドの調査
サービス仕様のヒアリング
運用設計書の作成
一貫性チェックとレビュー
このスキルは推測や推論を避け、事実に基づいた設計を行います:
実施すること:
実施しないこと:
良い例:
コンサルタント: サービスの可用性目標について確認させてください。
以下のどれに該当しますか？
A) 99.9%（月間ダウンタイム約43分） - Webサービスの一般的な目標
B) 99.95%（月間ダウンタイム約22分） - ミッションクリティカルなサービス
C) 99.99%（月間ダウンタイム約4分） - 金融サービス等の高可用性要求
D) その他（具体的な目標値をお聞かせください）
悪い例:
コンサルタント: Webサービスなので、一般的に99.9%の可用性で良いと思います。
これで進めます。
サービス仕様を段階的かつ体系的にヒアリングします:
【重要】すべてのヒアリングはAskUserQuestionツールを使用して実施すること
ヒアリングの流れ:
サービス設計書の有無確認
まず、既存のドキュメントについて確認させてください。
以下のドキュメントはお持ちですか？
- システム設計書
- アーキテクチャ図
- 要件定義書
- サービス仕様書
これらがあれば、内容を共有していただけますか？
基本情報の収集
技術情報の収集
運用要件の収集
運用設計を開始する前に、必ず業界の最新トレンドを調査します:
調査項目:
調査方法:
WebSearchツールを使用して以下を調査:
1. "[業界名] 運用設計 最新トレンド"
2. "[サービス種別] SRE DevOps ベストプラクティス 最新"
3. "[業界名] セキュリティ コンプライアンス 最新"
調査結果の提示:
[業界名]の最新トレンド調査結果をまとめました。
【主要トレンド】
1. [トレンド1]
- 概要: [説明]
- 本サービスへの適用: [提案]
2. [トレンド2]
- 概要: [説明]
- 本サービスへの適用: [提案]
これらのトレンドを運用設計に反映させることを推奨しますが、
貴社の状況に照らして、どのトレンドを採用すべきか確認させてください。
設計書作成後、内容の一貫性を客観的にレビューします:
レビュー観点:
SLO/SLI/SLAの整合性
運用体制と作業内容の整合性
監視とインシデント対応の整合性
変更管理とリリース管理の整合性
レビュー実施方法:
運用設計書のレビューを実施します。
【レビュー結果】
✅ 整合性が取れている項目:
- [項目1]: [確認内容]
- [項目2]: [確認内容]
⚠️ 矛盾または不明確な項目:
- [項目1]: [矛盾内容] → [確認事項]
- [項目2]: [不明確な点] → [質問]
以下の点について確認させてください:
[質問リスト]
flowchart TD
A[0. 会話ログの初期化] --> B[0.5. インフラパターンの選択]
B --> C[1. 業界トレンド調査]
C --> D[2. サービス仕様のヒアリング]
D --> E[3. 運用設計書の作成]
E --> F[4. 各セクションでのユーザー確認]
F --> G[5. 一貫性チェック]
G --> H[6. 最終レビューと承認]
A -.- A1[会話ログファイルの作成<br/>セッション情報の記録]
B -.- B1[クラウドネイティブ/IaaS/オンプレミス<br/>適切なテンプレートの選択]
C -.- C1[対象業界の調査<br/>調査結果を会話ログに記録]
D -.- D1[既存ドキュメントの確認<br/>各質問と回答を会話ログに記録]
E -.- E1[概要・SLO/SLI・運用体制<br/>各セクションの承認状況を記録]
F -.- F1[内容の確認・修正・承認<br/>確認結果を会話ログに記録]
G -.- G1[矛盾の検出・修正提案<br/>チェック結果を会話ログに記録]
H -.- H1[全体の整合性確認<br/>最終的な決定事項を記録]
【重要】運用設計セッション開始時に必ず実行すること
コンサルタント: 運用設計のご依頼ありがとうございます。
セッションを開始する前に、会話ログファイルを作成します。
このファイルに、これからのすべてのヒアリング内容、
調査結果、決定事項を記録していきます。
[Writeツールでconversation_log_template_ja.mdを基に
会話ログファイルを作成]
会話ログファイルを作成しました：
`[YYYY-MM-DD]-[サービス名]-conversation-log.md`
このファイルにすべての情報を記録しますので、
長期間のセッションでもコンテキストを失うことなく
進めることができます。
それでは、インフラパターンの確認から開始させてください。
作成するファイルの内容:
assets/templates/conversation_log_template_ja.md[YYYY-MM-DD]-[サービス名]-conversation-log.md【重要】新規構築か移行案件かで、以降のヒアリング内容が大きく変わる
コンサルタント: （AskUserQuestionツールを使用）
運用設計を始める前に、プロジェクトの性質を確認させてください。
このプロジェクトはどれに該当しますか？
A) **完全新規構築** ⭐⭐⭐⭐⭐
- ゼロからシステムを構築
- 既存システムの制約なし
- 最新技術を自由に選択可能
推奨理由: クラウドネイティブ技術を最大限活用できる
考慮事項: 運用ノウハウを一から構築する必要がある
B) **オンプレミスからクラウド移行（Lift & Shift）** ⭐⭐⭐⭐
- 既存のオンプレミスシステムをクラウドへ移行
- アプリケーションは基本的に変更せず、インフラのみ移行
- 段階的な移行を計画
推奨理由: 移行リスクを最小化、短期間で移行可能
考慮事項: 現行運用の課題、移行制約のヒアリングが必須
C) **既存クラウドサービスのリプラットフォーム** ⭐⭐⭐
- 既にクラウドで稼働中
- アーキテクチャを刷新（例: EC2ベース → サーバレス）
- クラウドネイティブ化を推進
推奨理由: クラウド活用の最適化、コスト削減
考慮事項: 既存運用の課題分析が必須
D) **既存システムの運用設計見直し** ⭐⭐⭐⭐
- システムは既に稼働中
- 運用プロセス・体制の改善が目的
- システム構成の大きな変更はなし
推奨理由: 運用品質の向上、コスト最適化
考慮事項: 現行運用の詳細な分析が必須
ユーザー: [回答]
コンサルタント: ありがとうございます。[選択されたパターン]のプロジェクトですね。
[Editツールで会話ログに記録]
[B、C、Dを選択した場合]
既存システムについて、追加で確認させてください：
Q1: 現行システムの運用課題は何ですか？
- 可用性の問題
- パフォーマンスの問題
- 運用コストの問題
- 運用負荷の問題
- その他
Q2: 現行の運用ドキュメントはありますか？
- 運用設計書: 有/無
- 運用手順書: 有/無
- 障害対応手順書: 有/無
- インシデント履歴: 有/無
Q3: 移行スケジュールの制約はありますか？
- 移行期限: [日付]
- ダウンタイム許容時間: [時間]
- 段階的移行の可否: 可/不可
それでは、次に予算とスケジュールを確認させてください。
会話ログへの記録内容:
### [HH:MM] プロジェクト性質の確認
**プロジェクトタイプ**: [A/B/C/D]
**記録事項**:
- プロジェクト性質: [新規/移行/リプラットフォーム/運用見直し]
- 既存システムの課題: [課題リスト]（該当する場合）
- 移行制約: [制約内容]（該当する場合）
- 次のアクション: 予算・スケジュール制約の確認
【重要】予算制約を知らないと実現不可能な設計になる可能性がある
コンサルタント: （AskUserQuestionツールを使用）
運用設計の前提条件として、予算とスケジュールを確認させてください。
【予算について】
Q1: 運用コストの月額予算はありますか？
A) **明確な予算上限あり** ⭐⭐⭐⭐⭐
- 月額予算: [金額]円
- 予算超過時の対応: [内容]
推奨理由: 予算内で最適な設計ができる
考慮事項: コスト制約を考慮した設計が必要
B) **おおよその目安あり** ⭐⭐⭐⭐
- 月額目安: [金額]円程度
- 多少の超過は許容
推奨理由: 柔軟な設計が可能
考慮事項: コスト最適化の優先度を確認
C) **予算制約なし（品質優先）** ⭐⭐⭐
- 可用性・パフォーマンスを最優先
- コストは二の次
推奨理由: 最高品質の運用設計が可能
考慮事項: コスト効率の観点も提案する
D) **未定（今後決定）** ⭐⭐
- まず運用設計を作成してから予算を決める
- 複数パターンの提示を希望
推奨理由: 選択肢を持てる
考慮事項: 複数プランの作成が必要
Q2: コストと品質のトレードオフについて
可用性目標とコストはトレードオフの関係にあります。
どちらを優先しますか？
A) **品質優先（高可用性）** ⭐⭐⭐⭐⭐
- 99.99%以上の可用性を目指す
- コストが高くなっても許容
B) **バランス重視** ⭐⭐⭐⭐
- 99.9%程度の可用性で十分
- コストとのバランスを重視
C) **コスト優先** ⭐⭐⭐
- 最低限の可用性でコストを抑える
- ダウンタイムは許容範囲
【スケジュールについて】
Q3: 運用開始の期限はありますか？
- 運用開始予定日: [YYYY-MM-DD]
- 期限の厳格性: 絶対厳守/できれば守りたい/柔軟
- マイルストーン: [主要なマイルストーン]
ユーザー: [回答]
コンサルタント: ありがとうございます。
[Editツールで会話ログに記録]
予算制約を考慮しつつ、最適な運用設計を提案させていただきます。
それでは、インフラパターンの選択に進みます。
会話ログへの記録内容:
### [HH:MM] 予算・スケジュール制約の確認
**予算情報**:
- 月額予算: [金額]円 / おおよその目安: [金額]円 / 予算制約なし / 未定
- コスト優先度: 品質優先/バランス重視/コスト優先
**スケジュール情報**:
- 運用開始予定日: [YYYY-MM-DD]
- 期限の厳格性: [厳格性レベル]
- マイルストーン: [リスト]
**記録事項**:
- 予算制約が運用設計に与える影響: [分析]
- 次のアクション: インフラパターンの選択
【重要】運用設計書のテンプレートを選択するため、インフラパターンを確認すること
コンサルタント: （AskUserQuestionツールを使用）
運用設計書を作成する前に、インフラのパターンを確認させてください。
システムのインフラ構成はどれに該当しますか？
A) **クラウドネイティブ / サーバレス / Kubernetes** ⭐⭐⭐⭐⭐
- Lambda, Cloud Functions, Cloud Run等のサーバレス
- EKS, GKE, AKS等のKubernetes環境
- マネージドサービス中心の構成
- コンテナベースのアプリケーション
推奨理由: 最新のクラウドネイティブ技術を活用
考慮事項: 責任共有モデル、クラウドサービスのSLA依存
B) **クラウドインスタンス / IaaS（LAMP等）** ⭐⭐⭐⭐
- EC2、GCE、Azure VM等のクラウドインスタンス
- オンプレミスからのLift & Shift
- LAMP/LEMP等の従来型Web構成
- 仮想マシンベースのアプリケーション
推奨理由: オンプレミスと同様の運用が可能、クラウドの柔軟性も活用
考慮事項: OS・ミドルウェア管理が必要、一部クラウドサービス制限あり
C) **オンプレミス** ⭐⭐⭐
- 自社データセンター
- コロケーション施設
- 物理サーバー/VMware、Hyper-V等
- 完全な自社管理インフラ
推奨理由: 完全なコントロールが可能
考慮事項: スケーリングリードタイム（2〜4ヶ月）、リソース保有コスト、
全責任範囲の管理が必要
D) **SaaS / マルチテナント** ⭐⭐⭐⭐⭐
- マルチテナントSaaSアプリケーション
- コンテナ基盤（ECS, GKE, AKS等）
- クラウドプロバイダー非依存の設計
- テナント分離・課金・SLA管理
推奨理由: SaaS特有のマルチテナント運用・テナント管理を網羅
考慮事項: テナント分離戦略、SaaS固有のセキュリティ・コンプライアンス要件
ユーザー: [回答]
コンサルタント: ありがとうございます。[選択されたパターン]に適した運用設計書テンプレートを使用します。
[選択されたパターンに応じたテンプレートを使用]
- A選択時: assets/templates/operations_design_template_cloud_native_ja.md
- B選択時: assets/templates/operations_design_template_cloud_instance_ja.md
- C選択時: assets/templates/operations_design_template_onpremise_ja.md
- D選択時: assets/templates/operations_design_template_saas_ja.md
※ SaaS選択時は以下の順序でヒアリングを重点的に実施:
（各項目をステップ1の業界調査後、ステップ2のヒアリングで順番に確認する）
1. テナント分離戦略（プール/サイロ/ハイブリッド）
2. 認証・オンボーディング方式（SSO, MFA, JIT）
3. プラン・課金体系（リソース制限, API制限）
4. SLA定義（テナント種別ごとの目標値）
5. コンプライアンス要件（GDPR, 個人情報保護法）
6. 監視・アラート（テナント別メトリクス）
7. インシデント対応・バックアップ（テナント影響範囲の特定）
※ ヒアリング結果に基づきテンプレートの各セクションを埋める。
不明な項目は[未定]として残し、後続ステップで再確認する。
それでは、業界トレンド調査に進みます。
コンサルタント: 運用設計を開始する前に、対象業界の最新トレンドを調査させてください。
まず、サービスの業界分類を教えていただけますか？
A) Webサービス/SaaS
B) EC/マーケットプレイス
C) 金融サービス
D) メディア/コンテンツ配信
E) ヘルスケア
F) その他（具体的にお聞かせください）
ユーザー: [回答]
コンサルタント: ありがとうございます。[業界]の最新トレンドを調査します。
[WebSearchで調査実施]
調査が完了しました。以下のトレンドが確認できました。
[調査結果の提示]
[Editツールで会話ログに調査結果を記録]
調査結果を会話ログに記録しました。
これらのトレンドを踏まえて運用設計を進めていきます。
会話ログへの記録内容:
### [HH:MM] 業界トレンド調査
**調査対象業界**: [業界名]
**調査結果**:
1. [トレンド1]: [概要]
2. [トレンド2]: [概要]
3. [トレンド3]: [概要]
**記録事項**:
- 調査実施日: [YYYY-MM-DD]
- 主要な技術トレンド: [リスト]
- 本サービスへの適用候補: [リスト]
- 次のアクション: サービス仕様のヒアリング開始
【重要】以下のすべての質問はAskUserQuestionツールを使用して実施すること
【重要】各質問と回答は会話ログに記録すること
2-1. 既存ドキュメントの確認
コンサルタント: （AskUserQuestionツールを使用）
サービス仕様について確認させてください。
既存のドキュメントはお持ちですか？
- システム設計書
- アーキテクチャ図
- 要件定義書
- その他の仕様書
お持ちの場合は共有していただけますか？
ユーザー: [回答]
2-2. サービス基本情報の収集
ドキュメントがない場合や不足がある場合:
コンサルタント: サービスの基本情報をヒアリングさせてください。
【サービス概要】
Q1. サービス名を教えてください
Q2. サービスの目的は何ですか？（ユーザーにどのような価値を提供しますか？）
Q3. 対象ユーザーは誰ですか？（一般消費者/企業/特定業界等）
Q4. 想定ユーザー数はどれくらいですか？
[1つずつ質問し、回答を記録]
2-3. システム構成の収集
コンサルタント: システム構成について教えてください。
【システムアーキテクチャ】
Q1. システムの主要コンポーネントは何ですか？
- フロントエンド
- バックエンド
- データベース
- その他
Q2. 使用している技術スタックを教えてください
- プログラミング言語
- フレームワーク
- データベース
- インフラ（クラウド/オンプレミス）
Q3. 外部サービスとの連携はありますか？
- 決済サービス
- 認証サービス
- その他のAPI連携
[1つずつ質問し、回答を記録]
2-4. 運用要件の収集
コンサルタント: 運用に関する要件を確認させてください。
【運用要件】
Q1. 可用性の要件は？
A) 99.9%（月間約43分のダウンタイム許容）
B) 99.95%（月間約22分のダウンタイム許容）
C) 99.99%（月間約4分のダウンタイム許容）
D) その他
Q2. サービス提供時間は？
A) 24時間365日
B) 平日のみ（営業時間）
C) その他
Q3. 重要なセキュリティ要件やコンプライアンス要件はありますか？
- 個人情報の取り扱い
- 業界特有の規制
- 認証・認可の要件
[1つずつ質問し、回答を記録]
2-5. データ量とトラフィック特性の確認
【重要】キャパシティ設計、オートスケーリング設計、コスト試算に直結する情報
コンサルタント: （AskUserQuestionツールを使用）
システムのデータ量とトラフィック特性を確認させてください。
これらはキャパシティ設計とコスト試算に必須の情報です。
【データ量について】
Q1: 想定データ量はどれくらいですか？
- 初期データ量: [XX] GB / TB
- 月間データ増加量: [XX] GB / TB
- 年間データ成長率: [XX]%
- 3年後の想定データ量: [XX] TB
Q2: トランザクション数はどれくらいですか？
- 平均リクエスト数: [XX]リクエスト/秒
- ピーク時リクエスト数: [XX]リクエスト/秒
- 平常時とピーク時の比率: [XX]倍
【トラフィックパターンについて】
Q3: トラフィックのパターンを教えてください
A) **時間帯による変動あり** ⭐⭐⭐⭐⭐
- ピーク時間帯: [時間帯]
- オフピーク時間帯: [時間帯]
- ピーク時の負荷: 平常時の[XX]倍
推奨理由: オートスケーリングで最適化可能
考慮事項: スケーリング戦略の設計が必要
B) **曜日による変動あり** ⭐⭐⭐⭐
- ピーク曜日: [曜日]
- オフピーク曜日: [曜日]
- 変動幅: [XX]倍
推奨理由: 週次でのリソース調整が可能
考慮事項: 週末のメンテナンス計画に影響
C) **季節性の変動あり** ⭐⭐⭐⭐
- ピークシーズン: [時期]
- オフシーズン: [時期]
- 変動幅: [XX]倍
推奨理由: 長期的なキャパシティ計画が可能
考慮事項: 事前のキャパシティ増強が必要
D) **イベント・キャンペーンによる急激なスパイク** ⭐⭐⭐
- 想定イベント: [内容]
- スパイク時の負荷: 平常時の[XX]倍
- 頻度: [頻度]
推奨理由: イベント対応の計画が可能
考慮事項: 急激なスケーリングへの対応が必須
E) **安定的（変動が少ない）** ⭐⭐⭐⭐
- 時間帯・曜日による大きな変動なし
- 緩やかな成長のみ
推奨理由: 運用が容易、コスト予測が簡単
考慮事項: 過剰なスケーリング機能は不要
ユーザー: [回答]
コンサルタント: ありがとうございます。
[Editツールで会話ログに記録]
データ量とトラフィック特性を考慮したキャパシティ設計を行います。
会話ログへの記録内容:
### [HH:MM] データ量とトラフィック特性の確認
**データ量**:
- 初期データ量: [XX] GB/TB
- 月間増加量: [XX] GB/TB
- 年間成長率: [XX]%
- 3年後想定: [XX] TB
**トランザクション数**:
- 平均: [XX]リクエスト/秒
- ピーク: [XX]リクエスト/秒
- 比率: [XX]倍
**トラフィックパターン**:
- パターン種別: [時間帯変動/曜日変動/季節性/イベントスパイク/安定]
- ピーク時期・時間帯: [詳細]
- 変動幅: [XX]倍
**記録事項**:
- キャパシティ設計への影響: [分析]
- コスト試算への影響: [分析]
- 次のアクション: 運用チームの体制とスキル確認
2-6. 運用チームの体制とスキルレベルの確認
【重要】運用チームのスキルに合わない技術を選定すると運用不可能になる
コンサルタント: （AskUserQuestionツールを使用）
運用チームの体制とスキルレベルを確認させてください。
これは運用設計の実現可能性を判断するために必須です。
【運用体制について】
Q1: 運用チームの構成はどうなっていますか？
- 運用要員数: [XX]名
- 運用体制: 24時間365日対応可能/平日のみ/営業時間のみ
- オンコール体制: 構築可能/構築困難/不可
- シフト体制: 可能/不可
Q2: 開発チームとの連携体制は？
A) **DevOps体制（開発と運用が統合）** ⭐⭐⭐⭐⭐
- 開発チームが運用も担当
- CI/CD、Infrastructure as Codeを実践
- オンコール体制も開発チームで対応
推奨理由: 最新のSRE/DevOpsプラクティスを適用可能
考慮事項: 高度な技術スキルが必要
B) **協力体制（開発と運用が協力）** ⭐⭐⭐⭐
- 運用チームが日常運用を担当
- 開発チームが技術サポート・障害対応支援
- 定期的な情報共有会議あり
推奨理由: バランスの良い体制
考慮事項: コミュニケーションプロセスの設計が必要
C) **分離体制（開発と運用が別組織）** ⭐⭐⭐
- 運用チームが完全に独立
- 開発チームとの連携は限定的
- 手順書ベースの運用
推奨理由: 明確な責任分界
考慮事項: 詳細な運用手順書が必須、自動化が困難
【技術スキルについて】
Q3: 運用チームの技術スキルレベルを教えてください
**クラウド運用経験**:
- AWS/GCP/Azure運用経験: あり（[X]年）/なし
- マネージドサービス活用経験: あり/なし
- インフラのコード化（Terraform等）: 経験あり/なし
**コンテナ・Kubernetes経験**:
- Docker運用経験: あり（[X]年）/なし
- Kubernetes運用経験: あり（[X]年）/なし
- Helm等のツール利用経験: あり/なし
**プログラミング・スクリプティング**:
- プログラミング能力: あり（言語: [XX]）/なし
- シェルスクリプト作成: 可能/基本的なもののみ/不可
- 自動化ツール（Ansible等）: 経験あり/なし
**監視・ログ分析**:
- 監視ツール使用経験: あり（[ツール名]）/なし
- ログ分析経験: あり/なし
- APM（Application Performance Monitoring）: 経験あり/なし
ユーザー: [回答]
コンサルタント: ありがとうございます。
[Editツールで会話ログに記録]
運用チームのスキルレベルを考慮した、実現可能な運用設計を行います。
会話ログへの記録内容:
### [HH:MM] 運用チームの体制とスキルレベル確認
**運用体制**:
- 運用要員数: [XX]名
- 運用時間: 24/365 / 平日のみ / 営業時間のみ
- オンコール体制: 可能/困難/不可
- 開発との連携: DevOps / 協力体制 / 分離体制
**技術スキル**:
- AWS/クラウド運用: [経験年数]
- Kubernetes運用: [経験年数]
- プログラミング: [言語リスト]
- 監視ツール: [ツールリスト]
- 自動化ツール: [ツールリスト]
**記録事項**:
- 実現可能な運用設計の制約: [分析]
- スキルギャップと教育計画の必要性: [分析]
- 次のアクション: 開発・運用の責任分界確認
2-7. 開発・運用の責任分界の確認
【重要】責任分界が不明確だと運用時にトラブルになる
コンサルタント: （AskUserQuestionツールを使用）
開発チームと運用チームの責任分界を明確にさせてください。
【責任分界について】
以下の作業について、どちらが責任を持ちますか？
Q1: デプロイ作業の実施
A) 開発チームが実施
B) 運用チームが実施
C) 開発チームが作成したスクリプトを運用チームが実行
D) 完全自動化（承認のみ人手）
Q2: アプリケーションログの分析
A) 開発チームが分析
B) 運用チームが分析
C) 運用チームが一次分析、開発チームが詳細分析
Q3: インフラ変更（スケーリング、設定変更等）
A) 開発チームが実施
B) 運用チームが実施
C) 協議の上、ケースバイケース
Q4: 障害対応（アプリケーション起因）
A) 開発チームが対応
B) 運用チームが対応（必要に応じて開発にエスカレーション）
C) 運用チームが一次対応、開発チームが二次対応
Q5: 障害対応（インフラ起因）
A) 開発チームが対応
B) 運用チームが対応
C) 協議の上、ケースバイケース
Q6: パフォーマンスチューニング
A) 開発チームが実施
B) 運用チームが実施
C) 協力して実施
ユーザー: [回答]
コンサルタント: ありがとうございます。
[Editツールで会話ログに記録]
責任分界を明確にした運用設計を行います。
会話ログへの記録内容:
### [HH:MM] 開発・運用の責任分界確認
**責任分界（RACI）**:
- デプロイ実施: [開発/運用/協力/自動化]
- ログ分析: [開発/運用/協力]
- インフラ変更: [開発/運用/協議]
- 障害対応（アプリ起因）: [開発/運用/協力]
- 障害対応（インフラ起因）: [開発/運用/協議]
- パフォーマンスチューニング: [開発/運用/協力]
**記録事項**:
- 運用設計書のRACI定義に反映: [内容]
- 次のアクション: 外部連携先のSLA確認
2-8. 外部連携先のSLAと依存関係の確認
【重要】外部サービスのSLAが自システムのSLO上限を決める
コンサルタント: （AskUserQuestionツールを使用）
外部サービスとの連携について詳しく確認させてください。
【外部連携の詳細】
先ほど確認した外部サービス連携について、
各サービスの詳細を教えてください。
各外部サービスについて：
Q1: サービス名と提供元
- サービス名: [サービス名]
- 提供元: [会社名]
Q2: SLA（サービスレベル合意）の有無
- SLA契約: あり/なし
- 保証可用性: [XX.XX]%
- SLA未達時の補償: あり/なし
Q3: ダウン時の影響と対応
- 外部サービスがダウンした場合の自システムへの影響:
A) サービス全停止（致命的）
B) 主要機能が停止（重大）
C) 一部機能が停止（中程度）
D) 影響なし（代替手段あり）
- ダウン時の自システムの動作:
A) エラーを返す
B) リトライする（回数: [XX]回、間隔: [XX]秒）
C) フォールバック処理を実行
D) キューに溜めて後で処理
Q4: レスポンスタイム要件
- 外部サービスの想定レスポンスタイム: [XX]ms/秒
- タイムアウト設定: [XX]秒
- タイムアウト時の処理: [処理内容]
Q5: API制限（レートリミット）
- リクエスト数制限: [XX]リクエスト/秒、[XX]リクエスト/日
- 制限超過時の動作: エラー/スロットリング/キューイング
[外部サービスごとに上記を繰り返し質問]
ユーザー: [回答]
コンサルタント: ありがとうございます。
[Editツールで会話ログに記録]
外部サービスの依存関係を考慮したSLO設計を行います。
これでサービス仕様のヒアリングは完了しました。
次に、運用設計書の作成に進みます。
会話ログへの記録内容:
### [HH:MM] 外部連携先のSLAと依存関係確認
**外部サービス一覧**:
1. [サービス名1]:
- 提供元: [会社名]
- SLA: [XX.XX]%
- ダウン時の影響: 全停止/主要機能停止/一部停止/影響なし
- フォールバック戦略: [内容]
- レスポンスタイム: [XX]ms、タイムアウト: [XX]秒
- API制限: [XX]req/秒
2. [サービス名2]:
- （同様の情報）
**記録事項**:
- 外部サービス依存によるSLO制約: [分析]
- 複合SLAの計算: [計算結果]
- フォールバック戦略の必要性: [分析]
- 次のアクション: セキュリティ・コンプライアンス要件の詳細確認
2-9. セキュリティ・コンプライアンス要件の詳細確認
【重要】DevSecOpsの実装に必要な情報
セキュリティとコンプライアンスについて以下のカテゴリでヒアリングを実施：
詳細な質問項目: hearing_items/2-9_security_compliance_ja.md を Readツールで参照し、プロジェクトの性質に応じて適切な質問を選択・実施。
会話ログ記録: references/conversation_logging_ja.md の形式で、回答内容を会話ログに記録。
運用設計書を段階的に作成します。各セクション完成後、ユーザーに確認を取ります。
3-1. 概要セクションの作成
コンサルタント: ヒアリング内容を基に、運用設計書の「概要」セクションを作成しました。
[作成した内容を提示]
内容を確認していただけますか？
- 承認して次に進む
- 修正が必要
ユーザー: [回答]
3-2. 運用方針とSLO/SLIの作成
コンサルタント: 次に、運用方針とSLO/SLIを定義します。
調査した業界トレンドによると、[業界]では以下のような
SLO設定が推奨されています：
[トレンド調査結果に基づく推奨値]
貴サービスの場合、以下のSLOを提案します：
【提案するSLO】
- 可用性: [値]
- レスポンスタイム: [値]
- エラーレート: [値]
この提案で問題ありませんか？
調整が必要な項目があれば教えてください。
ユーザー: [回答]
コンサルタント: 承知しました。[調整内容]を反映してSLOセクションを作成しました。
[作成した内容を提示]
内容を確認していただけますか？
ユーザー: [回答]
3-3. その他のセクション作成
同様の形式で以下のセクションを順次作成:
各セクション完成後、必ずユーザーの確認と承認を得ます。
全セクション完成後、一貫性をチェックします。
コンサルタント: 運用設計書の全セクションが完成しました。
内容の一貫性チェックを実施します。
[チェック実施]
【一貫性チェック結果】
✅ 整合性が確認できた項目:
1. SLO「可用性99.9%」に対して、適切な監視項目とアラート設定が定義されています
2. インシデント対応時間がSLOのMTTR目標と整合しています
3. 運用体制（24/365オンコール）とサービス提供時間（24時間365日）が整合しています
⚠️ 確認が必要な項目:
1. 変更管理の「通常変更」のリードタイム（3営業日）と、リリーススケジュールの
「週次リリース」の整合性について
→ 週次リリースを実現するには、リードタイムの短縮が必要ではないでしょうか？
2. バックアップのRPO（6時間）と、SLOで定義された「データ損失は許容しない」
という要件の整合性について
→ RPOを短縮すべきか、SLO要件を調整すべきか、確認が必要です
これらの点について、どのように対応すべきか教えていただけますか？
ユーザー: [回答]
コンサルタント: 承知しました。[調整内容]を反映して運用設計書を更新します。
コンサルタント: 一貫性チェックの結果を反映し、運用設計書を最終版にまとめました。
【最終版の概要】
- 全20セクション
- SLO: [主要な目標値]
- 運用体制: [体制概要]
- 主要な運用プロセス: [プロセス概要]
最終レビューをお願いします。
承認いただければ、この運用設計書を正式版として保存します。
ユーザー: [回答]
コンサルタント: ありがとうございます。
運用設計書を[保存先]に保存しました。
【重要】質問時は必ずAskUserQuestionツールを使用すること
運用設計のコンサルティング過程で、以下のルールを厳守してください：
質問が必要な場合は必ずAskUserQuestionツールを使用する
不明な点は積極的に質問する
質問する時は常にAskUserQuestionツールを使って回答させる
選択肢にはそれぞれ、推奨度と理由を提示する
加点要素:
減点要素:
良い例：
可用性目標について確認させてください：
A) 99.9%（月間ダウンタイム約43分） ⭐⭐⭐⭐
推奨理由：一般的なWebサービスの標準。コストと品質のバランスが良い
根拠：業界調査により、同種サービスの70%がこの水準を採用
B) 99.95%（月間ダウンタイム約22分） ⭐⭐⭐⭐⭐
推奨理由：貴サービスが決済機能を含むため、より高い可用性を推奨
根拠：決済サービス業界標準（PCI DSS推奨レベル）
C) 99.99%（月間ダウンタイム約4分） ⭐⭐
推奨理由：最高水準だがコストが2-3倍必要
根拠：金融サービス等のミッションクリティカルなシステム向け
どれを選択しますか？
使用場面：
【重要】すべてのユーザーとの会話は会話ログファイルに記録すること
運用設計のコンサルティング過程で収集したすべての情報を会話ログファイルに記録し、コンテキストを失わないようにします。
ファイル名: [YYYY-MM-DD]-[サービス名]-conversation-log.md
記録タイミング:
詳細なガイド: references/conversation_logging_ja.md を Readツールで参照し、会話ログの作成方法、記録フォーマット、活用方法を確認してください。
【重要】必ず段階的に作成し、各ステップでユーザー確認を取る
運用設計書は以下の順序で段階的に作成します：
作業の流れ:
概要セクション
業界トレンド分析セクション
運用方針とSLO/SLIセクション
その他の運用セクション
一貫性チェック
確認の取り方:
各セクション完成時に以下のように確認を求めます：
[セクション名]の作成が完了しました。
内容を確認していただけますか？
[作成した内容を提示]
- 承認して次に進む
- 修正が必要
修正が必要な場合は、どの部分をどのように修正すべきか教えてください。
運用設計書には具体的で測定可能な内容を記載します：
良い例:
悪い例:
避けるべき表現:
推奨される表現:
以下の行為は実施しません:
推測や推論
一方的な進行
一貫性のない設計
以下の場合は、作業を進めず、ユーザーに確認します:
サービス仕様が不明確
運用要件が未定義
矛盾する情報
運用設計を開始する前に必ず業界トレンドを調査します:
サービス仕様を段階的に収集します:
設計内容の一貫性を常にチェックします:
完成した運用設計書を客観的にレビューします:
運用設計書テンプレート（インフラパターン別）:
assets/templates/operations_design_template_ja.md: 汎用テンプレート（パターン未選択時）assets/templates/operations_design_template_cloud_native_ja.md: クラウドネイティブ/サーバレス/Kubernetes対応assets/templates/operations_design_template_cloud_instance_ja.md: クラウドインスタンス/IaaS対応（LAMP等）assets/templates/operations_design_template_onpremise_ja.md: オンプレミス対応assets/templates/operations_design_template_saas_ja.md: SaaS運用設計対応（マルチテナント・コンテナ基盤・クラウドプロバイダー非依存）その他のテンプレート:
assets/templates/conversation_log_template_ja.md: 会話ログテンプレートoperations_design_guide_ja.md: 運用設計の詳細ガイドindustry_research_guide_ja.md: 業界調査のガイドラインこのスキルは将来的に以下の機能を追加予定です: