📑

「AI 駆動開発ライフサイクル（AI-DLC）」への個人的理解まとめ

に公開
学習メモ
aidlc
ai駆動開発ライフサイクル
idea

はじめに

ここ最近、「AI 駆動開発ライフサイクル（AI-Driven Development Lifecycle、AI-DLC）」という考え方に出会いました。
以下がその white paper です。

最初は、AI によるプロセス改善の一つくらいに思っていました。
しかし、資料を読み込むにつれ、これは開発者・チームの役割や思考方法そのものを再構想する試みなのだと感じました。

※この記事は、私が AI-DLC についての white paper を読み込んだ過程で感じたことや最終的に理解したことを整理するための記事となっています。

この記事の結論

私が AI-DLC を調べて得た最も重要な気づきは以下の2点です。

  • 開発者の役割を AI の提案を評価・判断する「マネージャー」へとシフトさせることが求められる
  • 良きマネージャーになるには、コンテキストエンジニアリングを実践しなければならない

AI-DLC への違和感から理解までの道のり

AI-DLC の基本的な考え方

AI-DLC を理解する上で、まず押さえておきたいのが、そのプロセスです。
これは単に AI を使うだけでなく、AI と人間が協働するための具体的なステップが定義されています。

そのプロセスは、大きく3つのフェーズに分かれています。

  1. Inception（着想）フェーズ

    • すべては、プロダクトオーナーや開発者が示す高レベルな目的 Intent から始まります。
    • AI はこの Intent を解釈し、具体的なユーザーストーリーや Unit（独立した作業単位）に分解した計画案を提示します。
    • 人間は、AI が生成した計画をレビューし、ビジネス要件と合致しているか、リスクは何かを判断・承認します。

  2. Construction（構築）フェーズ

    • 実際の開発は Bolt と呼ばれる数時間〜数日単位の短いサイクルで進められます。
    • AI がドメインモデル、論理設計、そして実際のコードとテストを段階的に生成します。
    • 開発者はその提案をレビューし、技術的な妥当性を判断し、必要に応じて修正を指示します。

  3. Operations（運用）フェーズ

    • デプロイ後も AI の役割は続きます。
    • システムの監視データ（テレメトリ）を分析し、異常の予兆を検知したり、改善点を提案したりします。
    • 人間は、その提案を評価し、どの改善策を実行するかを決定します。

このフロー全体を貫いているのが、 「AI が提案し、人間が判断する」 という原則です。
従来の開発のように、人間がゼロから詳細な指示書を書くのではなく、AI が叩き台を作り、人間はそれに対するレビューや意思決定に集中する。

「AI が会話を始める」という違和感

私が AI-DLC について学び始めたとき、違和感を覚えたことがありました。
それは以下のことが説かれている箇所です。

AI-DLC introduces a fundamental shift where AI initiates & directs
the conversations with humans instead of humans
initiating the conversation with AI to complete their tasks.

AI-DLCは根本的な転換をもたらします。
人間がタスクを完了するためにAIとの会話を開始するのではなく、
AIが人間との会話を開始し、主導するようになるのです。

これにはいまいちピンときませんでした。
具体的に何が変わるのだろうか、何を変えなければいけないのか...

AI-DLC のインプットとアウトプットに着目する

そこで私は、改めて AI-DLC の white paper を図解することで理解しようと試みました。
AI に図解してもらう際は、各フェーズのインプットとアウトプットに着目するようにさせました。

それがこの図です。
（Claude に作成してもらいました）

この図を見て気づいたのですが、プロセス全体を貫いているのが、 「AI による成果物に対して人間が可否を下してから次のステップに移る」 という原則です。

ここで人間のタスクが質的に変わったと感じました。
従来の開発プロセスでは、人間は要件分析、設計、実装、テストといった作業を担当していました。

ところが AI-DLC では、開発者（チーム）に求められるのは、AI の提案に対して「ビジネス要件と合致しているか？」や「組織のガイドラインに合っているか？」を判断することです。

つまり、開発者（チーム）は 「マネージャー」の役割へとシフトすることが求められるのです。

こう理解した時、先ほどの違和感は払拭されました。

AI の提案の質を左右する「コンテキストエンジニアリング」

開発者がマネージャーとして振る舞うのであれば、 AI が提案する内容の質が成功の鍵を握ります。

AI に「新機能を実装して」と指示するだけでは、業界標準的で「平均的な」答えしか返ってきません。
しかし、私たちのプロジェクトは平均的ではありません。

  • 独自のドメイン知識
  • 既存の技術スタック
  • チーム固有の設計思想
  • 過去の失敗から学んだ教訓

こうしたコンテキストを AI に与えることで、初めて「私たちのプロジェクトに最適な」提案が生まれます。
つまり コンテキストエンジニアリング に向き合う必要があります。

コンテキストとして、例えば以下のような情報が挙げられると考えられます。

  • API スキーマ
  • データベーススキーマ
  • アーキテクチャ図
  • ADR, Design Doc
  • 技術的な制約や非機能要件

現状の AI の性能やコンテキストウィンドウではこれらの情報を一挙に渡すのは現実的ではないので、
「最適なステップ」で「最適な情報のみ」をどうやって渡すのかを今後考えなければならないのではないでしょうか。

AI-DLC の現実的な導入戦略

ここまでの考察から、AI-DLC は強力な一方、既存のレガシーシステムを持つ多くの現場では、いきなり全面適用することは現実的ではないとも思いました。

よって、既存システムの改修では、以下のような段階的な導入アプローチが有効ではないでしょうか。
（これはトヨタの自動運転のレベル表を真似してみました）

レベル 名称 概要 AI の主な役割 人間の主な役割
0 非AI-DLC AI を使い、既存のコード改修やドキュメントを分析する。 コード・ドキュメントの生成。 開発における計画、設計、実装、検証をタスクごとに主導。
1 AI支援により、コンテキストメモリーを可視化 AI を使い、既存のコードを分析・可視化する。 既存コードの静的/動的モデルのドラフト生成、ドキュメントに要約。 AI の生成物を レビューし、手動で修正・清書。コンテキストメモリーを構築。
2 整備されたコンテキストに基づいたコード生成 人間が設計した小タスクの実装計画・テスト計画を AI が実行する。 コード生成、ユニットテスト作成、単純なリファクタリング。 明確な指示とコンテキスト を与え、生成されたコードを レビュー・修正 する。
3 AIによる計画 育ってきたコンテキストを基に、計画プロセスを AI が支援する。 ユーザーストーリーや受け入れ基準の草案を提案。Intent から設計のたたき台 を生成。 AI の提案を 起点 に議論し、最終決定。計画の主導権は人間が持つ。
4 高度な自律開発 ビジネスレベルの Intent から、人間の承認のみで価値をリリースする。 Intent の分解・計画。また、設計からテスト、Deployment までを一貫して実行。自己修正案を提示。 ビジネス上の戦略決定。AI の計画と最終成果物を 承認。例外処理とアーキテクチャ判断に集中。

まとめ

  • 開発者は「マネージャー」へ
    • AI-DLC において、開発者の役割はコードを書く実装者から、AI の提案を評価・判断するマネージャーへとシフトします。
  • 成功の鍵は「コンテキストエンジニアリング」
    • AI から質の高い提案を引き出すには、API スキーマや設計思想など、プロジェクト固有のコンテキストを AI に与えることが不可欠です。
  • 導入は段階的に
    • 既存システムがある環境では、まず AI に現状を分析・可視化させ、コンテキストを整備することから始め、小さな範囲で成功体験を積むことが現実的ではないでしょうか。

今後 AI-DLC は、人間と AI の関係性をどう設計するかという思考の転換点となる開発プロセスとなるかもしれません。

このプロセスで成功するのに必要なのは、マネージャー的な判断能力だと考えられるので、今後はこういったスキルを伸ばすのが重要になってくると思いました。

Discussion