name	designing-architecture
description	システムアーキテクチャと技術スタック設計を支援します。モノリス/マイクロサービス判定、クラウドアーキテクチャ、スケーラビリティ設計を提供します。大規模システムの設計、技術アーキテクチャの決定が必要な場合に使用してください。

アーキテクチャ設計

概要

システム全体のソリューション設計、クラウドアーキテクチャ、技術スタック選定を包括的に支援するスキルです。

実行フロー

Step 1: 要件分析と目標設定

ビジネス要件

ビジネス目標とKPI
ユーザー数と成長予測
提供する価値と差別化要因
予算とタイムライン

非機能要件

パフォーマンス:

APIレスポンス: p95 < 100ms
ページロード: < 2秒
スループット: X req/sec

可用性:

稼働率: 99.99%（月間ダウンタイム < 4.38分）
RTO（目標復旧時間）: < 1時間
RPO（目標復旧時点）: < 5分

セキュリティ:

データ暗号化（保存時・転送時）
認証・認可方式
コンプライアンス要件（GDPR、HIPAA等）

スケーラビリティ:

水平スケーリング対応
地理的分散
将来の成長への対応

Step 2: アーキテクチャパターンの選定

パターンの比較

モノリス vs マイクロサービス:

観点	モノリス	マイクロサービス
初期開発速度	高速	低速
デプロイ	シンプル	複雑
スケーリング	垂直	水平
技術選択の柔軟性	低	高
運用複雑度	低	高
チームサイズ	小〜中	中〜大

選定基準:

チームサイズ < 10人 → モノリス推奨
独立したデプロイが必要 → マイクロサービス
高速な初期開発が必要 → モノリス

その他のパターン

イベント駆動アーキテクチャ:

疎結合な非同期処理
メッセージキュー（Kafka、RabbitMQ）
イベントソーシング

CQRS（Command Query Responsibility Segregation）:

読み書き分離
最適化されたクエリモデル
高スループットシステム向け

サーバーレス:

コスト効率
自動スケーリング
イベント駆動処理

Step 3: コードアーキテクチャとフォルダ構造

アーキテクチャ原則

SOLID原則:

S - Single Responsibility Principle（単一責任の原則）
O - Open/Closed Principle（オープン/クローズドの原則）
L - Liskov Substitution Principle（リスコフの置換原則）
I - Interface Segregation Principle（インターフェース分離の原則）
D - Dependency Inversion Principle（依存性逆転の原則）

その他の重要原則:

関心の分離（Separation of Concerns）
DRY（Don't Repeat Yourself）
KISS（Keep It Simple, Stupid）
YAGNI（You Aren't Gonna Need It）

フォルダ構造設計

モノリス構造（例: Next.js/React）:

src/
├── app/                    # Next.js App Router
│   ├── (auth)/             # 認証関連ルート
│   ├── (dashboard)/        # ダッシュボード
│   └── api/                # API Routes
├── components/             # 再利用可能なコンポーネント
│   ├── ui/                 # 基本UIコンポーネント
│   ├── features/           # 機能固有コンポーネント
│   └── layouts/            # レイアウトコンポーネント
├── lib/                    # ライブラリとユーティリティ
├── stores/                 # 状態管理
├── types/                  # TypeScript型定義
└── styles/                 # グローバルスタイル

バックエンド構造（例: Node.js/Express）:

src/
├── api/                    # API層
│   ├── routes/             # ルート定義
│   ├── controllers/        # コントローラー
│   └── middlewares/        # ミドルウェア
├── domain/                 # ドメイン層（ビジネスロジック）
│   ├── models/             # ドメインモデル
│   ├── services/           # ビジネスロジック
│   └── repositories/       # データアクセス抽象化
├── infrastructure/         # インフラ層
├── config/                 # 設定
├── utils/                  # ユーティリティ
└── types/                  # 型定義

Step 4: システム構成設計

全体構成図

                    [CDN]
                      ↓
               [Load Balancer]
                      ↓
        ┌─────────────┼─────────────┐
        ↓             ↓             ↓
   [Web Server] [Web Server] [Web Server]
        └─────────────┼─────────────┘
                      ↓
              [API Gateway]
                      ↓
        ┌─────────────┼─────────────┐
        ↓             ↓             ↓
  [Service A]   [Service B]   [Service C]
        │             │             │
        └─────────────┼─────────────┘
                      ↓
              [Message Queue]
                      ↓
           [Background Workers]
                      ↓
        ┌─────────────┼─────────────┐
        ↓             ↓             ↓
   [Database]    [Cache]       [Storage]

Step 5: 技術スタック選定

選定基準

基準	評価ポイント
スケーラビリティ	将来の成長に対応できるか
開発速度	チームの生産性を最大化できるか
運用性	保守コストと運用負荷
コスト	初期費用とランニングコスト
エコシステム	コミュニティ、ドキュメント、サポート
チームスキル	学習コストと既存スキル

Step 6: セキュリティ設計

多層防御

ネットワークセキュリティ（VPC、WAF、DDoS保護）
アプリケーションセキュリティ（HTTPS、CORS、CSP）
データセキュリティ（暗号化、マスキング）
アクセス制御（最小権限、IAM/RBAC、MFA）

Step 7: スケーラビリティとパフォーマンス

水平スケーリング（ステートレス設計、オートスケーリング）
キャッシング戦略（CDN、アプリケーションキャッシュ、DBキャッシュ）
パフォーマンス最適化

Step 8: 可用性と災害復旧

マルチAZ/マルチリージョン構成
バックアップと復旧（RTO/RPO）
ヘルスチェックとモニタリング

Step 9: CI/CD パイプライン

パイプライン設計（Build → Test → Deploy → Monitor）
デプロイ戦略（Blue-Green、カナリア、ローリング）

出力成果物

アーキテクチャ設計書: システム全体の設計ドキュメント
システム構成図: 全体構成、データフロー
技術スタック選定理由: 各技術の選定根拠
非機能要件定義: パフォーマンス、可用性、セキュリティ目標
コスト試算: インフラコストの見積もり

ベストプラクティス

シンプルさを保つ: 過剰設計を避け、YAGNIの原則を守る
スケーラビリティを考慮: ステートレス設計、疎結合
セキュリティファースト: 多層防御、最小権限の原則
運用性を重視: 監視、自動化、文書化
コストを最適化: リソースの適正サイズ、自動スケーリング

designing-architecture

Install Skill

SKILL.md