ビジネス活用2026年9月更新

システム開発の追加費用はなぜ発生する?AI開発で多い典型パターンと防ぎ方【2026年9月最新】

公開日: 2026/09/14
システム開発の追加費用はなぜ発生する?AI開発で多い典型パターンと防ぎ方【2026年9月最新】

この記事のポイント

システム開発の追加費用は変更1件で約6万〜200万円(試算)。JUAS 2026の規模別予算超過率、AI開発で多い外部AIの提供終了・利用料・合格基準の後出し、誰が払うかの判定表、IPAモデル契約に沿った防ぎ方まで発注者向けに解説します。

システム開発の追加費用は、変更1件あたり約6万円(一覧画面に項目を1つ足す程度)から約200万円(外部システムとの連携を1つ足す程度)かかり、その多くは「着手後の変更」「決めきれていなかった事項」「見積の前提に入っていなかった作業」から生まれます。防ぐには、契約前に変更を頼むときの手順を決め、全体の10〜20%を予備費として別枠で確保したうえで、小さく区切って発注することです。

※変更1件あたりの金額は、1人日(1人が1日働く作業量)を3〜5万円と置いた試算です。前提は後ほど表で示します。

日本情報システム・ユーザー協会(JUAS)の「企業IT動向調査報告書2026」には国内企業957社が回答しています。それによると、予定より予算を超過したプロジェクトの割合は、10人月未満の案件で6.0%、500人月以上の案件で42.2%でした。規模が大きいほど、予算は超えやすいということです。発注の単位を小さくする対策は、発注する側が自分で決められます。

この記事は、見積をもらった段階、契約の直前、あるいは着手後に追加見積を出された段階の発注者向けです。次の順に整理します。

  • 追加費用が出る典型パターンと金額の目安
  • AI開発ならではの追加費用
  • 「誰が払うべきか」の判定
  • 請求されたときの確認手順
  • 契約前に決めておくこと

なお、当社の受託開発の価格は、PoC(本格的に作る前の試作検証)が300万円〜、小規模改修が30万円〜、本開発が個別見積です(すべて税別)。

追加費用はどれくらいの確率で発生するのか

JUAS「企業IT動向調査報告書2026」の表紙

出典: JUAS(日本情報システム・ユーザー協会) 公式サイト

予算オーバーは、特別な失敗プロジェクトだけに起きることではありません。JUAS「企業IT動向調査報告書2026」(2025年度調査・経済産業省 商務情報政策局 監修)は、東証上場企業など4,500社を対象に調査し、957社から回答を得ています。今回からは100人月未満の案件を3つに分けて集計しました。「人月」は、1人が1ヶ月働く作業量を表す単位です。

規模が大きいほど、予算も工期もずれる

プロジェクトの規模

予定より予算を超過

予定より工期が遅延

10人月未満

6.0%

9.6%

10〜50人月未満

10.4%

16.2%

50〜100人月未満

19.6%

25.4%

100〜500人月未満

36.2%

38.8%

500人月以上

42.2%

47.8%

出典:JUAS「企業IT動向調査報告書2026」第7章(図表7-1-4ほか)

10人月未満の案件では、「予定どおり完了」が45.7%、「ある程度は予定どおり」が43.4%で、予算超過は6.0%にとどまります。一方、500人月以上になると4割を超えます。報告書も「品質・費用・納期のすべてで、規模が小さいほど不良の割合が低く、大きいほど高い」とまとめています。

人月単価は、事業会社が公開している値で1人月60〜100万円前後が一般的な目安です。この単価で換算すると、10人月未満は、おおむね600万〜1,000万円を下回る規模の案件にあたります(換算は当社によるもので、JUASの記載ではありません)。数百万円単位の案件に区切れるなら、そのほうが予算超過のリスクを抑えやすいと公的な調査から読み取れます。

予算がずれた理由の上位は「複雑さ」「考慮不足」「仕様変更」

予算が予定どおりにならなかった要因(複数回答)

割合

想定以上の現行業務・システムの複雑さ

51.4%

計画時の考慮不足

51.0%

仕様変更の多発

48.6%

社員のスキル不足

31.8%

ベンダー(開発会社)のスキル不足

27.8%

想定外の外的要因

22.9%

開発体制のリソース不足

21.2%

出典:JUAS「企業IT動向調査報告書2026」図表7-1-7(2025年度・n=245)

上位3つはいずれも前年度より1.4〜9.7ポイント増えています。報告書は「品質・費用・納期に共通する悪化要因として依然根強い」と指摘しています。注目すべきなのは、「開発会社のスキル不足」(27.8%)より、「現行業務の複雑さ」「計画時の考慮不足」「仕様変更の多発」のほうが倍近く多いことです。3つとも、発注する側が契約前や着手後に深く関わる部分です。品質・費用・納期の悪化に影響した工程としては、「要件定義」(57.4〜69.0%)と「設計・実装・テスト」(51.7〜74.1%)が高く挙がっています。

追加費用の中身については、少し古い調査もあります。日経コンピュータが2018年に公表した1,745プロジェクトの調査では、コストが超過したのは365件(20.9%)でした。その原因(複数回答)は次のとおりです。

  • 「追加の開発作業が発生した」:64.4%
  • 「追加の設計作業が発生した」:53.7%
  • 「見積もりが甘かった」:37.3%

追加費用の多くは、「頼んだ作業の範囲が後から広がったこと」から生まれているのです。

システム開発で追加費用が発生する典型パターン7つ

「追加費用」と一口に言っても、中身は大きく3種類に分かれます。まずこの区別を押さえておくと、請求を受けたときの判断が早くなります。

種類

中身

追加開発

新しい機能や対象を足す

仕様変更

合意済みの動き・条件・前提・成果物を変える

不具合修正

合意済みの仕様どおりに動いていないものを直す

そのうえで、実際に追加費用が出やすい場面は次の7つです。

1. 着手後に「やっぱりこう動いてほしい」が出る

画面の試作を見て初めて、具体的なイメージが湧くことはよくあります。「承認を2段階から3段階にしたい」「入力の順番を変えたい」といった変更は、見た目が小さくても、裏側の処理やテストのやり直しにつながります。JUASの調査で「仕様変更の多発」が48.6%を占めるのは、この積み重ねです。

2. 「ついでにこれも」が積み重なる

テストの段階で現場の担当者が触り始めると、要望が一気に増えます。1件ずつは小さくても、承認のたびに作業範囲が広がり、合計すると大きな金額になります(金額の試算は後述)。

3. 決めきれていなかった事項が、後から決まる

帳票のレイアウト、権限の分け方、連携先の仕様などを「後で決めます」としたまま始めると、決まった内容によって作業量が変わります。決まった時点で見積が変わるのは、ある意味で当然の結果です。

4. 現行の業務やシステムが、想定より複雑だった

JUASの調査で最も多い要因(51.4%)です。部署ごとに運用が違う、例外処理が担当者の頭の中にしかない、古いシステムのデータの持ち方が独特だった。こうした事情は、着手後の調査で初めて見つかることが多くあります。

5. 見積の前提に入っていなかった作業

開発環境の準備、各種ドキュメントの作成、導入時の操作研修、データの移行などが見積の範囲外になっていると、後日追加で請求される可能性があります。見積書で何が「含まれていない」かの読み方は、AI開発の見積もりの比較方法AI受託開発の費用相場で詳しく整理しています。

6. 口頭やチャットで頼んだ「ちょっとした変更」

IT分野の弁護士が紛争の典型として挙げているパターンがあります。納期を優先するあまり、開発会社の担当者が細かく確認しないまま変更に応じ、後から追加報酬を請求するというものです。発注者側には仕様変更をした認識すらないため、紛争になります。発注者が不信感を抱く理由として多いのは、「自分が頼んだ変更のうち、どれが追加費用の対象なのかを事前に知らされていなかった」ことです。

7. 大きな変更のあとに、不具合と再テストが増える

JUAS「ソフトウェア・メトリクス調査2025」では、要求仕様の変更の大きさによって不具合の出る割合(規模あたりの欠陥率)が大きく変わりました。

要求仕様の変更

件数

平均の欠陥率

変更なし

50

0.192

軽微な変更

97

0.213

大きな変更

33

0.481

大きな変更があったプロジェクトは、変更なしに比べて不具合の出る割合が平均で約2.5倍です(0.481÷0.192で当社が算出)。直す作業に加えて確認し直す期間も延びるため、公開が遅れたり、発注側の社内の手間が増えたりという形でも費用がかかります。

1件ごとの金額は小さくても、積み重なると数百万円になる

変更1件がいくらになるかは、「作業量(人日)×1人日の単価」で決まります。人月単価の公開値は次のとおりです。

発注先

人月単価の目安

フリーランス

50〜80万円

中小の開発会社

70〜120万円

大手のシステム開発会社(システムインテグレーター)

120〜200万円

一般的な目安である1人月60〜100万円を月20営業日で割ると、1人日あたり約3〜5万円です。この単価で、典型的な変更の金額を試算しました。

追加・変更の例

主な作業

想定する作業量

追加費用の試算

一覧画面に項目を1つ追加(データはすでにある)

画面の修正+テスト

2〜3人日

約6〜15万円

帳票・CSVの出力項目を変更

出力処理の修正+関連テスト

3〜5人日

約9〜25万円

入力・保存がある画面を1つ追加

設計・データの持ち方の変更・実装・テスト

10〜20人日

約30〜100万円

外部システムとの連携先を1つ追加

相手先の仕様調査・実装・つないだ状態でのテスト

15〜40人日

約45〜200万円

※1人日3〜5万円 × 想定作業量で当社が置いた試算です。作業量は一般的な作業の分け方から置いた仮定で、こうした変更の費用を集めた公的な統計はありません。

たとえば1,000万円で発注した案件で、着手後に次の変更が出たとします。

  • 一覧画面の項目追加 5件:約30〜75万円
  • 出力項目の変更 2件:約18〜50万円
  • 入力画面の追加 1件:約30〜100万円
  • 連携先の追加 1件:約45〜200万円

合計は約123〜425万円で、当初の金額の12〜43%にあたります。 予備費として10〜20%(100〜200万円)を確保していても、上振れすれば足りません。「1件10万円程度なら」と承認を続けると、こうなるわけです。

AI開発で特に多い追加費用5つ

AnthropicのClaude公式ドキュメント「Model deprecations(モデルの提供終了)」ページ

出典: Anthropic 公式(Claude Platform Docs)

AIを組み込んだシステムには、一般的なシステム開発にはない追加費用の発生源があります。費用相場の解説ではあまり扱われませんが、AIを使う開発を検討しているなら、契約前に必ず確認してください。

1. 使っている外部AIが提供終了になり、乗り換えが必要になる

AIを組み込んだシステムの多くは、Anthropic(Claude)やOpenAIなどが提供するAIを外部から呼び出して動いています。これらの提供元は、古いモデル(AIの版)を一定の予告期間のあとに提供終了にします。

提供元

提供終了の通知時期(公式)

2026年の実例・予定

Anthropic(Claude)

少なくとも60日前

Claude Opus 4.1:6月5日に終了を予告 → 8月5日に提供終了/Claude Sonnet 4・Claude Opus 4:4月14日に終了を予告 → 6月15日に提供終了

OpenAI

一般提供モデルは少なくとも6ヶ月前、特化版は少なくとも3ヶ月前、プレビュー版は2週間などより短い場合あり

個別の終了予定は公式ページで随時更新

Anthropicは、提供終了日を過ぎたモデルへのリクエストは失敗すると明記しています。つまり、何もしなければシステムのAI部分が止まります。上の実例では、モデル名に含まれる日付(2025年5月14日、2025年8月5日)から数えて、およそ1年〜1年1ヶ月で使えなくなりました。Claude Sonnet 4.5やClaude Haiku 4.5にも、「この日より前には終了しない」という日付(それぞれ2026年9月29日、10月15日)が公式に示されています。

しかも、新しいモデルに差し替えるだけで済むとは限りません。たとえばClaude Opus 4.7以降では、回答のばらつきを調整する設定値(temperatureなど)に既定以外の値を渡すとエラーになります。モデルを新しくするだけでも、プログラムの修正が必要になる例です。

動作確認、AIへの指示文の調整、再テストで5〜15人日かかるとすると、乗り換え1回あたり約15〜75万円になります(1人日3〜5万円での試算)。数年使うシステムなら、使っている間に何度か乗り換えが起こりうる前提で考えてください。

経済産業省の「AIの利用・開発に関する契約チェックリスト」(2025年2月)も、既存の生成AIを組み込むタイプの開発では、開発会社自身が外部AIサービスの利用者として、その利用規約に縛られると指摘しています。開発会社の努力だけでは避けられない費用なので、保守契約に含めるのか、都度の追加費用なのかを契約時に決めておくことが最も確実な防ぎ方です。

2. AIの利用料・クラウド費用が、見積の想定より膨らむ

生成AIの利用料は、使った分だけ課金される形が基本です。利用者や処理件数が増えれば、そのまま月額が増えます。JUAS「企業IT動向調査報告書2026」では、IT予算が増える理由として新たに設けられた「AI関連投資・利用料増加」の回答が、2025年度計画の36.3%から2026年度予測で43.7%へ、7.4ポイント増えました(予算超過の調査ではなく、予算が増える理由の調査です)。

提供元の価格改定で運用費が変わることもあります(DeepSeek APIの値上げ企業のAIコスト問題)。見積の段階で、開発費とは別に「実費(クラウド利用料・外部AIの利用料・ソフトウェアのライセンス)」を分けて示してもらいましょう。あわせて、その月額が何人の利用者、何件の処理を前提にした数字なのかも確認してください。

3. 「どこまでの精度なら合格か」を後から決める

同じチェックリストは、AIモデルは学習データから帰納的に作られるため、完成の約束や性能の保証が必ずしも容易ではないと整理しています。合格の基準がないまま始めると、「もう少し精度を上げたい」「この書類でも試したい」という調整が終わらず、そのたびに費用が積み上がります。

事業会社の見解ですが、「80点でよいのか、95点以上が必要か」で必要な工数が倍以上になるケースがあるとも言われています。開始前に「どの質問や書類に対して、どの水準で答えられたら合格か」を文書で決めることが、最も効く対策です。

4. データの整備が想定より重い

AIに読ませるデータの形式がバラバラだったり、抜けや表記ゆれが多かったりすると、整える作業に大きな手間がかかります。データの準備だけで全体の費用の大半を占めてしまうリスクを指摘する開発会社もあります。着手してから「思ったより使える状態のデータがない」と分かるのが典型です。契約前に実際のデータの一部を開発会社に見せ、整備はどちらの作業範囲なのかを決めておいてください。

5. 試作から本番に移すときに、見えていなかった要件が出る

試作(PoC)の簡易な仕組みは、本番での利用者の増加、処理量、障害時の対応までは考えていないのが普通です。そのため、本番に移す段階で大きな追加費用が必要になることがあります。医療情報を扱う場合のように、セキュリティの要件が後から判明するケースも同じです。試作の結果報告に「本番にするとき追加で必要になるもの」まで含めてもらうと、本開発の見積が後からずれにくくなります(試作の費用感はAI PoCの費用)。

AI開発の追加費用

発覚しやすい時期

契約前に決めておくこと

外部AIの提供終了による乗り換え

公開後(通知期間は提供元により2ヶ月〜6ヶ月以上。プレビュー版はより短い)

保守に含むか都度見積か/通知を受けてから影響調査を出す期限

AIの利用料・クラウド費用

公開後、利用が広がったとき

実費を開発費と分けて明示/想定する利用者数・処理件数

合格基準の後出し

試作〜テスト

合格とする水準を文書で決める

データの整備

着手直後

整備はどちらの作業か/実データを事前に見せる

試作から本番への移行

本開発の見積時

本番化で追加になる要件を試作の報告に含める

その追加費用は誰が払うべきか

追加見積を受け取ったら、最初に判断すべきは「そもそも払うべき費用かどうか」です。法律事務所の解説と、IPA(情報処理推進機構)のモデル契約書の考え方をもとに、原因別に整理しました。

追加費用の原因

原則として払うのは

判断の分かれ目

発注者が依頼した仕様変更・機能追加

発注者

金額を変えるのは契約の変更なので、本来は合意が前提。ただし合意書がなくても認められることがある(下記)

決めきれていなかった事項が後から決まった

事前の書面次第

「確定したときに費用や納期が変わるなら受け入れる」と書面にしていれば発注者(IPAモデル契約 第36条の考え方)

見積の前提条件の外にある作業

見積書の書き方次第

前提条件や対象外として明記されていれば発注者。書かれていなければ協議

開発会社の見積誤り(想定より手間がかかった)

開発会社

見積誤りを理由にした追加請求の余地はないとされる

合意した仕様どおりに動かない(不具合)

開発会社

「不具合」か「仕様変更」かの切り分けが争点になりやすい

外部AIの提供終了による乗り換え

契約次第

保守に含めるか都度見積かを決めていないと揉めやすい

1行目の「合意書がなくても」について補足します。法律事務所の解説によると、金額の変更は契約の変更にあたるため、合意がなければ原則として追加報酬は請求できません。ただし例外があります。商法512条は「商人が営業の範囲内で他人のために行為をしたときは、相当な報酬を請求できる」と定めており、契約書を作り直していなくても追加報酬が認められることがあります。

よく引かれるのが東京地方裁判所の平成17年4月22日の判決です。プログラムの本数が当初の182本から414本に増えた事案で、「当初の受注範囲と金額が明確」「依頼範囲を超えて作業したことが明確」という条件のもと、追加報酬が認められたと解説されています。認められやすい条件としては、開発会社が「追加作業には別途費用がかかる」ことをメールを含む文書で事前に伝えていることなどが挙げられています。

発注者にとっての意味ははっきりしています。「契約書を作り直していないから払わなくていい」とは言い切れません。 チャットで頼んだ変更に対して、開発会社から「別途費用がかかります」とメールが来ていれば、請求が認められる可能性は高まります。

請負(完成した成果物に対して払う契約)と準委任(作業に対して払う契約)のどちらで契約しているかによっても、扱いが変わります(違いはAI開発の契約形態で整理しています)。個別の契約の判断は、弁護士にご確認ください。

追加費用を請求されたときの確認手順

追加見積が届いたら、金額を見て承認・却下を即決せず、次の5つを順に確認してください。

  1. 契約書・見積書の範囲と照らし合わせる
    「追加開発」「仕様変更」「不具合修正」のどれにあたるかを先に決めます。本来は開発会社が負担する不具合修正が、追加費用に混ざっていないかを確認します。
  2. 依頼の記録をたどる
    誰が、いつ、どの手段(会議・メール・チャット)で頼んだのかを確認します。着手前に開発会社から「費用がかかる」と連絡があったかどうかも見ます。
  3. 金額の根拠を作業量で出してもらう
    「どの作業に何人日、1人日いくら」の形で内訳を求めます。1人日3〜5万円を目安に割り戻すと、規模感が妥当かどうか分かります。たとえば一覧画面の項目1つの追加で50万円なら、約10〜17人日です。前述の試算(2〜3人日)と大きく違う場合は、データの持ち方の変更など見えていない作業が含まれていないかを聞いてください。高いから不当とは限らず、理由が説明できるかどうかが判断材料です。
  4. 代わりの選択肢を検討する
    その変更は、①やめる、②範囲を削る、③公開後の改修に回す、④他の機能と入れ替える、のどれかにできないかを考えます。「公開前に本当に必要か」を1件ずつ問い直すだけでも、後回しにできる変更は見つかります。
  5. 納期と他の条件への影響まで確認してから社内承認する
    金額だけでなく、スケジュール、テストのやり直しの範囲、保守費への影響を確認します。後述するIPAの「変更管理書」の項目がそろっているかが確認の目安になります。

確認が終わるまで着手を待ってもらうのは問題ありません。ただし、協議そのものを拒むのは避けてください。理由は後述する取適法にあります。

契約前に決めておく5つの取り決め

モデル取引・契約書を公開しているIPA(情報処理推進機構)のロゴ

出典: IPA(情報処理推進機構) 公式サイト

1. 変更を頼むときの手順と書式を1枚にしておく

IPAが無料で公開している「情報システム・モデル取引・契約書(第二版)」(2020年12月公開)では、手順が決まっています。仕様の変更は、変更の内容と理由を書いた「変更提案書」で提案します(第34条)。提案を受けた側は「変更管理書」を作り、双方の協議の場で可否を決めます(第37条)。変更管理書に書く項目は次の8つです。

#

変更管理書に書く項目

発注者が見るポイント

1

変更の名称

一覧で管理できる名前になっているか

2

提案の責任者

発注側・開発側のどちらの提案か

3

年月日

いつ依頼・提案されたものか

4

変更の理由

本当にいま必要か

5

変更に係る仕様を含む変更の詳細

何がどう変わるのか

6

変更のために費用を要する場合はその額

作業量×単価の内訳が出ているか

7

検討期間を含めた変更作業のスケジュール

公開日が動くか

8

その他、契約条件(作業期間または納期、委託料、契約条項等)への影響

他の機能や保守費に波及しないか

この8項目をそのまま社内の書式にし、「この書式を通っていない変更には着手しない」と開発会社と合意しておきます。金額に応じて社内の承認者も決めておくと、現場の判断で追加費用が積み上がることを防げます。

2. 決めきれていないことを、書面に残してから始める

同じモデル契約書の第36条は、発注者の事情でまだ決められない事項について、次の3点を書面にしておくよう定めています。

  • その内容
  • 確定する予定の時期
  • 確定したときに委託料や納期の変更が必要なら、発注者が受け入れること

発注者には不利に見えますが、「どこが追加費用になりうるか」が最初から一覧で見えるという利点があります。要件が固まっていない状態でどう発注を始めるかは、要件が固まっていない段階での開発相談で扱っています。

3. 途中で届く設計書や画面案の確認期限を守る

第35条では、開発途中で届く設計書などの資料について、発注者が決められた期間内に、具体的な理由を書いた異議を書面で出さなければ、承認したものとみなされます。承認後に直したくなった場合は、変更の手続き、つまり追加費用の対象になります。「あとで見ます」と後回しにしないよう、社内で確認の担当者と期限を決めておいてください。

4. 予備費を全体の10〜20%、別枠で確保する

システム開発の予算管理の解説では、全体の10〜20%程度を予備として見込む考え方が一般的に紹介されています(公的な基準値はありません)。1,000万円の案件なら100〜200万円です。予備費を使うときの社内の承認ルールも決めておきます。ただし前述の試算のとおり、変更が積み重なると予備費だけでは足りなくなります。1〜3の取り決めと組み合わせて初めて機能します。

期間についても同じ考え方です。JUAS「ソフトウェア・メトリクス調査2025」は、工期を守るための工夫として「要求仕様の明確化と仕様変更の最小化」「標準より余裕をもった計画工期の設定」を挙げています。

5. 小さく区切って発注する

冒頭の調査のとおり、10人月未満の案件では予算超過が6.0%にとどまります。IPAのモデル契約書(第二版)も、特徴として「多段階契約と再見積りの考え方」を採り入れています。これは、段階ごとに契約し、次の段階に進むときに改めて見積もる進め方です。AI開発については、経済産業省のチェックリストも踏み込んでいます。契約の時点でリスクを十分に分析できない場合は、1つの契約ですべて調整しようとせず、後の契約で段階的に調整するほうが実態に合う場合がある、としています。

具体的には、次のような分け方です。

  • AIを使う新しい仕組みは、まず試作で確かめ、その結果を見て本開発の範囲と見積を決める
  • 既存システムの改修は、変更したい箇所を1つずつ切り出して発注する

小規模な改修でどこまでできるかはシステムの小規模改修の費用にまとめています。見積依頼の時点で前提条件をそろえる方法はシステム開発の相見積もりとRFPを参照してください。

追加費用を「払わない」で抑えようとすると起きること

「下請法」から「取適法」への改正事項をまとめた公正取引委員会・中小企業庁のリーフレット

出典: 公正取引委員会 公式サイト

追加費用を抑える方法として、「追加分は払わない」「当初の金額の中でやってもらう」と交渉するのは、発注者にとってリスクがあります。

無償の追加作業は、取適法違反になりうる

2026年1月1日に、下請法が改正されて「取適法(中小受託取引適正化法)」として施行されました。プログラムの作成を外部に委託する取引も対象です。プログラム作成の場合、次のいずれかに当てはまれば適用されます。

発注する側

受ける側

資本金3億円超

資本金3億円以下

資本金1千万円超3億円以下

資本金1千万円以下

従業員300人超

従業員300人以下(今回の改正で新設)

禁止されている行為のうち、追加費用に直結するのは次の4つです。

  • 受ける側に責任がないのに発注内容を変更したり、無償でやり直しや追加作業をさせたりすること
  • 価格の協議を求められても応じない、必要な説明をしないなど、一方的に代金を決めること(今回新設)
  • 発注時に決めた代金を、相手に責任がないのに後から減らすこと
  • 通常の対価に比べて著しく低い代金を不当に定めること

たとえば従業員300人を超える会社が、従業員300人以下の開発会社に「ついでにこれもお願いします。費用は当初の範囲で」と押し切れば、違反になりえます。発注内容(給付の内容・代金の額・支払期日・支払方法)を書面やメールなどで明示する義務もあります。変更で内容や代金が変わるなら、その都度記録を残しておくのが安全です。

追加要望を出し続けた発注者が、約14億円を負担した裁判例

発注者の責任が正面から問われた例として、旭川医科大学とNTT東日本の間の電子カルテ開発をめぐる裁判(札幌高等裁判所 平成29年8月31日判決)があります。

  • 2009年7月、両者は「以後、画面や帳票に関わるものも含め、一切の追加開発要望を出さない」という合意(これ以上仕様を変えない「仕様凍結」の合意)をしていた。その時点で開発会社は625項目の追加開発を受け入れていた
  • 合意後も、大学側からは追加要望が出され続けた(解説記事によれば171項目で、うち92項目は開発対象外のカスタマイズ)
  • 高裁は、発注者には合意後に大量の追加要望を出して開発を妨げない義務(協力する義務)があるとして、開発が頓挫した責任は発注者のみにあると判断した
  • 開発会社については、「追加要望に応じれば納期を守れないことを明らかにし、拒否を含めた対応をした」として責任を否定した
  • 大学側に約14億円(遅延損害金は別)の支払いが命じられ、最高裁が大学側の上告を受理しなかったことで確定した

IPAの講演資料(2025年4月)でも、発注者に求められる「協力」には、開発会社の作業を邪魔しないことも含まれると説明されています。

追加費用は、「払わない交渉」で抑えるものではありません。「発生させない段取り」で抑えるものです。

追加費用を抑える発注の単位と、当社の費用

ここまでが、どの開発会社に頼む場合にも共通する話です。ここからは当社の場合を紹介します。当社の受託開発は、小さく区切って発注できるメニュー構成にしています(すべて税別)。

メニュー

価格

含まれるもの

追加費用を抑える使い方

小規模な既存システム改修

30万円〜

画面の追加・修正、帳票の追加、CSV出力、軽微な外部連携、既存処理の修正

変更したい箇所を1件ずつ切り出し、範囲を決めて発注する

PoC(試作検証)

300万円〜

課題整理、簡易な要件定義、設計・開発、検証環境、結果の整理、本開発の提案

合格基準を決めて試し、その結果から本開発の範囲と見積を出す

本開発

個別見積

利用者数、機能数、外部連携、データ移行、セキュリティ、運用、止まらずに動かし続けるための要件を確認したうえで算出

試作で確かめた範囲だけを本番にする

実費

別途

クラウド利用料、外部AIなどの利用料、ソフトウェアライセンス

開発費とは別枠で示す

提案・見積の段階では、対応範囲、成果物、費用、スケジュールを提示しています。クラウドや外部AIの利用料などの実費も、開発費とは別に示します。この記事で挙げた「見積の前提外の作業」や「AIの利用料が膨らむ」といった点を、見積書の段階で確認できる形です。契約条件に応じたソースコード・成果物の引き渡しや、お客様のクラウド環境での構築にも対応しています。

冒頭の換算で言えば、小規模改修やPoCは、予算超過が最も少なかった「10人月未満」(おおむね600万〜1,000万円を下回る規模)の帯から始められる発注単位です。費用の内訳と対応範囲は受託開発サービスのページに掲載しています。初回相談は無料で、要件が固まっていない段階でも、他社で進んでいる案件の追加見積が妥当か確かめたいという段階でも、お話を伺います。

実際にやった事例

守秘のため社名は伏せ、「追加費用を抑える」という観点で、当社が担当した3件を紹介します。

調剤薬局のケース:全部作り直さず、転記部分だけを改修した

課題
前の開発で、データを読み取る部分までは作られていました。ところが、読み取った内容を2つのシステムに人が入力し直す作業が残っており、現場の負担は減っていませんでした。システム全体を作り直せば、大きな追加投資になる状況でした。

作ったもの
読み取り部分は既存のものを残し、転記の部分だけを作り直しました。2つのシステムに同じ内容を流し込み、内容が食い違ったときだけ担当者に確認画面を出す形です。

何がどう変わったか
二重入力がなくなり、担当者が目で確認するのは食い違いが出た件だけになりました。前の開発で作られていた部分を資産として活かしたので、追加投資は小規模改修の枠に収まっています。範囲を1箇所に絞ったこと自体が、追加費用を小さく抑える一番の手段でした。

医療機関のケース:試作の前に「合格基準」を文書にした

課題
蓄積された文書や記録は多いのに、必要な情報を探すのに時間がかかっていました。AIで解決できそうでも、どこまでできれば業務に使えるのか、誰にも判断できない状態でした。

作ったもの
手元の資料をAIに読ませ、質問すると根拠の箇所を示しながら答える仕組みです。いきなり全部門に広げず、1部門・1業務に絞って試作から始めました。そして開始前に、「どの質問に、どの水準で答えられたら合格とするか」を文書で決めました。

何がどう変わったか
判定の基準があったので、拡大するかどうかの判断が短期間で済みました。本記事で挙げた「合格基準を後から決めることによる調整の繰り返し」を、最初から防いだ形です。

インフラ企業のケース:1年続いた試作を、基準を決めて「本番化」と「見送り」に分けた

課題
点検記録をAIで分析する取り組みが、試作を繰り返しながら1年以上続いていました。何ができたら本番にするのかが決まっておらず、精度の報告だけが毎月上がってくる状態でした。

作ったもの
最初にやったのは開発ではなく、判定基準づくりです。対象を点検記録3種類に絞り、「どの精度に届いたら本番に進む、届かなければ中止する」を1行で決めました。そのうえで、基準を満たした1種類だけを本番のシステムに載せました。

何がどう変わったか
残る2種類は「現時点では見送る」と正式に判断し、費用が流れ出し続ける状態を止めました。終わりの条件がない試作は、それ自体が毎月の追加費用になります。

相談から開発開始までの流れと期間の考え方

当社の進め方は次の5段階です。各段階で発注側に決めていただくことが、そのまま追加費用の予防策になります。

段階

当社が行うこと

追加費用を防ぐために発注側で決めること

1. ご相談(無料)

困っている業務、使っているシステム、予算感を伺う

決まっていないことを、そのまま「未確定」として伝える

2. 課題・要件整理

業務、データ、権限、外部連携を確認する

部署ごとの運用の違いや例外処理を出し切る(JUASで最多の要因「現行業務の複雑さ」への対策)

3. 提案・見積もり

対応範囲、成果物、費用、スケジュールを提示する

対象外の作業、変更を頼むときの手順、未確定事項、予備費

4. PoCまたは本開発

試作・開発・テスト

合格基準、設計書や画面案の確認期限、変更は書面で依頼する

5. 導入・改善

公開後の改善

外部AIの提供終了と利用料の扱い

期間の目安には、JUAS「ソフトウェア・メトリクス調査2025」の工期の配分が参考になります。要件定義、設計〜結合テスト、総合テストの比率はおおむね20:50:30です。6ヶ月の開発なら、要件定義に約1.2ヶ月かける計算です。追加費用の多くは要件定義の不足から生まれるため、ここを短く削るほど後で高くつきます。同調査では、納期を最優先にしたプロジェクトは予定の工期までに完了した割合が74.5%で、他を優先したプロジェクトの61.6%を上回りました。何を最優先するかを最初に決めておくと、「この変更は次の段階に回す」という判断もしやすくなります。

期間全体の目安はAI開発の期間で整理しています。どの段階から相談すべきか迷う場合は、受託開発の相談窓口から、現在の状況だけお知らせください。

よくある質問

Q1. チャットで気軽に頼んだ小さな変更も、後から請求されますか?

請求される可能性はあります。防ぐには、運用で次の3つを徹底するのが確実です。

  1. チャットで依頼するときも、最後に「費用や納期に影響がある場合は、着手前に金額を教えてください」と1文添える
  2. 開発会社への依頼は発注側の窓口1人に集約し、現場の担当者から直接頼まない
  3. 依頼した変更を1つの一覧にまとめ、週1回、費用がかかるものとかからないものを双方で確認する

現場の担当者が直接頼む運用のままだと、発注側の誰も把握していない追加費用が積み上がっていきます。

Q2. 準委任(作業時間に対して払う契約)なら、追加費用の心配はありませんか?

「追加費用」という名目の請求は出にくくなりますが、安心はできません。作業時間が増えれば、その分の支払いがそのまま増える契約だからです。請求書の名目が変わらないぶん、総額が膨らんでいることに気づきにくいという弱点があります。月ごとの上限時間と、超えそうなときは事前に相談する取り決めを契約に入れてください。月次の報告では、どの依頼に何時間かかったかの内訳まで出してもらいましょう。

Q3. 固定価格(請負)で契約すれば、追加費用は一切かかりませんか?

かかります。固定されているのは「合意した範囲」の金額で、範囲の外にある変更や追加、未確定だった事項の確定分は別に見積もられます。請負では、この範囲の境界が曖昧だと「仕様書に書かれていないものはすべて範囲外」と扱われかねません。契約前に、仕様書とは別に「今回の対象外とするもの」を一覧で書いてもらうと、境界がはっきりします。

Q4. 見積書に「予備費」や「バッファ」が入っているのは、水増しではありませんか?

項目として明示されているなら、むしろ誠実な見積です。見積の末尾に置かれる予備費が工数費の10〜20%を占めることもある、と解説されています。注意すべきなのは、予備がどこにも見当たらない見積のほうです。その場合、変更はすべて追加見積になる可能性があります。予備費が入っている場合は、次の3点を確認してください。

  1. 何のリスクに備えた予備費か
  2. 使わなかった場合にどう扱うか(減額するのか、変更に充てるのか)
  3. 予備費の中で吸収する変更と、別見積にする変更の線引き

Q5. 使っている外部AIが提供終了になったら、改修費用は誰が負担しますか?

契約で決めた側が負担します。決めていなければ協議になり、揉めやすくなります。契約書には次の3点を書いておくことをおすすめします。

  1. 対象:どの外部AIサービスの、どんな変更を対象にするか(提供終了、価格改定、仕様変更)
  2. 保守料金に含む範囲:たとえば「同じ提供元の後継モデルへの切り替えと動作確認まで」
  3. 含まない場合の扱い:見積の出し方と、通知を受けてから影響調査を報告するまでの期限

もう1点、見落としやすい点があります。Amazon BedrockやGoogle Cloudを経由してAIを使っている場合、提供終了日はそれぞれのクラウドが別に決めています。AI提供元の告知だけを見ていると気づけないため、どの経路で使っているかを設計書に書き残しておいてください。

Q6. 開発会社が影響を説明しないまま変更に応じ、結果として遅れました。これも発注者の責任ですか?

発注者だけの責任とは限りません。IPAの講演資料(2025年4月)は、仕様変更は後のスケジュールや費用に影響する可能性が高いと説明しています。そのうえで、開発会社には変更の影響を分析して発注者に説明し、本当に変更すべきかを慎重に協議する必要があるとしています。分析や説明をせずに安易に応じて遅延や不具合が起きた場合は、開発会社が責任を負う可能性がある、という整理です(東京高等裁判所 平成25年9月26日判決・平成26年1月15日判決を参照)。一方で、旭川医科大学の例のように、合意後も発注者が要望を出し続けていれば、発注者の責任が問われます。誰が何を頼み、開発会社がどう説明したかの記録が判断材料になるので、残しておいてください。個別の判断は弁護士にご相談ください。

Q7. 追加見積が高すぎて納得できません。途中でやめたり、別の会社に続きを頼んだりできますか?

IPAのモデル契約書(第二版)第38条は、変更の協議がまとまらず、発注者が納期や費用への影響を理由に続けないと判断した場合について定めています。この場合、まだ終わっていない部分を解約できますが、それまでの委託料と、解約によって開発会社に生じた損害は支払う形です。実際にどうなるかは、お手元の契約書の中途解約の条項で決まります。別の会社に引き継ぐなら、ソースコードと設計書を受け取れるか、外部サービスのアカウントが自社の名義かを先に確認してください。止まったプロジェクトの畳み方はAI開発の失敗はどこで起きるかで詳しく扱っています。

追加費用に悩む前に、発注の段取りからご相談ください

この記事の要点は3つです。

  1. 追加費用は変更1件で約6万〜200万円(試算)。 積み重なると当初の金額の1割強〜4割強になりえます。予備費10〜20%だけでは防げません
  2. 小さく区切った案件ほど予算超過は起きにくい。 JUASの調査では、10人月未満で6.0%、500人月以上で42.2%でした
  3. AI開発では、外部AIの提供終了・利用料・合格基準の3点を契約前に決める。 どれも一般的な見積書には書かれにくい費用です

次のような状況なら、ご相談ください。

  • 着手後に追加見積が出てきたが、妥当かどうか判断がつかない
  • これから発注するが、変更の手順や予備費をどう決めればよいか分からない
  • AIを組み込むシステムの見積に、外部AIの提供終了や利用料の扱いが書かれていない

当社の受託開発は、PoC 300万円〜、小規模改修 30万円〜、本開発は個別見積(すべて税別)です。クラウドや外部AIの利用料などの実費は、開発費と分けて提示します。医療機関・薬局・インフラ企業での実績があり、初回相談は無料です。要件が固まっていない段階からお受けしています。

受託開発の無料相談はこちら

関連記事:AI受託開発の費用相場AI開発の契約形態AI開発の見積もりの比較方法業務システム開発の費用相場AI開発会社の選び方

参考資料

要件が固まっていない段階からご相談いただけます(初回相談無料)

開発について相談する

この記事の著者

AI革命

AI革命

編集部

AI革命株式会社の編集部です。最新のAI技術動向から実践的な導入事例まで、企業のデジタル変革に役立つ情報をお届けしています。豊富な経験と専門知識を活かし、読者の皆様にとって価値のあるコンテンツを制作しています。

経理・事務作業・開発を、AI革命にまとめて任せられます

ご相談は無料です。オンラインで完結します