6
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【AWS】AI-DLCを実際にチームでやってみてわかったことをまとめてみました

6
Last updated at Posted at 2026-06-12

はじめに

先日(2026年5月)、AWSが主催する以下のハッカソンに、チームで参加してきました。

このハッカソンのテーマのひとつが、AWSが提唱する新しい開発手法 AI-DLC(AI-Driven Development Life Cycle) を利用することでした。

「AIと一緒に開発する」と聞くと、最近は Claude Code や Amazon Q、Cursor などのAIコーディングツールを思い浮かべる方が多いと思います。AI-DLCはそういった「ツールの使い方」の話ではなく、チーム全体の開発プロセスそのものをAI前提で組み直すという、もう一段階上の考え方です。

この記事では、

  • そもそもAI-DLCとは何なのか
  • 実際に若手中心のチームでやってみて、何が良くて、どこでつまずいたのか

を、できるだけ正直にまとめてみます。これから試してみたい方の参考になれば嬉しいです。

⚠️ あくまで一回のハッカソンで体験した範囲の所感です。チーム構成やプロダクトによって感じ方は変わると思うので、その点はご了承ください。

AI-DLCとは?

AI-DLC(AI-Driven Development Life Cycle)は、AWSが提唱する AIを開発の「中心的な協力者」として組み込んだ開発ライフサイクル です。

3つのフェーズ

AI-DLCは大きく3つのフェーズで構成されています。

image.png

フェーズ 役割 やること(ざっくり)
Inception(構想) 何を・なぜ作るか ビジネス要件の言語化、ユーザーストーリー作成、リスク評価
Construction(構築) どう作るか アーキテクチャ設計、ドメインモデル、実装、テスト
Operations(運用) どう動かし続けるか デプロイ、監視・可観測性の確保

それぞれのフェーズで、AIが提案を出し、チーム全員でそれを検証していく形で進みます。

試せるリポジトリ

AWS Labsから、実際にAI-DLCのワークフローを試せるオープンソースが公開されています。

Claude Code、Amazon Q、Kiro、Cursor、Cline、GitHub Copilot など、主要なAIコーディングエージェントに対応しているので、手元の環境で試しやすいのもありがたいポイントです。

実際にやってみてわかったこと

ここからが本題です。ドキュメントを読むだけでは見えてこなかった、実際に手を動かして初めてわかったことをまとめます。

1. レビューが多くなり、人間がボトルネックになる

これが一番強く感じたことでした。

AI-DLCでは、AIが要件・設計・実装の各段階で次々と提案を出してきます。生成のスピードはとにかく速い。ところが、AI-DLCの根幹である「重要な判断は人間がする」を守ろうとすると、そのすべてを人間がレビューして承認する必要があります。

結果として何が起きたかというと、

  • AIの生成スピード >>> 人間のレビュースピード
  • レビュー待ちのものがどんどん溜まっていく
  • AIではなく人間がボトルネックになる

という逆転現象でした。「AIで速くなる」と素直に思っていたのですが、速くなるのはあくまでAIが担当する部分だけ。チーム全体のスループットは、結局レビューできる人間の数とスピードで決まる、というのが実感です。

AI-DLCを回すなら、「どこまでをAIに任せ、どこを人間が見るか」のレビュー設計を最初に決めておくのが重要だと感じました。全部を丁寧に見ようとすると、人間が詰まります。

2. 若手のみのチームだと、レビュワーとしての視点や経験が不足する

私たちのチームは若手のみの構成でした。普段の開発では大きな問題はないのですが、AI-DLCではこの構成が思わぬ形で効いてきました。

AI-DLCは「AIの提案を人間が検証する」ことが品質の土台になっています。つまり、レビュワーの目利き力がそのまま成果物の品質に直結するわけです。

ところが、

  • AIが出してくる設計やコードは、もっともらしく見える
  • でも「これ、本当に運用に耐えるか?」「セキュリティ的に大丈夫か?」を見抜くには経験が要る
  • 若手だけだと「なんとなく良さそう」で通してしまいがち

という難しさがありました。AIが優秀になるほど、それを評価する側の力量が問われる——AI-DLCはレビュワーの実力を映す鏡のような側面があると感じました。

なので、可能なら経験のあるシニアエンジニアを1人レビュワーとして入れると、AI-DLCの効果がぐっと上がりそうです。逆に若手チームの場合は、これを「シニアの視点を学ぶ場」と捉えると学習効果が高いとも思いました。

3. Inceptionフェーズの選択肢が広く、技術スタックの偏りが響く

Inception(構想)フェーズでは、開発手法や使用する技術を幅広い選択肢の中から選んでいくことになります。AIは「こういう選択肢がありますよ」と提示してくれますが、最終的にどれを選ぶかは人間の判断です。

ここで効いてきたのが、チームメンバーの技術スタックの偏りでした。(メンバーは某AWSユーザーコミュニティを中心に集めたので...)

  • AIは複数の選択肢を出してくれる
  • でも、自分たちが知らない技術は「これが最適かどうか」を判断できない
  • 結果、よく知っている技術に引っ張られて選んでしまう

最適な選択をするには、選択肢を正しく評価できるだけの幅広い知識がチームに必要です。Inceptionは上流フェーズなので、ここでの選択ミスは後工程すべてに響いてきます。「AIが選択肢をくれる」≠「最適な選択ができる」というのは、痛感したポイントでした。

Inceptionフェーズの前に、チームでざっと技術選択肢を洗い出して目線を合わせておくと、AIの提案をより活かせそうです。AIに「それぞれの選択肢のメリット・デメリットを比較して」と聞くのも有効かもしれません。

レビューのコスト増加について

「人間のレビューがボトルネックになる」という体験は、私たちのチームだけの特殊な話ではなくて、すでに一般論として普及しているようでして。以下のような論文も出ていました。

こちらの論文はMITのChristian Catalini氏らが2026年2月に公開した論文 "Some Simple Economics of AGI" で、まさに同じ構造が経済学の視点から論じられていました。

この論文の主張をざっくり言うと、こうです。

AIは「実行(execution)」のコストをほぼゼロまで下げる。
しかし、その出力が本当に正しいかを「検証(verify)」するコストは、人間の時間に縛られていて下がらない。

論文では、

  • 実行コスト(Cost to Automate) … 計算資源と知識の蓄積で、指数関数的に下がっていく
  • 検証コスト(Cost to Verify) … 人間の時間や経験という「生物学的なボトルネック」に縛られ、簡単には下がらない

この2つの差を「Measurability Gap(測定可能性のギャップ)」と呼び、AIが速くなるほどこのギャップは広がると指摘しています。

つまり、

成長を縛る制約は、もはや「知能(AIの賢さ)」ではなく「人間の検証帯域(human verification bandwidth)」である

というのが論文の核心メッセージです。さらに、現在の「human-in-the-loop(人間が確認しながら進める)」という心地よい状態は、放っておくと崩れていく不安定なものだと論じています。

image.png

この論文で語られていることを上の図に示しているので参考にしてみてください。
横軸が右にいくほど AIが進化し、検証しきれないギャップ(Measurability Gap)が広がっていく状態です。そのときに何が起きるか、2つのパターンを比べています。

  • 🔴 赤の線(レビューそのまま):人間がレビュー量を変えずにいると、AIが進化するほど品質・意図への忠実さ(アラインメント)はどんどん崩れていく
  • 🟢 緑の線(レビューを増やす):AIの進化に合わせて人間の監視・レビューを増やしていくと、品質を高いまま保てる

赤と緑の差(紫の矢印)が、まさに「人間がレビューを増やすことで初めて守れる品質」です。AIが速くなったぶん、人間が手を抜くと品質はむしろ下がる——図にすると、この構造がはっきり見えてきます。

これを読んで、ハッカソンでの「AIはどんどん作るのに、レビューが追いつかず人間が詰まる」という体験が、ふわっとした感想ではなく構造的に起きるべくして起きていた現象だったと気づけました。私たちが感じた「レビューがボトルネック」は、まさにこの赤い線をたどりかけていた状態だったのだと思います。

AIを使った開発は、「全工程が一律に速くなる」わけではありません。実行(作る)工程は速くなる一方で、検証(レビュー・判断)工程はむしろ相対的に重くなり、場合によってはチーム全体のタスク量が増えることすらあります。AI-DLCに限らず、AIを利用した開発手法を導入するなら、この「検証側のコスト」を最初から見込んでおくことが大切だと感じました。

さいごに

AI-DLCを実際にチームでやってみて、一番の収穫は

AIが速くなるほど、人間側(レビュー・判断・技術的な引き出し)の重要性がむしろ増す

ということに気づけたことでした。

「AIに任せれば開発が速くなる」というのは半分正解で、半分は誤解だと思います。AIが生成する部分は確かに速くなりますが、それを評価し、判断し、責任を持つのは最後まで人間です。MITの論文が言うように、AIが速くなるほど「検証」という人間の仕事はむしろ重みを増します。AI-DLCは、その役割分担を実際の開発現場で明確に突きつけてくる手法だと感じました。

開発初心者の私にとっては、「AIに何を任せ、自分は何を磨くべきか」を考える良いきっかけになりました。これから試す方は、ぜひレビュー体制とチームの技術的な引き出しを意識して臨んでみてください。

参考

6
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
6
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?