【AWS Summit Japan 2026】AI-DLCについての話をセッション横断でまとめてみました

CR2課の前田です。 2026年6月24日～25日にかけてAWS Summit Japan 2026が開催されました。
今年はAI駆動開発ライフサイクル（AI-DLC）関連のセッションを中心に視聴していたのですが、各セッションの話につながりがあるように見受けられました。

今後、AI-DLCのことを私のお客様にも説明できるようにするため、自分自身の理解のためにもセッション横断で一つの話の流れにまとめてみました。

前提
- おことわり
- 今回視聴したセッション
AI時代における課題
AI-DLCの登場
9つの教訓
「スキル侵食の悪循環」と「オーナーシップの欠如」についての深掘り
AI-DLCを成功させるための要素
AI-DLC活用事例
感想

前提

おことわり

本記事では各セッションで出たAI-DLC関連の話を一つの話の流れにマッピングすることを目的としています。
そのため各セッションの話が混ざっています。また私個人の感覚（印象に残ったこと、残らなかったこと）も入っているため内容に濃淡があります。
詳細な説明については各セッションの資料にぜひ目を通してみてください。

今回視聴したセッション

AWS Summit2026において、AI-DLC関連では下記のセッションを視聴していました。資料ダウンロードはこちらから、録画視聴はこちらから可能です。
各資料のリンクは脚注に記載しています。

AI 駆動開発ライフサイクル (AI-DLC) のご紹介 [AIM221]
AI 駆動は上流工程にこそ活きる－非エンジニアにこそ知ってほしい、AI 駆動開発ライフサイクルによる上流工程の変革 [AIM222]
AI でコードは書けても、レビューできる人がいなくなる ― ソフトウェア開発における自動化のパラドックス [AIM223]
AI が開発／運用しやすいクラウドサーバーレスの視点から考える設計原則 [CNS449]
Kiro と Amazon の文化から学ぶ AI 駆動開発の型 [DVT324]
Operation Phase of AI-DLC － AI 駆動カオスエンジニアリングのすすめ [DVT452]
ランサム危機を転機にーアスクルが加速させた AI-DLC [AIM146]

次の章からまとめを記載していきます。

AI時代における課題

AI をソフトウェア開発に導⼊しても得られる速度向上は10~15 %程度にとどまっている。*1
現在のAIを用いる開発では下記2パターンに属するが、複雑で大規模なPJでは品質やスピードに課題が発生することが多い状況。

パターン	説明	課題
AI-Managed（AI 自律型開発）	ユーザーの要件に基づいて人間の介入なしに AI がアプリケーション全体を生成することを期待するアプローチ	複雑で大規模なコードでは要件反映などが疎かになり品質が犠牲になる
AI-Assisted（AI 支援型開発）	ドキュメント作成、コード補完、テストなどの特定のタスクを AI が強化するアプローチ	人間の担当部分がボトルネックになり速度が犠牲になる

AI-DLCの登場

上記の課題を解決するためにAWSは「AI駆動開発ライフサイクル（AI-DLC）」を生み出した。*2
従来の開発手法（ウォーターフォール・アジャイル）にAIを後付けするのではなく、AIを中心に据えた開発手法*3。

ざっくり言うと「AIが実行し、人間がレビューすることを繰り返す」手法
下記の3段階で実行する。各ステップの成果物が次のステップのコンテキストになる
- INCEPTION
- CONSTRUCTION
- OPERATION

※より具体的な説明はホワイトペーパーに記載されていますが、弊社で左記を分かりやすく解説しているブログもあるので是非ご覧ください。

INCEPTION

■概要*4

既存システムを対象とする場合は既存コードのコンテキストを構築する
ユーザーストーリーで意図を明確化する
要件・ストーリーが固まったら次のフェーズに向けての作業単位を分割する

ここで重要なのは、上記を「モブワーク」によって行うこと。*5

AIにより実装スピードが上がっても、人間がボトルネックとなる部分（ステークホルダーによる要件の合意、レビューなど）があると開発速度はあまり変わらない。
そこでステークホルダー（プロダクトマネージャー、開発者、運用チーム、QAなど）全員を同じ部屋に集め、AIへの指示・結果レビュー・意思決定を同期的に行う。

全員でレビューするためビジネス意図が洗練され、判断を下す人もその場にいるため意思決定も迅速になる。（INCEPTIONフェーズで実施するモブワークはモブエラボレーションと呼称。）

CONSTRUCTION

■概要 *6

INCEPTIONフェーズで定義された作業単位に従って、3～5名ほどの役割の異なる人々で構成されたチームごとにモブワークを行う（※モブコンストラクションと呼称）
INCEPTIONフェーズで作成されたコンテキストをもとにAIに詳細設計、実装、テストの提案をしてもらい、人間がレビュー・意思決定を実施する。

モブワークを実践する上でいくつかコツがある。*7

1回2～4時間
大きな共有画面があること
リラックスできる環境であること
- ※AIの速度に人間が合わせなければならないため疲れる。合宿形式でできるとなお良い。
ラピッドプロトタイピング（その場でAIにデモを作らせる）を実施してその場で認識合わせをする

OPERATION

■概要*8

AIがテレメトリデータ（メトリクスやログ）を能動的に分析して問題の予測を行う
AIがランブック（手順書）と連携し、リソースのスケーリングなどの実行可能アクションを提案する
開発者は検証役としてAIの分析や提案を確認/検証。実行を承認する

このフェーズについては2点、留意点がある。

1. 運用のことはINCEPTIONフェーズから考えておくこと

非機能要件に運用が含まれたり、監視ツールによって実装内容も変わるため。*9
（モブエラボレーションの参加者に運用チームがいるのもそのため。）

2. OPERATIONフェーズに書かれていることは段階的に導入する

ホワイトペーパーに書かれていることは下記のように「非常に高度な成熟された運用があること」を前提としており、運用したてのシステムでは難しい。*10

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

AIを使って「非常に高度な成熟された運用があること」という前提を満たそうとしても、地道な改善なくして高度化は実現し難いため、下記の3段階でAIによる運用を進められるとよい。*11

1.AI-DLCで開発したものだとしても、まずは既存の運用に載せてみる
- 現在運用できている = （大なり小なり課題はあるが）上手く回っているということなので、まずはその仕組みに載せる。
2.今できていないことをAIで改善する
- 例：手順書をAIに書かせてみる、セキュリティテストの自動化…など
3.AIを活用した運用（AIOps）を実践していく
- 例：ランブックと連携しAIがアクションを提案、自律的に動くAIによる自動解決…など

9つの教訓

AWSが過去数年間、AI-DLCを実践していく中で得た教訓が9つあった。*12

1.コンテキストウィンドウの慎重な管理
2.既存システムでもうまくいく
3.既存コード例を模倣させる
4.強い意味を持つトークンを使う
5.パッチ修正より書き直しの方が速いのか
6.AIをシニアエンジニアと同じように信頼しない
7.実験への姿勢
8.AIとの協働を学ぶには実践経験が大切
9.最終的なコードの所有者はあなた

※以降に記述する9つの教訓は基本的に上記脚注の資料に記載されていますが、
他のセッションでも関連する話が出てきたため追記しているところがあります。
該当部分には個別に脚注を記載しています。

1.コンテキストウィンドウの慎重な管理

読み込ませるコンテキスト量が多いとAIに下記の悪影響が発生。
- コンテキストロット…AIの精度劣化
- Lost in the Middle…AIの中でコンテキストの中間情報が失われる現象
AWS内部のアンケートにおいては40万トークン前後で実感したとのこと*13
ソースコードだけでなく下記もコンテキストウィンドウを圧迫する*14
- コードベースの調査において読み込んだファイル
- Lint, Build, Test, Deploy の実行ログ
- 実装したソフトウェアの起動・実行・操作ログ
- MCPサーバーから提供されるツールの結果（ウェブ検索など）

対策としては下記がある

ステアリングファイルなど、AIに恒常的に渡しているプロンプトは定期的に見直しを実施してノイズになり得る箇所を見直す
あるセッションで調査した内容を圧縮して別セッションで渡す*15
- ※最近は自動的に圧縮してくれる機能も出始めているが、人間の意図を明示的に伝えるなら手動圧縮が有効
コンテキストの圧縮を、ドキュメントだけでなくアーキテクチャでも意識し、AIが開発・運用しやすい環境を実現する*16
- ノイズの蓄積により精度が落ちる前提を受け入れて設計する*17
- サービス間の境界をインターフェースだけを読めばわかる状態を設計する*18
  - AIにとっては全てのコンテキストを1つのリポジトリに集約すると実装しやすいが、読み込むコンテキストも増えてしまう。インターフェースを実装して機能は隠蔽し、細部を見なくても理解できる構造を作る。
    - 例えばUnix File I/Oは、裏のカーネルをいじったりする処理は公開しておらず簡単な呼び出しで使える。このようなインターフェースが理想。
- Package や Lambda を実用的で AI が管理可能な粒度で分割する*19
  - Lambda-lith（コードを集約した1つのLambda） or Micro lambda（機能ごとにコードを分割した複数のLambda）の2択ではなく、Pragmatic Lambda（境界付けられたコンテキストで分割したLambda）を用いる。
- 運用エージェントの目線でログ・メトリクスのサービス境界を設計する*20
  - 運用に必要なログなどのコンテキストを、精度劣化を行さないボリュームでAIエージェントが読み込める環境にする
  - 例えば下記の情報を含むログが運用AIエージェントにとって読みやすいログ
    - サービス境界（例：マイクロサービス中のサービス名）
    - トレーサビリティ（例：Lambda関数名）
    - ビジネスロジックのコンテキスト（例：ユーザーID）
    - エラー情報（例：S3で権限拒否…などの具体的なエラー情報）
    - メタデータ（例：エラーメッセージの吐かれたSQSメッセージID、リトライ回数）

2.既存システムでもうまくいく

大規模なコードをそのまま入力するのではなく、クラス・関数・コンポーネントの役割などコードの意味を要約したコンテキストを読み込ませることで、AI-DLCは既存システムにおいても有効に働く

3.既存コード例を模倣させる

人間の指示は曖昧。AIは様々な仮定を置いて望まない方向に進むことがある。
事細かに指示を出すよりも参考にすべきコードを渡すことが大事
- 例：「このリファレンスのコードベースを踏襲して」「このプロジェクトに認証、ロギング、エラーハンドリングを実装して」

4.強い意味を持つトークンを使う

意味をダイレクトに伝えてコンテキストの増加を防ぐ。
- 良い例：「ビルダーバターンを使ってリファクタリングして」
- 悪い例：「コンストラクタで一気にオブジェクトを作らずに別クラスを挟んでセッターをたくさん生やしてそれぞれが自身を返すようにして、最後にビルドメソッドを読んだら完成品が返るようにリファクタリングして」
AIには広く知られた強い意味を持つ概念が通じやすいので、本を読んで見識を深めることも大事。*21

5.パッチ修正より書き直しの方が速いのか

AI登場以前はアプリケーションの書き直しは数年がかりの問題で、パッチを当て続けるのが現実的な解だった。
AI登場によってアプリケーションの書き直しも現実的な選択肢になった。
- ※書き直しに必要な知識（ソフトウェア開発スキル）は必須。
（登壇者様は）技術的負債に対して修復するよりも0から構築した方がずっと早い…という事例を実際に見てきた。

6.AIをシニアエンジニアと同じように信頼しない

勝手に暗黙的な仮定を置いてハルシネーションを起こすことがあるため信頼しない。
AIは問い詰められて多角的に考え始めると、全てを鵜呑みにしていた時よりもずっとよく働くようになる
人間がAIを妄信すると「スキル侵食の悪循環」が発生する*22
- AIの出力に満足する → 思考停止する → 評価能力が低下する→さらにAIの出力に依存する…という悪循環。システムが正常に動く限りこの問題は露呈しないため、すぐ気が付くことが出来ない。

7.実験への姿勢

まずやってみて、素早く失敗して、失敗から学ぶ
- アスクル様は、小さな事例で複数回、AI-DLCを実践してから本命のシステム改修にAI-DLCで挑んでいた*23
実験を設計し、評価メトリクスを設計し、飛び込んでみることが重要

8.AIとの協働を学ぶには実践経験が大切

机上の学習だけではなく手を動かそう*24
- AI Driven Development Life Cycle (AIDLC) Workshop
  - AI-DLCを用いて実際にアプリケーションを構築するワークショップ
- aidlc-workflows
  - AIエージェントでAI DLCのワークフローを実行するためのルールとステアリングファイルが含まれている
  - プロンプトやステアリングファイル = AI-DLCではない。人と人、AIと人のコラボレーションを補助するためのツールだという認識を忘れずに

9.最終的なコードの所有者はあなた

AIが実装したとしても説明責任はあなたにある（オーナーシップ）
コントロール・深い知識・自己投入の3経路が断たれるとオーナーシップの欠如が発生する*25

名称	説明	「経路が断たれる」の例
コントロール	自分がコントロールしている感覚	そのコードを書いたのはAIです
深い知識	端から端まで知っている感覚	コードの設計妥当性は未確認です
自己投入	時間・思考・労力がしみこんでいる感覚	AIが10分で出しただけです

「スキル侵食の悪循環」と「オーナーシップの欠如」についての深掘り

教訓6で追記した「スキル侵食の悪循環」と教訓9で追記した「オーナーシップの欠如」は表裏一体の話となっている
考える工程がAIにより消える → スキル侵食が発生 → 更にAIに依存する → コントロール/深い知識/自己投入が満たされない → オーナーシップ欠如…と連鎖する

*26

対応案1：作った人が、運用まで責任を持つ

顧客の反応が直接届く構造はエンジニアの学習速度を加速させる。良い判断は良い結果として、悪い判断は悪い結果として返ってくる。
下流（運用）の痛みが必ず上流（要件定義、設計、開発）の自分に跳ね返ってくる構造なので、上流で手を抜けない。

*27

対応案2：意図的な非効率で育て、AI-DLCで実践する

意図的な非効率とは

効率化からあえて外す（AI頼りではなく自力でやらせる）工程を残すことでスキル育成をするための工夫。*28
AIの利用禁止ではなく、「どの作業が人間の領域なのか」を設計してAIを使い続けていくための仕掛け。具体的には下記の3つで構成される。

オーナーシップを形成するコントロール・深い知識・自己投入の育成領域を確保する
- この領域を組織として設計する。
個人の経験値に合わせた段階的なAI活用設計
- ジュニア：AI制限で考える力を育てる
- ミドル：AIを活用しつつレビューは自力で行う。評価能力を維持する
- シニア：AI活用を最大化しつつ、余剰時間でジュニア育成をする
安全な失敗経験の設計
- あえてAIなしで取り組み、失敗できる環境を用意してあげる

■「意図的な非効率」の事例

いえらぶGROUP様で執行役員がジュニアエンジニアにAI禁止令を出した事例。段階的にAI利用を解禁し、ジュニアエンジニアの基礎体力（設計判断・調べる力）が強化された話

AIを禁止して気づいたエンジニアの基礎体力 …ジュニアエンジニア視点の記事
新人AI禁止令と、その結果の答え合わせ …執行役員視点の記事

AI-DLCで実践し、対策すべき領域を明らかにする

INCEPTIONフェーズで要件・優先順位を先に確定してから実装するので判断の先送りが出来ず主体が明示される
エグゼクティブ、PdM、デザイナー、開発者などあらゆるステークホルダーが参加するので、誰が責任を引き受けるかが全員に見える
AIがあらゆる工程を支援するので人間は「判断・議論・育成」に時間を振り向けられる
これで見えた弱点（責任者不在、レビュー出来る人がいない）を「意図的な非効率」で対策していく

*29

すぐに始められる具体的な方法

STEP1：言語化
- 下記の2問を組織やチームで言葉にして書き出す
  - なぜAIを使うのか
  - 誰がどの成果物に責任を持つのか
STEP2：設計
- AIをあえて使わない「意図的な非効率」を注入する領域を決め、1つで良いので手順に記入する
  - 例：育成・レビュー・オーナーシップ設計など
STEP3：運用&実践
- 下記2つを並行で回す
  - 運用：AIを活用することによって、活用前後で何が速くなって何が遅くなったのかを時間的・工数的に記録する
  - 実践：AI-DLCで判断と責任の所在を露にする

*30

対応案3：Design for Evaluationを通じて叡智を内在化する

Design for Evaluationとは？

該当セッション内で定義された、AIにタスクを引き渡す前に「評価可能か？」を問う所作を反復することによって、「熟練のエンジニアの思考や動きに含まれる叡智」を個人に内在化させるための型のこと。*31
身につけるためには下記を意識する。

守破離の概念を守る。
- まずはAIにタスクを渡す前に「評価可能か？」と問うところから。
- 学習途中で型の要素を分解したり、中途半端に言語化を試みたりするとその叡智が獲得できなくなる。
重要なのはツールや技術そのものではなく、それを通してエンジニア自身が叡智を獲得することが前提
評価可能にするためには「評価基準」「評価手段」「観測対象」の3要素を揃えること。

※【私見】「問う」というのはAIに問うのではなく、自分自身に問いかけるという意味での使われ方かと思います。

外在化された叡智と内在化された叡智

外在化された叡智
- 「アーキテクチャパターン」や「ライブラリ」など、誰が使っても同じ結果になる
- 状況がパターンとマッチしないとうまくいかない
内在化された叡智
- 「Design for Evaluation」「DevOps」など、主体を通して自ずと現れる。使う人や状況によって異なる結果になる。
- 未知の状況にも対応できる。
- 進化の早いAI駆動開発ではこれが有効に働く。

*32

※【私見】この叡智の話については漫画「鬼滅の刃」の作者が語っていた
「剣士のレベルにはできる、使いこなす、極めるの3段階ある」という話のうち「極める」ことを指すのかなと思いました。

できることと、使いこなすことと、極めることはそれぞれ違います。
繰り返し練習して決まった動作が“できる”ようになったら、それをどんな体勢や状況でも適材適所に出せるようになるのが“使いこなす”ことです。
さらに、その使いこなしている技を、他の誰よりも速く強く、常に最大限の力で出せるよう練り上げることが“極める”ことです。

例：Kiroの仕様駆動開発におけるDesign for Evaluation

■Requirements（要求定義）作成フェーズ

2つの側面から評価可能性を検討。下記の問いと、それらをどう評価するか考える。

「ビジネスの言葉でふるまいを評価できるか？」（ステークホルダーとの合意形成）
- 評価基準…ドメインエキスパートの知見
- 評価手段…文書の読み合わせ（+ビジネスの人たちが理解できるように図やデモで補足、ビジネスの言葉を使う）
- 観測対象…requirement.md
「AIが自律的にふるまいを評価できるか？」（AIとの合意形成）
- 評価基準…要求定義の受入基準
- 評価手段…ブラウザテストツール
- 観測対象…開発環境のソフトウェア

■Design（ソフトウェア仕様書）作成フェーズ

Requirementsフェーズと同じく2つの側面から評価可能性を検討。下記の問いと、それらをどう評価するか考える。

「ソフトウェアの内部構造や特性を評価できるか？」（チームメンバーや自分自身との合意形成）
- 評価基準…シニアエンジニアの知見
- 評価手段…文書や図のレビュー
- 観測対象…design.md
「AIが自律的に構造や特性を評価できるか？」（AIとの合意形成）
- 評価基準…構造の制約やテストの要件
- 評価手段…Linterやツール、自動テスト
- 観測対象…ソースコード

*33

※【私見】前述の「意図的な非効率」から更に踏み込んだ話のように思えました。
AIに思考停止で丸投げするのではなく、「何をもって正しいとするのか」を調べ、考えることでその過程で得た知識が「スキル」となり、得た経験が「自己投入」となり、スキル侵食とオーナーシップ欠如を防ぐのかと思いました。

AI-DLCを成功させるための要素

アスクル様が実体験から得たAI-DLCを成功させるための4つの要素は下記。*34

1.目的目標を共有し覚悟を決める
- 「何のために何をしようとするのか」を決める。これが定まっていないと周りが動けず、権限移譲もできない。
- 本丸（改善したい仕組み）を改善するならのであれば、本丸を捨てるぐらいの「覚悟」を持つ
2.全関係者を巻き込む
- ビジネス側とエンジニア側が一体化して動くことが手戻りもなくなるため大事。
- 重要案件ほどエースを投入することで、会社の本気度が周りに伝わる。
3.現場に権限と責任を委譲する
- 具体的なビジョンが共有されている限りにおいては現場に権限を委譲していく。
- スピード向上に加えて現場で動く人々が成長する
4.AI活用に十分な環境を整備する
- エンジニアが安心して働けるよう投資を惜しまない

※「4.AI活用に十分な環境を整備する」については他のセッションに関連する話があったため下記に記載*35

AIと人間のどちらにも使いやすいコンテキスト基盤を整備する
- 横断性
  - 組織・職種の壁を越えてプロダクトに関する情報の全てにアクセスできること
- AIとの親和性
  - AIが自律的に情報を探しノイズが少ない形式で情報を取得できること
コンテキストスイッチの削減
- 意思決定者は1つの作業に集中して取り組む時間を設ける
- 並行してのタスク処理だと集中力低下によるミスや処理速度低下が発生 = ボトルネックになってしまう

AI-DLC活用事例

アスクル様

2025年10月に一部オンプレと一部SaaSがランサムウェアに侵害され、ゼロベースでの再構築を余儀なくされたことを転機と捉え、AI-DLCを取り入れた。
復旧作業と並行して、まずはメルマガや広告など、小規模な箇所の改善をAI-DLC（ミニ合宿あり）で実施。
小さな成功体験を積んだ後、長年の「商品の品ぞろえを高速化する」という課題にAI-DLCで挑戦
- 商品担当が複数ツールを利用して各関係者と調整の上、商品を手配する…という属人化された複雑な業務がボトルネックとなっていた
- 商品担当が使用するツールを一元化し、各関係者のデータも集約する…というシステムをフルスクラッチで製造した。
- 結果
  - 開発期間…従来の開発手法で予定していた「12カ月」から「6カ月」に短縮できた
  - 商品掲載スピード…従来の業務から2倍に向上
  - 副次効果として、モブワークを通してエンジニア側のビジネスの理解が進んだ。

*36

Wipro様

医療保険者向けエンタープライズヘルスケアプラットフォームの開発において、3つの分散したチームによる数カ月分の作業を想定していた
合計20時間（4時間 × 5日）で本番リリース可能な状態まで開発完了した

*37

dhan様

完全新規のアプリケーションを、2カ月要するところを48時間でリリースできた

*38

サイバーエージェント様

広告関連のアプリ改修において下記の状態からスタート
- 開発者が40%削減された体制下
- ビジネス要求の言語化が難しいなど、開発の属人性が高い
- AI駆動開発の経験のあるメンバーはいない
AI-DLCを実践することで下記のような結果が出た
- モブエラボレーションを取り入れることで、メンバー間におけるビジネス/技術コンテキストをAIとともに具体化。開発属人性を排除できた。
- 開発速度が80%以上向上した

*39

Mixi様

「みてね」という実在のアプリにおいて改修が必要になった。
ユーザーストーリー作成から実装に至るまでをAWS協力のもとAI-DLCで進め、その過程でビジネスサイド・技術サイド含めたモブワークを実施。
開発速度は当初の見積の2～3倍になった。

*40

モノタロウ様

要件定義や設計など上流工程ではAI活用されていない状態だった。
AWS協力のもとAI-DLC体験会を開催。
3日間でプロトタイプの開発を実施。60～70%の開発速度向上を実感。

*41

感想

最も印象に残ったセッションは「AI でコードは書けても、レビューできる人がいなくなる ― ソフトウェア開発における自動化のパラドックス」でした。
「コントロール・深い知識・自己投入がなくなるとオーナーシップが欠如する」という言葉が非常に刺さりました。
最近Kiroを使って便利な社内ツールが出来たり、作業が短時間で終わったりするのですが、「自分で作り上げた」という感じはなく、（勿論レビューはしているし責任も持つのですが）「心血注ぎ込んだ」という自己投入感が薄れてしまっていたのは事実だったためです。

また「意図的な非効率を設ける」と言う話も非常に刺さりまして、「苦労しないと何事も覚えないよな～」と常日頃から感じていたこともありすんなり腹落ちしました。
（実はこの記事は、しっかり自分の中に取り込みたいこともあり、意図的な非効率を意識して、久しぶりにAIに頼らず書いています。）

特に理解が難しかったのは「Kiro と Amazon の文化から学ぶ AI 駆動開発の型」でした。
抽象的な話でしたので、リアルタイム視聴時は「型って何？叡智って何？」と終始分からず、最終的に自分の中では「意図的な非効率」の更に踏み込んだ具体的手法かと解釈したのですが、社内のエンジニアにも解釈を聞いてみたいです。

お目通しいただいた方、ありがとうございました。

*1:AI 駆動開発ライフサイクル (AI-DLC) のご紹介 P7～P13

*2:AI 駆動開発ライフサイクル (AI-DLC) のご紹介 P16～P19

*3:AI 駆動開発ライフサイクル:ソフトウェアエンジニアリングの再構築

*4:AI 駆動開発ライフサイクル (AI-DLC) のご紹介 P18～P19

*5:AI 駆動開発ライフサイクル (AI-DLC) のご紹介 P20~P22 + セッション中の発言

*6:AI 駆動開発ライフサイクル (AI-DLC) のご紹介 P18～P19 + セッション中の発言

*7:AI 駆動は上流工程にこそ活きる－非エンジニアにこそ知ってほしい、AI 駆動開発ライフサイクルによる上流工程の変革 P30、P32

*8:Operation Phase of AI-DLC － AI 駆動カオスエンジニアリングのすすめ－ P16～P20

*9:Operation Phase of AI-DLC － AI 駆動カオスエンジニアリングのすすめ－ P16～P23

*10:Operation Phase of AI-DLC － AI 駆動カオスエンジニアリングのすすめ－ P39

*11:Operation Phase of AI-DLC － AI 駆動カオスエンジニアリングのすすめ－ P40～P43