こんにちは、学びの探求者です。
普段はnoteで活動しています。
2025年のQiitaアドベントカレンダーでは、
「ノーコード／ローコードで、自分のコンテンツ基盤を自動化していく」
をテーマに、25日間の仕組みづくりを記録していきます。
ぜひ、応援してください。
Day8 と Day9 では、ついに「推し」の話です。
今回は WEST. のセトリ予想のための曲データ基盤を、スプレッドシートだけで組み立ててみた話を書きます。
⚠ 注意：この時点でデータはまだ「ざっくり版」です。
いろいろなサイトを見て、目視とコピペで集めているので、
まだ完全に正規化できていません。
でも、それでも十分“役に立つ”状態にはできる、という話でもあります。
今日のゴール
Day8 のゴールはただひとつ。
「WEST. の曲たちを、セトリ予想に使える“マスターテーブル”っぽい形にする」
です。
具体的には：
- シングル曲（A面・カップリング）を singles シートにまとめる
- アルバム曲を albums シートにまとめる
- 2つをマージして、「曲ごとの基本情報が1行にまとまった songs シート」をつくる
ここまでを スプレッドシートベースでやり切る のが Day8 の範囲です。
（Day9 で、ここにセトリ情報をひも付けて「頻度」を計算していきます）
スプレッドシート構成
最終的に、スプレッドシートの構成はこんな感じに落ち着きました。
- singles：シングル起点（A面 / カップリング）で曲情報を整理した“元データ”
- albums：アルバム起点で曲情報を整理した“元データ”
- songs：singles と albums をもとに作った、“マージ済みマスター”
途中で試行錯誤があり、
いったん songs を作ってみた →
「元のシングル一覧はそれはそれで残したい」と思った →
songs をコピーして singles として保持
という流れになりましたが、
記事上は「singles と albums から songs を作る」というかたちで整理しています。
singles シート：シングルから曲一覧を作る
まずは、シングルから曲リストをつくりました。
single シートのカラム構成はこんな感じです：
| 列 | カラム名 | 説明 |
|---|---|---|
| A | song_name | 曲名 |
| B | release_type |
single 固定 |
| C | release_name | シングルのタイトル（例：ええじゃないか） |
| D | release_year | 発売年（西暦） |
| E | is_single_title | A面なら 1、そうでなければ 0 |
| F | is_coupling | カップリングなら 1、それ以外は 0 |
| G | is_album_track | アルバムにも入っているなら 1（後で付与） |
| H | is_unit_or_solo | ユニット／ソロ曲なら 1 |
| I | memo | 補足（デビュー曲、ライブでも定番 etc.） |
例：デビューシングル「ええじゃないか」の行
| song_name | release_type | release_name | release_year | is_single_title | is_coupling | is_album_track | is_unit_or_solo | memo |
|---|---|---|---|---|---|---|---|---|
| ええじゃないか | single | ええじゃないか | 2014 | 1 | 0 | 1 | 0 | デビュー曲・ライブ頻度高い |
| バンザイ夢マンサイ! | single | ええじゃないか | 2014 | 0 | 1 | 1 | 0 | |
| その先へ… | single | ええじゃないか | 2014 | 0 | 1 | 1 | 0 | |
| 浪速一等賞! | single | ええじゃないか | 2014 | 0 | 1 | 1 | 0 | |
| Rainbow Dream | single | ええじゃないか | 2014 | 0 | 1 | 0 | 0 |
ここは完全に「手作業」です。
公式サイトだけでなく、ファンサイトや Wikipedia なども見ながら、
自分が納得できる粒度で埋めていきました。
albums シート：アルバムから曲一覧を作る
次に、アルバム起点で曲を一覧化しました。
albums シートのカラム構成はこうしています：
| 列 | カラム名 | 説明 |
|---|---|---|
| A | album_name | アルバム名（例：なうぇすと etc.） |
| B | release_year | 発売年 |
| C | song_name | 収録曲名 |
| D | singer | ユニット／ソロの場合にメンバー名を入れる |
singer は、最初は「ユニット曲の判定に使えるかな？」と思って入れていましたが、
最終的には そこまで予測に効かなそう だったので、
- とりあえず情報としては残す
- モデル上のフラグ分け（ユニット / ソロ）は深追いしない
というスタンスにしました。
人気が出る曲は、ユニット曲初出でも「全員版」でアルバム入りしたりするので、
「ユニットかどうか」よりも
どのアルバムに入っているか・どれくらいライブで歌われているか
の方がセトリ予想には効きそう、という判断です。
アルバムにしか入っていない曲を見つける（helper 的なこと）
シングルリスト（songs）とアルバムリスト（albums）ができたので、
「シングルにはいないけど、アルバムにはいる曲」＝アルバム専用曲
を見つけたくなります。
一時的に helper シートを作り、こんな感じの式を使いました：
=FILTER(
albums!C2:C,
ISNA(MATCH(albums!C2:C, songs!A:A, 0))
)
- albums!C2:C …… アルバム側の song_name
- singles!A:A …… シングル側の song_name
- MATCH(..., 0) で一致を探して、見つからなかったもの（ISNA）だけを抽出
これで 「アルバムにだけ登場する曲一覧（候補）」 が取れます。
が、ここでひとつ問題が出ました。
問題：参照元を書き換えると helper が全部消える問題
singles や albums をいじっていると、
それを参照している FILTER / MATCH が再計算されてしまい、
helper シートの結果がまるごと空になる ことが何度もありました。
「せっかくきれいに抽出できたのに、ちょっと元データを触ると消える…！」
というストレスが大きかったので、
最終的には以下の割り切りをしました。
割り切り：helper は「一時的な計算用」、正として残すのは“値だけ”
最終的な運用はこうです：
1. helper シートで FILTER や MATCH を使って、アルバム専用曲候補を出す
2. 結果を 別シートか別の場所に、「値として」貼り付ける
3. そこから先は、「ただのテーブル」として扱う（関数は消してOK）
つまり、
関数で“抽出”はするけど、
抽出した結果はスナップショットとして保存し、
マスターデータは“値だけの世界”にする。
というスタイルです。
ノーコード／ローコードのワークフローに乗せるなら、
最終的にはこの「値だけ」のテーブルを参照したほうが安定します。
songs：マージ済みマスターテーブルを作る
最終的には、
• singles（シングル起点の曲リスト）
• albums（アルバム起点の曲リスト）
• helper の抽出結果（アルバム専用曲）
をもとに、
1曲を1行で表現した “マージ済みマスター”
として songs シートを手で作りました。
（実際には、途中で songs を作ってから「これは元データとして残したい」と思い、
コピーして singles に分けています）
songs の列構成は、singles をベースにしています：
| 列 | カラム名 | 説明 |
|---|---|---|
| A | song_name | 曲名 |
| B | release_type |
single / album / best など |
| C | release_name | シングル名 or アルバム名（共通カラム） |
| D | release_year | 発売年 |
| E | is_single_title | シングルA面なら 1 |
| F | is_coupling | カップリングなら 1 |
| G | is_album_track | アルバムに入っているなら 1 |
| H | is_unit_or_solo | ユニット／ソロ曲なら 1（使うかは後で考える） |
| I | memo | 「デビュー曲」「ライブ定番」など自由記述 |
ポイントは、
C列の release_name に、シングル名もアルバム名も全部まとめてしまうという設計にしたことです。
「これはシングルの何枚目で、こっちはアルバムの何枚目で…」と細かくやり始めると、
正規化との戦いになってしまいます。
今回は セトリ予想に必要な粒度だけ残す ことを優先して、
- その曲が最初に（あるいは印象的に）出た「作品名」
- その作品がシングルなのかアルバムなのか
- いつ頃の作品（年）
がわかればよし、と割り切りました。
「完璧な正規化」はいったんあきらめる
正直にいうと、この記事を書いている時点では、
- 公式情報だけでは拾えないものもある
- サイトによって表記ゆれがある
- FG 曲や未音源の情報は追いきれていない
などの理由から、
「完璧な正規化」はまだできていません。
でも、それでも、
- 楽曲ごとの行があって
- シングル／アルバムが区別できて
- だいたい何年の曲かわかって
- 「これはデビュー曲」「これはカップリング」くらいがメモに入っている
という状態になれば、セトリ予想に使うには十分な“マスター”になります。
完璧にしたくなる気持ちはめちゃくちゃあるのですが、
まずは動く分析環境をつくることを優先する
という判断をしました。
Day9 につづく：セトリとひも付けて「ライブ頻度」を出す
Day8 では、
- singles シートでシングル起点の曲データをつくる
- albums シートでアルバム起点の曲データをつくる
- helper 的なシートでアルバム専用曲を抽出する
- 最終的に “マージ済み曲マスター songs” をつくる
ところまでをスプレッドシートで組んでみました。
Day9 では、ここに 「セトリ情報」 を足していきます。
- ライブごとのセットリストを setlists シートとして表にする
- COUNTIF / COUNTIFS で「この曲が何回歌われたか？」を数える
- TOUR / SPECIAL / EVENT など、ライブの種類ごとの頻度も出す
- セトリ予想モデルの“特徴量”として使える形にする
ここまでいくと、
「WESTA! で歌われそうな曲」を、感覚ではなく“数字込み”で予想できるようになります。
推しのライブを科学するのも、また楽しい。
おわりに
今回は、
「ノーコード／ローコードで遊びながら学ぶ」
かつ
「推し活にも使えるデータ基盤づくり」
という、個人的にテンションの上がる回でした。
データはまだ完璧ではありませんが、
自分が使えるレベルの“マスター”が1つできたことで、
この先のセトリ予想や可視化が一気にやりやすくなりました。
Day9 では、いよいよ セトリ × 曲マスターを掛け合わせて「ライブ頻度」を出す ところに進みます。
読んでくださってありがとうございました。
続きもゆるっとお付き合いいただけると嬉しいです。