音楽出版社が広告・映像の制作会社から届く楽曲の使用の依頼に、曲調・テンポ・歌詞の言葉・権利の状態で管理楽曲のカタログを検索し、提案できる曲の候補を許諾の条件付きで並べる

処理の起点を決める

処理の起点は2つあります。 1つは、営業の担当が受付の画面から依頼を送ったとき。もう1つは、毎晩、権利の台帳と曲の説明の表から、前日に変わった曲を索引に入れ直すときです。

排他の期間の登録は、その日のうちに索引に反映させます。 CMの使用が決まって排他を登録した直後に、同じ業種の別の依頼が来ることがあるからです。著作権の管理の担当が台帳で排他を登録したら、その曲だけを索引に入れ直します。

入力データを集める

質を決めるのは、曲の説明とテンポです。 説明の無い曲は意味の近さで見つからず、テンポの無い曲は数字の幅で絞れません。説明の書き方をそろえる決まり（第14章）が、この構成の最初の作業です。

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

索引の項目は、次のように持たせます。

テンポは integer_range で持ちます。 公式のページでは、範囲の型に integer_range と date_range があり、範囲の検索の relation の既定は INTERSECTS です。途中でテンポが変わる曲を「92〜128」で持てば、依頼の「110〜130」と重なるので候補に入ります。 1つの数字で持つと、どちらかの区間で外れます。

排他は、業種と期間の組で持ちます。 1曲に複数の排他が付くことがあるので、業種と期間を組にした nested の項目にします。依頼の業種と期間に重なる排他がある曲を、絞り込みで外します。

AIへ渡す前に整形する

1. 曲の説明をそろえる … 担当者ごとの書き方を、決まったタグの語（「明るい」「疾走感」「切ない」「壮大」など）と自由な説明に分けます
2. 説明の無い曲に印を付ける … 説明もタグも無い曲は mood_text を空にし、説明を書く対象の一覧に回します
3. テンポを数字にする … 説明の表の「速め」「ミディアム」は数字にせず、数字が分からない曲は bpm_range を空にします
4. 歌詞を分ける … 歌詞は kuromoji で分けます。歌詞は意味の近さの検索に使わず、言葉の一致だけに使います
5. 権利の項目を写す … 台帳から毎晩写します。排他の登録は即時に写します
6. 埋め込みを作る … mood_text が変わった曲だけ、埋め込みを作り直します

3番目で「速め」を数字にしないのは、言葉の幅が人によって違うからです。 「速め」を130と決めて入れると、110の曲を「速め」と書いた担当者の説明と食い違います。 数字が分からない曲は、テンポの絞り込みから外れないよう、絞り込みの側で「テンポが空の曲も含める」を選べるようにします。

4番目で歌詞を意味の検索に使わないのは、歌詞の雰囲気と曲調が一致しないことがあるからです。 明るい曲調で別れを歌う曲は珍しくありません。歌詞は「空」「走る」のような言葉を探すときだけに使い、曲調は説明で探します。

AIに処理させる

させるのは、依頼の文を検索の条件に分けることだけです。 曲を選ぶこと、許諾できるかを決めることはさせません。

検索は hybrid で、言葉と意味の3つの検索を組み合わせます。

{
  "query": {"hybrid": {
    "filter": {"bool": {
      "filter": [
        {"terms": {"territory": ["国内", "全世界"]}},
        {"range": {"bpm_range": {"gte": 110, "lte": 130, "relation": "INTERSECTS"}}}
      ],
      "must_not": [
        {"term": {"excluded_industries": "飲料"}},
        {"nested": {"path": "exclusivity", "query": {"bool": {"filter": [
          {"term": {"exclusivity.industry": "飲料"}},
          {"range": {"exclusivity.period": {"gte": "2027-01-01", "lte": "2027-03-31",
                     "relation": "INTERSECTS"}}}]}}}}
      ]}},
    "queries": [
      {"match": {"mood_text": "明るい 前向き 爽やか"}},
      {"match": {"lyrics": "空 走る"}},
      {"knn": {"mood_vector": {"vector": [], "k": 50}}}
    ]}}
}

得点のまとめ方は、normalization-processor で決めます。 公式のページでは、正規化の既定は min_max、組み合わせの既定は arithmetic_mean で、weights で検索ごとの重みを決められます（合計は1.0）。arithmetic_mean では、1つの検索にしか当たらなかった文書は、当たらなかった検索の分が0として数えられ、得点が半分になるとされています。

この性質は、歌詞の言葉の検索で効いてきます。 歌詞に「空」が無くても雰囲気の合う曲は多く、歌詞の検索の重みを大きくすると、そうした曲が下に沈みます。 重みは、曲調の説明（言葉）0.35、曲調の説明（意味）0.45、歌詞 0.2 から始め、担当が選んだ曲の順位を見て直します。依頼に歌詞の言葉が無いときは、歌詞の検索を外して2つで組みます。

指示内容を固定する

あなたは音楽出版社の営業の担当として、広告会社・制作会社から届いた
楽曲の使用の依頼を、カタログの検索の条件に分ける立場です。
依頼の文に書かれていることだけを使ってください。

【分ける項目】
- mood_terms: 曲調を表す言葉。次のタグの語のうち近いものと、
  依頼の言葉そのものを並べる
  タグの語: {mood_tags}
- mood_summary: 曲調の説明に使う1〜2文
- bpm_min / bpm_max: テンポの数字の幅
- lyric_terms: 歌詞に入っていてほしいと書かれた言葉
- vocal: female / male / mixed / instrumental / unspecified
- length_sec: 曲の長さの希望（秒）
- notes: 上のどれにも入らない希望

【厳守事項】
- テンポの数字が書かれていないときは、bpm_min と bpm_max を null に
  してください。「速め」「ゆったり」を数字に直さないでください。
- 「120前後」のように書かれていたら、前後10の幅にしてください。
- 歌詞の言葉は、依頼に書かれたものだけを写してください。
  言い換えや似た言葉を足さないでください。
- 曲名・作家名・アーティスト名を挙げないでください。
  曲を選ぶのはこの後の検索と担当です。
- 許諾できるか、使用料がいくらかを書かないでください。

【依頼の文】{request_text}

「曲名を挙げない」と書くのは、モデルが有名な曲を思いつくからです。 依頼の雰囲気から、他社の管理する有名な曲の名前を挙げることがあり、それが自社のカタログにあるかのように受け取られると、提案の誤りになります。

「歌詞の言葉を言い換えない」も同じ考えです。 依頼者が「空」と書いたのは、CMのコピーと合わせるためであることが多く、「青」「雲」を足すと、意図と違う曲が上がります。

出力形式を固定する

Claude API の構造化出力で、次の形で受け取ります。 output_config.format に type: json_schema でスキーマを渡し、vocal は enum で縛ります。数値の minimum／maximum は構造化出力で使えないので、テンポの幅が40〜250に入っているかは Lambda で確かめます。

{
  "mood_terms": ["明るい", "前向き", "爽やか"],
  "mood_summary": "春の始まりに合う、明るく前向きで爽やかな曲",
  "bpm_min": 110, "bpm_max": 130,
  "lyric_terms": ["空", "走る"],
  "vocal": "female",
  "length_sec": 30,
  "notes": "サビが冒頭15秒以内にあるとよい"
}

1つ目の理由は、mood_summary をそのまま埋め込みの検索に使えることです。 依頼の文をそのまま埋め込むと、「30秒」「春のCM」のような条件の言葉が混ざり、曲調以外の言葉で意味の近さが決まります。

2つ目は、bpm_min が null のときに、テンポの絞り込みを外せることです。 null を0や既定の数字で埋めると、絞り込みで曲が落ちます。

候補の一覧は、次の形です。

{
  "request_id": "SY-20261015-0044",
  "ready": [{"song_id": "", "title": "", "matched": ["mood_text", "bpm_range"],
             "lyric_hits": ["空"], "master_owner": "レコード会社",
             "use_history": "2023年 テレビCM（飲料以外）"}],
  "needs_approval": [{"song_id": "", "approval": "作家の承認"}],
  "excluded_count": {"exclusivity": 0, "excluded_industries": 0, "territory": 0}
}

excluded_count は、絞り込みで外れた曲の数です。 候補が少ないときに、雰囲気の合う曲が無いのか、権利の条件で外れたのかを担当が分けられます。 外れた曲の名前は出しません。

master_owner を出すのは、原盤の権利が別だからです。 著作権法は、レコード製作者がそのレコードを複製する権利を専有するとしています（第96条）。既存の録音をそのまま使う依頼では、音楽出版社の許諾だけでは足りず、原盤の権利者の許諾も別に要ります。

システムへ連携する

権利の台帳には書き込みません。 候補に挙がったことも、提案したことも、台帳の記録にはしません。使用が決まったときの許諾と排他の登録は、著作権の管理の担当が台帳で行います。

人が確認する

担当は、依頼者に送る前に、候補の曲を必ず試聴します。

1. excluded_count を見る … 候補が少なく、外れた曲が多ければ、期間や業種の条件を依頼者と相談する材料にします
2. ready を試聴する … 曲の説明が実際の曲に合っているかを耳で確かめます。合っていなければ、その曲の説明を直す一覧に回します
3. needs_approval を著作権の管理の担当に回す … 作家の承認や共同出版者の同意の見込みを確かめてから送ります
4. master_owner を見る … 既存の録音を使う依頼なら、原盤の権利者への確認を依頼者に伝えます

2番目で説明を直す一覧に回すのが、検索を良くしていく道です。 説明が曲に合っていないと、その曲は雰囲気の検索で何度も外れるか、合わない依頼で何度も上がります。直した説明は翌晩の取り込みで埋め込みが作り直され、次の依頼から効きます。

目標は1件7分です。 候補の上位を数曲ずつ試聴し、承認の要る曲の見込みを確かめるところまでで、著作権の管理の担当が作家に確かめる時間は含みません。

例外に対処する

5行目で業種が分からないまま検索しないのは、排他の判定ができないからです。 業種の分からない依頼で候補を出すと、排他の期間中の曲を提案することになります。

記録を残す

• 依頼の文、使う媒体・期間・地域・業種、Claude API が分けた条件
• 実際の検索の条件（絞り込み、重み）と、excluded_count
• 候補の一覧と、担当が試聴した曲、依頼者に送った曲
• 依頼者が試聴の後に選んだ曲（分かった場合）
• 担当が「説明が合っていない」とした曲と、直した説明

4つ目は、重みを直す材料になります。 依頼者が選んだ曲が候補の何番目にあったかを毎月見て、下のほうから選ばれることが多ければ、重みか曲の説明を見直します。