はじめに

こんにちは、MSP セクションの毛利です。

前回の記事で、私たちのチームが今期、業務の自動化に取り組んでいることをお伝えしました。まずはスペック駆動開発（SDD）に挑戦しているところです。

ただ、自動化したい業務はまだまだたくさんあります。そこで考えていたのが、「要件の検討から開発（SDD）まで含めて、AI-DLC（AI 駆動開発ライフサイクル）でサイクルを回せないか」ということでした。

そんな期待があったため、今回の AWS Summit Japan 2026 では、AI-DLC 関連のセッションを中心に聞くと決めて参加しました。実際に聞いたのは、次の4つです。

  • AI 駆動開発ライフサイクル (AI-DLC) のご紹介 [AIM221]
  • AI 駆動は上流工程にこそ活きる － 非エンジニアにこそ知ってほしい、AI 駆動開発ライフサイクルによる上流工程の変革 [AIM222]
  • AI でコードは書けても、レビューできる人がいなくなる ― ソフトウェア開発における自動化のパラドックス [AIM223]
  • Kiro と Amazon の文化から学ぶ AI 駆動開発の型 [DVT324]

この記事では、AIM221・AIM222・DVT324 の内容と、聞きながら考えた「MSP でどう活かすか」をお伝えします。AIM223 については、別の記事で詳しく書いたのでそちらをどうぞ。

なぜ MSP が AI-DLC なのか

開発手法を新しく取り入れるとき、よく論点になるのが「既存のプロセスをどう変えるか」だと思います。ですが私たち MSP は、少し事情が違います。

  • そもそも、組織的にソフトウェア開発を実施していないため、プロセスがない（ゼロからのスタート）
  • メンバー自身も、業務でソフトウェア開発を実施した経験がほぼない

開発の土台がない、というのは一見ハンデです。ですが裏を返せば、変えるべき既存のやり方もない、ということでもあります。だからこそ、最初から AI-DLC を前提に組み立てて、一気に進められないか ― そんな期待を持って参加しました。

AI 駆動開発ライフサイクル (AI-DLC) のご紹介 [AIM221]

AI-DLC は、AI を開発の中心に据えた開発ライフサイクルです。大きく3つのフェーズで回ります。

  • Inception（インセプション）：既存コードからコンテキストを作り、ユーザーストーリーで意図を明確化、作業単位で計画する
  • Construction（コンストラクション）：ドメインモデルを起こし、コードとテストを生成、IaC でデプロイしてテスト
  • Operation（オペレーション）：IaC で本番へデプロイし、インシデントを管理する

印象的だったのは、「AI にコードを速く書かせれば終わり、ではない」という話です。従来の開発で時間がかかっていたのは、実は“誰かが、誰かの作業を待っている”時間。だから AI-DLC では、みんなで集まって一気に進める「モブ（Mob）」を重視していました。

私たちはリモート中心で集まりにくいので、ここは工夫が要りそうです。並行して進められる単位に分割したり、意見を出し合って誰かが取りまとめる、を繰り返す形が合うかもしれない、と聞きながら考えていました。

9つの教訓も紹介されていて、その中で特に刺さったのがこの2つです。

  • 素早く失敗する（実験への姿勢）
  • AI との協働を学ぶには、実践経験が大切

「コーディングは、コードを書かずに学べましたか?」「近道はありますか?」というスライドの問いが、ずっと頭に残っています。そして「最終的なコードの所有者はあなた。コミットログにはあなたの名前が残る」とも。AI に任せても、責任は人に残る、ということを再認識させられました。

AI 駆動は上流工程にこそ活きる [AIM222]

こちらは、より上流・ビジネス寄りのセッションでした。私がいちばん知りたかった「要件検討の“上流”に AI をどう効かせるか」に応えてくれる内容でした。

  • AI が得意なのは、ゴールが明確な作業
  • AI が不得意なのは、漠然とした議論、正解のない意思決定、非機能要件の考慮 ― つまり、上流工程ほど人間の知見が要る

では、その人間の知見を、AI とどう組み合わせるのか。ここで鍵になるのが モブワークでした。AI にいろいろな意思決定をリアルタイムで委ねるには、人間のチームが即応できる態勢が要る。ミーティングを「承認の場」から「共同作業の場」に変える、という発想です。

そして刺さったのが、モブワークは“機能伝承の場”になるという話。AI 時代に求められるのは、(1) うまくやるために必要な経験を伝えるスキル、(2) 適切な問いを立てるスキル（AI は放っておくと一般論を返しがち）だ、と。

ただ、私たちは全員で集まって集中するのが難しい環境です。だからこそ、この“機能伝承の場”を私たちなりにどう作り込むか、工夫して検討する必要があると感じました。

Kiro と Amazon の文化から学ぶ AI 駆動開発の型 [DVT324]

最後は、エンジニアの学びと“型”についてのセッションです。

コードを書く主体は、もう AI になった。でも、だからこそエンジニアの技術は、これまで以上に重要になる。

紹介されていた Kiro は、人間の指示を「仕様」（要求定義・設計・実装タスク）に変換し、その仕様を介して人間と AI が合意形成しながら実装を進める、という考え方でした。「目的は仕様書を作ることではない」「仕様はスーパープロンプトとして機能する」という言葉が印象的でした。Kiro はまさに SDD（仕様駆動開発）で開発を進めるためのツールです。MSP でも一部のメンバーはすでに Kiro を使っていますが、組織的に導入していくのも選択肢の一つだと感じました。

心に残った「You build it, you run it」

セッションを通して、何度も出てきて、いちばん心に残った言葉があります。

“You build it, you run it.” ― 作った人が、運用まで責任を持つ

この言葉は、私たちのチームがミッションとして掲げていること ― 自分たちで業務を理解し、設計し、作り、運用まで持つ ― と、自然と重なっていました。目指している方向とこの言葉がぴたりと一致していて、どこか運命的なものを感じました。自分たちの取り組みは間違っていないんだ、と自信を持てた瞬間でした。

いちばんの気づき ― 経験しながら学ぶ「両輪」

たくさんの学びがありましたが、私の中でいちばん残ったのは、こんな感覚でした。

「できる」と「できない」を分けているのは、結局のところ「知っているかどうか」だと思います。ただ、その“知っている”には2種類あるな、と感じました。経験から知っていることは、生々しくて強いけれど、どうしても断片的。一方で、学び（座学）から知っていることは、体系的だけれど、頭でわかっているだけになりがちです。だからこそ、経験しながら学ぶ ― その両輪を一緒に回していくことが大事なんじゃないか。今回のサミットを通して、強くそう感じました。

AI-DLC は、まさにこの両輪を回す仕組みになり得ると感じました。メンバーが実際に手を動かして開発を経験しながら、AI-DLC や SDD という型で学ぶ。MSP にはもともと開発プロセスがないからこそ、最初からこの両輪を前提に組み立てられる ― そう前向きに捉えています。

おわりに

AI-DLC を上流に据えて、SDD につなぐ。そして、メンバーが「作って、運用まで持つ」経験を積みながら学んでいく。これが、私たちの業務自動化のミッションを前に進める形だと、サミットを通して自信を持てました。

正直なところ、AI-DLC は、私たち MSP の開発にとっては少し“過剰”かもしれません。ですが、それを見極めるために立ち止まるよりも、まずはチャレンジすることを優先したいと思っています。動きながら軌道修正していけばいい。そして、その試行錯誤そのものが経験になり、次につながっていく ― さきほどの「経験しながら学ぶ」を、まずは自分たちで実践してみるつもりです。

まだ始まったばかりです。実際にやってみて分かること、つまずくこともたくさんあると思いますが、その過程もまた発信していきます。