@k2works/claude-code-booster 0.4.0 → 0.6.0

package/lib/assets/.claude/commands/analysis.md

@@ -81,7 +81,7 @@ docs/reference/ユースケース作成ガイド.md に基づくユースケー
 #### アーキテクチャ設計サポート
 
 @docs/reference/アーキテクチャ設計ガイド.md に基づくアーキテクチャ設計ドキュメントを作成します。
-成果物は architecture_backend.md と architecture_frontend.md です。
+成果物は architecture_backend.md と architecture_frontend.md architecture_infrastructure.md です。
 
 ```bash
 /analysis --architecture
@@ -92,6 +92,7 @@ docs/reference/ユースケース作成ガイド.md に基づくユースケー
 - @docs/requirements/user_story.md を参照
 - バックエンドアーキテクチャ設計を実施して @docs/design/architecture_backend.md を作成
 - フロンエンドアーキテクチャ設計を実施して @docs/design/architecture_frontend.md を作成
+- インフラストラクチャアーキテクチャ設計を実施して @docs/design/architecture_infrastructure.md を作成
 
 #### データモデル設計サポート
 

package/lib/assets/.devcontainer/devcontainer.json

@@ -0,0 +1,34 @@
+// For format details, see https://aka.ms/devcontainer.json. For config options, see the
+// README at: https://github.com/devcontainers/templates/tree/main/src/docker-in-docker
+{
+	"name": "Case Study Game Dev Container",
+	// Or use a Dockerfile or Docker Compose file. More info: https://containers.dev/guide/dockerfile
+	//"image": "mcr.microsoft.com/devcontainers/base:bullseye",
+	"build": {
+		"dockerfile": "../Dockerfile"
+	},
+
+	"features": {
+		"ghcr.io/devcontainers/features/docker-in-docker:2": {
+			"version": "latest",
+			"enableNonRootDocker": "true",
+			"moby": "true"
+		}
+	},
+
+	// Use 'forwardPorts' to make a list of ports inside the container available locally.
+	// "forwardPorts": [],
+
+	// Use 'postCreateCommand' to run commands after the container is created.
+	// "postCreateCommand": "docker --version",
+
+	// Configure tool-specific properties.
+  "customizations" : {
+    "jetbrains" : {
+      "backend" : "IntelliJ"
+    }
+  },
+
+	// Uncomment to connect as root instead. More info: https://aka.ms/dev-containers-non-root.
+	// "remoteUser": "root"
+}

package/lib/assets/docs/reference//343/202/242/343/203/274/343/202/255/343/203/206/343/202/257/343/203/201/343/203/243/350/250/255/350/250/210/343/202/254/343/202/244/343/203/211.md

@@ -17,36 +17,49 @@
 
 ```plantuml
 @startuml
-package "アプリケーション" {
-    package "フロントエンド" {
-        [Webアプリケーション] as WebApp
-    }
-
-    package "バックエンド" {
-        [APIサーバー] as API
-        database "データベース" as DB
+package "インフラストラクチャ" {
+    package "ネットワーク" {
+        package "アプリケーション" {
+            package "フロントエンド" {
+                [Webアプリケーション] as WebApp
+            }
+
+            package "バックエンド" {
+                [APIサーバー] as API
+                database "データベース" as DB
+            }
+
+            WebApp --> API : HTTP/REST
+            API --> DB : SQL/NoSQL
+        }
     }
-
-    WebApp --> API : HTTP/REST
-    API --> DB : SQL/NoSQL
 }
 @endtuml
 ```
 
 ### コンポーネント責務
 
-#### フロントエンド
+#### アプリケーション
+
+##### フロントエンド
+
 - **UI/UX**: ユーザーインターフェース・ユーザー体験
 - **状態管理**: アプリケーション状態とサーバー状態の管理
 - **API連携**: バックエンドとのデータ通信
 - **レンダリング**: 効率的な画面描画とユーザーインタラクション
 
-#### バックエンド
+##### バックエンド
+
 - **ビジネスロジック**: 業務ルール・制約の実装
 - **データ永続化**: データの保存・取得・更新・削除
 - **セキュリティ**: 認証・認可・データ保護
 - **外部システム連携**: API・メッセージング・ファイル処理
 
+#### インフラストラクチャ
+
+- **ネットワーク**: 負荷分散・DNS・CDN
+- **アプリケーション**: ホスティング: サーバー・コンテナ管理
+
 # バックエンドアーキテクチャ
 
 ## バックエンドアーキテクチャパターン選択フロー
@@ -1369,9 +1382,745 @@ stop
 4. **バンドルサイズ監視**: パフォーマンス劣化防止
 5. **ブラウザ互換性**: サポート対象ブラウザでの動作確認
 
-## まとめ
+# インフラストラクチャアーキテクチャ
+
+## インフラストラクチャ設計の原則
+
+### 基本方針
+
+- **Infrastructure as Code (IaC)**: インフラの設定をコード化し、バージョン管理
+- **自動化**: デプロイ・スケーリング・復旧の自動化
+- **モニタリングとオブザーバビリティ**: システム状態の可視化と追跡
+- **セキュリティファースト**: 設計段階からのセキュリティ考慮
+- **コスト最適化**: リソース利用の効率化とコスト管理
+
+## デプロイメントアーキテクチャパターン
+
+### 1. モノリシックデプロイメント
+
+#### 適用場面
+- **システム規模**: 小規模〜中規模
+- **チーム規模**: 小規模チーム
+- **特性**: 単一アプリケーション、シンプルなデプロイ
+
+#### 構造
+```plantuml
+@startuml
+node "Webサーバー" {
+  [アプリケーション]
+}
+
+database "データベース" as DB
+
+cloud "ロードバランサー" as LB
+
+LB --> [アプリケーション]
+[アプリケーション] --> DB
+@enduml
+```
+
+**メリット**:
+- シンプルな構成
+- 低い運用コスト
+- デプロイが容易
+
+**デメリット**:
+- スケーリングの柔軟性が低い
+- 単一障害点
+- 大規模化時の制約
+
+### 2. マイクロサービスデプロイメント
+
+#### 適用場面
+- **システム規模**: 大規模
+- **チーム規模**: 複数チーム
+- **特性**: 独立したサービス、高いスケーラビリティ
+
+#### 構造
+```plantuml
+@startuml
+cloud "APIゲートウェイ" as gateway
+
+node "認証サービス" {
+  [Auth Service]
+}
+
+node "予約サービス" {
+  [Reservation Service]
+}
+
+node "会議室サービス" {
+  [Room Service]
+}
+
+database "Auth DB" as authdb
+database "Reservation DB" as resdb
+database "Room DB" as roomdb
+
+gateway --> [Auth Service]
+gateway --> [Reservation Service]
+gateway --> [Room Service]
+[Auth Service] --> authdb
+[Reservation Service] --> resdb
+[Room Service] --> roomdb
+@enduml
+```
+
+**メリット**:
+- 独立したデプロイとスケーリング
+- 技術スタックの柔軟性
+- 障害の局所化
+
+**デメリット**:
+- 複雑な運用
+- 分散システムの課題
+- デバッグの困難さ
+
+### 3. コンテナオーケストレーション
+
+#### 適用場面
+- **デプロイ頻度**: 高頻度
+- **スケーリング要件**: 動的スケーリング
+- **特性**: Kubernetes、Docker等のコンテナ技術
+
+#### 構造
+```plantuml
+@startuml
+package "Kubernetesクラスター" {
+  node "マスターノード" {
+    [API Server]
+    [Scheduler]
+    [Controller]
+  }
+
+  node "ワーカーノード1" {
+    [Pod 1]
+    [Pod 2]
+  }
+
+  node "ワーカーノード2" {
+    [Pod 3]
+    [Pod 4]
+  }
+
+  [API Server] --> [Pod 1]
+  [API Server] --> [Pod 2]
+  [API Server] --> [Pod 3]
+  [API Server] --> [Pod 4]
+}
+@enduml
+```
+
+**メリット**:
+- 自動スケーリング
+- 高可用性
+- リソース効率化
+
+**デメリット**:
+- 高い学習コスト
+- 複雑な設定
+- 運用の複雑さ
+
+### 4. サーバーレスアーキテクチャ
+
+#### 適用場面
+- **負荷パターン**: 変動が大きい
+- **実行頻度**: イベント駆動、バースト型
+- **特性**: AWS Lambda、Azure Functions等
+
+#### 構造
+```plantuml
+@startuml
+cloud "APIゲートウェイ" as api
+rectangle "Lambda関数" as lambda1
+rectangle "Lambda関数" as lambda2
+rectangle "Lambda関数" as lambda3
+database "DynamoDB" as db
+queue "SQS" as queue
+
+api --> lambda1 : HTTP
+queue --> lambda2 : イベント
+lambda1 --> db
+lambda2 --> db
+lambda3 --> db
+@enduml
+```
+
+**メリット**:
+- 完全なサーバー管理不要
+- 自動スケーリング
+- 従量課金
+
+**デメリット**:
+- コールドスタート
+- ベンダーロックイン
+- ローカルテストの困難さ
+
+## ネットワークアーキテクチャ
+
+### ネットワーク構成パターン
+
+```plantuml
+@startuml
+package "DMZ（非武装地帯）" {
+  [ロードバランサー]
+  [リバースプロキシ]
+}
+
+package "プライベートネットワーク" {
+  package "アプリケーション層" {
+    [Webサーバー]
+    [APサーバー]
+  }
+
+  package "データ層" {
+    database "DB(Primary)"
+    database "DB(Replica)"
+  }
+}
+
+cloud "インターネット" as internet
+
+internet --> [ロードバランサー]
+[ロードバランサー] --> [リバースプロキシ]
+[リバースプロキシ] --> [Webサーバー]
+[Webサーバー] --> [APサーバー]
+[APサーバー] --> "DB(Primary)"
+"DB(Primary)" --> "DB(Replica)" : レプリケーション
+@enduml
+```
+
+### ネットワーク設計の要点
+
+| 要素 | 考慮事項 |
+|------|----------|
+| **負荷分散** | ロードバランサーによる複数サーバーへの分散 |
+| **セキュリティ** | ファイアウォール、WAF、DDoS対策 |
+| **可用性** | 冗長化、フェイルオーバー |
+| **パフォーマンス** | CDN、キャッシング、帯域幅 |
+
+## スケーリング戦略
+
+### 垂直スケーリング vs 水平スケーリング
+
+```plantuml
+@startuml
+left to right direction
+
+package "垂直スケーリング" {
+  node "サーバー" as v1 {
+    [CPU: 2コア\nメモリ: 4GB]
+  }
+
+  node "サーバー" as v2 {
+    [CPU: 8コア\nメモリ: 32GB]
+  }
+
+  v1 -right-> v2 : スペックアップ
+}
+
+package "水平スケーリング" {
+  node "サーバー1" as h1 {
+    [CPU: 2コア\nメモリ: 4GB]
+  }
+
+  node "サーバー2" as h2 {
+    [CPU: 2コア\nメモリ: 4GB]
+  }
+
+  node "サーバー3" as h3 {
+    [CPU: 2コア\nメモリ: 4GB]
+  }
+
+  h1 -right-> h2 : サーバー追加
+  h2 -right-> h3 : サーバー追加
+}
+@enduml
+```
+
+### スケーリング戦略の選択
+
+| 戦略 | メリット | デメリット | 適用場面 |
+|------|----------|------------|----------|
+| **垂直スケーリング** | シンプル、データ整合性保持 | 物理的上限、ダウンタイム | データベース、レガシーシステム |
+| **水平スケーリング** | 柔軟性、高可用性 | 複雑な設計、データ分散 | Webアプリケーション、マイクロサービス |
+
+### オートスケーリング
+
+```plantuml
+@startuml
+start
+
+:負荷監視;
+
+if (CPU使用率 > 80%?) then (yes)
+  :インスタンス追加;
+  :負荷分散設定更新;
+else if (CPU使用率 < 20%?) then (yes)
+  :インスタンス削減;
+  :負荷分散設定更新;
+else (no)
+  :現状維持;
+endif
+
+:負荷監視;
+
+stop
+@enduml
+```
+
+## 監視とログ管理
+
+### 監視アーキテクチャ
+
+```plantuml
+@startuml
+package "アプリケーション" {
+  [Webサーバー]
+  [APサーバー]
+  [DBサーバー]
+}
+
+package "監視システム" {
+  [メトリクス収集] as metrics
+  [ログ収集] as logs
+  [アラート管理] as alerts
+}
+
+package "可視化・分析" {
+  [ダッシュボード]
+  [ログ分析]
+  [トレーシング]
+}
+
+[Webサーバー] --> metrics
+[APサーバー] --> metrics
+[DBサーバー] --> metrics
+
+[Webサーバー] --> logs
+[APサーバー] --> logs
+[DBサーバー] --> logs
+
+metrics --> [ダッシュボード]
+logs --> [ログ分析]
+metrics --> alerts
+logs --> alerts
+@enduml
+```
+
+### 監視対象と指標
 
-### バックエンドアーキテクチャ選択の指針
+| カテゴリ | 監視項目 | 重要指標 |
+|----------|----------|----------|
+| **インフラ** | CPU、メモリ、ディスク、ネットワーク | 使用率、レスポンス時間 |
+| **アプリケーション** | レスポンスタイム、エラー率、スループット | レイテンシ、成功率 |
+| **ビジネス** | アクティブユーザー数、トランザクション数 | コンバージョン率、利用状況 |
+
+### ログ管理戦略
+
+#### ログレベルの定義
+
+```java
+// ✅ 適切なログレベルの使用
+public class ReservationService {
+    private static final Logger logger = LoggerFactory.getLogger(ReservationService.class);
+
+    public void createReservation(ReservationRequest request) {
+        logger.debug("予約作成開始: {}", request);
+
+        try {
+            var reservation = processReservation(request);
+            logger.info("予約作成成功: reservationId={}", reservation.getId());
+        } catch (BusinessException e) {
+            logger.warn("予約作成失敗（ビジネスエラー）: {}", e.getMessage());
+            throw e;
+        } catch (Exception e) {
+            logger.error("予約作成失敗（システムエラー）", e);
+            throw new SystemException("予約作成処理でエラーが発生しました", e);
+        }
+    }
+}
+```
+
+#### ログの集約と分析
+
+- **集約**: Fluentd、Logstash等でログを集約
+- **保存**: Elasticsearch、S3等で長期保存
+- **分析**: Kibana、CloudWatch Insights等で可視化・分析
+
+## セキュリティアーキテクチャ
+
+### 多層防御アーキテクチャ
+
+```plantuml
+@startuml
+left to right direction
+
+rectangle "インターネット" as internet
+
+package "セキュリティ層" {
+  rectangle "WAF/DDoS対策" as waf
+  rectangle "ファイアウォール" as fw
+  rectangle "IDS/IPS" as ids
+}
+
+package "認証・認可層" {
+  rectangle "認証サーバー" as auth
+  rectangle "API Gateway" as apigw
+}
+
+package "アプリケーション層" {
+  rectangle "暗号化通信" as encrypt
+  rectangle "入力検証" as validation
+  rectangle "アクセス制御" as access
+}
+
+package "データ層" {
+  database "暗号化DB" as db
+  rectangle "監査ログ" as audit
+}
+
+internet --> waf
+waf --> fw
+fw --> ids
+ids --> auth
+auth --> apigw
+apigw --> encrypt
+encrypt --> validation
+validation --> access
+access --> db
+db --> audit
+@enduml
+```
+
+### セキュリティベストプラクティス
+
+| 領域 | 対策 | 実装例 |
+|------|------|--------|
+| **ネットワーク** | ファイアウォール、WAF、DDoS対策 | AWS WAF, CloudFlare |
+| **認証・認可** | 多要素認証、OAuth2.0、RBAC | Auth0, Keycloak |
+| **データ保護** | 暗号化（保管時・転送時）、マスキング | TLS/SSL, AES-256 |
+| **監査** | アクセスログ、変更履歴、コンプライアンス | CloudTrail, 監査ログ |
+
+### セキュリティ実装例
+
+```java
+// ✅ セキュアな実装
+@RestController
+@RequestMapping("/api/reservations")
+public class ReservationController {
+
+    @PostMapping
+    @PreAuthorize("hasRole('USER')")  // 認可チェック
+    public ResponseEntity<Reservation> create(
+            @Valid @RequestBody CreateReservationRequest request) {  // 入力検証
+
+        // SQLインジェクション対策（PreparedStatement使用）
+        var reservation = reservationService.createReservation(request);
+
+        // 監査ログ記録
+        auditService.log("RESERVATION_CREATED", reservation.getId());
+
+        return ResponseEntity.ok(reservation);
+    }
+}
+```
+
+## バックアップと災害復旧
+
+### バックアップ戦略
+
+```plantuml
+@startuml
+package "本番環境" {
+  database "本番DB" as prod
+}
+
+package "バックアップ" {
+  database "日次バックアップ" as daily
+  database "週次バックアップ" as weekly
+  database "月次バックアップ" as monthly
+}
+
+package "災害復旧サイト" {
+  database "DR環境" as dr
+}
+
+prod --> daily : 毎日
+prod --> weekly : 毎週
+prod --> monthly : 毎月
+prod --> dr : リアルタイムレプリケーション
+@enduml
+```
+
+### RPO/RTO定義
+
+| 指標 | 意味 | 目標値例 |
+|------|------|----------|
+| **RPO (Recovery Point Objective)** | データ損失許容時間 | 1時間以内 |
+| **RTO (Recovery Time Objective)** | サービス復旧目標時間 | 4時間以内 |
+
+### ディザスタリカバリパターン
+
+#### 1. バックアップ＆リストア
+- **RPO**: 数時間〜1日
+- **RTO**: 数時間〜1日
+- **コスト**: 低
+- **用途**: 非重要システム
+
+#### 2. パイロットライト
+- **RPO**: 数分〜数時間
+- **RTO**: 1時間以内
+- **コスト**: 中
+- **用途**: ビジネス継続性が重要
+
+#### 3. ウォームスタンバイ
+- **RPO**: 数秒〜数分
+- **RTO**: 数分
+- **コスト**: 高
+- **用途**: 高可用性要求システム
+
+#### 4. マルチサイトアクティブ/アクティブ
+- **RPO**: ゼロ
+- **RTO**: ゼロ（自動フェイルオーバー）
+- **コスト**: 非常に高
+- **用途**: ミッションクリティカルシステム
+
+## Infrastructure as Code (IaC)
+
+### IaCツールの選択
+
+| ツール | 特徴 | 適用場面 |
+|--------|------|----------|
+| **Terraform** | マルチクラウド対応、宣言的 | クラウド横断的なインフラ管理 |
+| **CloudFormation** | AWS特化、AWSサービスとの統合 | AWS専用環境 |
+| **Ansible** | 構成管理、手続き型 | サーバー設定管理 |
+| **Pulumi** | 汎用プログラミング言語使用 | 複雑なロジック要求時 |
+
+### IaC実装例（Terraform）
+
+```hcl
+# ✅ VPC定義
+resource "aws_vpc" "main" {
+  cidr_block           = "10.0.0.0/16"
+  enable_dns_hostnames = true
+  enable_dns_support   = true
+
+  tags = {
+    Name        = "main-vpc"
+    Environment = var.environment
+  }
+}
+
+# ✅ サブネット定義
+resource "aws_subnet" "public" {
+  count                   = 2
+  vpc_id                  = aws_vpc.main.id
+  cidr_block              = "10.0.${count.index}.0/24"
+  availability_zone       = data.aws_availability_zones.available.names[count.index]
+  map_public_ip_on_launch = true
+
+  tags = {
+    Name = "public-subnet-${count.index + 1}"
+  }
+}
+
+# ✅ セキュリティグループ
+resource "aws_security_group" "web" {
+  name        = "web-sg"
+  description = "Security group for web servers"
+  vpc_id      = aws_vpc.main.id
+
+  ingress {
+    from_port   = 443
+    to_port     = 443
+    protocol    = "tcp"
+    cidr_blocks = ["0.0.0.0/0"]
+  }
+
+  egress {
+    from_port   = 0
+    to_port     = 0
+    protocol    = "-1"
+    cidr_blocks = ["0.0.0.0/0"]
+  }
+}
+```
+
+## CI/CDパイプライン
+
+### CI/CDアーキテクチャ
+
+```plantuml
+@startuml
+start
+
+:コード変更;
+:Git Push;
+
+fork
+  :ユニットテスト実行;
+fork again
+  :静的解析;
+fork again
+  :コードカバレッジ;
+end fork
+
+:ビルド;
+
+if (テスト成功?) then (yes)
+  :コンテナイメージ作成;
+  :イメージレジストリ登録;
+
+  if (本番デプロイ?) then (yes)
+    :承認待ち;
+    :本番デプロイ;
+  else (no)
+    :ステージングデプロイ;
+  endif
+
+  :スモークテスト;
+  :監視開始;
+else (no)
+  :通知（失敗）;
+  stop
+endif
+
+:デプロイ完了;
+
+stop
+@enduml
+```
+
+### デプロイメント戦略
+
+#### ブルーグリーンデプロイメント
+
+```plantuml
+@startuml
+left to right direction
+
+cloud "ロードバランサー" as lb
+
+package "Blue環境（現行）" {
+  node "App v1.0" as blue1
+  node "App v1.0" as blue2
+}
+
+package "Green環境（新規）" {
+  node "App v2.0" as green1
+  node "App v2.0" as green2
+}
+
+lb --> blue1
+lb --> blue2
+@enduml
+```
+
+**メリット**:
+- 即座にロールバック可能
+- ゼロダウンタイム
+- 本番環境での検証
+
+**デメリット**:
+- リソースが2倍必要
+- データベース移行の複雑さ
+
+#### カナリアデプロイメント
+
+```plantuml
+@startuml
+cloud "ロードバランサー" as lb
+
+package "本番環境" {
+  node "App v1.0" as old1
+  node "App v1.0" as old2
+  node "App v1.0" as old3
+  node "App v2.0（カナリア）" as canary
+}
+
+lb --> old1 : 75%
+lb --> old2 : 75%
+lb --> old3 : 75%
+lb --> canary : 25%
+@enduml
+```
+
+**メリット**:
+- リスク最小化
+- 段階的なロールアウト
+- 問題の早期発見
+
+**デメリット**:
+- 複雑な管理
+- バージョン混在期間
+
+## インフラストラクチャ評価基準
+
+### 品質属性評価マトリックス
+
+| 品質属性 | モノリシック | マイクロサービス | コンテナ | サーバーレス |
+|----------|:---:|:---:|:---:|:---:|
+| **運用複雑性** | ⭐⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ |
+| **スケーラビリティ** | ⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
+| **コスト効率** | ⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
+| **デプロイ速度** | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
+| **可用性** | ⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
+| **監視・デバッグ** | ⭐⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐ | ⭐⭐ |
+
+### コスト最適化戦略
+
+| 戦略 | 実装方法 | 削減効果 |
+|------|----------|----------|
+| **リソース最適化** | 適切なインスタンスサイズ選択 | 20-40% |
+| **予約インスタンス** | 長期コミットメントで割引 | 40-60% |
+| **スポットインスタンス** | 余剰リソースの活用 | 70-90% |
+| **オートスケーリング** | 需要に応じた自動調整 | 30-50% |
+| **ストレージ最適化** | ライフサイクル管理、圧縮 | 30-60% |
+
+## インフラストラクチャ移行戦略
+
+### クラウド移行パターン
+
+```plantuml
+@startuml
+start
+
+:現状分析;
+
+if (移行戦略) then (リフト＆シフト)
+  :既存システムをそのままクラウドへ;
+  :最小限の変更;
+else if (リプラットフォーム) then
+  :軽微な最適化;
+  :クラウドサービス活用;
+else if (リアーキテクト) then
+  :アプリケーション再設計;
+  :クラウドネイティブ化;
+else (リビルド)
+  :完全な再構築;
+  :最新アーキテクチャ採用;
+endif
+
+:移行実行;
+:検証;
+:最適化;
+
+stop
+@enduml
+```
+
+### 移行時の注意点
+
+1. **段階的移行**: すべてを一度に移行せず、段階的に実施
+2. **パイロットプロジェクト**: 小規模システムで先行検証
+3. **データ移行計画**: データの整合性とダウンタイム最小化
+4. **セキュリティ**: クラウド環境でのセキュリティ要件確認
+5. **コスト管理**: 移行コストと運用コストの可視化
+
+# まとめ
+
+## バックエンドアーキテクチャ選択の指針
 
 1. **業務ドメインの理解**: 中核業務と補完業務の明確な識別
 2. **データ複雑性の評価**: エンティティ関係とビジネスルールの複雑さ
@@ -1379,7 +2128,7 @@ stop
 4. **チーム能力の評価**: 技術的習熟度と学習意欲
 5. **長期戦略の整合**: 将来的な拡張性と保守性の確保
 
-### フロントエンドアーキテクチャ選択の指針
+## フロントエンドアーキテクチャ選択の指針
 
 1. **プロジェクト規模**: 小規模・中規模・大規模に応じた構造設計
 2. **ユーザー体験要件**: SEO・パフォーマンス・インタラクティビティの優先順位
@@ -1387,42 +2136,59 @@ stop
 4. **チーム構成**: フロントエンド専任・フルスタック・QAエンジニアの有無
 5. **技術的制約**: ブラウザサポート・既存システム・運用環境
 
-### 成功要因
+## インフラストラクチャアーキテクチャ選択の指針
+
+1. **システム規模とトラフィック**: 予想される負荷・成長率・ピーク時の要件分析
+2. **可用性要件**: SLA・ダウンタイム許容度・災害復旧要件の定義
+3. **セキュリティ要件**: コンプライアンス・データ保護・監査要件の評価
+4. **運用体制**: チームの技術力・運用負荷・自動化レベルの考慮
+5. **コスト制約**: 初期投資・運用コスト・スケーリングコストのバランス
+
+## 成功要因
 
-#### バックエンド
+### バックエンド
 - **適切なパターン選択**: 業務特性に応じた最適なアーキテクチャの採用
 - **段階的な実装**: 小さく始めて継続的に改善
 - **品質の作り込み**: テストファースト・継続的インテグレーション
 - **ドメイン駆動設計**: ビジネスルールの適切な表現と分離
 
-#### フロントエンド
+### フロントエンド
 - **適切な技術選択**: 要件に応じたライブラリ・フレームワークの選定
 - **コンポーネント設計**: 再利用性と保守性を両立した設計
 - **状態管理戦略**: スケールに応じた適切な状態管理手法の採用
 - **パフォーマンス最適化**: ユーザー体験を重視したパフォーマンス設計
 
-### 統合的成功要因
+### インフラストラクチャ
+- **自動化の徹底**: IaC によるインフラ管理とデプロイメントの自動化
+- **監視とオブザーバビリティ**: 包括的な監視体制と問題の早期検知
+- **セキュリティの組み込み**: 設計段階からのセキュリティ対策実装
+- **コスト最適化**: リソース利用の継続的な見直しと最適化
+
+## 統合的成功要因
 
 - **チーム教育**: アーキテクチャ原則の共有と実践
 - **継続的改善**: 定期的な設計見直しとリファクタリング
 - **品質文化**: 自動テスト・コードレビュー・静的解析の徹底
 - **段階的移行**: リスクを最小化した漸進的なアーキテクチャ改善
 
-### 実践ポイント
+## 実践ポイント
+
+### 開発初期
 
-#### 開発初期
 1. **要件に基づく技術選択**: 過度な技術より要件適合性を重視
 2. **プロトタイプ開発**: アーキテクチャ妥当性の早期検証
 3. **チーム合意形成**: 技術選択の背景と理由の共有
 
-#### 開発中期
+### 開発中期
+
 1. **継続的リファクタリング**: 設計負債の早期解消
 2. **パフォーマンス監視**: 品質メトリクスに基づく改善
 3. **テストカバレッジ**: アーキテクチャ変更に対する安全性確保
 
-#### 運用期
+### 運用期
+
 1. **監視・メトリクス**: 実装の効果測定と改善指針
 2. **技術的負債管理**: 計画的なアーキテクチャ改善
 3. **スケーラビリティ対応**: 成長に応じたアーキテクチャ進化
 
-良いアーキテクチャは、システムの長期的成功の基盤となります。本ガイドを参考に、バックエンド・フロントエンドそれぞれの特性を理解し、プロジェクトに最適なアーキテクチャを選択・実装してください。
+良いアーキテクチャは、システムの長期的成功の基盤となります。本ガイドを参考に、アプリケーション・インフラストラクチャそれぞれの特性を理解し、プロジェクトに最適なアーキテクチャを選択・実装してください。

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@k2works/claude-code-booster",
-  "version": "0.4.0",
+  "version": "0.6.0",
   "description": "AI Agent Development Support Tool",
   "main": "main.js",
   "bin": {