自社が配信するポッドキャストの音声を文字に起こし、番組の紹介文・章立て・SNSの告知文を下書きして、固有名詞の確認に回す

処理の起点を決める

編集済みの mp3 が「配信前」フォルダに置かれたことを起点にします。 見張るのは作成の日時で、ファイルの種類は音声に絞ります。担当者が手でシナリオを動かす運用にはしません。 編集者が置いた時刻から下書きができるまでを、人の手が空くのを待たずに進めます。

実行の間隔は1時間にします。 配信は週に数回で、編集済みの音声が届くのは配信日の前日か前々日です。15分ごとに見張る必要はありません。 1回で扱う件数の上限は3にします。1話ごとの処理が重いので、まとめて置かれたときは次の実行に回します。

ファイル名の決まりを編集者と決めておきます。 「番組の略号_回の番号.mp3」の形にし、シナリオはファイル名から番組と回を読みます。決まりに合わないファイル名のものは処理せず、担当者に知らせます。 番組を取り違えると、辞書も紹介文の型も別の番組のものが使われます。

入力データを集める

質を決めるのは、回の情報と辞書です。 ゲストの名前と所属を収録の前に管理表に書いておけば、文字起こしの名前と照らす先ができます。 辞書には、自社の社名、番組名、聞き手の名前、自社と取引先の製品名、業界でよく出る語を入れ、「よくある誤りの表記」の列も持たせます。 一度誤った表記が見つかったら、ここに足します。

公開しない話題の欄は、編集で落としきれなかったときの備えです。 収録で「ここはオフレコで」と言った話題を担当者が書いておき、紹介文と告知文にその話題が入っていないかを、AIに印を付けさせます。 落とすのは編集者と担当者です。

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

文字起こしの呼び出しには、次の項目を付けます。 model は whisper-1、response_format は verbose_json、timestamp_granularities[] は segment です。verbose_json で返ってくる区切りごとの開始の時刻が、章立ての時刻の元になります。

prompt には、その回の固有名詞を並べます。 OpenAI のガイドでは、プロンプトは名前・略語・その収録に特有の語の認識を助けるとされ、whisper-1 では 224トークンまで とされています。全部の辞書は入らないので、その回のゲストの名前と所属、番組名、聞き手の名前、自社の社名に絞ります。 取りこぼした名前は、後の段の照合で拾います。

ファイルは25MBまでです。 OpenAI のガイドでは、Transcriptions API が受け付けるファイルは25MBまでで、それを超えるものは圧縮した形式にするか、25MB以下に分けるとされています。分けるときは文の途中で切らないようにとも書かれています。編集者に、書き出しの設定を話し声に足りるビットレートにしてもらうのが先です。 1話50分を超える回だけ、編集者に前後半の2ファイルで置いてもらいます。

AIへ渡す前に整形する

1. ファイル名の確認 … 番組の略号と回の番号を読み、管理表に回の行があるかを確かめます
2. サイズの確認 … 25MBを超えるものは処理せず、担当者に知らせます
3. 文字起こしの区切りに番号を振る … 返ってきた区切りに 0 から順に番号を付け、番号・開始の時刻・文の表にします
4. 辞書の絞り込み … 番組の略号と「共通」に当たる行だけを渡します
5. 区切りの表を渡す形に整える … 「[12] 734.2 今日は採用の話を…」のように、番号と開始の秒と文を1行にします
6. 前後半の2ファイルのとき … 後半の区切りの開始の時刻に、前半の長さを足してからつなぎます

3番目と5番目が、章の時刻をAIに数えさせないための準備です。 AIには区切りの番号を選ばせ、番号から時刻を引くのはワークフローです。 AIに「12:30」と書かせると、秒を分に読み替えたり、近い時刻を丸めたりします。

6番目を忘れると、後半の章の時刻が全部ずれます。 後半のファイルの時刻は後半の頭から数えられているからです。

AIに処理させる

させるのは、1回の呼び出しで4つの下書きと1つの一覧を作ることです。

引いた発言には、区切りの番号を必ず付けさせます。 告知文に入れる発言は、ゲストの言葉として世に出ます。ワークフローは番号の区切りの文に、引いた発言がそのまま含まれるかを確かめ、含まれなければ告知文に印を付けます。

固有名詞は、照合の結果を3つに分けます。 辞書の表記と一致した matched、辞書の「よくある誤りの表記」に当たった known_misspelling、辞書に無い not_in_dictionary です。2つ目は辞書の正しい表記に置き換えてよいものとし、3つ目は人が確かめます。

1行目がいちばん起きやすい誤りです。 文字起こしに「さいとう」と出ても、AIは文脈から「斉藤」と書きがちです。ゲストが「齋藤」なら、その一字の違いが（c）の連絡になります。 直させずに、一覧に出させます。

指示内容を固定する

あなたは自社のポッドキャスト番組の制作担当です。
下の文字起こしだけを使って、配信ページと SNS の下書きを作ってください。
文字起こしに無いことを書かないでください。

【作るもの】
1. 紹介文：番組の型に沿って、話題の要点とゲストの紹介を書く。
   ゲストの名前・所属・肩書きは、回の情報に書かれたものだけを使う。
2. 章立て：話題が変わったところの区切りの番号（segment_id）と、
   章の見出しを選ぶ。最初の章は区切り 0 から始める。
   時刻は書かないでください。番号だけを選んでください。
3. 告知文：番組の調子に沿って書く。発言を引く場合は、
   文字起こしの文をそのまま引き、その区切りの番号を quote_segment_id に入れる。
   言い換えた発言を、かぎかっこで引かないでください。
4. 固有名詞の一覧：文字起こしに出た人・会社・製品・サービスの名前を、
   文字起こしの表記のまま並べ、辞書と照らして status を付ける。
   - matched ............ 辞書の正しい表記と一致する
   - known_misspelling .. 辞書の「よくある誤りの表記」に当たる
   - not_in_dictionary .. 辞書に無い

【厳守事項】
- 辞書に無い名前を、正しそうな字に直さないでください。
  紹介文と告知文には、文字起こしの表記のまま入れ、一覧に出してください。
- known_misspelling に当たった名前は、紹介文と告知文で辞書の正しい表記を使ってください。
- 下書きに、回の情報の「公開しない話題」が入っていないかを見て、
  入っていれば contains_off_record を true にしてください。迷う場合も true。
- 配信してよいかどうかは書かないでください。

【番組の情報】{show}
【回の情報（ゲスト・公開しない話題）】{episode}
【固有名詞の辞書】{dictionary}
【文字起こし（[番号] 開始の秒 文）】{segments}

「時刻は書かないでください。番号だけを」と明記しないと、両方を書きます。 番号と時刻の両方があると、ワークフローがどちらを使うかで迷い、時刻のほうが間違っていても気づけません。 書かせるものを1つにします。

「言い換えた発言を、かぎかっこで引かない」は、告知文のためです。 告知文は短く切れのある文が好まれるので、AIは発言を短く言い換えて引きがちです。かぎかっこの中は、ゲストが実際に言った言葉でなければなりません。

出力形式を固定する

{
  "episode_id": "",
  "description": "",
  "chapters": [
    { "segment_id": 0, "title": "" }
  ],
  "social_post": "",
  "quote_segment_id": null,
  "proper_nouns": [
    { "as_transcribed": "", "kind": "person | company | product | other",
      "status": "matched | known_misspelling | not_in_dictionary",
      "dictionary_form": "" }
  ],
  "contains_off_record": false
}

構造化出力にする1つ目の理由は、章立てを番号のまま受け取れることです。 chapters の segment_id を、ワークフローが区切りの表で開始の秒に引き、「12:14」の形に直して見出しの前に付けます。Claude API の構造化出力では、スキーマを output_config.format に渡すと、その形の JSON が応答の本文に入ります。

2つ目は、固有名詞の一覧を配列で受け取れることです。 not_in_dictionary のものだけを抜き出して、担当者へのメールの一番上に並べます。 担当者は下書きを全部読む前に、確かめる名前を知ることができます。

3つ目は、応答の終わり方を確かめられることです。 公式のページでは、stop_reason が max_tokens のときは出力が途中で切れてスキーマに合わないことがあるとされています。50分の回は文字起こしが長いので、max_tokens には余裕を持たせ、通常の終わり方でなければ下書きを作らずに担当者に知らせます。

下書きの文書は、次の順に並べます。

システムへ連携する

Claude API は、Anthropic Claude のアプリの Make an API Call で呼びます。 Make のアプリには Create a Prompt もありますが、アプリの説明に構造化出力の設定が書かれていないため、Messages API の本文に output_config.format を自分で書きます。

配信ページと SNS には書き込みません。 載せるのは担当者です。自動で載せる設計にすると、名前の表記の誤りがそのまま公開されます。 メールを送る先も社内の担当者だけで、ゲストには送りません。

人が確認する

担当者が、すべての下書きを配信の前に確かめます。

1. 確かめる名前の一覧を先に見る … not_in_dictionary の名前を、名刺やゲストの会社のサイトで確かめ、紹介文と告知文の表記を直します。正しい表記が分かったら辞書に足し、誤りの表記も「よくある誤りの表記」の列に足します
2. 公開しない話題の印を見る … 印が付いていれば、該当の文を削り、編集者に音声の側も確かめてもらいます
3. 章立てを数か所聞く … 章の時刻に飛んで、話題の頭から始まっているかを確かめます
4. 告知文の発言を確かめる … 引いた発言を区切りの文と見比べ、ゲストの言葉を告知に使ってよいかをゲストに確かめます
5. 上長の確認を経て載せる … 管理表の状態を「確認済み」にして、配信ページに載せます

1番目で辞書に足すのが、この構成を育てる作業です。 同じゲストの会社の名前は、次の回にも出てきます。辞書が育つほど、not_in_dictionary の件数が減ります。

例外に対処する

上の2行が大半を占めます。 どちらも、音声の書き出しの設定と長さの問題です。編集者と書き出しの設定を一度決めれば、ほとんど起きなくなります。

記録を残す

• 元の音声のファイル名と、置かれた日時
• 文字起こしの JSON の全文（区切りごとの時刻を含む）と、渡した prompt
• Claude API の応答の JSON の全文と、stop_reason
• 下書きの文書の場所と、担当者が配信の前に直した箇所
• 辞書に足した名前と、足した日・足した人
• 配信ページに載せた最終の紹介文と章立て

4つ目を残すのは、指示を直す材料にするためです。 担当者が毎回同じように紹介文の書き出しを直しているなら、番組の型の書き方が足りていません。

5つ目は、辞書の質を保つためです。 誤った表記を正しい表記として足してしまうと、以後の回でその誤りが matched として通ります。 誰がいつ足したかが分かれば、見直せます。