AI開発発注の失敗図鑑｜要件の追加・変更（スコープクリープ）の管理を決めず予算と納期が膨張する失敗

結論：AI開発の予算と納期は「変更を管理する仕組み」がないと静かに膨張する

AI開発で予算と納期が膨張する典型的な原因は、見積りの甘さよりも、進行中に出てくる要件の追加・変更を扱う仕組み（変更管理プロセス）を決めていないことである。「ついでにこの帳票も」「精度をもう少し上げてほしい」「この部署の例外にも対応して」——一つひとつは小さな依頼でも、それを誰が受け、影響を評価し、再見積りして、誰が承認するのかが決まっていないと、依頼が無管理に積み上がる。気づいたときには当初の範囲をはるかに超え、予算超過と納期遅延が同時に進行している。これがスコープクリープ（範囲の漸増）である。

• スコープクリープは「大きな仕様変更」ではなく「小さな追加の積み重ね」で起きるため、誰も止め時を意識しないまま膨張する。
• 防ぐ鍵は変更を禁じることではなく、変更要求→影響評価→再見積→承認という変更管理プロセスを最初に決めておくことである。
• AI開発は出力が確率的で「もう少し精度を」が終わりなく続きやすく、一般的なシステム開発よりスコープが膨張しやすい。
• 変更管理の有無は契約形態（請負か準委任か）の選び方とも直結し、契約段階で設計すべき論点である。
• 変更管理は発注時に要件・契約へ組み込むものであり、揉めてから決めるものではない。

この連載は「AI開発発注の失敗図鑑」として、発注側がつまずきやすい論点を一つずつ分解している。第24回となる本稿は、見積り時点での範囲の曖昧さを扱った第4回：見積書の「AI一式」が曖昧になる理由とは切り口を分ける。第4回が「最初の範囲がそもそも曖昧」という入口の問題だとすれば、本稿は「最初は明確だった範囲が、進行中の追加・変更を管理できずに膨らんでいく」という途中の問題、すなわち変更管理プロセスの不在に絞って解説する。

なぜAI開発でスコープは膨張するのか

「小さな追加」は一つずつだと断りにくい

スコープクリープの厄介さは、一つひとつの変更が小さく、合理的に見える点にある。「この画面に項目を一つ」「この帳票も出せると助かる」といった依頼は、単体では工数も小さく、開発側も発注側も「それくらいなら」と受けてしまう。ところがこの小さな受諾が積み重なると、設計の前提が少しずつずれ、テスト範囲が広がり、当初の見積り工数を静かに食いつぶす。誰も大きな決断をしていないのに、合計では大きな超過になっているのがこの失敗の本質である。

そもそも進行中に追加要望が次々出るのは、要件定義の段階で現場の業務を十分に引き出せていない裏返しでもある。最初のヒアリングが浅いと、作り始めてから「本当に必要なもの」が見えてきて追加が止まらなくなる。要件のずれが後工程で噴き出す構造は連載第8回の現場ヒアリング不足で要件がずれる問題で扱ったとおりで、入口の要件定義の質はスコープの安定性に直結する。

AIの出力は確率的で「完成」の線を引きにくい

通常のシステム開発であれば「この機能が動けば完成」という線を引きやすい。しかしAIの出力は確率的で、100点満点の正解が常に返るわけではない。だからこそ「もう少し精度を上げられないか」という要望が、機能の追加とは別の軸で延々と発生する。この「完成の線が引きにくい」性質が、AI開発をスコープ膨張に特に弱くしている。

これを防ぐには、どこまで到達すれば完成とみなすかを事前に合意しておく必要がある。何をもって受け入れるかを定義する考え方は連載第21回の検収・受け入れ基準が曖昧で揉める問題で扱った。受け入れ基準が曖昧なまま走り出すと、「精度向上」という名のスコープが無制限に広がりやすい。AIを業務へ組み込む難度や到達可能な精度の見極めに不安がある場合は、AI導入可否アセスメントで対象業務と現実的なゴールラインを先に切り分けておくと、後からの際限ない要望を避けやすい。

「AIは後からいくらでも調整できる」という誤解

AIは学習やプロンプトの調整で振る舞いを変えられるため、関係者が「後からいくらでもチューニングできる」と捉えがちである。この感覚が、要件を固める動機を弱め、進行中の変更を軽く扱う土壌になる。実際には、データの追加、評価の作り直し、再学習や再調整には相応の工数がかかり、調整するほど別のケースで精度が落ちることもある。AIを「無限に微調整できるもの」と扱うと、変更が止まらず予算と納期が膨らむ。

AIを単発の機能ではなく、運用と改善まで含む業務システムとして設計する視点があると、この誤解は緩和できる。AIを業務フローへ組み込む観点はDX・業務システム開発の進め方と密接に関わり、今回の範囲と次フェーズの改善を線引きする設計力が、スコープの安定に効いてくる。

「無管理の変更受付」と「変更管理プロセス」を比較する

進行中の変更を、その場の判断で受けるか、決められた手順で扱うかで、結果は大きく変わる。

変更管理プロセスとは、変更を禁じる仕組みではなく、変更を「見える形で正しく決める」仕組みである。手順があるからこそ、必要な変更は堂々と取り込め、不要な変更は止められる。手順がないと、必要な変更も不要な変更も同じ重さで流れ込み、結局すべてが予算と納期を圧迫する。

変更管理プロセスを四段で設計する

実務上は、進行中の追加・変更を次の四段で扱うと判断がぶれにくい。

1. 変更要求（起票）：追加・変更したい内容を、口頭ではなく一覧に起票する。これだけで「何が当初範囲外なのか」が可視化され、無自覚な膨張を止められる。
2. 影響評価：その変更が工数・納期・他機能・テスト範囲・運用にどう影響するかを開発側が評価する。「小さく見えて影響が大きい」変更をここで検知する。
3. 再見積り：影響評価に基づき、追加費用と納期の増減を提示する。当初範囲と追加分を分けて示すことが、予算管理の前提になる。
4. 承認：費用と納期の変化を踏まえ、承認者が取り込むか・見送るか・次フェーズへ回すかを決める。承認されて初めて着手する。

この四段を回すには、各段の責任者がいることが前提になる。発注側に判断する人がいないと、せっかくの手順も形骸化する。承認の権限と責任の所在は推進体制そのものの問題であり、誰が範囲を守るのかという論点は連載第23回の発注側にオーナーがおらず丸投げする失敗（推進体制・ガバナンス）とも重なる。変更管理プロセスは、オーナーがいて初めて機能する。

「精度をもう少し」が無限ループになる構造

AI開発で最も止めにくい変更が「精度をもう少し上げてほしい」である。機能の追加と違って終わりの線がなく、上げるほど次の不満が見えてくる。さらに、ある条件で精度を上げると別の条件で下がるトレードオフがあり、改善が堂々巡りに陥りやすい。この無限ループを断つには、次の枠組みを最初に置くことが要る。

• 何をもって「十分な精度」とするかを、業務上許容できる誤りの範囲として事前に合意する。
• 精度向上を当初範囲（合格ライン到達まで）と追加要望（合格ライン超の上積み）に分け、後者は変更管理で扱う。
• 精度を上げる対象（どの業務・どのケースを優先するか）を絞り、全方位の改善を求めない。

「とりあえず作って様子を見る」だけで合格ラインを決めずに進むと、検証が終わらないまま予算を使い続ける構図にもなりやすい。検証が出口を持たないまま続く問題は連載第1回のPoCで終わる会社の共通点とも通じており、精度の議論にも「どこで一区切りとするか」の合意が欠かせない。

発注前に確認すべきこと（チェックリスト）

スコープクリープによる膨張は、発注時に変更管理を要件・契約へ含めるかどうかで大きく変わる。発注前に次を確認したい。

• 進行中の追加・変更を扱う変更管理プロセス（変更要求→影響評価→再見積→承認）を契約・要件に明記しているか。
• 変更要求を口頭ではなく一覧で起票し、当初範囲と追加分を区別できる運用になっているか。
• 変更ごとに工数・納期・他機能への影響を評価し、再見積りを提示してもらう手順があるか。
• 変更の取り込み可否を誰が承認するのか（発注側の承認者）が決まっているか。
• AIの「合格ライン（十分な精度）」を事前に合意し、それ超の精度向上を追加要望として扱う前提があるか。
• 「今回の範囲」と「次フェーズの改善」を分け、すべてを初回に詰め込まない計画になっているか。
• 契約形態（請負／準委任）が変更の起きやすさと合っており、変更時の費用・納期の扱いが決まっているか。
• 予算と納期に対し、変更を吸収するための余白（バッファ）と、超過時の判断ルールを想定しているか。

このチェックリストは、AIを業務に組み込む難度の見極めと直結する。到達できる精度や対象範囲に不安があるなら、AI導入可否アセスメントで現実的なゴールと範囲を切り分けてから着手すると、際限ない追加を避けやすい。変更管理を含めた進め方を伴走で固めたい場合は、AI開発の進め方と合わせて、最初の範囲設定から相談するのが現実的である。

GXOに相談する前に整理しておくとよい情報

相談前に次を整理しておくと、変更管理と範囲設計の議論が具体化しやすい。

• 今回必ず実現したい範囲：最低限ここまでは達成したいという中核の要件。ここが定まると追加要望と切り分けやすくなる。
• 将来やりたいが今回は見送れる範囲：次フェーズへ回せる要望。初回に詰め込まないための線引きの材料になる。
• 精度・品質の許容ライン：業務上、どの程度の誤りまでなら許容できるか。AIの「合格ライン」を決める前提になる。
• 意思決定体制：追加・変更の取り込みを誰が承認するのか、予算と納期の決裁権限の所在。
• 予算と納期の制約：上限と、超過しそうなときに優先する判断軸（範囲を削るか、納期を延ばすか、費用を足すか）。

これらが揃っていると、AI開発を「際限なく膨らむ一式」ではなく「範囲を管理しながら進める計画」として設計しやすくなる。既存の業務システムへ組み込む場合は、DX・業務システム開発の観点で、今回の範囲と次フェーズの改善をどう分けるかを併せて整理しておくとよい。追加投資の妥当性や段階的な予算配分を社内で通す段になったら、システム開発の稟議・ROI診断の観点で、当初範囲と追加分の投資対効果を整理しておくと意思決定がスムーズになる。

補足：実務上の注意点

契約形態とスコープの膨張は表裏一体

変更の起きやすさは、契約形態の選び方と直結する。要件が固まりきらず探索が続くAI開発を、成果物を固定する前提の契約で進めると、変更のたびに「これは追加か、当初範囲内か」で揉めやすい。逆に探索的に進める契約を選んでも、変更管理の手順がなければ工数だけが膨らむ。請負と準委任の使い分けは連載第13回の請負と準委任の契約類型の選び方で扱ったとおりで、変更管理プロセスは契約形態とセットで設計するのが望ましい。

「変更を歓迎する」ことと「無管理に受ける」ことは違う

探索が前提のAI開発では、進行中に良いアイデアが出ること自体は望ましい。重要なのは、それを歓迎しつつ、影響評価と承認を通すことである。変更管理は変更を抑え込む官僚的な手続きではなく、良い変更を安全に取り込むための仕組みだと捉えたい。手順があるからこそ、現場は安心して改善を提案でき、発注側は予算と納期を握り続けられる。

見積りの読み方も膨張の防波堤になる

そもそも当初見積りで範囲がどこまでかを読み解けていないと、追加と当初範囲の境界が分からず、変更管理も機能しない。見積書の項目・前提・除外事項を読み解く力は、追加要望が出たときに「それは含まれているのか」を即座に判断する土台になる。見積りの読み解き方は連載見積書の読み解き方で体系的に扱っており、変更管理の前提として押さえておきたい。

範囲を削る判断も用意しておく

予算や納期が逼迫したとき、追加を足す判断だけでなく「今回は範囲を削る」判断も選択肢として持っておくべきである。すべてを初回に実現しようとすると膨張は避けられない。中核の要件を守り、優先度の低い要望を次フェーズへ回す判断を、変更管理の中であらかじめルール化しておくと、いざというときに冷静に範囲を守れる。

関連記事

• 特集トップ：AI開発発注の失敗図鑑
• 第4回：見積書の「AI一式」が曖昧になる理由
• 第8回：現場ヒアリング不足で要件がずれる問題
• 第13回：請負と準委任の契約類型の選び方
• 第21回：検収・受け入れ基準が曖昧で揉める問題
• 第23回：発注側にオーナーがおらず丸投げする失敗（推進体制・ガバナンス）
• 見積書の読み解き方（連載）
• AI開発の進め方とご相談

よくある質問

Q1. 変更管理プロセスを入れると、必要な変更まで止まってしまわないか。

逆である。手順がないと、必要な変更も不要な変更も同じ重さで無管理に流れ込み、結局すべてが予算と納期を圧迫する。変更要求を起票し、影響を評価して承認する手順があるからこそ、必要な変更は影響を見たうえで堂々と取り込め、優先度の低い変更は次フェーズへ回せる。変更管理は変更を抑える仕組みではなく、変更を正しく決める仕組みである。

Q2. AI開発はなぜ普通のシステム開発よりスコープが膨張しやすいのか。

AIの出力が確率的で「ここまで動けば完成」という線を引きにくく、「精度をもう少し」という終わりのない要望が機能追加とは別軸で発生するためである。加えて「AIは後からいくらでも調整できる」という誤解が、要件を固める動機を弱め、進行中の変更を軽く扱う土壌になる。合格ラインを事前に合意し、それ超の精度向上を追加要望として扱うことが膨張を抑える鍵になる。

Q3. 「精度をもう少し上げてほしい」という要望にどう線を引けばよいか。

業務上許容できる誤りの範囲として「十分な精度（合格ライン）」を事前に合意し、そこまでの到達を当初範囲、それ超の上積みを追加要望として変更管理で扱うとよい。改善対象も全方位ではなく優先度の高い業務やケースに絞る。AIは条件によって精度がトレードオフになるため、全ケースで満点を求めない前提を関係者で共有しておくことが重要である。

Q4. すでにスコープが膨張し始めている場合、何から手をつければよいか。

まず進行中の追加・変更を一覧に起票し、当初範囲と追加分を区別することから始める。可視化するだけで無自覚な膨張は止まる。そのうえで未着手の変更は影響評価と再見積りを行い、承認者が取り込む・見送る・次フェーズへ回すを判断する手順を入れる。同時に、中核の要件を守るために削れる要望がないかを検討し、予算と納期の優先軸を決め直すとよい。

発注前チェックリスト（全30項目・無料）：本連載の30類型を1枚で点検できるチェックリストを無料ダウンロードできます。発注前の社内確認・稟議の添付資料にご利用ください。

AI開発の予算と納期は、技術よりも「変更をどう管理するか」の設計で安定するかが決まる。スコープクリープの抑え込みや変更管理プロセス・契約形態の設計でお困りの場合は、無料相談から、今回の範囲と変更管理の整理を一緒に始めていただきたい。