作成日：2026年9月21日(月)

はじめに

AWS Skill Builder で公開されている「AI駆動開発ライフサイクル（AI-DLC）」の日本語版コースを受講しました。所要は約3時間半、全9モジュール（最後はナレッジバッジ）です。

ここに至るまでの経緯を4行だけ書かせてください。読んでいただく上での、私の立ち位置の説明になります。

2025年7月ごろから、AWS Kiro の仕様駆動開発を学習していました。「AI にコードを書かせる前に、仕様をどう固めるか」という問題意識を持ち、その流れで AI-DLC というフレームワークに興味を持ちました。
2026年8月、会社で AWS AI-DLC Unicorn Gym（v1 のワークショップ）を受講し、方法論を手を動かして体験しました。
その後、v2 のワークショップにも申し込んだのですが、満席で抽選に外れました。
そこで独学で概念を固めようと考え、公開されていた日本語版 Skill Builder を受けることにしました。きっかけは Qiita の @news_it_enj（荒木 ARK）さんの記事「AI駆動開発ライフサイクル（AI-DLC）の日本語版Skill Builderが公開されたので体験してみた」です。コースの存在を知るきっかけをいただきました。ありがとうございます。

この記事で扱うこと・扱わないこと

扱うのは「コースを受けて印象に残ったこと」です。網羅的なコース要約ではありません。
コースが教えるのは方法論としての AI-DLC です。GitHub の awslabs/aidlc-workflows（実装）とは粒度が違います。この差は最後のほうで触れます。
私が実際に手を動かしたのは v1 のワークショップと、この Skill Builder までです。v2 の実装は動かしていません。 実装に触れる箇所は調べた内容であり、自分の実測ではないことを都度お断りします。

印象に残ったのは、次の5点でした。

AI-DLC は「AI支援型」と「AI管理型」の中間に置かれている
スプリントではなく**ボルト（Bolt）**という時間単位を使う
モブコンストラクションが儀式として制度化されている
設計の最初の段階で技術要件をあえて指定しない
コース中「Spec Drift」という言葉が一度も出てこない

順に書いていきます。

1. 一番刺さった前提：AI-DLC は「支援型」と「管理型」の間にある

AI支援型とAI管理型のどちらにも傾いた天秤と、その中央で釣り合うAI-DLCを示すイラスト

コースは冒頭（モジュール1）で、組織における AI 活用を2つのモードに整理します。

AI 支援型は、コード補完などの限定されたタスクに AI を使う形です。コースはここで、既存の慣習がベロシティを低下させると指摘します。スプリント計画もスタンドアップもアドホック会議もそのままなので、生成は速くなっても、プロセス全体は人間のペースのまま進みます。

AI 管理型は、人間の関与を最小限に抑えたシングルショットの自律開発です。生成は最速ですが、コードの問題修正に多大な時間を要することが多いと説明されます。

そして、どちらも「変革的なメリットをもたらす上で限界がある」と明言されます。AI-DLC は、この二極の中間に位置づけられます。AI が重い作業を担い、人間が監視とコントロールを持つ、というバランス点です。

この「バランス」を具体化したのが、Plan → Clarify → Refine → Approve → Execute → Verify という継続サイクルです（モジュール1・4）。Approve と Verify が人間側の持ち場になります。

所感

正直に言うと、この二極の図を見せられた時点で「自分の現場は支援型のまま止まっている」と自覚しました。ツールは入れた、補完も使っている、でもプロセスは何も変わっていない。速くならない理由が「AI の性能」ではなく「自分たちの慣習」の側にある、と名指しされた感覚があります。

そしてもうひとつ。「AI に全部やらせる」対「AI を補助輪にする」という、社内でよくある不毛な二択から降りるための語彙をもらえました。中間に立つポジションに名前が付いているだけで、議論がだいぶ進めやすくなります。

2. 印象1：スプリントではなく「ボルト（Bolt）」

コンストラクションフェーズのイテレーションは、スプリントではなくボルト（Bolt） と呼ばれます。定義は、高速で適応的なサイクル。2週間ではなく、数時間から数日で計測されます（モジュール8）。

面白いのは、コースがなぜ新語にしたのかを明示していることです（モジュール3・原則6）。

新しい方法論を導入する際、最大の障壁は学習コストである。だから、すでに知っている概念（スプリント）をベースに残しつつ、AI のスピードに適応させ、その速さを強調するために「ボルト」と呼ぶ。

つまり「基本的な考え方は馴染みのあるものだが、実行は新しい能力に合わせて進化している」という設計思想が、用語レベルで貫かれているわけです。コースはこのパターンが AI-DLC 全体に繰り返し現れる、とも述べています。

所感

名前を変えるのは単なる言い換えではなく、「2週間」という暗黙の前提を捨てさせるための仕掛けだと感じました。

スプリントという器のまま速くしようとすると、結局モジュール2が指摘するミスマッチ、つまり「AI のスピード」と「人間のペースで行われるセレモニー」のズレが残ります。週次のバックログ整理と翌日のスタンドアップを維持したまま、数分でコードが出てくる状況を扱うのは無理があります。器のほうを替える、という主張だと理解しました。

そして、これはリバースエンジニアリング起点で一番効くと思います。既存システムを解析して仕様化し、小さく直す、という流れは「数時間で1周する」ことと相性が良い。逆に新規開発は、そもそも決めるべきことが多いので、ボルトの回転はそう簡単には上がらないはずです。

注意：概念と実装の成熟度は別

ひとつ補足を。ここで学ぶ「ボルト」は方法論上の概念です。

実装側（awslabs/aidlc-workflows v2）を調べたところ、現行ランタイムでは bolt-plan.md は計画文書であって、実行単位としては消費されていません（Planned / non-executable という扱い）。実際の並行実行のまとまりは、別の依存グラフから導かれます。

コースの概念図をそのまま「今すぐ動くもの」だと思って期待値を作ると外します。ここは分けて理解したほうがよさそうです。

3. 印象2：モブコンストラクション

チームが共有画面に並ぶAIの提案カードをその場で採否判断しているモブコンストラクションのイラスト

モブコンストラクションは、コンストラクションフェーズの中核の儀式として定義されています。チーム全員が共有画面で協働し、AI が提案し、人間がリアルタイムで検証する形です（モジュール8）。

インセプションフェーズには対になるモブエラボレーションがあります（モジュール7）。AI が作業の分解案を提示し、プロダクト・開発・QA のメンバーがその場で現実性のチェックを入れる。

コースが挙げる効果は3つです。

アーキテクチャ選択、設計トレードオフ、インフラ選定といった複雑な意思決定は集合知の恩恵が大きい
共有された理解の確保と、コストの高いミスの防止
知識移転の加速

象徴的だと思ったのは、インセプションの成功条件が「インセプション後にチームがすぐに構築を開始できる状態。追加の確認ミーティングは不要」と定義されていることです。会議を減らすために会議をする、という逆説的な構造ですが、意図ははっきりしています。

意思決定を止めないための道具立て

モブが機能するには、その場で決め切れることが前提になります。モジュール4はそのための道具を挙げています。

問題の分解、責任の共有、Have Backbone: Disagree and Commit、70% のデータで意思決定する
One-Way Door（覆すことが困難な決定）と Two-Way Door（容易に覆せる決定）を区別し、前者だけ慎重に扱う
人間が判断すべき5つのポイント（明確化の質問、計画の承認、実行への介入、成果物の品質、イテレーションと完了の判断）

Amazon 由来の意思決定カルチャーが、そのまま AI-DLC の速度を支える前提として組み込まれています。ここを輸入せずに手順だけ真似すると、たぶん詰まります。

所感

これは新規開発起点で最も効くと思いました。ゼロから作るときは「何を作らないか」を含めて合意コストが高く、そこを非同期レビューでやると必ず往復が発生します。同じ画面を見ながらその場で潰すほうが速い。

一方で、率直な懸念もあります。AI-DLC の速度は全員の時間を同時に押さえられるかに依存します。受託や分散チームの現場では、ここが一番難しいのではないでしょうか。

コースもそこは織り込んでいて、モジュール6では、モブセッションを開始する前に技術的な準備・部門横断の共同配置・ドメイン知識の評価を済ませておく、と明記されています。モブは「集まればできる」ものではない、という釘の刺し方だと受け取りました。

4. 印象3：設計の最初に「技術要件を指定しない」

個人的に、このコースで一番の収穫はここでした。

コンストラクションフェーズは5つのステージで構成されます（モジュール8）。

#	ステージ	答える問い
1	機能設計	ビジネスの観点でシステムは何をするか
2	非機能要件設計	システムはどう振る舞うべきか
3	インフラ設計	どのテクノロジーを使うか
4	コード生成	設計を実装に変換する
5	ビルドとテスト	すべてが機能することを検証する

なお、常に5つすべてを実行するわけではなく、AI がタスクの複雑さに応じてステージを動的にスキップします。単純なバグ修正はコード生成に直行する、といった具合です。

核心：機能設計は完全にテクノロジー非依存

コースの表現をそのまま引きます。

重要なのは、これが完全にテクノロジーに依存しないことです。データベースや API についてはまだ考えません。純粋なビジネスロジックだけです。

機能設計でやるのは、テクノロジーに依存しない言語でビジネスエンティティ・ルール・ワークフローをモデル化することだけ。

非機能要件設計でも、まだ製品名は出さない

ここが徹底していると思った点です。非機能要件設計では論理コンポーネントという抽象を使います。

非同期処理が必要 → 「メッセージキュー」という論理コンポーネントが必要だと特定する
高速なデータアクセスが必要 → 「レイテンシ10ミリ秒以下、TTL ベースの有効期限をサポートするキャッシュ」を特定する

この時点では、どのキュー製品を使うかも、どのキャッシュ実装を使うかも言及しません。必要な論理コンポーネントを指定しているだけです。

実際の製品を決めるのはインフラ設計になってから。ここで初めて論理コンポーネントをクラウドサービスへマッピングし、その判断を ADR（アーキテクチャ決定レコード） に残します。

同じ原則はインセプション側にもあります。「適切に構造化された意図は、ビジネス言語で表現され、具体的な機能を説明し、早期の技術的意思決定を避ける」（モジュール7）。

Before / After

普段書いてしまいがちな機能設計と、この規律に沿った書き方を並べてみます。

<!-- Before：技術要件が混ざっている -->
## 注文機能
- 注文を DynamoDB の Orders テーブルに保存する
- 在庫引当は SQS 経由で非同期に処理する
- 注文履歴は ElastiCache でキャッシュして 10ms 以内に返す

<!-- After：機能設計（テクノロジー非依存） -->
## 注文
- エンティティ: 注文、注文明細、在庫引当
- ルール: 在庫が不足している明細を含む注文は受け付けない
- ルール: 注文確定後の明細変更は、確定から 30 分以内に限る
- ワークフロー: 注文受付 → 在庫引当 → 確定 → 出荷指示

<!-- 非機能要件設計（論理コンポーネントまで） -->
- 在庫引当はピーク時に注文受付をブロックしてはならない → 論理コンポーネント「メッセージキュー」
- 注文履歴の参照は 10ms 以内 → 論理コンポーネント「キャッシュ（TTL 対応）」

<!-- インフラ設計で初めて製品を決め、ADR に残す -->

所感

これはプロンプトエンジニアリングの話ではなく、抽象化レベルの規律の話だと理解しました。

人間が最初から「DynamoDB で」と書いてしまうと、AI はその制約の中でしか設計しません。選択肢を潰す時期を意図的に後ろへ倒す、というのが AI-DLC の設計思想です。言われてみれば当たり前ですが、AI に投げる文脈だと「具体的に書いたほうが良い結果が出る」という直感が働きやすく、逆方向に振れがちです。

これは新規開発起点で効く2つ目だと思います。既存システムの改修では技術スタックがすでに決まっているので、この規律の価値は相対的に小さくなります。

実務への翻訳としては、要件定義のレビューで製品名が出てきたら一旦止める、というチェック観点として使えそうです。

5. 印象4：「Spec Drift」という言葉が出てこない

最後は、あったことではなくなかったことの話です。

全9モジュールを通して、「Spec Drift（仕様乖離）」という言葉は一度も出てきませんでした。仕様とコードが少しずつズレていく、あの現象です。AI にコードを書かせる文脈では必ず話題になるはずのテーマなのに、名前が与えられていない。

では扱っていないのか、というと、そうではありませんでした。概念が別の言葉に分散している、という整理が近いと思います。

トレーサビリティ：生成されるコードは要件まで完全に遡れる。すべてのビジネスルールに、すべての API に、すべてのコンポーネントにテストがあり、それらがユーザーストーリーへトレースバックされる（モジュール8）
フェーズ境界の検証ゲートと、ステージごとの承認ゲート
人間の監視が損失関数になる、というモジュール8の表現
レガシー文脈では、「モダナイゼーションの前に、静的構造と動的フローを記述してレガシーシステムをコンテキスト化する」（モジュール5）

所感

言葉がないのは問題を見ていないからではなく、「ドリフトは事後に検出するものではなく、ゲートで発生させないもの」という立て付けだからではないか、というのが私の読みです。検出という語彙で語る限り、前提として「ズレが起きること」を認めてしまう。そうではなく、各ステージの承認とフェーズ境界の検証で、下流が積み上がる前に捕まえる。

ただし、これはコースを受けたうえで自分なりに解釈したものであって、コースがそう明言しているわけではありません。

そして実運用では、結局「どれが正の仕様か」という問題は残ります。実装側（v2）を調べた範囲では、ズレを検出する仕組みは複数の層で用意されている一方、検出した後に仕様側（要件や機能仕様）を自動で追従させる機能はありません。ここは人がやることとして残ります。

6. 方法論としての AI-DLC と、実装としての AI-DLC

最後に、期待値の話をひとつ。

コースが教えるのは、インセプション / コンストラクション / オペレーションという3フェーズの方法論です。一方、awslabs/aidlc-workflows（v2 系）は、フェーズもステージもエージェントも細分化された別の粒度の実装で、リリース頻度も非常に高い状態にあります。

コースは「考え方」を、リポジトリは「今動くもの」を教えます。両方を混ぜて期待値を作ると外します。 前述の「ボルト」がまさにその例でした。

効果の数字についても、少し慎重に見ています。AWS 側が示す倍率はワークショップ演習に由来するものが多く、国内の独立した測定では「劇的な短縮はなかった」という報告も出ています。むしろ確度が高そうな効果は、速度そのものではなく 「実装前に仕様の矛盾が見つかる」 ことのほうだと感じました。

測定の仕方については、コース自身がはっきり述べています（モジュール6）。

AI-DLC は最初は時間がかかる場合がありますが、開発のライフサイクル全体を測定すると優れた結果をもたらします。

要件・設計・開発（手戻りを含む）の全体で測れ、という指針です。コンストラクションだけを切り出して「速くなっていない」と判断するのは早い、ということだと受け取りました。

なお AI-DLC は awslabs が公開する OSS（MIT-0）で、AWS の公式サポート対象ではありません。実装を評価する際はこの前提を忘れないほうがよさそうです。

まとめ：明日から真似できること

手を動かす部分がなくても、明日から持ち帰れるものを3つに絞りました。

イテレーションの単位を「日」で測り直す。 ボルトの発想を借ります。2週間を暗黙の前提に置かない、というだけでも見え方が変わります。
設計レビューで「製品名が出てきたら止める」。 機能設計はテクノロジー非依存で、非機能要件設計は論理コンポーネントまで。製品を決めるのはインフラ設計から。
AI の提案を全員が同じ画面で見る時間を確保する。 ただし、事前準備（技術的準備・部門横断の配置・ドメイン知識の評価）とセットで。

コースそのものの評価

良かったのは、3時間半を通して 「AI をどう使うか」ではなく「開発プロセスをどう作り直すか」 に一貫して寄せられていた点です。ツールの使い方の話に逸れません。

物足りなかった点も書いておくと、具体的なツール操作や失敗事例の分量です。手を動かす部分は結局、別途 GitHub 側を触る必要があります。逆に言えば、概念の整理に特化していると割り切れば3時間半は妥当な長さでした。

v2 のワークショップは抽選に外れてしまいましたが、二極（支援型 / 管理型）の間に立つ、という言語化を得られただけでも受ける価値がありました。次は実装を動かしてみたいと思います。

AI駆動開発ライフサイクル（AI-DLC）の日本語版Skill Builderの結果

AI駆動開発ライフサイクル（AI-DLC）の日本語版Skill Builderの結果を開く

40問中37問正解で93%で合格しました。

AI駆動開発ライフサイクル（AI-DLC）の日本語版Skill Builder_ナレッジバッチ

付録：この記事に出てきた用語

AI-DLC の語彙は独特なので、本文で使った語を重要順にまとめました。★ 印の3語は、コース（方法論）と v2 実装とで指すものがずれるので注記付きです。

用語集（20語）を開く

#	用語	読み	説明
1	AI-DLC	エーアイ・ディーエルシー	AI-Driven Development Life Cycle（AI 駆動開発ライフサイクル）。awslabs が公開する MIT-0 の OSS で、AWS の公式サポート対象ではありません（コミュニティベース）。
2	AI 支援型（AI-assisted）	エーアイ・アシステッド	コード補完など限定的なタスクにだけ AI を使う形。従来の進め方を続けるため、品質は保たれるがスピードはほとんど向上しない。
3	AI 管理型（AI-managed）	エーアイ・マネージド	人間の関与を最小にし、AI が自律的・シングルショットで生成する形。生成は最速だが品質が伴わず、レビューと修正に時間を取られる。
4	SDLC	エスディーエルシー	ソフトウェア開発ライフサイクル。ウォーターフォールやアジャイルを含む上位概念で、AI-DLC が置き換える対象として登場する比較用語。AI-DLC は SDLC に AI を足したものではありません。
5	Phase（フェーズ） ★	フェーズ	ライフサイクルの大区分。コースは3つ（インセプション / コンストラクション / オペレーション）で説明しますが、v2 実装は5つ（Initialization / Ideation / Inception / Construction / Operation、計33ステージ）です。
6	Stage（ステージ）	ステージ	フェーズを構成する離散ステップ。本文の「コンストラクションの5ステージ」がこれにあたります。
7	Bolt（ボルト）	ボルト	スプリントに相当するコンストラクションの反復。数週間ではなく数時間〜数日。v2 では計画文書として作られますが、既定の走行はこれを実行単位として消費しません。
8	モブ実行（Mob execution） ★	モブ・エグゼキューション	コースの「モブコンストラクション／モブエラボレーション」は人が集まる儀式を指します。一方 v2 実装の `mode: mob` は特定の1ステージだけに付くエージェントの実行モードで、別物です。
9	承認ゲート（Approval gate）	アプルーバル・ゲート	各ステージ末尾の対話チェックポイント。承認 / 変更要求 /（3回改訂後の）現状受諾を人が選びます。本文でいう「人間の持ち場」の実体。
10	検証ゲート（Verification gate）	ベリフィケーション・ゲート	フェーズ境界で走るトレーサビリティ検査。リンク欠落や孤立した成果物を、下流が積み上がる前に捕まえます。最終判断は人間。
11	トレーサビリティ	トレーサビリティ	要件からコードまでの追跡可能性。要件 → ユーザーストーリー → コンポーネント → 作業ユニット → コードの連鎖。本文5章の中心概念。
12	作業ユニット（Unit of work）	ユニット・オブ・ワーク	独立して実装可能な解の一片。インセプションの「How」の答え。PMBOK の WBS とは粒度が異なり、工数・金額・日付を持ちません。
13	意図 / Intent ★	インテント	コースではインセプションの「Why」＝ビジネス上の目的を指します。v2 実装の Intent は1件の作業を登録する単位で、別の意味です。
14	ADR	エーディーアール	Architecture Decision Record。Context / Decision / Consequences / Alternatives Rejected の4節で、「なぜ A ではなく B か」に後から答えられる状態を保ちます。
15	グリーンフィールド / ブラウンフィールド	—	既存コードベースが無い新規開発 / 有る既存改修。本文の「新規開発起点」「リバースエンジニアリング起点」に対応します。
16	CodeKB	コード・ケービー	リポジトリ単位のコード知識ベース。リバースエンジニアリングが生成し、複数の作業をまたいで再利用されます。
17	スコープ / ワークフロープロファイル	スコープ	どのステージをどの深さで実行するかを決める構成。本文の「AI がステージを動的にスキップする」の裏側にあたります。
18	Rule ⇄ Sensor	ルール / センサー	Rule は作業前に効く恒久的な行動規則（フィードフォワード）、Sensor は出力に対して発火する決定的チェック（フィードバック）。この対で品質を担保します。
19	レビュアー（Reviewer）	レビュアー	成果物が出た後に別エージェントとして起動する品質ゲート。所見はレビューファイルに書き、成果物には書きません。ブロックはせず、最終判断は常に人間。
20	Plan Approval	プラン・アプルーバル	計画そのものへの承認。「コード生成は人間が実行計画を承認してからのみ始まる」がこれで、自律モードでも省略されない必須のハードストップです。

出典: AI-DLC 公式 Glossary（https://awslabs.github.io/aidlc-workflows/guide/glossary/）。v2 実装に関する記述は v2.9.0 時点のものです。

参考リンク

受講したコース
- AI駆動開発ライフサイクル（AI-DLC）日本語版 Skill Builder
参考にした記事
- 「AI駆動開発ライフサイクル（AI-DLC）の日本語版Skill Builderが公開されたので体験してみた」(2026/8/31: @news_it_enj （荒木 ARK）さん)
- AWS AI-DLC Unicorn Gymに参加して感じた、AI時代に開発者の仕事はどう変わるのか (2026/9/18:@hacchi_no_donburi (佐藤祥人)さん)
実装リポジトリ
- awslabs/aidlc-workflows
公式ドキュメント
- AI-DLC Workflows Documentation

※ 本文中の数値（所要3時間半、全9モジュール、コンストラクションの5ステージ、ボルト = 数時間〜数日）は受講時点のものです。v2 実装に関する記述は v2.9.0 時点で調べた内容であり、私自身が動かして確認したものではありません。
※ AI-DLC v2は現在試していますがリバースエンジニアリングでかなり苦戦中です。
※ 記事中のイラストは生成 AI（gpt-image-2）で作成しました。