証憑 · Shōhyō — 日本語の請求書・領収書・支払通知書を JSON 抽出する評価データセット

証憑（しょうひょう）は、請求書・領収書・支払通知書から項目を抜き出す「文書 → JSON 抽出」の精度を測るための、正解付き評価データセットです。和暦・軽減税率・源泉徴収・適格請求書（インボイス制度）・収入印紙税・相殺控除といった日本語帳票特有のロジックを、正解側で算術まで検証してあります。

抽出パイプラインを作ると、必ず「精度をどう測るか」で詰まります。本物の請求書は個人情報を含むため評価に使えず、正解 JSON を一件ずつ手で作るのも現実的ではありません。証憑は、その ground truth（正解データ）を肩代わりするためのものです。

測るもの / 測らないもの

採点の対象は、きれいなテキスト入力に対する抽出の正しさです。具体的には、和暦から西暦への変換、相対日付の解決、軽減税率 8% と標準税率 10% の区分、源泉徴収額の計算、収入印紙税、全角・記号の正規化など、日本語の帳票で間違えやすい箇所を見ます。

測らないのは OCR・レイアウト解析（画像 → テキスト）です。入力は document_text というテキストを前提にしているので、紙やスキャン画像からの読み取り精度は対象外になります。

収録

• 本体は請求書 2,000 件 / 領収書 2,000 件 / 支払通知書 2,000 件（合計 6,000 件）（無料サンプルは 45 件）。すべて合成データで、実在の企業・個人情報は含みません。
• 各レコードは document_text（現実的な本文）＋ expected_output（正解 JSON）＋ 難易度・難所タグの組です。
• JSON Schema、検証スクリプト、採点スクリプトを同梱しています。採点スクリプトは、自分の抽出器の精度を難所別に分解して出してくれます。

支払通知書は構造が反転している（2026-08 追加）

支払通知書（仕入明細書）は買手が発行する文書なので、請求書と立場が入れ替わります。issuer が支払者（買手）、payee が支払先（売手）で、登録番号は売手側に付きます（仕入明細書として保存する場合に必要になるため）。「どちらの登録番号か」を取り違える抽出器は、ここで落ちます。

この文書タイプ固有の難所も入れてあります。

• 複数請求書の合算 — 明細 1 行が請求書 1 枚に対応し、invoice_number を持ちます
• 相殺・値引き・振込手数料の控除（deductions）— 支払額は 税込 − 源泉徴収 − 控除合計
• 締日と支払予定日 — 日付が 2 つあり、どちらを取るかを間違えやすい

作り方（正解を先に確定してから本文を描く）

一般的な合成データは「本文を書いてから、そこに書かれた正解を読み取る」順序で作られます。この順序だと読み取りの段階で誤りが混入します。証憑は逆向きに作っています。

1. 正解の構成 — 金額・税率区分・税額（切捨／四捨五入／切上）・源泉徴収額・収入印紙税額を先に確定する。
2. 本文の描画 — 確定した値から document_text を描画する。和暦・全角・「￥」「金〜円」・相対日付といった表記の揺れは、ここで意図的に振る。

正解が先にあるので、本文と正解が原理的に食い違いません。そのうえで機械検証（スキーマ適合＋算術の全件検算：明細＝数量×単価／税率区分の合算／小計・税込／源泉徴収額／収入印紙税額）を通しており、現行の本体 6,000 件はすべて合格しています。

生成は seed を固定した決定論なので、同じ版はいつでも同一に再現できます。

使うシーン

• 内製した抽出器の回帰テスト — モデルやプロンプトを変えたとき、難所別のスコアがどこで落ちたかを見る。「軽減税率の区分だけ悪化した」のような形で原因に当たれます。
• 会計 / 経理 SaaS の新規参入時のベンチ — 自社の抽出精度を、特定前提に依存しない共通のものさしで測る。社内データだけだと評価が甘くなりがちなところを補えます。
• LLM アプリ / エージェントの CI 組み込み — 採点スクリプトをそのままパイプラインに差し込み、リリース前に抽出精度のしきい値チェックを回す。

比較

正解データを自前で作る場合、本物の請求書は個人情報の壁があり、合成しても「正解が本当に正しいか」を誰も検算していない、という問題が残ります。とくに源泉徴収や軽減税率の区分は、人が手で正解を作ると取り違えが起きやすいところです。

証憑は、正解を先に確定してから本文を描く作り方にして、そのうえで算術を全件検算しているのが差分です。きれいなテキスト入力に絞っているぶん、OCR の良し悪しに評価がぶれず、抽出ロジックそのものの精度だけを切り出して見られます。

入手

まず無料サンプルで中身の性質を確認してから、必要な範囲のライセンスを選んでください。

無料サンプル（Hugging Face）

請求書 20 件 / 領収書 10 件 / 支払通知書 15 件の凍結版。本体と同じ生成方式・同じスキーマなので、買う前に「どんな難所が入っているのか」「正解の粒度はどれくらいか」を確認できます。CC BY-NC 4.0（非商用・評価用途）。 → データセットページ

有料版（合計 6,000 件 / 3 文書タイプ）

いずれも validate.py（算術整合の全件検算）と score.py（難所別の採点）を同梱します。

年間ライセンスで約束しているのは次の 3 点だけです。「毎月」「毎四半期」といった固定頻度の更新は約束していません。 制度改正は毎月起きるものではなく、難所の追加は設計作業を伴うため、守れない頻度を掲げるほうが不誠実だと考えています。

• 契約期間中に追加される文書タイプは、すべて追加費用なしで利用可（2026-08 に支払通知書を追加しました。次の候補は納品書・契約書ですが、追加時期は確約しません）
• 税制・様式の改正があった場合、90 日以内にスキーマとデータを追従
• 既存文書タイプの件数・難所の拡充（年 1 回以上）

制作の記録は Build に書き残していきます。

用途は抽出精度の評価です。税務・会計の助言ではありません。税率区分などは特定前提下の一例であり、実務判断は専門家にご確認ください。