音楽出版社が海外のサブパブリッシャー・著作権管理団体から届く英文の分配明細を読み取り、楽曲ごと・作家ごとの分配額を支払の台帳に転記して、楽曲コードの不一致を拾う

処理の起点を決める

相手方ごとの受け取りの場所（S3 のフォルダ）にPDFが保存されたことを起点にします。 フォルダは royalty/<相手方コード>/<対象期間>/ の形にし、どの相手方・どの期間の明細かを、保存した場所で決めます。 明細の表紙の社名から相手方を決めると、同じグループの別の国の会社と取り違えます。

読み取りを始めるとき、ClientRequestToken に「相手方コード＋対象期間＋ファイルの番号」を入れます。 公式のページでは、同じトークンで StartDocumentAnalysis を呼ぶと同じ JobId が返り、同じジョブを誤って二度始めるのを防げるとされています。同じ明細を二度保存しても、分配が二重になりません。

完了は Amazon SNS の通知で受け、JobTag に入れた相手方コードと対象期間で、どの明細かを知ります。 JobId は7日間だけ有効なので、結果は受け取ったその場で S3 に保存します。

修正版の明細が後から届くことがあります。 同じ相手方・対象期間のフォルダに2つ目のファイルが入ったら、前の下書きを無効にせず並べ、行ごとの違いを確認事項に出します。

入力データを集める

質を決めるのは、相手方の楽曲コードの対応表です。 一度照合を確定した行は、相手方のコードと自社のコードの組として対応表に足します。次の月からは同じ楽曲がコードで決まり、AIに渡す行が減っていきます。

契約の分配率の一覧には、有効な期間も持たせます。 作家との契約が更新されて分配率が変わったとき、明細の対象期間が更新の前なら前の分配率で計算する必要があるからです。明細が届く日ではなく、明細の対象期間で分配率を選びます。 海外の分配は利用からかなり時間をおいて届くので、届いた日で選ぶと分配率を取り違えます。

ISWCは、楽曲台帳の側でも履歴を持ちます。 ISWCの公式のページでは、ISWCは楽曲（作品）を識別する番号で、録音や楽譜などは識別しないとされています。また、誤って割り当てられたISWCは、後から統合や分離ができるとされています。台帳のISWCが変わることがあるので、古いISWCでも引けるようにします。

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

表は、TABLE のブロックから CELL を行の番号・列の番号の順に並べて組み立てます。 公式のページでは、セルには行と列の位置が付き、列の見出し・小見出し・合計の行のセルにはそれぞれ COLUMN_HEADER・TABLE_SECTION_TITLE・TABLE_SUMMARY の印が付くとされています。小見出しの文字（たとえば「PERFORMANCE」「MECHANICAL」）は、その下の行の収入の種類として引き継ぎます。合計の行を楽曲の行として数えると、分配が二重になります。

**問い合わせは、表の外にある項目だけに使い、Pages: ["*"] を付けます。 公式のページでは、ページを指定しないと既定で1ページ目だけに当てる**とされています。合計と源泉の税額は最後のページにあることが多いからです。

結果は NextToken が返る限り GetDocumentAnalysis を呼び続け、全ページ分をそろえてから組み立てます。 公式のページでは、1回で返るブロックは最大1,000件とされています。数十ページの明細では何十回にも分かれます。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF のどれかであることを確かめます。XFA の形式のPDFとパスワードで保護されたPDFは扱えないとされています
2. ページをまたぐ表のつなぎ … 列の見出しが同じ表は、1つの表としてつなぎます。小見出しはページをまたいで引き継ぎます
3. 金額の読み方 … 小数点がカンマかピリオドかを相手方ごとの設定で読み分け、「(12.40)」「-12.40」を負の数として読みます
4. 行の合計の確かめ … 楽曲ごとの手取りの合計が、明細の合計と一致するかを確かめます。一致しなければ下書きを作らず、人に回します
5. 題名と作家名の正規化 … 大文字と小文字、記号、括弧の中の「TV SIZE」「INST」などを外した形を別に作ります。元の文字列も残します
6. ISWCの形の確かめ … 「T」に続く9桁と確認の数字の形になっているかを確かめます。形が違うものはコードとして使いません

4番目を軽く見ないでください。 写し間違いや行のずれは、合計の不一致として必ず表に出ます。合計が合わないまま照合と計算に進むと、どこかの作家の分配が増え、別の作家の分配が減ります。 合計が合ってから先に進みます。

AIに処理させる

させるのは2つだけです。 収入の種類の書き方を区分に当てはめることと、コードで決まらなかった行に、渡された候補の中から楽曲を選ぶことです。

候補選びでは、作家名の一致を題名の一致より重く見させます。 同じ題名の楽曲は台帳に何曲もありますが、題名と作家の両方が一致する楽曲は、ほとんどの場合1曲です。 作家名が1人も一致しない候補は、題名が同じでも選ばせません。

3行目がいちばん起きやすい失敗です。 候補に当てはまるものが無いとき、AIは「おそらく○○という楽曲」と台帳の外の題名を書きがちです。選べるのは渡した候補の番号と none だけにし、出力の形で縛ります。

指示内容を固定する

あなたは音楽出版社の印税の担当者を手伝い、海外から届いた分配明細の行に
自社の楽曲台帳の楽曲を当てる作業をします。
渡された「明細の行（題名・作家名・持分・相手方の楽曲コード）」と
「候補の楽曲（候補番号・題名・別の表記・作家と役割・持分）」だけを見てください。

【やること】
- 行ごとに、候補の中から同じ楽曲を1件選び、candidate_no に入れてください。
- 同じ楽曲と判断できる候補が無ければ、candidate_no に "none" を入れてください。
- matched_points に一致した点（題名・作家名・持分）を、
  mismatched_points に違う点を書いてください。

【厳守事項】
- 作家名が1人も一致しない候補は、題名が同じでも選ばないでください。
- 作家名は、名字と名前の順の違いとローマ字の書き方の違いを同じとみなしてよいです。
  ただし、別の人の名前に読み替えないでください。
- 候補に無い楽曲の題名を書かないでください。
- 金額や持分の計算をしないでください。
- 迷ったときに候補を選ばないでください。"none" にしてください。
- 括弧の中の「TV SIZE」「INST」「REMIX」などは、同じ楽曲の別の版として扱ってよいです。
  ただし、自社の台帳でそれが別の楽曲として登録されている候補があれば、その候補を選んでください。

「作家名が1人も一致しない候補は選ばない」を書くのは、題名の一致に引っ張られるからです。 「Sakura」の行に「Sakura」の候補が3件あると、AIは作家名の違いを「ローマ字の揺れ」と読み替えて選びがちです。作家名の一致を必須の条件として先に書きます。

括弧の中の版の扱いを書くのは、台帳の登録の仕方が会社ごとに違うからです。 版ごとに別の楽曲として登録している会社では、元の楽曲に当てると分配率がずれます。

出力形式を固定する

AIの出力は、Claude API の構造化出力で形を決めて受けます。 公式のページでは、output_config.format に JSON スキーマを渡すと、スキーマに合う JSON が返るとされ、正式提供の機能です。candidate_no は候補番号と none だけを列挙した値にします。数値の minimum／maximum などの制約はスキーマに書けないとされているので、値の範囲はプログラムで確かめます。

{
  "statement_id": "royalty/SP-FR/2026H1/1",
  "matches": [
    { "row_no": 212, "candidate_no": "2",
      "matched_points": ["題名 SAKURA NO UTA", "作家 YAMADA TARO（作曲）"],
      "mismatched_points": ["作詞者の記載なし"] },
    { "row_no": 213, "candidate_no": "none",
      "matched_points": ["題名 SAKURA"],
      "mismatched_points": ["作家名が候補のどれとも一致しない"] }
  ]
}

プログラムは、これに照合の方法と分配の計算を足して下書きにします。

{
  "row_no": 212, "work_code": "W-004518", "match_method": "ai_candidate",
  "income_type": "performance", "net": 84.20, "currency": "EUR",
  "allocations": [
    { "writer_id": "A-0091", "role": "composer", "rate": 0.5, "amount": 42.10 },
    { "writer_id": "A-0144", "role": "lyricist", "rate": 0.5, "amount": 42.10 }
  ],
  "checks": [ "lyricist_missing_on_statement" ]
}

match_method を残すのは、照合の確かさが方法で違うからです。 iswc と partner_code で決まった行は流し見で足り、ai_candidate の行は人が確かめます。

システムへ連携する

楽曲台帳には書き込みません。 ISWCや持分の食い違いが見つかっても、台帳を直すのは楽曲の登録の担当で、相手方への照会の結果を待ってからです。 明細の値で台帳を上書きすると、相手方の誤りが自社の台帳に入ります。

相手方の楽曲コードの対応表だけは、確定した照合から足します。 足すのは印税の担当が確定した行だけで、AIの候補のまま足しません。

人が確認する

1. total_mismatch を先に見る … 合計が合わない明細は、行のずれか読み取りの誤りです。原本で確かめます
2. ai_candidate の行を確かめる … matched_points と mismatched_points を読み、台帳で確かめて確定します
3. unmatched を照会の一覧に回す … 相手方に、楽曲の登録の内容を問い合わせます
4. iswc_mismatch と share_mismatch を楽曲の登録の担当に渡す … 台帳と相手方の登録のどちらが正しいかを確かめます
5. 支払の台帳に登録する … 確定した下書きだけを登録します。作家への支払は会計の手続きで行います

例外に対処する

3行目が、この構成で最も守りたいことです。 分配率が分からないまま「作曲と作詞で半分ずつ」と仮に計算すると、それらしい数字が支払の台帳に入り、そのまま作家に払われます。 分配率が無いときは金額を出しません。

記録を残す

• 分配明細の原本と、保存した場所（相手方・対象期間・版）
• Textract が返した結果の全文と、組み立てた行の一覧
• AIの出力（収入の種類の区分、候補選びの結果と根拠）
• 印税の担当が確定・変更した照合 … どの行を、どの楽曲に、なぜ当てたか
• 計算に使った分配率と、作家ごとの分配額の下書き
• 照会の一覧に回した行と、相手方からの回答

4つ目の記録は、相手方の楽曲コードの対応表と指示の改善に使います。 AIの候補を人が変えた行が多い相手方は、題名の書き方に癖があります。