大学に海外の出版社から届く英文の論文掲載料（APC）の請求書を読み取り、論文・著者・割引の適用を契約条件と照らして、支払いの可否を一次判定する

処理の起点を決める

学内のAPCの支払申請が受け付けられたことを起点にします。 添付のPDFを S3 の apc/<年月>/<申請番号>/ に保存し、どの申請の請求書かを保存した場所で決めます。 宛名から申請を探すと、同じ研究者の別の論文と取り違えます。

保存をきっかけに、請求書の項目と明細を取る StartExpenseAnalysis と、論文の情報を問い合わせで取る StartDocumentAnalysis を同時に始めます。 請求書の読み取りの機能には問い合わせを渡す口が無いため、2つに分けます。

どちらも ClientRequestToken に「申請番号＋版」を入れます。 公式のページでは、同じトークンで呼ぶと同じ JobId が返り、二重の開始を防げるとされています。完了は Amazon SNS の通知で受け、JobTag に入れた申請番号でどの申請かを知ります。 JobId は7日間だけ有効なので、結果は受け取ったその場で S3 に保存し、2つがそろってから照合を始めます。

入力データを集める

質を決めるのは、契約条件の一覧の「対象誌のISSN」と「対象の論文の種類」の列です。 ISSN があれば誌名の表記のゆれに関係なく引けます。論文の種類の列が無いと、契約で対象外とされた種類まで「契約の対象」と判定してしまいます。 名簿には論文で使うローマ字の表記と旧姓を入れます。

データの取得方法を決める

請求書の項目は、標準の名前で受けます。 公式のページでは、書類に書かれた項目名は LabelDetection、値は ValueDetection として、それぞれ信頼度付きで返るとされています。GetExpenseAnalysis は1回に20件までしか返さないので、NextToken が返る限り呼び続けます。途中でやめると、2ページ目の割引や税の行が落ちます。

論文の情報は、問い合わせで取ります。 問い合わせは英語の文書でだけ使え、非同期では1ページあたり30件までです。答えは QUERY_RESULT として信頼度付きで返り、見つからなければ空のまま返るので、原稿番号の書かれていない請求書を見分けられます。

AIへ渡す前に整形する

1. 形式の確認 … 請求書の読み取りは JPEG・PNG・PDF に対応すると公式のページにあります。TIFF で届いたものはPDFに変換します。 XFA の形式のPDFは扱えないとされています
2. パスワードの確認 … パスワードで保護されたPDFは扱えません。 研究者に解除して添付し直してもらいます
3. 1ファイルに複数の請求書がないかの確認 … 請求書の読み取りは、書類の中の請求書の数を ExpenseIndex で返します。2件以上なら、申請と1対1にならないので人に回します
4. 通貨と数の整理 … 値の通貨のコードと、明細の行の通貨がそろっているかを確かめ、数を数値に直します
5. 原稿番号の整え … 前後の空白と記号をそろえ、出版社ごとの原稿番号の形（英字と数字の並び）に合うかを確かめます
6. ISSN の確かめ … ISSN は8桁で、最後の1桁が検査用の数字（X のこともある）です。計算が合わないものは読み取りの誤りとして扱い、誌名で引き直します
7. 合計の確かめ … 明細の行を足した額が TOTAL と合うかを確かめます

7番目は、明細の読み落としを照合の前で止めるためのものです。 割引の行が読み取れていないと、割引の付け漏れに見えます。

AIに処理させる

させるのは、表記のゆれと言葉を扱う4つの仕事だけです。 項目の読み取りは Textract、照合と判定はプログラムが行います。

1行目と2行目は、候補を出すまでです。 採るかはプログラムが規則（著者なら名簿の在籍の期間が論文の時期に合うか）で決め、決められなければ人に回します。

3行目を外すのは、研究費ごとに使い方の決まりが違うからです。 予算の番号が申請に書かれているかを確かめるところまでが、この構成の仕事です。

指示内容を固定する

責任著者の候補を出す指示です。

あなたは大学の経理課で、論文掲載料の請求書に書かれた責任著者が、
本学の研究者の名簿の誰に当たるかの候補を挙げる担当者を手伝います。
渡された「請求書の責任著者の表記」と「名簿の抜粋」だけを見てください。

【やること】
- 名簿の抜粋から、同じ人の可能性がある研究者を最大3人挙げてください。
- 挙げた理由を、表記のどこが一致するか（姓、名、頭文字、旧姓、ミドルネーム）で書いてください。

【厳守事項】
- 名簿の抜粋に無い人を挙げないでください。
- 姓だけが一致する候補には、理由に「姓のみ一致」と書いてください。
- 本学の所属かどうか、契約の対象かどうかを書かないでください。
- 候補が無ければ、candidates を空にしてください。推測で埋めないでください。

明細の行を分け、照会の下書きを作る指示です。

あなたは大学の経理課で、海外の出版社の論文掲載料の請求書を扱う担当者を手伝います。

【明細の区分】
渡された明細の行を、次のどれかに分けてください。
apc（論文掲載料）／discount（割引・会員の値引き・免除）／tax（税）／
color_charge（カラー図版の料金）／page_charge（ページ超過の料金）／other
- 行の言葉だけで判断してください。金額の大きさから推し量らないでください。
- 行の原文を raw にそのまま残してください。
- 「waiver」「voucher」「prepaid」「agreement」の語があれば、その語を qualifier に写してください。

【照会の下書き】
- 原稿番号、誌名、請求番号、請求額を、渡された値のままで書いてください。
- 保留の理由（contract_covered／discount_missing／duplicate）ごとに、
  根拠として渡された契約の条件や過去の請求番号を並べてください。
- 支払わないと書かないでください。確認をお願いする形にしてください。
- 割引の額や正しい請求額を計算して書かないでください。

「agreement」「prepaid」を写させるのは、契約で精算済みであることが明細に書かれていることがあるからです。 「Covered by institutional agreement」で合計が0の書類は通知で、支払の手続きに回さずに済みます。

出力形式を固定する

一次判定は、プログラムがJSONで出します。 生成AIの出力も、Claude API の構造化出力で形を決めて受けます。公式のページでは、output_config.format に JSON スキーマを渡すと、スキーマに合う JSON が返るとされ、正式提供の機能です。

{
  "request_no": "APC-2026-0912",
  "invoice": { "invoice_id": "", "publisher": "", "currency": "EUR",
               "subtotal": 2890.00, "discount": 0.00, "tax": 0.00, "total": 2890.00,
               "due_date": "2026-11-13", "sum_check": "matched" },
  "article": { "manuscript_id": "", "journal": "", "issn": "",
               "issn_check": "ok | failed | missing",
               "corresponding_author": "Yamada, Taro", "article_type": "Research Article" },
  "matching": {
    "contract_type": "transformative | discount | none",
    "journal_covered": "yes | no | unknown",
    "author_affiliated": "yes | no | unknown",
    "article_type_covered": "yes | no | unknown",
    "expected_discount_rate": 0.15, "applied_discount_rate": 0.00,
    "request_found": true, "budget_code_present": true,
    "duplicate_of": ""
  },
  "verdict": "payable | hold_contract | hold_discount | hold_request | duplicate | needs_human",
  "reasons": [ "Journal ISSN in agreement list; author matched (Faculty of Medicine)" ],
  "min_confidence": 96.4
}

契約の3つの条件を別々の列で持つので、どれが unknown かで図書館に何を確かめてもらえばよいかが決まります。 verdict は規則で決めます。

上から順に当てます。 hold_contract を先に置くのは、契約で精算されるはずの論文に払う誤りが、いちばん取り戻しにくいからです。

システムへ連携する

財務会計システムにも申請にも書き込みません。 一次判定を申請に書き戻すと、研究者には「経理が却下した」と見えます。

Claude を Amazon Bedrock から使う場合は、構造化出力の対応を先に確かめます。 公式のページでは、Bedrock では構造化出力が旧来の連携でだけ使え、Claude in Amazon Bedrock では使えないとされています。

人が確認する

経理の担当者が全件の一次判定を確かめます。 payable は一覧で根拠を流し見て、保留のものに時間を使います。

1. hold_contract を先に見る … 3つの条件の根拠を確かめ、図書館の担当者に出版社の管理画面で論文の状態を見てもらいます
2. needs_human の unknown を埋める … どの条件が決められなかったかを見て、原本で確かめます
3. hold_discount の割引率を確かめる … 一覧の割引率と、請求書の割引の行を見比べます
4. duplicate の過去の支払を開く … 再送の請求か、別の料金（カラー図版など）の請求かを見ます
5. 照会を直して送る … 下書きの番号と根拠を確かめ、送信は担当者が行います。研究者にも同時に知らせます

payable も、最初の3か月は全件を原本で見ます。 規則の漏れは、payable の中にしか現れないからです。

例外に対処する

最後の行は、契約の対象が受理日で決まるか出版日で決まるかが契約ごとに違い、請求書だけでは決められないためです。

記録を残す

• 請求書の原本と、保存した場所（申請番号・版）
• Textract が返した結果の全文（請求書の項目と明細、問い合わせの答え）
• 照合に使った契約条件の一覧と研究者の名簿の、その時点の版
• 一次判定（matching、verdict、reasons）と、生成AIが出した候補と採否
• 担当者が判定を覆した記録 … どの条件を、どう直したか
• 図書館への回付と出版社への照会、その回答
• 出版社ごとの保留の件数と理由の推移

3つ目で一覧の版を残すのは、契約の対象誌が年ごとに変わるからです。 当時の一覧が残っていないと、判定が正しかったかを確かめられません。