生成AIと作るレコードコレクション可視化サイト ― JavaScriptとGitHub Pagesで詰まった5つの罠
Abstract
本記事は、Discogsに登録した613枚のレコードを、年代・ジャンル・作品間の関係から分析し、「自分がどんな音楽を、どのようなつながりで集めてきたのか」を可視化した記録である。
面白さは、所有枚数を集計するだけでなく、参加ミュージシャン、影響、共同制作などを線で結ぶことで、コレクションを個人の知識グラフとして眺められる点にある。線が集中する場所や、反対に線が存在しない場所から、自分でも意識していなかった収集傾向や、次に調べるべき音楽も見えてきた。
制作には生成AIを活用した。本記事を通して、曖昧なアイデアをAIとの対話で仕様へ変える方法に加え、Discogsデータの加工、MusicBrainzによるメタデータ補完、SVGを使ったネットワーク可視化、データ分析の切り口、GitHub Pagesでの公開、そして実装中に遭遇した5つの問題と解決方法を知ることができる。
はじめに
はじめまして、最近レコードを買いすぎて彼女に怒られはじめている道草太郎です。
レコード棚を眺めていると、ときどき不思議に思う。
Stevie Wonderの隣にPrinceがあり、その少し先にはD'Angeloがいる。Miles DavisからA Tribe Called Questへ頭の中で線が伸び、Joy DivisionはNew Orderへ名前とメンバーを引き継いでいく。
棚の上では別々のジャケットなのに、自分の中ではつながっている。
では、その「頭の中にある音楽の地図」を本当に画面へ描き出したら、何が見えるのだろう。
好きなジャンルの偏りだけではなく、どの年代を行き来しているのか。どんな作品を起点に次のレコードへ進んだのか。自分でも意識していなかったコレクションの傾向が見えてくるのではないか。
そんな思いつきから、Discogsに登録している613枚のレコードを、年代・ジャンル・作品間のつながりで可視化するWebサイトを作った。
そして今回は、かなりの部分を生成AIとの対話で進めた。
ただし、AIに「いい感じのサイトを作って」と頼んだら完成した、という話ではない。むしろ実際の制作は、完成しかけた画面を見て私が違和感を口にし、AIがそれを原因と仕様に翻訳し、また画面を見て考え直す、という往復の連続だった。
この記事では、サイトの作り方だけでなく、その過程で何を考え、生成AIとどうやり取りし、どこで詰まったのかを書いていく。
- 公開サイト: Record Collection Map
- ソースコード: GitHubリポジトリ
先にまとめ
- Discogsから書き出した613件のコレクションを、横軸＝初版発売年、縦軸＝ジャンルで配置した
- 大きなジャケットと小さな点を使い分け、情報量と一覧性を両立した
- MusicBrainzとCover Art Archiveで初版年とアートワークを補完した
- 作品間の線は「影響」だけでなく、メンバー在籍、演奏参加、共同制作、プロデュース、再解釈なども扱った
- 生成AIはコード生成だけでなく、要件整理、原因調査、関係性の調査、UI改善に使った
- 最後はHTML、CSS、JavaScriptだけの静的サイトとしてGitHub Pagesで公開した
「所有リスト」ではなく「自分の音楽地図」が欲しかった
Discogsはコレクション管理に便利だ。何を所有しているか、どの盤なのか、いつ登録したかを一覧にできる。コレクションはCSVとして書き出すこともできる。
一方で、一覧から見えるのは基本的に「1枚ずつの情報」だ。
私が見たかったのは、その間だった。
たとえば、ある作品を買った理由が、その作品単体にあるとは限らない。参加ミュージシャンをたどって別のアルバムに出会うこともあれば、サンプリング元を知って数十年前の作品を探すこともある。プロデューサー、レーベル、バンドの系譜からレコードが増えることもある。
つまり、コレクションは単なる所有物の集合ではない。聴いてきた順番、興味が枝分かれした跡、過去へさかのぼった軌跡が重なったものだ。
そこで、最初の仮説を次のように置いた。
頭の中にあるコレクション同士のつながりを可視化すれば、自分でも気づいていない収集傾向が見えてくるのではないか。
この仮説が、画面の設計を決めた。
- 横方向には時間を置く
- 縦方向にはジャンルを置く
- 作品同士の関係は線で結ぶ
- 線には「なぜつながるのか」という根拠を持たせる
Excelの集計表ではなく、地図のように眺められるものが欲しかった。
生成AIに最初から正解を求めない
制作にはChatGPTとCodexを使った。
最初に伝えたのは、Discogsのコレクションを年代とジャンルで可視化したい、という大まかな要望だった。そこから、データの持ち方、画面構成、静的サイトとして成立させる方法を一緒に分解していった。
構成はできるだけ単純にした。
DiscogsのCSV
↓ 必要な項目だけに加工
collection.js
↓
JavaScriptで年代・ジャンル別に配置
↓
MusicBrainzで作品を照合
↓
Cover Art Archiveから画像を取得
↓
HTML / CSS / JavaScriptをGitHub Pagesで公開
バックエンドもデータベースもない。ビルド工程もない。GitHub Pagesに置けば、そのままブラウザで動く構成である。
ここで生成AIに期待したのは、一度で完成コードを出してもらうことではなかった。
- まず動くものを作る
- 実際のデータで表示する
- 画面を見て違和感を言葉にする
- AIに原因と修正案を考えてもらう
- 修正後の画面をもう一度見る
この循環を速く回すことに使った。
振り返ると、最も重要だった入力は立派な仕様書ではなく、次のような率直な感想だった。
「これとこれがつながっていないのはなぜ？」
「2000年以降に線がないのは少し違和感がある」
「詳細を隠すボタンが反応しない」
人間の違和感が、次のプロンプトになった。
613枚を全部ジャケットにしたら、地図ではなく壁になった
コレクションは613件、ジャンルは8分類ある。
| ジャンル | 件数 |
|---|---|
| ロック／ポストパンク／ニューウェーブ | 167 |
| ソウル／ファンク | 105 |
| ワールド／その他 | 77 |
| エレクトロニック／ダンス | 68 |
| ジャズ | 60 |
| ヒップホップ | 50 |
| シティポップ／J-POP | 44 |
| レゲエ／スカ／ダブ | 42 |
最初は、せっかくならすべてのジャケットを並べたくなる。しかし613枚を同じ大きさで表示すると、作品同士が重なり、年代も線も読めない。音楽の地図を作るはずが、ジャケットの壁紙になってしまった。
そこで表示を二段階に分けた。
- つながりを持つ作品、代表作品、検索中・選択中の作品は大きなジャケットで表示する
- それ以外の通常レコードは小さな丸い点で表示する
小さな点は「画像取得に失敗したレコード」ではない。コレクション全体の密度を残しながら、重要な作品と関係線を読めるようにするための圧縮表現である。点もクリックすれば詳細を開ける。
これは最初の大きな学びだった。
可視化では、すべてを同じ強さで見せることが、すべてを見せることにはならない。
罠1：アルバムアートワークが一部しか出ない
画面ができた直後、目についたのは大量のプレースホルダーだった。
原因は一つではなかった。
- 自動照合が最初の少数件だけを対象にしていた
- タイトルとアーティスト名だけの検索では、再発盤や表記揺れを正確に特定できない
- Cover Art Archiveに画像がないリリースもある
- 一度の失敗をローカルキャッシュへ保存すると、その後も失敗結果を使い続けてしまう
特に厄介だったのは最後の項目だ。コードを直しても、ブラウザが古い「画像なし」という判定を覚えている。修正したのに直っていないように見える。
改善後は、次の順番で照合するようにした。
Discogs release ID
↓ MusicBrainzのURL relationshipを検索
MusicBrainz release / release-group ID
↓
Cover Art Archiveのfront画像
↓ 失敗した場合
タイトル＋アーティスト検索へフォールバック
さらに、照合ロジックへバージョン番号を持たせ、古い失敗キャッシュは再試行できるようにした。
const LOOKUP_VERSION = 2;
const RETRY_AFTER_MS = 6 * 60 * 60 * 1000;
function needsEnrichment(album) {
const cached = getEnriched(album);
if (!cached) return true;
if (cached.lookupVersion !== LOOKUP_VERSION) return true;
const checked = Date.parse(cached.coverFailedAt || cached.checkedAt || '');
return !Number.isFinite(checked) || Date.now() - checked > RETRY_AFTER_MS;
}
MusicBrainzのWeb Serviceは、通常の利用でIPアドレス当たり平均1リクエスト／秒に抑えるルールがある。そのため、このサイトでもリクエストをキューに入れ、約1.1秒の間隔を空けた。Discogs IDを使えるものはまとめて照合し、無駄なアクセスを減らしている。
AIに「画像が出ない原因を直して」と頼むだけでは、画像URLを別のURLに差し替える修正で終わる可能性がある。今回は、照合件数、IDの経路、API制限、失敗キャッシュまで原因を分解したことで、ようやく再発しにくい仕組みになった。
罠2：「詳細を隠す」ボタンを置いただけでは隠れない
右側には、選択中のアルバム情報を表示する詳細パネルがある。
最初の画面では、このパネルが常に横幅を使っていた。そこで表示／非表示ボタンを追加したが、最初の実装は期待どおりに動かなかった。
原因は、詳細パネルの状態が一つではなかったことだ。
- パネルそのものを開く状態
- 画面全体を3列から2列へ変える状態
- PCでは横に配置し、狭い画面では右から重ねて出す状態
- ボタンの文言と
aria-expanded
単にdisplay: noneを切り替えるだけでは、空いた列が残ったり、スマートフォン側の表示と食い違ったりする。
そこで「詳細が表示中か」を一つの状態に集約した。
function setDetailPanelVisible(visible) {
detailPanelVisible = visible;
appShell.classList.toggle('detail-collapsed', !visible);
detailPanel.classList.toggle('open', visible);
detailPanel.setAttribute('aria-hidden', String(!visible));
detailToggle.setAttribute('aria-expanded', String(visible));
detailToggleLabel.textContent = visible ? '詳細を隠す' : '詳細を表示';
}
PCでは3列目を0にして中央の可視化領域を広げ、狭い画面ではオーバーレイとして開閉する。
この問題から、UIの状態は見た目だけでなく、レイアウト、操作、アクセシビリティを一緒に切り替える必要があると分かった。
罠3：線は見えているのにクリックできない
作品間の関係線はSVGで描画した。
細い線をそのままクリックするのは難しいので、見える線とは別に、透明で太いクリック領域を重ねていた。仕組みとしては正しいはずだったが、線を押しても反応しない。
原因はレイヤーの順番だった。
SVGの線より上に、アルバムを配置する透明なnode-layerが全面に広がっていた。その透明な要素がクリックを受け止め、下のSVGまでイベントが届かなかった。
修正は短い。
.node-layer {
pointer-events: none;
}
.album-node,
.album-dot {
pointer-events: auto;
}
レイヤー全体はクリックを通し、実際のジャケットと点だけがクリックを受け取るようにした。さらに線側には太さ18pxの透明なヒット領域を持たせ、キーボードのEnter／Spaceでも詳細を開けるようにした。
.edge-hit {
stroke: transparent;
stroke-width: 18;
pointer-events: stroke;
cursor: pointer;
}
「見えているのに触れない」という不具合は、JavaScriptのイベント処理ではなくCSSが原因だった。
罠4：年代フォーカスが、ただの絞り込みになった
年代ボタンを追加した最初の実装では、「1990s」を選ぶと1990年代以外の作品を非表示にしていた。
機能としてはフィルターだが、欲しかったのはフォーカスだった。
1980年代から1990年代へ渡る線や、1990年代から2000年代へ続く流れまで消えてしまうと、音楽地図としての文脈が失われる。特定の年代を詳しく見たいのであって、他の時代が存在しなかったことにしたいわけではない。
そこで、年代によって横軸の縮尺を変えることにした。
選択年代より前：圧縮表示
選択した10年間：大きく拡大
選択年代より後：圧縮表示
実装では、年を単純な等間隔のX座標へ変換せず、フォーカス範囲の内外でpx/yearを切り替える。
function xForYear(year, dimensions) {
if (year < dimensions.focusStart) {
return (year - minYear) * dimensions.contextPxPerYear;
}
const before =
(dimensions.focusStart - minYear) * dimensions.contextPxPerYear;
if (year <= dimensions.focusEnd) {
return before +
(year - dimensions.focusStart) * dimensions.focusPxPerYear;
}
return before +
(dimensions.focusEnd - dimensions.focusStart) * dimensions.focusPxPerYear +
(year - dimensions.focusEnd) * dimensions.contextPxPerYear;
}
これで、注目年代は詳しく見えつつ、その前後の作品と関係線も残るようになった。
データを絞ることと、視線を誘導することは同じではない。
罠5：「影響」だけでは、コレクション同士がつながらない
初期のネットワークには、有名な影響関係を中心に線を入れていた。
しかし画面を眺めると、2000年以降へ伸びる線が少ない。ジャズにも、知っているはずの関係が表示されていない。
ここで、私からAIへの問いが変わった。
「もっと線を増やして」
ではなく、
「Jazzなら、バンドメンバーとして参加している関係もあるのでは？」
「2000年以降にまったく線がつながっていないのは違和感がある」
と伝えた。
調べ直すと、音楽のつながりは「AがBに影響を与えた」という一方向の関係だけでは表現できないことが分かった。
そこで関係を次の種類へ広げた。
- 音楽的影響
- バンドやグループの直接的な系譜
- メンバー在籍
- レコーディングへの演奏参加
- 共通メンバー
- 共同制作
- プロデュース
- カバー／再解釈
- トリビュートや明示的な参照
現在は75本の関係データを収録している。各線には、関係の種類、説明、情報源、信頼度、結びつきの強さを持たせた。線をクリックすると右側のパネルで「なぜこの2枚がつながっているのか」を確認できる。
ここでもAIは便利だった。人名や参加作品を広く洗い出し、候補を整理する速度は速い。一方で、AIが挙げた関係を、そのまま事実として線にすることはできない。
同姓同名、参加年の違い、作品単位とアーティスト単位の混同、「影響を受けた」と「似ている」の混同が起きるからだ。
そのため、線には根拠URLを添え、公式サイト、本人インタビュー、信頼できる音楽メディア、クレジット情報などを確認した。確証の強さも同じ線として扱わず、色と数値で区別した。調査内容はリポジトリのSOURCES.mdにもまとめている。
生成AIは調査の入口を大きく広げてくれる。しかし、最後に線を引く責任までAIへ渡してはいけない。
頭の中の地図を、データの地図へ変える
実装上は、横軸が年、縦軸がジャンルという単純な配置だ。
const x = xForYear(firstReleaseYear, dimensions);
const y = genreIndex * laneHeight + laneHeight / 2;
しかし難しかったのは座標計算よりも、何を「年」とし、何を「ジャンル」とし、どこまでを「つながり」と呼ぶかだった。
たとえば手元の盤が2023年の再発盤でも、作品が最初に発表されたのが1971年なら、音楽史の地図では1971年に置きたい。そのためDiscogs CSVの盤の発売年をそのまま使わず、MusicBrainzで初版年を補完した。
ジャンルも完全な正解があるわけではない。複数ジャンルをまたぐ作品を一つのレーンへ置く以上、分類は地図を読むための編集になる。
線についても同じだ。作品同士の直接関係なのか、アーティスト同士の関係をコレクション内の代表作へ割り当てたものなのかを区別しなければ、見た目だけがもっともらしい地図になってしまう。
可視化とは、データをきれいに並べる作業ではなく、「何を同じものとして扱うか」を決める作業なのだと実感した。
GitHub Pagesで公開するために、個人情報を削った
元のDiscogs CSVには、公開表示に不要な管理情報が含まれる可能性がある。購入・登録に関する日付、コンディション、メモなどを、そのまま公開リポジトリへ置く必要はない。
そこで公開版には、表示に必要な加工済みデータだけを収録した。
- Discogs release ID
- アーティスト名
- タイトル
- レーベル
- フォーマット
- 発売年
- 表示用ジャンル
- Discogsへのリンク
静的サイトは配布も運用も簡単だが、ブラウザへ送るデータは誰でも閲覧できる。「画面に表示していないから非公開」にはならない点に注意が必要だった。
公開はGitHubのSettings → Pagesから、mainブランチの/(root)を選択した。GitHub Pagesは、指定したブランチとフォルダへ変更がpushされるとサイトを公開できる。
更新時の基本操作は次のとおり。
git status
git add .
git commit -m "Improve record collection map"
git push origin main
最初の公開時には、GitHub側で先に作られていたREADMEとローカルのREADMEが衝突し、rebaseの途中で止まる場面もあった。さらに更新後、JavaScriptがブラウザキャッシュに残り「直したはずなのに直っていない」ように見えることもあった。
後者には静的ファイルのURLへバージョンを付けた。
<script src="data/collection.js?v=20260808-4"></script>
<script src="data/influences.js?v=20260808-4"></script>
<script src="app.js?v=20260808-4"></script>
地味だが、GitHub Pagesのような静的配信では、最後まで惑わされたポイントだった。
生成AIと作って分かったこと
今回、生成AIが特に役立ったのは次の場面だった。
- 曖昧なアイデアを画面要件へ分解する
- HTML、CSS、JavaScriptの初期実装を作る
- 画面の症状から原因候補を洗い出す
- SVG、レスポンシブUI、キャッシュ処理を改善する
- レコード間の関係候補を広く調査する
- GitHub Pages公開時の手順を整理する
一方で、人間側に残った仕事もはっきりしている。
- 何を作りたいのかを決める
- 実際の画面を見て違和感を持つ
- AIの説明と実装が一致しているか確かめる
- 音楽上の関係に根拠があるか確認する
- どの情報を公開してよいか判断する
AIは、こちらが言葉にしていない違和感までは直せない。
最初の年代フォーカスが「他を消すだけ」になったのも、仕様としては間違いではなかった。「フォーカス」という言葉から、私が期待していた見え方まで共有できていなかっただけだ。
しかし、画面を見て「違う」と言えれば、その違和感をAIと一緒に分解できる。
今回の制作で、AIへの指示は最初から完璧でなくてもよいと感じた。重要なのは、出てきたものを観察し、具体的な違和感を返し続けることだった。
可視化して見えてきたのは、所有枚数ではなく聴き方だった
完成した地図を眺めると、単純なジャンル別枚数とは違うものが見えてきた。
ロックが何枚、ソウルが何枚という集計だけではなく、古い作品が後年のヒップホップやR&Bへどうつながっているか、ジャンルをまたぐハブがどこにあるかが目に入る。
そして、線が少ない場所も情報になる。
本当に関係がないのか。自分がまだ調べていないだけなのか。あるいは、その年代の作品を点として買っていて、系譜として追えていないのか。
「線がないのはおかしい」という感覚から調査が始まり、新しい参加ミュージシャンや制作関係を知ることもあった。つまり、このサイトは完成したコレクションを表示するだけではなく、次に何を調べ、何を聴くかを考える装置にもなった。
頭の中にあった地図を外へ出したことで、逆に頭の中の空白が見えるようになった。
これは、作る前には想像していなかった一番面白い結果だった。
今後の課題と展望
この地図は完成したように見えるが、実際にはまだ「調査途中の地図」でもある。
現在登録している関係は75本あるものの、613枚のコレクション全体から見れば一部にすぎない。線がない作品も、本当に孤立しているとは限らない。参加ミュージシャン、プロデューサー、サンプリング、カバー、レーベルまで調べれば、まだ見えていない関係が現れる可能性がある。
今後は、内容と技術の両面から改善していきたい。
1. ブラウザでの照合から、事前生成方式へ移行する
現在はブラウザからMusicBrainzとCover Art Archiveへアクセスし、取得結果をlocalStorageへ保存している。
この方法は静的サイトだけで完結する一方、別の端末で開くと照合をやり直す必要がある。また、APIのレート制限、通信失敗、キャッシュの不整合によって、利用者ごとに表示結果が変わる可能性もある。
将来的には、公開前にデータを生成する方式へ移行したい。
Discogs CSV
↓
データ変換スクリプト
↓
MusicBrainzで初版年とMBIDを照合
↓
Cover Art Archiveの画像URLを取得
↓
collection.generated.jsを生成
↓
GitHub Pagesへ公開
APIへの問い合わせをブラウザではなく事前処理へ移せば、公開サイトは生成済みのデータを読むだけになる。表示速度が安定し、APIへの重複アクセスも減らせる。
GitHub Actionsを使って、コレクションデータを更新したときだけ生成処理を実行する構成も考えられる。
2. 関係データを検証できる仕組みを作る
現在の関係データには、接続元、接続先、関係種別、信頼度、説明、出典URLなどを持たせている。
{
id: 'inf-019',
from: {
artist: 'Joy Division',
title: 'Unknown Pleasures'
},
to: {
artist: 'New Order',
title: 'Movement'
},
kind: 'lineage',
reliability: 0.98,
strength: 5.0,
source: {
publisher: 'Rock & Roll Hall of Fame',
url: 'https://...'
}
}
関係数が増えると、作品名の表記揺れ、存在しない接続先、IDの重複、出典URLの欠落などが起きやすくなる。
そのため、データ追加時に次を自動検査する仕組みが必要になる。
-
idが重複していないか - 接続元と接続先がコレクション内に存在するか
- 関係種別が定義済みの値か
- 信頼度が0〜1の範囲か
- 強さが1〜5の範囲か
- 出典URLが設定されているか
- 同じ関係が重複登録されていないか
JSON Schemaや簡単なNode.jsスクリプトで検証し、問題があれば公開前に処理を止めるようにしたい。
3. 「アーティストの関係」と「アルバムの関係」を分離する
現在の線には、アルバム同士の直接関係と、アーティスト同士の関係を代表アルバムへ割り当てたものが混在している。
たとえば、Joy DivisionからNew Orderへの線は直接的な系譜として説明しやすい。一方、「あるアーティストが別のアーティストに影響を与えた」という情報を、コレクション内の特定アルバム同士へ割り当てている場合もある。
今後はデータ構造を分けたい。
Artist
├─ Album
├─ Album
└─ Album
Artist ── influence ──> Artist
Album ── personnel ──> Album
Album ── sample ─────> Album
Artist ── member ─────> Group
内部的にアーティストとアルバムを別ノードとして扱い、表示時に必要な関係だけをアルバムへ投影すれば、「この線は作品そのものの関係か、アーティスト単位の関係か」をより正確に伝えられる。
これは、単なる配列データから小さな知識グラフへ発展させるための重要な変更になる。
4. 線が増えても読める表示方法を考える
関係線を増やすほど情報は豊かになるが、線が交差して読みにくくなる。
現在はSVGのベジェ曲線で一本ずつ描いているが、今後は次の方法を検討したい。
- 関係種別による表示フィルター
- 選択作品に関係する線だけを強調
- 近い経路をまとめるエッジバンドリング
- 同じ年代・ジャンル内での重なり回避
- ズーム率に応じて表示量を変えるLevel of Detail
- 線が多い場所を集約表示し、クリック時に展開する
作品数がさらに増えた場合は、すべてをDOM要素として描く方法にも限界が来る。SVGの操作性を残しながら、一部をCanvasやWebGLへ移す選択肢もある。
ただし、高速化のために線の意味が読めなくなれば本末転倒である。描画性能だけでなく、「なぜつながっているかを確認できること」を優先したい。
5. 自動テストと表示確認を追加する
今回の不具合には、実際にブラウザで操作しなければ見つけにくいものが多かった。
- 詳細ボタンを押してもレイアウトが変わらない
- 透明なレイヤーが線のクリックを妨げる
- 画面幅によって詳細パネルが戻らない
- 年代フォーカスで前後の文脈が消える
- キャッシュによって古い処理が残る
今後は、最低限の操作を自動テストへ追加したい。
アルバムを選択
↓
詳細パネルが開く
↓
「詳細を隠す」を押す
↓
中央の表示領域が広がる
↓
再表示後も選択内容が残っている
Playwrightなどを使えば、PC幅とスマートフォン幅の両方で操作を確認できる。完成画面のスクリーンショットを保存し、変更前後の差分を検出するビジュアルリグレッションテストも役立ちそうだ。
6. 「発売年」と「自分が知った時期」を重ねる
技術的な改善の先で、特に試してみたいのが二つの時間軸の比較である。
発売年の地図では、音楽史の流れが見える。一方、Discogsへの登録日や購入時期を使えば、私自身がどの順番で音楽を知ったかを可視化できる。
作品の時間：その音楽が発表された年
自分の時間：その音楽がコレクションへ加わった年
たとえば、1990年代のヒップホップを入口に1970年代のソウルへ進んだのか。現代ジャズから過去の作品へ戻ったのか。
二つの時間軸を切り替えられるようにすれば、「音楽の歴史」と「自分が音楽を発見した歴史」の違いが見えるはずだ。
線がない場所は、次に調べるべき場所でもある
可視化して初めて気づいたのは、線が多い場所だけでなく、線がない場所にも意味があるということだった。
線がないのは、関係が存在しないからなのか。まだ調査できていないからなのか。それとも、自分がその作品を他の音楽と結びつけず、単独で購入してきたからなのか。
将来的には、接続の少ない作品を自動的に抽出し、MusicBrainzの人物クレジットや信頼できる資料から、関係候補を提示する機能も考えられる。
接続が少ない作品を検出
↓
参加人物・制作クレジットを取得
↓
コレクション内の同一人物を検索
↓
関係候補と根拠を提示
↓
人間が確認して採用
ここで重要なのは、AIが自動的に線を確定するのではなく、根拠付きの候補を提示し、人間が採用を判断することだ。
人気作品を薦める一般的なレコメンドではなく、自分のコレクションにある空白を埋める一枚を提案する仕組みへ発展させられるかもしれない。
コレクションは、個人の小さな知識グラフになる
今回の試みはレコードを対象にしたが、同じデータ構造は本、映画、写真、ゲームなどにも応用できる。
作品、人物、年代、ジャンル、影響、参加関係、出典をそれぞれノードとエッジとして扱えば、所有物の一覧は個人の興味や経験を記録した知識グラフへ変わる。
生成AIによって、関係候補の調査や分類、画面の実装までのハードルは大きく下がった。一方、どの関係に意味を感じ、どの線を残すかを決めるのは人間である。
次に作りたいのは、単に線が増えた地図ではない。
データを更新するたびに検証され、眺めるたびに新しい疑問が生まれ、次に調べるものや聴くものが見つかる、成長し続けるコレクションの地図である。
まとめ
613枚のレコードを可視化する作業は、データを並べれば終わると思っていた。
実際には、ジャケットをどこまで見せるか、初版年をどう決めるか、音楽上のつながりを何と定義するか、根拠の強さをどう伝えるかという、編集と判断の連続だった。
そして生成AIは、その判断を代行する存在ではなく、違和感を実装へ変換するための共同作業者だった。
今回の5つの罠を、最後にまとめる。
- アートワークが出ないときは、照合方法と失敗キャッシュの両方を疑う
- UIの開閉状態は、表示・レイアウト・アクセシビリティを一か所で管理する
- SVGがクリックできないときは、透明な上位レイヤーを確認する
- フォーカスでは他のデータを消さず、文脈を残したまま拡大する
- 「影響」だけでなく、参加・共同制作・系譜まで見ないと音楽の地図はつながらない
もし手元に、長年ためてきた本、映画、写真、ゲーム、あるいはコードのコレクションがあるなら、一覧とは違う軸で並べてみると面白いかもしれない。
そこには、所有物の情報だけでなく、自分が何に惹かれ、どこからどこへ移動してきたのかが残っている。
データを可視化することは、ときどき自分自身を可視化することでもある。