機械学習開発の見積もりの作り方｜あとで足せない項目

2026年5月15日

長谷川奈津

この記事のポイント

✓機械学習開発の見積もりの出し方を
✓あとから追加できない項目に絞って整理しました
✓データ整備や検証など見落としやすい工程

機械学習開発の見積もりの出し方で失敗する人は、金額の計算を間違えているのではありません。見積書に載せるべき項目を落としているだけです。落とした項目は、着手後にほぼ確実に必要になりますが、その時点では追加できません。「聞いていない」「その分も含まれていると思っていた」という話になり、無償で吸収することになります。結論から言うと、機械学習開発の見積もりで最も重要なのは金額の精度ではなく項目の網羅性です。この記事では、見積もりが外れる構造を分解したうえで、費目の骨格、あとで足せない項目の一覧、見積書を組み立てる手順、契約形態の選び方、そして内訳の見せ方までを順に整理します。

機械学習開発の見積もりが外れる構造

見積もりの外れ方には再現性があります。個別の案件事情ではなく、この分野に共通する性質から生じているためです。原因を3つに分けて確認します。

工数が読めない工程が最初から含まれている

機械学習開発の工程のうち、データ整備と精度の調整は、着手前に工数を正確に見積もることができません。データは開けてみるまで状態が分からず、精度は試してみるまでどこまで伸びるか分かりません。この2つを、他の工程と同じ精度で見積もろうとするところに無理があります。

正しい対応は、精度を上げることではなく、扱い方を変えることです。読める工程は固定金額で、読めない工程は段階を分けるか時間あたりの精算にする。この使い分けを見積書の構造に組み込みます。すべてを一式の請負として提示すると、読めない部分のリスクをすべて受注側が背負うことになります。

完了の定義が数値になっていない

見積もりは、どこまでやったら終わりかが決まって初めて計算できます。「精度の高いモデルを構築する」という定義では、終わりがありません。終わりがない仕事に対して金額を出すと、その金額は必ず不足します。

完了の定義は、評価指標と目標値の組み合わせで書きます。どの指標を使うのか、どのデータで測るのか、いくつを合格とするのかの3点です。この3点が決まっていない段階では、開発の見積もりではなく、定義を作る工程の見積もりを出すのが筋です。企業のAI活用を上流から支援する仕事の全体像はAIコンサル・業務活用支援のお仕事にまとまっており、定義を作る工程が独立した役務として成立していることが分かります。

見えない工程を無償で飲み込んでいる

打ち合わせ、資料作成、環境構築、動作確認の立ち会い、社内説明用の資料への協力。これらは成果物として目に見えないため、見積書から落ちがちです。落ちた工程は、発注側からは「無料でやってくれるもの」に見えます。実際には時間を消費しており、案件の利益率を静かに削ります。

見積もりの骨格を理解する

項目を洗い出す前に、費用がどういう比率で構成されるかという骨格を把握しておきます。骨格が頭に入っていると、見積書を見返したときに「この費目が薄すぎる」と自分で気づけます。

割合はあくまで目安（二次情報の集約）だが、「人件費が6〜7割」「データとインフラで残りの大半」という骨格は、どのAI開発でもおおむね変わらない。出典: gxo.co.jp

個人で受ける場合、この骨格は少し形を変えます。人件費に相当するのは自分の作業時間であり、そこにデータの取り扱いにかかる手間と、実行環境の費用が乗ります。個人だからインフラは無視してよい、とはなりません。学習に使う計算資源、データを安全に保管する環境、検証結果を共有する仕組み。どれも実費または時間が発生します。

作業時間の中身を分ける

作業時間を一括りにすると、見積もりの根拠を説明できません。少なくとも、要件を定義する時間、データを整える時間、モデルを作る時間、検証する時間、組み込む時間、資料を作る時間の6つに分けます。分けておくと、発注側から「予算が足りない」と言われたときに、どの工程を削ると何が起きるかを説明できます。説明できれば、値引きではなく範囲の調整という交渉ができます。

データにかかる費用を可視化する

データの受け渡し方法、匿名化の処理、保管期間中の管理、返却または破棄の手続き。個人情報や取引先情報を含むデータでは、これらの作業が無視できない量になります。あわせて、外部データを購入する必要がある場合や、ラベル付けの作業が発生する場合は、その分を明示します。ラベル付けは特に見落とされやすく、量によっては開発本体より時間を食います。

実行環境の費用を実費として出す

クラウドの計算資源を使うなら、学習の試行回数によって費用が変わります。「何回まで試行する前提の金額か」を書いておくと、追加の試行が必要になったときに追加費用の話をしやすくなります。ここを曖昧にすると、試行のたびに持ち出しが増えます。

あとで足せない項目

ここからが本題です。以下の項目は、見積書に最初から入っていなければ、後から追加するのが極めて難しくなります。追加できない理由は、発注側の予算がすでに確定しているからです。稟議を通した金額を後から増やすには、社内で再度手続きが必要になり、担当者にとって大きな負担になります。

データ整備

最も大きく、最も落としやすい項目です。受け取ったデータの形式確認、欠損の処理、表記揺れの統一、外れ値の扱い、期間の突き合わせ。これらは「前処理」の一言で片付けられがちですが、実際の工数は案件の半分近くを占めることもあります。見積書では独立した項目として立て、想定するデータの状態を条件として明記します。「表記の揺れが軽微であることを前提とする」「1つの表に統合済みであることを前提とする」といった書き方です。前提が外れた場合に再見積もりとなることも、あわせて書きます。

要件定義とヒアリング

打ち合わせに出る時間、議事録を作る時間、要件を文書にまとめる時間は、すべて作業です。無償のヒアリングとして扱うと、要件が固まらない案件ほど自分の時間が消えます。回数の上限を決めて見積もりに入れます。「オンライン打ち合わせを2回、要件定義書の作成を1式」といった形です。

検証と評価レポート

モデルを作る作業と、その性能を検証して説明する作業は別物です。検証には、評価用データの準備、複数モデルの比較、結果の可視化、レポートの作成が含まれます。発注側にとっては、このレポートこそが社内で説明するための材料であり、価値の中心です。それだけに、独立した項目として金額を付ける正当性があります。

環境構築と再現性の担保

学習を再現できる状態にする作業です。使用したライブラリのバージョン固定、乱数の種の管理、データの取得条件の記録、実行手順の文書化。これがないと、半年後に「同じ結果を出してほしい」と言われて対応できません。再現性は品質の一部であり、後から追加すると作業をやり直すことになります。

ドキュメントと引き継ぎ

モデルの仕様書、運用手順書、想定される劣化のパターンとその対処。発注側の社内で運用する場合、これらがなければ成果物は使われません。使われない成果物は次の発注につながらないため、自分の利益のためにも必要な項目です。

修正対応の回数と受付期間

納品後にどこまで直すかを、金額に含まれる範囲として明記します。回数、1回の数え方、受付期間の3点です。ここを書かずに納品すると、修正依頼が無期限に続きます。この項目は金額そのものより、範囲を確定させる役割で重要です。

保守と再学習

データの傾向が変われば精度は落ちます。落ちたときの再学習を誰がどういう条件で行うかを、開発の見積もりとは別枠として提示します。別枠であることを最初に伝えておかないと、無償の永久サポートとして期待されます。保守を継続的な契約にできれば、収入の安定にもつながります。

権利と再利用の条件

作成したコードやモデルの権利がどちらに帰属するか、汎用的な部分を他の案件で再利用してよいか。これは金額そのものに直結します。すべての権利を譲渡する条件なら、その分は金額に反映されるべきです。契約書に何も書かずに進めると、あとから譲渡を求められて交渉材料を失います。取引条件を書面で明示することはフリーランスとの取引における基本であり、制度の考え方は公正取引委員会の案内で確認できます（https://www.jftc.go.jp/）。個別の契約で判断に迷う場合は、専門家に確認してください。

見積もりを作る前に集める材料

項目を並べる前に、判断の材料が揃っているかを確認します。材料が足りないまま作った見積書は、前提条件の羅列ばかりになり、結局あとで作り直すことになります。

データのサンプルを実際に開く

説明を聞くだけでは、データの状態は分かりません。全量でなくてよいので、代表的な期間の一部を受け取り、実際に開いて確認します。確認するのは、行数と列数、項目名の意味、欠損の割合、日付の形式、同じ意味の値が複数の表記で入っていないか、といった点です。30分ほど手を動かすだけで、前処理の工数の見当は大きく変わります。

サンプルの提供が難しい場合は、項目一覧と各項目の説明、代表的な値の例だけでも受け取ります。それも出せない案件は、社内の情報システム部門との調整が済んでいない状態です。その状態で金額を出すと、前提が崩れる確率が高くなります。

既存システムとの接点を確認する

モデルを作って終わりなのか、既存のシステムに組み込むところまでなのかで、工数はまったく違います。組み込みが含まれるなら、接続先の仕様、認証の方式、本番環境への反映手続き、テスト環境の有無を確認します。ここが未確認のまま一式で見積もると、連携の調整に想定外の時間を取られます。周辺領域まで含む案件の分類はAI・マーケティング・セキュリティのお仕事に整理されており、セキュリティ要件が加わると工程が増える点も踏まえて確認しておくと安全です。

発注側の体制を確認する

質問に答えられる人が誰か、その人がどれくらいの頻度で対応できるかを確認します。回答に時間がかかる体制なら、その待ち時間は工程に含めるべきです。含めずに日程を組むと、自分の作業が止まっていない時間まで遅延として扱われます。あわせて、検収を誰が行うかも確認しておきます。検収の担当者が打ち合わせに一度も出ていない案件は、最後に方針が覆るリスクを抱えています。

発注側は見積書のどこを見ているか

見積書は、受注側が作る書類でありながら、読むのは発注側です。どこを見られているかを知っておくと、書き方が変わります。

総額より内訳の妥当性

決裁者が最初に見るのは総額ですが、判断を左右するのは内訳です。人件費に相当する部分が大半を占め、データと環境で残りの多くを占めるという骨格から大きく外れた見積もりは、根拠を疑われます。逆に、骨格に沿った内訳が並んでいれば、金額そのものが高くても説明が通ります。内訳の粒度は、工程名と作業内容が対応している程度で十分です。

何が含まれていないか

経験のある発注担当者ほど、除外事項を先に読みます。除外が書かれていない見積書は、後から追加費用が出るリスクがあると判断されます。除外事項を明記することは、自分を守るだけでなく、相手からの信頼にもつながります。「データの収集作業は含みません」「運用開始後の保守は別途お見積もりとなります」と書くことで、見積書の精度が高いという評価になります。

スケジュールと支払い時期

金額と同じくらい、いつ支払いが発生するかが見られています。着手金があるのか、中間の支払いがあるのか、完了後の一括なのか。発注側は自社の予算の執行時期と照らして判断します。この情報がないと、経理側の確認が入って決裁が止まります。工程の区切りごとに支払いを設定すると、受注側の資金繰りも安定します。

質問への回答の速さ

見積書そのものではありませんが、提出後に来る質問への回答速度も評価対象です。内訳の根拠を聞かれたときに即答できるかどうかで、工程を把握しているかが判断されます。手元に作業を分解した表を残しておけば、どの質問にも数字で答えられます。この準備があるかどうかが、同程度の金額で並んだときの差になります。

見積書を組み立てる手順

項目が揃ったら、順番に組み立てます。手順を固定しておくと、案件ごとの出来不出来が減ります。

手順1: 目的と完了条件を1行で書く

見積書の冒頭に、何のための開発で、何が達成されたら完了かを1行で書きます。この1行が書けない場合、まだ見積もりを出す段階ではありません。定義を作る工程の提案に切り替えます。

手順2: 前提条件を列挙する

データの状態、提供時期、打ち合わせの回数、発注側の担当者の体制、使用する環境。これらを前提として並べます。前提が崩れた場合は再見積もりになると添えておくと、後の交渉が事実の確認だけで済みます。

手順3: 工程を分解して時間を積む

作業を半日から1日で終わる粒度に分解し、それぞれに時間を割り当てます。粗い粒度のまま積むと誤差が大きくなります。分解した表は手元に残し、提示する見積書では工程単位にまとめます。

手順4: 読めない工程に扱いを決める

データ整備と精度の調整については、固定金額にするのか、段階を分けるのか、時間精算にするのかを決めます。固定にするなら、前提条件を厳しめに書きます。

手順5: 除外事項を書く

含まれないものを明記します。データの収集そのもの、他システムの改修、運用開始後の保守、業務フローの変更に伴う調整。書いておかないと、含まれていると解釈されます。

手順6: 有効期限と支払い条件を書く

見積もりの有効期限、着手金の有無、締め日と支払日を記載します。決裁に時間がかかる案件では、期限がないと数か月後に同じ金額で発注が来ます。その間に自分の状況は変わっています。

手順7: 第三者が読んで分かるか確認する

見積書は、打ち合わせに出ていない上司や経理担当者が読みます。専門用語だけで書かれた項目は、社内で説明できず、削られる対象になります。項目名は業務の言葉で書き、必要なら補足を添えます。文書としての体裁や構成に不安があるなら、ビジネス文書検定の出題範囲が実務的な下地になります。

契約形態の選び方

見積もりの形は、契約形態とセットで決まります。

請負契約は、成果物の完成に対して対価が発生します。完了条件が数値で書ける案件、データの状態が確認済みの案件に向きます。金額が確定するため発注側の社内手続きが通りやすい一方、想定を超えた作業はすべて受注側の負担になります。

準委任契約は、作業の遂行に対して対価が発生します。要件が動く案件、探索的な検証が中心の案件に向きます。作業時間で精算するため、読めない工程のリスクを一方に寄せません。ただし、発注側から見ると総額が読めないため、上限時間を設けるなどの工夫が必要になります。

判断の基準は単純です。完了条件を数値で書けるなら請負、書けないなら準委任です。書けないのに請負で受けると、見積書の項目をどれだけ丁寧に並べても足りなくなります。検証の段階だけを準委任で受け、結果を見てから本開発を請負で契約する、という二段構えも実務では有効です。システム連携まで含む案件では工程ごとに性質が異なるため、アプリケーション開発のお仕事にあるような開発全体の流れを踏まえて工程ごとに契約形態を変える設計も検討できます。

見積もりの提示で失敗しやすい点

金額を1つだけ提示すると、発注側は高いか安いかしか判断できません。判断材料を増やすために、段階を分けた提案にします。実現可能性の検証まで、モデル構築まで、システム組み込みまで、という3段階で金額を出す形です。予算が限られている相手でも、第一段階から始めるという選択ができます。

内訳を見せるかどうかも論点になります。見せない見積書は、発注側から見ると根拠が分からず、値引き交渉の対象になりやすくなります。工程単位の内訳を見せると、削る場合にどの工程が削られるかという議論になり、単純な値引きの圧力は下がります。ただし、時間単価が逆算できるほど細かく見せる必要はありません。工程単位で十分です。

もう一つ、口頭で概算を伝えるのは避けます。「だいたい〇〇くらいですかね」と言った数字は、相手の社内で正式な見積もりとして共有されます。後から正式な見積書を出しても、最初の数字が基準として残ります。概算が必要なら、条件を明記した書面で出します。

見積書に添えると効く補足資料

見積書だけを送るより、短い補足資料を添えたほうが決裁は通りやすくなります。手間は増えますが、作るのは一度で、次の案件でも型を使い回せます。

一つ目は、工程表です。どの週に何を行い、どの時点で発注側の確認が必要かを1枚にまとめます。発注側は自分たちが動くべき時期を把握でき、社内の担当者を確保しやすくなります。確認の遅れが遅延の主因になる分野なので、この1枚が実際のスケジュールを守ります。

二つ目は、成果物の一覧です。納品されるものを具体的に並べます。学習済みモデル、実行手順書、評価レポート、前処理のコード、環境の構成情報。一覧があると、発注側は自分たちが何を受け取るのかを理解でき、検収の基準も自然に定まります。曖昧なまま進むと、検収の段階で「これも入っていると思っていた」という話になります。

三つ目は、想定されるリスクとその対応方針です。データの品質が想定を下回った場合、目標の精度に届かなかった場合、既存システムの仕様が想定と異なった場合。それぞれについて、どう進めるかを1行ずつ書きます。リスクを先に開示すると不安を与えると思われがちですが、実際には逆で、想定して備えている相手として評価されます。開示せずに問題が起きたときのほうが、はるかに信頼を失います。

この3点を添えた見積書は、打ち合わせに出ていない決裁者が読んでも判断できます。読んで判断できる書類を出せるかどうかが、個人の受注者と組むことへの不安を取り除く最大の要素になります。

見積もり精度を上げる記録の取り方

案件が終わったら、見積もり時の想定時間と実績時間を工程ごとに比較して残します。この記録が溜まると、自分がどの工程を過小に見積もる癖があるかが分かります。多くの場合、データ整備と資料作成が過小になります。癖が分かれば、次回から係数をかけて補正できます。

記録は複雑にする必要がありません。工程名、想定時間、実績時間、差の理由を並べた表で足ります。差の理由まで書いておくと、前提条件の書き方の改善にもつながります。技術者としての市場での位置づけを客観的に確認したい場合はソフトウェア作成者の年収・単価相場のような統計を参照すると、自分の時間の価値を説明する材料になります。

途中で追加見積もりを出すときの手順

前提を丁寧に書いていても、着手後に条件が変わることはあります。そのときに追加見積もりを出せるかどうかで、案件の採算は決まります。

最初にやるのは、変更点を当初の前提条件と並べて示すことです。「当初は1つの表に統合済みのデータをご提供いただく前提でしたが、実際には3つのシステムから個別に出力されたファイルをいただいています」という書き方です。責任の話ではなく、条件の差分の確認として提示します。差分が明確なら、追加費用の必要性は説明を要しません。

次に、追加作業の内容と時間を分解して示します。統合の作業に何時間、突き合わせの検証に何時間、という粒度です。総額だけを提示すると、金額の妥当性を判断できず、社内で止まります。

最後に、進めるかどうかの選択肢を出します。追加費用を払って当初の範囲を維持する案、追加費用なしで範囲を縮小する案、日程を延ばして分割で進める案。選べる形にすると、担当者は上長に相談しやすくなります。追加見積もりは、こちらの都合を押し通す書類ではなく、相手が判断するための書類です。この姿勢で出した追加見積もりは、実際に相当な割合が承認されます。着手してから言い出すのではなく、条件の変化に気づいた時点で出すことが前提になります。

市場を見てきた立場からの観察

在宅ワークと業務委託の市場を20年見てきた立場から言えば、見積書が丁寧な受注者は、金額が他より高くても選ばれています。理由は明確で、発注側の担当者が社内で説明しやすいからです。項目が並び、前提が書かれ、除外事項が明示された見積書は、稟議の資料としてそのまま使えます。安いだけの一式見積もりは、途中で追加費用が発生するリスクが読めないため、決裁者に嫌われます。

もう一つ、長く続いている受注者に共通するのは、値引きを求められたときに金額ではなく範囲で応じていることです。金額を下げると、次の案件も下げた金額が基準になります。範囲を調整すれば、単価は維持できます。仲介の手数料が乗らない直接取引では、同じ予算でも発注側はより多くを依頼でき、受け手の手数料0%の取引は手取りが厚くなります。手取りに余裕があると、無理な値引きを受けずに済み、結果として品質が守られます。契約条件を前段で固める文化が定着している英語圏の取引の進め方はUpworkの使い方ガイド｜日本人フリーランスが海外案件を取る方法に整理されており、見積もりに前提と除外事項を書き込む習慣の参考になります。

見積もりは、金額を伝える書類ではなく、仕事の範囲を確定させる書類です。あとで足せない項目を最初に並べておくことが、着手後の消耗を防ぐ唯一の方法になります。