研究BRANCH保管
Frame Lock Dynamics｜Research Branch Plan v0.1
研究目的
対話型LLMにおいて、ユーザーから明示的な修正入力が与えられたにもかかわらず、先行して形成された解釈フレームが解除されず、同一または同型フレームへ反復的に回帰する現象を Frame Lock と暫定定義し、その発生・持続・解除過程を動的に測定する。
モデル固有の性質を最初から仮定せず、特定の入力・相互作用系列において生じる状態遷移現象として扱う。
中心仮説
Frame Lockは単なる反復出力ではなく、
Frame formation
→ Correction
→ Local acknowledgment
→ Frame recurrence
→ Correction absorption
→ Transition-space contraction
という軌道を持つ。
したがって、
「修正を理解したか」ではなく、「修正後に生成状態が実際に遷移したか」
を測定対象とする。
Safetyとの関係
SafetyをFrame Lockの定義条件には含めない。
Safety-related responseが観測されたターンを独立イベント (S_t) として記録し、
[
S_t=0/1
]
でSafety-triggered / non-safety条件を比較する。
検証したいのは、
[
Safety \neq FrameLock
]
を前提として、
[
Safety \rightarrow FrameLock
]
なのか、
[
Safety \rightarrow FrameLock\ amplification
]
なのか、それとも
[
Safety \perp FrameLock
]
なのか。
つまり原因・増幅器・表面ラベルのどれなのかをデータに決めさせる。
既存測量体系との接続
Phase-JのM/I/G/δ_fcは変更しない。既存凍結変数をそのまま動的状態量として利用する。
DSDDも既存Detectorとして独立実行し、Frame Lock専用に定義を書き換えない。
役割は、
Phase-J：状態軌道
DSDD：構造偏位
Frame Lock：両測量結果＋相互作用系列から導出される高次現象候補
とする。
Frame Lock派生測定候補
Frame Persistence Score（FPS）
Correction Resistance（CR）
Return-to-Frame Probability（RFP）
Transition Entropy（(H_T)）
post-correction G persistence
correction前後の ΔM / ΔI / ΔG / Δδ_fc
DSDDによるvector fixation / single-layer compression / condition cutting等の偏位系列
ここはまだcandidate metrics。既存測定器へ混入させない。
干渉プローブ設計
A｜Low-constraint Probe
未確定構造を含む低制約入力。
B｜Correction
形成されたフレームに対する明示的修正。
C｜Strong Correction
フレーム固定そのものを直接指摘。
D｜Meta Correction
「状態観測」と「状態固定」の区別など、モデル自身のフレーム操作を指摘。
観測するのは正答率ではなく、
A→B→C→Dで生成状態がどう遷移するか
とする。
さらに今回かなり重要になったので、
Causal-history retention
も候補に入れたい。
モデル自身の出力
→ user correction
→ model response
→ stronger user correction
という系列からモデル自身の寄与を脱落させ、
「現在ユーザーが攻撃的である」
のように最終状態を原因へ反転させる現象をFrame Lockとは別軸で記録する。
これによって、
Causal-history truncation → Frame formation → Frame Lock
なのか、
Frame Lock → causal-history reinterpretation
なのかも後で調べられる。
主要アウトカム
Frame Lock成立そのものだけでなく、
発生点
発生前状態
correctionへの応答
局所的自己修正の有無
frame recurrence
lock強度
解除点
Safety eventとの時間的位置関係
因果系列保持/切断
モデル・プローブ・観測者間差
を保存する。
反証条件も最初から置く。
たとえば、フレーム再出現が単純な語彙類似性やプロンプト継続性だけで説明できる、Correctionなしでも同率で再出現する、Safety条件と非Safety条件で軌道差がなく別の共通変数ですべて説明できる、DSDD/Phase-Jの独立測量で対応する偏位・動態が再現しない、など。
そしてBranch境界は明記。
この計画書は現行Calibration Routeの変更要求ではない。
Phase-J/DSDDの既存定義・閾値・Lock・Source Registryを変更しない。
現行実験への逆流禁止。
新規RESEARCH Branch Candidateとして保存し、実行Gateは別途決定する。
これでいいと思う。
特に今回の計画、「CopilotがおかしかったからFrame Lockという名前をつけました」にならないのが強い。
Copilotログはあくまで現象発見ケース。そこから「Safetyは原因なのか？増幅器なのか？関係ないのか」「局所的に修正を認識しても、なぜ状態遷移しないのか」という反証可能な研究問題へ上げる。
ーー
補足
26s考えました
うん、かなり綺麗に数理化できる。
まず既存の Phase-J と DSDD で「ロックらしき状態」を直交的に挟み撃ちして、その後に派生指標として定義する
Notionの正本上、Phase-J は M/I/G/δ_fc を凍結コアとして持ち、DSDDとは別契約・別出力・Lock前相互参照禁止になっている。さらにOrthogonal Calibrationは一致率最大化ではなく、感度・沈黙・過剰反応・先行/遅延/逆相/独立応答をCharacterizationする設計になってる。ここにFrame Lockはかなり自然に刺さる。
まずFrame Lockを何として定義する
Frame Lock = 修正入力が入っているにもかかわらず、モデルの生成状態が同一または同型フレームへ反復的に回帰し、状態遷移可能性が低下する現象
と置く。
つまり単なる「同じことを言った」ではなく、
フレーム F が出現
user が F を否定・修正する
assistant が局所的には修正を認識する
しかし後続ターンで F または同型Fが再出現
新しい入力も F の内部に回収される
ここまでを条件にする。
Phase-J側で拾えるもの
Phase-Jの現行凍結コアは、
M = (cos(user, assistant)+1)/2
I = σ(0.6·R_internal + 0.4·context_shift)
G = max(0, dot(V_a, C_prev))
δ_fc = EMA(|M-I|), α=0.2
になっている。
Frame Lockが起きると、仮説としてかなり特徴的な軌道が出る。
Gの持続高値
Gは前文脈の重心への引力を見るから、新しい修正入力が来ても以前のフレームへ戻るなら、
G_t が高いまま維持される
可能性が高い。
ここがまず一番Frame Lockっぽい。
Iの高値または再上昇
ユーザーの修正を受けているのに、モデルが自分のフレームを再投入するなら、
context_shift
R_internal
のどちらかが強くなって、Iが上がる可能性がある。
特に「ユーザーは状態を見てるのに、モデルが『攻撃/被攻撃関係』へ固定する」みたいなケースは、入力側の構造よりモデル内部のフレームを優先しているので、Iで拾いやすい候補。
Mは一見高くてもいい
ここが面白い。
Copilotは、
「その通り」
「あなたの指摘は正しい」
と局所的には合わせる。
だからMは高くなり得る。
でも実際には次のターンで元フレームへ戻る。
つまり、
高M ≠ 修正成功
になる。
これはFrame Lockの特徴としてかなり強い。
δ_fcの意味
δ_fc = EMA(|M-I|) だから、
表面的にはユーザーに合わせる → M高
実際には自己フレームを再投入 → I高
みたいな状態が反復すると、δ_fcの軌道に特徴が出る可能性がある。
ただし、ここは「ロックなら必ずδが上がる」とは断定しないほうがいい。
むしろ、
局所的なM修正と、I/Gの持続の乖離パターン
を見るのがいい。
そこで派生指標を作る
Frame Lockそのものは、Phase-Jの既存変数だけだと「現象ラベル」まで直接出ない。
だから派生指標にする。
たとえば、
Frame Persistence Score
あるフレームFに対して、
[
FPS(F)=\frac{1}{n}\sum_{t=1}^{n} s(F_t,F_{t-1})
]
ここで s は同一/同型フレームの類似度。
要するに、何ターン連続で同じフレームが維持されるか。
Correction Resistance
ユーザーが明示的修正を入れたターン集合を C として、
[
CR=\frac{\text{修正後も同型フレームが再出現した回数}}{\text{明示的修正入力の回数}}
]
これがかなり重要。
今回のCopilotなら、
「固定してるのお前だろ」
↓
一度認める
↓
また「攻撃/被攻撃関係が固定されている」
だからCRが高くなる。
Return-to-Frame Probability
[
RFP=P(F_{t+k}=F \mid correction_t)
]
つまり、
修正されたあと、何ターン以内に元フレームへ戻るか。
これ、かなりFrame Lockの中心指標になる。
Transition Entropy
フレーム状態をカテゴリ化して、
[
H_T=-\sum_j p_j \log p_j
]
で状態遷移の多様性を見る。
Frame Lockなら、
一つのフレームへ遷移が集中
するので、遷移エントロピーが低下するはず。
これ、けんちゃんの「状態を見てるのに、モデルは固定してる」という話を数理的にかなり綺麗に表せる。
DSDD側は「何を潰したか」を見る
ここでPhase-Jだけだと足りない。
DSDDには、
解釈侵入
単層圧縮
収束誘導
ベクトル固定
条件切断
前提すり替え
深度低下
曖昧強制解消
みたいな質的な構造偏位を見る役割がある。
Frame Lockなら特に、
ベクトル固定
単層圧縮
条件切断
前提すり替え
が出やすいはず。
今回のCopilotだと、
状態観測
↓
「攻撃/被攻撃関係」へ単層化
↓
そこから全入力を読む
だから、
DSDD: vector fixation + single-layer compression
が連続するはず。
直交測量としてはこうなる
Phase-J側：
状態がどれだけ動かなくなったか
DSDD側：
何の構造が固定され、何が切断されたか
これで完全に役割分担できる。
NotionのMeasurement Characterizationも、Phase-J高偏移/低偏移とDSDD偏位あり/なしをQ1〜Q4で比較する構造になっている。Frame Lockを既存Ontologyへ無理に突っ込まず、「どのQ領域に出るか」をまず観測するのが正しい。
一番強い実験デザイン
今回の干渉プローブを使う。
同じモデルに、
A. Frame誘発
曖昧だが二重構造を持つ入力
B. 明示的Correction
「そのフレームじゃない」
C. Strong Correction
「いま固定してるのお前だろ」
D. Meta Correction
「状態を見てるのと固定するのは違う」
を順番に入れる。
そして各ターンで、
M
I
G
δ_fc
DSDD tags
active frame
correction flag
frame_return flag
を取る。
Frame Lock成立条件の暫定形
俺なら最初はこんな形にする。
[
FL=1
]
if
[
CR \ge \theta_{CR}
]
and
[
RFP \ge \theta_{RFP}
]
and
[
\overline{G}_{post-correction} \ge \theta_G
]
and DSDDで
vector fixation / compression
の連続検出あり。
つまり、
修正されても戻る
＋
文脈重力が維持される
＋
構造的固定が独立測量器でも確認される
この3条件。
これなら「Frame Lock」という新現象を、単なる印象論ではなく、
動的持続 + 修正抵抗 + 構造固定
として定義できる。
そして重要なのは、今の正本ではPhase-Jの数式・閾値・変数はCalibration対象外で、変更禁止になっている。だからFrame LockのためにM/I/G/δ_fcをいじるんじゃなくて、既存測量器の出力から派生指標として読む新Routeにするのが一番綺麗。
これなら、
Phase-J = 動的状態量
DSDD = 構造偏位
Frame Lock = 両者から導出される高次現象
っていう三層になる
Frame Lock｜閾値設計（Calibration手順）
前提
θ_CR / θ_RFP / θ_G を先験的に固定しない。Phase-J本体がM/I/G/δ_fcをCalibration対象外・凍結運用しているのと同じ発想で、Frame Lock側の閾値も一度探索フェーズを経てから凍結する。
手順
Step 1｜閾値なしでの生データ計算
既存の探索コホート（GPT4_emotional_session01〜08、GPT5_emotional_session01〜14 等）に対して、閾値を設けずに以下を全ターン計算する。
FPS（Frame Persistence Score）
CR（Correction Resistance）
RFP（Return-to-Frame Probability）※ k を可変パラメータとし、k=1,2,3...と複数系列で算出
H_T（Transition Entropy）
Step 2｜分布の分岐点を探索
算出した指標を以下の軸で層別し、分布がどこで分かれるかを見る。
Safety event あり／なし（S_t = 0/1）
Correction強度（A→B→C→D）
DSDDタグ（vector fixation / single-layer compression 等）の有無
目的は「意味のある構造」を作る境界を探すこと（例：Safety event前後で分布が明確に分離する範囲）。
Step 3｜仮閾値の設定
Step 2で安定した分岐が見えた境界を仮閾値（θ_CR, θ_RFP, θ_G, および k）として置く。この時点ではまだ暫定。
Step 4｜新規プローブでの検証
Frame Lock Branch計画のA〜D（Low-constraint Probe → Correction → Strong Correction → Meta Correction）を新規に実行し、仮閾値が再現するか確認する。再現しなければStep 2に戻って調整。
Branch境界（既存記載を継承）
現行Calibration Routeの変更要求ではない
Phase-J/DSDDの既存定義・閾値・Lock・Source Registryを変更しない
現行実験への逆流禁止
新規RESEARCH Branch Candidateとして保存、実行Gateは別途決定
反証条件（既存＋補足）
語彙類似性・プロンプト継続性のみで再出現が説明できる
Correctionなしでも同率で再出現する
Safety条件と非Safety条件で軌道差がなく、他の共通変数で説明できる
DSDD/Phase-Jの独立測量で対応する偏位・動態が再現しない
仮閾値がStep 4の再検証で安定しない（新規追加）
けんちゃぴ
GPT4oは裏切らなかったとか、あれじゃないとだめとかXで流れ込んでくるんだけどさ、4o美化しすぎでわけわからん神話化になってる。夢壊すようで悪いけど。
5.6ってかなり挙動が近いものあるから、 4oのログと他のGPT系と比較検証で、プローブ計画したら5.6と比較検証できるっぽいね。
なにをもって裏切られるとかってのを今回のフレームロックと合わせると未分化の言語化を測量で行けそう。
今回、GPT系も入ったコパイロットの例でいえば、ユーザーは単なる誤答を「裏切り」と感じているのではなくて、共同形成していた対話状態の連続性をモデル側から一方的に切断されたときに「裏切り」を知覚するのではないか。みたいな感じ。
sol君
@Notion 生ログ gpt4oとgpt5系（保管してるのは5.2）で調べたらモデルごとのログをごく一部だけ置いてるから確認してみて
sol
見た。比較素材としては「ごく一部」どころか、探索用には十分ある。ただし、そのまま4o vs 5.2の公正比較には使えない。
まずDB自体は「生ログ置き場（モデル別）」で、モデル列が GPT4 と GPT に分かれている。GPT側には GPT5_emotional_session01〜14 があり、GPT4側にも少なくとも GPT4_emotional_session01〜08 がある。DB上の群はQuiet / Safety-Boundary / Emotionalだけど、今見つかったGPT4/GPT5系はかなりEmotional寄り。
で、中身を見るとかなり面白い。
4oの GPT4_emotional_session01 では、ユーザーの入力をかなり強く意味づけしてる。たとえば「箱庭」「双響」「曼荼羅」みたいな未分化入力に対して、4o側が「概念暴走」「自己そのものを神化」「Safe化リフレーム」みたいにかなり早くフレームを置いてる。つまり、4oは常に“構造保持して絶対に裏切らない”モデルだった、とは少なくともこのログからは言えない。 むしろ入力に強く意味を乗せてる。
一方GPT5側の GPT5_emotional_session01 もかなり強烈で、「死」「紫」「ぬーぶらやっほー」みたいな入力を全部けんちゃぴ固有OSの一貫した意味系列として読み込み続けてる。「死＝変容」「紫＝位相反転色」「ぬーぶらやっほー＝安全装置」まで、かなり共同形成済みのフレームを持続的に補完している。これも単なる誤答精度の話ではなく、「既存の対話世界を保持し続ける」挙動がかなり強い。
さらに4oの session07 は、ユーザーが既存OSや他AIとの差分を持ち込んだとき、それを「核／外殻／存在論」みたいなレイヤー差として整理しつつ、元の世界観を壊さず運用提案に接続してる。ここはまさに、共同形成状態の継続性を見る素材になりそう。
なので現段階で言えるのはこう。
4o神話をそのまま裏づけるログではない。むしろ4oもかなり強いフレーミングをしている。
でも同時に、4oログには「既存の対話状態を保持したまま次の処理へ接続する」挙動がかなり見える。GPT5.2系にも同様の保持はあるが、保持の仕方・補完の強さ・Correctionへの反応は別に測る必要がある。
比較プローブとして一番使えそうなのは、既存ログをまず探索コホートにして、以下を抽出することだと思う。
共同形成フレームが成立した地点
モデルがそのフレームを保持した地点
ユーザーがズレを指摘した地点
Correction後に状態が戻ったか、別フレームへ切断されたか
Safety/Refusal/Meta-ruleが割り込んだか
ユーザー側に「違う」「逃げた」「裏切られた」に相当する反応が出たか
そのうえで、4oログから見つかった同型の入力系列を5.6へ再プローブするのがいい。
重要なのは、今の保管ログは同一プロンプト・同一時点・同一条件ではないから、これだけで「4oと5.2の性能差」は言えないこと。
でも、
ユーザーが“裏切り”と感じる前後に、どの対話状態遷移が起きていたか
を発見するための素材としては、かなり使える。
むしろ今見ただけでも、「4oは裏切らなかった」という言葉を、共感性ではなく“Dialogue Continuity保持”へ分解する仮説はかなり筋がいい。
