前と似た装置なのに、見積もりが担当で変わる——積算の根拠が案件に残らない構造と、業務OSでそろえられる範囲【2026年】

「前に似た装置を受注したはずなのに、今回の見積もりは前回と数百万円違う。担当者が替わっただけで、なぜここまで変わるのか」——製造業の見積もり・積算の現場では、こうした戸惑いは珍しくありません。多くの場合、疑われるのは担当者の力量ですが、本当の原因はそこではありません。

問題は見積もりの数字そのものではなく、その数字を支える「根拠」が案件に残らないことです。数量をどう積んだのか、単価をどこから取ったのか、工数を何時間で見たのか、どんな条件・リスクを織り込んだのか。これらが成果物として残らないため、次の似た案件で誰も参照できず、見積もりは人によって変わり、失注や赤字のあとに「どこがずれたのか」を検証できません。この記事では、積算が属人化する構造を分解し、業務OS（AIエージェント基盤）でどこまでそろえられるかを整理します。

見積もりの根拠が残らないと、何が起きるのか？

結論から言えば、見積もりの精度と再現性が、担当者個人に依存します。同じような装置でも担当が違えば数字が変わり、受注後に「安く見過ぎていた」「高すぎて失注した」と分かっても、原因を根拠までさかのぼって特定できません。改善のループが回らないまま、次の案件でも同じ勘に頼ることになります。

なぜ同じような案件で、見積もりが人によって変わるのか？

見積もり（積算）とは、製品や装置を作るのに必要な数量・材料費・加工費・工数・経費を積み上げ、価格を組み立てる業務です。ここで積み上げの前提——どの図面を基準にしたか、どの単価表を引いたか、どの工程を何時間で見たか——は、担当者の頭の中やローカルのExcelにあり、見積書には最終金額しか出力されません。前提が案件に残らないため、次の担当者は同じ前提を再現できず、自分の経験で置き直すしかない。これが「人によって変わる」の正体です。

見落とされがちなのは、この属人化がベテランの引退で一気に顕在化する点です。長年の勘で妥当な数字を出せていた人が抜けた瞬間、根拠が言語化・データ化されていないため、組織として見積もり精度を維持できなくなります。

数量の根拠は、部品表（BOM）の正確さに直結します。BOMそのものが人手の転記に頼っている場合、その揺らぎは見積もりの数量根拠にそのまま乗ってきます。この構造は過去記事で次のように整理しました。

問題は二つあることではなく、二つの間の「変換」が構造化されず、人手の転記に依存していることです。

同じ製品なのに部品表が二つある——E-BOMとM-BOMの変換が人手に頼る構造と、業務OSでそろえられる範囲

積算が属人化する3つの構造

積算の属人化は、意識や能力の問題ではなく、「前提が残らない」「根拠が人に偏る」「探すコストが高い」という3つの構造が連動して起きます。下図に全体像を示します。

構造1：見積もりの前提が成果物に残らない

見積書に残るのは金額と項目名だけで、「なぜその数量・単価・工数になったか」の前提は出力されません。数量は基準図面の版数に依存し、単価は参照した時点の市況やサプライヤー見積に依存し、工数は担当者が想定した工法に依存します。これらが案件データとして紐づかないため、後から同じ条件を再現できず、見積もりは毎回ゼロから組み直しになります。

構造2：根拠を持つのが特定のベテランに偏る

前提が残らない結果、「妥当な数字かどうか」を判断できるのが特定の1〜2名に偏ります。その人が忙しければ見積もりが滞り、不在なら精度が落ち、退職すれば根拠ごと組織から失われます。若手は数字を出せても、その数字が妥当かを自分で確かめる手立てがありません。教育も、根拠が言語化されていないため「見て覚える」に頼らざるを得ません。

構造3：過去見積を探すコストが判断コストを超える

似た案件の過去見積を探そうにも、案件フォルダ・メール・個人Excelに散らばっているため、探すだけで30分〜数時間かかることがあります。この「材料そろえ」に時間が溶けると、肝心の値決めを考える時間が残らず、結局は勘と経験で概算を置くしかなくなります。探すコストが判断コストを上回ると、人は探すのをやめ、根拠のない数字が積み上がっていきます。

見積もりの根拠は、業務OSでどこまでそろえられるのか？

結論を先に述べると、業務OS（AIエージェント基盤）がそろえられるのは「材料そろえ」までで、最終的な値決めは人が握ります。ここを取り違えると「AIが見積もりを自動で出す」という誤解に陥ります。まず、既存のERPやPLMではこの業務がなぜ変わらなかったのかを、過去記事の整理で確認します。

理由は単純で、ERPは「お金とモノの記録台帳」、PLMは「図面とBOMの保管庫」であり、いずれも「業務そのもの」を実行する仕組みではないからです。

設計OSとは——図面・部品表・設計変更を一気通貫させる業務エージェント基盤

見積もりに引き付けると、記録台帳や保管庫には過去見積や単価が「入って」はいても、新規案件のときに判断に使える形で引き出せないのが問題でした。業務OSがそろえるのは、過去見積・実績単価・標準工数の横断検索、類似案件の候補提示、そして見積根拠を案件にひも付けて出典まで示すことです。一方、戦略的な値決め、前例のない仕様のリスク評価、顧客との交渉は人が握ります。下図に範囲を整理します。

観点	根拠が残らない積算	根拠が案件に残る積算
数量の根拠	基準図面の版数が不明	見積時の基準図番・版数が案件に記録
単価の根拠	取得元・取得時点が残らない	参照した単価表・見積の出典を明示
工数の根拠	想定工法が担当者の頭の中	標準工数と想定工法を案件に紐付け
再現性	担当が替わると再現不能	誰でも同じ前提で再計算できる
事後検証	失注・赤字の原因を特定できない	見積と実績の差異を根拠まで追える
教育	「見て覚える」に依存	根拠が言語化され引き継げる

「原価が見えない話」とは、どう違うのか？

見積もりの根拠の話は、「製造原価がいくらになるか読めない」という別の論点としばしば混同されます。後者は設計段階でコストの大半が決まってしまう構造の話で、過去記事では次のように整理しました。

設計段階で製造原価が見えないのは、設計者の能力ではなく、原価判断の材料が部署に分散している業務基盤の問題です。

図面はできたのに原価は「作ってみないと分からない」——設計段階で製造原価が見えない構造と、原価をそろえる順番

両者は近いようで別です。原価の話は「これから作るものが、いくらかかるか」の見通し。本記事の見積もりの話は「すでに出した見積もりの根拠を、あとから再現・検証できるか」。原価が読めても、見積もりの前提が案件に残らなければ、担当ごとのばらつきも失注の事後検証も解決しません。逆に、両方を同じ業務基盤の上でそろえると、原価の見通しと見積もりの根拠が地続きになり、値決めの精度が上がります。

よくある反論への先回り

反論1：見積もりは経験の勘所だから、標準化できないのでは？

半分は正しく、半分は構造の問題です。前例のない仕様のリスク評価や戦略的な値決めは、確かに経験に裏打ちされた領域で、そこを機械が置き換えるべきではありません。しかし「過去見積を探す」「単価を照合する」「標準工数を引き当てる」は判断ではなく準備作業で、ここは仕組みでそろえられます。準備を仕組みに任せることで、人は本来の勘所——値決めとリスク評価——に時間を使えます。

反論2：見積テンプレートはもうExcelにある。それで十分では？

テンプレートは計算式をそろえますが、「その案件で、なぜその数量・単価・工数にしたか」という前提までは残しません。しかもExcelはコピーで枝分かれし、どれが最新版か分からなくなります。テンプレートは出力の様式を統一する一歩ですが、根拠を案件に紐づけて横断検索できる状態とは別物です。様式は活かしつつ、根拠が残り引き出せる基盤に載せ替えることが要点です。

自己診断：見積もりは仕組みで支えられているか？

次の5項目のうち3つ以上に「はい」がつく場合、見積もりは仕組みではなく個人に支えられている可能性が高い状態です。業務OSのような基盤で根拠を束ねる余地が大きいと言えます。

• 同じような装置の過去見積もりを、担当者以外がすぐに探し出せない
• 見積書に、数量・単価・工数の「根拠」が案件データとして残っていない
• 失注・赤字案件のあとで、見積もりのどこがずれたかを検証できていない
• 積算の精度が、特定のベテラン1〜2名に依存している
• 過去見積を探すのに、毎回30分以上かかることがある

次のアクション

いきなり全社の見積もりを標準化しようとすると、たいてい途中で止まります。現実的な着手点は、失注・赤字だった案件を数件持ち寄り、「見積もりの前提がどこまで案件に残っているか」を棚卸しすることです。数量・単価・工数の根拠がどこにあり、誰なら再現できるかを洗い出すだけで、属人化のボトルネックが具体的に見えてきます。そのうえで、まず1つの製品群に絞って過去見積を横断検索できる形に集約するのが、最初の一歩になります。

自社の見積もり・積算のどこが属人化しているかを整理したい方は、業務診断で現状を業務分解できます。過去見積・単価・工数の根拠がどこにあるかを棚卸しし、仕組みでそろえられる範囲と人が握るべき範囲を切り分けます。

よくある質問（FAQ）

見積もりの属人化は、ベテランの経験が問題なのですか？

いいえ。ベテランの経験そのものは資産です。問題は、その経験に基づく見積もりの根拠が案件に残らず、組織として再現・検証できないことです。根拠がデータとして残れば、経験は失われず、若手にも引き継げます。

見積テンプレートはExcelにあります。それでは不十分ですか？

テンプレートは計算の様式をそろえますが、案件ごとの前提（基準図番・単価の出典・想定工法）までは残しません。様式の統一と、根拠を案件に紐づけて横断検索できる状態は別物です。テンプレートは活かしつつ、根拠が残る基盤に載せ替えるのが要点です。

業務OSを入れると、見積もりは自動で出せるようになりますか？

完全な自動化ではありません。業務OSがそろえるのは過去見積・単価・標準工数の横断検索と根拠の提示までで、最終的な値決めや戦略的な安値受注の判断は人が握ります。準備作業を仕組みに任せ、判断に時間を使えるようにするのが目的です。

出典

• JIS Z 8141:2022 生産管理用語（「見積り」「原価」等の用語定義）
• 製品原価の大半が設計・開発段階で決まるという原価企画の標準的知見については、関連記事「図面はできたのに原価は『作ってみないと分からない』」を参照（経済産業省「ものづくり白書」のコスト決定論に基づく）。
• 本記事の図はいずれも編集部作成の概念図であり、特定企業の実測値ではありません。

次に読むべき記事

• 図面はできたのに原価は「作ってみないと分からない」——設計段階で製造原価が見えない構造と、原価をそろえる順番
• 設計OSとは——図面・部品表・設計変更を一気通貫させる業務エージェント基盤
• 検図はなぜベテラン頼みになるのか——指摘の観点が図面に残らず、レビュー品質が人でばらつく構造と、設計OSでそろえられる範囲