請求書の転記をAIで|RPAより崩れに強い理由

請求書の転記をAIで|RPAより崩れに強い理由 AI活用の記事
結論

取引先が増えて書式がバラバラになる転記は、AIでの読み取りなら崩れにくい

決まった書式の転記なら、RPA(画面操作を自動化する道具)でもプログラムでも十分にこなせます。
ただし取引先が増えて書式がバラバラになった瞬間、当方の実測ではRPAもプログラムも同じように崩れ、崩れなかったのはAIだけでした。

  • 取引先が1〜2社で、請求書の書式がずっと同じなら … 今回の実演では、RPA・プログラムのどちらも全項目を正しく取得できた
  • 取引先が増えて書式がバラバラなら … 今回の実演では、AIが全55項目を正しく読み取った(1枚0.4〜2円)
  • プログラムを書ける人が社内にいないなら … AIにプログラムを書かせる方法もある
費用感
AIでの読み取りは1枚0.4〜2円ほど
最初の一歩
自社に届く請求書が「毎回同じ書式か、取引先ごとに違うか」を数える

なぜプログラムではなくRPAを使うのか

1APIが無くても動く
2現場の担当者が自分で直せる

エンジニアなら、転記のような作業は普通プログラムを書きます。それでもRPAが選ばれるのには、理由が2つあります。

1つは、RPAなら、API(他社のシステムからデータを受け取るための正式な窓口)の無いシステムでも動くことです。

APIが無くても、人がマウスやキーボードで操作するのと同じやり方で画面を動かせます。古い会計ソフトや、APIを公開していない業務システムでも自動化できるのはこのためです。

もう1つは、保守する人が違うことです。RPAは業務担当者が画面の録画やドラッグ&ドロップで組み立てられます。業務のやり方が少し変わっても、直すのは業務担当者本人です。

プログラムの保守を外注している会社では、直すたびにそのやり取りが挟まりますが、RPAならそこを省けます。あとで触れますが、AIコードエージェントを使えば、プログラムでもこのやり取りを省ける場合があります。

逆に言うと、社内にエンジニアがいて、対象のシステムにAPIがある場合は、プログラムの方が向いていることも多いです。この境目が、今回の実演の出発点になりました。

→ くわしくは「商品説明文をAIで|プログラムと人で誤りを止める」で解説しています。

架空の請求書11枚で、RPA・プログラム・AIを試した

当方が実際に確かめたのは、次のような場面です。ある会社に、取引先の運送会社から毎月同じ書式の請求書が届きます。

担当者がPower Automate Desktop(Microsoftが無料で提供するRPAツール)を使い、Excelへの転記を自動化しました。ここまでは順調でした。

ところが9月に、新しい取引先3社の請求書が混ざりました。書式は当然、運送会社のものとは違います。この状態でRPA・プログラム・AIがそれぞれどうなるかを、架空のデータで確かめました。

※ ここから先の数字はすべて、当方が作成した仮のデータ(実在しない会社名・金額)での実測です。実在の企業とは関係ありません。

用意したのは請求書PDF11枚です。

  • 基準の8枚:同じ取引先「サンプル運輸」からの月次請求書(書式は完全に同じ、数字だけが違う)
  • 崩れるパターンの3枚:新しい取引先3社。和暦の日付、支払期日の記載なし、値引き行ありと、それぞれ書式の癖が違う

取り出す項目は、取引先名・請求書番号・請求日・支払期日・合計金額の5つに絞りました。

動く方法
Before(取引先1社だけの想定)

RPA・プログラムのどちらでも問題なし
➜
After(取引先が増えた)

AIだけが崩れず、RPA・プログラムは書式ごとに直しが要る
正解率(5項目×枚数)
Before(取引先1社だけの想定)

40/40
➜
After(取引先が増えた)

AI 15/15、RPA 1/15、プログラム 3/15

→ くわしくは「Amazonの画像加工|AIとプログラムの境目」で解説しています。

RPAは、書式が変わると何が起きるか

当方の担当者が、Power Automate Desktopで実際にフローを組みました。PDFから文字を抜き出し、ラベルの前後を切り取ってExcelへ書き込む、という組み立てです。

実際に組み上げたフローの全体は、次の画像の通りです。

Power Automate Desktopで組んだ請求書転記フローの全体

フォルダー内のPDFを1件ずつ処理し、ラベルの前後の文字を切り取ってExcelへ書き込む、という流れを積み上げています。1つの項目を取り出すのに、切り取りの操作がいくつも並ぶ場面もありました。

基準の8枚(サンプル運輸の請求書)では、5項目×8枚=40項目すべてが正しく取れました。ここまでは狙い通りです。

ところが、新しい取引先3社を混ぜて流すと、様子が変わりました。

基準8枚(40項目) 新しい3社(15項目)
正解数 40/40 1/15(合計金額のみ)

新しい3社では、1社は5項目すべてが空欄になりました。別の1社は合計金額だけが正しく取れ、請求日は「:令和8年9月8日」とラベルの記号が混ざったうえ和暦のまま入りました。

残る1社は、Excelに行そのものが書き込まれませんでした(原因は突き止めていません)。

理由は単純です。RPAは「このラベルの後ろ、この記号の前まで」という位置を頼りに文字を切り出します。「請求日」というラベルが、書式によって「発行日:」や英語の「Date:」に変わると、同じ場所を探しても見つかりません。

プログラムを書いても、同じように崩れるのか

「それならプログラムの方が確実では」と思い、同じ条件でPythonの正規表現(文字のパターンを指定して探す書き方)を書いて試しました。

ただし、RPAのフローを組んだときと同じ前提、つまりサンプル運輸の書式だけを見て書いています。新しい3社の書式は見ずに進めました。

結果は、RPAとほとんど変わりませんでした。

基準8枚(40項目) 新しい3社(15項目)
RPA 40/40 1/15
プログラム(正規表現) 40/40 3/15

プログラムの3項目のうち1つは、支払期日の記載が無い請求書で何も取れなかった結果が、正解の「空欄」と一致したものです。実際に読み取れたのは2項目でした。

ここで分かったのは、「プログラムだから優れている」わけではないということです。

今回組んだRPAのフローと正規表現のプログラムは、どちらも「決まった位置に、決まった言い回しで書かれている」ことを前提にしていました。その前提が外れると、同じように崩れてしまいます。

この結果は「RPAもプログラムも役に立たない」という意味ではありません。取引先が1社しかなく、書式がずっと変わらないなら、どちらも十分に使えます。今回崩れたのは、取引先が増えて前提が変わったときの話です。

今回、なぜAIだけが書式の違いを越えて読み取れたのか

同じ11枚のPDFを、そのままAI(Claude Haiku・Claude Opus)に渡しました。ラベルの位置を指定する必要はなく、「取引先名・請求書番号・請求日・支払期日・合計金額を読み取ってください」と伝えるだけです。
料金は2026年9月時点のものです。

基準8枚(40項目) 新しい3社(15項目) 費用(11枚)
RPA 40/40 1/15 0円(ライセンス費は別)
プログラム 40/40 3/15 0円
AI(Haiku) 40/40 15/15 4.18円
AI(Opus) 40/40 15/15 20.92円

新しい3社も含めて、55項目すべてが両方のモデルで正解でした。和暦の日付は西暦にそろえられ、支払期日の記載が無い請求書では、勝手に推測せず空欄のまま返してくれました。

今回は、AIが読み取った値を、あらかじめ用意した正解表と機械的に突き合わせて採点しています。

実際の業務でAIの読み取り結果をExcelへ転記したあとは、当方や現場の担当者が原票と見比べて確定させる工程が必要です。この照合作業は今回、実演していません。

AIとRPA・プログラムの違いは、位置ではなく意味で読むことです。「請求日」でも「発行日」でも「Date」でも、そこに書かれているのが日付だと分かれば、ラベルの言い回しに左右されません。

AIにプログラムを書かせる手順

ここまでの正規表現のプログラムは、当方がPythonを書いたのではありません。AIコードエージェント(プログラムを書いて実行できるAI)に指示して作らせました。

コードを書き終えるまでの時間は数分です。あとで触れる3つのバグの修正まで含めても、その場のやり取りだけで終わっています。

進め方は次の4ステップです。

途中で、PDFの中の「月」「日」「支」の字がフォントの都合で別の文字コードになっていたり、円記号がバックスラッシュ(\)として出てきたりして、読み取れないバグが3つ見つかりました。これも手順4の要領で伝えると、その場で直してくれました。

Power Automate Desktopでのフロー作りでは、当方の担当者が何十回もダイアログを開き直し、設定を直しては動かす作業を繰り返す必要がありました。プログラムの場合は、コードを書いて動かして直すやり取りを、AIとの対話だけで素早く繰り返せます。

要点:プログラミングの知識が薄くても、AIに要件を伝えれば動くプログラムができる/作られたプログラムは0円で何度でも動かせる

ただし、書式を決め打ちにしたプログラムは、AIに書かせても新しい3社では崩れました。書式がばらばらなら、プログラムからPDFをAIに渡して読ませる形にします。今回のAIでの読み取りも、この形で動かしています。

AIにプログラムを書かせる手順

なお、Excelファイルのような対象は、AIコードエージェントで扱えます。ただしパッケージソフトの画面操作のようにファイルでもAPIでも触れないシステムには、この方法は使えません。

その場合は、Pythonで画面操作を自動化する道具(PyAutoGUIなど)もあります。ただし画面の位置やタイミングに頼るぶん、RPAと同じように崩れやすくなります。

今回のような、PDFやExcelなどファイルとして扱えるデータには、そもそも画面操作は要りません。

  1. 対象の書式を1〜2枚見せる
    … 今回はサンプル運輸の請求書PDFを渡しました
  2. 取り出したい項目を伝える
    … 「取引先名・請求書番号・請求日・支払期日・合計金額を取り出して」と依頼
  3. 実際に動かして結果を確かめる
    … 出てきた値が正しいか、値がずれていないかを見る
  4. おかしい点を具体的に伝えて直してもらう
    … 「日付の月と日が読めていない」のように、起きたことをそのまま伝える

つまずいた点

当方の担当者がいちばん時間を取られたのは、RPAで「取引先名」を取り出す設定でした。請求書番号のように「請求番号」というラベルが付いていればまだ簡単です。取引先名にはラベルが無く、「請求番号の行の次の行」という位置でしか判断できません。

最初に終了の目印として「御中」という文字を使ったところ、取引先名ではなく請求書の宛先(自社名)を拾ってしまいました。「御中」が文書の先頭近くにあって、狙っていた場所とずれていたためです。

改行を目印にしようとしても、入力欄でEnterキーを押すとダイアログごと閉じてしまい、別の入力方法を探す必要がありました。何段階かの切り出しを組み合わせてようやく取れたと思ったら、今度は前の設定のコピーが残っていて、意図と違う変数を参照していたことにも気づきませんでした。

1つ直すたびに、Excelを開いて中身を確かめ、また直す。この往復を、取引先名1項目だけで10回近く繰り返しました。書式が変わると崩れるという結果そのものより、直すたびに人の目で確かめる手間が、RPAでいちばん実感したところです。

FAQ

自社の請求書もRPAで自動化できますか?

取引先が少なく書式がずっと変わらないなら、今回の実演のようにRPAでも全項目を取得できます。ただし当方のおすすめはAIでの読み取りです。取引先が増えて書式が変わっても作り直さずに済み、今回は新しい3社も含めて全項目を正しく読み取れました。

プログラムを書くには、社内にエンジニアが必要ですか?

今回の正規表現のプログラムは、AIコードエージェントに要件を伝えて数分で作りました。ただし、PDFの文字コードのようなバグが実際に出るので、動かした結果を確かめて、おかしければ直す、というやり取りは必要です。

まとめ

  • 今回の実演では、決まった書式8枚の転記はRPAでもプログラムでも全項目を正しく取得できた
  • 取引先が増えて書式がバラバラになると、当方の実測ではRPAもプログラムも15項目中1〜3項目しか正しく取れなかった
  • AIはラベルの言い回しや位置に縛られず、今回の11枚55項目すべてを正しく読み取った(読み取り費用は1枚0.4〜2円)
  • 書式が決まっている範囲なら、プログラムをAIコードエージェントに書かせると、プログラミングの知識が薄くても、コード作成から動作確認まで短時間で済む
  • 画面操作でしか触れないシステムを除けば、ファイルとして扱えるデータに画面操作の自動化は要らない

次の一歩自社に届く請求書や伝票が、取引先ごとに書式がどれだけ違うかを1週間分だけ数える

自社の業務に合わせたAIツールの選定・導入は、
ぜひ、ジッソウLABのゲンバAIへ無料でご相談ください。

大平

執筆・監修

大平 — ジッソウLAB代表

中小企業の業務改善・メルカリ物販、中古PC販売の実務経験を活かし、現場目線でAI活用を検証・発信

NEXT ACTION

この記事の内容が「自社でもいけるか」は、1分の無料診断で確かめられます。
個別の事情は無料相談でどうぞ(売り込みはしません)。

コメント

タイトルとURLをコピーしました