同じ結果を再び得るには、コードを残すだけでは足りない。どの入力、どの版、どの評価規則でその結果に至ったかも保つ必要がある。
ある報告に、40問すべてが期待と一致したと書かれている。
しかし数か月後に同じ作業へ戻るとき、その数値だけでは足りない。問いが変わっているかもしれない。期待する答えが書き直されているかもしれない。新しい版のエンジンが、以前の問いに別の経路で答えているかもしれない。
同じ数値を再び見ることと、同じ結果を再び得ることの間には距離がある。
前の文章では、実験結果を公開するとき、読者がその実験を再検討できる道を残すことを考えた。ERMの既存の検証記録は、その道をどう作れるかという具体例になる。
ここで新たな実行の結果を報告するわけではない。2026年10月6日付の記録を開き、再現可能性のために何が保たれているかを見る。
まず、どのERMかを定める
この文章が扱うのは、ERM v0.12の関係的記憶の試作だ。
この試作は、特定の出来事の関係構造と、その同じ出来事について記録された明示的な言明を一緒に評価する。例えば、一時的な利用の構造を支える関係がある一方で、同じ受け渡しについて返却を前提とする利用ではないと述べる記録がある場合だ。
その場合、システムは両方の根拠を示し、矛盾を報告する。
この研究の系統は、RGM／関係空間H1aの検索実験とは別のものだ。両者の文書や結果を同じ再現記録に入れると、どの仕組みを検証したのかが曖昧になる。
だから、最初の記録は実行コマンドより前に来る。どの版の、どの問いを、もう一度調べているのか。
古い問いを保ち、新しい問いを分ける
新しい機能を加えるとき、二つのことを知りたい。
以前の動作は保たれているか。新しい機能は、そのために用意した状況でどう動くか。
この二つを一つの結果件数にまとめるのは簡単だ。しかしそうすると、改善や退行がどこから生じたのかをたどりにくくなる。
ERMの10月6日の記録では、以前の問いと反例の入力を変更せずに保っている。新しい統合的な意味の問い合わせのシナリオは、別のファイルに置かれている。
| 確認のグループ | 記録が報告する結果 |
|---|---|
| 以前の40問 | 40/40が一致。以前の詳細な答えと証拠を保持 |
| 以前の反例に対する36件の問い合わせ | 36/36が一致。以前の詳細な答えと証拠を保持 |
| 新しい20シナリオの段階別25判断 | 25/25が期待する判断と一致 |
これらは別々の確認グループだ。合算して一つの総合成功率にすれば、何を検証したのかが伝わりにくくなる。
新しいシナリオでは、同じ枠組み内の相反する言明、別の時刻や対象物に関する記録、曖昧な受け渡しへの参照、出典の変更をそれぞれ扱っている。
こうして、以前の試験の保持と、新しい動作の検証を分けて読めるようにしている。
ファイル名が同じなら、中身も同じか
同じ名前でファイルを残しても、同じ入力を保ったとは限らない。
中の一つの関係、期待ラベル、評価規則が変わっているかもしれない。結果が同じに見えても、すでに別の検証について話している可能性がある。
そのためプロトコルは、最終実行の前にエンジンのソースと四つのJSON入力をSHA-256のファイル要約値で固定する。ファイルが変われば、新しい試験の版が必要になる。
この文章を準備する際、現存する四つの入力ファイルの要約値を固定記録と照合し、一致を確認した。これはファイルの完全性の確認だけだ。エンジンを再実行したわけでも、結果を独立に検証したわけでもない。
ファイルの要約値は、中身が正しいとは教えてくれない。どの内容を使ったかを識別する助けになる。
再現記録では、この区別が重要だ。まず、同じ部品を調べているのかを知る必要がある。
同じラベルの背後にある根拠
問い合わせが再びconflictingを返せば、それで十分だろうか。
結果のラベルは同じでも、別の出来事の関係を使ったのかもしれない。取り下げた出典を、まだ根拠として数えているのかもしれない。現在のリビジョンにはない記録に、答えが依存しているのかもしれない。
だからERMのプロトコルは、最後のラベルだけを見ていない。
判断に含まれる証拠は、現在のリビジョンと、見える出典コンテキストに属していなければならない。構造の説明は問い合わせ対象の受け渡しを含み、必要な前提には有効な出典の裏付けがなければならない。
各段階で、問い合わせ前後の永続状態も比較する。読み取りで記憶を変更しないことが求められる。保存して再読み込みした状態で、同じ詳細な答えが得られるかも別途確認する。
こうして、再現の問いが広がる。
同じ答えを得たのか。そして、同じ根拠から同じ答えを得たのか。
これは出典の取り下げやリビジョンの変更で、とりわけ重要になる。以前は裏付けられた結果が、その裏付けを失った後も古い答えを保っているだけで、再び成功と数えられてはいけない。
期待する答えは、誰が書いたか
記録の一致を読むとき、もう一つ問う必要がある。期待はどこから来たのか。
新しいシナリオの期待する判断は、開発者が書いている。エンジンの出力から計算したものではない。期待ラベルを変えてもエンジンの答えが変わらないことも、プロトコルは確認する。
これは、評価用のラベルが答えを直接決めることを防ぐための確認だ。
ただし、独立した人による評価を提供するものではない。
関係と意味のつながりは手で定義されている。この試作は自然言語の語りを読んで、構造全体を自ら抽出するわけではない。現在の意味の橋渡しも、明示的に定めた狭い関係に基づく。
そのため報告では、合成的な技術プロトコルの通過と、人による意味の検証を別の状態として保持している。
後者は、今もhuman_meaning_validated=falseと記録されている。人の評価フォームの判断欄と理由欄は空白のままだ。
その空白は、報告の書きかけの一文に見えるかもしれない。実際には、どの証拠がまだ存在しないのかを明確に示している。
戻ることのできる記録を残す
10月6日の報告は、348件のエンジンテスト、16件のプロトコルテスト、127件の技術的確認を通過したとも述べている。それぞれが異なる責任を確認しており、研究の範囲から独立した正しさの保証にはならない。
この記録ができることは、より具体的だ。保持した入力のもとで以前の動作を比較し、定義されたシナリオで新機能の答えを調べ、その答えの出典をたどること。
別の環境で再実行するなら、その実行自身の記録も必要になる。使った版、環境、コマンド、入力、完了状態、以前の結果と異なる点は、別に書き留めるべきだ。
違いが出たとき、「再現できなかった」とだけ書いて終えるのでは十分ではない。入力、環境、実装、評価規則のどこから違いが生じたのかを、まず調べる必要がある。
研究記録に私が求めるのは、そのように戻ることを可能にすることだ。
数か月後に報告を開いたとき、いくつの確認に通ったかだけでなく、どの問いにどの部品で答えを探したかも読めるようにしたい。同じ作業を再び実行することが、それを再び理解する道にもなり得る。
出典について — 2026年10月18日：ERMの関係的記憶v0.12の文書と、10月6日付のパターンと言明の整合性v0.4のプロトコル、比較、固定、ファイル監査記録に基づく。現存する四つの入力ファイルのSHA-256値を固定記録と照合した。この文章のためにエンジンテストや再現実行は行っておらず、独立した人による評価も行っていない。
つながり
ERM v0.12の関係的記憶試作の10月6日付の入力保持、証拠、再読み込み、検証記録を、RGM/H1aとは分けて考える。
実験結果を再検討する道を残す問いを、ERMの既存の再現可能性の記録で具体化する。