AI-DLCで業務改善はどう進む？全体の流れを解説

AI-DLCは、AIが計画・設計・作成を進め、人が重要な判断を担うソフトウェア開発の方法です。業務改善では、現場の希望を機能に変え、仕事に取り入れるために使います。

AI-DLCは、AWSが提唱するAI-Driven Development Life Cycleの略称です。AIが次にする作業や確認点を提案し、曖昧なところを人に質問するのが特徴です。

業務担当者が「何に困り、どうなれば助かるか」を伝え、AIが機能や作業の案に変えます。開発・運用担当者は、プログラムや利用環境を確かめます。非エンジニアも、仕事のルールを説明し、実際の画面で使い勝手を確認する役割を担えます。

最初に調べるのは、誰が、どこで困り、なぜ仕事が止まるかです。AIに手順や記録を整理してもらい、実際の仕事と照らして改善する対象を絞ります。

ここからは、説明用の架空例として、申請の差し戻しが多い職場を考えます。「空欄をなくしたい」という要望だけなら、申請画面の項目を一律で必須にする案が浮かびます。ただ、同じ空欄でも、理由が違えば対策も変わります。

聞き取りでは「どんな機能がほしいですか」に加え、「最近戻った申請は、どこを直しましたか」「その情報は、申請時点で分かりましたか」と尋ねます。承認側にも戻した理由を確かめると、要望の背後にある原因を検討できます。これは原因を切り分けるための質問例です。

記録は会社の情報管理ルールに沿って扱います。解決方法は、既存システムの設定変更や市販サービスも含めて検討します。新たな開発や改修が必要なら、業務責任者と開発担当者が対象を決め、改善前の作業時間や差し戻し理由を残します。

AIの案をたたき台に、必要な機能と「何ができれば完成か」を決めます。使う人と確認する人の事情をそろえ、曖昧な希望を、動作を確かめられる条件に変えます。

システムが満たすべき条件を「要件」と呼びます。申請の例では、申請側は「金額が未定でも相談したい」、承認側は「金額が分からなければ購入を認められない」と考えたとします。どちらにも理由があります。

この場合、金額を必須にすると相談を始められず、任意にすると購入承認に必要な情報が欠けます。そこで「見積もりの相談」と「購入の承認」を分ける案を考えます。前者は未定で受け付け、後者は金額を確定してから進める、という条件です。

期限を過ぎても金額が未確認なら、担当者が追えるようにします。この扱いに申請側と承認側が合意して初めて、画面や処理へ落とし込めます。

開発担当者は、利用者ごとの権限や既存システムとの接続を確かめます。今回作る機能、対象外の機能、完成の条件をそろえ、AIの作業計画を調整します。

AIが設計案やプログラム、テストを作り、人が内容と動作を確かめます。業務担当者は実際の仕事の順番で画面を使い、開発担当者は技術面の品質を点検します。

設計は、画面の操作、保存する情報、処理の順番を決める作業です。AIが作った案を基に、業務側と開発側が「使う人が迷わないか」「データを安全に扱えるか」を話し合い、作成へ進みます。

申請画面なら、「金額のある購入申請は進める」「金額のない購入申請は止める」「担当者と期限のある未定の相談は受け付ける」を試します。通るべきものと、止めるべきものの両方を、先ほど合意した条件に照らします。

この報告から本記事では、試す画面を用意することに加え、「誰が何を見て判断するか」も先に決める必要があると考えます。申請者は入力のしやすさ、承認者は判断材料の十分さ、開発担当者は動作と権限を確かめます。

必要な機能が動き、確認結果がそろったら、現場で仕事を回す準備へ進みます。見た目の完成と、実際の利用に必要な確認を分けて扱います。

新しい仕組みで、入力・確認・やり直しの流れを変えます。申請の例では、入力漏れに本人が送信前に気づけるようにし、担当者が差し戻す手間を減らすことを目指します。

使う人に渡すのは、日々の作業に必要な画面と手順です。たとえば申請者が「相談か購入か」を選べば、必要な欄が分かる形にします。開発の工程や設定を毎回理解しなくても、仕事を進められる入口を作ります。

同時に、以前のメールや紙の手順をどこで終えるかを決めます。新しい画面への入力に加えて、以前の申請も続けるなら、二重の作業になります。未定の相談は誰が追い、期限を過ぎたらどうするかまで含め、一部の業務で最後まで試します。

開発・運用担当者は、権限、データの保護、不具合の検知、復旧方法を整えます。「変更してはいけない」とAIに指示することと、権限のない変更をシステム側で拒否することは別です。必要な制限が、実際の利用環境で働くかを確認します。

AWSが公開した富士通のAI-DLC体験レポートでも、稼働基盤を作り、利用できる状態にするには知識と経験が必要だと報告されています。AIに作成を任せる範囲が広がっても、利用環境を整える判断は残ります。

最初に記録した作業時間や差し戻しと、導入後の結果を比べます。開発が速く終わっても、毎日の仕事が楽になったかは、使った結果から判断します。

たとえば、同じ種類の申請について、導入前後の入力・確認・やり直しの時間を記録します。申請件数が変わると総時間だけでは比べにくいため、申請当たりの時間と件数を併せて見ます。

利用者から「まだ使いにくい」と言われたら、どの操作で止まったかを確かめます。入力位置が分からないなら画面、未定案件が進まないなら受付条件、確認を頼んでも返事が来ないなら担当や連絡の手順を見直します。AIは、記録から原因の候補と修正案を整理できます。

直す際には、「未定の相談も、期限を過ぎると一覧から追えなくなった」といった困る状況を、説明用のデータで再現します。修正後は、その状況が解消し、通常の申請も進むかを確かめます。実際の不具合が見つかったときに、同じ問題を再確認できる形へ残す考え方です。

残すのは、動く仕組みに加え、なぜその条件にしたか、何を試したか、変更時に誰が確かめるかです。判断と検査を残すことで、担当者が替わっても、次の改善を始めやすくなります。

AIが一般的な案を出せても、自社で通用する条件は、現場で確かめて残す必要があります。たとえば「未定の相談は受けるが、購入は承認しない」という理由と検査が残れば、次の画面変更でもその条件を守れます。こうした蓄積が、変更の速さや品質につながるかを確かめていきます。

社内だけで進められる？　相談が役立つのはどこ？

業務の判断、開発、運用を担う人が揃い、条件を決めて検証できるなら、社内で進められます。一方、部署間で完成の条件が決まらない、試作品から利用へ進めない、直すたびに別の問題が出る場合は、その原因を整理できる支援者に相談する余地があります。

相談先には、何を残してもらう？

相談先には、画面や資料に加え、合意した業務条件、採用・不採用の理由、確かめる入力と期待結果、変更と引き継ぎの手順を求めます。支援後に、自社の担当者が条件を一つ変え、影響を調べて試せるか。そこまでを、支援の成果として話し合うことができます。

ビジョン・コンサルティング（VC）への相談も、「AIで何か作りたい」から始められます。その際、困った仕事の具体例と、「どこまで自社で判断・変更できるようになりたいか」を共有すると、必要な支援を絞りやすくなります。

最初から完成形を描く必要はありません。まずは、繰り返し戻ってくる申請を一つ取り上げ、どこで困り、何が分かれば進められるかを確かめる。その答えをAIと形にし、仕事で試し、分かったことを次に残す。AI-DLCは、その改善を進めるために活用できます。

AI-DLCの定義と開発の進め方は、AWSおよびAWS Labsの公開資料に基づきます。業務改善への当てはめ方、判断理由、知見の残し方は本記事の考察です。申請業務の状況・発言・条件は説明用の架空例で、特定案件の再現や導入実績ではありません。

1. AWS：AI駆動開発ライフサイクルの基本 — 公開日：2025-08-08。AI-DLCの定義と、AIが計画・作成を進め、人が判断する仕組みの根拠。
2. AWS：案件に応じて変わるAI-DLCの進め方 — 公開日：2025-11-29。開発用AIツールでの進め方、要件・計画の引き継ぎ、案件に応じた工程の調整を確認。
3. AWS：富士通のAI-DLC体験と技術面の学び — 公開日：2026-04-20。富士通が参加した開発体験の報告。システムの稼働基盤の構築や利用環境の準備に必要な知識・経験の根拠。
4. AWS Labs：AI-DLC Workflowsの工程と成果物 — 2026年9月14日確認。要件・設計・作成・検証・運用の関係を確認。更新される公開実装であり、本文の5段階と同じ工程区分ではありません。
5. AWS：AstemoのAI駆動開発体験と学び — 公開日：2026-07-28。試作画面による認識合わせと、人の意思決定が進行を妨げた場面を確認。開発体験の報告と、そこからの本記事の考察を分けて記載。

情報確認日：2026年9月14日。本文の5段階は、業務改善とのつながりを示す編集上の整理です。公開された開発体験と本記事の考察を区別し、試作や設計上の提案を、本番業務の成果として扱っていません。