ラジオ局から届く放送されたCMの録音を文字にして発注した原稿と照らし、読み違い・抜け・社名や価格の誤りを拾って広告主への放送報告にそろえる

処理の起点を決める

局ごとの受付フォルダに、放送確認書か録音のファイルが保存されたことを起点にします。 放送確認書と録音は別々に届くことがあるので、両方がそろった放送から順に処理します。 片方しか無い放送は、待ちの一覧に置きます。

放送の翌営業日には結果が出るようにします。 生CMの読み違いは、次の放送の前に局へ伝えられれば、同じ誤りが次の回で繰り返されるのを止められます。 月末にまとめて確かめる運用では、それができません。

3営業日たっても録音が届かない放送は、待ちの一覧から局への催促の候補に移します。 放送確認書だけで報告すると、第3章の（c）の確認ができないからです。

入力データを集める

質を決めるのは、重要な語の一覧と、新旧の素材の原稿です。 重要な語が決まっていないと、差異のどれが広告主にとって困るものかを決められません。完成した素材の新旧の原稿がそろっていないと、差し替え前の素材が流れたことを判定できません。

放送確認書のPDFは、表の行を読み取って使います。 局ごとに様式が違うため、局ごとに列の並びを決めた読み取りの設定を作ります。 読み取りに自信のない行は、担当者が出稿の管理表と見比べて結びつけます。

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

文字起こしは、高速文字起こしのAPIに音声とその定義を送ります。

POST https://{リソース名}.cognitiveservices.azure.com/speechtotext/transcriptions:transcribe?api-version=2025-10-15
audio      = 放送IDを名前にした音声ファイル
definition = {
  "locales": ["ja-JP"],
  "profanityFilterMode": "None",
  "phraseList": { "phrases": ["<広告主名>", "<商品名>", "<店舗名>",
                              "<キャンペーン名>"] }
}

profanityFilterMode を None にするのは、照合のためです。 既定の Masked のままだと、不適切な語と判定された語が伏せ字になり、原稿との照合で「抜け」と出ます。 広告の文言は原稿で確かめてあるので、伏せ字にする理由がありません。

フレーズリストは、認識の直前に渡す語句の一覧で、モデルの学習は要りません。 2,000語句を超えないようにし、長いほど品質と待ち時間に影響するとされています。その放送の広告主の語句だけを渡し、価格や電話番号の数字は入れません。 数字をフレーズリストに入れると、原稿の数字に寄せて認識され、読み違いを見逃すおそれがあるためです。

AIへ渡す前に整形する

1. 数字の書き方をそろえる … 高速文字起こしの結果は表示形式（ディスプレイ形式）だけで返ります。「千九百八十円」「1980円」「1,980円」を同じ形にそろえます。原稿の側も同じ規則でそろえます
2. 日付と期間の書き方をそろえる … 「10月31日」「十月三十一日」「31日」を、原稿の期間から月を補わずに、読まれたままの形でそろえます
3. 記号と空白を落とす … 句読点、かぎ括弧、全角と半角の違いを落としてから比べます
4. CMの範囲を決める … 番組の前後の話が入っている録音は、原稿の最初と最後の文に近い位置で切ります
5. 聞き取れなかった文に印を付ける … confidence がしきい値を下回る文を low_confidence にします

1番目を、原稿と録音の両方に同じ規則で行うのが要です。 片方だけをそろえると、数字が合っているのに差異と出るか、違っているのに一致と出ます。 規則は中継の処理の中の1か所に置き、両方から呼びます。

2番目で月を補わないのは、読み違いを消さないためです。 パーソナリティが「31日まで」と読んだのを、原稿の「10月31日まで」に合わせて補うと、月を読み落としたことが分からなくなります。

AIに処理させる

差異そのものは、AIに見つけさせません。 そろえた原稿と文字起こしを Python の difflib の SequenceMatcher で比べ、get_opcodes() が返す replace ／ delete ／ insert の箇所を差異として取り出します。比べる文字数が200を超えると既定の自動の除外が働くため、autojunk=False を指定します。

AIにさせるのは、取り出した差異の1つずつに種類を付けることだけです。

asr_suspect を別に立てるのが、第1章の「聞き違え」への答えです。 原稿の「ご来店」が「ご来展」と出ていれば、ほぼ認識の誤りです。ただし重要な語に当たる差異は、asr_suspect でも担当者が聞きます。 価格の聞き違いと読み違いは、文字では区別できないからです。

指示内容を固定する

あなたは広告会社でラジオCMの放送を確認する担当の補助です。
放送の文字起こしと、発注した原稿の差異の一覧を受け取り、
差異の1つずつに種類を付けてください。差異を新しく探さないでください。

【CMの種別】{cm_type}（live：生CM／recorded：完成した素材）
【重要な語の一覧】{key_terms}
  社名、商品名、価格、期間、電話番号、URL、注意書きの文

【種類の選び方】
- key_term_error … 重要な語の一覧にある語が、文字起こしで違う語・数字になっている
- omission ……… 原稿の文や注意書きが、文字起こしに無い
- addition ……… 原稿に無い内容が足されている
- wording ……… 意味が変わらない言い回しの違い（語順、助詞、「です」と「でございます」など）
- asr_suspect … low_confidence の文の中で、音が似ている別の語になっている

【厳守事項】
- 重要な語に当たる差異は、音が似ていても key_term_error にしてください。
  asr_suspect にしてよいのは、重要な語に当たらない差異だけです。
- 価格・日付・電話番号の数字が1桁でも違えば key_term_error です。
- 足された内容に価格・割引・期間・条件が含まれる場合は、addition にして
  has_condition を true にしてください。
- 原稿が正しいか、放送が正しいかを判断しないでください。
- 迷ったときに wording を選ばないでください。
- 各差異に、差異の番号 diff_id と、根拠にした文字起こしの文番号を付けてください。

【差異の一覧（diff_id・原稿側・文字起こし側・文番号・low_confidence）】{diffs}
【原稿の全文】{script}

「迷ったときに wording を選ばない」を明記しないと、生CMの差異をまとめて言い回しの違いにします。 生CMは原稿とずれているのが普通なので、生成AIは「よくある崩し」として流しがちです。 迷ったものが聞く側に寄るようにしておきます。

重要な語を asr_suspect にさせないのは、聞き違いの判定が楽観に傾くからです。 「1,890円」が認識の誤りか読み違いかは、AIにも分かりません。分からないものは人が聞きます。

出力形式を固定する

次の形のJSONで受け取ります。 Azure OpenAI の構造化出力で、このスキーマに従わせます。

{
  "broadcast_id": "",
  "cm_type": "live | recorded",
  "diffs": [
    { "diff_id": 0,
      "category": "key_term_error | omission | addition | wording | asr_suspect",
      "key_term": null, "has_condition": false,
      "sentence_id": 0 }
  ],
  "version_match": null
}

構造化出力では、すべての項目を必須にし、省略したいものは null との共用体型で表します。 オブジェクトには additionalProperties: false が必要です。version_match は完成した素材のCMだけに使い、生CMでは null にします。

完成した素材のCMの新旧の判定は、規則で行います。 文字起こしを新旧の原稿のそれぞれと SequenceMatcher で比べ、ratio() の値と重要な語の一致を見ます。

中継の処理は、確認の一覧に時刻を付けます。 差異の箇所の単語の offsetMilliseconds から、前後2秒を含む再生の範囲を作ります。担当者は一覧の行を押すと、その数秒だけを聞けます。

確認の一覧の行は、次のような形になります。

1行目と3行目は、どちらも数字の違いですが、意味が違います。 1行目は読み違いか聞き違いかを聞いて決めるもの、3行目は素材の取り違えで、同じ枠のその後の放送もすべて確かめるものです。

システムへ連携する

出稿の管理表には書き込みません。 確認の結果は確認の一覧と放送報告の側に残し、出稿の管理表は発注の記録として変えずにおきます。

局への確認と対応の依頼は、担当者が送ります。 依頼の文面の下書きは出しますが、補填や再放送を求めるかどうかは、局との取り決めと広告主の意向で決まるからです。

人が確認する

人が聞くのは、確認の一覧に載った箇所だけです。 次の順に見ます。

1. previous を先に見る … 差し替え前の素材の放送は、同じ誤りが続いているおそれがあります。その日以降の同じ枠もまとめて確かめます
2. key_term_error と omission を聞く … 該当の数秒を聞き、放送の誤りか、音声認識の誤りかを決めます
3. addition で条件を含むものを聞く … 原稿に無い割引や期間が足されていないかを確かめます
4. 結果を確定する … 放送の誤りと決めたものに、局への依頼の要否を付けます

確認の画面には、原稿と文字起こしを並べ、差異の箇所に色を付けます。 聞く前に何が違うのかが分かっていれば、数秒の再生で判断がつきます。

wording を全部聞き直さないでください。 聞き直す運用にすると、第10章の1分には収まりません。最初の1か月だけ、wording から無作為に1割を選んで聞き、誤って言い回しの違いにされた重要な差異が無いかを確かめます。

例外に対処する

上から6行目は、放送の誤りとして見落とされやすいものです。 パーソナリティの善意の一言でも、広告主が出していない割引は、店舗での説明の手間を生みます。 原稿に無いことを足したかどうかも、確認の対象にします。

記録を残す

• 元の録音のファイルと放送確認書、受け取った日時
• 文字起こしの全文と、文と単語ごとの時刻・信頼度
• そろえた後の原稿と文字起こし、difflib が出した差異の一覧
• 生成AIの分類と、担当者が確定した結果（放送の誤り／音声認識の誤り）
• 局への依頼と、その回答・対応
• 広告主へ送った放送報告

4つ目で「音声認識の誤り」と確定した件数は、フレーズリストを直す材料になります。 特定の店舗名がいつも聞き違えられるなら、その語をフレーズリストに足します。

録音の保存の期間は、局との取り決めに合わせます。 放送の録音は局から受け取ったもので、使ってよい範囲と期間は契約で決まっています。