AI開発コネクト
開発方式比較

既存システムにAIを後付けするか、作り直すか。費用と期間で分かれる5つの判断点

同じ依頼でも後付け前提と作り直し前提では見積もりが別物になります。データの持ち方、連携の経路、保守の主体、止められる時間、作り直す理由の5点で判断し、相見積もりで条件を揃える5行を示します。

公開: 2026.10.09 / 更新: 2026.10.09

社内で AI を使おうという話になると、たいてい対象は新規のサービスではなくすでに動いている業務システムである。受発注、在庫、顧客管理、問い合わせ履歴。そこで必ず出るのが「今のシステムに後付けできないか」と「この機会に作り直したほうが早いのではないか」の二択である。

この二択は好みの問題に見えて、実際には見積書の金額がいちばん大きく割れる分岐でもある。同じ「AI で問い合わせ対応を効率化したい」という依頼でも、後付け前提の会社と作り直し前提の会社では、提示される金額も期間も別物になる。ここでは判断の材料を 5 つに整理する。

2 つの進め方で、実際に何が違うのか

比較軸 既存システムに後付け 作り直して AI を組み込む
初期費用 小さい(AI 部分と連携部分だけ) 大きい(既存機能の作り直しを含む)
期間 短い(数か月) 長い(半年〜年単位)
止まるリスク 既存の動作に影響が出うる 移行時に集中する
伸びしろ 既存の作りに縛られる 設計から決められる
社内の手間 現場の業務は変わらない 業務の見直しと教育が要る
失敗したときの損 小さい 大きい

表だけ見ると後付けが有利に見える。ただし後付けが成立しない作りの既存システムが実際にあるため、判断点を順に見ていく。

古い木箱に外付けされた計器と、新しい箱に埋め込まれた計器を巻尺で測っている

判断点 1. AI に渡すデータが、既存システムの中でどう持たれているか

最初に見るのはここである。AI が扱えるのは、取り出せる形で入っているデータだけである。

  • 項目として分かれている(取引先コード、品目、数量、日付)→ 後付けしやすい
  • 自由記述の中に埋まっている(備考欄に納期も担当者も条件も書いてある)→ 取り出す処理が要る
  • 画面にしか無い(帳票として印刷され、元の値がどこにも残っていない)→ 作り直しの検討対象

2 つ目は後付けでも対応できるが、抽出の精度を測る工程が丸ごと増える。3 つ目に当てはまる項目が業務の中心にあるなら、AI の話の前にデータの持ち方の話になる。費用がどこで膨らむかはAI業務システムの費用相場に内訳を書いた。

判断点 2. データを出し入れする口があるか

次に、既存システムに外から触れる経路があるかを確認する。経路の種類で、後付けの難度と費用はかなり変わる。

経路 後付けのしやすさ 注意点
API が用意されている 高い 必要な項目が API に含まれているか
データベースを直接参照できる 中 保守元の許可と、更新時の整合
ファイル連携(CSV などの定期出力) 中 鮮度が落ちる。即時性が要る用途には向かない
画面操作の自動化しかない 低い 画面変更のたびに壊れる。保守費が積み上がる

いちばん下に当てはまる場合、後付けの初期費用は安く見えても、運用に入ってからの保守費で逆転することがある。見積書を比べるときは初期費用だけでなく、画面変更時の対応が保守に含まれるかを確認したい。

判断点 3. 既存システムを誰が保守しているか

技術の話よりこちらが効く案件は多い。既存システムを作った会社と、AI を頼む会社が別になるとき、次の 3 つが問題になる。

  1. 仕様書があるか。無ければ調査の工数が最初に乗る
  2. 改修の許可が出るか。保守契約で第三者の改修を制限している場合がある
  3. 不具合の切り分けを誰がやるか。AI を足したあとに既存機能が止まったとき、原因の所在で揉めやすい

3 つ目を契約で先に決めておかないと、運用開始後に止まる。分離して発注するか一括にするかの考え方は分離発注と一括発注に整理した。

判断点 4. いつ止められるか、どれだけ止められるか

作り直しは、どこかで必ず切り替えが要る。業務が 24 時間動いている、月末月初に止められない、繁忙期が決まっている。こうした制約は、作り直しの費用そのものより移行の費用を押し上げる。

  • 並行稼働の期間を取れるか(取れないなら一発勝負の移行になる)
  • 過去データをどこまで移すか(全件か、直近数年か)
  • 旧システムをいつ停止するか(残すなら二重の運用費がかかる)

ここを曖昧にしたまま作り直しの見積もりを取ると、移行が「別途」になった金額が出てくる。別途になりやすい項目はAI開発の見積書で「別途」になりやすい費用10個にまとめた。

判断点 5. 作り直しの理由を、AI だけで説明しようとしていないか

これがいちばん大事である。作り直しの費用は AI の部分だけでは回収できないことが多い。既存機能をもう一度作る費用が大半を占めるからである。

したがって、作り直しが妥当になるのはAI 以外の理由がすでにある場合である。

  • 保守している製品やミドルウェアの提供終了が決まっている
  • 障害や手作業での補正が常態化していて、現状維持の費用が見えている
  • 法令や取引先の要件で、どのみち改修が必要になっている
  • 使っている人が限界を感じていて、業務ごと見直す合意がある

これらが無いまま「古いから」で作り直すと、投資の説明がつかない。逆に 1 つでも当てはまるなら、その改修に AI を合わせて載せるほうが費用対効果は説明しやすい。安く仕上げる余地がどこにあるかはAI業務システムを安く作るに書いた。

迷ったときの進め方

二択で決めきれないときは、後付けで小さく始めて、作り直しの判断材料を集めるのが現実的である。

  1. 業務の一部だけを対象に、既存システムを変えずに AI を試す
  2. そこで分かったこと(データの質、取り出せない項目、精度の上限)を記録する
  3. 既存の作りが原因で頭打ちになった点を、作り直しの要件として書く

この順番なら、作り直しの判断が「感覚」ではなく「試した結果」に基づく。1 の段階で既存システムを改修してしまうと、その費用が無駄になることがあるので、最初は読み取りだけに留めるのが安全である。

相見積もりで条件を揃える 5 行

後付けと作り直しのどちらで提案されても比較できるよう、依頼時に次の 5 行を揃えておきたい。

  1. 既存システムの名称・稼働年数・保守している会社
  2. 取り出せるデータの経路(API/DB/ファイル/画面のみ)と、確認済みかどうか
  3. 既存機能のうち、今回変えてよい範囲と触ってはいけない範囲
  4. 止められる時間帯と、並行稼働を取れる期間
  5. 移行するデータの範囲(全件か、直近何年か)

この 5 行が無いと、各社は自社のやりやすい前提で見積もるため、金額差の理由が読めなくなる。無料で相見積もり・相談の案件票では、既存システムとの連携の有無や扱うデータの種類を選択式で揃えているので、後付けと作り直しの提案を同じ土俵に並べられる。

まとめ

後付けと作り直しは、どちらが優れているという話ではない。既存システムからデータを取り出せるかと、AI 以外に作り直す理由があるかの 2 つで、ほぼ決まる。

取り出せるなら後付けで始めればよい。取り出せない、あるいは別の理由ですでに改修が必要なら、その機会に合わせて組み込むほうが説明がつく。どちらにしても、既存システムの情報を先に揃えてから見積もりを取ることが、金額の比較を成立させる条件である。

AI開発の見積もりを、同じ条件で比べる。

条件を整理した 1 枚の案件票で複数のAI開発会社に依頼。初期費用だけでなく、データ整備・API 費・精度検証・保守・権利まで同じ列で比較できます。

無料で相見積もり・相談する →
無料で相見積もり・相談30秒で費用診断