相見積もりで比べるべき数字は、見積書の合計金額ではありません。5年分の総額です。 そして総額で差がつく箇所は、金額欄ではなく前提条件欄に書かれています——保守の範囲、インフラの契約名義、外部サービスの名義、データの取り出しやすさ。この4つが違えば、初期費用が安いほうが5年後に高くつくことは珍しくありません。
この記事は、見積書に載らない費用を洗い出し、5年分を自分で積み上げ、相見積もりを総額で比較できるようにするための実務ガイドです。金額の相場そのものは費用相場と見積もりの内訳で、比較の進め方は相見積もりの取り方で扱っています。本稿は稼働したあとに効いてくる費用に集中します。
1. 結論：見積書は「初日までの費用」しか書いていない
見積書が答えているのは「作るのにいくらかかるか」です。発注者が本当に知りたいのは「これを持ち続けるのにいくらかかるか」です。この2つは別の問いで、後者に答える書類は通常どこからも出てきません。
作る側に悪意があるわけではありません。見積書は依頼された範囲の作業を積算する書類なので、依頼していない「3年後のライブラリ更新」は書きようがない。だからこそ、総額を出す責任は発注者側にあります。
構造としてはこうなります。
総コスト（5年） = 初期開発費
+ 保守費 × 60ヶ月
+ インフラ費 × 60ヶ月
+ 外部サービス利用料 × 60ヶ月
+ 自社側の運用人件費 × 60ヶ月
+ データ移行費（初回）
+ 撤退・移行費（最後に1回）
見積書に載るのは1行目だけです。残り6行は、聞かなければ誰も教えてくれません。
2. なぜ「5年」で見るのか——税務がそう決めている
期間の置き方は恣意的に見えますが、根拠があります。国税庁のタックスアンサー No.5461 は、ソフトウエアの耐用年数をこう定めています。
1 複写して販売するための原本または研究開発用のものについては、3年 2 その他のものについては、5年
— 国税庁「No.5461 ソフトウエアの取得価額と耐用年数」
自社の業務で使うために作ったシステムは「その他のもの」に当たり、5年です。税法は「5年で価値を使い切る」前提を置いている、ということになります。
ただしここで止めると誤読します。5年は税務上の償却期間であって、技術的な寿命ではありません。 実態はもっと長い。
経済産業省のDXレポートは、日本情報システム・ユーザー協会（JUAS）の調査を引いてこう記しています。
企業が保有する「最も大きなシステム」（≒基幹系システム）が、21年以上前から稼働している企業の割合は20％、11年〜20年稼働している企業の割合は40％。
— 経済産業省「DXレポート」（2018年9月）脚注／出典：JUAS「企業IT動向調査報告書 2016」
6割の企業が、11年以上前に作ったシステムをまだ使っています。（この調査の回答企業は東証上場企業クラスなので、中小企業そのものの数字ではありません。ただし「作ったものは想定より長く使われる」という傾向は規模を問わず共通です。）
税法は5年で償却させ、現場は11年から20年使う。この落差が、そのまま「見積書に出てこないコスト」の正体です。 償却が終わった6年目以降も、保守費もサーバー代も外部サービス料も止まりません。
ここから2つのことが導けます。
- 比較期間は最低でも5年。 3年で比較すると保守費の重みを過小評価します。そして5年でもなお控えめだ、というのが上のデータの意味です。
- 5年より早い作り直しは、想定より高い買い物だったという意味になります。 償却が終わる前に捨てる資産だからです。発注時点で「これは何年使うつもりか」を言語化しておくと、後から効いてきます。
補足すると、この「長く使われる」傾向は開発現場の側からも見えます。IPAが集計した1,479プロジェクトのうち、**新規開発は29.1％にとどまり、既存システムへの改修・保守が51.5％**を占めます（2016〜2021年度の開発データ。2014〜2019年度の45.8％から増加）。件数ベースの割合であって金額比ではありませんが、開発という営みの半分以上は、すでに動いているものの手入れだという事実は、発注前に知っておく価値があります。
なお、取得価額の扱いにも同ページに例外規定があります。研究開発費や、製作原価のおおむね3パーセント以内の少額な間接費・付随費用は取得価額に算入しないことができるとされています。会計処理の詳細は顧問税理士の領域ですが、「開発費として払った金額」と「資産計上される金額」は一致しないことがあるという点だけは、資金計画上知っておく価値があります。
3. 見積書に出てこない6つの費用
順に見ていきます。前半3つは「見積書に項目はあるが金額が小さく見える」もの、後半3つはそもそも項目自体が存在しないものです。後者のほうが危険です。
3-1. 保守費——月額ではなく「月額 ÷ 範囲」で見る
保守費は見積書に載ることが多い費用です。問題は金額ではなく範囲です。
同じ「保守費 月5万円」でも、中身は大きく分かれます。
| 契約に含まれがちなもの | 別料金になりがちなもの |
|---|---|
| 障害発生時の一次対応 | OS・ライブラリ・フレームワークの更新 |
| 稼働監視・バックアップ確認 | 依存パッケージの脆弱性対応 |
| 軽微な設定変更 | 決済・外部APIの仕様変更への追随 |
| 問い合わせ対応（時間帯・回数の制限つき） | 画面や帳票の追加・変更 |
右列は「起きるかどうか」ではなく「いつ起きるか」の話です。ライブラリの更新は必ず来ますし、決済代行の仕様変更も外部都合で来ます。右列が全部別料金の契約は、月額が安くても追加見積もりが常態化します。
確認すべき問いはひとつです。「この保守契約に含まれない作業を、具体的に列挙してください」。含まれるものを聞くと営業的な回答になりますが、含まれないものを聞くと契約の輪郭が出ます。
3-2. インフラ費——「誰の名義で契約するか」が総額を決める
サーバーやクラウドの費用そのものは、規模が読めていれば見積もれます。総額を左右するのは金額ではなく契約名義です。
- 自社名義：クラウド事業者から直接請求が来る。金額の内訳が見え、開発会社を替えても環境はそのまま残る。
- 開発会社名義：開発会社経由で請求が来る。管理手数料が乗ることがあり、そして開発会社を替えるときに環境ごと移設が必要になる。
後者が悪いわけではありません。運用を任せる前提なら合理的です。ただし乗り換えコストが将来の自分に請求される、という点は理解して選ぶべきです。この判断は稼働後には覆せません。
3-3. 外部サービスの利用料——積み上がると保守費を超える
いまどきの業務システムは、外部サービスの上に乗っています。決済、メール配信、SMS、地図、帳票生成、認証、エラー監視。それぞれは月数千円でも、5〜10個積み上がれば保守費を上回ります。
そして多くは従量課金です。ユーザーが増えれば増える。事業がうまくいくほど上がる費用なので、「成功したときにいくらになるか」を発注前に一度計算しておいてください。単価と課金単位（1件あたりか、1,000件あたりか、アクティブユーザー数か）を聞けば、その場で概算できます。
ここも契約名義が効きます。決済サービスを開発会社名義で契約していると、売上金の入金先が自社でないという事態になり得ます。決済だけは必ず自社名義にしてください。
3-4. 自社側の運用人件費——見積書に項目自体が存在しない
これが最も見落とされます。システムを入れると、自社側に新しい仕事が生まれます。
- マスタデータの登録・更新
- 利用者からの問い合わせ一次受け
- 月次の締め処理・帳票確認
- 新入社員への使い方レクチャー
月10時間でも年120時間です。担当者の時給を3,000円とすれば年36万円、5年で180万円。中規模システムの保守費に匹敵する規模が、見積書のどこにも書かれないまま発生します。
これは「隠された費用」ではなく「自社が負う仕事」なので、開発会社を責める筋ではありません。ただし総額に入れないと比較を誤ります。現場の運用が楽になる設計に少し多く払うことは、5年で見れば安くつくという判断が、ここを数えて初めて可能になります。
3-5. データ移行費——「今あるデータ」は必ず汚れている
既存のExcelや旧システムからデータを移すとき、作業量を決めるのは件数ではなくデータの汚れ具合です。表記ゆれ、重複、必須項目の空白、Excelのセル結合。移行スクリプトを書く時間より、どう寄せるかを決める時間のほうが長くかかります。
そしてこの判断は開発会社にはできません。「この2件は同じ取引先か」を知っているのは発注者側だけだからです。移行費が安い見積もりは、データが綺麗である前提を置いている可能性があります。サンプルを実際に見てもらってから金額を出してもらってください。
3-6. 撤退・移行費——契約書に書いていなければ、後から交渉になる
いつかは乗り換えます。そのとき何が起きるかは、契約時に決めておかないと後から交渉になります。交渉は、乗り換えたい側が不利です。
契約書に入れておく条項は3つです。
- データの返還形式（CSV・JSON など機械可読な形式で、全テーブル分)
- 返還の期限と費用（無償か、有償ならいくらか）
- ソースコードの扱い（納品物に含むか、使用許諾か）
3つ目は特に、契約形態によって前提が変わります。詳しくは契約形態の選び方を参照してください。
4. 5年TCOの計算シート
そのまま使える形にします。相見積もりを取ったら、各社ぶんこの表を埋めてください。
| 費目 | 初期 | 月額 | 5年計（初期 + 月額×60） | 誰が払うか |
|---|---|---|---|---|
| 初期開発費 | — | — | — | 自社 |
| 保守費 | — | — | — | 自社 |
| クラウド・サーバー | — | — | — | 名義を確認 |
| 外部サービス利用料 | — | — | — | 名義を確認 |
| 自社の運用人件費 | — | — | — | 自社 |
| データ移行費 | — | — | — | 自社 |
| 撤退・移行費（想定） | — | — | — | 契約条項を確認 |
| 合計 |
埋めるときのコツを3つ。
- 空欄を残さない。 分からない欄は開発会社に聞く。聞いても出てこない欄は「見積もれない不確実性がある」というシグナルなので、そこを0円として比較してはいけません。
- 従量課金は2通り計算する。 現状の利用量と、事業計画上の目標利用量。後者で破綻する設計なら、成功したときに困ります。
- 人件費は時間で書く。 金額に変換する前に「月何時間の作業が増えるか」を開発会社に見積もってもらうと、答えが具体的になります。
5. 総コストで差が出る4つのポイント
相見積もりを並べたとき、5年総額の差が生まれる箇所はほぼこの4つに集約されます。いずれも金額欄ではなく前提条件欄に現れます。
ポイント1：保守の範囲定義
前述のとおり、含まれない作業の列挙で判断します。範囲が明確で月額が高い会社と、範囲が曖昧で月額が安い会社では、後者のほうが総額が読めない。読めない見積もりは、安いのではなくリスクが移転されているだけです。
ポイント2：インフラの契約名義
自社名義なら乗り換え時の移設が要りません。開発会社名義なら手数料と移設費が将来かかります。5年のうちに開発会社を替える可能性が少しでもあるなら、この一点で数十万円単位の差が出ます。
ポイント3：外部サービスの契約名義
決済は必ず自社名義。それ以外も、自社名義にできるものは自社名義に寄せておくと、乗り換え時にアカウントを引き継ぐだけで済みます。開発会社名義だと、同じサービスを契約し直して設定を作り直すところからになります。
ポイント4：データの取り出しやすさ
「エクスポート機能はありますか」ではなく、「全テーブルを機械可読な形式で、いつでも自分で取り出せますか」と聞いてください。管理画面から1画面ずつCSVを落とす方式は、データが増えると実質的に取り出せません。API経由か、DBのダンプを定期的に自社ストレージへ置く仕組みがあると、乗り換えも、バックアップも、将来の分析も同時に解決します。
この4つは、開発が始まってからでは変えられません。総コストは発注後には下げられず、発注前の設計判断でしか下がらないというのは、この意味です。
6. 補助金の落とし穴：クラウド利用料は最大2年分
補助金を前提に発注する場合、期間のずれに注意が必要です。デジタル化・AI導入補助金2026（通常枠）の補助対象経費は、公式にこう定められています。
買取形式及び月額・年額で使用料金が定められている形態の製品（サブスクリプション販売形式等）は最大２年分の費用を補助対象とする。
カテゴリー７（保守サポート）については、ソフトウェアの利用範囲内で、最大２年分の費用を補助対象とする。
— デジタル化・AI導入補助金2026 公募要領（通常枠）
ここで、よくある誤解を1つ正しておきます。保守費用は補助対象外ではありません。 対象です——ただし2年で切れる。クラウド利用料も同じく2年分。なお保守サポートを含む「大分類Ⅲ 役務」の補助対象経費には200万円の上限があります。
「対象外だから最初から見積書に載る」なら、まだ気づけます。厄介なのは2年だけ面倒を見てもらえるせいで、3年目の崖が見えなくなることです。
ここで前節の耐用年数と突き合わせてください。
| 期間 | |
|---|---|
| 法定耐用年数（自社利用ソフトウェア） | 5年 |
| 補助対象となるクラウド利用料 | 最大2年分 |
| 自己負担が確定している期間 | 残り3年分 |
補助金は初期導入の背中を押す制度であって、運用費を恒久的に肩代わりする制度ではありません。 「補助金が出るから月額も大丈夫」という資金計画は、3年目に破綻します。逆に言えば、3年目以降の月額を自力で払える事業計画があるなら、補助金は素直に有利です。
補助金の入金タイミングそのものも資金繰りに効きます。これは補助金の後払いと資金繰りで詳しく扱っています。制度の補助率・上限・対象経費は公募回ごとに変わるため、必ず最新の公募要領で確認してください。筆者は登録支援事業者ではなく、申請代行も行っていません。
7. 総コストを下げる3つの設計判断
最後に、発注前に決められることを3つ挙げます。いずれも「安く作る」話ではなく「持ち続けやすく作る」話です。
1. 作らない部分を決める。 会計、勤怠、CRM のような一般業務は、既製のSaaSのほうが総コストで勝ちます。保守もアップデートも提供側が持つからです。スクラッチで作る価値があるのは、その会社固有の業務フローだけ。この線引きは内製・外注・SaaSの判断で扱っています。
2. 標準的な技術を選ぶ。 珍しい技術で作られたシステムは、保守できる人が少ないぶん保守費が上がり、乗り換え先も減ります。「速く作れる」より「引き継げる」を優先してください。判断材料は技術選定のフレームワークにまとめています。
3. 運用の手間を仕様に書く。 「管理画面からマスタを一括更新できる」は、開発時に数十万円かかっても、5年分の運用人件費を上回って回収できることがあります。3-4 で人件費を時間で数えたのは、この比較を可能にするためです。
まとめ：比べるのは金額ではなく「5年後の姿」
要点を3つに畳みます。
- 見積書は初日までの費用しか書いていない。 保守・インフラ・外部サービス・自社人件費・データ移行・撤退費の6つを足して、初めて総額になります。
- 5年で比べる。 自社利用ソフトウェアの法定耐用年数が5年（国税庁 No.5461）である以上、それが自然な比較期間です。
- 差は前提条件欄に出る。 保守の範囲、インフラの名義、外部サービスの名義、データの取り出しやすさ。この4つは発注前にしか決められません。
初期費用が安いことは、それ自体は良いことです。ただし安さの理由が「あとで払う」ことなのか「本当に効率的」なのかは、5年分を並べてみないと区別できません。並べてみて総額でも安いなら、それは良い見積もりです。
発注前に判断材料を揃えたい場合は、発注前チェックリストを用意しています。個別の案件で「この見積もりの総額をどう見るか」を相談したい場合は、無料DX診断（30分）で、優先順位と概算費用レンジまで整理してお返しします。