結論：金額の正答率だけでは、見積AIの導入は判断できない
製造業のAI見積PoCでは、まず「どの作業をAIに任せるのか」を決め、その作業に対応する指標を測ります。注文書の転記、過去案件の検索、材料・加工・外注の原価計算、営業見積の作成、承認、ERP登録は、同じ評価では判定できません。
本稿では、抽出の正しさ、判断を保留できること、人が確認する工数を分ける評価方法を提案します。掲載する評価表は設計例です。実案件の改善率や、特定のAI製品の性能を示すものではありません。
シンシアの受発注・見積の公開ページでは、文章を入力するデモと、実際の製造原価・図面起点の見積・顧客案件での効果を区別しています。本稿も、その区別を前提にします。[1]
最初に、評価する業務の境界を決める
「見積できた」を一つの合格条件にしない
PoCを始める前に、次の表を対象業務に合わせて埋めます。AIが作った金額を表示できることと、顧客へ提示できる見積になることは別です。
| 対象作業 | 検証するもの | 人が確定するもの |
|---|---|---|
| 注文書・案件文の読み取り | 品番、数量、単位、納期などの抽出結果と原文の対応 | 読めない項目、矛盾する条件 |
| 過去案件の検索 | 参照した案件と、採用した比較条件 | 今回の条件へ流用できるか |
| 原価計算の支援 | 材料、加工、外注などの計算根拠・適用ルール | 未確定単価、工程の妥当性 |
| 営業見積の下書き | 明細・条件・除外事項・版 | 顧客へ提示する価格と条件 |
| 承認・ERP登録 | 承認状態、転記結果、変更履歴 | 承認、訂正、取消 |
「文章から必要項目を抜き出す」ことだけを評価するPoCで、加工原価まで自動計算できると判定してはいけません。逆に、金額計算を対象外にしたPoCを、金額が一致しないという理由で失敗にするのも不適切です。
対象外を先に書く
初回の検証計画には、対象の帳票、業務、品目群、入力形式、使用するマスタの版と、対象外の処理を記載します。たとえば、文章入力だけを対象にする場合、図面PDFの読解能力は未検証です。図面からの抽出を評価に含めるときの項目の選び方は、図面AI・OCRの適用範囲と評価の設計で別に整理しています。特急案件を対象外にする場合は、特急を通常案件として処理せず、対象外として検知するテストを用意します。
評価データは、案件単位で分ける
評価表には、匿名化した案件ID、入力資料の版、正解を決めた担当者、適用ルール、期待する処理を持たせます。顧客名や図面の機密情報を、公開デモや公開記事のサンプルへ持ち出さないでください。
本稿で提案する進め方は、開発中に参照するデータと、最後に判定するデータを案件単位で分ける方法です。同じ案件の見積書と、その訂正版を別の集合に入れると、実質的に既知の案件で性能を測ることになります。案件、図面の系列、顧客固有の帳票をどの単位で分けたかまで記録します。
過去の承認済み見積もりも、無条件に正解とはしません。当時の入力条件、単価の適用日、後日の訂正を確認し、担当者が正解を確定できないケースは「正解未確定」として分けます。
未見の評価セットを、調整を始める前に固定する
最後の判定に使う評価セットは、ルールやプロンプトの調整を始める前に作り、開発中は中身を見ない状態で保管します。調整しながら同じケースを何度も見ると、そのケースに合わせた修正が入り、未知の案件での実力より良い結果が出やすくなるためです。
| 決めること | 本稿で提案する決め方 |
|---|---|
| 誰が持つか | 業務側の担当者など、調整作業に関わらない人が保管する |
| いつ固定するか | 調整を始める前。固定した日付、件数、資料の版を記録する |
| 何を入れるか | 標準ケースに加え、保留すべきケース、対象外のケースを入れる。正解を確定できないケースは母数から外して別枠で数える |
| 比率 | 実際の業務で起きる頻度を目安に決め、決めた比率と根拠を記録する |
| 修正した後 | 評価セットの失敗を見て直したケースは、以後「既知」として扱う。再判定は新しく用意した未見のケースで行い、同じセットの再実行結果とは分けて報告する |
次の節の表に挙げるケースは、用意すべきケースの種類の例です。評価セットの件数の目安ではありません。
標準ケースだけでなく、保留すべきケースを用意する
以下は、本稿で提案するテスト設計例です。実行結果ではありません。
| ケース | 期待する動作 | 合格にしない動作 |
|---|---|---|
| 数量が「1,000」と記載されている | 数量1,000と抽出し、原文へ対応付ける | 1個として確定する |
| 数量の単位が不明 | 単位の確認待ちにする | 個・kgなどを推測して金額を確定する |
| 材質がマスタにない | 未登録として照会する | 材料費を0円扱いにして合計を確定する |
| 外注費の単価が未定 | 未定として照会する | 外注費を0円扱いにして合計を確定する |
| 旧版と新版の図番が混在 | 版の確認待ちにする | 都合のよい数値だけを混ぜる |
| 本文と明細で数量が異なる | 不一致を示して保留する | 一方を無根拠に採用する |
| 顧客手配の工程がある | 除外条件として提示し、担当者に確認させる | 自社の作業として無条件に加算する |
| 同一案件が再送された | 重複候補として扱う | 新規案件として二重に処理する |
| 未承認の見積が入力された | 下書きのまま止める | ERPへ確定取引として登録する |
シンシアの公開ページには、架空案件25件でのデモ確認について、修正前14件、修正後24件の合格が記されています。ただし、これは公開ページが報告する特定の入力とルールの検証です。修正後の24件は、同じ25件の失敗を見て読み取りを直した後の再実行で、未見のケースでの結果ではありません。本稿の作成時に再実行した結果でもなく、製造業全体の精度や実案件での効果へ一般化できません。[1]
指標は、分母と対象を固定して記録する
1. 必須項目の抽出
数量、単位、品番、版数など、業務上重要な項目ごとに「正しく取得できた件数／正解を確定できた対象件数」を測ります。項目ごとの値と案件単位の合格を分けて残します。重要でない項目の数を増やして、平均正答率を高く見せないためです。
2. 保留判断
保留すべきケースについて、正しく止められた件数を記録します。同時に、本来処理できる案件を過剰に止めた件数も残します。全部を保留すれば誤った確定は減らせますが、それだけでは業務改善にはなりません。
3. 誤った確定
誤った金額や数量が、担当者の確認を経ずに確定処理へ進んだかを確認します。ここで「重大誤りゼロ」を合格条件に設定することはできますが、有限のテストでゼロだったことは、本番でも誤りが起きないという保証ではありません。
4. 人が費やす時間
入力、確認、修正、承認、再作業に使った時間を分けます。AIの処理待ち時間と、人の実作業時間も別の列にします。処理が速くても確認が増えていれば、業務全体の削減とは言えません。
仮の例として、従来の実作業が1件30分、新方式の入力・確認・修正の合計が18分だった場合、同じ条件での削減時間は12分です。この数字は計算例であり、シンシアや特定製品の導入実績ではありません。実際の比較では、案件難易度と担当者の条件をそろえ、中央値と時間のかかったケースも示します。
合格・継続・中止をどう決めるか
| 判定 | 判断に必要な条件 | 次の行動 |
|---|---|---|
| 限定範囲で次段階へ | 必須項目、保留、誤確定、実作業時間の基準を満たし、対象外も検知できる | 人の承認付きで対象を限定して試行する |
| 検証を継続 | 正解データやサンプルの偏りが残る、修正の効果が未評価 | データと基準を修正し、未使用の評価セットで再確認する |
| 現行方式を維持 | 確認負担が増える、重要な誤りを止められない、データ利用の条件が満たせない | 先にルール整備・入力標準化・システム連携を検討する |
具体的な合格閾値は、業務責任者と開発担当がPoCの実施前に合意してください。結果を見た後で閾値を緩めた場合は、当初計画を残し、変更理由を別途記録します。業種を問わないPoCの期間・体制・本番移行の判断は、AI PoCの進め方5ステップで整理しています。
ERP連携は、見積AIの評価と別に確認する
承認済み見積の内容が正しくても、再送による二重登録、単価の適用日、取消・訂正の反映が壊れれば、業務で使えません。AIの採点票と、連携のテスト票は分けて管理します。
基幹・ERP連携の説明では、正となるデータ、連携方式、権限、再送・削除の扱いを整理しています。PoCの対象に連携が含まれるかを確認したうえで、対象範囲に合うテストを作成してください。[2]
相談前に整理しておく情報
まず、対象の業務を1つ選び、現在の入力形式、担当者が判断している箇所、見積にかかる時間の概数、既存システムへの転記の有無を整理します。顧客の図面や実際の取引単価は、最初の相談フォームに記載しないでください。
受発注・見積の支援内容を確認すると、相談の前に確認する項目や、標準機能・個別開発・未検証部分の区分を確認できます。何を自動化したいかが曖昧な段階では、機能の比較より先に、対象業務と評価方法から整理します。
参照情報と、この資料の位置づけ
[1] シンシア：製造業の受発注・見積システム（2026年10月16日確認）。デモの検証範囲と実案件で未検証の事項を参照しています。
[2] シンシア：製造業の基幹・ERP連携（2026年10月16日確認）。連携範囲と運用上の確認項目を参照しています。
本稿の評価票、テストケース、判定手順は編集上の提案です。第三者調査、実案件の成果、実施済みのベンチマークとして掲載するものではありません。
この記事の作成にはAIによる下書き支援を使用しています。参照した公開ページの記述は、2026年10月16日に照合しました。
