k2works/operating-review

運用成果物レビュー

運用フェーズの成果物（インフラ定義、CI/CD パイプライン、デプロイ設定、運用スクリプト、Dockerfile、環境設定など）を複数の XP エージェントで並列レビューし、信頼性・セキュリティ・運用性の観点からフィードバックを統合する。

レビューの価値

運用成果物の不備は本番障害に直結する。インフラ設定のミス、セキュリティの穴、デプロイ手順の不備は、発見が遅れるほど影響が大きくなる。複数の専門的視点で事前に検証することで、本番環境のリスクを最小化する。

レビューエージェント

| エージェント | 視点 | 着眼点 | |:---|:---|:---| | xp-architect | インフラ設計 | アーキテクチャとの整合、スケーラビリティ、可用性、コスト効率、IaC のモジュール化 | | xp-tester | 信頼性・セキュリティ | セキュリティ設定、権限の最小化、障害シナリオ、ロールバック手順、テスト可能性 | | xp-project-manager | 運用性・持続可能性 | 運用手順の明確さ、ドキュメントの十分性、チームへの影響、持続可能なペースの維持 |

レビュー対象と重点観点

| 成果物 | 重点観点 | |:---|:---| | Terraform / IaC コード | セキュリティグループ、IAM ポリシー、状態管理、モジュール設計 | | CI/CD パイプライン | ビルドの再現性、テスト網羅性、シークレット管理、OIDC 認証 | | Dockerfile / docker-compose | ベースイメージの安全性、レイヤーの最適化、マルチステージビルド | | デプロイ設定 | ロールバック手順、ヘルスチェック、環境変数管理、段階的デプロイ | | 運用スクリプト | エラーハンドリング、冪等性、ログ出力、ドキュメント整合性 | | 環境設定 | 環境間の差異管理、シークレット管理、設定の外部化 |

レビューワークフロー

1. レビュー対象の特定

レビュー対象のファイルを特定する。ユーザーが明示的に指定しない場合は、以下のディレクトリを確認する。

• ops/ — 運用スクリプト、Gulp タスク
• infra/ / terraform/ — IaC 定義
• .github/workflows/ — CI/CD パイプライン
• docker-compose*.yml / Dockerfile* — コンテナ定義
• docs/operation/ — 運用手順書

2. エージェントの並列起動

Agent ツールを使い、3 つのエージェントを 同一メッセージで並列起動 する。各エージェントには以下を指示する。

あなたは {エージェント名} です。
.claude/agents/{エージェント名}.md の定義に従ってレビューしてください。

## レビュー対象
{ファイルパスとその内容}

## 関連コンテキスト
{関連する設計ドキュメント、運用要件、環境情報}

## レビュー観点
{エージェント固有の着眼点}

## 出力形式
以下の形式でフィードバックを返してください：

### 評価サマリー
（1-2 文で全体評価）

### 良い点
- （具体的に）

### 改善提案
- 【重要度: 高/中/低】（ファイル:行番号）（具体的な改善提案と理由）

### セキュリティ懸念
- （権限、シークレット、ネットワーク設定に関する懸念）

### 運用リスク
- （障害時の影響範囲、復旧手順の有無、監視の網羅性）

### スコープ外の発見
- （レビュー対象外だが報告すべき問題）

Agent ツールが利用できない場合のフォールバック

Agent ツールが利用できない環境では、3 つの視点を逐次的にシミュレートする。各エージェントの定義ファイル（.claude/agents/{エージェント名}.md）を読み、その視点でレビューを順次実施する。出力形式は同一のテンプレートに従う。

3. フィードバックの統合

全エージェントのフィードバックを受け取った後、以下の形式で統合レポートを作成する。

## 運用レビュー結果

### レビュー対象
- {ファイル名 / 設定名}

### 総合評価
（全エージェントの評価を統合した 2-3 文の評価）

### 改善提案（重要度順）

#### 高（本番適用前に対応必須）
| # | 提案 | 箇所 | 指摘元 | 理由 |
|---|------|------|--------|------|

#### 中（対応推奨）
| # | 提案 | 箇所 | 指摘元 | 理由 |
|---|------|------|--------|------|

#### 低（改善の余地あり）
| # | 提案 | 箇所 | 指摘元 | 理由 |
|---|------|------|--------|------|

### 矛盾事項

複数エージェントの指摘が相反する場合、ここに記載する。

| # | 視点 A | 視点 B | 論点 | 推奨判断 |
|---|--------|--------|------|----------|

### エージェント別フィードバック詳細

<details>
<summary>xp-architect（高: N / 中: N / 低: N）</summary>
（フィードバック全文）
</details>

<details>
<summary>xp-tester（高: N / 中: N / 低: N）</summary>
（フィードバック全文）
</details>

<details>
<summary>xp-project-manager（高: N / 中: N / 低: N）</summary>
（フィードバック全文）
</details>

4. 改善アクションの提案

重要度「高」の指摘（特にセキュリティ関連）は具体的な修正内容を提案する。本番環境に関する変更は、適用前にユーザーの明示的な承認を得る。

5. レビュー結果の保存

統合レポートを docs/review/{対象名}_review_{YYYYMMDD}.md に保存する。過去のレビュー結果と比較できるようにし、改善のトレーサビリティを確保する。

レビュー完了条件

以下をすべて満たした場合にレビュー完了とする。

• 全エージェントのフィードバックが収集済み
• 統合レポートが作成済み
• 重要度「高」の指摘について対応方針（修正する / 許容する / 保留する）が決定済み
• レビュー結果がドキュメントとして保存済み

注意事項

• セキュリティに関する指摘は常に重要度「高」として扱う
• 本番環境に影響する変更は慎重に扱い、段階的な適用を推奨する
• IaC の変更は plan 結果を確認してから apply する原則を維持する
• 運用手順書の更新漏れがないかも確認する

関連スキル

• orchestrating-operation — 運用フェーズの全体ワークフロー
• operating-setup — 環境構築
• operating-provision — IaC プロビジョニング
• operating-cicd — CI/CD パイプライン構築
• operating-deploy — デプロイ・ロールバック
• git-commit — レビュー結果の保存後のコミット