請求書PDFをAIで読み取って転記する｜内製で決める5点

回答: 取引先ごとに様式が違う請求書・領収書のPDFでも、生成AIに読ませれば「発行元・発行日・登録番号・金額」といった項目を取り出し、台帳の1行に転記できます。Google Apps Script（GAS）とGemini APIを組み合わせた具体的な手順も公開されています。ただし、内製して経理の業務に載せるかどうかは、読み取り精度だけでは決まりません。 決め手になるのは、①AIが「自信はあるのに間違っている」ケースをどう拾うか ②二重登録と取りこぼしをどう防ぐか ③送るデータの扱い ④電子帳簿保存法の保存要件を満たせているか ⑤止まったときに誰が直すか の5点です。件数が確認にかけられる工数に見合っていて、自社に届く書類で精度と確認時間を検証でき、二重登録・取りこぼしの対策と、止まったときの復旧の体制まで用意できるなら、内製は選択肢になります。件数が多い・会計ソフトへの連携まで必要・止まると支払いが遅れる、のいずれかに当てはまるなら、会計ソフトの読み取り機能や請求書受領サービスの検討を先にしてください。

この記事でわかること

• 請求書PDFをAIで読み取って転記する仕組みが、いまどこまで実用域にあるか
• AIが自信を持って読み違えたケースを拾うための、機械側2段＋人の目の置き方
• 内製する前に決める5点（確認担当・二重登録・データの扱い・保存要件・復旧）
• 電子帳簿保存法の検索要件を、転記した台帳で満たせるかどうかの考え方
• 内製が向くケースと、向かないケース

AIで請求書を読み取る仕組みは、どこまで来ているか

答え: 「取引先ごとに様式が違うから自動化できない」という前提は、もう成り立ちません。様式ごとのルールを書かずに項目を取り出す方法が、手順まで公開されています。

従来のOCRと正規表現による取り出しは、「この位置にこの文字が来る」という前提でルールを書く方式が中心でした。固定位置や様式別のルールに依存する方式では、取引先が増えるほどルールが増え、相手が様式を変えたときに抽出漏れや修正作業が生じます。自動化の足を引っ張りやすいのは、読み取り精度よりもこの保守の重さです。

生成AIを使う方式では、PDFや画像をそのまま渡し、出力の形（どの項目を、どんな型で返すか）だけを指定します。 様式ごとのルールは書きません。

Qiita に公開されている datarou 氏の手順（Gemini APIで請求書・領収書のPDFを読み取ってスプレッドシートに自動転記する【GAS】）では、処理の流れはこうなっています。

1. Gmail を検索して、対象のメールと添付ファイルを取得する
2. ファイルのハッシュ値で、すでに登録済みかどうかを判定する
3. Gemini API に添付を渡し、項目をJSONで受け取る
4. コード側で検算してから、スプレッドシートに1行追記する
5. 処理したスレッドにラベルを付ける（処理済み／エラー）

取り出している項目は次のとおりです。

区分	項目
相手先	発行元（会社名・店名）、登録番号
書類	書類種別（請求書／領収書／その他）、請求書番号・領収書番号
日付	発行日、支払期限
金額	小計（税抜）、消費税額、合計（税込）、通貨
判定	要確認フラグとその理由

対象は PDF・JPEG・PNG で、Word や Excel は対象外です。パスワード付きのPDFは読めません。

注目すべきは、プロンプト側に「書類に書かれていない項目は推測で埋めない」「内税表記で税抜金額が書かれていない場合は小計を出力しない」「和暦は西暦に変換する」といった指示を置き、さらに出力の形をJSONのスキーマで固定している点です。自由な文章で返させず、型を決めて受け取ることで、後段のプログラムが扱える形になります。

「読めた」と「業務に載る」は別——機械側で2段、その先に人の目

答え: AI自身の「自信がない」という申告だけでは足りません。自信を持って読み違えたものを拾うために、コード側の検算を別に置きます。

前述の手順では、プロンプトで「自信がない場合は要確認フラグを立て、理由を書く」と指示しています。ただし出典記事自身が書いているとおり、この申告で拾えるのはAIが自分で迷ったケースだけです。はっきり読めたつもりで数字を1桁取り違えた場合、フラグは立ちません。

そこでコード側に検算を置きます。出典記事が実装しているのは次の5つです。

• 小計＋消費税と合計の差が1を超えていないか
• 登録番号が「T」＋13桁の形式になっているか
• 日付が YYYY-MM-DD の形式になっているか
• 合計金額が数値として扱えるか
• 書類種別が「その他」になっていないか

この二段構えを、役割で整理するとこうなります。

置く場所	拾えるもの	拾えないもの
プロンプト（AIの自己申告）	印字がかすれて読めない、該当項目が見つからない	AIが自信を持って読み違えたもの
コード側の検算	金額の内訳が合わない、形式が違う、種別が判定できない	検算を通ってしまう誤り（取引先名の誤り、年の取り違えなど）
人の目	上の2つが通した誤り	見る時間と担当が決まっていなければ機能しない

3段目の「人の目」を省ける仕組みだと考えないでください。 要確認の行は必ず確認したうえで、フラグが立たなかった行についても、導入のあいだは全件を原本と照合し、運用に乗ってからは抜き取りでの確認を続けてください。支払いに直結する項目（合計金額・振込先・支払期限）は、間違えたときの影響の大きさに応じて、原本との照合を残すのが安全です。

出典記事は、月次締めのときに要確認の行を目視する使い方を例に挙げています。これは全件目視をやめるための工夫であって、確認そのものを無くす設計ではありません。

なお、登録番号の形式チェックは有効ですが、形式が合っていても実在する登録番号とは限りません。実在の確認は国税庁の適格請求書発行事業者公表サイトで行います（同サイトの検索欄は「T」を除く13桁の数字を入力する形式です）。形式チェックは、入力ミスや読み取りミスのふるい分けまでと考えてください。

内製したものを誰が確認するかという論点そのものは、請求書に限りません。あわせてAIで作るのは速い、では誰が確認するのか｜内製の落とし穴もご覧ください。

内製する前に決める5点

答え: 技術的に動かすことより、下の5点を先に紙に書くほうが判断は早く済みます。どれか1つでも空欄のままなら、内製はまだ始めないでください。

1. 要確認の行を、誰が、いつ見るか

要確認フラグは、見る人がいて初めて意味を持ちます。「月次締めの前日に、経理担当がフラグの立った行だけ確認する」程度に具体的な約束を決めてください。担当と時期が決まっていない自動化は、誤りを静かに通し続けます。

2. 二重登録と、取りこぼしをどう防ぐか

同じ請求書が2回届くことは珍しくありません。再送、担当者からの転送、CCとBCCの両方での受信などです。出典記事では、ファイルのハッシュ値で同一ファイルを判定し、さらに「発行元（登録番号、なければ会社名）＋請求書番号」の組み合わせで二重請求を検知しています。

取りこぼし側の落とし穴も、出典記事が挙げています。処理済みラベルを付けたスレッドに後から届いた添付は処理されません。 「先日の請求書に追加分です」と同じスレッドに返信が来る取引先がいる場合、ここで漏れます。請求書番号の先頭の0が消える（文字列書式で保存する必要がある）という指摘もあります。

3. 送るデータの扱いを、契約の条文で確認する

請求書には取引先名・金額・振込先が載ります。どこへ送っているのかを、規約で確かめてから決めてください。

Gemini API の追加利用規約では、無料で利用する場合、送信した内容と生成された応答を Google が製品・サービス・機械学習技術の提供・改善・開発に利用するとされており、人のレビュアーが内容を読む場合があるとも記載されています（レビュー前に Google アカウント・APIキー・Cloudプロジェクトから切り離すとされています）。一方、有料での利用（請求先アカウントが有効な Cloud プロジェクト経由）では、プロンプトと応答は製品改善には使用されないとされています。出典はGemini API Additional Terms of Serviceです。

さらに同規約の無料サービスの項には、「Do not submit sensitive, confidential, or personal information to the Unpaid Services.」（機密情報・秘密情報・個人情報を無料サービスに送信しないこと／出典: 前掲 Gemini API Additional Terms of Service）という一文が置かれています。取引先名・金額・振込先が記載された請求書は、ここに触れると考えるのが自然です。無料枠に実際の請求書を送るかどうかは、「読んで判断する」話ではなく、規約が送らないよう求めている領域として扱ってください。

したがって実務上の線引きはこうなります。検証は自社のダミー書類で無料枠、実際の請求書を扱うのは有料枠。 そのうえで、取引先の情報を外部サービスへ送ることが社内のデータ取扱方針に合っているかを確認してください。規約は改定されるため、導入判断の時点で必ず最新版を読んでください。

4. 電子帳簿保存法の保存要件を満たせているか

ここは見落としやすい点です。AIで読み取って台帳に転記しても、元の電子データを保存する義務が消えるわけではありません。 メールで受け取った請求書は電子取引のデータとして保存対象になります。台帳は検索と確認のための道具で、保存そのものの代わりにはなりません。

国税庁「電子帳簿保存法一問一答【電子取引関係】」（令和7年6月）では、検索機能について、取引年月日・取引先名称・取引金額により2以上の記録項目を組み合わせて条件を設定できること、日付または金額については範囲を指定して条件を設定できることが求められるとされています（規則第2条第6項第5号）。

緩和される場合も示されています。

• 税務職員によるダウンロードの求めに応じることができるようにしている場合は、範囲指定と項目の組み合わせの要件は不要
• その上で、判定期間に係る基準期間における売上高が5,000万円以下の事業者、または電磁的記録を出力した書面を取引年月日その他の日付および取引先ごとに整理して提示・提出できるようにしている事業者は、すべての検索機能の確保の要件が不要（この場合も、ダウンロードの求めに応じられる状態は必要）

また、改ざん防止の措置として、タイムスタンプを付す方法、訂正削除の記録が残るシステムまたは訂正削除ができないシステムを利用する方法、訂正削除の防止に関する事務処理規程を定めて運用する方法のいずれかを行うこととされています。

転記した台帳に「取引年月日・取引先・取引金額」を列として持っておくこと自体は、検索の素地になります。ただし自社がどの要件に当てはまるかは、規模と受け取り方で変わります。 詳細は電子帳簿保存法一問一答【電子取引関係】を確認し、判断は顧問税理士と合わせてください。この記事は税務の助言ではありません。

5. 止まったときに、誰が直すか

出典記事がつまずき例として挙げているのは、モデル名の誤りや提供終了による404、レート制限の429、添付が大きすぎる400、出力が途中で切れる MAX_TOKENS、JSONのパースエラー、実行時間の制限、検索条件が広すぎる、パスワード付きPDFが読めない——といった内容です。

GAS側の制約も設計に効きます。1回の実行時間の上限は6分です（Googleのクォータ表では Consumer・Workspace とも「6 min / execution」と記載されています。出典: Quotas for Google Services）。出典記事は4.5分で手前で打ち切り、残りを次回に回す設計にしています。

もう1つ、見逃されやすい論点があります。出典記事はモデル名の初期値に「最新のFlash」を指すエイリアスを使いつつ、本番運用ではバージョン付きの名前に固定することを勧めています。 エイリアスのままにすると、モデルが切り替わった日に出力の傾向が変わり、作った人以外には原因がわかりません。

そして一番危ないのは、エラーで止まることではなく、止まったことに誰も気づかないまま締めの日を迎えることです。この失敗の形は請求書に限らないので、自動化が「成功」のまま止まるとき｜エラーにならない3パターンとGASのエラーに気づかず反響を取りこぼす理由と対策もあわせてご覧ください。

内製が向くケース・向かないケース

答え: 件数と、確認できる体制と、止まったときの影響の大きさで分かれます。

	内製が向く	内製より仕組みを買うほうが向く
件数と検証	件数が確認にかけられる工数に見合い、自社の書類で精度と確認時間を検証できている	全件を人が見きれない量がある／自社の書類で検証していない
確認体制	要確認を見る担当と時期が決まっている	誰が見るか決まっていない
連携先	台帳に転記できれば足りる	会計ソフトや基幹システムへの連携まで必要
止まったときの影響	支払い前に人が気づく工程がある	止まると支払いや締めが遅れる
直せる人	社内に複数いる（1人に依存していない）	1人だけ、またはその人が異動・退職しうる
書類の種類	PDF・画像で、印字されたもの	パスワード付きPDFが混ざる（出典記事の手順では読めません）

「向かない」側に寄るなら、会計ソフトの読み取り機能、請求書受領サービス、あるいは台帳側だけを業務アプリで持って入力と承認の流れを作る、といった選択肢のほうが総額で安く済むことがあります。内製の費用を見るときは、作る時間と、後から直す時間を一緒に数えてください。 逆に、要件が小さく確認体制があるなら、内製で十分に回るケースもあります。

この記事で扱っていないこと

• 手書きの書類の読み取り（出典記事に記載がないため、本記事では向き不向きを判断していません。実際の書類で別途検証してください）
• 明細行まで取り出す場合の設計（後述のFAQで触れる範囲まで）
• 会計ソフト各社の読み取り機能の比較
• 消費税・インボイス制度の税務上の取り扱いそのもの

よくある質問

無料のGemini APIで試すのは問題がありますか

自社のダミー書類で試す段階なら、手早い方法です。一方で、追加利用規約は無料サービスに機密情報・秘密情報・個人情報を送信しないよう求めており、送信内容と応答が製品・サービス・機械学習技術の提供・改善・開発に利用される場合があること、人のレビュアーが読む場合があることも記載されています。取引先の実際の請求書は、検証段階でも無料枠に送らない前提で進めてください。 実際の書類を扱う段階では有料サービスの適用条件を確認し、社内のデータ取扱方針と合わせて判断してください。

読み取り精度はどれくらい期待できますか

出典記事は取引先ごとに数枚ずつ試して傾向を確認することを勧めており、精度の数値は示していません。様式・印字品質・スキャンの状態で変わるため、自社に実際に届く請求書で試すしか確かめる方法がありません。他社が公開している精度の数値を、自社の前提として使わないでください。

明細行まで取り出せますか

出典記事が扱っているのは発行元・日付・登録番号・金額などの見出し項目で、明細行は抽出対象として示されていません（出力が長くなって途中で切れる原因として触れられています）。明細単位での原価管理まで必要なら、要件が1段上がると考えてください。工事原価のように明細単位で積み上げたい場合は、読み取りの話とは別に、台帳側の設計から決める必要があります。

まず何から始めればよいですか

直近1か月に届いた請求書を10通だけ数えてください。何社から、どの様式で、誰が何分かけて転記しているか。この10通で、読み取りが効く相手と効かない相手が分かれます。最初から全社を対象にせず、様式が安定している取引先から始めるのが現実的です。

まとめ

請求書PDFをAIで読むことは、もう「できるか」を論じる段階ではありません。判断を分けるのは、誤りをどこで拾い、誰が見て、止まったときに誰が直し、保存の要件をどう満たすかです。

この5点を書き出すと、内製で回るのか、仕組みを買ったほうが安いのかが見えてきます。そして多くの場合、最初に決まっていないのは技術ではなく、要確認の行を誰がいつ見るかです。

—

この記事を書いた会社

7plus株式会社 不動産会社向けの営業DX支援を行うITソリューションプロバイダーです。反響対応を即時化する「Mail2Link」「Mail2Link×AI」、ノーコード業務アプリ「BizBlock」の開発・提供に加え、Salesforce認定パートナーとして不動産特化型Salesforceパッケージの導入・定着コンサルティングも行っています。

詳しくはこちら → https://7plus.jp/