「で、いくらですか」に即答できない理由──開発費用を動かす6つの要因を、発注する側の言葉で

「うちの業務を効率化したいんですが、いくらくらいかかりますか」

いちばん多い質問です。そして、その場で総額をお答えできません。

これは、はぐらかしているわけではありません。同じような依頼でも、条件次第で金額が数倍変わるからです。適当な数字を言って、後から「実は追加で」と言うほうが、よほど不誠実だと思っています。

ただし——「何が価格を動かすのか」なら、いまこの場で説明できます。 そしてそれを知っていれば、自分の案件が高くなる側か安くなる側か、自分で見当をつけられます。

この記事は、その分解です。

---

まず、出せる数字は出します

「価格が出せない」と言う前に、固定されているものは先に出します。

内容	費用	所要
無料相談	0 円	15〜30 分
業務診断（ヒアリング＋診断レポート＋ MVP 案＋概算見積もり）	20,000 円<br>※要件定義に進む場合は全額充当	ヒアリング 60〜90 分／レポートは 3 営業日以内
要件定義	都度お見積もり	規模により変動
MVP 開発	都度お見積もり	小規模なら最短 2 週間
運用改善・伴走	月額 200,000 円	週 1 回または隔週の定例

固定できるものは固定しています。固定できないのは、要件定義と開発だけです。そしてそれには理由があります。

なお業務診断は、そのまま要件定義に進む場合、診断料を全額お見積もりから差し引きます。診断は単体の商品ではなく、プロジェクトの最初の 1 工程という位置づけだからです。「診断だけ受けて終わり」でも構いませんし、その場合もレポートはお渡しします。

---

なぜ、開発だけ先に金額を出せないのか

理由は単純です。開発費用の大半は人件費で、人件費は作業時間で決まるからです。

そして作業時間は、何を作るかが決まって初めて計算できます。

「業務を効率化したい」の時点では、まだ何も決まっていません。同じ「在庫管理を楽にしたい」でも——

• 今の Excel を整理するだけで済むのか
• 入力の仕組みを作るのか
• 既存の販売管理システムと繋ぐのか
• 複数拠点で同時に使うのか

これで、かかる時間は 10 倍以上違います。この段階で「100 万円です」と言う会社があったら、それは当てずっぽうか、後で追加を取る前提のどちらかです。

だから私たちは、工程ごとに見積もり、工程ごとに請求します。要件定義が終わった時点で、開発の金額が確定する。それまでは確定しません。

---

価格を動かす 6 つの要因

ここからが本題です。規模ではなく、これらが金額を決めています。

1. 既存システムと繋ぐか

いちばん影響が大きい要因です。

繋がない場合——新しく作るものだけを考えればいい。作業量が読めます。

繋ぐ場合——相手側の都合に全部左右されます。

	安くなる側	高くなる側
接続先	繋がない（単体で完結）	既存の基幹システム、会計ソフト、外部サービス
相手の仕様	API が公開されている	API が無い／仕様書が残っていない
作った人	連絡が取れる	退職済み・会社が無い
データの出し方	CSV などで出せる	画面をコピーするしかない

API が無いシステムと繋ぐのは、費用が跳ね上がる典型です。正面の入口が無いので、裏口を探す作業になります。

実際に当たった案件

私たちが実際に当たったのは、古いサイトへの入力作業でした。jQuery で作られた時代のもので、API はありません。担当者が毎回、手で入力していました。

このとき解決策を教えてくれたのは、お客様の取引先の方でした。Python で画面の操作そのものを自動化するという手です。ブラウザを機械が動かして、人がやっていた入力を代わりにやる。

実装して、さらにその操作を管理する画面まで作りました。結果として、API が無いシステムに対しても自動化ができています。

ただし、正直に書いておきます。これは正面の入口が無いぶん、裏口から入る方法です。 画面の作りが変われば壊れます。だから「API がある場合」と同じ費用では見積もれませんし、保守の前提も変わります。

「API が無いから無理」ではありません。でも「API がある場合と同じ」でもありません。 ここが見積もりで分かれるところです。

2. データが整っているか

技術的負債の記事で書いた通り、AI もシステムもデータの上にしか乗りません。

整っていない場合、まずデータを整える工程が要ります。そしてこれは、依頼者から見ると「何も新しいものができていない」期間になります。

	安くなる側	高くなる側
形式	統一されている	部署ごと・年ごとにバラバラ
重複	一意に決まる	同じ顧客が複数の表記で存在
保管場所	1 か所	各自の PC、共有フォルダ、紙が混在
表記ゆれ	無い	「株式会社 ABC」「（株）ABC」「ABC」が混在

実際に当たった案件

私たちが当たったのは、日付と ID の全角・半角がバラバラという事案です。

２０２６／０８／１６ と 2026/08/16 が、同じ列に混在している。人が見れば同じだと分かりますが、機械にとっては完全に別のものです。ID も同様で、全角の Ａ１２３ と半角の A123 は繋がりません。

こうなっていると、まず揃える工程が要ります。そしてこの工程は、依頼者から見ると「何も新しいものができていない」期間になります。だから省きたくなる。でも省くと、その後に作るものが全部その上に乗るので、後で必ず戻ってきます。

ここは発注前に自社でできる部分でもあります。表記を揃えておくだけで、費用は確実に下がります。

3. 例外を、どこまで作り込むか

ここが最も見落とされ、そして最も金額を動かします。

どんな業務にも「たいていはこう」と「でも、たまにこういうことがある」があります。そして——

9 割のケースを処理する仕組みと、残り 1 割の例外を処理する仕組みは、同じかそれ以上の手間がかかります。

たとえば「請求書を自動で作る」。

• 通常の請求——簡単です
• 月をまたぐ契約は？
• 途中解約の日割りは？
• 値引きが入る場合は？
• 請求先と契約先が違う場合は？
• 過去にさかのぼって修正するときは？

例外を全部拾おうとすると、費用は倍以上になります。 そして皮肉なことに、その例外は年に数回しか起きなかったりする。

だから私たちは、「例外は人がやる」という選択肢を必ず提示します。9 割を自動化して、残りは今まで通り手でやる。

これは実際にそう作っています。問い合わせ対応を AI で一次受けする仕組みでは、定型的な問い合わせまでを自動にして、こじれた案件は人が引き取る設計にしました。全部を自動化しようとすれば、費用も、事故の可能性も跳ね上がります。

線をどこに引くかで、金額が変わる。 そしてその線は、要件定義で決めることです。

4. 使う人数と、権限の複雑さ

	安くなる側	高くなる側
使う人	1〜数人、全員が同じことをする	部署をまたぐ、役職で見えるものが違う
権限	全員が同じ	承認フロー、閲覧制限、部署別の切り分け
場所	社内だけ	社外・取引先も使う

権限の切り分けは、見た目に現れないのに手間がかかる部分です。「部長は見られるが課長は見られない」を実現するには、画面ごと・データごとに判定が要ります。

5. 止まったときに、何が起きるか

これは非機能要件と呼ばれる領域で、金額に大きく効きます。

• 止まっても困らない——社内の集計ツールなど。安い
• 止まると業務が止まる——受注、決済、顧客対応。監視、バックアップ、障害時の復旧手順まで作り込む必要があり、費用が数倍になることもあります

「念のため止まらないように」と言うと高くなります。本当に止まってはいけないのかは、最初に確認すべき論点です。

6. 誰が保守するのか

作って終わりではありません。

• 引き渡して自社で保守——初期費用は抑えられるが、社内に見る人が要る
• 伴走で継続的に改善——月額がかかるが、変化に追従できる

バイブコーディングの記事で書いた通り、「安く作れる」は「安く保てる」ではありません。初期費用だけを比べると、後で払うことになります。

自己診断:あなたの案件は、どちら側か

上の 6 つを、チェックリストにします。

費用が下がりやすい案件

• 既存システムと繋がない、または API がある
• データの形式が揃っている
• 例外は人がやると割り切れる
• 使うのは少人数で、全員が同じ操作をする
• 止まっても、その日の業務は回る
• 保守を誰がやるか決まっている

費用が上がりやすい案件

• 古い基幹システムと繋ぐ必要がある
• データが部署ごとにバラバラ
• すべての例外を自動化したい
• 部署をまたいで、権限を細かく分ける
• 止まると受注や決済が止まる
• 保守の担い手が決まっていない

上の側が多ければ、数十万円規模で始められる可能性があります。下の側が多ければ、数百万円規模の話になります。 これが「規模」ではなく「条件」で金額が決まる、ということです。

---

費用を下げる、現実的な方法

相場を調べるより、こちらのほうが効きます。

1. 作る範囲を削る——いちばん効きます。全部作らない。9 割を自動化して、残りは人がやる

2. 段階的に作る——小さく作って、使ってから広げる。一度に全部作ると、使われない部分にも払うことになります

3. データを先に整えておく——発注前に表記を揃える。これは自社でできて、確実に効きます

4. 既存ツールで済ませられないか確認する——業務によっては、既製のサービスで足ります。作らないのが最も安い

5. 決める人を、先に決めておく——仕様の判断を誰がするかが決まっていると、確認の往復が減ります。私たちも最初に「この件は、どなたが決めますか」を伺います

6. そもそも作るべきかを先に判断する——ほとんどの会社に、いま AI 導入は必要ありませんで書いた通り、作らない判断がいちばん安く済みます

---

見積もりを受け取ったときに、確認すること

最後に、他社の見積もりを見るときのチェックポイントを置きます。

確認すること	なぜ
工程ごとに分かれているか	一式いくら、では何にいくらか分からない。途中で止められない
例外処理の範囲が書いてあるか	ここが曖昧だと、後から必ず揉めます
保守は含まれるか。含まれないなら月額は	初期費用だけ安い見積もりに注意
既存システムとの接続に、相手側の調査が含まれるか	ここを見ていない見積もりは、ほぼ確実に膨らみます
途中でやめたら、成果物はどうなるか	納品済みのものが自社のものになるか

そして最も大事なのは、「なぜこの金額なのか」を説明できるかです。工数の内訳が出てこない見積もりは、根拠がありません。

---

まとめ

• 開発費用を即答できないのは、何を作るかが決まって初めて作業時間が計算できるから。その場で総額を言う会社は、当てずっぽうか追加前提
• 金額を動かすのは規模ではなく 6 つの条件——既存システムとの接続／データの整い方／例外の作り込み／人数と権限／止まったときの影響／保守の担い手
• 最大の変動要因は「例外をどこまで作り込むか」。9 割の自動化と、残り 1 割は同じかそれ以上の手間がかかる。「全部自動化」は費用対効果が最も悪い選択になりがち
• API が無くても、繋げないわけではない。画面操作の自動化という手はある。ただし壊れやすいぶん、保守の前提が変わる
• 費用を下げる現実的な方法は、範囲を削る／段階的に作る／データを先に整える／既存ツールで済ませる／決める人を先に決める／そもそも作らない
• 見積もりは、工程ごとに分かれているか／例外の範囲／保守の有無／接続調査の有無／中止時の扱いで見る

「いくらですか」より、「うちの案件は、何が費用を押し上げますか」と聞いてみてください。 これに具体的に答えられる相手なら、見積もりも信用できます。

Acetyl:Tech の業務診断（20,000 円・要件定義に進む場合は全額充当）は、まさにこの 6 つを一緒に確認する場です。 現場を伺って、何が費用を動かすかを整理し、概算見積もりと診断レポートをお渡しします。作るべきでないと判断すれば、そう申し上げます。料金・進め方はこちら／ご相談はこちら。