[AWS Summit Japan 2026] Operation Phase of AI-DLC － AI 駆動カオスエンジニアリングのすすめセッションレポート

こんにちは、サーバーワークスで生成AIの活用推進を担当している針生です。

AI-DLC（AI-Driven Development Life Cycle）は、Inception・Construction・Operation の3フェーズで構成されています。このうち Operation フェーズは、公開されている AI-DLC Workflows v1.0 ではプレースホルダーと書かれているだけで、具体的な中身がありませんでした。

そんな Operation フェーズの進め方が、AWS Summit Japan 2026 のセッション「Operation Phase of AI-DLC － AI 駆動カオスエンジニアリングのすすめ－ [DVT452]」で語られていました。この記事では、その内容をレポートとしてまとめます。

Operation フェーズとは何か

AI-DLC Workflows v1.0 では、Operation フェーズはプレースホルダーとだけ書かれ、中身は今後の拡張に委ねられていました。

一方、AI-DLC のホワイトペーパーには、Operation フェーズが目指すものが書かれています。要約すると次のとおりです。

システムのデプロイ・オブザーバビリティ・メンテナンスを中心に、AI で運用効率を高める
AI がテレメトリ（メトリクス・ログ・トレース）を能動的に分析し、異常の特定や SLA 違反の予測を行う
AI がランブックと連携して推奨アクションを提案・実行し、人間が検証・承認する

AI-DLC の各フェーズは「プラン ⇒ レビュー ⇒ 実行 ⇒ レビュー」という共通のループ（Human in the loop）で進みます。上の記述もこのループに対応しており、Operation フェーズも進め方の骨格は他フェーズと同じです。

ただし運用は、CI/CD・障害対応・DR・可用性・セキュリティ・コスト（FinOps）など守備範囲が広く、一律に定義しづらい領域です。また、運用は開発が終わってから始まるものではなく、ベースラインの要求や改善点を Inception / Construction にフィードバックする役割も持ちます。

Operation フェーズの始め方

セッションでは、3段階で始めることが示されていました。

既存の運用に乗せる（利用中の CI/CD やオブザーバビリティツールにまず乗せる）
今できていないことを AI で改善する（セキュリティテストの自動化、ランブックの整理など）
AI を活用した運用（AIOps）へ（AI がアクションを提案し、自律的に解決する）

ここで印象的だったのが「AI はワープではなく加速」という考え方です。運用の成熟度は取り組みの積み重ねで上がっていくもので、AI で一気に高い段階へ飛び越えることはできません。オブザーバビリティ・ランブック・ガードレール・自動化といった土台を整えたうえで、その改善を AI で加速する、というのが現実的な道筋です。

リスクストーミング × カオスエンジニアリング

セッションのハイライトが、副題にもなっている「AI 駆動カオスエンジニアリング」です。実際の運用に入る前に「運用への自信」を作るために、リスクストーミング（計画）とカオスエンジニアリング（実験）を組み合わせる、というアプローチが提案されました。

リスクストーミングは、Simon Brown さんが提唱したアーキテクチャリスクの特定手法です。アーキテクチャ図の上でリスクを可視化し、6カテゴリ（スケーラビリティ・可用性・パフォーマンス・セキュリティ・データ完全性・回復性）で洗い出して、影響度 × 発生確率で優先度をつけます。

カオスエンジニアリングは、Principles of Chaos Engineering の定義によれば「システムが本番環境の不安定な状況に耐えられる」という自信を構築するための実験です。ランダムに壊すこと自体が目的ではありません。「想定済みの障害だが、影響がどこまで波及するか分からない（Known Unknowns）」領域を、実験で確かめて明らかにしていきます。