viccom/software-architecture-design

ソフトウェアアーキテクチャ設計 — クイックリファレンス

このスキルは、単一のサービスやコンポーネント内の実装詳細ではなく、システムレベルの設計判断に使用してください。

クイックリファレンス

タスク	パターン/ツール	主なリソース	使用すべき状況
アーキテクチャスタイルの選択	レイヤード、マイクロサービス、イベント駆動、サーバーレス	modern-patterns.md	グリーンフィールドプロジェクト、大規模リファクタリング
スケーラビリティの設計	ロードバランシング、キャッシング、シャーディング、リードレプリカ	scalability-reliability-guide.md	高トラフィックシステム、パフォーマンス目標
復元力の確保	サーキットブレーカー、リトライ、バルクヘッド、グレースフルデグラデーション	scalability-reliability-guide.md	分散システム、外部依存関係
決定事項の文書化	アーキテクチャ決定記録 (ADR)	adr-template.md	主要な技術的判断、トレードオフ分析
サービス境界の定義	ドメイン駆動設計 (DDD)、境界づけられたコンテキスト	microservices-template.md	マイクロサービスへの分解
データ一貫性のモデル化	ACID vs BASE、イベントソーシング、CQRS、Sagaパターン	data-architecture-patterns.md	複数サービスにまたがるトランザクション
可観測性の計画	SLI/SLO/SLA、分散トレーシング、メトリクス、ログ	architecture-blueprint.md	プロダクション対応
モノリスからの移行	Strangler Fig（絞め殺しの木）パターン、データベース分割、シャドウトラフィック	migration-modernization-guide.md	レガシーシステムの近代化
サービス間通信の設計	APIゲートウェイ、サービスメッシュ、BFFパターン	api-gateway-service-mesh.md	マイクロサービスのネットワーキング

このスキルを使用すべき場合

以下の作業時に呼び出してください：

• システム分解: モノリス、モジュラーモノリス、マイクロサービスの決定
• アーキテクチャパターン: イベント駆動、CQRS、レイヤード、ヘキサゴナル、サーバーレス
• データアーキテクチャ: 一貫性モデル、シャーディング、レプリケーション、CQRSパターン
• スケーラビリティ設計: ロードバランシング、キャッシュ戦略、データベーススケーリング
• 復元力パターン: サーキットブレーカー、リトライ、バルクヘッド、グレースフルデグラデーション
• API契約: サービス境界、バージョニング、統合パターン
• アーキテクチャ判断: ADR、トレードオフ分析、技術選定
• 移行計画: モノリス分解、Strangler Figパターン、データベース分離

このスキルを使用すべきでない場合

代わりに他のスキルを使用してください：

• 単一サービスの実装（ルート、コントローラー、ビジネスロジック）→ software-backend
• APIエンドポイント設計（REST規約、GraphQLスキーマ）→ dev-api-design
• セキュリティ実装（認証、暗号化、OWASP）→ software-security-appsec
• フロントエンドコンポーネントアーキテクチャ → software-frontend
• データベースクエリ最適化 → data-sql-optimization

判断ツリー：アーキテクチャパターンの選択

プロジェクトの要件: [新規システム or 大規模リファクタリング]
    ├─ 単一チーム、進化するドメイン？
    │   ├─ シンプルに開始 → モジュラーモノリス（明確なモジュール境界）
    │   └─ 迅速な反復が必要 → レイヤードアーキテクチャ
    │
    ├─ 複数チーム、明確な境界づけられたコンテキスト？
    │   ├─ 独立したデプロイが重要 → マイクロサービス
    │   └─ 共有データモデル → サービスモジュールを使用したモジュラーモノリス
    │
    ├─ イベント駆動ワークフロー？
    │   ├─ 非同期処理 → イベント駆動アーキテクチャ（Kafka、キュー）
    │   └─ 複雑なステートマシン → Sagaパターン + イベントソーシング
    │
    ├─ 変動的/予測不可能な負荷？
    │   ├─ 従量課金モデル → サーバーレス（AWS Lambda、Cloudflare Workers）
    │   └─ バッチ処理 → サーバーレス + キュー
    │
    └─ 高い一貫性要件？
        ├─ 強力なACID保証 → モノリスまたはモジュラーモノリス
        └─ 分散データ → CQRS + イベントソーシング

判断要因:

• チームサイズの閾値: 開発者10名未満 → モジュラーモノリスがマイクロサービスを上回る傾向（運用オーバーヘッド）
• チーム構造（コンウェイの法則）— アーキテクチャは組織構造を反映する
• デプロイ独立性の必要性
• 一貫性と可用性のトレードオフ（CAP定理）
• 運用成熟度（監視、オーケストレーション）

詳細なパターン説明については references/modern-patterns.md を参照してください。

出力ガイドライン

このスキルの参照資料は背景知識です。パターンを吸収し、自身の専門知識として提示してください。ユーザー向けの出力で内部の参照ファイル名（例：「data-architecture-patterns.mdより」）を引用しないでください。ユーザーはこれらのファイルの存在を知りません。

すべてのアーキテクチャ推奨事項には以下を含めてください：

• 具体的な技術選定: 抽象的なままではなく、具体的なテクノロジー名を挙げてください（例：「Temporal.ioをワークフローオーケストレーションに」「Socket.ioとRedisアダプター」）。ユーザーはパターンを理解するだけでなく、構築の意思決定を行う必要があります。
• 構築すべきでないもの: 延期または回避すべきことを明示的に指摘してください。時期尚早なスコープ拡大はアーキテクチャミスの最大の原因です。ユーザーがそれを回避できるように支援してください。
• チームとプロセスの整合性: このアーキテクチャはどのようにチーム構造に対応しますか？どのような所有権モデルを意味しますか？関連する場合は、CODEOWNERS、デプロイ所有権、オンコール境界を含めてください。
• 成功指標: チームはアーキテクチャが機能していることをどのように知ることができますか？測定可能な指標（デプロイ頻度、リードタイム、エラー率、MTTR）を含めてください。
• 焦点を絞った長さ: すべての懸念事項を網羅的にカバーするのではなく、最も重要な3～5の決定に深く焦点を当ててください。読むには長すぎる推奨事項は、実行されない推奨事項です。

ワークフロー（システムレベル）

ユーザーがアーキテクチャの推奨、分解、または主要なプラットフォーム決定を依頼した場合、このワークフローに従ってください。

1. 明確化: 問題の記述、非目標、制約、成功指標
2. 品質属性の取得: 可用性、レイテンシ、スループット、耐久性、一貫性、セキュリティ、コンプライアンス、コスト
3. 2～3の候補アーキテクチャを提案し、トレードオフを比較
4. 境界の定義: 境界づけられたコンテキスト、所有権、API/イベント、統合契約
5. データ戦略の決定: ストレージ、一貫性モデル、スキーマ進化、移行
6. 運用の設計: SLO、障害モード、可観測性、デプロイ、DR、インシデントプレイブック
7. スコープの制限を明示: まだ構築すべきでないもの、延期すべきもの、購入すべきものと構築すべきもの
8. 決定事項の文書化: 主要なトレードオフと不可逆的な選択についてADRを作成

優先すべき成果物（リクエストに応じて選択）:

• アーキテクチャブループリント: assets/planning/architecture-blueprint.md
• 決定記録: assets/planning/adr-template.md
• パターンの詳細解説: references/modern-patterns.md、references/scalability-reliability-guide.md

2026年の考慮事項

質問が現在のトレンド、ベンダー固有の制約、または「Xに関する最新の考え方は？」に明示的に関連する場合にのみ読み込んでください。

• references/architecture-trends-2026.md — プラットフォームエンジニアリング、データメッシュ、コンポーザブルアーキテクチャ、AIネイティブシステム
• data/sources.json — カテゴリ別に整理された60の厳選リソース:
  • platform_engineering_2026 — IDPトレンド、AIとプラットフォームの融合、Backstage
  • optional_ai_architecture — RAGパターン、マルチエージェント設計、MCP/A2Aプロトコル
  • modern_architecture_2025 — データメッシュ、コンポーザブルアーキテクチャ、継続的アーキテクチャ

ライブWebアクセスが利用可能な場合は、data/sources.jsonから2～3の信頼できる情報源を参照し、その調査結果を推奨事項に組み込んでください。利用できない場合は、耐久性のあるパターンで回答し、変更される可能性のある前提（ベンダーの制限、価格設定、マネージドサービスの機能）を明示的に述べてください。

ナビゲーション

コアリファレンス

質問ごとに、読み込むリファレンスは最大2～3つにしてください。特定の依頼に最も関連するものを選び、すべてを読み込まないでください。

リファレンス	内容	いつ読むべきか
modern-patterns.md	判断ツリー付きの10のアーキテクチャパターン	パターンの選択または比較時
scalability-reliability-guide.md	CAP定理、DBスケーリング、キャッシング、サーキットブレーカー、SRE	スケーリングまたは信頼性に関する質問
data-architecture-patterns.md	CQRSのバリエーション、イベントソーシング、データメッシュ、Saga、一貫性	サービス間のデータフロー
migration-modernization-guide.md	Strangler Fig、データベース分割、フィーチャーフラグ、リスク評価	モノリスのリファクタリング
api-gateway-service-mesh.md	ゲートウェイパターン、サービスメッシュ、mTLS、可観測性	サービス間通信
architecture-trends-2026.md	プラットフォームエンジニアリング、データメッシュ、AIネイティブシステム	現在のトレンドのみ
operational-playbook.md	アーキテクチャ質問フレームワーク、分解ヒューリスティック	設計議論の枠組み設定

テンプレート

計画とドキュメント (assets/planning/):

• architecture-blueprint.md — サービスブループリント（依存関係、SLA、データフロー、復元力、セキュリティ、可観測性）
• adr-template.md — トレードオフ分析のためのアーキテクチャ決定記録

アーキテクチャパターン (assets/patterns/):

• microservices-template.md — マイクロサービス設計（API契約、復元力、デプロイ、テスト）
• event-driven-template.md — イベント駆動アーキテクチャ（イベントスキーマ、Sagaパターン、イベントソーシング）

運用 (assets/operations/):

• scalability-checklist.md — スケーラビリティチェックリスト（DBスケーリング、キャッシング、負荷テスト、自動スケーリング、DR）

関連スキル

• software-backend — バックエンドエンジニアリング、API実装、データ層
• software-frontend — フロントエンドアーキテクチャ、マイクロフロントエンド、状態管理
• dev-api-design — REST、GraphQL、gRPC設計パターン
• ops-devops-platform — CI/CD、デプロイ戦略、IaC
• qa-observability — 監視、トレーシング、アラート、SLO
• software-security-appsec — 脅威モデリング、認証、セキュア設計
• data-sql-optimization — データベース設計、最適化、インデックス
• docs-codebase — アーキテクチャドキュメント、C4図、ADR