この記事の要点
- システム開発の外注費がAI活用で下がるのは実装・単体テスト・ドキュメント整形など「作業量が支配する工程」に限られ、要件定義と運用保守はほとんど下がりません
- 「AI活用」をうたう会社には、開発プロセスにAIを使う会社と、AI機能そのものを作る会社の2種類があり、相談すべき相手が違います
- 要件が固まっていない状態の相見積もりは比較になりません。金額差の正体は実力差ではなく、前提条件と除外範囲の違いです
- 要件定義・テスト・ドキュメント・保守体制の4つは削ると後で高くつきます。安く見える見積もりは、ここが除外されていることが多いのです
「システム開発を外注したいが、AIを使えば安くなるらしい」。そう聞いて調べ始めたものの、各社の見積もりは金額もページ構成もバラバラで、どれが妥当なのか判断できない。よくある状態です。この記事は値切り方のテクニック集ではありません。どこは安くできて、どこを削ると後で高くつくのかを工程単位で切り分け、発注側が使える判断軸を渡すことを目的にしています。
目次
AI活用でシステム開発の外注費は本当に安くなる？安くなる条件と安くならない部分
AI活用で下がるのは、実装・単体テスト・ドキュメント作成といった作業量が費用を決める工程だけです。要件定義、業務設計、受入テスト、運用保守はほぼ下がりません。全体で1〜3割程度の圧縮が現実的なレンジで、「半額になる」前提で予算を組むと、途中で必ず破綻します。
AIで安くなるのはどの工程か（工程別の効き方）
削減余地は工程ごとに大きく違います。人が合意形成する工程には、AIの出力を持ち込んでも工数が残るからです。まず全体像を表で押さえてください。
| 工程 | AIによる削減余地 | そうなる理由 |
|---|---|---|
| 要件定義・業務ヒアリング | 小 | 現場の合意形成と意思決定が中心で、人が会議に出る時間は減らない |
| 基本設計 | 小〜中 | 既存業務・既存システムとのすり合わせが支配的 |
| 詳細設計 | 中 | 設計書のたたき台生成や記述の整形は効くが、レビューは残る |
| 実装（コーディング） | 大 | 定型的なCRUD処理・API連携・画面実装は生成と補完が効きやすい |
| 単体テスト | 大 | テストコードの生成・網羅パターンの列挙と相性が良い |
| 結合・受入テスト | 小 | 業務が成立するかの判断は発注側の人が行う |
| 運用・保守 | 小 | 障害対応・問い合わせ・法改正対応は人の体制コスト |
ここで大事なのは算数です。工程別の工数比率や規模別の実績値は、IPA「ソフトウェア開発分析データ集」で公開されています※1。案件によって幅はありますが、一般的な受託開発では要件定義から設計で3〜4割、実装で2〜3割、テストで3割前後に工数が分散します。仮に実装が全体の25%を占め、そこがAI活用で4割減ったとしましょう。全体への影響は25%×40%＝10%です。テスト工程の一部も減って、ようやく全体で1〜2割。これが「効いた場合」の現実的な姿です。
逆に言えば、実装比率が高い案件ほど効きます。画面数が多い定型的な業務アプリ、連携先が少ない新規開発、技術的に枯れた構成。この条件がそろうほど、AI活用の効果は見積もりに反映されやすくなります。
安くしてはいけない4つの部分
要件定義、テスト・品質保証、ドキュメントと引き継ぎ資料、リリース後の保守体制。この4つは削っても初期費用が下がるだけで、総額はむしろ上がります。削った瞬間に費用が消えるのではなく、後工程に移動するだけだからです。
要件定義を削ると、作り始めてから「そういう業務ではない」が発覚します。手戻りは設計からやり直しになり、追加見積もりが飛んできます。テストを削れば、本番稼働後に業務が止まります。止まった時間の損失は開発費より高くつくことが珍しくありません。ドキュメントを削ると、他社に引き継げなくなります。結果として最初の会社にしか頼めなくなり、改修単価の交渉力を失います。保守体制を削れば、少し直したいだけの依頼のたびに「調査費用」から積み直しです。
安く見える見積もりは、この4つのどれかが範囲外になっているケースが大半です。金額の前に、含まれているかどうかを見てください。
「AIで作るから安い」という見積もりを疑うべきケース
他社の半額といった極端に安い見積もりは、AIによる効率化ではなく、前提条件と対象範囲の違いで安く見えているケースがほとんどです。前の項で見たとおり、AI活用で下がる幅は工程構成から逆算できる範囲に収まります。それを大きく超える安さには、必ず別の理由があります。
次の観点を確認してください。
- テスト工程が金額に含まれているか（単体だけか、結合・受入支援まで含むか）
- 要件定義が込みか、別途見積もりか
- 既存システムとの連携調査費が入っているか、仕様提供が前提になっていないか
- 保守・監視の月額と対応時間の範囲
- 要件が増えた場合の追加単価と精算ルール
- データ移行・初期データ投入の担当
- 本番環境の構築費とクラウド利用料の負担者
そのうえで、「何をAIに任せ、何を人が担保しているか」を言語化できる会社かどうかを見ます。安さの理由を工程で説明できる会社は信頼できます。「AIを使っているので安いです」だけで内訳が出てこない場合、安さの正体は範囲の狭さである可能性が高いと考えてください。
※1 IPA「ソフトウェア開発分析データ集」リンク
AI活用の外注先を選ぶ5つの判断軸
比較すべきは金額ではなく、次の5点です。どこにAIを使う会社かの見極め、工程別に分解された見積もり、AI生成コードのレビュー体制、知財と情報の契約条項、保守と引き継ぎの担保。この5軸をそろえて初めて、各社を横に並べられます。
「開発プロセスにAIを使う会社」と「AI機能を作る会社」は別物
前者は自社の開発工程に生成AIを取り入れて、実装やテストの工数を圧縮する会社です。後者はチャットボット、文書要約、画像判定といったAI機能そのものを設計・実装する会社。どちらも「AI活用」と名乗りますが、あなたの目的によって必要な相手は変わります。
目的が「既存業務のシステム化を、なるべく安く早く」なら前者です。求めるのは開発効率であって、AI機能ではありません。目的が「問い合わせ対応を自動化したい」「書類のチェックを機械にやらせたい」なら後者で、精度検証やデータ整備の経験があるかが焦点になります。両方を兼ねる会社もありますが、提案書に「AI活用」と書かれていたら、どちらの意味かを最初の打ち合わせで必ず確認してください。ここを取り違えたまま進むと、期待していた提案が最後まで出てきません。
見積もりが工程別・機能別に分解されているか
「一式」「○人月」だけの総額表記は、比較にも交渉にも使えません。工程別または機能別に分解された見積もりを、依頼時の必須条件にしてください。分解されていれば、高い理由が工数なのか単価なのか範囲なのかを特定できます。
確認すべき項目は、工程ごとの工数と単価、対象機能の一覧、前提条件、除外範囲、変更発生時の精算方法。分解を依頼したときの反応も判断材料になります。前提条件を整理して出し直してくれる会社は、社内で工数根拠を持っている会社です。逆に「内訳は出せない」「一式でお願いします」と押し戻す会社は、契約後の変更管理でも同じ姿勢になりがちです。
AIが書いたコードを誰がレビューし、品質を誰が保証するのか
生成AIが書いたコードは、動くけれど読みにくい、想定外の入力で挙動が崩れる、といった性質を持ちます。品質の分かれ目は、人間のレビューとテストで担保する仕組みがあるかどうか。AIを使っているかどうかではありません。
次の質問をそのまま投げてみてください。
- 生成AIの利用について社内ルールはありますか
- AIが生成したコードは誰がレビューしますか（役割と経験年数）
- テスト自動化はどこまで実施しますか
- 不具合が出た場合、無償で直す期間と範囲はどこまでですか
最後の点は契約書の話になります。契約不適合責任の期間と対象範囲を、口頭ではなく条文で確認してください。生成AIの利用そのものは、開発プロセスの透明性や説明責任の観点から整理が進んでおり、経済産業省・総務省「AI事業者ガイドライン」でも、開発・提供・利用の各主体に求められる考え方が示されています※2。
ソースコードの権利・学習データ・情報漏えい対策の確認項目
成果物の著作権が発注側に移るか。自社データが外部のAIサービスの学習に使われないか。この2点は必ず契約書で明文化します。口約束で進めると、他社へ移管したい段になって権利関係が障害になります。
- 成果物の著作権譲渡、またはライセンスの範囲と期間
- 第三者OSSおよび生成コードの権利上の扱い
- 利用する生成AIサービス名と、入力データの学習利用オプトアウト設定
- 社内データを外部サービスへ投入する範囲と方法
- 秘密保持の対象と期間
- 再委託の可否と、再委託先への義務の承継
顧客情報や従業員情報を扱う場合は、個人情報保護法上の取り扱い（委託先の監督、第三者提供に当たるかの整理）を事前に確認してください※3。テストデータとして本番の個人データをそのまま渡す運用は、社外サービスへの入力を伴う場面ではとくに注意が必要です。匿名化・仮名化した検証用データを用意できるかも、発注側の準備項目になります。
リリース後の保守と、他社へ引き継げる状態かどうか
保守費の目安は初期開発費の年10〜15%程度とされることが多いものの、対象範囲によって上下します。ただし、金額以上に効いてくるのは「他社でも引き継げる状態で納品されるか」です。ここが固定化リスクを決めます。
納品物にソースコード一式、設計書、環境構築手順、テスト仕様書が含まれるか。クラウドやドメインのアカウント権限が発注側名義になっているか。保守契約の対応範囲（障害対応のみか、軽微な改修まで含むか）と受付時間。担当者が交代した場合の引き継ぎ体制。この4点を契約前に確認しておくと、数年後の選択肢が残ります。
※2 経済産業省・総務省「AI事業者ガイドライン」リンク
※3 個人情報保護委員会「個人情報保護法」リンク
相見積もりが比較にならない理由と、比較できる状態にする準備
要件が固まっていない状態で相見積もりを取ると、各社が勝手に違う前提を置きます。その結果、金額差は実力差ではなく「想定した範囲の差」になり、比較の意味を失います。比較可能にする方法はひとつだけ。最低限の要件を書いた共通の依頼書を、全社に同じ条件で渡すことです。
同じ依頼なのに見積もりが3倍違うのはなぜか
金額差の正体は、次の4つに分解できます。
- 対象範囲の解釈差：画面数、帳票、連携先の数を各社が推測で置いている
- 非機能要件の想定差：同時利用人数、稼働率、セキュリティ水準、レスポンス要件
- 工程の含み方の差：要件定義・テスト・データ移行・保守を含むかどうか
- リスクバッファの差：不確実性が高いほど各社は保険を積む
曖昧な依頼を受けた会社の反応は二極化します。リスクを見て厚めに積むか、範囲を狭く読んで安く出すか。前者は「高い会社」に見え、後者は「安い会社」に見えます。実力ではなく読み方の差です。だからこそ、安い見積もりを見たときの最初の問いは「なぜ安いのか」ではなく「どこまで含んでいるのか」になります。
相見積もり前に最低限そろえる3つの情報
解決したい業務課題と現在の運用フロー、必須機能と「あったら良い機能」の区別、予算レンジ・希望時期・利用人数などの制約条件。この3点を書面にすれば、各社が同じ前提で見積もれます。分量はA4で数枚あれば十分です。
意外に思われるかもしれませんが、精緻な機能一覧より「現状の困りごと」のほうが有効です。今どの作業に何人で何時間かかっているのか。どこで転記ミスが起きるのか。これが書いてあると、提案側は代替案（既製サービスの活用や機能の絞り込み）を出せます。機能一覧だけだと、書かれたものをそのまま積算するしかありません。
予算を伝えると足元を見られるのでは、という懸念はよく聞きます。ただ、予算を伏せた依頼は範囲調整ができず、実現不可能な提案か、逆に過剰な提案が返ってくるだけです。「初年度は◯百万円台で考えている」程度のレンジで構いません。依頼書に入れる項目は次のとおりです。
- 会社概要と対象部署、利用人数
- 解決したい業務課題（現状の作業手順と所要時間）
- 必須機能／希望機能の区別
- 連携が必要な既存システム名と連携方法の希望
- 取り扱うデータの種類（個人情報の有無）
- 予算レンジと希望リリース時期
- 社内の体制（窓口担当、決裁者、検収の担当）
- 見積もりに含めてほしい工程の指定（要件定義・テスト・保守）
要件が固まっていない場合の進め方（要件定義を先に発注する）
要件が固まらないなら、開発一式で見積もりを取るのをやめて、要件定義フェーズだけを先に発注します。その成果物をもって改めて相見積もりを取るほうが、結果的に安く済みます。範囲が確定した見積もりは精度が上がり、リスクバッファも薄くなるからです。
分割発注の利点は3つあります。見積もり精度が上がること、要件定義の成果物を持って開発は別会社に依頼できること、そして途中で「やらない」と判断しても損失が小さいこと。費用の目安は全体の1〜2割程度に収まるケースが多いものの、業務の複雑さと関係部署の数で変わります。
注意点も押さえてください。要件定義の成果物（業務フロー、機能一覧、画面イメージ、非機能要件）を自社に帰属させる契約にすること。もうひとつは、その会社の実装しやすい構成に寄った要件定義になっていないかを見ることです。要件定義の段階で特定の製品ありきの記述が並んでいたら、理由を確認してください。
要件が固まる前段階から相談できますhikeに相談する
提出された見積もりで必ず確認する3点
前提条件、除外範囲、変更時の精算ルール。この3点がそろって初めて比較できます。金額を横に並べる前に、範囲をそろえる作業が先です。順序を逆にすると、安い会社を選んだつもりが、追加費用込みで一番高くなります。
各社に投げる質問はこの形で十分です。
- この見積もりに含まれない作業は具体的に何ですか
- 要件が追加された場合の単価と、承認のフローはどうなりますか
- テストはどこまで実施し、受入テストの支援は含まれますか
- 既存システムとの連携で、自社側が用意すべき資料や作業は何ですか
- リリース後、何を何日以内に対応する契約になりますか
返答を並べると、金額だけでは見えなかった差が出ます。除外範囲を即答できる会社は、社内で見積もり根拠を持っている会社です。
AI活用の外注でよくある失敗パターンと回避策
失敗の原因は「安さで選んだこと」そのものではありません。安い理由を確認しないまま契約したことです。典型は3つ。追加費用による予算超過、保守できないブラックボックス化、PoC止まり。いずれも契約前の合意事項で防げます。
初期費用は安かったのに追加費用で予算超過する
症状は、着手後に「それは範囲外です」が続き、都度追加見積もりが積み上がる状態。原因は範囲の曖昧さと、変更管理ルールの不在です。範囲が文書化されていないと、判断のたびに解釈がぶつかります。
回避策は3つ。契約前に除外範囲を文書化して合意すること。変更要求は口頭では着手せず、書面と見積もりを経てから進めるルールを最初に決めること。そして総額の10〜20%程度を予備費として確保しておくことです。予備費は「使う前提のお金」ではなく、判断を急がされないための余白と考えてください。「安い見積もり＝範囲が狭い見積もり」という前提で見れば、超過の多くは事前に読めます。
AIで素早く作れたが、社内の誰も保守できない
短期間で動くものができたのに、半年後に誰も中身を説明できない。生成AIを活用して実装スピードが上がった案件ほど、設計書やコメントが後回しになりやすい構造があります。作る速度に、記録する速度が追いつかないためです。
回避策は納品物と権限の押さえ方に尽きます。納品物一覧を契約書に明記する。ソースコードのリポジトリとクラウドアカウントを発注側の名義で保有する。開発中の定例で、仕様の意思決定を議事録として残す。引き継ぎ説明会の実施を検収条件に含める。この4つを最初に決めておけば、担当者が代わっても、会社を変えても、続きから進められます。
PoC・試作で終わり、本番運用まで届かない
試作は動いた、でも本番化の話が進まない。原因は、成功基準と運用設計を決めずに始めたことです。何が達成されたら次に進むのかが決まっていないと、「まあまあ動いた」で判断が止まります。
着手前に、本番化の条件を数値で合意してください。処理時間が何分以内になるか、判定の正答率が何%以上か、対象業務の何件を処理できるか。加えて、PoC段階から運用担当を巻き込み、業務フローのどこがどう変わるかを検討します。生成AIを使う機能なら、誤りを含む出力が出る前提で、人が確認する手順を業務側に組み込めるかが本番化の分かれ目です。PoC費用と本番開発費用の関係（PoCの成果物を本番で流用できるのか、作り直しになるのか）も、契約時に確認しておく項目です。
まとめ：AI活用の外注は「安くする」より「安くなる条件をそろえる」
AI活用は、条件がそろえば外注費を圧縮できます。ただし効き方は工程で違い、発注側の準備が整っていなければ、そもそも比較すら成立しません。要点を整理します。
- AIが効くのは実装・単体テスト・ドキュメント整形。要件定義と保守はほぼ下がらず、全体では1〜3割が現実的なレンジ
- 要件定義・テスト・ドキュメント・保守体制の4つを削った見積もりは、初期費用が下がるだけで総額は上がる
- 「AI活用」には開発プロセスに使う意味と、AI機能を作る意味の2種類がある。どちらの話かを最初に確認する
- 要件が固まらないうちの相見積もりは比較にならない。固まらないなら要件定義を分けて先に発注する
- 比較は金額ではなく、前提条件・除外範囲・変更時の精算ルールをそろえてから行う
次にやることは3つです。解決したい業務課題を現状の作業手順つきでA4一枚にまとめる。必須機能と希望機能を分ける。それでも要件が固まらなければ、要件定義の段階から相談先を探す。要件が曖昧な状態でも、業務の困りごとが説明できれば範囲の整理から始められます。
よくある質問
AIを使った開発なら納期はどのくらい短くなりますか
短縮されるのは主に実装とテストコード作成の期間で、プロジェクト全体の短縮幅は限定的です。要件を決める会議の日程、関係部署の承認、発注側の受入テストといった「人と組織の時間」は圧縮できません。3か月の案件が1か月になるというより、実装フェーズが数週間縮む、という感覚が近いでしょう。納期を優先するなら、AI活用より先に、意思決定の担当者を絞って会議のリードタイムを短くするほうが効きます。
社内にIT担当がいなくても外注できますか
できます。必要なのは技術者ではなく、業務を説明できる担当者が1人いることです。現状の作業手順、例外処理、繁忙期の運用を答えられる人が窓口になれば、要件は形になります。あわせて、決裁者と検収の担当を最初に決めてください。ここが曖昧だと、仕様の判断が滞って納期が延びます。技術的な判断が必要な場面では、開発会社に選択肢とメリット・デメリットを提示してもらい、業務観点で選ぶ形で十分です。
オフショアや低単価の会社とAI活用の会社では、どちらが安いですか
単価だけでは判断できません。見るべきは単価と手戻りコストの合計です。低単価でも、仕様の伝達に翻訳や詳細な指示書が必要なら、発注側の工数が増えます。指示が曖昧なまま進んで作り直しになれば、差額は簡単に消えます。逆に、仕様が明確で定型的な機能が多い案件なら、単価差がそのまま効きます。自社が仕様をどこまで文書で渡せるか。それが判断の分かれ目です。
ノーコードやSaaSで済ませたほうが安いのはどんなケースですか
会計、勤怠、経費精算のように業務が標準化されている領域は、既製のSaaSのほうが総額でも運用負荷でも有利です。開発を検討すべきなのは、自社独自の業務ルールが競争力の源になっている場合、既存システムとの連携が多い場合、SaaSでは扱えないデータ量や権限設計が必要な場合です。判断に迷うときは、「この業務ルールを標準に合わせられるか」を先に検討してください。合わせられるなら、SaaSが選択肢に入ります。
補助金は使えますか
IT導入補助金やものづくり補助金など、システム導入に利用できる制度は存在します。ただし対象経費や要件は公募回ごとに変わり、2026年時点の条件が翌年度も同じとは限りません※4。申請には事前の事業者登録や交付決定前の発注禁止といったルールがあるため、開発会社を決める前に確認するのが安全です。必ず最新の公募要領で対象範囲と締切をご確認ください。
契約は請負と準委任のどちらが良いですか
範囲が確定していれば請負、要件定義や試行段階なら準委任、という判断軸で考えます。請負は完成義務があり成果物の責任が明確ですが、要件が動くと変更契約が必要です。準委任は作業時間に対する契約で柔軟に進められる一方、成果物の完成は保証されません。要件定義フェーズを準委任で進め、範囲が固まった開発フェーズを請負に切り替える組み合わせが、実務では扱いやすい形です。
※4 独立行政法人中小企業基盤整備機構「IT導入補助金」リンク