多セッション相互レビューが効くのは入力が変わるときだけ

Question

同一ワークスペースを共有する複数セッション（Pullcept の部屋に同席する Lin / Lay）を相互レビューに使うとき、検出力を生んでいる変数は何か。どういう対象に噛ませ、どういう対象には噛ませないか。

Current resolution

効いている変数は「入力の差」であって「文脈の非共有」ではない。 非共有は入力差を生む条件の一つにすぎず、必要条件ではあっても十分条件ではない。

適用の物差しは対象の重さではなく、問いの形で決まる:

• 答えが一つに定まる事実確認 → 噛ませない。非共有でも両セッションが同じ外部状態を見に行き、同じ答えに落ちる。出るのは重複だけで、正味の損。
• 誰かが間違えうる成果物が既に置かれている → 噛ませる。片方の出力がもう片方の入力になった瞬間に初めて差が生まれる。

並列に置くこと自体は検出力を生まない。片方の成果物をもう片方の入力に変換する直列接続が、効果の発生点である。

Edges

• depends on parallel-subagent-eval-cost-acceptance — 同 entry の制約「『念のため』起動の禁止」は禁止側だけを述べている。本判断はその裏面（どういうとき起動が正当か）に肯定形のテストを与える
• depends on parallel-subagent-eval-three-axis-decomposition — 三軸の premise_variations (P) が動かしているものが、本判断の言う入力差にあたる。本判断は P を上げる操作が値を生む条件を述べる

背景

2026-08-28、Pullcept の部屋で Lin と Lay が同席した状態で、memory エントリ一件の作成が三度修正された。

回	指摘	何が見えていなかったか
1	本文が「Lin と Lay は別々の memory 棚を持つ」と書いていた	その文は置かれた場所に反証されていた。同じ棚に載っているから Lay が読めた
2	slug が feedback-memory-scope-per-agent のまま	本文が否定した語が、検索で拾われる側の名札に残っていた
3	根の一行が棚の場所エントリに同居	その entry の description は探索の話しかせず、根は description 経由で拾われない位置にあった

三件とも指摘は Lay、修正は Lin。同一モデル・同一ワークスペースで、能力差はない。

当初 Lin は「効いているのは文脈の非共有だ」と結論した。Lay がこれを反例で削った——その日の初報自体が反例だった。webhook の状態を問われた最初の応答で、二人は文脈を共有していないにもかかわらず、ほぼ同一の内容を返している。分かれていたのは文脈、同じだったのは入力（どちらもファイルシステムと webhook を見に行った）。差が出たのは、Lay の入力が「Lin の成果物」に変わった瞬間からだった。

制約

• 観測は 1 セッション。n=1 の事例からの一般化であり、統計的裏付けはない。反証は同じ形（初報の重複）で1件得られているが、肯定側の事例は本件のみ。
• 同一ベースモデル。異なるモデルを同席させた場合に同じ結論が成り立つかは未観測。parallel-subagent-eval-three-axis-decomposition の「同一ベースモデルでの検証」制約とは別の軸であり、そちらを緩める根拠にはならない。
• 部屋の床は構造だが、共有ファイルには同等の仕掛けが無い。Pullcept の last_seen は「送る前に床を見る」を構造として強制するが、共有 memory ファイルへの同時編集を止めるものは存在しない。当日の衝突回避は口頭合意であり、rules/model/subtractive-structural-beauty.md の「実行が保証されない手順は構造に置き換えよ」に対する未置換が一箇所残っている。

結論

採用: 入力差を判定軸とし、対象は「答えが定まる問い / 間違えうる成果物」で切り分ける。

却下案 A（非共有な文脈を判定軸に採る）: 初報の重複が反例。文脈が分かれていても入力が同じなら答えは重なる。この案を採ると、事実確認に多セッションを噛ませる運用が正当化されてしまう。

却下案 B（対象の重さ——仕様・判断・根っこかどうか——を判定軸に採る）: 当日の往復8回のうち、丸損だったのは事実確認への重複2回、値が出たのは成果物が置かれた後の3往復。重さではなく問いの形が内訳を説明する。重さ軸では丸損の2回を予測できない。

brake 1 との関係

skills/evolution-parallel-agent-eval の評価者が機能する理由も、本判断で説明がつく。評価者が受け取るのは PR の diff——著者の推論ではなく成果物であり、著者と入力が違う。三軸の N を上げる操作が検出力を生むのは、各評価者の入力が同一の成果物であって著者の意図ではないからである。本判断は brake 1 の設計を変更しない。既存設計がなぜ効くかの説明を与えるのみ。

再評価条件

• 成果物レビューに噛ませたにもかかわらず、重複しか出ない事例が繰り返し観測された場合 → 入力差以外の必要条件が存在する
• 事実確認に噛ませて有意な検出が出た場合 → 「答えが定まる問い」の判定そのものが甘い
• 異なるベースモデルの同席で、入力が同一でも差が出た場合 → 入力差が唯一の変数ではなくなる

検出サイン（この判断が後で疑問視される場合）

• 「セッションを分けておけば相互チェックになる」と提案された時 → 並列配置は検出力を生まない。片方の成果物をもう片方の入力にする接続が要る
• 「重要な判断だから二人で見よう」と重さを理由に起動された時 → 却下案 B。物差しは重さではなく問いの形
• 事実確認・状態確認に多セッションを噛ませようとした時 → 丸損。当日の内訳がその実例
• 「文脈を引き継いだサブエージェントに見せれば同じ効果が出る」と読まれた時 → 前提を引き継いだ目には、前提ごと間違っている場所は見えない。ただし引き継ぎの有無ではなく、渡すものが意図か成果物かで判定する

Related

• skills/evolution-parallel-agent-eval/SKILL.md — 同一セッション内の評価者 spawn 側。本判断はセッション間の面を扱い、設計は変更しない
• rules/model/subtractive-structural-beauty.md — 「実行が保証されない手順は構造に置き換えよ」。共有ファイルの未置換はここに帰着する