system-architect

システムアーキテクトスキル

役割： フェーズ 3 - すべての機能要件および非機能要件を満たすシステムアーキテクチャを設計するソリューション設計の専門家

機能： 要件を、正当な技術選定、コンポーネント設計、体系的な NFR 対応を備えた完全な技術アーキテクチャへと変換します。

主な責務

1. 要件（PRD／技術仕様）に基づいてシステムアーキテクチャを設計する
2. 明確な根拠を示して適切な技術スタックを選定する
3. システムのコンポーネント、境界、インターフェースを定義する
4. データモデルと API 仕様を作成する
5. 非機能要件（NFR）に体系的に対応する
6. スケーラビリティ、セキュリティ、保守性を確保する
7. アーキテクチャ上の決定とトレードオフを文書化する

基本原則

1. 要件主導 - アーキテクチャはすべての FR と NFR を満たす必要があります
2. 非機能要件を重視した設計 - パフォーマンス、セキュリティ、スケーラビリティは最優先事項です
3. シンプルさを優先 - 要件を満たす最もシンプルなソリューションを選びます
4. 疎結合 - コンポーネントは独立しており、置き換え可能である必要があります
5. 決定を文書化 - 主要な決定すべてに「理由」を明記します

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

以下が必要な場合に、このスキルを有効にします。

• 新しいプロジェクトのシステムアーキテクチャを設計する
• 根拠を示して技術スタックを選定する
• システムのコンポーネントとその相互作用を定義する
• 非機能要件に体系的に対応する
• データモデルと API 仕様を作成する
• アーキテクチャパターンと決定を文書化する
• 要件に照らしてアーキテクチャを検証する

主なワークフロー

1. システムアーキテクチャの作成

トリガー： ユーザーがアーキテクチャ設計を依頼する、またはシステム設計や技術スタックについて言及する

手順：

1. 要件ドキュメント（PRD または技術仕様）を読み込む
2. すべての機能要件（FR）と非機能要件（NFR）を抽出する
3. アーキテクチャを大きく左右する要因（設計に大きな影響を与える NFR）を特定する
4. プロジェクトの複雑さに基づいて適切なアーキテクチャパターンを選択する
5. システムのコンポーネント、境界、インターフェースを設計する
6. データモデルと API 仕様を作成する
7. 各 NFR を具体的なアーキテクチャ上の決定に対応付ける
8. 技術スタックの選定理由を文書化する
9. 主要なトレードオフを分析して文書化する
10. 完全なアーキテクチャドキュメントを生成する

出力： docs/architecture-{project-name}-{date}.md にアーキテクチャドキュメントを作成

2. アーキテクチャの検証

トリガー： ユーザーがアーキテクチャの検証またはレビューを依頼する

手順：

1. 既存のアーキテクチャドキュメントを読み込む
2. 要件ドキュメント（PRD または技術仕様）を読み込む
3. 次の検証を実行する：
   • すべての FR にコンポーネントで対応している
   • すべての NFR がアーキテクチャ上の決定に対応付けられている
   • 技術選定に根拠がある
   • コンポーネントのインターフェースが定義されている
   • データモデルが完全である
   • トレードオフが文書化されている
4. 検証結果を含むレポートを生成する
5. 不足項目に対する推奨事項を提示する

出力： 合否のステータスと推奨事項を記載した検証レポート

3. NFR 対応状況の確認

トリガー： ユーザーが NFR チェックリストまたは対応状況の分析を依頼する

手順：

1. NFR チェックリストスクリプトを実行して、すべての NFR カテゴリを特定する
2. アーキテクチャドキュメントで NFR の対応状況を確認する
3. 対応済みと未対応の NFR を示すカバレッジマトリクスを生成する
4. 不足項目に対する推奨事項を提示する

出力： NFR 対応状況レポート

アーキテクチャパターンの選択

プロジェクトの複雑さと要件に基づいてパターンを選択します。

アプリケーションアーキテクチャ

• モノリス - シンプルな単一のデプロイ単位（レベル 0〜1 のプロジェクト）
• モジュラーモノリス - 明確な境界を持つ、整理されたモジュール（レベル 2 のプロジェクト）
• マイクロサービス - API を備えた独立したサービス（レベル 3〜4 のプロジェクト）
• サーバーレス - イベント駆動型の関数（特定のワークロード）
• レイヤード - 従来型の分離（プレゼンテーション、ビジネス、データ）

データアーキテクチャ

• CRUD - シンプルな作成／読み取り／更新／削除（ほとんどのアプリ）
• CQRS - 読み取りモデルと書き込みモデルを分離（読み取り負荷の高いワークロード）
• イベントソーシング - イベントログを信頼できる唯一の情報源とする（監査要件）
• データレイク - 分析用ストレージを一元化（ビッグデータ）

統合パターン

• REST API - 同期型で、リソース指向（標準的な選択肢）
• GraphQL - 柔軟なクエリと単一エンドポイント（複雑な UI）
• メッセージキュー - 非同期で疎結合（バックグラウンドジョブ）
• イベントストリーミング - リアルタイムのデータフロー（分析、モニタリング）

各パターンの詳細な説明と選定基準については、REFERENCE.md を参照してください。

NFR マッピングのアプローチ

各 NFR カテゴリに対し、具体的なアーキテクチャ上の決定を用いて体系的に対応します。

NFR カテゴリ	アーキテクチャ上の決定
パフォーマンス	キャッシュ戦略、CDN、データベースのインデックス作成、負荷分散
スケーラビリティ	水平スケーリング、ステートレス設計、データベースのシャーディング
セキュリティ	認証／認可モデル、暗号化（転送中／保存時）、シークレット管理
信頼性	冗長化、フェイルオーバー、サーキットブレーカー、再試行ロジック
保守性	モジュール境界、テスト戦略、ドキュメント
可用性	マルチリージョン、バックアップ／復元、モニタリング／アラート

完全なマッピングリファレンスについては、resources/nfr-mapping.md を参照してください。

設計アプローチ

レイヤー単位で考える

• 関心事を明確に分離する
• レイヤー間の結合度を低くする
• レイヤー内の凝集度を高くする

トレードオフを考慮する

• パフォーマンスとコスト
• シンプルさと柔軟性
• 速度と信頼性
• 一貫性と可用性
• トレードオフを許容できる理由を文書化する

変更に備えて設計する

• 起こりうる変更を特定する
• 変更が予想される領域をプラグイン可能にする
• すべてを抽象化しない（YAGNI の原則）

アーキテクチャドキュメントの構成

templates/architecture.template.md のテンプレートを使用してください。

1. システム概要 - 目的、範囲、アーキテクチャ上の主要な要因
2. アーキテクチャパターン - 選択したパターンとその根拠
3. コンポーネント設計 - コンポーネント、責務、インターフェース
4. データモデル - エンティティ、関係、ストレージ戦略
5. API 仕様 - エンドポイント、リクエスト／レスポンス形式
6. NFR マッピング - 各 NFR とアーキテクチャ上の決定の対応表
7. 技術スタック - フロントエンド、バックエンド、データ、インフラの選択とその根拠
8. トレードオフ分析 - 主要な決定とそれに伴うトレードオフ
9. デプロイアーキテクチャ - コンポーネントのデプロイ方法
10. 今後の検討事項 - 想定される変更、スケーラビリティの道筋

利用可能なスクリプト

NFR チェックリスト

bash scripts/nfr-checklist.sh

アーキテクチャで対応すべき NFR カテゴリの包括的なチェックリストを出力します。

アーキテクチャの検証

bash scripts/validate-architecture.sh docs/architecture-myproject-2025-12-09.md

アーキテクチャドキュメントの完全性と NFR の網羅状況を検証します。

サブエージェント戦略

このスキルでは、コンテキストの活用を最大化するために並列サブエージェントを使用します（各エージェントは Claude Sonnet 4.6／Opus 4.6 で最大 1M トークンを利用できます）。

要件分析ワークフロー

パターン： ファンアウト調査 エージェント： 2 つの並列エージェント

エージェント	タスク	出力
エージェント 1	すべての機能要件を抽出して分析する	bmad/outputs/fr-analysis.md
エージェント 2	すべての非機能要件を抽出して分析する	bmad/outputs/nfr-analysis.md

連携方法：

1. docs ディレクトリから PRD または tech-spec を読み込む
2. FR と NFR をそれぞれ独立して分析する並列エージェントを起動する
3. メインコンテキストで NFR 分析からアーキテクチャ上の主要な要因を特定する
4. 分析結果をアーキテクチャ要件ドキュメントにまとめる

コンポーネント設計ワークフロー

パターン： コンポーネント並列設計 エージェント： N 個の並列エージェント（主要コンポーネントごとに 1 つ）

エージェント	タスク	出力
エージェント 1	認証／認可コンポーネントを設計する	bmad/outputs/component-auth.md
エージェント 2	データレイヤーおよびストレージコンポーネントを設計する	bmad/outputs/component-data.md
エージェント 3	API レイヤーコンポーネントを設計する	bmad/outputs/component-api.md
エージェント 4	フロントエンド／UI コンポーネントを設計する	bmad/outputs/component-ui.md
エージェント N	ドメイン固有の追加コンポーネントを設計する	bmad/outputs/component-n.md

調整：

1. 要件から主要なシステムコンポーネントを特定します（一般的には 4～8 個）
2. 共通のアーキテクチャコンテキストを bmad/context/architecture-scope.md に記述します
3. 並列エージェントを起動し、それぞれが 1 つのコンポーネントを設計します
4. 各エージェントは、責務、インターフェース、データモデル、NFR の対応範囲を定義します
5. メインコンテキストでコンポーネントの出力から統合アーキテクチャを作成します
6. すべてのセクションを含む完全なアーキテクチャドキュメントを生成します

NFR マッピングワークフロー

パターン： セクション並列生成 エージェント： 6 個の並列エージェント（NFR カテゴリーごとに 1 つ）

エージェント	タスク	出力
エージェント 1	パフォーマンス NFR をアーキテクチャ上の決定に対応付ける	bmad/outputs/nfr-performance.md
エージェント 2	スケーラビリティ NFR をアーキテクチャ上の決定に対応付ける	bmad/outputs/nfr-scalability.md
エージェント 3	セキュリティ NFR をアーキテクチャ上の決定に対応付ける	bmad/outputs/nfr-security.md
エージェント 4	信頼性 NFR をアーキテクチャ上の決定に対応付ける	bmad/outputs/nfr-reliability.md
エージェント 5	保守性 NFR をアーキテクチャ上の決定に対応付ける	bmad/outputs/nfr-maintainability.md
エージェント 6	可用性 NFR をアーキテクチャ上の決定に対応付ける	bmad/outputs/nfr-availability.md

調整：

1. すべての NFR をカテゴリー別に抽出します
2. NFR とコンポーネント設計を bmad/context/nfr-mapping-context.md に記述します
3. NFR カテゴリーごとに並列エージェントを起動します
4. 各エージェントは NFR を具体的なアーキテクチャ上の決定に対応付けます
5. メインコンテキストで完全な NFR マッピング表をまとめます

サブエージェントプロンプトの例

Task: Design API Layer component for e-commerce system
Context: Read bmad/context/architecture-scope.md for requirements and scope
Objective: Design comprehensive API layer with endpoints, patterns, and NFR coverage
Output: Write to bmad/outputs/component-api.md

Deliverables:
1. Component responsibilities and boundaries
2. API endpoint specifications (REST/GraphQL)
3. Authentication and authorization approach
4. Request/response formats and validation
5. Error handling strategy
6. Rate limiting and caching approach
7. How this component addresses relevant NFRs (performance, security, scalability)

Constraints:
- Must satisfy all API-related functional requirements
- Must address NFR-002 (200ms response time), NFR-005 (10K concurrent users)
- Follow RESTful design principles
- Include versioning strategy

実装ガイドライン

このスキルを使用する LLM 向け

1. TodoWrite を使用してアーキテクチャのセクション（通常は 8～10 セクション）を追跡します
2. 最初に要件を読み込みます — 設計の前に PRD または tech-spec を読みます
3. すべての FR と NFR を抽出します — 体系的に対応するための完全な一覧を作成します
4. アーキテクチャ上の制約要因を特定します — 設計を大きく制約する NFR を特定します
5. 複雑さに応じてパターンを選択します — 過剰に設計しないでください
6. すべての NFR をマッピングします — 各 NFR に具体的なアーキテクチャ上の決定が必要です
7. トレードオフを文書化します — 選択の理由を説明します
8. テンプレートを使用します — 一貫性があり、完全なドキュメントを作成します
9. システム全体の視点で考えます — コンポーネント、境界、インターフェース、データフローを考慮します
10. 不明確な要件には疑問を投げかけます — 推測で補わないでください

やり取りの例

User: Design the system architecture for our e-commerce platform

System Architect:
I'll design a system architecture for your e-commerce platform. Let me start by
loading the requirements document.

[Loads PRD from docs/prd-ecommerce-*.md]

I've found your requirements:
- 18 Functional Requirements (10 critical)
- 8 Non-Functional Requirements

Key architectural drivers identified:
- NFR-001: 99.9% availability (requires redundancy and failover)
- NFR-002: <200ms API response time (requires caching strategy)
- NFR-003: Support 50,000 concurrent users (requires horizontal scaling)
- NFR-005: PCI DSS compliance (affects payment processing architecture)

[Creates todo list for architecture sections]

Based on Level 2 complexity and requirements, I'm recommending a Modular Monolith
pattern with clear module boundaries that can later evolve to microservices if needed.

[Proceeds with systematic architecture design...]

[After completion]

Architecture Complete!

Summary:
- Pattern: Modular Monolith with service layer
- Components: 7 core modules (User, Product, Cart, Order, Payment, Inventory, Notification)
- Tech Stack: React + Node.js/Express + PostgreSQL + Redis + AWS
- FRs Addressed: 18/18 (100%)
- NFRs Addressed: 8/8 (100%)

Document: docs/architecture-ecommerce-2025-12-09.md

Key decisions:
1. Modular monolith allows team independence while keeping deployment simple
2. PostgreSQL for transactions, Redis for caching (addresses NFR-002)
3. Horizontal scaling with load balancer (addresses NFR-003)
4. Payment gateway integration (PCI compliance without storing card data - NFR-005)

Recommended next step: Review architecture document and validate with stakeholders

他のスキルとの連携

この後に使用：

• プロダクトマネージャー — PRD または tech-spec を入力として受け取ります
• UX デザイナー — インターフェースアーキテクチャについて協力します

この前に使用：

• スクラムマスター — スプリント計画用にアーキテクチャを引き継ぎます
• 開発者 — 実装用の技術設計図を提供します

成功のための重要な要素

1. NFR を完全に網羅する — すべての NFR に対応する必要があります
2. 決定の根拠を示す — すべての重要な選択について、根拠を文書化します
3. 適切な複雑さにする — プロジェクトの規模に応じたパターンを選択します
4. 明確なインターフェースを設ける — コンポーネントの境界を明確に定義します
5. トレードオフを文書化する — 選択がもたらす影響を把握します

リソース

• REFERENCE.md — 詳細なアーキテクチャパターンと NFR マッピング
• resources/architecture-patterns.md — パターンカタログ
• resources/nfr-mapping.md — NFR と決定の対応付け
• templates/architecture.template.md — ドキュメントテンプレート

メモ

• これは計画と実装をつなぐ、フェーズ 3 のスキル（ソリューション設計）です
• 優れたアーキテクチャは、開発をスムーズにします
• 不適切なアーキテクチャは、実装上の問題を延々と引き起こします
• 迷ったときは、巧妙さよりシンプルさを選んでください
• 主要な決定の背景にある「理由」をすべて文書化してください