【AWS Summit Japan 2026】AI 駆動カオスエンジニアリングのすすめ [DVT452] セッションレポート

はじめに

今月誕生日の人、おめでとうございます🎉 エデュケーショナルサービス課の森純子です。

AWS Summit Japan 2026に行ってきました！会場は凄い盛況で、人・人・人！終始会場全体の熱気がすごく、近年のAWSへの注目度の高さをまじまじと感じました。基調講演やスペシャルセッションのオープニングのDJパフォーマンスもとってもかっこよかったです。

今回の私の参加目的は、AI時代の開発の「今」を現場レベルで知ることでした。ベストプラクティスはドキュメントで読めますが、実際に今どう使われていて、どこまで進んでいるのか。私は運用面ではAIを日常的に活用していましたが、アプリ開発は初心者レベルです。社内のAI開発イベントや勉強会を通じて、AIと一緒にモノを作ること自体は日常になっています。ただ、アプリは作って終わりではなく運用まで含めたライフサイクルで回していくもの。理論としては知っていましたが、実践者の話を聞いて体感として落とし込みたい。その思いから、AI-DLCのセッションに興味を持ちました。

そして実際にセッションを聴いて、「今までは人と人とのコラボレーションを前提とした開発方法論だった。これからは人とAIのコラボレーションだ」という言葉が刺さりました。まさに昨今の私の状況そのものだと思ったからです！

また、印象に残ったのは、「まず既存の運用に乗せて良い。そこからAIで改善を加速する。やることは増えるように見えるが、AIがトライのコストを下げてくれる」というメッセージでした。具体例として、リスクストーミング×カオスエンジニアリングをAI駆動で実践するデモが紹介されました。

本記事では、セッション内容の詳細をレポートします。

対象読者

AI-DLC（AI-Driven Development Lifecycle）を開発に取り入れている、もしくは検討中のエンジニア
AIを活用した運用改善（AIOps）に興味があるエンジニア
カオスエンジニアリングやリスクストーミングに興味はあるが、実践に踏み切れていないエンジニア

本記事で使用する略称

略称	正式名称
AI-DLC	AI-Driven Development Lifecycle
AIOps	AI for IT Operations
V1.0 / V2.0	AI-DLC Workflows Version 1.0 / 2.0
C4ダイアグラム	C4 Model（Context, Containers, Components, Code）によるアーキテクチャ図

セッション概要

項目	内容
タイトル	Operation Phase of AI-DLC − AI 駆動カオスエンジニアリングのすすめ− [DVT452]
登壇者	金森政雄氏（アマゾンウェブサービスジャパン合同会社ソリューションアーキテクト / 日本のAI-DLCリード）
日時	2026年6月26日（金）12:00 - 12:40 JST
会場	AWS Summit Japan 2026（幕張メッセ）
関連キーワード	AI-DLC / カオスエンジニアリング / リスクストーミング / AIOps

本セッションの動画は、すでにオンデマンドで公開されていました。スライドの詳細は動画をご覧ください。

summitjapan.awslivestream.com

AI-DLCの基本: プラン→レビュー→実行→レビュー

AI-DLCの核となる考え方は以下のサイクルです。

人が意図・企画をAIに渡す
AIが計画を作成する
人が計画をレビューする
AIが計画を修正する
人が修正計画をレビュー・承認する
AIが計画を実行する
人が結果をレビューする

常にAIがアウトプットを生成し、人がそれを監督する。この「プラン→レビュー→実行→レビュー」のリズムが、AI-DLCの全フェーズに共通する基本原則です。

もう一つの重要な柱は「ダイナミックなチームコラボレーション」です。

従来は要件定義→作業待ち→開発→作業待ち→テストと、人の作業を待つボトルネックが多く存在しました。AI-DLCでは、AIが人と同じ速度でアウトプットを生成するため、BizとDevがモブワークで常に一緒に問題解決や創造的な意思決定に集中できます。本当に加速されるのは「人と人の共通認識を作るコラボレーション」であり、AIはそのアウトプットを高速に形にする役割を担います。

AI-DLC Workflows: V1.0からV2.0へ

AI-DLC Workflowsは2025年8月にGitHubで公開されたOSSで、以下の実績があります。

適応的なワークフロー
主要なコーディングエージェントをサポート
世界中の300以上のお客様が検証済み
平均2倍〜5倍のリリース速度を実現

V1.0は「最大公約数的」な設計でした。ツール非依存で幅広く使える反面、特定のコーディングエージェント（Claude Code、Kiro等）の固有機能を活かしきれず、組織ごとの運用の多様性に対応しきれないという課題がありました。

V2.0（プレビュー中）では3つの学びを反映して進化しています。

構成の粒度を細かくする: ステージを「スキル」単位で構成
AIに「正しさの基準」を与える: 検証仕様を明示的に定義（プロンプト＋テストスクリプト）
エージェントのネイティブ機能を活かす: ツール固有の最適化を実現

これにより、拡張可能でコンポーザブルなステージライブラリを持ち、Claude CodeやKiro固有のエージェントワークフローとしてパッケージ化できるようになります。

Operationフェーズの現実: 地道な積み重ねをAIが加速する

AI-DLCのOperationフェーズは、ホワイトペーパーで以下のように定義されています。

AIがテレメトリデータを能動的に分析し、問題を予測する
事前定義されたランブックと連携し、実行可能なアクションを提案する
開発者が検証役として、AIの提案をSLAおよびコンプライアンス要件に適合するか確認する

これも「プラン→レビュー→実行→レビュー」と同じ流れです。

ただし、このストーリーには5つの前提条件があります。

AIが問題を検知できるようにするためのオブザーバビリティ
既知の課題に対処する整備されたランブック
AIの提案を判断できるシステムへの自信
AIにオペレーションを任せるためのガードレール
AIの操作単位となる適切な自動化

金森氏は「AIはこれまでの活動の延長線」だと強調しました。十分な自動化、ガードレール、人の関与を最小限にした仕組みを持つ組織ほどAIを活かせます。いきなり運用の成熟度をワープさせることはできませんが、AIで改善の取り組みを「加速する」ことはできます。地道にやってきたことが、AIによって一気に花開くイメージです。

Operationフェーズの始め方: 3段階アプローチ

既存の運用に乗せる: 利用中のCI/CDの仕組み、契約済みのオブザーバビリティツール/サービスをそのまま使う
今できていないことをAIで改善する: セキュリティテストの自動化（SAST/SCA/DAST等）、ランブックの整理など
AIを活用した運用（AIOps）: ランブックと連携しAIがアクションを提案、自律的に動くAIによる自動解決

リスクストーミング × カオスエンジニアリング: AI駆動の実践例

Operationフェーズの改善アプローチとして、Simon Brown提唱の「リスクストーミング」とカオスエンジニアリングの組み合わせが紹介されました。

リスクストーミングとは

アーキテクチャ図上でリスクを可視化し、優先度をつけて改善する手法です。

手順:

コンポーネント抽出: IaC/設計図からコンポーネントを特定
リスク特定: 6カテゴリ（スケーラビリティ、可用性、パフォーマンス、セキュリティ、データ完全性、回復性）でリスクを洗い出す
優先度評価: 影響度×発生確率でスコアリング
改善計画: Chaos実験やアーキテクチャ改善

リスクストーミングが見つけるのは「知識の共有と構造化された発散」です。サイレントフェーズ（個人作業）により、普段声を出しにくいジュニアエンジニアの視点も取り込めます。

カオスエンジニアリングとは

「本番環境を壊すこと」ではなく、「対象のシステムが本番環境での不安定な状況を耐えることができる」という自信を構築するために実施する実験の規律です（Principles of Chaos Engineering）。

手順:

定常状態を定義する
実験中も定常状態が継続する仮説を立てる
現実に起こりうる障害をシミュレートし実験する
実験結果を検証する
改善する

カオスエンジニアリングの目的は「未知」を見つけることです。テストが扱う「Known Knowns」（想定済みの障害×想定済みの影響）に対し、カオスエンジニアリングは「Known Unknowns」（想定済みの障害×未知の影響）や「Unknown Unknowns」（未知の障害×未知の影響）を探索します。

なぜこの組み合わせが有効か

リスクストーミングでリスクを洗い出し（プラン）、カオスエンジニアリングで実験・検証（実行→レビュー）。AI-DLCの基本フローと一致する
従来はアーキテクチャ図の準備、ステークホルダーの日程調整、ファシリテーション等が大変だったが、AIによる自動生成とAI-DLCのモブワーク前提で大幅に簡素化できる
AI生成物に対する「自動化バイアス」（自動的に生成されたものを無条件に信じてしまう心理傾向）への対策にもなる。構造化された発散（リスクストーミング）と安全な実験（カオスエンジニアリング）で「未知」を「既知」にする

デモ: Kiroを使ったAI駆動カオスエンジニアリング

金森氏はKiroを使って、以下の5ステップをライブデモしました。

デモ対象: 「Unicorn Market」（ユニコーンの貸し借りをするWebサイト、AI-DLCで開発されたマイクロサービス）

既存のシステムを分析して、アーキテクチャ図を作成: AIがコードを分析し、C4ダイアグラムを自動生成
リスクストーミング: AI主導でリスクを洗い出す: 6つのリスクカテゴリで分析、マトリクスとアーキテクチャ図にリスクを反映
カオスエンジニアリング: 実験の実行計画を作成: 定常状態の仮説と実験ストーリーをAIが生成、人がレビュー
カオスエンジニアリング: 実験を実施: 安全なロールバック機構を含むスクリプトをAIが自動生成し実行
改善案を確認、実施: 実験結果（仮説不成立: タイムアウト未考慮）をもとに改善案をAIが提案

デモでは実際に仮説が不成立となり、レンタル処理のペンディング時にタイムアウトが適切に設定されていない問題が発見されました。

まとめ

AI-DLCのOperationフェーズは、他のフェーズと同じく「Human in the loop」モデルで運用を効率化する
Operationフェーズの始め方は3段階: 既存運用に乗せる → AIで改善を加速 → AIOps
リスクストーミング×カオスエンジニアリングは、AI-DLCの「プラン→レビュー→実行→レビュー」と自然に組み合わせられる具体例
重要なのは、自分の持つ専門知識やプラクティスを、AIを使って加速させること。エンジニアの知識と経験はこれからもっと重要になる

所感

今まで私はAIを運用業務（監視、障害対応の効率化など）で主に活用していましたが、今回のセッションで「人と人のコラボレーションを前提とした開発方法論」から「AIと人が協働する方法論」への転換という視点に強く共感しました。

社内でもClaudeや生成AI縛りなしでのアプリ開発イベントを何度も実施していて、AIでモノを作る体験が広がっています。一般ユーザーのスマホにChatGPTが当たり前に入っている今、AIとの協働はもう日常です。その先にある「AIと一緒にどこまで行けるか」を追求していきたい。この世界が来るかもと思った映画「The Fifth Element（フィフス・エレメント）」、もはや遠い未来の話ではないかもと思ってます。

金森氏の「エンジニアの知識・経験はこれからもっと重要に。Tryのコストは下がっているので積極的に挑戦を！！」というメッセージは、まさに実感として腹落ちしました。私も、自分の領域とAIを掛け算して、どんどん試していこうと思いました。みなさんも、ご一緒にいかがでしょうか？