『AI-DLC の紹介』というタイトルでゆるWeb勉強会@札幌で登壇しました #ゆるWeb札幌
いわさです。
2026年8月22日に開催された「ゆるWeb勉強会@札幌 #31」で LT をしてきました。
今回のテーマは「最近のお気に入りツール・フレームワーク紹介」で、私は AWS が提唱する AI 駆動開発フレームワーク「AI-DLC」の紹介をさせて頂きました。
この記事ではスライドやイベントの様子を共有したいと思います。
登壇資料
発表スライドはこちらになります。
AI-DLC（AI-Driven Development Life Cycle）は、「AI が計画を作って人間が承認する」という開発フローのフレームワークです。
今回の発表では「フレームワークとしての AI-DLC」と「ツール（awslabs/aidlc-workflows）としての AI-DLC」の2つの観点から紹介しました。
私もちょうどキャッチアップしているところだったので、今回の登壇を機に色々と実際に使ったり情報を整理することができました。
人に説明できるくらいにはなったかなと思います。
質問への回答
発表中のわいわいタイムでいくつか質問を頂いたのですが、私も使い始めたばかりで十分にお答えできなかった部分がありました。
発表後にツール（awslabs/aidlc-workflows v2）のソースコードとドキュメントを調べてみたので、わかった範囲でまとめます。
記憶していくとコンテキストファイルが膨大になるのでは？
サイズ制限や自動整理の仕組みは見つかりませんでした。
学びが蓄積される先は team.md と project.md の2ファイルで、ワークフローを繰り返すたびに行が追記されていきます。
ただ、同じ内容が二重に書き込まれないように cid マーカーという仕組みがあったり、組織レベルルール（org.md）と矛盾する学びは弾かれるようになっていたりと、増えっぱなしにならないための工夫は入っていました。
team.md / project.md はログではなく「現在有効なルールの集合」で、学びの履歴は別ファイル（audit shard やステージごとの memory.md）に記録される設計です。
とはいえファイルサイズが増え続けること自体への対処は見当たらないので、長期間使い続けるプロジェクトでは定期的に人間が整理する運用が必要になりそうです。
コンテキストウィンドウに全量読み込む設計のため、いずれどこかで問題になり得るポイントだと思います。
人間が開発したい部分とAIが開発したい部分を分けることはできるのか？
AI-DLC は「AI がリードして人間が承認する」フレームワークなので、「ここは人間が書きたい」を前提にした使い方はフレームワークの想定から外れます。
仕組み上は以下のようにやろうと思えばできなくはなさそうでした。
- スコープ選択や compose/recompose でステージを SKIP にすれば、そのステージは AI が実行しない
- 承認ゲートで Reject して人間が書き直せる
ただし「このファイルは AI、このファイルは人間」のようなファイル単位の指定はできないようです。
「AI の出力品質が不安」ということであればレビュー・センサー機構（自動チェック）で対処するほうが合っていそうですし、「創造的な部分は自分で書きたい」ということであれば Copilot 的な「人間リード＋AI 補助」のツールを使ったほうがよさそうです。
仕様書みたいな単一なドキュメントを生成してくれるのか？
「統合仕様書」を自動生成する機能はありませんでした。
各ステージが個別の Markdown ファイルをインテントのディレクトリ配下に出力する設計になっています。
requirements.md、components.md、contract-summary.md、stories.md などがそれぞれ別々に生成されます。
それぞれ十分に詳細で設計ドキュメントとして機能しますが、1ファイルにまとまってはいません。
唯一「単一ドキュメント」に近いものとして OUTCOMES.md（/aidlc-outcomes-pack）がありましたが、これはワークフロー完了時に生成される引き継ぎ資料で、仕様書ではありません。
v1にはステージなどの概念が無さそうだった、v2で追加されたのか？
GitHub のリポジトリ（main ブランチ = v1）を確認してみたところ、v1 にもフェーズ・ステージの概念は存在していました。
v1 と v2 の違いはステージ概念の有無ではなく、制御の仕方と粒度の差でした。
| v1 | v2 | |
|---|---|---|
| フェーズ | 3つ | 5つ（Initialization / Ideation が追加） |
| ステージ数 | 十数個 | 33個 |
| 進行制御 | LLM 依存（プロンプトで AI が判断） | 決定論的 TypeScript エンジンで状態遷移を管理 |
| エージェント | 単一の AI が全て担当 | 14体が専門分野で分業 |
v2 のロードマップには「v1 は段階的 SDLC における人間ループの価値を実証するもの。v2 はワークフローを再構築し、機械検証可能な範囲を広げる完全リライト」と書かれていました。
v1 を触ったときに「ステージ感が薄い」と感じたのは、進行制御が LLM 任せで決定論的ではなかったためかもしれません。
AI-DLC から持ち帰りたいと思ったポイント
今回キャッチアップしてみて、AI-DLC の仕組みの中で普段の開発にも使いまわせそうだなと思った点が2つありました。
1つ目は、14体のエージェント定義の設計です。
AI エージェントにペルソナを定義して役割を持たせるのは普段からやっているのですが、1体のエージェントに詰め込むルールや定義の情報量が多すぎると、全部は厳格に実施してくれなくてドロップされちゃったりします。
AI-DLC では1体あたりの責務を絞って、代わりにエージェント数を増やして分業させています。全員にレビューさせるような構成のほうがアウトプット品質が上がるのかもしれません。
2つ目は、ワークフローを繰り返す中で学習し続ける仕組みです。
プロジェクトや組織のナレッジを team.md / project.md に継続的に追記していって、次回のワークフローではそれをコンテキストとして読み込む。使うたびに賢くなっていく感じで、これは真似したいなと思いました。
勉強会の様子
発表内容はスライドを見て頂ければと思うので、ここではイベントの様子を少しだけ。
会場はクラスメソッドの札幌オフィス（札幌ブリックキューブ 10階）でした。
たくさんの方にお越しいただきました。
今回のテーマが「最近のお気に入りツール・フレームワーク紹介」ということで、1password での環境変数管理、Tauri でのツール開発、サクラエディタの知られざる機能、Vaultwarden のおうちサーバー運用など、色々な発表がありました。
さいごに
本日は『AI-DLC の紹介』というタイトルでゆるWeb勉強会@札幌 #31 で登壇したので、その登壇レポートを作成させて頂きました。
ゆるWeb勉強会はその名の通り質問もしやすい雰囲気で、発表中にもわいわいとやりとりがあって良い勉強会でした。
