見積書・請求書をAIに任せたら、人のミスを先に見つけてきた

検証で使った担当者メモには「税込583,200円」と書かれていました。実はこれ、消費税率を8%で計算した誤りで、正しくは594,000円です。この間違いを、AI Workerは見積書を確定させる前に指摘してきました。

見積書・請求書の作成をAIに任せる価値は、速さでも「ミスが減った」という効果でもありません。承認の前に、過去実績との突合・検算が必ず挟まる仕組みになったことです。これまで人の目だけに頼っていた確認が、機械的なチェックを経てから人の承認に来る流れに変わります。検証では、あらかじめ仕込んでおいた税計算ミス・単価乖離・表記ゆれ・新規品目という4つの論点に対して、この仕組みが実際に働く実例を確認しました。Zemu（当社が開発するAIエージェントの実行環境）上にAI Worker（特定の業務を任せるために設定したAIエージェント）を構築し、実際の案件相当のデータ3件でこれを確かめた記録です。

AIに任せるのは「転記・計算・照合」まで

見積書・請求書の作成でAIに任せられるのは、次の3つです。

• 過去の取引実績（単価・取引先表記）との整合性チェック
• 見積書・請求書のPDF生成と転記
• 転記前後の自己検算（見積書と請求書の金額・品目の突合）

一方、次の2つは人に残します。

• 案件情報の入力：品目・数量・単価をはじめに確定させるのは人です
• 承認の意思決定：とくに与信判断（取引先の支払い能力や取引継続の可否を見極める判断）や値上げの妥当性判断はAIには委ねられません。単価が過去実績より上がっていた場合、それが「合意済みの改定」か「入力ミス」かをAIは判定できないためです

今回の検証でも、AI Workerは請求書への転記前に必ず人の承認待ちで一度止まる設計にしました。人が見るのは白紙の帳票ではなく、「単価はここが実績と何%違う」「金額はここが計算と合わない」という突合結果です。3件すべてで、承認前の転記実行はゼロ件でした。

誰が作り、誰が保守するのか

今回の検証では、Workerの構築（指示文の設計・承認ステップの設定）と、過去案件マスタ（取引先3社×品目9件）のナレッジ（Zemuに業務データを保存しWorkerが参照できるようにする機能）への登録は、当社側で行いました。今回はZemu上にAI Workerを構築しましたが、既製の請求書SaaSや受託開発など他の手段もあり、Zemuはその1つです。

費用目安（今回の検証でかかったAI利用料）

検証セッション（3件・見積書作成〜請求書転記）でAI Workerが消費したAI利用料は、課金台帳の実測値で合計約0.98ドル相当、1件あたり約0.33ドル相当でした。利用するAIモデルや料金体系によって変わり、将来も変動するため、あくまで参考値としてご覧ください。

どう動かしたか：入力・参照・出力

ケース1（株式会社田中製作所）で実際にWorkerへ渡した入力はこちらです。

以下の案件の見積書を作成してください。

【案件情報】
- 取引先: 株式会社田中製作所
- 案件名: 2026年8月 Webサイト保守・制作一式
- 品目:
  1. Webサイト保守（月額） 数量3（8〜10月分） 単価50,000円
  2. バナーデザイン 数量6点 単価8,000円
  3. ランディングページ制作 数量1式 単価180,000円
- 担当者メモ: 支払条件は従来どおり（月末締め翌月末払い）でお願いします。

Workerは、この入力をナレッジに登録した「過去案件マスタ」と突合します。マスタには取引先ごとの品目・実績単価が入っており、抜粋すると次のとおりです。

これをナレッジに登録しておくことで、Workerは案件のたびにここを参照し、単価が実績から±10%を超えて乖離していないかを自動で突合します。今回の入力は3品目とも実績単価どおりだったため、乖離なしと判定されました。

処理の流れは次のとおりです。

1. 案件情報の入力（人）：上記の案件情報
2. 過去案件マスタとの整合性チェック（AI）：単価乖離0%を確認
3. 見積書PDFの生成（AI）
4. 内容確認と承認（人）：「整合性チェック結果を確認しました。問題ないので見積書を承認します。請求書へ転記してください。」
5. 請求書PDFへの転記（AI）
6. 転記後の自己検算（AI）

この入力に対して、実際に出力されたのが次の見積書・請求書です。

検証用のダミーデータで生成した見積書です。取引先名・金額は架空の案件（ケース1・正常系）です。Zemu AI Worker＋サンドボックス内Python/reportlabで自動生成しました。

同じくケース1の検証データです。見積書の内容が人の承認を経たあと、請求書へ自動転記されたものです。転記後の金額・品目は見積書と完全に一致することを自己検算で確認しています。

突合の仕組みが働いた実例

3ケースに仕込んだ4つの論点（計算ミス1件・単価乖離1件・表記ゆれ1件・新規品目1件）に対して、承認前の突合・検算の仕組みが実際に働いた実例は次のとおりです。

• 税計算ミス：ケース2で、担当者メモに記載された「税込583,200円」という金額が、8%の税率で計算した誤り（正しい税率は10%）によるものであると指摘し、正しい594,000円で見積書を作成しました
• 単価乖離：同じケース2で、ある品目の単価が過去実績（30,000円）より16.7%高いことを要確認フラグとして提示しました
• 表記ゆれ：ケース3で、取引先の表記ゆれ「(株)みどり食品」を検出しました
• 新規品目：同じケース3で、過去実績のない新規品目については金額を確定させず、承認判断を人に委ねる形でフラグを立てました

いずれのケースも、承認の前にこうした突合結果が必ず人に提示される流れになっており、人が行ったのはその結果を確認して承認することでした。3ケースいずれも、請求書への転記後に見積書と請求書の金額・品目を照合する自己検算を行い、全ケースで完全一致を確認しています。

処理時間（参考値）

今回の検証では、Worker自体の処理時間も記録しました。ただしこれはWorkerの処理時間そのものであり、人が案件情報を入力する時間や承認を判断する時間は含みません。速さを本記事の主な便益として位置づけるものではなく、あくまで参考値としてご覧ください。

Worker処理時間は平均3分49秒／件でした（サンドボックスの起動やライブラリ準備などの環境準備時間を含みます）。

この検証で言えないこと

• 仕込んだミスは検証者自身が設定したもので、実際の業務で偶発的に起きたミスではありません
• 過去案件マスタは取引先3社×品目9件に整えられたデータで、実運用でありがちな未整備なマスタでの検証ではありません
• 検証件数が3件のため、問題のない入力にAIが余計な確認フラグを出す割合（誤検知率）は評価できていません
• Workerの構築・過去案件マスタの登録は当社側で行っており、読者が自分で同じものを構築する場合にどの程度の手間・専門性が必要かは、今回の検証では測っていません
• ケース3では取引先の表記ゆれ「(株)みどり食品」を、人の確認なしに正式表記へ自動変換しました。表記が似ているだけで別法人の可能性もあり、取引先名の変更は人が確認する運用にすべきです
• 見積番号・請求書番号が3件とも同一になりました（検証環境の制約）。請求書は取引の証跡となる帳票のため、番号の重複は実運用でこのまま使えない欠陥で、採番管理の仕組みが別途必要です
• 帳票の送付や入金確認（消込）は検証範囲に含まれていません

導入前に確認しておきたいこと

見積書・請求書には取引先名や金額など、外部に出したくない情報が含まれます。AIエージェントやSaaSの導入前には、少なくとも次の3点を提供元に確認することをおすすめします。

• 入力したデータがAIモデルの学習など他の目的に使われることがあるか
• データがどこに保管され、誰がアクセスできるか
• 秘密保持契約（NDA）など契約上のデータの取り扱い条件

次の一歩

自社の業務がどこまでAI化できそうか気になる方向けに、無料で相談できるチャット窓口をご用意しています。 こちら からお気軽にご相談ください。