英文の広告掲載申込書（IO）を読み取り、掲載期間・枠・単価・キャンセル条件を受注台帳に転記して、媒体の規定と合わない条件を拾う

処理の起点を決める

受付フォルダ（Amazon S3）にPDFが保存されたことを起点にします。 IOは広告会社の出稿の決定に合わせて不定期に届き、掲載開始の直前に届くこともあるため、1日1回の定時実行にはしません。 IAB の標準条件では、媒体社は署名済みのIOを受け取ってから2営業日以内に、在庫が無いことを知らせるよう商業上合理的な努力をするとされています。この期限に間に合わせるには、届いた日に読む必要があります。

保存するのは営業で、ファイル名の先頭に案件番号を付けます。 メールから自動で保存しないのは、署名前の案や見積の往復が混ざり、どれが署名済みの版か機械では決められないからです。

S3 への保存を AWS Lambda が受け、StartDocumentAnalysis を呼びます。ClientRequestToken に案件番号とファイルのハッシュから作った値を入れ、同じファイルを二度読まないようにします。 完了は Amazon SNS に届き、SUCCEEDED を確かめてから結果を取り、すぐ S3 に保存します（JobId は7日間だけ有効です）。

入力データを集める

質を決めるのは、掲載規定の表と広告枠の対応表です。 規定が文章のままだと照合できず、対応表が無いと「Top Banner」「Header 728x90」が同じ枠だと分かりません。

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

読み取りは StartDocumentAnalysis に FeatureTypes として TABLES、FORMS、QUERIES、LAYOUT を指定して行います。全文の行と単語は、指定した機能にかかわらず返ります。

明細は、セルの行と列の番号で組み立て直します。 公式の説明では、セルは CELL として行の番号・列の番号・信頼度を持ち、列見出しのセルには COLUMN_HEADER が付きます。列見出しの文字から、どの列が単価でどの列が配信量かを決め、決められない列があれば needs_human にします。 表の合計行は TABLE_SUMMARY として返ることがあるので、明細の行と分けて扱い、明細の合計と照合します。

質問は、手引きに沿って文書の言葉で聞きます。

ページの指定が無いと質問は1ページ目しか見ないので、Pages に ["*"] を入れます。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF であることを確かめます。XFA形式のPDFは扱えないため、印刷し直してPDFにします
2. パスワードの確認 … PDFはパスワードで保護されていてはいけません。電子署名のサービスから届いたPDFに保護が掛かっていれば、解除したものを頼みます
3. ページ数とサイズの確認 … 非同期の処理でPDFは500MB・3,000ページが上限です。広告の原稿や企画書が同じPDFに綴じられていれば、IOの部分だけに分けます
4. 言語の確認 … 英語以外の文が含まれていれば質問を外し、表とキーと値と全文で読みます
5. 版の確認 … 同じ案件番号・同じIO番号の前の版があるかを調べ、あれば改定版として扱います
6. 添付ページの切り分け … 電子署名のサービスが付ける署名の記録のページは、明細や条件と混ざらないよう、ページの範囲を分けて記録します

6番目を軽く見ないでください。 署名の記録のページにも日付と名前が並ぶため、そのまま渡すと、署名日を掲載の開始日と取り違えることがあります。

AIに処理させる

させるのは、明細を1行ずつ、条件を1条件1行に、原文のまま取り出し、条件に種類の札を付けることだけです。

請求の参照を受注のときに取るのには理由があります。 IAB の標準条件では、請求書にはIO番号、広告主名、キャンペーン名と、IOで請求に必要とされた番号を載せるとされ、すべての配信が終わってから90日以内に請求書を送るとされています。請求の担当が掲載の終わった後にIOを読み直さなくて済むよう、受注台帳の段階で参照番号を持たせます。

条件に札を付けるのが、照合を機械にできる理由です。 「cancellation」「payment」「measurement」のような種類を付ければ、プログラムは規定の表の同じ種類の行と比べられます。原文は必ず添えます。 比べた結果を人が確かめるとき、原文が無ければIOを開き直すことになります。

2行目がいちばん起きやすい失敗です。 「Subject to the 4A's/IAB Standard Terms and Conditions Version 3.0」とだけ書かれたIOを渡すと、AIは標準条件の一般的な内容からキャンセルの日数を書き足します。IOの側に独自の特約があれば、その日数は誤りになります。 名前と版だけを写させ、標準条件の中身は、自社で読んで規定の表と比べた結果を別に持ちます。

指示内容を固定する

あなたは媒体社の広告営業の担当として、英文の広告掲載申込書（IO）を読み、
受注台帳への登録と規定の照合に使う項目を取り出します。
OCRが返した読み取り結果だけを見てください。推測で埋めないでください。

【取り出す項目】
1. 明細（1行ずつ）：枠の名前、開始日、終了日、配信量、課金の方式、単価、金額、ネット／グロス
2. 組み込まれた取引条件の名前と版、特約の有無
3. 条件（1条件1行）：種類を cancellation / payment / measurement /
   creative / makegood / other から1つ選ぶ

【status の選び方】
- ok ......... 値が読み取れており、その項目として解釈できる
- not_found .. その項目が書かれていない
- unreadable . 文字は検出されているが信頼度が低く、値として確定できない
- ambiguous .. 候補が複数あり、1つに決められない
迷ったときに ok を選ばないでください。

【厳守事項】
- original には、IOの英文をそのまま写してください。言い換えないでください。
- 日本語の説明は note_ja にだけ書いてください。
- 明細の数字は表のセルの値を写してください。単価×配信量などの計算をしないでください。
- 枠の名前はIOの書き方のまま写してください。自社の枠の名前に直さないでください。
- 標準の取引条件は、書かれている名前と版だけを写してください。
  その条件の中身（キャンセルの日数など）を一般論で補わないでください。
- 書かれていない条件を補わないでください。
- 自社の規定に合うか、受けるべきかは書かないでください。
- 英語以外の文が含まれていれば、language_note にその旨を書いてください。

【読み取り結果】{textract_result}
【見出しごとに区切った原文】{sections}
【組み立て直した明細の表】{tables}

「標準条件の中身を補わない」は、書かないと必ず破られます。 AIは標準条件の内容をよく知っているように振る舞い、IOに書かれていない日数を条件の一覧に並べます。一覧に並んだ時点で、それがIOの条件なのか一般論なのか、人には区別できません。

出力形式を固定する

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

{
  "io_number": "",
  "line_items": [
    { "placement_text": "", "start_date": "", "end_date": "", "quantity": "",
      "pricing_model": "CPM | CPC | flat | other", "rate": "", "amount": "",
      "net_or_gross": "net | gross | not_stated", "status": "ok | unreadable | ambiguous" }
  ],
  "incorporated_terms": { "name_text": "", "version_text": "", "status": "ok | not_found" },
  "conditions": [
    { "condition_type": "cancellation | payment | measurement | creative | makegood | other",
      "original": "", "note_ja": "" }
  ],
  "language_note": ""
}

1つ目の理由は、照合の結果を別の層に置けることです。 JSONはAIが埋め、照合はプログラムが別の表に書きます。

2つ目は、検算をプログラムが行えることです。 単価と配信量から金額を出し、IOの金額と1行ずつ比べます。合わない行に印を付けるだけで、どちらが正しいかは人が決めます。

3つ目は、not_covered が規定の表を育てることです。 規定に行が無い条件が何度も出れば、規定の表に行を足す材料になります。

システムへ連携する

受注台帳と配信の予約には、人が確定するまで書き込みません。 予約を先に入れると、条件を読む前に配信が始まりうるからです。

外部の配信計測の有無は、配信の予約の設定に渡します。 IAB の標準条件では、広告会社が外部の配信計測を使う場合、媒体社は事前の書面の同意なしにIOの配信量の10％を超えて上乗せ配信しないとされています。IOで外部計測が指定されていれば、予約の画面で配信の上限を設けるよう、登録案に印を付けます。

人が確認する

人が確かめるのは、印の付いた明細と、規定と合わない条件です。 conform の行は一覧で流し見ます。一覧は、IOを受け取った日から数えた在庫の連絡の期限が近い順に並べます。 2営業日の数え方は自社の営業日の暦でプログラムが行います。

1. needs_human を先に見る … 読めなかったセルと、列の意味が決められなかった明細です
2. deviate と not_covered を原文と見比べる … 種類の札が正しいか、キャンセルと差し替えの条件を取り違えていないかを見ます
3. 扱いを決める … 営業の責任者が、受け入れるか、広告会社に修正を頼むかを決めます。返信の下書きは直してから送ります
4. 確定して登録する … 確定した明細だけを台帳に登録し、配信を予約します

目標は、120件をならして1件6分です。 前の版から配信量だけが変わった改定版は数分、条件の欄に特約が並ぶ新規のIOは10分を超えます。

例外に対処する

上から3行目までが大半を占めます。 どれも書式の問題で、よく取引する広告会社から順に、列見出しの対応を規則に足していきます。

記録を残す

• 元のIOのPDFと、保存した日時・版
• AWS Textract の結果のJSON全文と JobId
• Claude API の出力（line_items、incorporated_terms、conditions）
• 照合に使った料金表と規定の表の版と、照合の結果
• 規定と合わない条件の扱い（受け入れた／修正を頼んだ）と、決めた人
• 人が値を直した記録と、確定した版

4つ目と5つ目を残すのは、キャンセルや請求でもめたときの根拠にするためです。 どの規定の版で比べ、誰が何を受け入れたかが分かれば、広告会社との話が早く済みます。