AI-DLC Workflow V2のOperation Phase: コードの先にある"動かし続ける"設計
コードを書いたら終わり？ もちろん違いますよね。デプロイして、監視して、障害に備えて、パフォーマンスを検証して、フィードバックを次に活かす。AI-DLC Workflow V2のOperation phaseはこの「コードの先」を7ステージで構造化しています。シリーズ第12回。
Series: AI-DLC Workflow V2の解説 (31 articles)
- …
- 12AI-DLC Workflow V2のOperation Phase: コードの先にある"動かし続ける"設計 This article
1. なぜOperationがワークフローに含まれるのか
課題: コードを書いた後の「空白地帯」
Construction phase でBolt・Batch・Swarmの仕組みを見てきました。コードが生成され、テストが通り、CIパイプラインが構成された。ではその先はどうでしょうか。
多くの開発プロジェクトで「コードを書く」と「本番で動かす」の間には構造化されていない空白地帯があります。デプロイ手順は属人化し、監視は後回しになり、障害対応は場当たり的になる。AI-DLC Workflow V2（以降V2）の前身であるV1では、このOperation phaseは方法論のホワイトペーパーで定義されていましたが、ツール実装としては提供されていませんでした。
解決: 7ステージによる構造化
V2ではこの空白地帯を7つのステージとして具体化しています。
| # | ステージ名 | 識別名 | リードエージェント | 何が決まるか |
|---|---|---|---|---|
| 4.1 | Deployment Pipeline | deployment-pipeline | Pipeline Deploy Agent | CDパイプライン構成とデプロイ戦略 |
| 4.2 | Environment Provisioning | environment-provisioning | AWS Platform Agent | 環境のプロビジョニングと検証 |
| 4.3 | Deployment Execution | deployment-execution | Pipeline Deploy Agent | デプロイ実行とスモークテスト |
| 4.4 | Observability Setup | observability-setup | Operations Agent | ダッシュボード・アラーム・SLO |
| 4.5 | Incident Response | incident-response | Operations Agent | ランブックとエスカレーション |
| 4.6 | Performance Validation | performance-validation | Quality Agent | 負荷テストとNFR検証 |
| 4.7 | Feedback & Optimization | feedback-optimization | Operations Agent | SLOレポートとコスト分析 |
前半3ステージ（4.1〜4.3）が「どう届けるか」を担い、後半4ステージ（4.4〜4.7）が「動かし続ける品質」を積み重ねる構造です。
仕組み: CONDITIONALとスコープ制御
Operation phaseのすべてのステージはCONDITIONAL（条件付き実行）です。Ideation phaseやInception phaseにはALWAYS（必ず実行）のステージがありましたが、このフェーズではプロジェクトの性質に応じて実行ステージが切り替わります。
V2の設計原則「User decides, AI executes（人間が決定し、AIが実行する）」はこのフェーズでも変わりません。デプロイ戦略の選定、SLOの定義、インシデント対応の方針。運用に関わる判断はすべて承認ゲートを通過します。
また、全ステージに2つのセンサー（自動検証の仕組み）が設定されています。
required-sections（成果物の構成チェック）とupstream-coverage（上流成果物の参照チェック）です。上流の設計を無視して成果物を生成する事態を防ぐ仕組みとして、参照チェーンが長いOperation phaseでは特に効果を発揮します。2. デプロイの構造化（Deployment Pipeline & Execution）
課題: デプロイの属人化とリスク
では、コードを本番環境に届ける工程から見ていきましょう。
Construction phaseでCIパイプライン（ステージ3.7）が構成され、ビルドとテストは自動化されています。しかしその先、テストを通過したアーティファクトを「どの環境に」「どの順序で」「どの戦略で」届けるかは、別の設計判断です。CIは「コードを統合してテストする」仕組みであり、CDは「テスト済みコードを安全に届ける」仕組み。この区別が曖昧なまま進むと、デプロイが特定の人にしかできない作業になりがちです。
解決: 3ステージの直列フロー
V2ではデプロイを3つのステージに分解しています。
Deployment Pipeline（4.1） はCDパイプラインの設計です。Pipeline Deploy Agentがリードし、以下の判断を承認ゲートで問います。
- デプロイ戦略の選定（ブルー/グリーン、カナリア、ローリング）
- 環境昇格ゲート（dev → staging → prod）
- 本番デプロイの承認ワークフロー
- ロールバック手順
- フィーチャーフラグ戦略（CloudWatch Evidently、AppConfig）
成果物はcd-config（CDパイプライン構成）、deployment-strategy（デプロイ戦略と選定理由）、rollback-runbook（ロールバック手順書）の3つです。
Environment Provisioning（4.2） は環境の準備と検証です。AWS Platform Agentがリードし、DevSecOps Agentがセキュリティ態勢を独立した視点で検証します。VPC、サブネット、セキュリティグループ、シークレット注入、クロスアカウント接続が正しく構成されているかを確認し、environment-inventory（環境一覧）とvalidation-report（検証レポート）を生成します。
Deployment Execution（4.3） は実際のデプロイです。Pipeline Deploy Agentがリードし、Developer Agentがデータベースマイグレーションの実行をサポートします。デプロイ前チェック、マイグレーション実行、スモークテスト、ヘルスチェックを経て、deployment-log、smoke-test-results、health-check-reportを生成します。
仕組み: 上流成果物の受け渡しと欠損への対応
この3ステージは直列構造であり、Deployment Pipeline（4.1）の出力がEnvironment Provisioning（4.2）の入力に、Environment Provisioningの出力がDeployment Execution（4.3）の入力になります。加えて、Construction phaseからも成果物を受け取ります。
1
2
3
4
5
Construction Phase Operation Phase
───────────────── ───────────────
CI Pipeline (3.7) ─── ci-config, quality-gates ───→ Deployment Pipeline (4.1)
Infrastructure Design (3.4) ─── infrastructure-specification ───→ Deployment Pipeline (4.1), Environment Provisioning (4.2)
Build and Test (3.6) ─── build-test-results ──────────→ Deployment Execution (4.3)ここで重要なのは、
security-patchスコープでは上流のCI PipelineやInfrastructure Designがスキップされる場合があるという点です。その場合、エージェントはワークスペースの既存パイプライン構成を読み取り、実際にデプロイされている構成に基づいてCDパスを設計します。存在しない成果物の内容を推測で補うことはしません。3. 環境を安全に作る（Environment Provisioning）
課題: 設計と実環境のギャップ
ここで少し立ち止まって、Environment Provisioning（4.2）を掘り下げてみましょう。
Construction phaseのInfrastructure Design（3.4）でインフラ設計は完了しています。しかし「設計書がある」ことと「環境が正しく構成されている」ことは別の話です。セキュリティグループのルールが設計と異なる、シークレットの注入パスが間違っている、クロスアカウント接続の信頼ポリシーが不足している。設計と実装の間のギャップは、デプロイ時に初めて露呈することが多いのです。
解決: プロビジョニングと検証の分離
V2のEnvironment Provisioningは「作る」と「確認する」を明確に分けています。AWS Platform Agentが環境をプロビジョニングした後、DevSecOps AgentとCompliance Agentが独立した視点で検証を行います。
確認される観点は以下の通りです。
- インフラ設計通りに環境がプロビジョニングされているか
- VPC、サブネット、セキュリティグループ、NACLは正しいか
- シークレット（Secrets Manager / Parameter Store）が正しく注入されているか
- クロスアカウント・クロスVPC接続が検証されているか
仕組み: マルチエージェントによる独立検証
このステージの特徴は、リードエージェント（AWS Platform Agent）とは別にDevSecOps AgentとCompliance Agentがサポートに入る点です。プロビジョニングする側と検証する側を分けることで、「作った人が自分でOKを出す」という構造を避けています。
入力として受け取る上流成果物は、infrastructure-specification（Infrastructure Design 3.4から）、cd-config（Deployment Pipeline 4.1から）の2つ。設計根拠とパイプライン要件の両方を参照しながら環境を構成し、成果物としてenvironment-inventory（環境一覧）とvalidation-report（検証レポート）を出力します。
4. 見える化する（Observability Setup）
課題: 「動いてるっぽい」では足りない
デプロイが完了し、システムが本番環境で稼働を始めました。ここで一つ問いかけてみましょう。「ちゃんと動いてるの？」に、どう答えますか。
エラーが出ていないことと、正常に動いていることは同じではありません。レイテンシがじわじわ悪化している、特定のエンドポイントだけスループットが落ちている、メモリ使用率が少しずつ上昇している。こうした兆候は、計装して可視化しなければ気づけません。
解決: ゴールデンシグナルとSLOによる体系的な可観測性
Operations Agentがリードするこのステージでは、以下を体系的に設定します。
- ゴールデンシグナル（レイテンシ、トラフィック、エラー率、飽和度）の追跡対象
- SLO/SLI（サービスレベル目標/指標）の定義
- ダッシュボードレイアウト
- ログ保持期間と集約ルール
- 分散トレーシングの計装
成果物は6つ。Operation phaseの7ステージの中でも成果物の数が多いステージです。
| 成果物 | 内容 |
|---|---|
| dashboards.md | CloudWatchダッシュボード構成 |
| alarms.md | アラーム定義（重要度、SNSルーティング、エスカレーション） |
| slo-config.md | SLO/SLI追跡の構成 |
| log-queries.md | CloudWatch Logs Insightsの保存済みクエリ |
| tracing-config.md | X-Rayトレーシング構成 |
| anomaly-config.md | 異常検知の構成 |
仕組み: NFR Designの「設計」をAWSサービスの「構成」に変換する
このステージの本質は「変換」です。Construction phaseのNFR Design（3.3）から4つの成果物を受け取ります。
- performance-design（パフォーマンス設計）
- security-design（セキュリティ設計）
- reliability-design（信頼性設計）
- monitoring-design（監視設計）
NFR Designで「何を監視すべきか」を決め、Observability Setupで「どう監視するか」を実装する関係です。抽象的な設計がCloudWatch、X-Ray、CloudWatch Logs Insightsといった具体的なAWSサービスの構成として落とし込まれます。
アラーム定義には重要度（Severity）、SNSルーティング、エスカレーション先が含まれるため、「アラームが鳴ったら誰にどう通知するか」まで構成されます。この情報は次のIncident Response（4.5）の入力になります。
5. 障害に備える（Incident Response）
課題: 障害時の「誰が何をする」が決まっていない
可観測性が整い、アラームが鳴る仕組みができました。では、実際にアラームが鳴った時、チームはどう動きますか。
障害対応で時間を浪費しがちなのは「何が起きているか分からない」状態よりも、「誰が何をすればいいか分からない」状態です。エスカレーションパスが不明、ランブックが存在しない、あるいは存在するが古くて役に立たない。こうした状態では、復旧時間は担当者の経験値に依存してしまいます。
解決: ランブックとエスカレーションの事前定義
Operations Agentがリードするこのステージでは、障害発生前に以下を定義しておきます。
- 想定される障害モード（失敗パターン）
- エスカレーションパスとオンコールローテーション
- 自動修復（自動リメディエーション）の可能性
- インシデント中のコミュニケーション手順
- RTO（目標復旧時間）/ RPO（目標復旧時点）
成果物は3つです。
| 成果物 | 内容 |
|---|---|
| runbooks.md | SSM Automationランブックライブラリ |
| incident-plan.md | インシデント対応計画（AWS Incident Managerと統合） |
| escalation-matrix.md | エスカレーションマトリクス |
ランブックとは、障害発生時に実行する手順書です。V2ではSSM（AWS Systems Manager）Automationのランブックとして生成されるため、手動手順だけでなく自動化可能な復旧アクションも含まれます。災害復旧手順やAWS Backupの構成もこのステージの成果物に含まれ、「通常のインシデント」と「災害レベルの障害」の両方に備える構造です。
仕組み: Observability Setupとの対応付け
このステージはObservability Setup（4.4）の出力であるdashboardsとalarmsを入力として受け取ります。「このアラームが鳴ったら、このランブックを実行する」という対応付けを行うため、可観測性の設定が先に完了している必要があるのです。
加えて、reliability-design（NFR Design 3.3から）、security-design（NFR Design 3.3から）、infrastructure-specification（Infrastructure Design 3.4から）も参照します。信頼性設計で定義したRTO/RPOがランブックの復旧目標になり、インフラ仕様の構成がロールバック手順の前提になるという関係です。
6. 性能を検証する（Performance Validation）
課題: 設計通りの性能が出ているか分からない
振り返ってみましょう。Construction phaseのNFR Requirements（3.2）で「p99レイテンシ200ms以下」「秒間1000リクエストを処理」といった非機能要件を定義し、NFR Design（3.3）でその実現方式を設計し、コードに落とし込みました。しかし、実際に本番相当の負荷をかけた時、その目標を達成できているかはまだ誰も確認していません。
単体テストや統合テストでは、負荷条件下での振る舞いは検証できません。1リクエストが成功することと、1000リクエスト/秒で安定動作することは別の検証です。
解決: 負荷テストとNFR検証マトリクス
ここで注目してほしいのは、リードエージェントがOperations AgentではなくQuality Agentである点です。パフォーマンス検証は「品質の検証」であり、Quality Agentの専門領域です。Operations Agentは可観測性と障害対応を担当し、性能目標の達成判定はQuality Agentが行うという分担になっています。
承認ゲートで問われる内容は以下の通りです。
- 想定トラフィックパターン（定常状態、ピーク、バースト）
- 目標レイテンシのパーセンタイル（p50、p95、p99）
- システムが維持すべきスループット
- ボトルネックの可能性がある箇所
成果物は3つです。
| 成果物 | 内容 |
|---|---|
| load-test-plan.md | 負荷テスト計画 |
| load-test-results.md | テスト結果（レイテンシ、スループット、エラー率） |
| nfr-validation-matrix.md | NFR検証マトリクス（目標値 vs 実測値） |
仕組み: 要件・設計・実測の三点突合
このステージはNFR Requirements（3.2）とNFR Design（3.3）の両方から成果物を受け取ります。
- performance-requirements / scalability-requirements（要件: 何を達成すべきか）
- performance-design / scalability-design（設計: どう達成する設計にしたか）
- dashboards（Observability Setup 4.4から: 計測の仕組み）
「要件」と「設計」と「実測値」を三点で突き合わせるのがNFR検証マトリクスです。言い換えれば、このステージはConstruction phaseで定義した非機能要件の「答え合わせ」にあたります。
目標を達成していればそのまま運用に入り、達成していなければボトルネック分析とキャパシティプランニングの提言が成果物に含まれます。Observability Setup（4.4）のダッシュボードを入力としている理由は、負荷テスト中のメトリクスをCloudWatchやX-Rayの証跡として収集・分析するためです。テスト結果は推測ではなく、計装されたデータに基づきます。
7. 次に活かす（Feedback & Optimization）
課題: 運用データが次の開発に活かされない
ここまでの6ステージでシステムは本番で稼働し、監視され、障害に備え、性能が検証されています。しかし、運用から得られるデータが「見て終わり」になっていないでしょうか。
SLOを定義しても達成状況を定期的に評価しなければ意味がありません。コストは最適化しなければ増え続けます。構成ドリフト（意図しない構成変更）は検出しなければ蓄積します。そして何より、これらの運用上の知見が次の開発サイクルにフィードバックされなければ、同じ問題を繰り返すことになります。
解決: フィードバックループを閉じる
Operation phaseの最終ステージであり、V2ワークフロー全体の最終ステージでもあるFeedback & Optimization（4.7）は、運用データを集約し、次のサイクルへの橋渡しを形成します。
Operations Agentがリードし、AWS Platform Agentがコスト最適化の観点でサポートします。
承認ゲートで問われる内容は以下の通りです。
- SLOは達成されているか。エラーバジェットの消費速度はどうか
- コスト最適化の機会はあるか
- 構成ドリフトは発生していないか
- ユーザー行動パターンから新機能やバグの示唆はあるか
- 自動化で解消できる運用トイル（手作業の繰り返し）はあるか
成果物は4つです。
| 成果物 | 内容 |
|---|---|
| slo-report.md | SLO達成状況レポート |
| cost-analysis.md | AWS Cost Explorer分析と最適化提言 |
| drift-report.md | AWS Config構成ドリフト検出レポート |
| feedback-loop.md | フィードバックループ文書（次のIdeationサイクルへの入力） |
仕組み: サイクルを閉じる承認ゲート
このステージの承認ゲートは他のステージと異なり、3つの選択肢が提示されます。
- Approve（承認） — ワークフロー完了
- Request Changes（修正依頼） — フィードバック内容を修正
- Start New Ideation Cycle（新しいIdeationサイクルを開始） — フィードバックを基に次のワークフローを起動
Approveを選択すると、AI-DLCワークフロー全体が完了します。Start New Ideation Cycleを選択すると、feedback-loop.mdの内容が次のIdeation phaseのIntent Capture（1.1）への入力となり、新しい開発サイクルが始まります。
具体的な情報源は、AWS Cost Explorerによるコスト分析、AWS Configによる構成ドリフト検出、Trusted Advisorによる運用改善提案です。エージェントはこれらから得た知見を集約し、「エラーバジェット消費が加速している」「特定リージョンのコストが想定を超えている」「セキュリティグループに意図しない変更が入った」といった具体的な事実をフィードバック文書にまとめます。
入力として受け取る上流成果物は、必須がdashboards、alarms、slo-config（すべてObservability Setup 4.4から）とdeployment-log（Deployment Execution 4.3から）。オプションとしてload-test-results（Performance Validation 4.6から）とincident-plan（Incident Response 4.5から）も参照します。
AI-DLCの5フェーズ構造は一方通行のウォーターフォールではなく、運用から得た知見を次の開発に還すサイクルです。Feedback & Optimizationはそのサイクルの起点と終点を明示的につないでいるステージです。
8. スコープ別の実行パターン
最後に、スコープごとにOperation phaseがどう変わるかを整理しておきましょう。
課題: すべてのプロジェクトに全ステージは必要ない
セキュリティパッチを適用するだけのプロジェクトに負荷テストやインシデント対応計画は不要です。一方でエンタープライズ規模の新機能には7ステージすべてが必要かもしれません。ワークフローが固定的だと、軽量なプロジェクトにはオーバーヘッドになり、重要なプロジェクトには不足するという問題が生じます。
解決: スコープによる自動的なステージ選択
V2ではスコープ設定により、実行されるステージが自動的に決まります。
| スコープ | 実行されるステージ | 考え方 |
|---|---|---|
| enterprise | 全7ステージ | フルカバレッジ |
| feature | 全7ステージ | 機能追加は運用影響も含めて検証 |
| workshop | 全7ステージ | 学習目的で全工程を体験 |
| infra | Deployment Pipeline, Environment Provisioning, Deployment Execution, Observability Setup | デプロイと可観測性まで。障害対応・性能検証はスキップ |
| security-patch | Deployment Pipeline, Deployment Execution | パイプラインとデプロイ実行のみ。素早く本番へ届ける |
| mvp, poc, bugfix, refactor | なし | Operation phase自体がスコープ外 |
仕組み: エージェントの分担とConstruction phaseからの接続
スコープに関わらず、Operation phaseのエージェント分担は一定です。
| エージェント | 担当ステージ | 役割 |
|---|---|---|
| Pipeline Deploy Agent | Deployment Pipeline, Deployment Execution | パイプライン構成とデプロイ実行 |
| AWS Platform Agent | Environment Provisioning | 環境プロビジョニングと検証 |
| Operations Agent | Observability Setup, Incident Response, Feedback & Optimization | 可観測性、障害対応、フィードバック |
| Quality Agent | Performance Validation | パフォーマンス検証 |
Operations Agentが7ステージ中3ステージをリードしており、このフェーズの中心的な存在です。Construction phaseではDeveloper AgentやArchitect Agentが中心でしたが、Operation phaseでは運用の専門家にバトンが渡ります。
Operation phaseがConstruction phaseから受け取る成果物を整理すると、以下の通りです。
- ci-config / quality-gates / cicd-pipeline（CI Pipeline 3.7から）→ CDパイプラインの基盤
- infrastructure-specification（Infrastructure Design 3.4から）→ 環境構成とデプロイ先の設計根拠
- performance-design / security-design / reliability-design / monitoring-design（NFR Design 3.3から）→ 可観測性とパフォーマンス検証の基準
- performance-requirements / scalability-requirements（NFR Requirements 3.2から）→ 性能検証の目標値
- build-test-results（Build and Test 3.6から）→ デプロイ対象の品質証跡
Construction phaseの設計・実装がOperation phaseの「仕様書」になるという関係です。Operation phaseは新しいものを作るのではなく、Constructionで作ったものを本番に届け、期待通りに動作していることを検証し、その先の改善につなげるフェーズです。
Series: AI-DLC Workflow V2の解説 (31 articles)
- …
- 12AI-DLC Workflow V2のOperation Phase: コードの先にある"動かし続ける"設計 This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article