ここは数学OSの「理解の停滞 → 別視点 → 理解回復」という中核ループを成立させるための 最重要インターフェース設計です。
NegotiatorSelector（説得者選択）と ProfileManager（学習者モデル）がどう連携するかを、OSレベルの仕様として完全に設計します。
以下は Roblox Studio でそのまま実装できるレベルで、かつあなたの「制度OS」思想に沿った構造です。
📘 数学OS：NegotiatorSelector × ProfileManager 連携仕様（完全版）
🎯 目的
- 学習者が「理解できない」を選んだ瞬間、
ProfileManager が学習者の状態を提供し、
NegotiatorSelector が最適な説得者を選ぶ - 説得者の効果が出たら、
ProfileManager が学習者の理解スタイルを更新する
つまり、
ProfileManager = 学習者の状態データベース
NegotiatorSelector = 状態に応じて説得者を選ぶ推論エンジン
🧩 1. データの流れ（Data Flow）
[StepRunner]
↓ (理解できない)
[ProfileManager] --(学習者プロファイル)--> [NegotiatorSelector]
↑ ↓
←---------(選ばれた説得者)-------------------
理解できたら：
[StepRunner] --(理解できた + 説得者タイプ)--> [ProfileManager]
🧱 2. NegotiatorSelector が必要とする情報
NegotiatorSelector は ProfileManager から次の情報を受け取る：
① learnerPreferredType
- 学習者が最も理解しやすい説得者タイプ
- 例：Concrete / Diagrammatic / Narrative …
② preferenceScores
- 各タイプの理解成功回数
- 例：{Concrete=3, Diagrammatic=1, Reverse=0, …}
③ history.usedNegotiators
- 過去に使った説得者のログ
- 同じ説得者の連続使用を避けるため
④ history.stepResponses
- どのステップで理解が止まったか
- 壁の種類推定に使う
⑤ currentStep
- 今どの説明ステップにいるか
- ステップごとの「壁の種類」も含む
🧭 3. NegotiatorSelector → ProfileManager の要求（API）
NegotiatorSelector は ProfileManager に次の関数を要求する：
■ getPreferredType(profile)
学習者の理解スタイルを返す。
■ getHistory(profile)
過去の説得者や反応を返す。
■ getPreferenceScores(profile)
各タイプのスコアを返す。
■ recordHistory(profile, stepId, response, negotiatorType)
理解できた/できないを記録。
■ updatePreference(profile, negotiatorType)
理解が回復したときに preference を更新。
🧠 4. NegotiatorSelector の内部処理（ProfileManager 連携版）
Step 1：壁の種類を推定（DetectWall）
- currentStep の内容
- learnerFeedback
- history.stepResponses
から壁の種類を推定。
Step 2：候補説得者を抽出（FilterCandidates）
- Negotiators フォルダから
trigger に WallType を含むものを抽出
Step 3：スコアリング（Scoring）
ProfileManager から得た情報を使ってスコアをつける：
| 条件 | 加点 |
|---|---|
| negotiator.type == learnerPreferredType | +1 |
| negotiator.id not in history.usedNegotiators | +2 |
| negotiator.tags contains currentStep.topic | +2 |
| preferenceScores[negotiator.type] が低い | +1（多様性確保） |
| ランダム性 | +0〜1 |
Step 4：最適説得者を返す（PickBestNegotiator）
🔁 5. 理解できたときの連携（Feedback Loop）
学習者が「理解できた」を選んだ瞬間：
StepRunner → ProfileManager.updatePreference(negotiatorType)
さらに：
StepRunner → ProfileManager.recordHistory(stepId, "understood", negotiatorType)
これにより：
- preference が更新され
- growth.timeline に記録され
- 次回の NegotiatorSelector の精度が上がる
🗂 6. Studio でのフォルダ構成（連携を前提にした構造）
MathOS
├─ LearnerModel
│ ├─ ProfileManager
│ ├─ LearnerProfileTemplate
│ └─ DataStoreAdapter
│
├─ Negotiators
│ ├─ Concrete
│ ├─ Diagrammatic
│ ├─ Reverse
│ ├─ Abstract
│ ├─ Counterexample
│ └─ Narrative
│
├─ Protocol
│ ├─ NegotiatorSelector
│ ├─ StateMachine
│ └─ StepRunner
│
└─ Problems
NegotiatorSelector は
ProfileManager を require して情報を取得する。
🌱 7. あなたの思想との一致
この連携仕様は、あなたの思想を完全に反映している：
- 理解の停滞を状態として扱う（S1）
- 別視点を制度化する（Negotiator Modules）
- 学習者の成長を時系列で追跡する（growth.timeline）
- 制度同士が連携して学習を進める（Selector × ProfileManager）
- OSが学習者の“制度的プロファイル”を構築する
数学OSの「制度としての学習」がここで完成する。
次に進むなら…
- DetectWall（理解の壁分類器）を設計する
- NegotiatorSelector のスコアリング式を最適化する
- StepRunner の UI/UX を設計する
- 彩色数問題をこのプロトコルで実際に流すデモを作る
どれに進みますか。