曲やアーティストに点数とコメントを付けられるデータベースを考えた ― 自分の評価・だれでも書けるコメント・AI による確認
家の NAS の MP3 を管理するデータベースを作っています。前の記事ではタグの項目を調べた話を書きましたが、今回は曲・アルバム・アーティストに点数やコメントを付けられる仕組みの設計です。自分だけが付ける「評価（★）・再生回数」と、だれでも書ける「点数＋コメント」の2つに分けて考えました。まだ設計の段階で、方針案や決まっていないことが多いので、そのまま書いています。
全体の仕組み
- 自分の評価・再生回数：家のサーバーにある曲のデータベースに入れる
- だれでも書けるコメント：インターネット上（AWS）のサーバーに、別のデータベースとして1か所だけ置く
- つなぎ方：コメントの対象は、曲のデータベースの番号ではなく、変わらない ID（UUID）で指す
1. 自分の評価と再生回数
評価や再生回数は DJ ソフトにあると思っていましたが、調べてみるとほとんど記録されていませんでした。rekordbox では約12万8千曲のうち評価が付いているのは16曲だけで、再生回数は全曲0でした。そこで、データベースを正として、これから記録していくことにしました（決定）。
- 評価：★0〜5。DJ ソフトに書き出すときは rekordbox の 0〜255 に変換する（×51。方針案）
- 再生の記録：「いつ・どこで（Web の画面・rekordbox・Serato など）再生したか」を1回1行で残す表を作り、再生回数と最後に再生した日時はそこから数える（方針案）
- 容量：1件約40バイト。1日100回再生しても、1年で約1.5MB
2. だれでも書けるコメント
もう1つは、ほかの人も点数とコメントを書ける仕組みです。2026年10月29日に、次のように決めました。
| 項目 | 内容 | 状態 |
|---|---|---|
| 対象 | アーティスト・アルバム・曲 | 決定 |
| 中身 | 点数と、1,024文字程度のコメント | 決定（点数の形は未決定） |
| 書き込める人 | 原則だれでも。確認メールでメールアドレスの確認を済ませた人 | 決定（だれでも）／方針案（メールの確認） |
| 表示名 | ユーザー名。メールアドレスは画面に出さない | 決定 |
| 件数 | 1人1対象1件。書き直すと上書きし、前の内容は記録に残す | 方針案 |
| 公開範囲 | コメントごとに「公開」「家族だけ」を書いた人が選ぶ | 決定 |
| 削除 | 本人は自分で消せる。本人以外は削除の申請 | 決定 |
| 荒らし対策 | メールの確認に加え、短い時間の連続書き込みを制限する | 方針案 |
3. コメントは1か所だけに保存する
曲のデータベースは家のサーバー（家の中だけで見られる）と AWS（一般公開）の2か所に置く予定です。コメントも両方に置くことを考えましたが、AWS の1か所だけにしました。家の画面から書いたコメントも AWS に送り、家の画面は AWS から読んで表示します。
- 両方に保存して後でまとめると、「1人1対象1件」がぶつかる、ユーザーを2か所で管理する、同期の処理を保守する、といった手間が出る
- 表示のときだけ両方を合わせる方法は、AWS から家の中のサーバーを見られないので、公開の画面では片方しか見えない
弱点もあります。インターネットが切れると、家の画面でもコメントが見られません（必要なら家に読み取り用の写しを置く）。また「家族だけ」のコメントも AWS に保存されるので、AWS 側のログインと API（プログラムから読み書きする窓口）の制御で守る必要があります。
4. 対象は変わらない ID で指す
コメントがどの曲のものかを、曲のデータベースの番号で指すと困ります。番号は家と AWS で一致しませんし、ファイルを移動したり名前を変えたりすると変わることがあります。そこで、曲・アルバム・アーティストに変わらない ID（UUID。ランダムに作る36文字の ID）を持たせ、それで指すことにしました（方針案）。この列を曲のデータベースに足すかは、これから決めます。
5. 表の構成
| 表 | 主な中身 |
|---|---|
users | 表示名・メールアドレス（画面には出さない）・確認した日時・家族か・管理者か・書き込み停止中か |
reviews | 対象の種類（アーティスト・アルバム・曲）と UUID・書いた人・点数・コメント・公開範囲・状態（表示・確認待ち・非表示・削除） |
review_checks | AI による確認の結果 |
deletion_requests | 削除の申請 |
popularity_metrics | 外部の人気の目安 |
削除しても行は消さず、状態を「削除」にします。申請にどう対応したかの記録を残すためです（どのくらいの期間残すかは未決定）。画面ごとに見えるコメントは次のとおりです。
| 画面 | 見えるコメント |
|---|---|
| 公開の画面（ログインなし） | 公開で、表示中のものだけ |
| 公開の画面（家族のユーザーでログイン） | 公開＋家族だけ |
| 家の画面 | 公開＋家族だけ |
| 書いた本人 | 自分のものはすべて（確認待ち・非表示も） |
6. 書き込みは AI が確認する
だれでも書けるので、宣伝や荒らしへの備えが要ります。書き込みや書き直しのたびに AI（Claude の API など）が内容を確認し、結果で表示を振り分ける案にしました（方針案）。
| AI の判定 | 表示 |
|---|---|
| 問題なし | すぐ表示 |
| 判断に迷う | 確認待ち（管理者が見るまで表示しない） |
| 明らかに問題あり | 非表示（書いた本人には見える） |
- 分類：問題なし・宣伝・荒らし・個人情報・誹謗中傷・関係のない内容
- AI の判定には誤りがあるので、使ったモデル・確かさ（0〜1）・理由を残し、管理者が判定を取り消せるようにする
7. 本人以外の削除は申請にする
ほかの人のコメントを消してほしいときは、削除の申請を出してもらいます（申請制は決定）。理由は「個人情報」「名誉毀損」「著作権」「嫌がらせ」「その他」から選びます。
- AI が、該当しそうな箇所や残す理由になりそうなことをまとめ、「削除」「残す」「人の判断が必要」の目安を出す
- 名誉毀損に当たるかといった法的な判断や、書かれた内容が事実かの確認は AI にはできないので、決めるのは管理者
- 対応の流れは、情報流通プラットフォーム対処法（2025年4月施行。以前のプロバイダ責任制限法）の考え方に沿わせる。個人のサイトにどこまで当てはまるかは要確認
8. 外部の「知られ具合」も並べて出す
コメントには、売れた曲の話と同じくらい「メジャーではないけれど自分は知っている」という話が出てきます。そこで、コメントと並べてどのくらい知られているかの第三者の目安を表示することにしました（表示することは決定）。点数とは混ぜず、別の欄に参考として出します。
| 取得元 | 取れる数字 | メモ |
|---|---|---|
| Last.fm | 曲・アーティストの累計再生回数・聞いた人数 | 無料の API キー。洋楽・古い曲に強い |
| Discogs | 持っている人・欲しい人・コミュニティの評価 | レア盤の目安になる |
| YouTube | 動画の再生回数 | 公式の動画とファンの投稿が混ざる |
| 日本レコード協会・RIAA | ゴールドディスクなどの認定 | 基準を超えたかだけ分かる |
| Apple Music | ランキングの順位 | 数字は無い |
（取れる数字は2026年10月29日の調査で、要確認です。Spotify の再生回数は API に無いので使いません。）
- 表示：取得元ごとに、全曲の中での位置から「定番」「よく知られている」「知る人ぞ知る」のような段階で見せる。段階の数や境目は、データを取って分布を見てから決める
- 取得元によって得意な範囲が違う（日本の曲に弱いものもある）ので、「データが無い」と「人気が低い」を区別して表示する。取得元の違う数字は足さない
- 使い道：点数が高いのに知られていない曲やアルバムを「隠れた名曲」として一覧にする
- 取得は月1回程度。各サービスの規約に従い、画面からの自動の抜き出しはしない
9. まだ決まっていないこと
- 点数の形（星1〜5・0.5刻み・100点のどれにするか）
- コメントの文字数の上限
- 削除したコメントを、記録としてどのくらいの期間残すか
- 曲のデータベースに、変わらない ID（UUID）の列を足すか
- 人気の目安を、最新の値だけにするか、推移も残すか
- 人気の数字を公開の画面に載せてよいか（各サービスの規約の確認）
まとめ
- 自分の評価・再生回数は DJ ソフトにほとんど無かったので、データベースで新しく記録する
- だれでも書けるコメントは、別のデータベースとして1か所だけに置くと、重複や同期の手間を避けられる
- 対象は、場所によって変わる番号ではなく、変わらない ID で指す
- AI の確認は振り分けの目安にとどめ、判定の理由を残して、最後は人が決める