AIが主に書く開発の進め方とは？｜受け入れ基準を先に決める

「実装は驚くほど速くなったのに、使えるようになるまでの期間はほとんど変わっていません」「出てきたものが正しいかどうかを確かめる人が足りず、そこで列ができています」。自社に開発部門がある会社からも、外部に発注している部門からも、同じ形の話が届きます。ここで疑うべきは道具の性能ではありません。工程のどこが一番遅いかが入れ替わったのに、工程の並びが昔のままだから起きています。要件、設計、実装、試験という順番は、人が手で書く前提で組まれたものです。書く工程が最速になれば、詰まる場所は必ずその先へ移ります。この記事では、進め方がどう組み替わるのか、提唱されている方法論の中身、3つの進め方の選び方、そして外注の仕様書がどう変わるのかを整理します。

何が入れ替わったのか。実装が最も速い工程になった

従来の工程の並びには、はっきりした前提がありました。実装が最も時間のかかる工程だという前提です。だから要件を固め、設計を固め、そこから長い実装に入り、最後に試験をする。手戻りを避けるために前半を厚くするのは、後半が高いからです。この並びは、実装が高いあいだは合理的でした。

その前提が崩れました。2025年に公表された大規模な調査では、開発者のおよそ9割が日常的にAIを使っていると報告されています。技術者およそ5,000名の回答と100時間を超える聞き取りに基づくもので、補完、対話による問題解決、コードの提案が日常に組み込まれているという整理です。書く作業の単価が下がると、工程の中で最も高い場所が移動します。移動した先は、出てきたものが要求どおりかを判断する工程です。

同じ調査の中心的な発見は、AIが増幅装置だというものでした。組織がもともと持っている強みと弱みを、そのまま拡大する。この整理に沿って言えば、受け入れの基準が曖昧な組織は、曖昧なまま大量に作るようになります。速さだけが伸びて安定が伴わなければ、それは加速した混乱にすぎない、という指摘も添えられています。工程を組み替える理由は、速くするためではなく、増えた出力を受け止められるようにするためです。

用語のミニ解説。この記事に出てくる言葉

工程の組み替えを話す前に、呼び方を決めておきます。同じ作業が、作る側では設計、業務の側では仕様の相談と呼ばれ、どちらが決めるのかが曖昧になるためです。以降は、誰が決める工程なのかが分かる言い方に統一します。

• AI-DLC（AI駆動開発ライフサイクル）……AIが実装の大半を担う前提で、開発の工程そのものを組み直す進め方に付けられた呼び名。特定の製品を指す言葉ではない
• インテント（意図）……「申し込みの受付機能を足す」といった、業務の側から見た高い水準の目標。手段ではなく目的を書く
• ユニット・オブ・ワーク（作業単位）……意図を実現するために分割した小さな作業のかたまり。従来の大きな要求項目より1段細かい
• ボルト（短い反復の単位）……数時間から数日で1周する作業サイクル。従来の1週間から4週間の反復より桁が1つ短い
• モブ（全員で同時に決める場）……関係者が同時に同じ画面を見て、その場で判断していく進め方。持ち帰りを前提にしない
• 受け入れ基準（合格の条件）……何が満たされていれば完成とみなすかを、確認できる形で書いたもの。この記事の主題にあたる言葉

この中で実務上いちばん重要なのは、最後の受け入れ基準です。他の言葉は方法論の中の用語ですが、受け入れ基準はどの進め方を選んでも必要になります。方法論を採用しない会社でも、この1つだけは先に整えておく価値があります。

提唱元と時期。どこが何を言い出したのか

AI-DLC は、大手クラウド事業者であるアマゾン・ウェブ・サービスが、2025年7月31日に自社の開発者向け技術ブログで公開した記事で提唱した進め方です。著者は同社の技術者で、日本語では「AI駆動開発ライフサイクル」と訳されます。特定の製品名ではなく、開発の工程の組み方に付けられた名前です。

その後の動きを時系列で整理すると、2025年11月に進行の手順を定義した内容がオープンソースとして公開され、同年12月の年次イベントのセッションで紹介されました。さらに2026年6月には作り直した版が試用向けに公開され、進行の再現性を高める仕組みと、複数のコーディング支援ツールへの対応が加わったと紹介されています。1年ほどで版が変わっている領域なので、社内資料に写すときは参照した時点を書き添えてください。

提唱側の記事が挙げている問題意識は、計画や会議といった中核でない活動に時間が消えているというものです。そのうえで、AIを補助として付け足すだけでは能力を制約し、古い非効率をかえって強化してしまうと述べています。だからAIを補助ではなく中心的な協働者として置き直す、というのが主張の骨格です。なお、この記事は提唱する側の文書であり、うまくいかない場合や組織的な障壁については触れられていません。

3つの段階。構想・構築・運用で何が変わるのか

提唱されている進め方は、大きく3つの段階に分かれます。構想、構築、運用です。名前だけを見ると従来の工程と似ていますが、各段階で誰が何をするかが入れ替わっています。

1. 構想：業務の側から出てきた意図を、要件と作業単位まで具体化する段階。AIが問いを立てて不足を指摘し、関係者が同時に集まってその場で答えていく形が想定されている
2. 構築：どう作るかを決めて実行する段階。AIが論理的な構成、業務領域の模型、コード、試験を提案し、人はその場で技術的な選択を明確にしていく
3. 運用：基盤の記述と展開をAIが担い、人が監督する段階。前の2段階で蓄積された文脈をそのまま引き継いで使う

従来との違いを一言でまとめると、作業の主体が入れ替わっています。人が主導してAIが補助する形から、AIが実行して人が判断する形へ。この入れ替わりに合わせて、会議の役割も変わります。従来の会議は、持ち帰った作業の報告と承認の場でした。この進め方では、関係者が同時に画面を見てその場で決めていく共同作業の場になります。

会議の役割が変わる点は、日本の会社では最も抵抗が出る部分です。持ち帰って部内で調整してから答える、という手順を挟めなくなるからです。関係者を同時に集められない組織では、この進め方の速さは出ません。逆に言えば、集められるかどうかが採否の判断材料になります。技術の問題ではなく、会議体の設計の問題です。

週の単位から時間の単位へ。反復の刻みが変わる意味

この進め方でよく取り上げられるのが、反復の単位です。従来の短い反復は1週間から4週間で1周するのが一般的でした。提唱されている単位は数時間から数日で、桁が1つ違います。呼び名も別のものが当てられ、大きな要求項目に相当する言葉も、より小さな作業単位に置き換わっています。

刻みを短くすることの実務上の意味は、速さではありません。間違いに気づくまでの時間を短くすることです。2週間分をまとめて作ってから確認すると、方向が違っていた場合に2週間分がやり直しになります。半日分なら半日で済みます。書く工程が安くなったからこそ、この刻み方が現実的になりました。

ただし、刻みを短くすると確認の回数が増えます。半日ごとに判断を求められる状態は、判断する側にとってかなりの負荷です。実際、この進め方の課題として、判断の頻度が上がることによる消耗が指摘されています。刻みを短くする前に、誰が判断するのかと、その人の時間をどれだけ空けるのかを決めておく必要があります。ここを決めずに始めると、判断待ちの列が半日ごとにできます。

詰まる場所が動く。速くなった分だけ判断の列が伸びる

工程を組み替える理由は、ここに集約されます。ある工程の処理速度が上がると、そこで溜まっていた仕事が次の工程へ一気に流れ込みます。実装が10倍速くなれば、確認を待つものが10倍の速さで積み上がる。全体の所要時間は、最も遅い工程で決まります。実装が最速になった以上、全体を決めているのは受け入れの工程です。

受け入れが詰まる理由は3つあります。1つ目は、何をもって合格とするかが書かれておらず、確認する人が毎回考えているから。2つ目は、確認できる人が特定の少数に偏っているから。3つ目は、出てきた量が人が読める量を超えているからです。3つとも、実装の速さを上げても改善しません。

先ほどの調査でも、AIはレビューを置き換えるのではなく、レビューの重要性を上げると整理されています。手順が弱く、優先順位が不明確で、古い構造を抱えたままの組織は、質の低いものをより速く出すだけになる。速さが増幅されるのは、良い仕組みだけではありません。組み替えの目的は、増えた出力を受け止める側を先に作ることです。

受け入れ基準を先に決めるとは、何を先に決めることか

受け入れ基準を先に決めると言うと、要求仕様を詳しく書くことだと受け取られがちです。実際に決めるのはそこではありません。決めるのは、何が満たされていれば完成とみなすかを、確認できる形で書いた条件です。作るものの説明ではなく、合格の判定方法を書きます。

この5つを書く作業は、AIに下書きさせることができます。ただし3番目の合格条件と5番目の判定者は、必ず人が確定させます。合格条件は業務側の重みが入るため外部の情報だけでは決まらず、判定者は責任の所在そのものだからです。下書きを受け取ってから、この2つだけを人が書き直す、という形が実務では回ります。

試験の位置が前に出る。動いたかではなく、満たしたかで見る

受け入れ基準を先に決めると、試験の位置も自然に前へ出ます。従来、試験は作り終えてから行う確認作業でした。この並びでは、試験は合格条件を機械が確認できる形に翻訳したものになり、作る前に用意されます。作る側は、その試験を通す形で作ることになります。

提唱側の記事では、この進め方でAIが包括的な試験一式を提示すると述べられています。ここに実務上の注意が1つあります。作った本人が試験も書くと、作った前提の試験になりやすいという点です。人が書いても機械が書いても同じ性質があり、合格条件そのものは、作り始める前に別の人が確定させておくのが安全です。

もう1つの注意は、試験が通ったことと要求が満たされたことは別だという点です。試験は書かれた条件しか確かめません。書かれていない前提、たとえば運用時間帯の制約や、他部門の業務との整合は、試験には現れません。だから受け入れの場では、試験の結果と、業務側の目的に照らした確認の2つを見ます。前者は自動で、後者は人が担当します。

進め方その1：人が書く前提の従来型。いまも有効な条件

3つの進め方を並べます。1つ目は、従来型です。要件を固め、設計を固め、人が実装し、最後に試験する。AIは補助として部分的に使います。この形が古いから捨てるべきだ、という話にはなりません。条件が合えば、いまも最も予測しやすい進め方です。

有効なのは、次の条件がそろっているときです。作るものの正解が事前に確定していて変わらない、関係者を同時に集めることが難しい、暗黙知が多く言語化に時間がかかる、そして規制や監査で工程の記録の形が決まっている。特に最後の条件は無視できません。工程ごとの成果物と承認の記録が求められる領域では、進め方の変更自体が調整対象になります。

弱点も明確です。前半で決めたことが後半で変わったときに、やり直しの範囲が大きくなります。また、実装の工程が長いため、実際に動くものを見るまでの時間が長い。見てから気づく種類の要求が多い案件では、この弱点が致命的になります。逆に、見なくても決められる案件では弱点になりません。

進め方その2：AIに実装を任せる型。前提と落とし穴

2つ目は、実装の大半をAIに任せる形です。人は意図を渡し、作業単位に割り、提案を確認し、合格を判定します。短い反復で回し、関係者は同時に集まって決めます。この形が機能する前提は3つあります。関係者を同時に集められること、合格条件を書けること、そして前提となる情報が文書として整備されていることです。

落とし穴は、この3つの前提が満たされていない状態で速さだけを期待して始めることです。特に多いのが、合格条件を書けないまま始める場合です。合格条件が無いと、確認は「なんとなく違う」という感想の応酬になり、作り直しが増えます。実装が速いので作り直しは可能ですが、判断の回数だけが増え続け、判断する人が消耗します。

• 文脈の長さには制限がある。全体の事情を一度に把握させられないため、決めた内容はその都度、参照できる場所に残す
• 誤った提案が出る前提で、成果物ごとの承認の流れを先に決めておく。承認せずに次へ進める経路を作らない
• 設計の判断が会話の中に散らばると、後から追えなくなる。決めたことは会話ではなく文書側に落とす
• 若手が手を動かして学ぶ機会が減るという指摘がある。読む側の訓練をどこで積ませるかを別に設計する
• 分散したチームでは、同時に集まる形が成立しにくい。時間帯を固定した短い枠を先に確保しておく

実際の効果については、提唱側の年次イベントで10倍から15倍という生産性向上が主張されています。ただしこれは提唱する側の主張であり、第三者による検証を経た数字ではありません。国内でも、ある金融系のシステム会社が2日間の合宿形式で試した例では、4チームが動く初版まで到達し、通常なら数週間かかる作業を1日半ほどで形にしたと紹介されています。いずれも条件を整えた検証の場での結果で、日常の開発に同じ比率が出るとは限りません。

進め方その3：部分的に混ぜる型。多くの会社の現実解

3つ目は、工程の一部だけをAI中心に切り替える形です。全体の枠組みは従来型を残しつつ、作業単位に分けられる範囲でだけ短い反復を回します。多くの会社にとって、これが現実的な出発点になります。

混ぜ方には順番があります。まず、外部と接続せず、業務データを扱わず、失敗しても影響が閉じている範囲から始めます。社内向けの補助的な仕組み、既存機能の置き換え、試験用の道具などです。ここで合格条件を書く練習と、判断の回数に耐える体制の確認を済ませてから、範囲を広げます。いきなり基幹に近い部分から始めると、判断の負荷と失敗の影響が同時に来ます。

混ぜる型で失敗しやすいのは、範囲の境目を決めないまま始める場合です。どこまでがAI中心で、どこからが従来型なのかが曖昧だと、成果物の形式も承認の流れも案件ごとにばらばらになります。境目は工程ではなく、対象で引くほうが実務では管理しやすくなります。この仕組みは新しい形、この仕組みは従来型、という分け方です。

3つを同じ表で比べる。どの条件でどれを選ぶか

3つの進め方を、同じ軸で並べます。選ぶ基準は好みではなく、自社の条件がどれに当てはまるかです。

見る軸	従来型	AIに実装を任せる型	部分的に混ぜる型
合格条件を書けるか	後から詰めても進む	書けることが前提	対象を選べば書ける
関係者を同時に集められるか	不要	必要	限られた範囲で必要
前提情報の整備	作りながら整えられる	着手前に整っている必要がある	対象範囲だけ整えればよい
判断の頻度	低い。工程の節目のみ	高い。半日から数日ごと	中程度
やり直しの範囲	大きい	小さい	対象範囲に限られる
工程の記録の形	従来の様式のまま使える	様式を作り直す必要がある	併存させる必要がある
向いている案件	正解が確定し変わらない	見て決める要素が多い	初めて試す段階

表を読むときの要点は、上から3行がそろわない限り、2列目は選べないということです。合格条件が書けず、関係者を集められず、前提情報も整っていない状態で実装だけをAIに任せると、確認の列が伸びるだけで全体は速くなりません。この3行は、始める前に自社で確かめられます。

速くなる工程と、速くならない工程を分ける

この記事でいちばん誤解が起きやすいのがここです。速くなるのは書く工程だけです。決める工程は速くなりません。両者を混ぜたまま日程を組むと、速くなる前提で引いた線が守れなくなります。

工程	速くなるか	理由
下書きの作成	大きく速くなる	量が多く、判断の幅が狭い作業
定型的な組み替え	速くなる	既存の形を参照して機械的に置き換えられる
試験の記述	速くなる	合格条件が書かれていれば翻訳作業になる
文書の整備	速くなる	決まった内容を形式に落とす作業
合格条件を決める	速くならない	業務側の重み付けが必要で、外の情報では決まらない
関係部署の合意	速くならない	会議体と決裁の回数が制約になる
責任の所在を決める	速くならない	誰が判定するかは組織の判断であり委譲できない
業務の受け入れ確認	速くならない	実際の業務に照らす作業で、人の時間がそのまま必要

下4行が、日程の骨です。合意形成に2週間かかる組織では、実装が半日で終わっても、次の版が出るまでに2週間かかります。だから工程を組み替えるときは、この4行を先に工程表へ置き、その隙間に書く工程を配置します。逆の順で組むと、速くなった工程が待ち時間を生むだけになります。

レビューが追いつかない問題。人が読む範囲を先に決める

実務で最初に表面化するのが、確認が追いつかない問題です。出てくる量が増えるので、全部を人が読む形は成立しません。だからと言って読まないわけにもいかない。ここで必要なのは、読む範囲を先に決めておくことです。全部読むか読まないかではなく、どこは必ず読むかを決めます。

必ず読む範囲の決め方には、実務で使われている基準があります。外部と接続する部分、権限や認証に関わる部分、業務データを書き換える部分、金額や日付の計算を含む部分。この4つは、間違えたときの影響が大きく、試験でも見つけにくい性質があります。それ以外は、試験の結果と抜き取りの確認で扱います。

抜き取りの確認にも条件を付けます。読まなかった範囲から定期的に無作為に選んで読むことです。読む範囲を固定すると、その外側で何が起きているかに永久に気づけません。月に1回、対象外の中から数件を選んで読む手順を入れておきます。ここで問題が見つかったら、読む範囲の定義そのものを見直します。

外注の仕様書がどう変わるか

外部に発注している場合、仕様書の重心が移ります。従来の仕様書は、作るものの説明と成果物の一覧が中心でした。実装の工数が見積もりの根拠だったからです。実装が安くなると、その根拠が薄くなり、見積もりの根拠は受け入れの条件と、判断を誰が持つかに移ります。

具体的に足す項目は4つです。合格条件を誰が書くのか、判定は誰が行うのか、AIが出したものをそのまま納品してよいのか、そして生成に使った道具と入力した情報の扱いです。特に3つ目は、書いていないと後で揉めます。中身を人が読んで理解しているかどうかで、引き渡し後に直せるかが決まるからです。

• 成果物の一覧だけを書いて発注する——実装が安くなった分、何をもって完成とするかが曖昧なまま進む
• 合格条件を制作側に書かせて、そのまま承認する——判定の基準を相手が決める形になり、後から異議を出せなくなる
• 判定者を役職で書く——実際に見る人が決まらず、承認の署名だけが回る
• 生成に使った道具と入力情報の扱いを書かない——業務データを外部へ渡していたことに後から気づく
• 中身を読める人が社内にいないまま引き取る——引き渡し後に直せず、同じ相手に頼み続けるしかなくなる
• 反復の刻みだけ短くして、判断する人の時間を確保しない——半日ごとに判断待ちの列ができる
• 検証の場で出た速さの比率を、そのまま日程の前提に置く——条件を整えた場の結果を日常に持ち込むことになる

並べてみると、共通点があります。どれも、決める仕事の置き場所を決めていないことから起きています。書く仕事の置き場所が変わったのだから、決める仕事の置き場所も書き直す必要がある。仕様書の組み替えとは、その置き場所を明文化する作業です。

発注時と着手前の確認表

最後に、始める前に確かめる項目をまとめます。社内で進める場合も、外部に発注する場合も、確認する内容はほぼ同じです。ここが埋まらない項目が残っているなら、進め方を切り替える時期ではありません。

• この機能が何のためのものかを、業務側の言葉で1文にできている
• 合格の条件が、確認できる文で並んでいる。速い、使いやすい、といった形容詞で書かれていない
• 合格を判定する人が、役職ではなく名前で決まっている
• 今回やらないことが明記されている
• 必ず人が読む範囲が決まっている。外部接続、権限、業務データの書き換え、金額と日付の計算
• 読まない範囲から抜き取って確認する頻度が決まっている
• 判断する人の時間が、反復の刻みに合わせて確保されている
• AIに入力してよい情報の範囲が決まっている。業務データと取引先の情報の扱いが書かれている
• 引き渡し後に中身を読んで直せる人が、社内または継続的な委託先にいる
• 工程の記録の形が、監査や規制の要求と食い違っていない

この10項目のうち、2番目と3番目が埋まらないなら、進め方を変えるより先にそこを埋めます。合格条件と判定者が決まっていない状態は、実装が速くなればなるほど損失が大きくなります。作れる量が増えるほど、行き先の無い成果物が増えるからです。

まとめ

AIが実装の大半を書けるようになると、工程の前提が変わります。要件、設計、実装、試験という並びは、実装が最も高い工程だという前提で組まれたものでした。実装が最も速い工程になった以上、詰まる場所は受け入れの判断へ移ります。全体の所要時間は最も遅い工程で決まるので、実装を速くしても全体は速くなりません。

提唱されている進め方は、大手クラウド事業者が2025年7月31日に技術ブログで公開したもので、日本語ではAI駆動開発ライフサイクルと訳されます。構想、構築、運用の3段階を、数時間から数日という短い反復で回し、AIが実行して人が判断する形に置き換えます。ただしこれは、関係者を同時に集められること、合格条件を書けること、前提情報が整っていることを条件にした形です。この3つが欠けたまま実装だけを任せると、確認の列が伸びるだけになります。

実務では、対象を選んで部分的に混ぜる形から始めるのが現実的です。外部と接続せず業務データを扱わない範囲で、合格条件を書く練習と、判断の回数に耐えられるかの確認を済ませてから広げます。そして忘れてはいけないのは、速くなるのは書く工程だけだということです。合格条件を決める、関係部署の合意を取る、責任の所在を決める、業務に照らして受け入れる。この4つは速くなりません。工程表はこの4つから先に置き、その隙間に書く工程を配置する。受け入れ基準を先に決めるとは、この順番で組み直すことそのものです。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。