広告代理店で、過去に媒体の広告審査で否認された表現と理由の記録から入稿前の原稿に近い事例を探し、直し方の案を根拠付きで返す

処理の起点を決める

運用の担当が、確認の画面に原稿と区分を入れて「否認事例を探す」を押したときに動かします。 クライアントから原稿を受け取った直後、相談の前に使う想定です。入稿の直前では、直す時間がありません。

もう1つの起点は、審査の結果の記録です。 担当が媒体の管理画面で承認・否認を確かめ、確認の画面で結果を記録したときに、否認事例の索引に1件を足すか、既存の事例に「承認された修正文」を足します。

否認の記録は、否認の通知を受けたその日に残します。 1週間たつと、どの表現が否認されたのかを、担当自身も思い出せなくなります。

入力データを集める

質を決めるのは、3行目の「承認された修正文」です。 否認された表現だけが並んでも、直し方は担当が考えることになります。修正文があって初めて、直し方の案を事例に沿って出せます。

「否認の通知の理由の原文」と「自社での理由の区分」を分けて持ちます。 媒体の通知の文言は媒体ごとに違い、そのままでは集計も検索もしにくいからです。区分は、効果の表現・比較・価格・体験談・ビフォーアフター・個人の属性への言及のように、運用部で決めます。 原文は、担当が読むために残します。

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

検索パイプラインと検索の形は、次のようになります。

PUT /_search/pipeline/rejection-rrf
{
  "phase_results_processors": [
    { "score-ranker-processor": { "combination": { "technique": "rrf" } } }
  ]
}

POST /ad-rejections/_search?search_pipeline=rejection-rrf
{
  "size": 5,
  "_source": ["case_id", "media", "ad_format", "category", "rejected_text",
              "reason_class", "reason_original", "approved_text", "decided_on"],
  "query": {
    "hybrid": {
      "queries": [
        { "match": { "rejected_text": "どこよりも安い 定期便" } },
        { "knn": { "rejected_vector": { "vector": [0.0], "k": 20 } } }
      ],
      "filter": {
        "bool": {
          "filter": [
            { "term": { "media": "search_ads_a" } },
            { "term": { "category": "health_food" } },
            { "range": { "decided_on": { "gte": "now-24M/d" } } }
          ]
        }
      }
    }
  }
}

RRF の順位の定数は既定で60です。 大きくすると上位の重みが均され、小さくすると上位の差が大きくなります。最初は既定のままで始め、担当が「役に立った」と付けた事例の順位で見直します。 検索ごとの重みも指定できますが、まず重みなしで比べます。

期間で絞るのは、媒体の基準が変わるからです。 2年より前の否認事例は、いまの基準で同じ扱いになるとは限りません。古い事例は既定では出さず、担当が範囲を広げたときだけ、日付を目立たせて出します。

AIへ渡す前に整形する

1. 文の単位への分割 … 見出し・説明文は句点と改行で、画像の中の文言は文言ごとに分けます。1つの文に複数の訴求があるときも、まずは文のまま扱います
2. 否認事例の作り直し … 担当者ごとのスプレッドシートを集め、1件ごとに媒体・商材の区分・否認された表現・理由の区分・承認された修正文をそろえます
3. 否認された表現の切り出し … 否認の通知が原稿全体を指していても、どの文が理由に当たるかを担当が特定して入れます。 特定できないものは原稿全体を1件にし、印を付けます
4. 言い換えの一覧 … 「最安, 業界最安, どこよりも安い, 一番安い」のような組を、運用部で決めて synonym_graph に入れます
5. 区分のそろえ … 媒体と商材の区分を、決まった値の一覧から選ぶ形にします
6. 広告主の情報の扱い … 広告主の名前は広告主のコードにし、見られる範囲を分けます（第13章）

3番目が、検索の質を決めます。 原稿全体を1件にすると、「この原稿のどこかが否認された」という事例になり、どの言い回しが問題だったかが分かりません。 担当の手間がかかりますが、否認の記録を残すときに「どの文か」を選ぶ欄を設けるだけで、以後は自然にそろいます。

否認事例の索引の設定は、次のようにします。言い換えは検索のときの解析にだけ入れ、索引のときの解析には入れません。 索引に入れた語そのものは言い換えに左右されない形にしておき、一覧を直したときの反映の手順は、使う版の公式の手順で確かめます。

PUT /ad-rejections
{
  "settings": {
    "index.knn": true,
    "analysis": {
      "tokenizer": { "ja": { "type": "kuromoji_tokenizer", "mode": "search" } },
      "filter": {
        "ad_synonyms": {
          "type": "synonym_graph",
          "synonyms": [
            "最安, 業界最安, どこよりも安い, 一番安い",
            "No.1, ナンバーワン, 第1位, 一番人気",
            "必ず痩せる, 確実に痩せる, 絶対痩せる"
          ]
        }
      },
      "analyzer": {
        "ja_index": { "type": "custom", "tokenizer": "ja" },
        "ja_search": { "type": "custom", "tokenizer": "ja", "filter": ["ad_synonyms"] }
      }
    }
  },
  "mappings": {
    "properties": {
      "case_id": { "type": "keyword" },
      "media": { "type": "keyword" },
      "ad_format": { "type": "keyword" },
      "category": { "type": "keyword" },
      "advertiser_code": { "type": "keyword" },
      "rejected_text": { "type": "text", "analyzer": "ja_index", "search_analyzer": "ja_search" },
      "context_text": { "type": "text", "analyzer": "ja_index" },
      "reason_class": { "type": "keyword" },
      "reason_original": { "type": "text", "analyzer": "ja_index" },
      "approved_text": { "type": "text", "analyzer": "ja_index" },
      "decided_on": { "type": "date" },
      "rejected_vector": { "type": "knn_vector", "dimension": 1024 }
    }
  }
}

該当の語句は、ハイブリッドクエリとは別の通常の検索で取ります。 上位の事例の case_id で絞った match に highlight を付けると、否認された表現のうち、原稿の語と一致した箇所に印が付いて返ります。highlight は、検索に言い換えを使っていても元の語を強調するので、担当は事例のどの言い回しが当たったかを一目で確かめられます。

言い換えの一覧は、広げすぎないでください。 「安い」と「お得」まで同じにすると、否認とは関係の薄い事例が上位に来ます。否認の理由になった言い回しの組から始めます。

AIに処理させる

させるのは、文ごとに近い事例の要点をまとめ、承認された修正文を手がかりに直し方の案を並べることです。

3行目は迷うところです。 承認された修正文が無い事例について、AIに直し方を考えさせることはできます。しかし、それは「過去に通った直し方」ではなく、根拠の無い言い換えです。 この構成では出さず、事例だけを示して担当に考えてもらいます。

指示内容を固定する

あなたは広告代理店の運用部で、入稿前の原稿を確かめる担当のために、
過去の媒体の審査の否認事例を整理する立場です。
審査に通るかどうかを予想しないでください。

【やること】
1. 原稿の文ごとに、渡された否認事例のうち近いものを選んでください。
2. 近い事例があれば、否認された表現、理由の区分、媒体、日付を短く書いてください。
3. その事例に承認された修正文があれば、それに沿った直し方の案を1〜2つ書いてください。
4. 案ごとに、手がかりにした事例番号（case_id）を必ず書いてください。

【厳守事項】
- 渡された否認事例に無い事例番号を書かないでください。
- 承認された修正文が無い事例について、直し方を考えて書かないでください。
  「承認された修正文の記録なし」と書いてください。
- 「通ります」「否認されません」のような審査の結果の予想を書かないでください。
- 法令に適合するかどうかを書かないでください。
- 近い事例が無い文は「近い否認事例なし」とし、無理に事例を当てないでください。
- 事例の日付が1年より前の場合は、そのことを書いてください。

【媒体・広告の形式・商材の区分】{context}
【原稿（文ごと）】{sentences}
【検索結果（文ごとの否認事例）】{cases}

「近い事例が無い文は無理に当てない」を書かないと、すべての文に何かの事例を当てます。 検索は何かしらの結果を返すので、渡された事例を使いたくなります。近さの判断を緩めると、問題の無い文まで直すことになり、訴求が弱くなります。

「審査の結果を予想しない」も同じくらい大事です。 「この修正で通ります」と書かれると、担当はその言葉を信じてクライアントに伝えます。言えるのは、過去にこの直し方で通ったという事実までです。

出力形式を固定する

Claude API の構造化出力で、次の形のJSONを受け取ります。

{
  "sentences": [
    {
      "index": 1,
      "text": "",
      "matched_cases": [
        { "case_id": "RJ-2026-0412", "media": "", "reason_class": "", "decided_on": "", "note": "" }
      ],
      "suggestions": [
        { "text": "", "based_on": ["RJ-2026-0412"] }
      ],
      "status": "matched | no_match | matched_without_fix"
    }
  ]
}

1つ目の理由は、based_on と matched_cases の事例番号を照らせることです。 検索結果に含まれない番号があれば、その案は表示しません。

2つ目は、status で文ごとの扱いが分かれることです。 matched は直し方の案があるもの、matched_without_fix は事例はあるが承認された修正文が無いもの、no_match は近い事例が無いものです。担当は matched と matched_without_fix だけを見ればよく、確認の時間が絞れます。

3つ目は、matched_without_fix の件数が、記録の改善点になることです。 修正文の無い事例が多い区分は、承認の結果を残す運用が回っていない区分です。

応答が refusal や max_tokens で終わったときは、スキーマに合わないことがあるので、受け付けずにやり直します。

システムへ連携する

人が確認する

1. matched の文の事例を開く … 事例の原稿の前後の文と、否認の通知の理由の原文を読みます
2. 媒体の基準の更新を確かめる … 事例が古い場合や、媒体が基準を改定したと知らされている場合は、媒体の公開している基準を担当が読みます
3. 直し方を決める … 案をそのまま使うか、訴求に合わせて直すかを決めます
4. クライアントの担当と相談する … 直す理由を、事例を根拠に説明します
5. 審査の結果を記録する … 承認・否認と、承認された文を残します

2番目を省かないでください。 否認事例は過去の事実で、媒体の基準が変わると、通った直し方も通らなくなることがあります。 事例の日付は必ず見てください。

目標は、600件をならして1件5分です。 近い事例の無い原稿は数十秒で終わり、matched の文が多い原稿は10分前後かかります。

例外に対処する

1行目の表示の文言は大事です。 「近い否認事例なし」を「問題なし」と読むと、記録の無い否認をそのまま入稿します。 事例が無いのは、記録が無いだけかもしれません。

記録を残す

• 原稿と区分、確認した日時と担当
• 文ごとの検索の条件と、上位の事例番号と順位
• Claude API の出力と、指示の版
• 担当が「役に立った」と付けた事例
• 審査の結果（承認・否認、否認の通知の理由の原文、承認された文）

4つ目は、検索の調整の材料になります。 役に立った事例が何位に出ていたかを見れば、RRF の定数や言い換えの一覧を直す根拠になります。