広告の掲載の誤り・表記の誤り・配信の設定ミスが起きたときに、過去の事故報告から似た事故を探し、広告主への対応と効いた対策を根拠付きで返す

処理の起点を決める

取り込みと検索で、起点が2つあります。

取り込みは、品質管理室が事故報告を確定したときです。 確定済みのフォルダにファイルが置かれたことを検知して動かします。第一報の段階の下書きは取り込みません。 原因の推測や話す前の補償の案が、前例として返るのを防ぎます。

効果の確認の記録は、登録されるたびに付け足します。 再発防止策を始めてから3か月ほどたったところで、品質管理室が「再発なし」「再発あり」「運用をやめた」を記入します。その記入を起点に、該当する事故の対策の節を更新します。 事故報告そのものは取り込み直しません。

検索は、営業が新しい事故を調べ始めたときに動きます。 第一報は「バナーが違う」程度の書き方が多く、似た事故の精度が出ません。 応急の対応を頼んだあと、営業が状況を3〜4行で書き直してから検索します。

入力データを集める

質を決めるのは、事故報告の「広告主への対応」が節として書かれているかです。 何を、いつ、誰から伝え、何を補償し（再掲載、配信の延長、請求の減額、無償の追加の出稿）、広告主がどう受け止めたか。この節が無い報告書は、検索で当たっても営業が知りたいことが返りません。

広告主の社名は索引に持たせず、業種だけを持たせます。 別の広告主の事故が社名付きで画面に出ることを避けます。

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

取り込みは Word の事故報告から文字を取り出し、見出しで節に分けます。 年によって違う見出し（「顧客対応」「お詫びと補償」）は対応表で同じ節に寄せます。

索引の項目は、次のように持たせます。 1件の文書は「事故1件の1つの節」です。

意味のベクトルは、Amazon Titan Text Embeddings V2 で作ります。 公式のドキュメントでは、入力は最大8,192トークンまたは50,000文字、出力は1,024（既定）、512、256次元から選べ、日本語を含む多言語に対応するとされています。検索では文書を節のような単位に分けることが推奨されているので、節ごとに作ります。

AIへ渡す前に整形する

1. 節に分ける … 状況・原因・広告主への対応・対策の見出しで分けます。年ごとに違う見出しは対応表で寄せます
2. 社名と人名を外す … 広告主の社名、広告主の担当者名、媒体社の担当者名を「広告主」「先方の担当」のような記号に置き換えます
3. 呼び方の揺れを記録する … 「配信地域／ジオ／エリア指定」「掲載面／配信先／プレースメント」のような呼び方を一覧にし、言葉の検索の同義語にします
4. 金額を区分にする … 補償の金額は、そのままではなく「請求の1割未満」「1割以上」のような区分に置き換えます
5. 対策の番号を確かめる … 対策が「①校了後の差し替えは2名で確認」のように番号付きかを確かめ、無いものは品質管理室に戻します
6. ベクトルを作る … 状況の節と原因の節だけについて、Titan Text Embeddings V2 でベクトルを作ります

4番目を軽く見ないでください。 金額がそのまま出ると、出稿の規模が違うのに金額を前例として写します。 見るべきは補償の種類と重さです。

6番目で対応と対策の節にベクトルを持たせないのは、 対応の文がどの事故でも似た言い回しになり、起き方の違う事故が言い回しの近さだけで上がってくるためです。

AIに処理させる

AIの仕事は、検索で出た似た事故を、決まった項目で引用付きで並べることだけです。 似た事故を探すのも、事故ごとにまとめるのも、対応の節を添えるのも検索基盤で行います。

1行目と2行目が、いちばん外せない線です。 前例を並べたAIに案を書かせると、いちばん重い補償の前例に寄せがちで、伝われば取り消せない約束になります。

「違う点」を必ず書かせるのも同じ理由です。 予約型の紙面の事故と運用型のSNSの事故では、止めるまでの時間も、媒体社の関わり方も違います。似ている点だけを読むと、条件の違う前例の補償をそのまま持ち出します。

指示内容を固定する

あなたは広告会社の品質管理室で、新しい掲載事故の検討のために過去の似た事故を整理する係です。
渡された検索結果だけを根拠にしてください。一般的な広告の知識で補わないでください。

【新しい事故】
媒体の区分：{buy_type}　広告の形式：{ad_format}　事故の種類：{incident_type}
状況：{situation}
分かっている範囲の原因：{known_cause}

【検索結果】
事故番号ごとに、状況（situation）、原因（cause）、広告主への対応（response）、
対策（measure）の節と、対策ごとの効果の確認結果が渡されます。

【事故ごとに書くこと】
1. 事故番号、発生日、媒体の区分、広告の形式、事故の種類、広告主の業種
2. 当時の状況と原因（報告書の文を引用）
3. 当時の広告主への対応（伝えた内容、補償の種類、広告主の受け止め。報告書の文を引用）
4. 新しい事故と似ている点
5. 新しい事故と違う点（媒体の区分、形式、影響した期間、止めるまでの時間）
6. 対策ごとの効果の確認結果を記録のまま
   （再発なし／再発あり／運用をやめた。記録が無ければ「効果未確認」）

【厳守事項】
- 補償の内容や金額を提案しないでください。「今回も〜すべき」と書かないでください。
- 責任が誰にあるかを書かないでください。報告書に書かれていても、
  「報告書には〜と記載」と引用の形で書いてください。
- 広告主への対応の節が無い事故は、「対応の記載なし」と書いてください。
  他の事故の対応で補わないでください。
- 効果の確認結果が無い対策を「有効」と書かないでください。「効果未確認」と書いてください。
- 違う点が見つからないときも「違う点：記載から判断できない」と書き、空欄にしないでください。
- 似ていないと判断した事故は、「似ている点が少ない」と書いて最後に回してください。

「引用の形で書く」を入れるのは、 当時の報告書の「媒体社側の設定ミス」という判断を、AIが地の文で書くと今回にも当てはまる事実のように読めるためです。

検索結果は、Claude の検索結果ブロックで渡します。 1つの節を1つの search_result にし、source に「事故番号/節」、title に発生日と事故の種類、content に節の本文を入れます。公式の説明では、検索結果ブロックは Claude API、Amazon Bedrock、Google Cloud で使え、引用は content の中のテキストブロック単位です。対応の節は「伝えた内容」「補償」「受け止め」の3ブロックに分けて渡します。

出力形式を固定する

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

PUT /_search/pipeline/incident-rrf
{
  "description": "掲載事故の言葉と意味の検索を順位で混ぜる",
  "phase_results_processors": [
    { "score-ranker-processor": {
        "combination": {
          "technique": "rrf",
          "rank_constant": 60,
          "parameters": { "weights": [0.5, 0.5] }
        }
    } }
  ]
}

検索の要求は、次のように組みます。

GET /ad-incidents/_search?search_pipeline=incident-rrf
{
  "size": 8,
  "query": {
    "hybrid": {
      "filter": { "bool": { "filter": [
        { "term": { "finalized": true } },
        { "terms": { "section": ["situation", "cause"] } },
        { "range": { "occurred_on": { "gte": "now-5y/d" } } }
      ] } },
      "queries": [
        { "match": { "text": "配信地域 設定 漏れ 全国 配信 期間" } },
        { "knn": { "text_vector": { "vector": [0.021, -0.008], "k": 40 } } }
      ]
    }
  },
  "collapse": { "field": "incident_id" }
}

上位の事故番号が決まったら、2回目の検索で対応と対策の節を取ります。

GET /ad-incidents/_search
{
  "size": 40,
  "query": { "bool": { "filter": [
    { "terms": { "incident_id": ["AI-2024-0213", "AI-2023-1107"] } },
    { "terms": { "section": ["response", "measure"] } }
  ] } }
}

filter で状況と原因の節だけを当てているのが要点です。 似ている理由は起き方で決め、対応と対策の節は2回目の検索で事故番号から引きます。1回目の検索に対応の節を混ぜると、「お詫びに伺った」のような似た言い回しで起き方の違う事故が上がります。 2回の検索は Lambda から続けて投げ、画面には1つの結果として返します。vector の中身は、Lambda が Titan で作った1,024個の数値です。

最初の重みは0.5ずつにし、 第8章の試しで古参の営業が選んだ事故がどちらの検索で上に来るかを数えてから動かします。

画面に返す形は、次のJSONです。

{
  "query_incident": { "buy_type": "運用型", "ad_format": "SNS", "incident_type": "配信の設定ミス" },
  "similar": [
    { "incident_id": "AI-2024-0213", "occurred_on": "2024-02-13",
      "buy_type": "運用型", "ad_format": "ディスプレイ", "client_industry": "不動産",
      "situation": "", "cause": "",
      "response": { "told": "", "compensation_type": "配信の延長", "client_reaction": "" },
      "same_points": "", "different_points": "",
      "measures": [
        { "no": 1, "text": "", "result": "再発なし", "checked_on": "2024-05-20" },
        { "no": 2, "text": "", "result": "効果未確認", "checked_on": null }
      ],
      "citations": ["AI-2024-0213/response"] }
  ],
  "not_found": false
}

1つ目の理由は、response を3つに分けると、補償の種類だけを横に並べて前例の幅を見られることです。 金額は入れません。

2つ目は、measures の result を固定の値で返させることで、画面で色分けできることです。 効いた記録のある対策が先に目に入ります。

システムへ連携する

広告主へのメールや報告の書式には、何も書き込みません。 営業は結果を読み、自分で文面を書きます。画面から広告主へ直接送る経路は作りません。

人が確認する

この構成の確認は、必須です。 出てくるのは前例の材料で、広告主への説明と補償は人が決めます。

1. 並んだ事故が本当に似ているかを見る … 似ている点と違う点を読み、前例に使う事故を選びます。点数の順に上から使うことはしません
2. 原本とメールを開いて確かめる … 前例に使う事故は、事故報告の原本と当時のメールを開き、引用された対応が実際にそうだったかを確かめます
3. 補償の種類を上長と決める … 前例の補償は「同じ種類の事故で、ここまで出したことがある」という幅として使います
4. 使わなかった事故を記録する … 上位に出たのに使わなかった事故と、その理由（媒体の区分が違う、影響の期間が違う）を一言残します

1件あたり15分を目安にします。 原本とメールを開くのは選んだ1〜2件です。

例外に対処する

3行目は公式のドキュメントに書かれた動きで、 index.neural_search.hybrid_collapse_distinct_groups_enabled を有効にすると、size 件までの異なるまとまりを返せます。

記録を残す

• 取り込んだ事故報告の事故番号・節・確定日と、取り込んだ日時
• 効果の確認の記録から付け足した結果と、付け足した日時
• 検索の入力と、返した事故番号と順位
• Claude に渡した検索結果と、返ってきた答えと引用
• 営業が前例に使った事故と、使わなかった事故とその理由
• 「前例は見つかりませんでした」になった検索

5つ目と6つ目は、重みと同義語を直す材料です。 3か月分たまったところで、使われた事故がどちらの検索で上位に来ていたかを数えます。