海外のストック素材サイトの英文のライセンス証書と請求書を読み取って素材台帳に転記し、期限切れ間近と範囲外の利用を拾う

処理の起点を決める

起点は2つあります。証書が受付フォルダに入ったときと、毎月1日です。

1つ目は、受付フォルダ（Amazon S3）に証書と請求書が保存されたことです。購入した担当者が、ファイル名の先頭に案件コードを付けて入れます。注文確認のメールを専用のアドレスに転送すると添付が受付フォルダに入る仕組みも置き、購入した日のうちに台帳の仮登録まで進めます。 月末の回収をやめるのが目的です。

2つ目は、毎月1日の定時です。台帳の全行を、案件の使用計画とライセンス種別の条件表に照らします。月1回にしているのは、使用計画のほうが月の途中で動くためです。 印刷部数の増刷や掲載期間の延長は、購入の時点ではまだ決まっていません。

期間の終了日が60日以内に来る行は、毎週月曜にも一覧にします。 掲載の延長を決めるのに、月1回では遅いことがあります。

入力データを集める

質を決めるのは、ライセンス種別の条件表です。 証書に書かれたライセンス種別の名前（Standard License、Extended License など）を、条件表の行に対応付けて初めて、印刷部数や媒体と比べられます。条件表に無い種別は、照合をせずに人に回します。

使用計画に素材IDの列が無いと、照合は始まりません。 案件管理の仕組みに「使う素材ID」を入れる欄を足すのは、制作進行の側の準備です。

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

読み取りは StartDocumentAnalysis にS3の場所と FeatureTypes を渡して始めます。完了は NotificationChannel に指定した Amazon SNS のトピックに通知され、状態が SUCCEEDED なら GetDocumentAnalysis で結果を取ります。

表は、セルの行と列の番号で組み立て直します。 列見出しの付いたセルから、Asset ID、Description、License、Price の列を決め、行ごとに「素材ID・説明・ライセンス種別・金額」の組にします。 見出しの書き方はサイトで違うので、Image #、Item、Content ID のような別名を、サイトごとの列の対応表に持ちます。

1点ごとに1ページの証書は、表ではなくキーと値で返ります。 Licensee:、License Type:、Date: のキーと値を取り、ページごとに1行にします。表とキーと値のどちらで来るかはサイトで決まるので、サイトごとに読み方を切り替えます。

結果は1回最大1,000ブロックで区切られます。NextToken が返る限り呼び直し、まとめ買いの証書の後半のページが抜けないようにします。

使用計画は案件管理の仕組みからCSVで出し、条件表とあわせて Python が読みます。生成AIには渡しません。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF であることを確かめます。メール本文だけの注文確認は、PDFにして入れます
2. パスワードの確認 … PDFはパスワードで保護されていてはいけないとされています
3. サイズとページ数の確認 … 非同期の処理で、PDFとTIFFは500MB・3,000ページまでです
4. 証書と請求書の組み合わせ … 注文番号で、同じ注文の証書と請求書を組にします
5. 重複の検知 … 同じ注文番号と素材IDの組がすでに台帳にあれば、再ダウンロードの証書として印を付けます
6. サイトの特定 … 送信元のドメインかファイル名から購入先を決め、列の対応表と読み方を選びます

4番目で組にならないものも、そのまま進めます。 証書だけ、請求書だけの行は、台帳で「片方が未着」と分かるようにしておき、月次の照合の前に担当者が足します。

5番目は、同じ素材を別の担当者が買い直していないかの手がかりにもなります。 注文番号が違って素材IDが同じなら、二重購入の可能性として一覧に出します。

AIに処理させる

させるのは、証書と請求書の読み取り結果を、素材ごとの台帳の行にそろえることです。 範囲に入るかの判断はさせません。

期間は、書かれているときだけ入れます。 多くの証書には期間の欄がありません。期間が書かれていないことを、無期限と書き換えさせません。 無期限かどうかは、条件表のライセンス種別の行が決めます。

エディトリアル専用の表示を拾うのは、範囲外の利用のいちばん大きな手がかりだからです。 iStock の使用許諾契約では、「エディトリアル専用」と表示されたコンテンツは、商業、販売促進、広告などの目的に使えないとされています。

2行目がいちばん起きやすい失敗です。 Standard License と書かれていると、一般的な知識から「印刷は○部まで」と条件を書き足そうとします。サイトごとに条件が違うので、書き足した瞬間に台帳が誤った条件を持ちます。

指示内容を固定する

あなたは広告会社の知財の担当で、海外のストック素材サイトのライセンス証書と
請求書を、素材台帳の行にそろえる担当です。
OCRの読み取り結果だけを使ってください。推測で埋めないでください。

【取り出す項目】
order：site、order_no、order_date_raw、order_date、licensee_raw、currency、total
assets：素材ごとに次を入れてください。
  asset_id、asset_type（photo / video / illustration / music / font / unknown）、
  description、license_type_raw、editorial_only（true / false / unknown）、
  term_raw、term_start、term_end、price、status、source（ページと表の行）

【厳守事項】
- asset_id は書かれた文字列をそのまま入れてください。桁や記号を補わないでください。
- license_type_raw は書かれた名前のまま入れてください。
  ライセンスの条件（印刷部数、媒体、期間など）を書き足さないでください。
- term_raw は期間が書かれているときだけ入れてください。
  書かれていなければ空にし、「無期限」と書かないでください。
- 日付は日と月の順序が文面から決まるときだけ YYYY-MM-DD にし、
  決まらなければ空にして status を ambiguous にしてください。
- 素材ごとの金額が書かれていなければ price を空にしてください。
  合計から割り振らないでください。
- editorial_only は "Editorial use only" などの表示があるときだけ true にしてください。
- その使い方が許されるかを書かないでください。
- 証書でも請求書でもない書類は、項目を取り出さず document_type に種類を書いてください。

【読み取り結果】{textract_tables_and_forms}
【このサイトの列の対応表】{column_alias}

「条件を書き足さない」を明記しないと、書き足します。 ライセンス種別の名前だけを見て、一般的な知識から部数の上限や使える媒体を description に足して返し、その値が台帳に残ると、誰も条件表を見に行かなくなります。

出力形式を固定する

Claude API の構造化出力（output_config.format に json_schema を指定）で、次の形のJSONを受け取ります。

{
  "file": "",
  "project_code": "",
  "document_type": "license_certificate",
  "order": { "site": "", "order_no": "", "order_date_raw": "", "licensee_raw": "", "currency": "USD", "total": 0 },
  "assets": [
    { "asset_id": "", "asset_type": "photo", "description": "",
      "license_type_raw": "Standard License", "editorial_only": "false",
      "term_raw": "", "term_end": "", "price": 0, "status": "ok", "source": "p1:T1:R3" }
  ]
}

1つ目の理由は、素材ごとの行がそのまま台帳の行になることです。 assets の1要素が台帳の1行で、注文番号と案件コードが付いて仮登録されます。

2つ目は、照合をプログラムの側に置けることです。 Python が毎月1日に、台帳の行と使用計画と条件表を突き合わせて印を付けます。

3つ目は、no_license を出せることです。 使用計画の側から素材IDを数えるので、証書が無いまま使われている素材、つまりカンプのまま残った素材が、台帳の外から見つかります。

システムへ連携する

素材台帳には「仮登録」として書き込み、確定は人が行います。 確定済みの行を自動で書き換えることはしません。案件管理の仕組みにも書き込みません。 掲載期間や部数を変えるのは制作進行の判断です。

人が確認する

知財の担当者が開くのは、印の付いた行と、仮登録のうち信頼度の低い行です。 印の無い仮登録の行は、一覧で流し見て確定します。

1. needs_human を先に片付ける … 条件表に無い種別は、そのサイトの契約を読んで条件表に1行足します
2. licensee_mismatch の理由を確かめる … クライアントの代わりに買ったものか、自社で使うものかを購入した担当者に聞きます
3. over_print、editorial_in_ad、expiring を制作進行と確かめる … 追加ライセンスの購入か、計画の変更か、素材の差し替えかを決めます
4. no_license を最優先で止める … 証書の無い素材が入った制作物は、購入か差し替えが済むまで公開に回しません

4番目は、他の印より先に扱ってください。 証書が無いということは、ライセンスを持っていない可能性があるということです。

例外に対処する

最後の行が、導入の初めの数か月でいちばん多く出ます。 使用計画に素材IDを入れる習慣が付くまでは、照合の対象そのものが欠けます。 件数を毎月数え、制作進行に返します。

記録を残す

• 元の証書と請求書、受け取った日時、案件コード、購入した担当者
• AWS Textract が返したJSONの全文
• Claude API が返したJSON（order と assets の全行）
• 月次の照合の結果と、そのとき使った条件表の版と使用計画の内容
• 担当者が仮登録を直した記録 … どの項目を、どう直したか
• 追加ライセンスの購入や素材の差し替えの決定と、その理由

条件表の版を残すのは、サイトの契約が改定されるためです。 購入した時点の条件で使っていたことを後から説明するには、当時の条件表と証書の両方が要ります。