見積書の取り込みで手間になるところ
見積書を受け取ってから発注までの間には、内容を社内の形式へ書き写す作業が挟まります。表計算ソフトに品名と数量と単価を打ち直し、複数社から取った見積を並べて比べ、決まったら発注の内容として書き直す。この転記が、件数が増えるほど時間を取ります。
ここで手間なのは文字を読むことではありません。取引先ごとに明細の書き方が違うため、そのままでは並べて比べられないことです。同じものを指しているのに品名の書き方が違う、片方は数量10で単価を出し、もう片方は10個入り1セットの価格で出している、片方の合計には送料が含まれていて片方は別記されている。この差を人が読み取って揃え直しているのが、転記の中身です。
自動化を考えるときは、読み取りと、比較できる形へそろえることを分けて設計します。分けずに「見積書をAIで読み込む」とだけ決めると、読み取りは動いたのに比較表が作れない状態になります。
明細の1行を、どこまでデータにするか
見積書の頭にある取引先名や見積番号、有効期限は、書かれている位置が違っても意味で取れます。難しいのは明細です。取り出す対象を先に決めておきます。
| 取り出す項目 | 何を手がかりにするか | 取れなかったときの扱い |
|---|---|---|
| 品名・仕様 | 明細表の名称列。仕様が別行や備考に分かれることがある | 分割された行を1つの品目としてまとめ、原文も保持する |
| 数量と単位 | 数量列と単位列。単位が品名側に書かれる場合もある | 単位が取れなければ空のままにし、比較時に不足として出す |
| 単価 | 単価列。税抜か税込かは明細表の見出しか欄外に書かれる | 税の別が判別できない場合は人の確認へ回す |
| 金額 | 金額列。単価×数量と一致するかを検算できる | 一致しない場合は数量か単価の読み違いを疑う |
| 納期・納入条件 | 明細行の右端か、見積書の下部の条件欄 | 明細ごとに違う場合は行に紐づけて保持する |
| 備考 | 備考列や欄外の注記 | 内容を要約せず原文のまま持たせる |
備考を原文のまま持たせるのは、後で効いてきます。「3か月以降は別途保守費」「数量20以上で単価見直し」といった条件は、金額の欄には出てきませんが、比較のときには金額と同じ重みを持ちます。要約すると条件が落ちるため、そのまま残して人が読める場所に置きます。
読み取りの方式そのものをどう選ぶか（様式ごとに読み取り位置を登録する方式と、意味で項目を取る方式の違い）は AI-OCRと生成AIの違い で扱っています。見積書は取引先ごとに書式が変わり、初めて見る相手からの1枚目を扱う頻度も高いため、位置を登録しておく方式とは相性がよくありません。
一式・小計・オプションの扱いを先に決める
見積書には、請求書ではあまり出てこない書き方が混ざります。ここを設計に入れておかないと、取り込んだ後に人が直す作業が残ります。
| 見積書によくある書き方 | 取り込みで起きること | 決めておく扱い |
|---|---|---|
| 「一式」で数量が1、単価が総額 | 単価あたりの比較ができない | 一式であることを印として持ち、内訳の記載があれば子行として取る |
| 大項目と小項目に分かれ、小計行がある | 小計を明細と数えて合計が二重になる | 階層を持たせ、小計行は集計値として別に扱う |
| 選択制のオプション行 | 採用しない行まで合計に含まれる | 採用・不採用の状態を行に持たせ、既定は不採用にする |
| 値引き行がマイナス金額で入る | 品目として扱われ、単価の比較が崩れる | 値引きは明細と別の区分にし、対象範囲を保持する |
| 諸経費や運搬費が別行になっている | 他社が単価に含めている場合と比べられない | 費目の区分を付け、比較時に含める／含めないを切り替える |
| 税抜と税込が同じ書面に混在 | 合計だけ見ると差が出ているように見える | どちらの基準かを行と合計の両方で保持する |
値引きは特に扱いを決めておきます。全体に対する値引きなのか、特定の明細に対する値引きなのかで、単価あたりの比較結果が変わります。書面から対象範囲が読み取れないことも多いため、読み取れた範囲だけを持たせ、読み取れなければ全体値引きとして扱ったうえでその旨を表示します。勝手に按分すると、比較表の数字が書面のどこにも存在しない値になります。
税は、明細ごとの税率と、合計の税額を分けて持ちます。税率が混在する見積では、税率ごとの対象額を合計して税額を再計算し、書面の税額と突き合わせられます。合わなければ、どこかの行を読み違えている可能性が高いという判断材料になります。
機械で確かめられることと、人へ回すこと
抽出した値が正しいかどうかを、人の目視だけで確かめる構成にすると、自動化しても確認の負担が残ります。見積書は数字の関係が閉じているため、機械で確かめられる範囲が広く取れます。
機械で確かめる条件は、モデルが自己申告する確信度ではなく、値どうしの関係で置きます。確信度を閾値にすると、自信を持って間違えた値が素通りします。
| 機械で確かめること | 突き合わせる相手 | 合わなかったときの扱い |
|---|---|---|
| 単価×数量と金額の一致 | 同じ明細行の値 | 数量か単価の読み違いとして、その行を人の確認へ |
| 明細の合計と小計・合計欄の一致 | 同じ見積書内の値 | 行の取りこぼし、または小計の二重計上を疑う |
| 税率ごとの対象額から計算した税額 | 見積書に記載の税額 | 税抜・税込の判定違いを疑い、人の確認へ |
| 品名と過去の発注実績 | 自社の品目マスタや過去の見積 | 対応する品目が見つからなければ候補を示して人が選ぶ |
| 単価と前回発注時の単価 | 同一品目の過去実績 | 一定の幅を超える差は、読み違いか値上げかを人が判別する |
| 有効期限と発注予定日 | 案件の日程 | 期限切れの見積で発注しないよう止める |
人へ回すのは、この検算に合わなかった行だけにします。合わなかった行を人が見る画面には、元の見積書の該当箇所と抽出値を並べて表示し、抽出値がどこから取られたかが分かるようにします。読み直しではなく照合で済むため、1件あたりの時間が短くなります。
人が直した内容は記録します。同じ取引先で同じ直しが繰り返されるなら、その取引先固有の読み方として持たせます。「この会社の単価欄は税込」「この会社の数量はセット単位」といった規則は、書面からは読み取れませんが、直しの履歴からは見つかります。
相見積を比べられる形にそろえる
明細がデータになっても、そのままでは比べられません。比較表を作るには、社を横断して同じ行を同じ行として扱う必要があります。
品目の突き合わせが最初の関門です。品名の文字列が一致することはほとんどないため、型番や規格が書かれていればそれを鍵にします。書かれていない場合は、自社側で品目の一覧を持ち、各社の品名をそこへ寄せます。寄せ先の候補が複数出たときは、機械で確定させず候補を並べて人が選ぶ形にします。ここを自動で確定させると、違うものの価格を比べた表ができあがり、しかも間違いに気づきにくくなります。
単位の換算も要ります。1個あたりで見積もる会社と、10個入り1箱で見積もる会社を比べるには、比較の基準となる単位を自社側で決めておきます。基準単位が決まっていないと、読み取りが正しくても比較の数字が作れません。
合計だけで比べないようにします。比較表に並べるのは金額だけでなく、次の項目も含めます。
| 比較表にそろえる項目 | そろえないと起きること | そろえ方 |
|---|---|---|
| 基準単位あたりの単価 | 一式や箱単位の見積と比べられない | 自社の基準単位へ換算し、換算できない行は印を付ける |
| 諸経費・送料の含み方 | 安く見える見積が実は別途請求になる | 含む・含まないを行に持ち、両方の合計を出す |
| 税抜・税込の別 | 差額が実際より大きく／小さく見える | 税抜で並べ、税込は別列にする |
| 納期 | 価格だけで選び、間に合わない発注になる | 明細ごとに保持し、案件の日程と突き合わせる |
| 保証・保守の範囲 | 初期費用の安い見積に後から費用が乗る | 備考の原文を並べて人が読める形にする |
| 見積の前提条件 | 数量が変わると単価が変わる契約に気づかない | 条件が書かれた行を抜き出して表示する |
比較表は、機械が優劣を判定するものではなく、人が判断するための材料として作ります。最安の行を自動で色付けする程度に留め、採用の決定は人が行います。金額以外の条件が書面に書かれていない場合があるためで、そこを機械が無視して結論を出すと、比較表そのものが信用されなくなります。
発注データへ渡す
採用が決まったら、その見積の明細を発注の内容へ引き継ぎます。ここで転記し直すと、せっかくデータ化した意味が薄れます。
渡すときは、採用した明細だけを選んで持っていける形にします。相見積で1社を選ぶとは限らず、明細ごとに発注先が分かれることもあるためです。渡す先が購買システムや発注管理の表であれば、その受け入れ形式に合わせて変換します。受け入れ側が持つ品目コードや取引先コードは、見積書には書かれていないので、自社のマスタから引きます。
発注データを作ったら、元になった見積書と行単位で紐づけておきます。納品や請求の段階で金額が合わないとき、どの見積のどの行が根拠だったかを辿れるようにするためです。この紐づけがないと、請求書を受け取った側で「発注時の金額と差がある」という照合ができません。請求段階での突合の設計は 発行元ごとに書式が違う請求書をAIで取り込む で扱っています。
取引先とのやりとりがメール本文で進み、見積の内容が「数量を10から12に変更」といった形で更新される場合は、書面の読み取りだけでは追いきれません。その扱いは 受発注業務をAIで自動化する を参照してください。
どこから手を付けるか
範囲を広く取ると要件が膨らんで着手できません。絞り方には順序があります。
取り込む対象を、相見積を取る案件に限る。 1社だけから取る見積は転記の手間が小さく、自動化しても効果が見えにくい一方、複数社から取る案件は比較表の作成まで含めて手間がかかっています。
書式の種類ではなく、案件の種類で絞る。 同じ種類の案件で取る見積は、扱う品目の範囲が近く、比較の基準単位も決めやすくなります。書式の数を減らそうとして取引先で絞ると、次の案件で別の会社から見積が来た時点で対象外になります。
最初は比較表の作成までを対象にする。 発注データへの連携は受け入れ側の仕様に依存するため、読み取りと比較が安定してから足します。比較表が使われるかどうかで、そもそもの設計が合っているかが分かります。
人の確認は当初すべて残す。 抽出と検算だけを自動化し、比較表の内容は人が確かめてから使います。この期間に、どの項目で直しが多いかを記録します。自動で通してよい条件は、その記録から決めます。
記録を見て範囲を広げる。 直しがほとんど出なかった項目から、人の確認を外していきます。着手前に「何割を自動化する」と決めておくと、実態と合わない目標を追うことになります。
進める前に用意しておくものは、直近の相見積を数件分（書面そのまま）、自社の品目マスタと基準単位、比較の判断を誰が行うか、発注データの受け入れ形式、そして運用を直し続ける担当です。最後の1つが決まっていないと、書式の変化に追随できず数か月で使われなくなります。要件の書き方や工程の分け方は AIエージェント開発の進め方 で扱っています。
まとめ：見積書の取り込みを設計するときの要点
- 手間の中心は文字を読むことではなく、取引先ごとに違う明細を比べられる形へそろえ直すこと。読み取りと、そろえる工程を分けて設計する
- 明細から取るのは品名と仕様、数量と単位、単価、金額、納期、備考。備考は要約せず原文で持たせる
- 一式表記、小計行、オプション行、値引き行、諸経費、税抜と税込の混在は、扱いを先に決めておく。値引きの対象範囲が読み取れないときは按分せず、読み取れた範囲だけを持たせる
- 検算はモデルの確信度ではなく値どうしの関係で行う。単価×数量と金額、明細合計と合計欄、税率ごとの税額、過去単価との差が使える
- 人へ回すのは検算に合わなかった行だけにし、元の書面と抽出値を並べて照合できる画面にする。直した内容は取引先ごとの読み方として蓄積する
- 比較表では金額だけでなく、基準単位あたりの単価、諸経費の含み方、税の別、納期、保証範囲、前提条件をそろえる。採用の決定は人が行う
- 発注データへは採用した明細だけを渡し、元の見積と行単位で紐づけて残す。請求段階での金額照合がここに依存する
- 着手は相見積を取る案件に絞り、比較表の作成までを対象にして、人の確認を残したまま直しの記録を取る
Augueでは、帳票の読み取りから既存の購買・会計システムへの連携までを含めたAIエージェントの開発に対応しており、どこまでを機械に任せどこに人の判断を残すかの線引きから一緒に設計できます。自社の見積書の処理を自動化の対象にできるか判断したい方は、是非ご相談ください。
関連する記事
読み取り方式の選び方は AI-OCRと生成AIの違い、発注後の請求書側の取り込みは 発行元ごとに書式が違う請求書をAIで取り込む、メールでのやりとりを含む受発注の自動化は 受発注業務をAIで自動化する で扱っています。
開発の進め方や見積の内訳は AIエージェント開発の進め方、社内で改善を回せる体制づくりは 生成AI・AIエージェントの内製化とは を参照してください。
よくある質問
請求書の取り込みを既に自動化している場合、同じ仕組みで見積書も扱えますか？
抽出と検算の土台は共有できますが、そのままでは足りません。請求書は合計金額と振込先が確定していれば処理が進むのに対し、見積書は明細の1行ごとに他社と突き合わせるため、行の粒度をそろえる工程が別に要ります。逆に、支払や仕訳への連携は見積書には不要です。共有するのは取り込み経路と検算の仕組みまでにして、明細の突き合わせ以降は別に組むのが扱いやすい形です。
PDFではなくExcelやメール本文で届く見積は、どう扱いますか？
形式ごとに入口を分けず、取り込んだ直後に同じ明細の構造へ寄せます。Excelは行と列が既にあるため読み取りは楽ですが、列の意味がファイルごとに違う点はPDFと変わりません。メール本文だけの簡易な見積は項目が欠けていることが多いため、欠けた項目を空のまま通し、比較の段階で不足として表示させます。推測で埋めないほうが後の判断を誤りません。
導入にはどれくらいの期間と体制が必要ですか？
一律の期間は出せません。決め手になるのは書式の種類数ではなく、比較したい単位が社内で決まっているかどうかです。品目の呼び方や数量の単位が部署ごとに違う状態のままだと、読み取りが動いても比較表が作れません。着手前に、直近の相見積を数件分そのまま並べてみて、どの項目がそろわないかを洗い出す作業に時間を取ると見通しが立ちます。
購買システムやERPが既にある場合、どう組み合わせますか？
既存システムを置き換えず、その手前に読み取りと整形の工程を足す形が現実的です。多くの購買システムは発注データの取り込み口を持っているため、見積の明細をその形式へ変換して渡します。確認できるのは受け入れ側の仕様なので、読み取りの仕組みを作る前に、必要な項目とコード体系を確かめておきます。
受け取った見積書の原本は、どこまで残す必要がありますか？
見積書も取引に関して授受する書類にあたるため、電子で受け取ったものは保存の扱いを確認したうえで処理経路を設計します。実務上は、読み取り結果だけを残して原本を捨てる構成にしないことが重要です。抽出値に疑いが出たときに元の書面を開けないと、確認のたびに取引先へ問い合わせることになります。