注文書のPDFをGoogleドライブのフォルダに放り込んで、スプレッドシートのメニューを1回クリックする。それだけで会社名も品名も金額も納期も、行になって並ぶ。そういうツールを作りました。動画で実際の動きを紹介しています。
動画はこちら
注文書PDFをテンプレート方式で読む道は、最初から捨てた
注文書PDFを自動で取り込む仕組みをシステムで作ろうとすると、10年前であれば、帳票定義から始める必要がありました。例えば「この座標のこの矩形が注文番号、その下12ミリの枠が納期。」というような定義の仕方が必要だったわけです。この場合には、取引先が20社あれば20通りの定義を作る必要がありました。そうすると例えば先方が用紙を刷り直したら、システム側もまた作り直す必要があったわけです。
弊社が相談を受ける会社の注文書PDFでも、その注文書の形式はばらばらです。例えば、ひとつはエクセルで作った自社様式をPDF出力したもの。ひとつは基幹システムから吐き出された明細付きのもの。ひとつはFAXで届いた紙をスキャンしたもの。表計算ソフトの罫線がそのまま残っているものもあれば、罫線が一本もないテキストベタ打ちのものも存在します。
10年前のように座標で読む方式を採用すると、その時点で開発の採算が合わなくなるでしょう。20社分の定義を作る工数より、事務担当者が手で打ったほうが安いからです。「OCRは前に検討して、やめました」と言われることがあるのは、おそらくこの計算をした結果であると考えられます。
しかし生成AIの登場によってできるようになった今回作った仕組みのように、注文書PDFをそのままAIに渡す方式では、この作業が必要なくなります。システムやAIに座標はそもそも教えていませんし、項目名の揺れも教えていいません。例えばタイトルが「御注文書」でも「発注書」でも「PURCHASE ORDER」でも読みとることができます。他の項目についても、例えば「納期」という表記でも「希望納入日」でも「着荷指定日」でも、納期の欄として拾ってくれます。
注文書PDFをAIに読ませる仕組みは、Googleの中で完結する
この仕組みが具体的にどのように動いているかというと、Googleドライブに置いた注文書PDFを、Google Apps Scriptというプログラムでつくった仕組みが拾うという構造です。このプログラムが生成AI（Gemini）に情報を投げ、生成AIが返したデータをスプレッドシートに1行ずつ書くようにしています。処理が終わったファイルは済フォルダへ移すようにしています。
この仕組みのためのサーバーは立てていません。新しいSaaSも契約していません。つまり、すでにGoogle Workspaceを使っている会社なら、追加で払うのは生成AI（Gemini）のAPI利用料だけで済みます。ちなみにAPI利用料は、激安です！
注文書PDFをAIに読ませて詰まったのは、読み取り精度ではない
実際にこのシステムを組んでみて意外だったのは、文字を読みとる部分でほとんど苦労しなかったことです。動画でもご紹介していますが、斜めにスキャンした注文書PDFも、一発で読み取ることができました。
手こずったのは別のところです。
具体的には、空欄のPDFです。動画でもご紹介しているものですね。これが最初、いちばん厄介でした。全項目が空の紙をAIに見せると、素直に「読み取れません」と返してくれることもあるのですが、様式の見出し文字だけを拾って、それらしい行を作ってしまうことがありました。会社名の欄に「株式会社」とだけ入った行が生成されるようなことがあったのです。人間が見れば一目でおかしいのに、シートに並んだ200行のうちの1行になると、まず気づきません。
注文書PDFの読み取り結果に「要確認」をどこで立てるか
そこで操作ログのシートを追加しました。結果欄に成功か要確認かを記載するようにしたのです。
動画の後半に登場するのがこのシートなのですが、何件かに「要確認」が立っていることがわかるかと思います。該当の注文書PDFを開き直すと、金額がおかしいなどの確認事項を目で見て確認することができるようになっています。
「要確認」を立てるため、このシステムでは4つの条件を入れてみました。会社名か金額か納期のどれかが空、数量×単価が合計金額と一致しない、金額の桁が普段の取引レンジから外れている、（少々専門的ですが）JSONのパースに失敗した、のいずれかの条件です。
ちなみに、このうち「桁が外れている」のしきい値をどこに置くかという点は少々悩みました。上限を厳しくすると、たまにある大口が全部要確認になってしまいます。緩くすると、単価の桁を1つ多く読み違えたときに素通りしてしまいます。結局、過去の受注データの最大値の3倍を上限にして、下限は1円とすることにしました。これらは会社ごとに細かな運用設定が必要なところかと思います。
「結局チェックするなら手入力と同じでは」への回答
この注文書PDFの自動化ツールに対して、よく聞かれ感想があります。「目視するなら手入力と変わらないでしょう？」という意見です。
これはもちろん担当する事務担当者の頭の中次第だとは思いますが、弊社としては、目視といっても全件を疑いながら見るのと、全体のうち1件だけを見るのとでは、頭の使い方がまったく違うのではないかと感じています。
従来であれば、200行すべてに対して「これは合っているか」を判断し続ける作業が必要で、集中力が持ちませんでした。だから終盤ほどミスが増える。一方でこのシステムを使えば、AIが「ここが怪しい」と指差した場所だけをチェックすることができます。判断の回数が2桁減るというわけです。
なお、こういう感想を受けるとき、そもそも比べる相手を間違えているとも思っています。「AI対、完璧な人間」ではありません。手入力だってミスをしますし、桁を間違えるし、行を飛ばすし、似た品名を取り違えます。そうではなく、「AIが下書きして人が要確認だけ見る」と「人が全件打って人が全件確認する」の、工数とミス率を比較したほうが良いのではないでしょうか。
なおこのシステムでは、操作ログにファイル名と判定理由を残しているので、後から「どこを誰が確認したか」を追えるようにもしています。手入力にはなかったものです。
注文書PDFの自動化で削れる時間について、正直なところ
月200件、1件5分で打っているなら月17時間。時給2,000円なら年40万円。この手の記事によくある試算で、弊社でも提案のときに使います。
ただ、実際にこの通り削れるかというと、本当のところはケースバイケースです。事務担当者は注文書PDF「だけ」を打っているわけではないからです。電話を受けながら、来客に対応しながら、合間に打っている。その17時間がまるごと別の仕事に振り替わるかというと、そうはならないでしょう。
それでもこういったシステムを入れる価値があると弊社が考えているのは、時間というよりも、属人化防止のためです。このシステムを入れることで、取引先20社の様式を頭に入れている人が1人しかいない、という状態を解消することができます。担当者が休んだ日に受注登録が止まらないということを防止できるわけです。
ちなみにAPI利用料は、月数百件なら数十円～数百円のオーダーに収まります！ ここは大きなコストにはならないので大丈夫です。
注文書PDFをAIに読ませるうえで、まだ分かっていないこと
ただし、このシステムを長期運用したときに何が壊れるかは、まだ分かっていません。（日々進化する生成AIを使っており、長期運用した経験がないからです！）
例えばGeminiのモデルが更新されたとき、同じプロンプトで同じ精度が出るのか。出力の癖が変わることにならないか。このあたりはモデル側の都合なので、こちらでコントロールできません。バージョンを固定して使う手もありますが、それはそれで古いモデルに取り残されてしまいます。
まとめ
注文書PDFをAIに読ませる仕組みは、専用システムを買わなくても作ることができます。今回使ったのはGoogleドライブ、Google Apps Script、生成AI（Gemini）のAPI、スプレッドシートです。すでに手元にあるものの組み合わせで動くわけです。取引先ごとの帳票定義がいらないので、20社の様式がバラバラでもそのまま通ります。
システム導入によるコストカット（時間の削減幅）は、試算どおりというわけにはいかないかもしれません。それでも、取引先20社の様式を1人しか把握していない状態が解けることのほうを、弊社では評価したいと思います。
このような仕組みは、注文書PDFだけではなく、請求書でも納品書でも点検表でも同じ考え方で適用できるかと思います。自社の帳票でどこから手をつけるべきか整理したい会社は、AI業務改善診断をお試しください。