ライセンス先から届くロイヤルティ報告を読み取って、契約条件どおりかを点検する

処理の起点を決める

ライセンス受付専用のメールボックスへの新着メールを起点にします。報告書の送付先を専用アドレスに統一してもらうことが前提です。

担当者個人のメールアドレスへ届く運用のままでは、担当者が休んだ日に処理が止まります。契約更新や担当者の交代のタイミングで、送付先の変更を相手先へ依頼してください。 これは仕組みの前に片付けておく作業です。

もう1つの起点として、毎日の期限チェックを置きます。契約ごとの報告期限を持つテーブルを日次で見て、期限を過ぎているのに報告が届いていない相手先を洗い出します。こちらのほうが、金額の点検より先に効果が出ることがあります。 報告が来ていないことに気づけていない状態が、もっとも損をしているからです。

入力データを集める

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

報告書： メール添付で受け取り、SharePoint へ保存します。形式は3通りに分かれます。

Claude API はPDFをそのまま入力として受け取れます。リクエスト全体で最大32MB、ページ数は最大600ページ（コンテキストウィンドウが100万トークン未満の場合は100ページ）です。報告書は数ページなので、この上限に当たることはありません。ページ内のテキスト、図、表を扱えるため、レイアウトが単純な報告書ならカスタムモデルを作らずに済むこともあります。

カスタム抽出モデルを作るかどうかの判断は、件数で決めてください。 月に複数回届く上位10社程度は作る価値があります。年に数回しか届かない相手先は、汎用の読み取りで十分です。カスタム抽出モデルの入力はPDFと画像（JPEG/JPG、PNG、BMP、TIFF、HEIF）に対応し、PDFとTIFFは最大2,000ページ、有料プランでのファイルサイズは500MBまでです。

契約条件テーブル： この構成でもっとも手間のかかる準備です。契約書を1本ずつ読み、次の項目を表に落とします。

60社分を一度に作る必要はありません。 報告額の大きい上位20社で、全体の8割を占めることが多いはずです。そこから始めてください。

AIへ渡す前に整形する

1. 相手先の特定 … 送信元のドメインを相手先マスタと照合します。ドメインが一致しないメールは、件名と本文から候補を出して人へ回します
2. 報告書以外の除外 … 同じアドレスに問い合わせや請求書が届きます。件名と添付のファイル名で絞り込みます
3. 対象期間の正規化 … 「2026年度第2四半期」「Q2 FY2026」「2026年7月〜9月」を同じ期間として扱えるよう、開始日と終了日に直します。相手先の決算期が自社と違うことがあります
4. 通貨と単位の判別 … 金額の単位が千円なのか円なのか、USDなのかJPYなのかを、表の見出しから判定します。ここを誤ると桁が1,000倍違います
5. 重複の検出 … 同じ期の報告が再送されることがあります。「相手先＋対象期間」で既存データと照合し、再提出なら前の版を差し替える扱いにします

AIに処理させる

役割を3つに分けます。

OCR（Document Intelligence）にさせること： 報告書の表から、行と列の構造を保ったまま値を取り出すこと。ここはLLMにさせません。 表形式のデータは専用モデルのほうが安定し、費用も安く済みます。

LLMにさせること：

表計算側で行うこと： 算定額の再計算、差額の算出、最低保証との比較、前期比の増減率。すべて数式で行います。

この分担が重要です。AIに金額を計算させると、検算のしようがなくなります。 AIの役割は「この数字は何か」を決めるところまでで、決まった数字を使った計算は機械的な処理に任せます。

指示内容を固定する

あなたは知財部のライセンス管理を支援する担当者です。
ライセンス先から届いたロイヤルティ報告書の抽出結果を、
契約条件の項目へ対応づけてください。

【厳守事項】
- 金額、数量、日付を書き換えないでください。抽出結果の値をそのまま引き継いでください。
- 金額の計算をしないでください。合計、料率の掛け算、差額の算出は行わないでください。
  対応づけだけを返してください。
- 「正味売上高」に当たる数字を1つだけ選んでください。複数の候補があり
  どれか決められない場合は net_sales を null にし、candidates に候補を並べてください。
- 控除項目は、下の「契約で認めた控除区分」からのみ選んでください。
  どれにも当てはまらない控除が報告されている場合は、区分を "契約外" として
  その名称をそのまま deduction_name に書いてください。**勝手に近い区分へ寄せないでください。**
- 製品が契約の対象範囲に入るかは、下の「対象製品の定義」に照らして判定してください。
  判定できない製品は in_scope を "unknown" にし、理由を書いてください。
- 通貨と単位（円／千円／百万円）を必ず明示してください。
  表の見出しに書かれていない場合は unit を null にしてください。**推測しないでください。**
- 報告書に書かれていない期間や製品を補わないでください。

【契約条件】
{contract_terms}

【契約で認めた控除区分】
{allowed_deductions}

【対象製品の定義】
{product_scope}

【報告書の抽出結果】
{extracted_report}

「勝手に近い区分へ寄せない」の1行が重要です。 これを書かないと、AIは「広告協賛金」という控除を「値引」として処理します。契約で認めていない控除が通ってしまい、その分だけ受け取るロイヤルティが減ります。 契約外の控除は、契約外として残さなければ意味がありません。

「金額の計算をしない」の1行も同じくらい重要です。 LLMに掛け算をさせると、たいていは合いますが、合わない場合に気づけません。計算は数式で行い、AIの出力は入力として使うだけにします。

照会文の下書きを作らせる場合は、別の呼び出しにします。

下の食い違いについて、ライセンス先へ送る照会文の下書きを作ってください。

【厳守事項】
- 事実だけを書いてください。相手の意図を推測しないでください。
  「意図的に除外されたものと思われます」のような書き方をしないでください。
- 契約の該当条項を引用し、こちらの理解を示したうえで、確認を依頼する形にしてください。
- 金額は下の数値をそのまま使ってください。書き換えないでください。
- 支払いを求める表現にしないでください。まず事実確認を依頼する段階です。
- 5〜10行にしてください。

出力形式を固定する

{
  "licensee_code": "",
  "contract_no": "",
  "period_start": "",
  "period_end": "",
  "currency": "",
  "unit": "円 | 千円 | 百万円",
  "net_sales": 0,
  "net_sales_candidates": [],
  "products": [
    {
      "product_name": "",
      "model_code": "",
      "quantity": 0,
      "gross_sales": 0,
      "in_scope": "yes | no | unknown",
      "scope_reason": ""
    }
  ],
  "deductions": [
    {
      "deduction_name": "",
      "amount": 0,
      "category": "返品 | 現金値引 | 消費税 | 契約外",
      "allowed": true
    }
  ],
  "reported_royalty": 0,
  "fx_rate": 0,
  "fx_basis_stated": "",
  "missing_fields": [],
  "needs_review": [],
  "reason": ""
}

JSON Schema を指定して出力を固定します。Claude API では output_config.format に json_schema を渡すことで、応答をスキーマに沿った形に制約できます。

金額は文字列ではなく数値で返させてください。 文字列にすると「1,200,000」のようにカンマ入りで返り、後段の計算で壊れます。

net_sales_candidates は、正味売上高に当たる数字を1つに絞れなかったときの候補です。ここに複数入っている報告書は、そもそも様式が読み取りづらいということなので、相手先に様式の統一を依頼する候補になります。

fx_basis_stated は、報告書に為替レートの根拠が書かれていたかどうかです。書かれていない外貨報告は、それ自体が照会の対象です。 契約で「期中平均」と定めていても、相手が期末レートを使っている可能性があります。

システムへ連携する

抽出結果と契約条件から、点検シートをスプレッドシートに作ります。計算はすべてこの表で行います。

点検シートには、差額の大きい順に並べた一覧と、次の指摘欄を出します。

• 契約外の控除が計上されている
• 対象製品の判定が unknown のものがある
• 前期に報告されていた製品が、今期は報告されていない
• 最低保証を下回っている
• 為替レートの根拠が書かれていない
• 報告期限を過ぎている

確定した内容だけを、ライセンス台帳と会計システムへ渡します。 請求データの自動作成はしません。受け取る金額が確定するのは、相手先との照会が済んでからです。

人が確認する

全件、担当者が確認して確定します。段階的な自動化もしません。

理由は2つあります。1つは、指摘が必ずしも相手の誤りとは限らないためです。契約条件テーブルの側が古い、という可能性が常にあります。 契約は変更されます。覚書が交わされているのにテーブルへ反映されていなければ、正しい報告が誤りとして指摘されます。

2つ目は、相手先との関係に直結するためです。誤った指摘を送れば、相手の信頼を失います。差額が出たときに「なぜそうなったか」を人が納得したうえで照会することが、この業務では欠かせません。

確認を速くするための設計が効きます。

• 差額の絶対値の大きい順に並べる
• 契約外の控除がある行を最上部に出す
• 契約条件テーブルの最終更新日を各行に表示する（古ければテーブルの側を疑える）
• 報告書の該当箇所と、契約書の該当条項を左右に並べて表示する
• 前期・前々期の同じ相手先の数字を並べる

3つ目が効きます。 「この契約条件は2年前に登録されたまま」と一目で分かれば、指摘を鵜呑みにせずに契約書へ戻れます。

例外に対処する

記録を残す

この業務の記録は、監査の権利を行使するときの根拠になります。

• 報告書の原本（メール本文と添付）
• 抽出結果（生のJSON）
• 適用した契約条件テーブルの内容と、その版
• 自社計算の算定額と差額
• 人が確定した内容と、指摘を採らなかった場合の理由
• 相手先への照会文と、その回答
• 確定日、確定した担当者

「指摘を採らなかった理由」を残すことが効きます。 同じ相手先で同じ指摘が毎期出ているのに毎回見送っているなら、契約条件テーブルの側が間違っている可能性が高くなります。

契約には監査の権利が定められていることがあります。実際に監査を行うかどうかの判断材料は、この点検の積み重ねです。 「3期連続で契約外の控除が計上されている」という記録があって初めて、監査を申し入れる根拠になります。