これからはAIが主導し、人が支える。
AI-DLC（AI Development Life Cycle：AI 駆動開発ライフサイクル）で変わる仕事

第1章 なぜ「AIと私」だけでは足りないのか

一人だけ速くなっても、チーム全体は変わらない

生成AIを使えば一人ひとりの仕事は格段に速くなります。実際に資料作成や情報整理、コード生成など、すでに個人の作業効率を高める場面は数多く生まれています。

しかし、企業の仕事は一人で完結するものばかりではありません。ソフトウェア開発ではプロダクトマネージャーが企画し、デザイナーが設計し、エンジニアが開発し、運用担当へ引き継ぐというようにさまざまなメンバーが連携しています。

一人だけが速くなっても全体の流れを左右するボトルネック、いわゆるクリティカルパスが残っていたらチーム全体の生産性は大きく変わりません。

個人最適の集合では変革は起きない

私が「個人でAIを使うこと」と「チームでAIを使うこと」の違いとして着目しているのは「チームの働き方に変革が起きるのか」という点です。

ジェネラティブエージェンツでもそれぞれのメンバーがAIを活用し、それぞれの持ち場で生産性の向上を実感する場面は多くありました。一方、各自が「AIと自分」という関係の中で最適化を進めてもチーム全体が同じ方向を見るとは限りません。「この事業をどう伸ばすのか」「チームとして何を目指すのか」という問いにチームが同じ答えを持っていることが大事です。

これから求められるのは、単に仕事を速くこなすことではなく、チームとして高い作業品質を実現すること。個々の効率化を積み上げるだけでは、その領域に達することはできません。

注目すべきは、AIとチームの連携

だからこそ、AI活用では「AIと自分だけのやりとり」の関係にとどまっていては不十分だと考えています。重要なのはAIを使って自分の作業を楽にすることに加え、チーム全体の運用方法を効率化すること。

AIを起点に協働して仕事の流れを再設計することをGAでは 「初手AI」 と呼んでいます。企画から開発、運用までを分断したまま部分最適を積み上げるのではなく、川上から川下までをなめらかに繋いでチーム全体の品質と速度を引き上げていくのです。

第2章 「AI-DLC（AI Development Life Cycle：AI 駆動開発ライフサイクル）」とは

AI-DLCは「AIがリードする開発手法」

AI-DLCとは 「AIがリードして人間がレビュー・補完する、AI時代の新しいソフトウェア開発手法」 です。大切なのはAIを使うことよりも、AIがリードすることです。

多くの現場では今でも人間が主体となって仕事を進め、必要な場面のみAIを呼び出しています。しかし、それではAIは補助役にとどまってしまいます。

AI-DLCが目指しているのは、AIを便利な道具として部分的に使うことではなく、AIが開発プロセスを動かす状態。ここで言う開発プロセスとは、コードを書く工程だけではなく、企画、要件整理、設計、実装、検証といった一連の流れも含みます。

個々人がAIを使って作業を効率化することと開発の推進方法を変えることは似ているようで全く違う。AI-DLCはその差を明確にした上で、開発の主導権をAI側に移していきます。

人間がAIを使うのではない。AIが人間を導く

では、なぜその発想が有効なのでしょうか。それは人間中心の組織にAIを追加するだけでは限界があるからです。

人間が用事のある時だけAIを呼び出す構造では、AIは人間に従属する存在のままです。しかし、昨今のAIは適切なルールと前提条件のもとで動くと、人間よりも抜け漏れやミスが少なく24時間稼働し続けられます。

それなら 「人間がAIを使う」のではなく、「AIが動き続けて、関与すべき場面だけ人間が呼ばれる」 ほうが自然です。例えば、AIが仕事を進める中で「ここはあなたが判断すべきです」「この情報が不足しています」といった時だけ人間が登場するのです。

これからの働き方はそう変わっていくべきではないでしょうか。人間が全てを抱えながら部分的にAIに手伝ってもらうよりも理にかなっています。

AI中心に仕事を設計し直すことが競争力に

これは仕事の主従関係を組み替える話です。業界の競争が激化する中、他社や他チームがAIに仕事をリードさせて人間は必要な局面だけ関与する体制へ移っているとしたら、人間がAIを背負って走っていては勝てません。

さらに、AI中心で仕事を設計し直すことはスピードを上げるだけではありません。変革を推進するリーダーシップ、部門や役割を跨ぐコラボレーション、高い作業品質の実現まで含めて競争力の源泉になっていきます。

AIを業務の一部に組み込むのではなく、AIを中心に仕事の流れを再設計する。その思想があるからこそ、AI-DLCは単なるAI活用論では終わらないんです。何よりも、経営戦略や事業戦略まで網羅してAIを前提に組み直したほうが合理的に組織が成長できますよね。

第3章 PoCで止まる構造

AIを導入する場所を誤ると効果は出にくい

企業のAI導入がPoC（Proof of Concept：概念実証）で止まりやすい理由は、AIを導入する場所の見立てが甘いことです。これは「業務のどこをAIに置き換えられるのか」という前提から入り、部分最適に陥りやすいことが原因です。業務全体の流れが変わらなければ、大きな成果には繋がりません。

AIがそれほど効果を発揮しない箇所に実装して「効果がなかった」と結論づけてしまうケースも少なくない。便利にはなったけれど事業や組織に対するインパクトは限定的だった、と。

こうした失敗が起きやすいのは、現場ごとの小さなユースケースを積み上げるボトムアップ寄りのアプローチに偏っているからでもあります。

「AIの使い方に慣れること」と「AIの能力を最大限引き出すためのPoC」を混同しているかぎり、変革には至りません。

AI導入は業務変革という総合格闘技である

もう一つの理由は、AI導入を簡単に実現できるものと見なしていることです。AIを使って業務を変えることは、単に新しいツールを導入するレベルの話ではありません。「DX時代に難しかった業務変革を、AIだったら容易に実現できるだろう」と考えるのは適切ではありません。

前提として、AIができる業務範囲を見極めるための技術的理解が欠かせません。さらに、AIによってその業務のどこをレバレッジすべきかをシビアに判断するクリティカル・シンキングも求められます。

AI導入は単一の専門性で完結するものではなく、複数の能力が横断的に必要とされる 「総合格闘技」 としてイメージできます。

それでも「権限や予算、適切な人材配置がそこそこでも変革できるはずだ」と楽観視してしまいます。PoCで止まるのは、変革の難しさに対する見積もりが甘いことも原因です。

問うべきは「何を検証するのか」

PoCの設計にも大きなズレがあると感じています。本来、ここで行うべきことは仮説の検証ですが「AIエージェントが動くか」「自分たちで実装できるか」といった動作確認だけでは不十分です。

CADデータのような複雑な情報をどんなレベルで読み取れるのか、どの程度まで精度が達すれば実務に使えるのか、また、どの程度のエラーだったら人間がカバーできるのかといった仮説を予め立てること。そこを数値的に見極めると初めてPoCに意味が生まれます。

作り方自体を試行錯誤しているだけでは「とりあえず作ってみたレベル」のデモが量産されるだけで導入は進みません。何が動いたのかではなく、それによって何を検証できたのかを問うべきです。

第4章 AI-DLCで仕事を回す

人間は「意図」を担い、AIが実行する

AI-DLCで仕事を回す時、私の考える役割分担は明確で、AIが文章を書く、ソースコードを生成する、テストを作る、実行するといった実務の大半を担い、人間はそれらの根拠となる「意図」を担うべき です。

なぜこの仕事をやるのか、何を実現したいのか、どの条件を満たすべきなのか、どんな制約があるのか。そういった意図を徹底的に言語化し、AIの出力や振る舞いがそれに合っているのかを管理する。

AI-DLCは人間が細かな作業をAIに置き換えるための仕組みではありません。AIが仕事をリードする傍ら、人間が意図とレビュー判断に集中するための方法論ではないでしょうか。

AIをどう監督し、任せる範囲を広げるのか

ただし「AIエージェントに仕事を任せる」と言っても、最初から手放しで運用できるわけではありません。作っている最中やリリース直後、使い始めたばかりの段階では、人間とAIの間にまだ信頼がないからです。

まずはAIがやることを厳密にチェックする必要があります。どこにリスクがあり、どこを重点的に見るべきなのか。100回、1000回と運用して実績が積み上がる中で信頼が形成されてフィードバックを通じた改善が進んではじめて、人間の関与率を徐々に下げられるのです。

AI-DLCの運用も同様に、AIに丸投げしたり人間が全てをチェックしたりするのではなく、AIによる作業の信頼度を段階的に評価・調整していくこと が大事だとも考えています。

AIとチームを繋ぐ人が明暗を決める

では、AI-DLCを現場で回すには何が求められるのか。AIとチームの間を円滑にファシリテートできる存在ではないでしょうか。

現時点でのAIは作業をリードして大きく進展させる一方、人間のチームに入って全ての意思決定を仕切るのはまだ難しい。そこで、AIを上手に操れる人とチーム全体を繋ぐ仲介者が鍵となります。

また、AI-DLCが加速すると1つの仕事を大人数で抱えなくても良くなります。10人で回していた仕事が2〜3人の小さなチームで成立する場面も増えるでしょう。つまり、そこで浮いた人を余剰とみなさず、小さなチームを増やして新たな取り組みに再配置していくのです。

作業時間が減る分、人間には対話し、意思決定し、仕組みを改善する役割が求められます。AI-DLCをただの自動化で終わらせずチームの運用として機能させるにはそうした 実践的な協働と仕組みづくりやファシリテーションの設計 が欠かせません。

第5章 AI-DLCで仕事はどう変わるのか

MVPまでの時間感覚が変わる

AI-DLCが機能し始めると仕事の時間感覚が変わります。従来のソフトウェア開発では企画を立ててアジャイルで進め、2〜3スプリントを回してようやくMVP（Minimum Viable Product）の良し悪しが見えてくることがめずらしくありませんでした。

ところがAI-DLCを実践するとその一周の桁が変わります。数週間かかっていたものが1日、場合によっては数時間まで短縮される。 アイデアがあればMVPと呼べるものを数日で形にできるようになります。

小さな成功体験を積みやすくなるのは、この速度の変化が大きい。最小単位のプロジェクトで短いサイクルで試し、学び、次に臨めるようになります。

問いは「コラボレーションによる作業品質」

しかし、AI-DLCがもたらす変化は単なる高速化ではありません。

ソフトウェア開発の現場で起きるのは「量をこなす」「自動化する」ではなく、コラボレーションの中でどう高い作業品質を実現するのか という問いへのシフトです。

AIが仕事をリードし、人間は意図を与え、判断すべき局面で関与する。そうなると、これまで人間が多くの時間を使っていた作業よりも何を作るのか、どこまで求めるのか、誰が何を決めるのかといった対話や意思決定の比重が高くなっていきます。

AI-DLCが浸透した組織では速く作れること以上に、短いサイクルの中で質の高い判断と協働ができるのかが競争力になります。

ソフトウェア開発を起点に全業務へ波及

この変化は、ソフトウェア開発だけに閉じるものではありません。私はAI-DLC的なアイデアは法務、営業、人事のような一般業務にも波及していくと考えています。

理由は単純で、どの仕事にも必ず人間の意図があり、その意図を正しく実現するためのタスク分解や進行管理が必要だからです。この構造はソフトウェア開発と本質的には変わりません。

ポイントは、必ずしもエンジニアだけがそれを担うとは限らないこと。最初の導入や基盤整備には技術者が関わるとしても、業務を回す段階では意図とオーナーシップを持つ現場の人間が中心になります。

今後は、現場がAIを前提に仕事をし、専門人材が要所でのみ呼ばれるような働き方が広がっていくはずです。

AI-DLCに興味を持った方へのメッセージ

AI-DLCはツールではなく方法論です。「これさえやればいい」「これさえ使えばいい」というものではありません。考え方を体得して毎日トレーニングのように実践してこそ、この方法論が活かされます。

もう一つは、 自分の生産性さえ良ければいいという考え方をしていると、遅かれ早かれ仕事を失うリスクが高まる と思います。これからは会社やチーム、周りの仲間と、いかにコラボレーションして、品質の高い仕事をしていくのかにこだわるべきです。

当社ではすでにさまざまな研修メニューを提供しています。AI-DLCをチームで実践してみたい方には、実在のシステムに対してチームでコーディングツールやAI-DLCを活用しながら開発する「5週間の超実践的なトレーニング」として、 AIエンジニアリングマスター研修 の提供も開始しています。

すでに多くの企業の方々が参加しており、既存システムへ安全にコーディングエージェントを導入したり、AI-DLCを活用してAIがリードする新しい開発スタイルに挑戦したりすることで着実に実績を出しています。ぜひご参加ください。