AI-DLCは、AIが設計・プログラム作成・動作確認を進め、人が提案や結果を確認して判断する開発方法です。業務用AIの内製では、この進め方に現場が試して直せる環境を組み合わせ、繰り返し使える仕組みに育てます。
AIを使うだけでなく、自社の仕事に合うAIを作りたい
毎回、同じ条件をAIに説明している。試作はできても、担当者が替わると使い続けられない。小さな修正まで開発側に頼み、順番を待っている。こうした状態から、現場が改善を進められる内製の仕組みを考えます。
AIに仕事を頼むことと、業務用AIを作ること
業務用AIを内製すると、資料の選び方や回答の決まりを社内で管理し、繰り返し使えます。
ここでは、社内規程から返信案を作るAIを架空例として考えます。問い合わせのたびに、規程と注意事項をチャットへ貼る仕事が出発点です。
問い合わせに答える「業務用AI」と、そのプログラムや設定を作る「開発用AI」は別です。AI-DLCでは開発用AIが作業を進め、人が目的や必要な機能、採用する案を判断します。
前回の「AIエージェントで開発をうまく進めるには？」では、完成基準、社内知識、判断の理由をチームで共有することを扱いました。今回はそれを土台に、現場が作成・修正に参加できる内製の仕組みを考えます。
一度の返信案ではなく、担当者が替わっても同じ条件で使えるAIを社内に残します。
AI-DLCは、要件からテストまで条件を引き継ぐ
公開実装のAI-DLC Workflowsでは、AIが作業計画を提案し、不足する条件を質問します。人の確認・承認を挟みながら開発を進めます。
人が確認・承認した条件を要件や設計に残し、実装へ引き継ぎます。要件は「満たす条件」、設計は「実現する方法」、テストは「条件を満たしたかの確認」です。
- 要件 承認の案内を入れる 営業部の有効な規程を使い、必要な事前承認を案内する、と決めます。送信は人が行います。
- 設計 決めた条件を仕組みにする 部署と有効日で規程を選び、承認条件を返信案へ入れる処理を設計します。
- テスト 承認の案内が出るかを確かめる 架空の規程で試します。旧版や他部署の規程を選ばず、自動送信もしないことを確かめます。
人は提案や結果を確認して判断し、開発用AIは承認された条件に沿って作業を進めます。
開発中の設計例：現場が作り、直し続ける
独自見解私たちビジョン・コンサルティングは、業務用AIを現場で作成・修正する環境を開発しています。
現場の担当者は仕事内容を伝え、開発用AIの提案や試作品を確認します。初期設定、社内接続、利用できる資料や操作の設定は、技術担当者が受け持ちます。
- 現場の担当者 伝える 「規程から返信案を作りたい」と伝えます。使う資料と回答の条件を示し、送信は人が行うと決めます。
- 開発用AI 作る 不足する情報を質問し、必要な機能を提案します。人の確認後、AI-DLCの手順で設計・プログラム作成・動作確認を進めます。
- 現場の担当者 確かめる 試作品を使い、規程に沿った返信案かを見ます。気づいた点をAIへ伝え、修正後も確かめます。
営業部の規程を使うと決まっていれば、開発用AIは部署を聞き直しません。「規程に答えがない場合、誰へ確認を依頼するか」が未定なら質問します。回答方法を決めるために、まだ足りない情報を確かめる設計です。
営業部向けの問い合わせAIを、別の部署でも使う場合を考えます。根拠を表示する機能は残し、規程や承認先をその部署に合わせて変えます。資料をAIに読ませてよいか、送信などの操作を許可するかは改めて確認します。
現場は「返信案に、上司の事前承認が必要なことも書いて」と依頼します。変更してよい範囲を決めておき、AIが示した修正案を担当者が確認します。AIが設定やプログラムを直した後、試作品で修正前後の回答を比べます。
- 同じ質問で確認 承認の案内が加わったかを見る 同じ規程・同じ質問で修正前後を比べ、根拠の表示など、元の機能が保たれているかも確認します。
- 別の質問でも確認 他の回答も、規程どおりに出るかを見る 別の問い合わせでも案内が正しいか、今回直していない回答や表示が変わっていないかを確かめます。
- 責任者が判断 問題がなければ、普段使うAIを更新 責任者が内容を認めた後、更新したAIを利用者へ届けます。改善しなければ、元のAIを使い続けます。
在宅勤務の承認先が変わると、その条件を使うAIの回答や確認項目も変わります。私たちは、各AIが使う規程と条件を記録し、改定時に直す箇所を管理担当者へ知らせる仕組みを検討しています。
開発中の環境では、架空資料と試験用の環境で、依頼内容の相談や条件確認を行いました。試作品の作成・点検・試用までの流れを確認しています。実際の社内システムへの接続と、時間短縮効果は未検証です。
次の検証対象は、実際の接続と、確認・手直しを含めた業務全体の負担です。
まず何を試し、どこを専門家に相談するか
問い合わせAIなら、まず架空の規程で返信案だけを作り、承認条件と根拠がそろうかを確かめます。間違いを直した後は、同じ質問と別の質問で回答を確認します。
問い合わせの返信案、申請書のチェック、定型報告の整理などが候補です。既存ツールの設定変更で足りる仕事は、そのまま進めます。新しく作るかは、毎回の手間と、作成後の維持負担を比べて決めます。
- 資料を用意する 架空規程を渡す 「在宅勤務には上司の事前承認が必要」と書いた資料を用意します。この資料を使って返信案を作るAIの試作を依頼します。
- 試作品を使う 質問する 「在宅勤務には何が必要？」と、出来上がった試作品に入力します。
- 回答を確かめる 承認と根拠を見る 「上司の事前承認が必要です」という返信案と、根拠となる規程の箇所が出るかを見ます。
AI-DLCそのものを試す場合は、技術担当者と公式開始手順に沿って環境を用意します。設定済みのClaude Codeでは「/aidlc」に続けて、作りたいものを伝えられます。開発全体の手順は「AI-DLCの進め方・実践手順とは？」を参照してください。
添付した架空の在宅勤務規程を使い、社員の質問への返信案を作るAIを試作してください。「在宅勤務には何が必要？」と聞いたら、必要な手続きと根拠の箇所を示してください。送信はせず、人が返信案を確認します。足りない情報は質問してください。間違いや抜けがあれば、次の質問でも正しく答えるよう、試作品を直してください。
社内システムへの接続や、誰にどのデータを見せるかは、技術・管理側の判断が必要です。試作が動く段階と、実業務で使い始める段階を分け、各社の環境・権限に合わせます。
- 返信の見本。必要な事前承認を案内し、根拠の規程も示す返信を、見本として用意します。
- 担当分担。返信内容の修正は誰が担当するか、社内資料への接続や送信の許可は誰が管理するかを決めます。
- 規程との対応。在宅勤務の承認条件を使う問い合わせAIと申請書確認AIを、規程と対応付けて記録します。
- 確認と戻し方。試す質問と、業務で使うことを認める責任者を決めます。問題があれば、以前のAIへ戻す方法も用意します。
「試作後も、毎回開発者の手直しが必要」「部署ごとに規程が違い、共通化する範囲が決まらない」。こうした段階では、ツールの選定だけでなく、作成後の修正や管理の方法から相談できます。無料相談では、今の仕事、使っている資料、試作品で困っている点をお聞かせください。
目指すのは、AIを作って終わりにせず、現場からの指摘や規程の変更に合わせて、社内で直し続けられるようにすることです。
よくある質問
AI-DLCを入れるだけで、非エンジニアが業務用AIを作れますか？Q1
公開AI-DLCには対話しながら開発する仕組みがありますが、業務担当者だけで使える環境が完成するわけではありません。初期設定や接続・権限の確認は技術側が担い、現場で進めてよい作成・修正の範囲と、専門家へ戻す判断を決めます。本文は、その業務向け環境の設計を説明しています。
チャットでAIに指示するだけでは足りませんか？Q2
一度きりの作業や、既存ツールの設定で十分な仕事なら、それで足ります。同じ条件を繰り返し説明する、複数人で使う、規程変更を継続して反映するといった仕事では、設定・処理・テストを備えた業務用AIとして整える価値を検討します。
この記事の仕組みは、導入効果が実証済みですか？Q3
開発中の作成環境では、架空資料を使った相談から作成・試用までの動作を、検証用環境で確認しています。本文の問い合わせ対応は、設計を説明するための架空例です。実際の業務環境での接続は未確認で、時間短縮効果も未測定です。評価するときは、作成時間に加えて、人の確認・手直し・維持にかかる負担を、導入前と同じ仕事で比べます。
出典と調査方法
確認日：2026年10月23日。公開AI-DLCの進め方と承認手順は、以下の公式資料に基づきます。第3章の自社設計と第4章の相談事項は、公開AI-DLCとは別の設計・提案です。開発中の環境での動作確認は、架空資料を使った試験用環境に限ります。
- AWS：AI-DLCの考え方 — ソフトウェア開発方法としてのAI-DLCと、AIが作業を進め、人が重要な判断を担う関係の根拠。
- AWS：AI-DLCの適応型ワークフロー — 開発対象に応じた工程の調整、人の確認、成果物と判断の引き継ぎの根拠。
- AWS Labs：AI-DLC Workflows — 公開実装の構成と、開発範囲に合わせてAIと人が進めるワークフローを確認。
- AI-DLC Workflows：開始手順 — 開発環境の準備・設定と、設定済みのClaude CodeからAI-DLCを呼び出す方法の根拠。
- AI-DLC Workflows：最初の開発の流れ — 対話による要件整理、工程・設計の提案、成果物の引き継ぎ、承認した方法での実装検証を確認。
- AI-DLC Workflows：チームの知識と決まり — 開発用AIがチームの資料や決まりを参照する仕組みを確認。配布済み業務用AIの自動更新とは区別。
PoCを「技術実験」で終わらせず、経営判断まで設計する。
対象業務の選定、現状値の計測、評価設計、ガバナンス、本番移行判定を一つの意思決定プロセスとして整理します。