見積書を1件作るのに、営業が30分から1時間かけている会社があります。過去の似た案件を探し、単価を確認し、値引きの幅を上司に相談し、体裁を整えて送る。そして相手から「この項目は何ですか」と聞かれて、根拠を探し直す。
この作業の多くは、単価と値引きの判断が、営業一人ひとりの頭の中にあることから生まれています。書式を自動化しても、この部分が残っていれば時間は減りません。この記事では、単価表と値引きの基準を先に作り、そのうえで作成を自動化する順番を説明します。電子データでやり取りする以上は保存義務がかかるため、その線引きも整理します。
この記事でわかること
- 見積作成の時間が書式ではなく、単価と値引きの判断に消えている構造
- 過去の見積から単価表と値引きの基準を作る手順。承認を止めない設計
- 見積書を電子データでやり取りすると保存義務がかかること。電子取引の定義に見積書が明記されている
ムダの現状:探す時間と、相談待ちの時間
見積作成にかかる時間を、作業の中身で分けてみます。
書式に入力する時間は、実はそれほど長くありません。時間を食っているのは、過去の似た案件を探す時間、単価が最新かを確認する時間、そして値引きの可否を上司に相談して返事を待つ時間です。このうち3つ目が、翌日まで持ち越されることがあります。
時間より問題なのは、単価の揺れ
もう1つ、時間とは別の問題があります。同じ内容の見積が、営業によって違う金額になることです。
ある営業は過去の類似案件から単価を引き、別の営業は一昨年の価格表を見ている。顧客が2社から見積を取ったときに気づかれ、説明を求められる。この状態は、単に不公平なだけでなく、値上げのときに全社で足並みを揃えられないという問題につながります。
機械に渡せる部分と、人に残す部分
| 工程 | 中身 | 誰がやるか |
|---|---|---|
| 単価の引き当て | 品目から現在の単価を出す | 機械 |
| 金額の計算 | 数量・値引き・税の計算 | 機械 |
| 承認の要否の判定 | 基準を超える値引きかを判定 | 機械 |
| 値引きの判断 | 基準を超える値引きを認めるか | 人。責任者 |
| 提案の中身 | 何を提案するか、構成をどうするか | 人。営業 |
3番目の「承認の要否の判定」を機械に渡すのが要点です。基準の範囲内なら、そもそも相談が要らない状態にする。これで、相談待ちの時間の大半が消えます。
スキームの全体図:単価表、値引き基準、自動作成
1番目と2番目が揃って初めて、3番目が機能します。単価表だけ作っても、値引きの相談が残れば時間は減りません。逆も同じです。
必要なツールと費用(2026年9月22日時点)
| 必要なもの | 用途 | 費用の考え方 |
|---|---|---|
| 単価表 | 品目と現在の単価 | 表計算ソフトで足りる |
| 値引き基準の文書 | 裁量の幅と承認のしきい値 | 0円。決める会議が1回 |
| Apps Script | 見積の組み立てと承認の判定 | 追加費用なし |
| 保存の置き場所 | 電子取引データの保存 | 既存の共有ドライブ。要件は別途確認 |
見積の専用ツールを検討する前に、単価表と値引き基準を作ってください。この2つが無いままツールを入れても、営業は結局そのツールの外で過去の見積を探します。
導入手順:過去の見積から単価表を作る
Step 1:過去6か月の見積を集めて、品目を数える
単価表をゼロから設計しないでください。過去の実績から作ります。
直近6か月に出した見積を集め、品目ごとに件数と単価を並べます。すると3つのことが分かります。1つ目、実際によく出ている品目はどれか。2つ目、同じ品目でどれだけ単価が揺れているか。3つ目、価格表に載っているのに1件も出ていない品目はどれか。
単価表に載せるのは、件数の多い上位から累計して8割に届くところまでで十分です。残りは「都度見積」として、営業が個別に作る扱いにしてください。すべての品目を網羅しようとすると、表の保守が続きません。
数える作業は、半日で終わる
過去6か月の見積を集める作業は、送信済みメールや見積の控えを並べるだけです。件数が数百件あっても、品目名と単価を拾うだけなら担当者2人で半日あれば終わります。
ここで全部の項目を転記しようとしないでください。必要なのは、品目名、単価、数量、顧客の規模の4つだけです。案件の背景や商談の経緯は、この段階では要りません。それを含めようとすると、作業が数日に膨らみます。
集め終わったら、品目名で並べ替えます。表記が揺れているもの、たとえば同じ商品が「標準タイプ」と「標準型」で書かれているものは、この時点で束ねてください。束ねた記録は残します。後で品目コードを振るときの元になります。
Step 2:揺れている単価を、1つに決める
同じ品目で単価が揺れている場合、その場で「これが正しい」と決めないでください。まず、なぜ揺れたのかを3件ほど確認します。
理由はたいてい3つに分かれます。時期による改定が反映されていない、顧客の規模や取引量による違い、そして単に古い見積を流用した。2つ目が実在するなら、それは単価表の列を増やすべきという合図です。数量帯ごとに単価を持つ形にします。
| 列 | 中身 | 理由 |
|---|---|---|
| 品目コード | 一意の識別子 | 名称は表記が揺れる |
| 品目名 | 見積書に載せる名称 | 顧客が読む言葉で書く |
| 数量帯 | 適用される数量の範囲 | 数量で単価が変わる場合のみ |
| 単価 | 現在の標準の単価 | これが基準になる |
| 適用開始日 | その単価をいつから使うか | 改定時に過去分を壊さない |
| 更新者 | 誰が決めたか | 疑問が出たときの窓口 |
適用開始日の列を持つのが要点です。単価を上書きしてしまうと、過去に出した見積の根拠が辿れなくなります。行を上書きせず、新しい適用開始日の行を追加する形にしてください。
Step 3:値引きの基準を、数字で決める
ここが、この記事の中心です。値引きの可否を毎回相談している限り、待ち時間は消えません。
決めるのは2つです。営業が自分の判断で出せる値引きの幅。そして、それを超えた場合に誰の承認が要るか。
| 値引きの幅 | 扱い | 記録すること |
|---|---|---|
| 基準内 | 営業の判断で出せる。承認不要 | 値引きの理由を1行 |
| 基準超え | 責任者の承認が要る | 理由と、承認した人 |
| 原価割れ | 原則として出さない | 例外なら、その判断の経緯 |
基準内でも理由を1行残すのは、あとで値引きの傾向を見るためです。特定の顧客や特定の品目で値引きが常態化しているなら、それは単価表そのものが実勢と合っていないという合図になります。
Step 4:見積の組み立てを自動化する
単価表と基準ができたら、見積の作成を自動化します。次のApps Scriptは、品目と数量から金額を計算し、承認の要否を判定します。
var DISCOUNT_LIMIT = 0.1;
function buildQuote() {
var ss = SpreadsheetApp.getActiveSpreadsheet();
var prices = loadPrices(ss);
var lines = ss.getSheetByName('見積明細').getDataRange().getValues().slice(1);
var out = [];
var total = 0, listTotal = 0;
for (var i = 0; i < lines.length; i++) {
var code = lines[i][0], qty = Number(lines[i][1] || 0);
var discount = Number(lines[i][2] || 0);
if (!code) continue;
var p = pickPrice(prices, code, qty);
if (!p) {
out.push([code, qty, '', '', '単価表にありません']);
continue;
}
var listAmount = p.price * qty;
var amount = Math.round(listAmount * (1 - discount));
listTotal += listAmount;
total += amount;
out.push([code, qty, p.price, amount, discount > DISCOUNT_LIMIT ? '承認が必要' : '']);
}
var rate = listTotal > 0 ? 1 - total / listTotal : 0;
writeQuote(ss, out, total, rate);
}
function loadPrices(ss) {
var v = ss.getSheetByName('単価表').getDataRange().getValues().slice(1);
var today = new Date();
var m = {};
for (var i = 0; i < v.length; i++) {
var code = v[i][0];
var from = new Date(v[i][4]);
if (from > today) continue;
if (!m[code]) m[code] = [];
m[code].push({ min: Number(v[i][2] || 0), price: Number(v[i][3] || 0), from: from });
}
return m;
}
function pickPrice(prices, code, qty) {
var list = prices[code];
if (!list) return null;
var best = null;
for (var i = 0; i < list.length; i++) {
if (list[i].min > qty) continue;
if (best === null) { best = list[i]; continue; }
if (list[i].from > best.from) { best = list[i]; continue; }
if (list[i].from.getTime() === best.from.getTime()) {
if (list[i].min > best.min) best = list[i];
}
}
return best;
}
function writeQuote(ss, out, total, rate) {
var sh = ss.getSheetByName('見積結果');
sh.getRange(2, 1, Math.max(sh.getLastRow() - 1, 1), 5).clearContent();
if (out.length > 0) sh.getRange(2, 1, out.length, 5).setValues(out);
sh.getRange(1, 7).setValue(total);
sh.getRange(1, 8).setValue(rate);
}
実装で押さえている点を3つ挙げます。
1つ目、適用開始日が未来の行を除外していること。単価改定を事前に登録しておけば、その日から自動的に切り替わります。
2つ目、数量帯の選び方。同じ品目に複数の行がある場合、まず適用開始日が新しいものを優先し、同じ日付なら数量の下限が大きいほうを選びます。数量帯の下限を昇順で並べておかないと、意図しない単価が当たります。
3つ目、単価表に無い品目を無言で飛ばさないこと。「単価表にありません」と出力して、営業が気づける形にしています。黙って0円で計算するのが最も危険です。
見積の有効期限も、自動で入れる
単価表に適用開始日を持たせたら、見積書側にも有効期限を入れてください。単価が改定されたあとに古い見積で発注が来ると、社内で処理が止まります。
期限は、発行日から30日や60日といった一律の日数で構いません。ただし、原材料の価格変動が大きい品目を扱っているなら、その品目だけ短く設定する判断もあります。期限を入れておくと、値上げのときの交渉が楽になります。
あわせて、期限切れの見積で発注が来たときの扱いも決めておいてください。原則は再見積ですが、その判断を営業に毎回させると、また相談待ちが発生します。期限からの経過日数で扱いを分けておくと、現場で判断できます。
Step 5:値引きの記録を、月次で見る
仕組みが回り始めたら、値引きの記録を月に1回見てください。見るのは、品目別の平均値引き率と、承認が必要になった件数です。
特定の品目で値引きが常態化しているなら、単価表の見直しを検討します。承認が必要になる件数が多すぎるなら、基準の幅が狭すぎる可能性があります。承認の件数は、月に数件に収まるのが目安です。毎週何件も上がってくるなら、基準を設けた意味が薄れています。
基準を超えた見積の、通し方も決める
承認が必要になったときに何日かかるかを決めておかないと、結局いまと同じ待ち時間が残ります。
決めるのは3つです。誰が承認するか。何時間以内に返すか。そして、その人が不在のときは誰が代わるか。3つ目を決めていない会社が多く、承認者の出張で見積が2日止まる、ということが起きます。
返す時間は、半日以内を目安にしてください。そして承認の判断に必要な情報を、申請の時点で揃えておくこと。値引きの理由、競合の有無、今後の取引の見込み。この3つが書かれていれば、承認者は追加で聞かずに判断できます。
現場の合意の取り方:裁量を奪う話にしない
単価表と値引き基準を作ると言うと、営業からは「自由に交渉できなくなる」という反応が返ってきます。
| 反対の中身 | 背景 | 答え方 |
|---|---|---|
| 裁量がなくなる | 基準=制限と受け取られている | 基準内は承認不要になると先に伝える。むしろ裁量が明確になる |
| 現場の事情が反映されない | 過去の特別対応が消える懸念 | その事情を単価表の列か、承認の対象として明文化する |
| 単価表が実勢と合わない | 作って放置された経験がある | 月次で値引き率を見て、改定する運用まで決めて示す |
「承認が要らなくなる」ことから説明する
順番が大事です。基準を作る話を、制限から始めないでください。
先に伝えるのは、基準の範囲内なら上司に相談せずに出せるようになる、ということです。いままで毎回相談していたものが、その場で出せるようになる。これは営業にとって明確な利益です。そのうえで、超える場合の扱いを説明します。
この順番を逆にすると、基準は営業を縛るものとして受け取られます。一度そう理解されると、その後に利点を説明しても印象は変わりません。最初の30秒で何を言うかが、この仕組みの定着を左右します。
基準の数字は、営業と一緒に決める
値引きの幅を管理側だけで決めると、実勢と合わない数字になりがちです。Step 1で集めた過去6か月の実績を見せながら、営業と一緒に決めてください。
実績の分布を見ると、多くの見積がどの範囲に収まっているかが分かります。その範囲を基準にすれば、現状の大半は承認不要になります。いまより厳しい基準にすると、承認の件数が増えて現場が止まります。
失敗パターンと限界:電子取引の保存義務
見積書は、電子取引の定義に含まれる
見積書をメールやシステムでやり取りしている場合、保存の義務がかかります。ここは自動化の設計に直接関わるので、条文を確認しておきます。
電子帳簿保存法第2条第5号は、電子取引を「取引情報(取引に関して受領し、又は交付する注文書、契約書、送り状、領収書、見積書その他これらに準ずる書類に通常記載される事項をいう)の授受を電磁的方式により行う取引」と定義しています。見積書が、この定義に明記されています。
そして同法第7条は、所得税および法人税に係る保存義務者は、電子取引を行った場合には、財務省令で定めるところにより、当該電子取引の取引情報に係る電磁的記録を保存しなければならないと定めています。
つまり、見積書をPDFでメール送信した場合、そのデータは保存の対象になります。保存の具体的な要件は財務省令で定められているため、自社の保存方法が要件を満たしているかは、国税庁の資料や顧問税理士に確認してください。
自動化したときに、保存が抜けやすい
手作業で見積を作っていたころは、作ったファイルがそのまま共有ドライブに残っていました。ところが自動化すると、画面上で生成してそのまま送信する形になり、ファイルが残らないことがあります。
仕組みを作るときに、送信したものを保存する処理を必ず組み込んでください。後から追加しようとすると、その間に送った見積のデータが欠けます。
この仕組みが向かない場合
案件ごとに仕様が異なり、同じ品目が二度と出てこない業態では、単価表が機能しません。設計や開発の受託がこれにあたります。この場合は品目ではなく、工数の単価と、見積の構成の型を揃える方向が現実的です。
また、価格を顧客ごとに個別契約している場合は、単価表を顧客別に持つ必要があります。件数が多いと保守が重くなるため、標準単価と顧客別の差分という形にできないかを先に検討してください。
AIをどこに足すか
ここまでの仕組みに生成AIは登場しませんでした。単価の引き当ても金額の計算も、条件がはっきりしているのでルールで書けるからです。
AIを足すとすれば、2か所あります。1つは、顧客からの依頼メールを読んで品目と数量の候補を出すところ。もう1つは、見積に添える提案文の下書きです。どちらも、仕組みが回り始めてから足すものです。
最初からAIを組み込まないほうがよい理由は、動かなかったときに原因が切り分けられなくなるからです。単価が違うのか、AIの読み取りが違うのか、計算が違うのか。層を分けておけば、それぞれ別に直せます。
なお、依頼メールをAIに読ませる場合は、顧客の情報を渡すことになります。利用目的の範囲内か、委託にあたるならその監督ができる形かを、先に確認してください。
効果の測り方
| 数字 | 測り方 | いつ見るか |
|---|---|---|
| 見積の作成時間 | 依頼から送付までの経過時間 | 導入前後で比較 |
| 承認が必要になった割合 | 基準超えの件数を全体で割る | 毎月 |
| 品目別の平均値引き率 | 値引き後の金額を定価で割る | 毎月 |
1つ目は、作業時間ではなく経過時間で測るのが要点です。作業そのものは短くても、承認待ちで翌日になっていれば、顧客から見た速さは変わっていません。この仕組みが狙っているのは、その待ち時間です。
3つ目が常態的に高い品目は、単価表を実勢に合わせる検討をしてください。全営業が同じように値引きしているなら、その単価はもはや基準として機能していません。
まとめ
見積作成の時間は、書式への入力ではなく、過去の案件を探す時間、単価を確認する時間、そして値引きの相談を待つ時間に消えています。
順番は、単価表、値引き基準、自動化の3つです。単価表は過去6か月の実績から作り、件数の多い上位で8割に届くところまでを載せる。適用開始日の列を持ち、上書きせずに行を追加する。値引きは、営業が自分の判断で出せる幅を数字で決め、その範囲なら承認を不要にする。基準内でも理由を1行残し、月次で傾向を見る。
合意は、制限からではなく「承認が要らなくなる」ことから説明します。基準の数字は過去の実績を見せながら営業と一緒に決め、現状の大半が承認不要に収まる水準にする。そして、見積書は電子帳簿保存法の電子取引の定義に明記されており、電子でやり取りすれば電磁的記録の保存義務がかかります。自動化で送信したものが手元に残らない形にならないよう、保存の処理を最初から組み込んでください。
よくある質問
単価表に載せる品目は、全部揃えるべきですか
件数の多い上位から累計して8割に届くところまでで十分です。残りは都度見積として営業が個別に作る扱いにしてください。すべてを網羅しようとすると、表の保守が続かず、結局は古い表になります。使われる範囲を確実に最新に保つほうが効果があります。
値引きの基準は何割が適切ですか
他社の数字を使わないでください。過去6か月の実績の分布を見て、多くの見積が収まっている範囲を基準にします。いまより厳しい基準にすると承認の件数が増えて現場が止まり、緩すぎると基準の意味がなくなります。実勢から決めるのが唯一の方法です。
単価を改定するときは、どうすればよいですか
既存の行を書き換えず、新しい適用開始日を持つ行を追加してください。上書きすると、過去に出した見積の根拠が辿れなくなります。適用開始日を未来の日付にしておけば、その日から自動的に切り替わる設計にできます。
見積書をメールで送っている場合、何を保存すればよいですか
電子帳簿保存法は、電子取引の取引情報に係る電磁的記録を保存しなければならないと定めており、見積書は電子取引の定義に明記されています。保存の具体的な要件は財務省令で定められているため、自社の保存方法が要件を満たしているかは国税庁の資料や顧問税理士に確認してください。
営業ごとに単価が違う状態を、どう収束させますか
まず、なぜ揺れたのかを3件ほど確認してください。時期による改定が反映されていない、顧客の規模や取引量による違い、古い見積の流用。2つ目が実在するなら、単価表に数量帯や区分の列を増やすべきという合図です。理由を確かめずに1つに決めると、現場の実態と合わなくなります。
承認が必要な件数が減りません
基準の幅が実勢より狭い可能性があります。過去の実績の分布に戻って、どこに多くの見積が集まっているかを確認してください。あわせて、特定の品目だけで承認が発生していないかも見ます。その場合は基準ではなく、その品目の単価そのものが実勢と合っていません。
同じ部門の記事
営業営業日報を書かずに作る|カレンダーと案件記録から自動で下書きし、営業が足すのは1行だけにする2026年9月27日
営業営業リスト作成を自動化する|Places APIとスプレッドシートで毎週更新、営業が使うリストにする合意の取り方まで2026年9月20日
部門ごとの自動化スキームを、1つずつ
営業・経理・人事総務・サポート・現場。部門ごとに、1つのムダを消す設計図と、現場の合意の取り方を書いています。
同じ部門の記事だけを追うなら、営業・マーケティングの記事一覧からたどれます。