AI開発会社が見積もりを辞退する7つの理由。返事が来ない依頼文の直し方

AI 開発の相見積もりでよくある詰まり方がある。5 社に声をかけて、返ってきたのが 2 社。残りは「社内で検討しましたが今回は見送らせてください」か、そもそも返事が無い。

発注側から見ると理由が分からないので、「忙しいのだろう」「うちの規模が小さいからだろう」と解釈して終わる。実際には、辞退の理由の多くは依頼文の書き方で変わる。開発会社側は見積もりを作るのに数日から 1 週間の工数を使うので、出す前に「この案件に工数を使うか」を判断している。その判断に使われる材料は、だいたい決まっている。

ここでは辞退につながりやすい 7 つの理由と、依頼文のどこを直せば変わるかを整理する。辞退を 0 にすることが目的ではない。合わない会社が早めに降りるのは双方にとって良いことで、問題は「合うはずの会社が、情報不足で降りる」ことである。

理由 1. 工数が出せるだけの条件が書かれていない

いちばん多い。AI 開発の見積もりは、作る機能の数より扱うデータの量と状態で工数が決まる。それが書かれていないと、幅を取るしかなく、幅を取った金額は高く見えて失注する。だから出さない。

書かれていないことが多いのは次の 4 つである。

項目	書かれていないと起きること
対象データの件数と形式（PDF / 紙 / 表 / 基幹システム内）	前処理の工数が 10 倍ぶれる
既存システムとの連携の有無と相手の種類	連携の調査費を乗せるか外すかが決まらない
利用者数とピーク時の同時利用	インフラ構成が決まらない
精度の合格ラインと、誰がそれを判定するか	検収の条件が決まらない

直し方: 数字が確定していなくてよい。「PDF が約 3,000 件、うち 2 割はスキャン画像」「利用者は 50 人、朝 9 時台に集中」程度でも、桁が合えば見積もりは出る。確定していないことは「現時点で未確定」と書けばよく、書かずに空欄にする方が断られる。揃えるべき項目は相見積もりで条件を揃える12項目にまとめている。

理由 2. 予算の幅がどこにも書かれていない

「適正価格を知りたいので予算は伝えたくない」と考える発注担当者は多い。気持ちは分かるが、開発会社側からは規模の判断ができない案件に見える。300 万円の案件と 3,000 万円の案件では、提案する構成も関わる人数もまったく違う。どちらで書けばよいか分からないので、手を付けない。

もうひとつ、予算を伏せた依頼は「相場を調べているだけで発注しない」案件と区別が付かない。工数を使う順番で後ろに回される。

直し方: 上限額を言う必要はない。「初期で 500〜1,000 万円、運用は月 30 万円程度を想定」のような幅で十分である。幅を出すと相手の金額がそこに寄ってしまう、という心配はあるが、相見積もりで同じ幅を全社に伝えていれば、その中での内訳の違いが比較の材料になる。むしろ幅を伝えないと、各社がバラバラの規模で出してきて比較できない。見当が付かない場合は30秒費用診断で概算の幅を作ってから依頼するとよい。

理由 3. 声をかけた社数が多すぎる

相見積もりは 3 社前後が実務的な上限である。依頼文に「10 社に声をかけています」と書くと、当たる確率が 10 分の 1 の案件として扱われる。見積もり作成に 3 日かかるなら、期待値が合わない。

社数を書かない場合でも、同じ文面が業界に広く出回っていることは伝わる。AI 開発の会社は横のつながりがあり、同じ依頼を受け取ったという話は出る。

直し方: 3 社程度に絞り、そのことを書く。「3 社に同じ条件でお送りしています」と明記するほうが、伏せるより通る。社数の考え方は相見積もりを取るか1社に絞るかで整理した。

理由 4. 分野・フェーズが合っていない

AI 開発会社は見た目より専門が分かれている。文書検索（RAG）を主にやっている会社、音声・通話を扱う会社、画像・外観検査の会社、業務システム寄りの会社で、持っている部品も人も違う。

合わない分野の案件は、取れても赤字になることが分かっているので辞退する。これは発注側に落ち度があるわけではなく、相手の選定の問題である。

同じことがフェーズでも起きる。PoC だけを請ける体制の会社に本番運用まで含む依頼を出す、逆に大規模な運用を主とする会社に 100 万円の PoC を出す、どちらも辞退になりやすい。

直し方: 依頼の前に、相手の公開実績の分野とフェーズを見る。会社の規模で選ぶのではなく、扱っているデータの種類で選ぶ。規模による違いは大手SIerとAI専門会社に書いた。

理由 5. 納期が物理的に合わない

「2 か月後に稼働させたい」という依頼に対し、手が空くのが 3 か月後なら辞退するしかない。これは依頼文の問題ではなく稼働の問題だが、納期の書き方で救えることがある。

よくあるのは、社内の都合で決めた日付をそのまま「納期」として書いてしまうケースである。実際には「4 月の人事異動までに現場が触れる状態になっていればよく、全機能が揃うのは夏でもよい」ということが多い。それを書けば、段階的な提案が返ってくる。

直し方: 「いつまでに何ができていればよいか」を 2 段階で書く。「①〇月までに現場 10 人が試せる、②〇月までに全社」のように分けると、手が埋まっている会社でも前半だけ、あるいは後ろ倒しの提案を出せる。納期と費用の関係はAI開発の納期はどう決まるかに整理した。

理由 6. 決裁の見通しが書かれていない

見積もりを出しても、発注されるかどうかが分からない案件は後回しになる。判断材料は 3 つで、誰が決めるか・いつ決まるか・予算がもう付いているかである。

「社内で検討中」「上申してみます」としか書かれていないと、予算化すらされていない情報収集と見なされる。実際そうである場合も多いのだが、そうでないなら書いたほうがよい。

直し方: 次の 3 行を依頼文に入れる。それぞれ 1 行でよい。

• 決裁者（例: 情報システム部長、役員会）
• 選定の予定時期（例: 10 月中に 1 社に絞り、11 月に契約）
• 予算の状態（例: 今期予算に計上済み / 来期申請予定）

「来期申請予定」と正直に書いても構わない。書いてあること自体が、実在する案件である証拠になる。社内で予算を通す手順はAI開発の予算を社内で通す方法にまとめている。

理由 7. 契約・検収の条件が受けられない

依頼文や RFP に、次のような条件が入っていると、読んだ時点で辞退になることがある。

• 提案段階で無償の PoCや無償のデモ開発を求める
• 精度が出なければ全額返金とする
• 成果（売上増・工数削減）に連動した完全成果報酬
• 瑕疵の責任期間が長期、または期間の定めが無い
• 提案書に含まれるノウハウの権利が発注者に帰属する

AI の精度は入力データの質に左右されるため、データを見る前に結果を保証することは原理的にできない。保証を求める条件は、できる会社だけが残るのではなく、条件を軽く見る会社だけが残る方向に働きやすい。

直し方: 精度の不確実性は「保証」ではなく「段階」で扱う。小さく試して、合格ラインに届いたら次へ進む形にすれば、発注側のリスクは期間で区切れる。契約形態の選び方は請負と準委任、AI開発はどちらで契約するか、初期費用 0 円型の実際の負担は初期費用0円・成果報酬のAI開発は安いのかで検証した。

辞退されたときに聞くこと

断られたら、1 行だけ聞いてみる価値がある。

「今回は見送りとのこと、承知しました。差し支えなければ、条件・時期・分野のどれが合わなかったかだけ教えていただけますか」

選択肢の形で聞くと返事が来やすい。返ってきた答えが「分野が違う」なら相手選びの問題で、依頼文を直す必要はない。「条件が足りない」なら、次に声をかける会社の前に直せる。同じ依頼文で全社に断られてから直すより、1 社目の返事で直すほうが早い。

まとめ

辞退の 7 つの理由を、発注側が直せるものと直せないものに分けると次のようになる。

理由	発注側で直せるか
1. 条件が足りない	直せる（情報を足す）
2. 予算の幅が無い	直せる（幅で書く）
3. 社数が多すぎる	直せる（3 社に絞る）
4. 分野が合わない	直せる（相手の選び方）
5. 納期が合わない	一部直せる（2 段階で書く）
6. 決裁が見えない	直せる（3 行足す）
7. 契約条件が重い	直せる（段階に分ける）

ほとんどが依頼文の書き方で、追加の費用はかからない。逆に言えば、書き方を直さないまま社数を増やしても結果は変わらない。

無料で相見積もりでは、ここで挙げた条件・予算の幅・時期・決裁の見通しを選択式で埋める案件票を作り、同じ内容を各社に渡している。各社が同じ前提で見積もりを出すので、返ってきた金額の差が「条件の読み違い」ではなく「やり方の違い」として読める。