請求書・契約書の確認を自動化｜AI抽出・Drive保存・Chat承認

Expert Q&A

文書処理を自動化する前に確認すること

湯田英也SakuraAI株式会社 代表 / ソフトウェアエンジニア

Q. 請求書と契約書を同じAIフローで処理できますか？

A. 受付と原本保存までは共通化できますが、確認項目と責任者は分けます。請求書は金額、税、支払先、発注・検収との照合、契約書は当事者、期間、更新、解約、責任範囲などを見るためです。

Q. OCRの信頼度が高ければ自動承認してよいですか？

A. 信頼度は正しさの保証ではありません。読み取りやすさの目安にはなりますが、支払や締結の影響は別です。重要項目は原本と台帳を人が照合します。

Q. Chatで承認まで完結させますか？

A. 原本と差分を十分に確認できないなら、確認画面を開くボタンにします。Chat上のワンクリックだけで支払や締結を確定せず、対象版と承認履歴を正本へ記録します。

この記事の立場を先に述べておくと、AIの読み取り精度を競うのが目的ではありません。受付と候補抽出は自動化し、支払・締結・最終承認は人が原本を確認して確定する。ここを崩さないことが、あとで「言った・言わない」「どの版で承認したか」を説明できる状態につながります。

請求書・契約書の自動化では、PDFから文字を読めるかに注目しがちです。しかし、実務で難しいのは、どれが原本か、何を照合したか、誰がどの版を承認したかを後から説明できる状態にすることです。

同じファイル名でも中身が違う。AIが合計金額を読めても税や支払先が違う。契約書の要約が正しく見えても、対象版が古い。こうした問題はOCR精度だけでは解決しません。

先に分ける：原本・抽出データ・確定情報

AI抽出結果を原本へ書き戻したり、そのまま会計・契約台帳の確定値にしたりしません。修正した場合も、元の抽出値と確認後の値を比較できるようにします。

請求書・契約書・稟議は確認内容が違う

受付を共通化しても、後段を一つのプロンプトにまとめないことが重要です。書類種別ごとに確認項目、担当者、正本、完了条件を分けます。

どの作業から自動化するべきか

安全な処理フロー

原本保存が完了する前に抽出・承認を進めません。OCRやAIが失敗しても原本から再処理でき、どのファイルをもとに判断したか追跡できます。

電子で受け取ったデータは原本保存から考える

国税庁は、注文書、契約書、領収書、見積書、請求書などに相当するデータを電子的にやり取りした場合、電子取引データとして保存対象になることを案内しています。

ここで注意したいのは、紙へ印刷して保存すればよい、PDFを別形式へ変換すればよい、と独自判断しないことです。添付PDFだけでなく、取引情報がメール本文に含まれる場合の扱いも確認します。

AI・OCRで抽出する項目

請求書

契約書

AIが条項名を見つけても、法的な意味や受け入れ可否までは確定しません。抜粋だけで判断せず、前後の条文と契約全体を確認します。

OCR製品は日本語対応と版を確認する

Google Cloud Document AIには、請求番号、取引先名、金額、税、日付、明細などを抽出するInvoice Parserがあります。ただし、2026年6月29日に確認した公式プロセッサ一覧では、Invoice Parserの対応言語一覧に日本語は表示されていません。

日本語の請求書で使う場合は、最新の対応言語、プロセッサの版、リージョン、ページ上限、実データでの精度を導入前に確認してください。Google製品だから日本語帳票へそのまま使える、と判断しないことが重要です。

重複はファイル一致と業務上の重複を分ける

同一ファイルを受け取っても、再送として履歴を残す必要があります。重複候補を削除するのではなく、受付IDと原本を保持し、処理対象かを決めます。

Driveはフォルダだけでなくラベルを使う

Driveラベルは、ファイルやフォルダへ構造化されたメタデータを付け、検索やポリシーへ使える仕組みです。所属はフォルダ、状態はラベルのように分けると、確認のたびにファイルを移動せずに済みます。

金額、口座、契約内容をファイル名や広いChatスペースへ載せる必要はありません。検索性と情報公開範囲を両方考えます。

Chatの承認ボタンは冪等に処理する

Google Chatアプリはカードのボタンクリックやダイアログ送信を処理できます。一方、公式ドキュメントでは、通信失敗などにより同じインタラクションが再送される可能性も案内されています。

そのため、同じ承認操作を二度処理しない設計が必要です。

承認ボタンを押した瞬間に支払や署名を実行するのではなく、権限を持つシステムの確認画面へ遷移させる方法もあります。操作の影響が大きいほど、Chat内だけで完結させない方が安全です。

Workspace内製と専用システムの比較

Workspaceは受付と社内連携に強い一方、会計・支払・契約管理の専門システムを無理に置き換えるものではありません。件数、監査、承認、外部連携が増えたら専用システムを正本にし、Workspaceは入口と通知に使います。

導入手順

1. 文書種別ごとに正本と完了条件を決める

請求書、契約書、稟議を分け、原本、抽出データ、承認記録、最終台帳を決めます。受信しただけ、Driveへ保存しただけを完了にしません。

2. 受付IDと原本保存を先に作る

Gmailやフォームから受け取り、受信日時、送信元、元メール、添付、受付IDを記録します。抽出・分類に失敗しても原本を追跡できる状態にします。

3. ルール分類とAI抽出を分ける

送信元、件名、ファイル形式など明確な条件を先に使い、本文を読まないと分からない種別・項目だけAIで補います。

4. 差分確認画面を作る

原本、AI抽出値、既存台帳値を並べ、重要項目の不一致を目立たせます。信頼度だけで自動承認しません。

5. Chat通知と承認履歴を接続する

Chatには文書ID、状態、担当、期限、不一致理由を通知し、原本と差分を確認する画面へ誘導します。承認結果は正本へ記録します。

6. 指標を見て自動範囲を広げる

よくある失敗

SakuraAIで支援できること

SakuraAIは、請求書・契約書・稟議の受付、原本保存、AI・OCR抽出、重複候補、差分確認、Driveラベル、Google Chat通知を、文書種別ごとに設計します。

金額、税、支払先、契約条項、承認、支払、締結は人が確定し、会計・契約管理システムを正本として連携します。Workspace内製で足りる範囲と、OCR、会計、契約管理の専用製品が必要な範囲も比較します。

Expert Q&A

最後に湯田へ確認

湯田英也SakuraAI株式会社 代表 / ソフトウェアエンジニア

Q. 最初のPoCはどの文書で行いますか？

A. 送信元と形式が揃った請求書の受付・原本保存・担当通知が向いています。金額の自動承認ではなく、受付漏れと保存時間が減るかを確認します。

Q. 自動化が成功した状態とは？

A. 原本をすぐ追跡でき、抽出ミスと不一致が確認者に見え、期限内に正しい人が判断できる状態です。OCRの読取率だけ高くても、承認履歴と正本が曖昧なら成功ではありません。

Q. 専用システムへ移る目安は？

A. 発注・検収・支払・仕訳の照合や、契約の版管理・締結・更新が増えてきたときです。Workspaceに個別機能を足していく保守費と、専用製品が標準で持つ機能を天秤にかける。自作にこだわりすぎると、いつのまにか会計システムを作っていた、となりがちです。

Reviewed by

監修者: 湯田英也

SakuraAI株式会社 代表 / ソフトウェアエンジニア

Google Chatの導入・移行、Google Workspace連携、Google Chat API / Webhook / Bot、Gmail・Meet・Drive・Calendarをまたぐ業務自動化領域を監修しています。

Google公式情報、各プロダクトの仕様、実務での運用・開発観点をもとに、企業が導入判断・運用設計・自動化設計を行える内容になるよう確認しています。

GitHubLinkedInX

プロフィール