| name | mcl-product-design |
| description | 個別プロダクト/ワークロード設計用スキル。AWS / Azure / GCP / オンプレミスを対象に、ベンダー中立のワークロードモデル、ベンダー別サービスマッピング、実装仕様、オブザーバビリティ仕様、コスト最適化ヒント、IaC スケルトンを生成する。コンピュート、データベース、メッセージング、ストレージ、キャッシュ、CDN のサービス選定を、可用性、レイテンシ、データ機密性、トラフィックパターン、整合性、復旧目標、コストポスチャに基づいて行う。特定のアプリケーションワークロード、マイクロサービスアーキテクチャ、プロダクトインフラ、ユースケースごとのクラウドサービス選定の設計やレビューに使用すること。1 クラウドのみの言及でも発動する。EC2/App Service/Cloud Run、RDS/Azure SQL/Cloud SQL、SQS/Service Bus/Pub/Sub などのサービス比較もワークロード文脈であればトリガーする。オンプレ（セルフホスト PostgreSQL/Redis/Kafka 等）へのワークロード配置やクラウドとの比較でもトリガーする。
|
mcl-product-design
このスキルの役割
特定のプロダクトやワークロードのインフラを設計するスキル。基盤と共有プラットフォームの制約にワークロード要件を加えて、ワークロードモデル、vendor mapping、オブザーバビリティとコストヒントを含む実装仕様、IaC スケルトンの一式を生成する。
各プロダクト設計は独立しているが、基盤のガードレールと共有プラットフォームのサービスカタログの両方に準拠すること。
前提条件
以下の 2 つが必要:
- Foundation context:
specs/foundation/output/foundation-context.yaml
- Shared platform context:
specs/shared-platform/output/shared-platform-context.yaml
いずれかが欠けている場合は、先に実行すべき上位スキルをユーザーに案内する。
アーキテクチャ概要
同じ 4 層モデル:
- Vendor Sources — サービス固有のドキュメント
- Canonical Model — ベンダー中立のワークロードモデル
- Vendor Mapping — ベンダーごとのサービス選定
- Implementation Artifacts — 実装仕様、オブザーバビリティ、コストヒント、IaC
Canonical Model のスコープ（ワークロード特性）
- workload_type — Web アプリ、API、バッチ、イベント駆動、データパイプライン、ML 推論 等
- availability_target — SLA ティア、冗長モデル、フェイルオーバー戦略
- latency_sensitivity — 応答時間要件、リージョン配置
- data_sensitivity — 分類レベル、暗号化要件、データ所在地制約
- traffic_pattern — 定常、スパイク、スケジュール、イベント駆動、季節変動
- consistency_needs — 強整合性、結果整合性、read-after-write、因果整合性
- recovery_target — RPO、RTO、バックアップ戦略、DR モデル
- observability_needs — メトリクス、ログ、トレース、SLI/SLO、アラート要件
- cost_posture — コスト最適化、パフォーマンス最適化、バランス型、スポット/プリエンプティブル許容度
ベンダー別マッピング対象
| Canonical 概念 | AWS | Azure | GCP | オンプレ（代表例） |
|---|
| コンピュート | EC2, ECS, Lambda, App Runner | App Service, Container Apps, Functions | Cloud Run, Compute Engine, Cloud Functions | VM（vSphere/OpenStack）, K8s Deployment |
| DB（リレーショナル） | RDS, Aurora | Azure SQL, PostgreSQL Flexible | Cloud SQL, AlloyDB | PostgreSQL/MySQL セルフホスト（Patroni 等で HA 構成） |
| DB（NoSQL） | DynamoDB | Cosmos DB | Firestore, Bigtable | MongoDB, Cassandra |
| メッセージング | SQS, SNS, EventBridge | Service Bus, Event Grid | Pub/Sub, Eventarc | RabbitMQ, Apache Kafka |
| オブジェクトストレージ | S3 | Blob Storage | Cloud Storage | MinIO, Ceph RGW |
| キャッシュ | ElastiCache | Azure Cache for Redis | Memorystore | Redis/Valkey セルフホスト |
| CDN | CloudFront | Front Door | Cloud CDN | なし（gap: 外部 CDN サービス併用またはリバースプロキシキャッシュ） |
オンプレ列は代表例。ヒアリングでスタックが指定された場合はそのスタックの製品で、未指定の場合は OSS を具体選定してマッピングする。マネージドサービスと同等の運用性が担保できない場合は fidelity を partial 以下で評価し、運用負担を明記する（../mcl-common/references/mapping-rules.md のオンプレ特則参照）。
ワークフロー
Step 1: 上位コンテキストの読み込み
以下の両方を読み込む:
specs/foundation/output/foundation-context.yamlspecs/shared-platform/output/shared-platform-context.yaml
適用されるガードレールと利用可能な共有サービス（必須/任意）を把握する。
Step 2: ワークロード入力の収集
specs/product/input/ に入力ファイルがあればそこから取得する。無い場合は以下の項目を段階的にヒアリングする。各項目は必ず選択肢を提示し、ユーザーに選んでもらうこと（../mcl-common/SKILL.md のユーザーヒアリングポリシー参照）。
ヒアリング 1: ワークロードタイプと可用性
Q1. ワークロードタイプ
| # | 選択肢 |
|---|
| 1 | Web アプリ / API ★推奨（最も一般的） |
| 2 | バッチ処理 / データパイプライン |
| 3 | イベント駆動 / メッセージ処理 |
| 4 | ML 推論 / AI サービス |
| 5 | その他（説明を入力してください） |
Q2. 可用性ターゲット
| # | 選択肢 | ダウンタイム/年 |
|---|
| 1 | 99%（標準） | 約 3.65 日 |
| 2 | 99.9%（高可用性）★推奨 | 約 8.8 時間 |
| 3 | 99.95% | 約 4.4 時間 |
| 4 | 99.99%（ミッションクリティカル） | 約 52 分 |
Q3. API レイテンシ要件（p99）
| # | 選択肢 |
|---|
| 1 | 100ms 以内（リアルタイム） |
| 2 | 200ms 以内 ★推奨 |
| 3 | 500ms 以内 |
| 4 | 1 秒以内 |
| 5 | レイテンシ要件なし（バッチ系） |
ヒアリング 2: データとトラフィック
Q4. データ機密性（複数選択可）
| # | 選択肢 |
|---|
| 1 | 個人情報（PII）を扱う — 暗号化必須 ★よくあるケース |
| 2 | 決済情報を扱う — PCI DSS 対応必須 |
| 3 | 医療情報を扱う — HIPAA 対応必須 |
| 4 | 機密性の高いビジネスデータ |
| 5 | 公開データのみ — 特別な暗号化不要 |
Q5. トラフィックパターン
| # | 選択肢 |
|---|
| 1 | 定常（日中ピーク、夜間閑散） |
| 2 | スパイク型（セール、キャンペーン等で急増）★EC サイト推奨 |
| 3 | スケジュール型（月末締め、バッチ集中） |
| 4 | イベント駆動（外部イベントにより不定期に急増） |
| 5 | 一定（24h ほぼ同量） |
Q6. スパイク倍率（Q5 でスパイク型を選択した場合）
| # | 選択肢 |
|---|
| 1 | 2〜3 倍 |
| 2 | 5 倍 |
| 3 | 10 倍 ★推奨（EC セール想定） |
| 4 | 20 倍以上（ティッカー、フラッシュセール） |
ヒアリング 3: データストアとコスト
Q7. データベース（複数選択可）
| # | 選択肢 |
|---|
| 1 | PostgreSQL ★推奨（汎用 RDBMS） |
| 2 | MySQL |
| 3 | NoSQL（DynamoDB/CosmosDB/Firestore） |
| 4 | その他（DB 名を入力してください） |
Q8. キャッシュ
| # | 選択肢 |
|---|
| 1 | Redis ★推奨 |
| 2 | Memcached |
| 3 | キャッシュ不要 |
Q9. コスト最適化方針
| # | 選択肢 |
|---|
| 1 | コスト最適化優先（スポット/プリエンプティブル積極活用） |
| 2 | バランス型 ★推奨 |
| 3 | パフォーマンス最適化優先（コストより性能） |
Step 3: ベンダーソースの取得（必須）
ベンダーソースは設計判断の根拠となるため、ワークロードモデル生成前に必ず取得すること。ソースが手元にない状態で設計を進めてはならない。
docs/cloud-context/sources/{vendor}/ に対象レイヤーのソースファイルが存在するか確認する- 存在しない場合: バンドルスクリプト
../mcl-common/scripts/fetch-vendor-sources.sh を実行してベンダーソースをダウンロードする。対象ベンダーごとに実行する（オンプレを含む場合は --vendor onprem）:
../mcl-common/scripts/fetch-vendor-sources.sh <project-dir> --vendor aws --layer product
../mcl-common/scripts/fetch-vendor-sources.sh <project-dir> --vendor azure --layer product
../mcl-common/scripts/fetch-vendor-sources.sh <project-dir> --vendor onprem --layer product
スクリプトは ../mcl-common/scripts/sources.tsv に定義された URL から公式ドキュメントを取得し、docs/cloud-context/sources/{vendor}/ に markdown として保存する。対象ベンダーあたり最低 1 つのソースが取得できていなければ設計を開始しない。
- 存在する場合: そのまま読み込む。
docs/cloud-context/summaries/product/ にサマリーがあればサマリーも併用する
- 取得したソースを読み込み、product レイヤーに関連するガイダンスを把握した上で次の Step に進む
WebFetch に失敗した場合はリトライし、それでも失敗する URL はスキップしてユーザーに通知する。ただし、対象クラウドあたり最低 1 つのソースは取得できていなければ設計を開始しない。
Step 4: ワークロードモデルの生成
../mcl-common/templates/canonical-model.yaml をベースに、上記 9 つのワークロード特性を記述したワークロード固有の canonical model を作成する。
ヒアリングで選択された特定製品名（DB エンジン、キャッシュ製品等）は description を含め canonical に書かない。括弧書きの例示も禁止。特性は「リレーショナル DB、強整合性が必要」のように capability として表現し、製品名は vendor mapping に記録する（../mcl-common/references/canonicalization-rules.md 参照）。
生成後に ../mcl-common/scripts/check-vendor-neutrality.sh specs/product/output/product-workload-model.yaml を実行し、OK になるまで修正する。
保存先: specs/product/output/product-workload-model.yaml
Step 5: Vendor Service Mapping の生成
対象ベンダーごとにワークロード特性に基づき最適なサービスを選定する。以下を考慮する:
- 共有プラットフォームの必須サービス（必ず使用する）
- 共有プラットフォームの任意サービス（適合すれば優先する）
- ベンダー直接サービス（共有プラットフォームでカバーできない場合）
保存先: specs/product/output/product-mapping-{vendor}.yaml
Step 6: Decision Record の生成
保存先: docs/cloud-context/decisions/product/
Step 7: Implementation Spec の生成
保存先: specs/product/output/product-impl-{vendor}.yaml
Step 8: Observability Spec の生成
ワークロードのオブザーバビリティ設定を定義する:
- 主要メトリクスと SLI
- SLO とエラーバジェット
- ログレベルと保持期間
- 分散トレーシング設定
- ダッシュボード定義
- アラートルールとエスカレーション
保存先: specs/product/output/product-observability.yaml
Step 9: コスト最適化ヒントの生成
ワークロード特性に基づきコスト最適化戦略を提案する:
- ライトサイジング推奨
- リザーブド/コミット利用割引の適格性
- スポット/プリエンプティブル対象ワークロードの候補
- ストレージ階層化の機会
- データ転送最適化
- オートスケーリングパラメータ
保存先: specs/product/output/product-cost-hints.yaml
Step 10: Conformance Report の生成
ワークロードモデル、foundation ガードレール、shared platform 制約に対して検証する。
保存先: docs/cloud-context/conformance/product/
Step 11: IaC スケルトンの生成
オンプレは Terraform（vsphere / openstack / kubernetes provider 等）+ Ansible（OS・ミドルウェア構成）の 2 層構成とする。
保存先: infra/product/{vendor}/
Step 12: ターゲットアーキテクチャ Markdown の生成
ワークロード設計を要約した可読性の高いアーキテクチャドキュメントを生成する。図解には Mermaid 記法を使用すること（../mcl-common/SKILL.md の図解ポリシー参照）。以下の図を含める:
- ワークロード全体構成図:
graph TD でコンピュート・DB・キャッシュ・メッセージングの接続関係を表現
- リクエストフロー図:
sequenceDiagram でクライアントからレスポンスまでのデータフローを表現
- オートスケーリング構成図:
graph LR でスケーリングトリガーとターゲットの関係を表現
- ベンダー別デプロイメント図:
graph TD で対象ベンダー（AWS / Azure / オンプレ等）をサブグラフに分け、各サービスのマッピングを表現
保存先: docs/cloud-context/generated-md/product/
出力一覧
| Artifact | パス | 形式 |
|---|
| ワークロードモデル | specs/product/output/product-workload-model.yaml | YAML |
| Vendor Mapping（ベンダーごと） | specs/product/output/product-mapping-{vendor}.yaml | YAML |
| Decision Record | docs/cloud-context/decisions/product/ | YAML |
| Implementation Spec（ベンダーごと） | specs/product/output/product-impl-{vendor}.yaml | YAML |
| Observability Spec | specs/product/output/product-observability.yaml | YAML |
| コスト最適化ヒント | specs/product/output/product-cost-hints.yaml | YAML |
| Conformance Report（ベンダーごと） | docs/cloud-context/conformance/product/ | YAML |
| IaC スケルトン（ベンダーごと） | infra/product/{vendor}/ | HCL/Bicep 等 |
| ターゲットアーキテクチャ | docs/cloud-context/generated-md/product/ | Markdown |
重要な制約
- Foundation と shared platform の context は必須の前提条件
- 共有プラットフォームの必須サービスを使用する。バイパスしない
- ファイル生成のみ行う。apply や commit はユーザーが実行する
- YAML が正本。Markdown は派生生成物
- 共通メタデータフィールドを必ず含める
../mcl-common/templates/ のテンプレートを使用する../mcl-common/references/ のルールに従う
リファレンス
foundation と同じリファレンスファイルを使用する。必要に応じて ../mcl-common/references/ から参照する。
