広告会社に届く媒体資料のPDFを掲載枠ごとに索引し、予算・時期・入稿締切の条件で横断して検索し、提案に使える媒体と枠の候補を一覧にする

処理の起点を決める

取り込みと検索は、別々のきっかけで動かします。

取り込みは、取り込み用フォルダにPDFが保存されたことを起点にします。媒体資料は月に30冊前後届くので、届いた日に1冊ずつ処理します。月末にまとめると、その月のあいだは古い版の料金で検索されます。

承認は、取り出した表を媒体担当が承認したことを起点に索引へ入れます。承認されていない版は検索の対象に入れません。取り出しから承認までのあいだは、前の版が使われ続けます。

検索は、プランナーが検索画面で条件を送ったことを起点にします。営業からの依頼のチャットを直接読んで動かすことはしません。依頼の文面には条件が書かれていないことが多く、プランナーが聞き直して埋めてから検索するほうが、結果が使えます。

入力データを集める

質を決めるのは、資料の有効期間です。 媒体資料には「2026年4月〜9月掲載分」のように、料金表が使える期間が書かれていることが多くあります。これを持たないと、来月の掲載の依頼に、期限の切れた料金表の枠が出ます。 書かれていない資料は、届いた日から半年を仮に入れ、一覧に「有効期間の記載なし」と出します。

料金の種別も、必ず持たせます。 グロスとネットを混ぜたまま範囲で絞ると、同じ80万円でも実際の支払いが違う枠が並びます。 資料に書かれていなければ「不明」とし、範囲の絞り込みではグロスとして扱います。

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

PDFの読み取りは、Claude API にPDFをそのまま渡して行います。 公式のドキュメントでは、PDFの中の文字、図、表について質問でき、要件はリクエスト全体で最大32MB、1回あたり最大600ページ（コンテキストが100万トークン未満のときは100ページ）です。媒体資料は20〜40ページのものが多く、1冊を1回で渡せます。

取り出した結果は、構造化出力で受け取ります。 output_config.format に type: "json_schema" を指定すると、スキーマに合ったJSONが返ります。 枠の配列、料金の数値、種別の列挙をスキーマで決めておけば、索引に入れる前の検査を型で行えます。

締切は、資料の書き方のまま取り出し、日付への換算はプログラムで行います。 「掲載の10営業日前」「発売日の21日前」「毎月20日締め」は、書き方そのものを deadline_rule に写させ、換算は祝日の一覧を使って別の処理で行います。 生成AIに日付を計算させると、営業日の数え方がぶれます。

日付の範囲は range で絞ります。 公式のドキュメントでは、range は gte（以上）・gt（より大きい）・lte（以下）・lt（未満）を受け付け、日付の項目にも使えます。 日付は既定でUTCとして扱われ、time_zone を指定すると与えた日付がUTCに換算されます。日本時間で入れるなら time_zone に +09:00 を必ず付けます。 付け忘れると、月の境目で1日ずれます。

AIへ渡す前に整形する

1. パスワードの確認 … Claude API が受け付けるのは標準のPDFで、パスワードや暗号化の掛かったものは扱えません。 掛かっているものは媒体社に解除した版を頼みます
2. ページ数とサイズの確認 … リクエスト全体で32MB、1回600ページ（100万トークン未満のときは100ページ）を超えるものは章で分けます
3. 版の判定 … ファイル名と表紙の改訂日から、同じ媒体の既存の版と比べて新旧を決めます
4. 重複の検知 … 同じ媒体・同じ改訂日のPDFが二度届いたら、2つ目は取り込みません
5. 金額の正規化 … 「80万円」「800,000円」「¥800,000（税別）」を、税別の円の整数にそろえます。税込みとしか書かれていない資料は、その旨を印にします
6. 締切の換算 … deadline_rule と祝日の一覧から、掲載開始日ごとの締切の日付を出します
7. 説明文の整え … 読者の属性、媒体の特徴、枠の説明を1つの説明文にまとめ、Sudachi で語に分ける項目に入れます

5番目を軽く見ないでください。 税別と税込みが混ざったまま範囲で絞ると、予算80万円の依頼に、税込み88万円の枠が「80万円」として出ます。 正規化の結果は承認のときに媒体担当が確かめます。

6番目をプログラムでやるのは、締切が案件の成否を決めるからです。 1日の読み違いで入稿が間に合わず、枠を押さえたのに原稿が入らないことになります。

AIに処理させる

生成AIの出番は、取り込みのときと、一覧に注意書きを添えるときの2か所だけです。検索そのものは OpenSearch が行います。

検索は、三つの条件を1つの問い合わせにまとめます。

予算・時期・入稿は、同じ nested の中に入れます。 別々の nested に分けると、料金は枠Aで合い、締切は枠Bで合う資料が当たります。1つの nested に3つの条件を並べれば、3つとも同じ枠で満たすものだけが返ります。

ターゲットの言葉は、絞り込みではなく順位に使います。 「30代女性」と書かれていない媒体でも、「働く女性」「子育て中の母親」と書かれていれば候補になりえます。言葉が合わないものを外すと、プランナーが知らない媒体が出てきません。

指示内容を固定する

取り込みのときの指示です。

あなたは広告会社のメディア部門で、媒体資料から掲載枠の情報を
取り出す立場です。渡したPDFに書かれていることだけを使ってください。

【取り出すもの】
1. 媒体名、資料の改訂日、料金表の有効期間
2. 掲載枠ごとに：枠の名前、料金、料金の種別、税の扱い、
   サイズ・形式、掲載期間の単位、入稿締切の書き方、根拠のページ番号
3. 読者・利用者の属性の説明（資料の書き方のまま）

【厳守事項】
- 書かれていない値は null にしてください。推測で埋めないでください。
- 料金は資料に書かれた数字をそのまま price_text に写し、
  円の整数にできるものだけ price_yen に入れてください。
  税込み・税別の換算、グロス・ネットの換算はしないでください。
- 料金の種別が書かれていなければ price_basis を unknown にしてください。
- 入稿締切は、書き方のまま deadline_rule に写してください。
  日付に換算しないでください。
- 1つの枠に複数の料金（期間別・回数別）がある場合は、
  料金ごとに別の行にしてください。まとめないでください。
- 「要問い合わせ」「別途見積」と書かれた枠は、price_yen を null、
  note にその旨を書いてください。
- 根拠のページ番号は、その値が書かれたページを入れてください。
- 掲載基準（掲載できない業種など）が書かれていれば、
  restrictions に書き方のまま写してください。

一覧に注意書きを添えるときの指示です。

あなたは広告会社のプランナーに、媒体の候補一覧を渡す立場です。
渡した枠の情報だけを根拠にしてください。

【やること】
枠ごとに、プランナーが提案の前に確かめるべき点を1〜2文で書いてください。
確かめる点の例：締切が営業日か暦日か、料金がグロスかネットか、
税の扱い、掲載基準に依頼の業種が当たらないか、有効期間の記載がないこと。

【厳守事項】
- 渡した情報に無いことを書かないでください。
- 枠に順位を付けないでください。どれを提案すべきかも書かないでください。
- 料金や締切の数字を書き換えないでください。
- 掲載基準に当たりそうな場合は「掲載基準の確認が必要」とだけ書き、
  掲載できるかどうかを判断しないでください。

「料金ごとに別の行にする」を明記しないと、期間別の料金が1行にまとまります。 「1週間30万円／4週間100万円」を1行にされると、範囲で絞ったときにどちらの値で判定したのかが分からなくなります。

「換算しない」を料金と締切の両方に書いているのは、どちらも換算すると誤りが見えなくなるからです。 資料の書き方のまま残しておけば、承認のときに元のページと見比べるだけで済みます。

出力形式を固定する

取り込みのときは、次の形のJSONで受け取ります。

{
  "media_name": "",
  "revised_on": "2026-09-01",
  "valid_from": "2026-10-01",
  "valid_to": "2027-03-31",
  "audience_text": "",
  "slots": [
    {
      "slot_name": "",
      "price_text": "",
      "price_yen": null,
      "price_basis": "gross | net | unknown",
      "tax": "excluded | included | unknown",
      "size_format": "",
      "period_unit": "",
      "deadline_rule": "",
      "restrictions": "",
      "page": 0,
      "note": ""
    }
  ]
}

1つ目の理由は、索引の形と同じにできることです。 slots がそのまま nested の項目になり、price_yen と換算後の締切が range の対象になります。取り出した結果と索引の形がずれないので、変換の処理で誤りが入りません。

2つ目は、price_text と price_yen を分けていることです。 承認する人は price_text を元のページと見比べ、検索は price_yen を使います。「要問い合わせ」の枠は price_yen が null になり、予算の絞り込みには出ませんが、一覧の下に「料金要問い合わせ」としてまとめて出します。

検索の結果は、次の表で返します。

根拠の列から、資料の該当ページを直接開けるようにします。 プランナーは表を信じるのではなく、提案に使う枠だけ元のページで確かめます。

システムへ連携する

媒体社へは何も送りません。 枠の空き状況や最新の料金は、この構成では分かりません。候補が決まったら、営業が媒体社に空きと料金を確かめます。 一覧の上に「空き状況は未確認」と常に出します。

提案書のひな形にも書き込みません。 一覧から使う枠を選ぶのはプランナーで、選んだ理由を提案書に書くのも人の仕事です。

人が確認する

1. 取り込みの承認（媒体担当） … 取り出した表と元のページを並べ、料金・税・種別・締切の書き方を見比べます。1冊あたり5分ほどで、検索のたびには見ません
2. 候補の確認（プランナー） … 一覧の根拠の列から、提案に使う枠のページだけを開いて確かめます
3. 空きと最新の料金の確認（営業） … 媒体社に問い合わせます
4. 誤りを見つけたら記録する … 料金や締切の取り出しの誤りは、承認の画面から版ごとに直します

1番目を省かないでください。 取り込みの誤りは、直すまで全員の検索に出続けます。 1冊を5分で見ておけば、その後の何十回の検索が正しくなります。

承認の画面では、見る順番を決めておきます。 料金の桁、税の扱い、料金の種別、締切の書き方の4つを先に見て、サイズや形式は後に回します。前の4つは検索の絞り込みに使う値で、誤ると候補が消えるか、誤った候補が出ます。 後の2つは誤っても一覧で気づけます。

プランナーの確認の目安は、1件あたり8分です。 一覧に出た候補のうち、提案に使う3〜4枠の根拠のページを開いて、料金と締切を目で確かめます。一覧の全部を開く必要はありません。 開いた枠と開かなかった枠は記録に残し、誤りが見つかったときにどの範囲を見直すかの手がかりにします。

例外に対処する

4行目と5行目は、外さずに出すことが大事です。 分からない枠を絞り込みで消すと、プランナーはその媒体があることすら知らないまま初案を作ります。

記録を残す

• 媒体資料のPDFの原本と、届いた日・取り込んだ担当者
• 取り出したJSONの全文と、承認した人・日時・直した箇所
• 版の履歴（どの版がいつからいつまで検索の対象だったか）
• 検索の条件、返した枠の一覧、プランナーが開いた根拠のページ
• 提案に使われた枠（プランナーが一覧から選んだもの）

版の履歴を残すのは、後から料金を確かめるためです。 発注のときに「初案の料金と違う」と言われたら、その日にどの版の料金が出ていたかを引けます。

最後の行は、索引の改善に使います。 何度検索されても選ばれない媒体は、説明文が依頼の言葉と合っていないかもしれません。