Claudeで発注書・納品書・請求書を三点照合する手順

発注書・納品書・請求書の三点照合は、PDFを3つ並べてClaudeに渡せば、数量・単価・品番のずれを一覧にする作業まで任せられます。ただし、Claudeが返す表はそのまま検収の根拠にはなりません。人が見るべきなのは「ずれがある行」と「Claudeが読み取りに自信を持てなかった行」だけに絞り、残りは目視を省く。この記事は、そこまでの流れを作る手順です。

見積書どうしの比較はClaudeでベンダー見積を比較する方法、数量の差異分析は棚卸差異の分析に書いています。ここで扱うのは、発注から請求までの3枚を突き合わせる工程です。

三点照合でClaudeに任せる範囲と人が残す範囲

三点照合の目的は、発注したものが、発注した数だけ、発注した値段で届き、その通りに請求されているかを確かめることです。突き合わせる軸は決まっています。

• 品番(品名):発注にあるものだけが届き、請求されているか
• 数量:発注数、納品数、請求数が一致するか
• 単価:発注単価と請求単価が一致するか
• 金額:数量×単価の小計と、請求の合計が合うか

Claudeが得意なのは、3枚のレイアウトが違っても、品番を手がかりに行を対応づけて表にする作業です。社名やレイアウトが異なる書類を、人が目で往復して照合する時間を減らせます。

人に残すのは、判断が絡む部分です。納品数が発注より少ない分を分納として扱うか、単価の差を値引き合意として認めるか、といった判断は書類の外にある事情で決まります。Claudeには「ずれの事実」を出させ、「許容するか」は人が決める。この線引きを最初に決めておくと、後の指示文がぶれません。

PDFを3つ同時に渡す仕組み

Claudeに渡したPDFは、ページごとに画像へ変換され、各ページから抽出したテキストが画像と一緒に渡されます。つまりClaudeは、テキストと見た目の両方を見て内容を理解します。表や押印の位置まで読めるのはこのためです。

渡し方は3通りあります。PDFのURLを指定する方法、base64でエンコードしてdocumentブロックに入れる方法、Files APIにアップロードしてfile_idで参照する方法です。社内の請求書をURLで公開するのは現実的でないので、実務ではbase64かFiles APIが使いどころです。Amazon BedrockとGoogle Cloudでは、現状はbase64のみ使えます。

リクエストには上限があります。

この上限はPDF以外のテキストも含むリクエスト全体にかかります。三点照合は1社1回の取引なら数ページから十数ページに収まるはずですが、月次でまとめて渡すとすぐ超えます。1取引ごとに1リクエスト、というのが基本の単位です。

トークンの目安は、1ページあたりおよそ1,500〜3,000トークンです。PDFだからといって追加料金はなく、通常のAPI料金が適用されます。ページ数が多いときは、先にトークン数を数えて見積もれます。

手順:三点照合のリクエストを組み立てる

リクエストの例

base64化した3つのPDFと指示文を、jqでひとつのJSONにまとめる例です。指示文はprompt.txtに書いておきます。

for f in po delivery invoice; do
  base64 < "$f.pdf" | tr -d '\n' > "$f.b64"
done
 
jq -n --rawfile po po.b64 --rawfile dn delivery.b64 \
  --rawfile inv invoice.b64 --rawfile prompt prompt.txt '{
  model: "claude-opus-5-5",
  max_tokens: 4096,
  messages: [{role: "user", content: [
    {type: "text", text: "【発注書】"},
    {type: "document", source: {type: "base64",
      media_type: "application/pdf", data: $po}},
    {type: "text", text: "【納品書】"},
    {type: "document", source: {type: "base64",
      media_type: "application/pdf", data: $dn}},
    {type: "text", text: "【請求書】"},
    {type: "document", source: {type: "base64",
      media_type: "application/pdf", data: $inv}},
    {type: "text", text: $prompt}
  ]}]
}' > request.json

あとはrequest.jsonをMessages APIに送ります。モデル名は公式のPDF入門に載っている例に合わせたものです。契約中のモデル名に置き換えてください。

curl https://api.anthropic.com/v1/messages \
  -H "content-type: application/json" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -d @request.json

指示文の書き方:ずれを区分して出させる

指示文で最も効くのは、出力の列と、ずれの区分を先に決めておくことです。次のような形になります(例示であり、実際の出力ではありません)。

3つのPDFは、順に発注書・納品書・請求書です。
品番をキーに行を対応づけ、次の列の表を出してください。
品番 / 品名 / 発注数 / 納品数 / 請求数 / 発注単価 / 請求単価 / 区分 / 根拠ページ
 
区分は次のどれか1つにしてください。
- 一致
- 数量差(発注数・納品数・請求数のどれかが違う)
- 単価差(発注単価と請求単価が違う)
- 未対応(3枚のうち1枚以上に該当行がない)
- 読取不確実(文字が不鮮明で数字を確定できない)
 
数字は書類に書かれた通りに転記し、推測で補正しないでください。
読み取れない箇所は空欄にせず「読取不確実」と書き、理由を添えてください。
根拠ページには、各書類の何ページ目かを書いてください。

ポイントは3つあります。

• 品番をキーにする:品名は書類ごとに表記が揺れやすく、キーに向きません
• 「推測で補正しない」と書く:合計が合うように数字を直されると、ずれが隠れます
• 「読取不確実」の区分を設ける:自信のない行を黙って確定させず、人に回させます

根拠ページを列に入れておくと、人が原本の該当ページを開くだけで確かめられます。ページの指定には、PDFビューアに表示される論理ページ番号を使うと指示がずれにくいというのが公式の推奨です。

検収前に人が確認する行を残す

返ってきた表を、そのまま回覧しないでください。人が見る行は次の3つに絞れます。

「一致」の行は、抜き取りで足ります。ただし抜き取りの対象には、金額の大きい行を必ず含めてください。

もうひとつ、合計の検算を人かスクリプトに残します。Claudeには「数量×単価の小計と、請求書の合計が合っているか」も聞けますが、この計算は表から機械的に再計算できるので、jqや表計算で確かめる方が確実です。Claudeの役割は行の対応づけと転記、計算の検証は決定的な道具、と分けると事故が減ります。

スキャンPDFで数字を読み違えるときの対処

納品書は、現場で受領印を押したスキャンが多く、ここが読み違いの最大の山です。仕組みを知っておくと対策が立てやすくなります。

PDFのページは画像としても渡されるので、テキストが埋め込まれていないスキャンでも、Claudeは画像を見て内容を読めます。一方で、画像の読み取りには限界があります。画像の説明ページには、低品質・回転・200ピクセル未満の小さな画像では、誤解釈や幻覚(実際にない内容を答えること)が起こり得ると書かれています。数え上げも、小さなものが多数あると正確とは限りません。

三点照合で起こりやすい誤りは、次のようなものです。

• 桁の読み違い:「1,000」と「10,000」、小数点やカンマの見落とし
• 似た文字の取り違え:0とO、1とl、5と6
• 受領印や手書きの訂正が、数字に重なっている

対策は、読み取りの自信を表に出させることと、人が桁を確認する順序を決めることです。

• 指示文に「数字は書類通りに転記し、不鮮明なら読取不確実とする」と入れる
• 納品書だけ、数量の列を別途「見えた通りの文字列」で出させ、数値化した列と並べて人が見比べる
• 金額の大きい行、桁が3つ以上ある行は、区分に関係なく原本を見る
• スキャン時に解像度を上げ、傾きを直してから渡す

ファイルが重いと、ページ数の上限に届く前に失敗することがあります。公式は、文字が小さいページや複雑な表が多いPDFは、上限の前にコンテキストを使い切ることがあると説明しています。その場合は、分割して渡すか、埋め込み画像を縮小します。パスワード付きや暗号化されたPDFは受け付けないので、事前に解除が必要です。エラーの原因切り分けはCould not process PDFの400エラーにまとめています。

運用に組み込むときの注意

同じ3枚に対して、指示を変えて何度も聞くなら、プロンプトキャッシュが使えます。PDFをキャッシュしておけば、繰り返しの分析の性能が上がると公式は説明しています。月末にまとめて処理するなら、バッチ処理も選択肢です。

件数が多い取引先では、PDFを1回ごとに送るより、取引単位でファイルを揃える前処理の方が効きます。発注番号をファイル名に含めておけば、どの3枚が1組かを機械的に決められ、組の取り違えという別の事故も防げます。

Claudeに任せない範囲も決めておきます。

• 検収の承認そのものは、人の権限に残す
• 差異の原因の断定はさせず、「確認が必要な事実」として出させる
• 取引先への問い合わせ文面を作らせる場合も、人が内容を確認して送る

PDF処理の上限をChatGPTと比べたい場合は、ClaudeとChatGPTのPDF処理上限の比較が参考になります。経理業務の全体像はClaude中小企業経理ガイドにあります。

よくあるつまずき

3枚の対応が崩れて、別の取引の行が混ざる

品番をキーにする指示がないと、品名の表記揺れで行が結びつかないことがあります。表の「未対応」が多いときは、品番の体裁(ハイフンの有無など)を指示文で揃えさせます。

合計は合っているのに、明細にずれがある

数量差と単価差が互いに打ち消し合うと、合計だけでは見つかりません。明細の行ごとに区分を出させる設計にしているのは、そのためです。

毎回、表の形が変わる

列名と区分を固定した指示文をテキストファイルで管理し、毎回同じものを使います。区分の名前を変えない限り、後工程の集計がそのまま使えます。

まとめ

三点照合では、行の対応づけと転記をClaudeに、計算の検算を機械に、許容するかの判断を人に分けます。スキャンの納品書は桁と似た文字の読み違いが最大の弱点なので、「読取不確実」の区分と根拠ページを表に入れ、人は原本のそのページだけを見る。この設計にすると、全件を目で往復していた検収前の作業が、ずれのある行の確認に絞られます。