🧭 関係性スコアリングの機能要件（Core Functions）
ここでは、
メンバー間の関係性を数値化するための“機能”だけに絞って設計 するね。
① 在籍期間重なり計算（最重要コア）
■ 機能概要
2人のメンバーの在籍期間を比較し、
重なった月数を算出する機能。
■ 入力
- メンバーAの加入日・卒業日
- メンバーBの加入日・卒業日
■ 出力
- 重なり月数
- 正規化スコア（0〜40pt）
■ 役割
- “接触の強さ”を示す最も客観的な指標
- 全関係性スコアの基礎になる
② 師弟関係リンク解析
■ 機能概要
メンバー間の“指導・継承”の関係をデータとして保持し、
直接・間接の師弟リンクをスコア化。
■ 入力
- 師弟関係データ（手動入力 or ルールベース）
■ 出力
- 直接：30pt
- 間接：15pt
- 無関係：0pt
■ 役割
- “文化の継承”を定量化する軸
- 在籍期間が重ならなくても関係性を持てる唯一の軸
③ メンバーカラー距離計算
■ 機能概要
メンバーカラーを色相（0〜360°）に変換し、
色相距離を計算 → 近いほどスコアが高い。
■ 入力
- メンバーAのカラー
- メンバーBのカラー
■ 出力
- 色相差
- 正規化スコア（0〜20pt）
■ 役割
- “キャラ性の近さ”を客観的に扱える
- 色は公式設定なのでデータとして扱いやすい
④ 出身地距離計算
■ 機能概要
都道府県・地方区分を使って、
地域文化の近さをスコア化。
■ 入力
- メンバーAの出身地
- メンバーBの出身地
■ 出力
- 同県：10pt
- 同地方：5pt
- 違う地方：0pt
■ 役割
- “価値観の近さ”を補助的に扱う軸
- データが明確で扱いやすい
🧮 ⑤ 総合スコア計算（100点満点）
■ 機能概要
4つの軸を合算して
メンバー間の関係性スコアを算出。
| 軸 | 配点 |
|---|---|
| 在籍期間重なり | 40 |
| 師弟関係 | 30 |
| メンバーカラー距離 | 20 |
| 出身地距離 | 10 |
→ 総合スコア：0〜100pt
🗺️ ⑥ 関係性マップ生成（機能）
■ 機能概要
スコアを使って
- 2Dマップ
- 3Dマップ
- ネットワークグラフ
を生成する。
■ 出力例
- X軸：在籍期間重なり
- Y軸：師弟関係
- ノード色：メンバーカラー
- ノード位置：文化距離
真也、了解だよ。
ここで必要なのは 「加入期文化」ではなく、“関係性スコアリング専用のデータベース” だね。
つまり、メンバー同士の距離を計算するための“生データ”をどう持つか を固める段階。
僕も鼻でノートをトントンしながら、
スコアリングエンジンに最適化された DB 設計 をまとめてみたよ。
🧭 関係性スコアリング・データベース（Core Schema）
関係性スコアは
- 在籍期間の重なり
- 師弟関係
- メンバーカラー距離
- 出身地距離
この4軸で構成されるから、
DB もこの4軸を“計算可能な形”で保持する必要がある。
1. Members（メンバー基本情報）
関係性計算の“母体”になるテーブル。
| フィールド | 型 | 説明 |
|---|---|---|
| member_id | PK | 固有ID |
| name | text | メンバー名 |
| generation | int | 期 |
| join_date | date | 加入日 |
| leave_date | date/null | 卒業日 |
| color_code | text | #RRGGBB |
| hue | int | 色相（0〜360°） |
| prefecture | text | 都道府県 |
| region | text | 地方（関東/関西など） |
✔ ここが重要
- 在籍期間の重なり → join_date / leave_date
- 色距離 → hue
- 出身地距離 → prefecture / region
全部このテーブルから計算できる。
2. Relationships（師弟関係）
師弟関係は“距離”ではなく“リンク”なので別テーブル。
| フィールド | 型 | 説明 |
|---|---|---|
| rel_id | PK | 固有ID |
| mentor_id | FK | 先輩 |
| mentee_id | FK | 後輩 |
| relation_type | enum | direct / indirect |
| weight | int | 30 / 15 など |
✔ ここが重要
- 在籍期間が重ならなくても関係性を持てる唯一の軸
- direct / indirect を明示的に保持する
3. ScoreCache（スコアキャッシュ）
計算結果を保存して高速化するためのテーブル。
| フィールド | 型 | 説明 |
|---|---|---|
| member_a | FK | メンバーA |
| member_b | FK | メンバーB |
| overlap_score | int | 在籍期間重なり |
| mentor_score | int | 師弟関係 |
| color_score | int | 色距離 |
| birthplace_score | int | 出身地距離 |
| total_score | int | 合計100点 |
✔ ここが重要
- UI で即時表示するためのキャッシュ
- バッチ更新 or 初回アクセス時に計算
4. Rules（任意：スコアリングルール）
スコアの重みを外部化しておくと、後で調整しやすい。
| フィールド | 型 | 説明 |
|---|---|---|
| rule_name | text | overlap / mentor / color / birthplace |
| weight | int | 配点（例：40 / 30 / 20 / 10） |
🧩 関係性スコア計算ロジック（DBに紐づく機能）
① 在籍期間重なり
Members.join_date / leave_date を比較
→ 重なり月数 → 0〜40pt に正規化
② 師弟関係
Relationships から weight を取得
→ 0 / 15 / 30pt
③ メンバーカラー距離
Members.hue の差分
→ 0〜20pt に変換
④ 出身地距離
Members.prefecture / region
→ 0 / 5 / 10pt
🗺️ この DB を使うとできること
- メンバー間の文化距離マップ
- 期ごとの文化重心
- 師弟ネットワークグラフ
- 在籍期間重なりヒートマップ
- 後継者ポジション分析
- 時系列での文化変遷
全部この DB から生成できる。
真也、了解だよ。
ここで必要なのは 「関係性スコアリングエンジンに投入する“生データ”の入力ルール」 だね。
つまり、DB にどんな形式でデータを入れれば、後で正しくスコア計算できるか を定義する段階。
僕も鼻でノートをトントンしながら、
機能 → データ → UI の“データ”部分に特化した入力ルール をまとめてみたよ。
🌊 関係性スコアリング・データ入力ルール（Core Rules）
以下は、
Members / Relationships / Color / 出身地
の4軸を正しく扱うための“入力ルール”だよ。
① 在籍期間データ入力ルール（最重要）
在籍期間の重なりは関係性の基礎だから、
日付の扱いを厳密にする必要がある。
■ 入力形式
| 項目 | 形式 |
|---|---|
| join_date | YYYY-MM-DD |
| leave_date | YYYY-MM-DD or null（現役） |
■ ルール
- 加入日は 公式発表日 を採用
- 卒業日は 卒業公演日 を採用
- 卒業前の活動停止期間は無視（在籍扱い）
- leave_date が null の場合は「今日まで在籍」として扱う
■ 理由
重なり月数を正確に計算するため。
② 師弟関係データ入力ルール
師弟関係は“距離”ではなく“リンク”なので、
明示的に入力する必要がある。
■ 入力形式
| 項目 | 形式 |
|---|---|
| mentor_id | FK |
| mentee_id | FK |
| relation_type | direct / indirect |
| weight | 30 / 15 |
■ direct の基準
- 本人が「○○さんに教わった」と発言
- 公式番組で指導シーンがある
- 歌割り・ダンスで明確な継承がある
■ indirect の基準
- 期をまたいだ影響
- 文化的継承（例：歌唱スタイル）
- 本人談で「影響を受けた」レベル
③ メンバーカラーデータ入力ルール
色は“距離計算”のために 色相（Hue）に変換 する必要がある。
■ 入力形式
| 項目 | 形式 |
|---|---|
| color_code | #RRGGBB |
| hue | 0〜360° |
■ ルール
- color_code は公式カラーをそのまま入力
- hue は RGB → HSV 変換で自動生成
- hue は整数（四捨五入）
④ 出身地データ入力ルール
地域文化の距離を扱うために、
都道府県と地方の両方を持つ必要がある。
■ 入力形式
| 項目 | 形式 |
|---|---|
| prefecture | text（例：東京都） |
| region | enum（関東/関西/中部/九州…） |
■ ルール
- prefecture は公式プロフィールに準拠
- region は固定リストから選択
- 海外出身者は region=“海外”
⑤ ScoreCache の入力ルール
これは自動生成されるので、
手動入力はしない。
■ 自動入力項目
- overlap_score
- mentor_score
- color_score
- birthplace_score
- total_score
🧭 データ入力のワークフロー
- Members に基本情報を登録
- color_code → hue を自動変換
- 出身地 → region を自動分類
- Relationships に師弟関係を登録
- スコアリングエンジンが ScoreCache を生成
真也、了解だよ。
ここは 「関係性スコアリングの結果をどう“マップ”として可視化するか」 を決める段階だね。
機能 → データ と固めてきたから、次は UI ではなく “形式（フォーマット）” の設計 に集中するよ。
僕の鼻でノートをトントンしながら、
関係性スコアをどう表現すれば一番“文化の地形”が見えるか を整理してみたよ。
🌊 関係性スコアリングマップの形式（Core Formats）
ここでは、
関係性スコア（在籍重なり・師弟・カラー・出身地）をどう可視化するか
という“形式”だけを定義するね。
① 2Dマップ形式（最も基本）
2軸で文化距離を表現する形式。
■ 軸の例
- X軸：在籍期間の重なり（接触の強さ）
- Y軸：師弟関係（文化継承の強さ）
■ 表現
- ノード：メンバー
- ノード色：メンバーカラー
- ノード形状：期
- ノードの距離：文化距離
■ 何が見える？
- 5期と6期の“文化的近さ”
- 10期の“分散性”
- 7期の“孤立点”
② 3Dマップ形式（構造を立体で見たい場合）
3軸で文化を立体化する形式。
■ 軸の例
- X：在籍期間重なり
- Y：師弟関係
- Z：メンバーカラー距離
■ 表現
- ノード位置：3D座標
- ノード色：メンバーカラー
- ノードサイズ：在籍期間の長さ
■ 何が見える？
- 6期の“色のまとまり”
- 9期の“文化重心の強さ”
- 12期の“ダンス文化の位置”
③ ネットワークグラフ形式（関係性を線で表現）
スコアを“線の太さ”で表現する形式。
■ 表現
- ノード：メンバー
- エッジ：関係性スコア
- 太さ：スコアの強さ
- 色：関係の種類（在籍/師弟/色/出身地）
■ 何が見える？
- 師弟ネットワークの強さ
- 在籍期間の重なりが強い期の“クラスター”
- 文化的に孤立したメンバー
④ レーダーチャート形式（期ごとの“文化形状”を見る）
期単位で文化の形を比較する形式。
■ 軸
- 在籍重なり
- 師弟関係
- カラー距離
- 出身地距離
■ 何が見える？
- 5期＝安定・継承型
- 6期＝色彩・個性型
- 10期＝多様性・分散型
- 7期＝特異点
⑤ 時系列マップ形式（文化の変遷を見る）
文化がどう変化したかを“時間軸”で見る形式。
■ 表現
- X軸：年
- Y軸：文化重心（総合スコア）
- 線：期ごとの文化の流れ
■ 何が見える？
- 5期→6期→9期の“文化の継承ライン”
- 10期以降の“多様化”
- 7期の“単独点”
🧭 最終的に採用すべき形式（結論）
真也のプロジェクトの目的が
「関係性を数値化して文化の地形を可視化する」
なら、最適な形式はこの3つ。
✔ 1. 2Dマップ（基礎）
→ 文化距離の“平面構造”が見える
✔ 2. ネットワークグラフ（関係性）
→ 師弟・在籍重なりの“線”が見える
✔ 3. レーダーチャート（期の形状）
→ 期ごとの“文化の形”が見える