見積書に記載された金額だけを予算として確保していたら、後から想定していなかった費用が次々と発生した、ということがあります。この記事では、見積書に載っていないことが多い、後から発生しやすい費用の項目を整理します。
この記事で分かること
見積書は、開発費そのものを示すものであり、開発・公開に関わるすべての費用を網羅しているとは限りません。この記事では、見積書の外側で発生しやすい費用を、具体的に紹介します。
なお、見積書を受け取った際にまず確認したいのは、その見積書自体がどこまでの範囲をカバーしているかという点だ。見積書の内訳の読み方では、含まれる範囲・含まれない範囲の見分け方を詳しく解説している。
結論を先に示すと、見落としやすい費用は次の4つです。
- サーバー・ドメインなどの運用インフラ費
- 決済・外部サービスの利用料
- 保守・追加改修の費用
- テスト・確認作業にかかる費用
「見積書に書かれている金額＝そのサービスにかかる総額」だと思い込んでしまうと、公開後に「聞いていなかった費用」が次々と発生し、当初の資金計画が崩れてしまいます。見積書というものの性質を正しく理解し、その外側にある費用を事前に洗い出しておくことが、個人・複業でサービスを立ち上げる際の資金計画の基本になります。
そもそも、なぜ見積書には「載っていない費用」が発生するのか
見積書に載っていない費用が発生する背景には、見積書というドキュメントの性質があります。開発会社が作成する見積書は、基本的に「依頼された機能を作るための人件費・作業費」を算出したものです。つまり、見積書は「作る費用」の見積もりであり、「動かす費用」「維持する費用」「変える費用」の見積もりではないケースが多いのです。
この違いを理解していないと、次のような誤解が生まれます。
- 「見積金額を払えば、サービスが完成してそのまま使い続けられる」という誤解
- 「開発が終わったら、もう追加の費用は発生しない」という誤解
- 「動作確認やテストは、開発費に自動的に含まれている」という誤解
これらの誤解は、開発会社が悪意を持って費用を隠しているというよりも、依頼者側と開発会社側で「見積書が指す範囲」の認識がずれていることから生じます。見積書を受け取ったら、まず「この金額はどこからどこまでを指しているのか」を確認する習慣を持つことが、後々のトラブルを防ぐ第一歩です。
見落としやすい費用1：サーバー・ドメインなどの運用インフラ費
開発会社の見積書は、多くの場合「システムを作る」ための費用を示していますが、そのシステムを実際に動かすための「サーバー」や「ドメイン」の費用は、別途発生することが一般的です。
これらの費用は、開発費と比べると一つひとつは小さい金額ですが、毎月継続的に発生する費用であるため、長期的に見ると無視できない金額になります。公開後の運用費の詳しい内訳については、別記事で解説しています。
具体的にどんな費用が発生するか
運用インフラ費として代表的なものには、次のようなものがあります。
- サーバー・ホスティング費：サービスを実際に動かすためのサーバーの利用料。利用者数やデータ量に応じて金額が変動することが多い
- ドメイン費：独自のURL（例：example.com）を取得・維持するための年間費用
- SSL証明書費：通信を暗号化するための証明書費用（無料のサービスもあれば有料のものもある）
- ストレージ・バックアップ費：画像やファイルなどのデータを保存する容量に応じた費用、データ消失に備えたバックアップの費用
- CDN・画像配信費：画像や動画などを高速に配信するためのサービス利用料
失敗パターン：利用者数が増えてから費用が跳ね上がる
よくある失敗パターンの一つは、サービス開始時は無料枠や低額プランで運用できていたのに、利用者数やデータ量が増えるにつれてサーバー費用が段階的に上昇し、想定していた運用費を大きく超えてしまうケースです。
多くのクラウドサーバーサービスは、利用量に応じた従量課金制を採用しています。開発時点では「月額数千円で足りる」と説明を受けていても、それは「利用者数が少ない前提」での金額であることが多く、サービスが成長するにつれて費用も比例して増えていきます。見積もりを受け取る際は、「今の規模」だけでなく「利用者が10倍になったときの費用感」も合わせて確認しておくと、後から慌てずに済みます。
見落としやすい費用2：決済・外部サービスの利用料
決済機能や、地図表示、メール送信といった機能を実装する場合、多くはAIやシステムが独自に作るのではなく、外部のサービス（決済代行会社、地図サービスなど）と接続して実現します。これらの外部サービスには、利用に応じた手数料や月額費用が発生することが一般的です。
見積書には、これらの外部サービスの費用が含まれていないことが多く、別途、利用規模に応じて費用がかかることを見落としがちです。外部サービスの費用については、別記事で詳しく解説しています。
具体的にどんな費用が発生するか
- 決済手数料：クレジットカード決済などを利用した際に、決済額に対して数％程度が手数料として差し引かれる
- 地図APIの利用料：地図表示や検索の回数に応じて、一定回数を超えると費用が発生する
- メール送信サービスの利用料：送信件数が一定数を超えると、従量課金が発生する
- SMS送信費：電話番号認証などでSMSを使う場合、送信1件ごとに費用がかかる
- 外部AI・API利用料：文章生成や画像認識など、外部のAIサービスを利用する場合の従量課金
失敗パターン：「無料プランでできる」が前提のまま契約してしまう
外部サービスには無料プランが用意されていることが多く、開発時のデモや初期の少人数利用では無料枠の範囲内に収まることがよくあります。しかし、無料プランには利用回数・送信件数・データ量などに上限が設けられており、サービスが順調に成長すると、ある時点から一気に有料プランへの切り替えが必要になります。
「無料でできると言われたのに、急に費用がかかるようになった」というトラブルの多くは、この上限を正しく把握していなかったことが原因です。見積もりの段階で、想定する利用規模において各外部サービスがどのプランに該当するのか、そのプランの費用がいくらなのかを、具体的な数字で確認しておくことが重要です。
見落としやすい費用3：保守・追加改修の費用
見積書が開発費のみを示している場合、公開後に発生する不具合対応や、追加の機能改修にかかる費用が、当初の予算に含まれていないことになります。
「開発が終わったら、もうお金はかからない」と考えていると、公開後に想定外の出費が発生し、予算が不足する事態に陥ることがあります。保守契約の内容については、開発会社とのつきあいかたのカテゴリで詳しく解説しています。
見積書に載っていない費用のなかでも、保守費用は特に金額の幅が大きく、開発費全体に対する比率で語られることが多い。保守費用の相場と内訳では、フルスクラッチ開発を前提とした相場感が整理されている。
保守費用に含まれることが多い内容、含まれないことが多い内容
一般的な保守契約でカバーされることが多い内容と、追加費用が発生しやすい内容を整理すると、次のようになります。
| 区分 | 内容の例 |
|---|---|
| 保守契約に含まれやすい | サーバー監視、簡易な不具合の修正、OS・ライブラリの更新対応 |
| 追加費用が発生しやすい | 新機能の追加、デザインの大幅な変更、外部サービスの仕様変更への対応、利用者からの要望に基づく改修 |
「保守契約に入っているから安心」と思っていても、その保守契約が具体的にどこまでの作業をカバーしているのかは、契約書や見積書の記載を確認しないと分かりません。特に「不具合修正」と「機能追加」の境界はあいまいになりやすく、開発会社によって判断が異なることがあります。
失敗パターン：軽微な要望のつもりが「追加改修」として課金される
サービス公開後、「ボタンの位置を変えたい」「表示する項目を1つ増やしたい」といった、依頼者側からすると軽微に感じられる要望が、開発会社側からすると「保守の範囲外の追加改修」として扱われ、都度見積もりが発生するケースがあります。
これは、依頼者と開発会社の間で「保守」の定義がすれ違っていることが原因です。契約前に、「軽微な変更はどこまで保守費用の範囲内で対応してもらえるのか」「範囲を超えた場合の課金単位（時間単位か、件数単位か）はどうなっているか」を具体的に確認しておくと、公開後のやり取りがスムーズになります。
見落としやすい費用4：テスト・確認作業にかかる費用
見積書に「テスト費用」という明確な項目がない場合でも、実際には、開発の各段階で動作確認・テストを行う作業が発生します。この作業自体に別料金が発生する場合もあれば、開発費に含まれている場合もあり、見積書の記載だけでは判断しづらいことがあります。
特に、複数のブラウザやスマートフォンでの表示確認、実際のデータ量を想定したテストなど、追加のテスト作業を依頼する場合、それが標準の見積もりに含まれているかどうかを、事前に確認しておくことをおすすめします。
追加のテスト費用が発生しやすい場面
- 対応するブラウザ・OSの種類を、当初の想定より増やしたいとき
- 実際の利用者数を想定した負荷テスト（大量アクセスに耐えられるかの確認）を行いたいとき
- 決済など、失敗すると金銭的な損害につながる機能について、念入りな確認を依頼したいとき
- 第三者によるセキュリティ診断を依頼したいとき
これらは、いずれも「品質を上げるための追加投資」としての性質を持つため、標準の見積もりの範囲を超えることが多い作業です。特に決済機能やユーザーの個人情報を扱うサービスでは、テスト・確認作業を軽視すると後から重大な問題につながる可能性があるため、必要な範囲のテストにはあらかじめ予算を割いておく判断も必要です。
見積もりを受け取った際に、確認すべき質問
見落としやすい費用を防ぐために、見積もりを受け取った際は、次のような質問を開発会社に投げかけることをおすすめします。
- 「このシステムを動かすために、開発費以外にかかる費用は何がありますか」
- 「決済や外部サービスを使う場合、その利用料は別途発生しますか」
- 「納品後、不具合が出た場合の対応は、この見積もりに含まれていますか」
- 「テスト・動作確認の費用は、この見積もりに含まれていますか」
これらの質問への回答を確認することで、見積書に記載されている金額の外側にある費用を、事前に把握できます。
確認チェックリスト
見積もりを受け取ったタイミングで、以下の項目にひとつずつ目を通しておくと、費用の見落としを防ぎやすくなります。
- [ ] サーバー・ドメイン・SSL証明書などの運用インフラ費が、見積もりに含まれているか、別途発生するか明記されている
- [ ] 利用者数やデータ量が増えた場合の、インフラ費の増額シミュレーションを確認した
- [ ] 決済・地図・メール送信など、利用する外部サービスの一覧と、それぞれの無料枠の範囲を確認した
- [ ] 外部サービスが有料プランに切り替わる条件（利用回数・件数の上限）を確認した
- [ ] 公開後の保守契約の有無と、契約に含まれる作業範囲（不具合対応・軽微な変更の範囲）を確認した
- [ ] 保守契約の範囲外となる作業の課金方法（時間単価・件数単価など）を確認した
- [ ] 想定するブラウザ・OSの範囲でのテストが、見積もりに含まれているか確認した
- [ ] 決済機能や個人情報を扱う機能について、追加のテスト・診断が必要かどうかを検討した
このチェックリストは、契約前だけでなく、契約後に追加の依頼をする際にも役立ちます。都度、「これは保守の範囲内か、追加費用が発生するのか」を確認する習慣をつけることで、想定外の出費を減らせます。
「予算のバッファ」を、あらかじめ確保しておく
見積書に記載された金額だけを予算として確保するのではなく、想定外の費用に備えて、一定のバッファ（余裕分）をあらかじめ確保しておくことをおすすめします。目安として、見積もり金額の10〜20%程度を、予備費として別途確保しておくと、想定外の費用が発生した際にも慌てずに対応できます。
自己資金300万円が何ヶ月分の運用に持つかを計算する方法については、別記事で詳しく解説しています。
バッファの考え方の目安
バッファの割合は、サービスの性質によっても変わります。次のような観点で、余裕を持たせる割合を調整すると良いでしょう。
- 決済や外部サービスとの連携が多いサービスほど、外部要因による費用変動のリスクが高いため、バッファは多めに（20%程度）確保する
- すでに似たようなサービスを何度も開発した経験のある開発会社に依頼する場合は、想定外の費用が発生するリスクが比較的低いため、バッファはやや少なめ（10%程度）でも対応しやすい
- 専門分野の業務知識を反映した独自性の高いツールほど、前例が少なく費用の見通しが立てにくいため、バッファは多めに確保しておく
専門知識を活かしたツールで、見落としやすい費用
専門分野の業務知識を反映したツールの場合、専門的なデータの保存・処理に必要な、通常より高性能なサーバーが必要になることがあります。一般的なMVP（実用最小限の製品）を想定した見積もりでは、この点が見落とされやすく、後から追加のインフラ費用が発生する可能性があります。
専門知識を活かしたツールを検討する際は、開発会社との打ち合わせで、扱うデータの量や処理の複雑さを具体的に伝え、それに対応したインフラ費用の見通しを、早い段階で確認しておくことをおすすめします。
たとえば、専門的な計算処理を頻繁に行うツールや、大量の画像・文書データを扱うツールでは、一般的なWebサービスよりもサーバーの処理能力（CPU・メモリ）やストレージ容量を必要とすることがあります。こうした要件は、開発の初期段階では見えにくく、実際に利用者が増えてデータ量が積み上がってから、インフラの増強が必要になって初めて費用として表面化するケースが少なくありません。専門知識を活かしたツールの価格設定を考える際は、こうした将来的なインフラ費用の増加も見込んでおく必要があります。
店舗の業務改善ツールで、見落としやすい費用
店舗の業務改善のためのツールでは、将来的に複数店舗での利用を想定している場合、店舗ごとにデータを分ける設計（マルチテナント化）に伴う追加費用が、当初の見積もりに含まれていないことがあります。
最初は自分の店舗だけで使う想定で見積もりを取っていても、後から他店舗への展開を考え始めた場合、当初の設計を作り直す必要が出て、想定以上の追加費用がかかることがあります。将来の展開予定があるなら、その旨を最初から伝えておくことで、こうした見落としを防げます。
マルチテナント化とは、1つのシステムを複数の利用者（この場合は複数の店舗）が、それぞれ独立したデータとして利用できるようにする設計です。最初から複数店舗での利用を想定して設計しておけば、後からの追加費用は比較的抑えられますが、単一店舗向けに作られたシステムを後からマルチテナント対応に改修する場合は、データベースの構造自体を見直す必要が生じることが多く、当初の開発費に近い規模の追加費用がかかることもあります。
「まずは1店舗で試してみて、うまくいったら他店舗にも展開したい」という考え方自体は自然なものですが、開発会社に依頼する時点で「将来的に他店舗展開の可能性がある」ということだけは伝えておくと、設計段階で最低限の準備をしてもらえる可能性があります。
具体例で見る「見積書の外側」の費用感
抽象的な説明だけではイメージしづらいため、個人・複業で立ち上げる小規模なWebサービス（利用者数百人規模を想定したMVP）を例に、見積書の外側で発生しやすい費用の目安感を整理します。金額はサービスの内容や規模によって大きく変わるため、あくまで「こういう種類の費用が、こういう頻度で発生する」という考え方の参考として捉えてください。
- 運用インフラ費：サーバー・ドメイン・SSL証明書などをまとめて、月々数千円〜数万円程度から始まり、利用者数やデータ量の増加に応じて段階的に上昇していく
- 決済手数料：決済代行サービスを利用する場合、決済金額に対して数％程度が手数料として差し引かれる。売上が増えるほど手数料の総額も増える
- 外部サービス利用料：地図表示やメール送信は、少人数のうちは無料枠に収まることが多いが、利用者数が一定を超えると月額の従量課金が発生し始める
- 保守費用：不具合対応や軽微な修正を依頼できる保守契約を結ぶ場合、月額固定費または都度課金のいずれかの形で費用が発生する
- 追加改修費：新機能の追加やデザイン変更は、その都度、作業内容に応じた見積もりが発生する
これらを合計すると、開発費とは別に、毎月一定額の「維持費」がかかることになります。開発費という一度きりの大きな支出だけを見て資金計画を立てると、この毎月の維持費を見落としがちなので、開発費とは別の「運用予算」の枠を、資金計画のなかにあらかじめ用意しておくことをおすすめします。
開発会社との打ち合わせで、費用の内訳を明確にする進め方
見積書を受け取った段階で不明点をすべて解消しようとするのではなく、打ち合わせの中で段階的に費用の内訳を明確にしていく進め方も有効です。具体的には、次のような順番で確認を進めると、抜け漏れが少なくなります。
- 見積書に記載されている作業内容を、一つひとつ確認する：「この項目は具体的に何をする作業ですか」と質問し、金額の根拠となる作業内容を明らかにする
- 見積書に記載されていない項目を、カテゴリごとに質問する：運用インフラ費、外部サービス利用料、保守費用、テスト費用の4つについて、それぞれ「これは含まれていますか、別途ですか」と確認する
- 別途発生する費用について、金額の目安を聞く：「別途」と回答された項目については、「だいたいどれくらいの金額を想定しておけばいいですか」と、具体的な金額の目安を確認する
- 確認した内容を、文書やメールで残す：口頭でのやり取りだけで終わらせず、確認した内容をメールなどの文書に残しておくと、後から「言った・言わない」のトラブルを防げる
この進め方は、開発会社に対して失礼にあたるものではありません。むしろ、費用の範囲を明確にしておくことは、依頼者と開発会社の双方にとって、後々のトラブルを避けるために有益な作業です。誠実な開発会社であれば、こうした質問に対して具体的に回答してくれるはずです。逆に、これらの質問に対して曖昧な回答しか得られない場合は、その開発会社との契約自体を慎重に検討する材料にもなります。
「見積もりが安い」ことの裏に、見落とされた費用が隠れていることもある
複数の開発会社から見積もりを取った際に、極端に安い見積もりを提示された場合は、その安さの理由を確認することをおすすめします。安い見積もりの背景には、次のような事情が隠れていることがあります。
- 運用インフラ費・保守費用・テスト費用など、この記事で紹介した項目がそもそも見積もりの対象に含まれておらず、開発費のみを示した金額になっている
- 想定している機能の範囲が、依頼者の想定よりも狭く設定されている
- 使用する技術やサービスの選定によって、後から拡張しにくい構成になっている（結果として将来の改修費用が高くなりやすい）
「安いから」という理由だけで開発会社を選んでしまうと、開発費自体は抑えられても、その後の運用費・保守費・追加改修費が積み重なり、結果的に総コストが高くなってしまうことがあります。見積もりを比較する際は、金額の大小だけでなく、「その金額がどこからどこまでをカバーしているのか」を必ず確認したうえで判断することが重要です。
見積書の外側にある費用を、契約書に落とし込んでおく
打ち合わせで確認した内容は、最終的に契約書や発注書といった正式な文書に落とし込んでおくことをおすすめします。口頭やメールでのやり取りだけでは、時間が経つと「そんな説明は受けていない」という認識の齟齬が生まれることがあります。
契約書に明記しておきたい項目の例を挙げると、次のようなものがあります。
- 開発費に含まれる作業内容の範囲（どの機能・どの工程までが対象か）
- 運用インフラ費・外部サービス利用料が、開発費とは別に発生することの明記
- 保守契約を結ぶ場合の、契約期間・月額費用・作業範囲
- 保守範囲を超える追加改修が発生した場合の、見積もり・課金の方法
- テスト・動作確認の範囲と、対象外の作業が発生した場合の対応
これらの項目は、開発が始まる前の段階で確認し、文書に残しておくことで、公開後に「聞いていなかった費用」が発生するリスクを大きく減らすことができます。特に個人・複業でサービスを立ち上げる場合、法務担当者がいないことが多いため、依頼者自身がこうした契約内容を丁寧に確認する意識を持つことが重要です。
資金計画に「見えない費用」を組み込む考え方
この記事で紹介した4つの費用項目は、いずれも「開発が終わった後」に発生し続ける性質を持っています。個人・複業でサービスを立ち上げる場合の資金計画は、次の3つの層に分けて考えると整理しやすくなります。
- 開発費：サービスを立ち上げるまでの、一度きりの大きな支出
- 運用維持費：サーバー・ドメイン・外部サービス利用料など、サービスを続ける限り毎月発生する支出
- 改修・保守費：不具合対応や機能追加など、不定期に発生する支出
多くの人は、資金計画を立てる際に「開発費」だけに注目してしまいますが、実際にサービスを軌道に乗せるまでには、この3つの層すべてを合算した費用を用意しておく必要があります。特に、サービスが軌道に乗るまでの期間（利用者が増え、収益が安定するまでの期間）は、運用維持費・改修費を売上でカバーできず、自己資金から支出する状態が続くことも珍しくありません。開発費だけでなく、この期間を乗り切るための運用維持費・改修費も含めた総額を、資金計画の出発点として見積もっておくことが、無理のないサービス立ち上げにつながります。
まとめ：見積書は「作る費用」であり「続ける費用」ではない
見積書に記載されている金額は、多くの場合「システムを作る」ための費用であり、そのシステムを「動かし続ける」ための費用や、「変え続ける」ための費用は、別途発生することが一般的です。この記事で紹介した4つの見落としやすい費用――運用インフラ費、外部サービス利用料、保守・追加改修費、テスト・確認作業費――を事前に確認し、見積もり金額の10〜20%程度のバッファを予算に組み込んでおくことで、公開後の想定外の出費に慌てずに対応できるようになります。
見積もりを受け取ったら、金額の大小だけでなく、「この金額はどこからどこまでを指しているのか」を必ず確認する。この一手間が、個人・複業でのサービス立ち上げを、無理のない資金計画のもとで進めるための土台になります。
この記事の次に読みたい記事
見落としやすい費用を理解したら、次は具体的な運用費の内訳についても確認しておきましょう。あわせて次の記事も参考にしてください。
見積もり比較や契約項目の削り方については、複業検証型、開発費を抑えるために削ってよい契約項目とだめな項目も参考にしてください。
