Keynote：AI駆動開発ライフサイクル（AI-DLC）のご紹介
まず、発表の冒頭ではAIが普及してからお客様の声として以下が上がっていることが説明されました。
1.変化への不安
・AIによって業界に大きな変化が訪れようとしている
・どのように備えればいいかわからない
2.うまく扱いきれない
・数多くのAIコーディングが期待通りの動作をしない
・より良いツールがどんどん出てくるが、前のツールが良かったなど
3.開発者をAIファーストにするにはどうすればいい？
・スケールの壁、何千人の開発者にどう広めればいいかわからない
ここ３〜４年の間にChatGPT、Gemini、Cline、Claude等がリリースされてきました。そこからはMCPやSkill、SDD、マルチエージェント、ハーネス等、手法や技術がどんどん出てきて、本当に変化が激しいですよね。
AI ソフトウェア生産性のパラドックス
2025年の研究ですが、以下の研究では「AIを使用したことで24%開発スピードが上がった」と認知したのにも関わらず、「実際には19%も生産性が下がった」と報告しています。
※大規模なOSSへのコントリビュート経験のある開発者をAI使用群とAI未使用群で実際の開発を実施
ただし、これは単に「AIがプログラミングに役に立たない」という話ではないです。AIを数十時間程度触った程度かつ「高い技術力が求められる・複雑なドメインを有する」ような現場においては、2025年時点ではAIは人間の開発スピードを低下させることを研究では示唆しています。同時にプロンプトやファインチューニングの実施によって結果は異なることも示しています。
Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
AI-DLC（AI-Driven Development Lifecycle）とは？
従来のAIでの開発アプローチとして以下のような手法が挙げられていました。
AI-Managed：AIは自律的にソフトウェアを構築・保守して人間の関与は最小限・またはゼロ
この手法だと実装されたコードの振る舞いを評価することは可能ですが、実装されたコードが正しいかを信頼することや説明することができません。
AI-Assisted：開発者が要件定義・設計や実装をたくさん考え、狭い範囲でのタスクをAIに任せることです。
これではAIによるアジリティが損なわれます。また、コーディング以外の部分で多くの時間を消費してしまい、開発全体のライフサイクルとしてはAIを使わない状態になる可能性があります。
AI-DLCではAIのワークフローの中に人間が監視・レビュアーとして登場します。
- 人が意図・企画を渡す
- AIが計画を作成
- 人が計画をレビュー
- AIが計画を修正
- 人が修正計画をレビュー・承認
- AIが計画を実行
- 人が結果をレビュー
- 再度計画のサイクルを回す
全体の流れを次の３段階でまとめていました。
- INCEPTION
・既存コードのコンテキストの構築
・ユーザーストーリーで意図の詳細化
・作業単位での計画 -
CONSTRUCTION
・ドメインモデル ※ドメイン駆動の場合
・アーキテクチャコンポーネントの追加
・コードとテストの生成 -
OPERATION
・IaCで本番環境にデプロイ
・AIファーストなインシデント管理
・開発者への素早いFB
特にINCEPTIONでは意図の正確な言語化が必要だと感じました！
人間のためのオペレーティングモデル
ソフトウェアの開発ライフサイクルにおいて、実装の時間は意外と短いです。
多くの時間は要件定義・設計に費やされるかと思います。
その中でも人間同士でのコミュニケーションに費やす時間も多いですよね。
「設計のレビューをお願いします」
「この設計は大丈夫なのか」
「この実装はもっとこうしてほしい」等
このように開発チームの意思や各人が抱えている情報が違うことで意思決定に「待ち」が発生する場面はよくあります。
実際に私もプロジェクトの中でレビューが溜まってしまい、私自身がボトルネックになる経験がありました。
AIの生成スピードは速いのですが、結局人間関係の依存関係の解消が必要です。
そこで、次の方法が提唱されていました。
モブエラボレーション
運用チーム、開発チーム、ビジネスアナリスト、プロダクトマネージャー、QAが一堂に集まりその場で全員がAIの成果物を見ていくアプローチです。メリットは次のとおりです。
・全員でレビューをしていくと意図が洗練されていく
・意思決定がその場でされていく
・全員がAIに対してのレビューをしていくのでその場での合意形成ができる
余談ですが、この話を聞いた時にスマブラの作者である桜井政博さんの動画を思い出しました。
桜井さんはゲーム開発でゲームのキャラ制作に関わるメンバーを全員集めて、キャラのコンセプトや内容を伝えていたようです。
時間がかかってしまう一方で、いろんなメンバーが集まって生成AIのレビューをすることで意思の統一化が図れること、それぞれの担当の観点を持ってレビューができるのでこれは非常にいい方法だと思いました。
モブコンストラクション
・小規模チームを形成しての開発、QA、デザイナー等の役割を超えた混合チームを形成し、各チームでビジネス要求を実装・テストしデリバリーまで行います。
・ここでもその場で高度な意思決定を繰り返して行います。
得られた教訓
コンテキストウィンドウは慎重に管理する
・コンテキストの内容に無関係な情報（ノイズ）が入っていないか？
・コンテキストのリセットタイミング
つい設計書に色々書いてしまいがちですが必要以上に記載をしてしまうとコンテキストを圧迫し、精度問題に繋がります。
既存システムでもうまくいく
・そのまま大規模なコードベースを入力するのを止める
・事前にコードの意味を要約したリッチなコンテキストを構築する
・非常に大きなコードベースには、高度な分解手法を使用する
以前、生成AIを活用するために、リポジトリを集約していくことが必要だと述べましたが、
ただ集約して全部を読ませるだけではなく、生成AIにどこまで読ませるかのガードレールを敷く必要がありそうですね。
生成AIをフル活用できるモノレポ構成について
既存コード例を模倣させる
・リファレンスのコードベースが強力なコンテキストとなる
・事細かに指示するより簡単にコードベース全体の構造やスタイルの両方を踏まえた生成が可能
最初が肝心ですね。AIは模倣する性質があるのでベースが悪いとそれを模倣してどんどん質の低いコードを生成してしまいます。開発初期段階でのAIレビューの際は時間を割いてでも無駄のないコードにする必要があると感じました。
AIとの協働を学ぶには実践経験が大切
・コーディングはコードを書かずに学べたか？
・近道はあるか？
発表の最後には以下のメッセージがありました。
最終的なコードの所有者はあなたです。
コミットログに著者として載るのはあなたの名前です。
「AIが言っているから」「AIが判断したから」ではなく、自分の意見や意思を入れて
開発等に取り組んでいきたいですね。
最後に
AI-DLCの取り組みを視聴する中で以下の課題があると思いました。
・ある程度の経験を積んだメンバーが必要
・コミュニケーションがしっかり取れるメンバーが必要。もしくはコミュニケーションが取れるチームに成長させる
上記の場合、どのようにAI-DLCに取り組んでいけばいいかは今後考えていきたいと思います。
ただ、この取り組みでサイクルが回ってきた時に組織の成長の観点で非常にメリットがあると感じました。
各メンバーの様々な考えや意図を知ることができるのでメンバー全員のレベルアップができそうです。
まずは小さなプロジェクトや仮想プロジェクトで実践してみたいと思います！
簡単30秒