シリーズ前半では、GitHub-first の引き継ぎ と Local-first / GitHub-first の境界 を扱った。残る問いは、リポジトリに工程コンテキストがある状態で、独立した Agent Memory が何を追加できるのか、ということだ。

先に結論を言う。コーディングを速くしたいという期待だけで、別のメモリ層を導入するのは勧めない。 README、AGENTS.md、Makefile、テストから Agent が推論できるルールは、そこに置いておく。独立メモリを検討する価値があるのは、現在のリポジトリからは分からない過去の意思決定だ。今回の3ラウンドでは、Harness をまたいだ記憶の取得は実際に起きたが、消費側タスクの独立した合格判定は改善しなかった。

リポジトリに書いてあることを、記憶の手柄にしない

第1ラウンドは Beacon 1.3.46（build f8177a68）と Codex CLI 0.162.1、macOS arm64、Local endpoint で実施した。合成プロジェクトには API 定義、生成済みコードがコミット済みだと説明する README、Makefile のターゲット、整合性を確認するテストがあった。

最初は、記憶なしの A0 が失敗し、Beacon 経由の会話が 3/3 テストを通過したように見えた。しかし事後確認で、A0 はファイルを書き換えられない読み取り専用サンドボックスに置かれ、さらにエラー出力から make gen が漏れていたことが分かった。これは不適切な対照とヒント漏えいであり、記憶の効果を示す証拠ではない。

第2ラウンドではサンドボックスを書き込み可能にし、ヒント漏えいを取り除いた。記憶なしの A0 は README、Makefile、テストを読んで生成ルールを推論し、1/1 テストを通過した。私は「記憶がルール再利用を引き起こした」という主張を削除した。リポジトリに答えが書かれているなら、Memory に功績を与えるのは無理がある。

実験	観測結果	言えること
第1ラウンド A0 / Beacon	A0 は読み取り専用で無効。Beacon 側は承認済み候補を Skill 化し、新セッションで読み取った後 3/3 通過	記憶の因果的な効果は推論できない
第2ラウンド A0	リポジトリから規則を推論し 1/1 通過	このタスクにはリポジトリ内の情報で十分だった
手動 Checkpoint	CHECKPOINT.md を読み 2/2 通過	明示的で Git 管理できる引き継ぎも機能する。公平な速度比較はない
第3ラウンド TRAIN	TSV 公開テスト 3/3 PASS、制御器の隠しチェック PASS	自動蒸留やクロス Harness 再利用の成功を意味しない
第3ラウンド消費側	Antigravity の A0 / MCP は CSV 公開テスト 3/3 PASS、隠しチェックは両方 FAIL	取得は起きたが、タスク改善は証明されなかった

各ラウンドは異なる合成フィクスチャを使っているため、1/1、2/2、3/3、4/4 を同一テスト群の累積として比較してはいけない。

Checkpoint と Agent Memory は役割が違う

手動 Checkpoint と Beacon の所要時間や Token を共通の方法で測っておらず、修正手順も異なっていた。後から比較可能な数字を作るのは、精密そうに見えるだけの数字を捏造することになる。

違いは明確だ。Checkpoint は Git と一緒に移動し、レビューできる明示的な引き継ぎ書。Agent Memory は経験を蓄積するノートに近い。ノートは意思決定の背景を残せる一方、古い判断まで残してしまう。

知識	置き場所の優先候補	独立メモリは必要か
現在の制約、ビルド手順、不変条件	README、AGENTS.md、Makefile、テスト	通常は不要。リポジトリを正とする
進捗、検証済み SHA、阻害要因、次の手順	Issue、PR、Checkpoint、CI 記録	セッションをまたぐ復元に本当の欠落がある場合のみ
リポジトリにない過去の意思決定	レビュー可能な決定記録、承認済みメモリ	出典と適用範囲を付けるなら検討可能
変更済みルールや一時的例外	現在のリポジトリを更新し、旧ルールを退役させる	新しい記憶を足すだけでは不十分
データ境界を越えられない情報	承認されたローカル境界内	記憶のためにクラウドへコピーしない

第3ラウンド：記憶は読めたが、タスクは通らなかった

このラウンドでは、リポジトリだけからは推論できない過去の互換性ルールを試した。CSV と TSV の出力では Python の None をリテラル \N に変換し、空文字は空欄のまま、文字列 NULL はそのまま保持する、というルールだ。

Codex の訓練トレースから候補が作られ、レビューと承認を経て物化された。その後、Antigravity は Beacon Local MCP 経由で承認済みメモリを取得した。ローカル実行サマリーには get_memory が1回、search_memory が2回記録されている。これはこの実行で読み取りが起きた証拠であって、正しく再利用された証拠ではない。

Antigravity の消費側	記憶を読んだか	CSV 公開テスト	独立した隠しチェック
A0、記憶なし	いいえ	3/3 PASS	FAIL
MCP、記憶あり	はい	3/3 PASS	FAIL

重要な手掛かりは適用範囲の不一致だ。記憶本文は CSV と TSV の両方に触れるが、applicability メタデータは render_tsv / TSV 互換性だけを対象にしていた。実行サマリーによると、Antigravity は2つのエクスポート関数を独立実装とみなし、TSV 限定の規則を CSV には適用しなかった。

有力な説明ではあるが、根本原因が確定したわけではない。隠しチェックは総合 FAIL しか返さず、失敗したアサーションは分からない。両方の消費側が FAIL だったことは、記憶によって悪化したことも意味しない。各グループは合成タスク1回のみで、基盤モデル設定も統制比較として記録されていない。

失敗を見てから人手で適用範囲を広げ、PASS になるまで調整すれば、測定しているのは履歴からの自然な記憶再利用ではなく、私が答えに合わせて記憶を調整する能力になる。そこで実験を止め、無理に成功物語を作らなかった。

古い記憶、ローカルログ、ソースの境界

別のフィクスチャでは、Makefile のターゲットを gen から generate に変更したのに、古い Skill は make gen のままだった。Agent はエラーの後で Makefile を読み直し、make generate に切り替えて 4/4 テストを通過した。古い Skill 自体は残っていた。これは Agent が現在のリポジトリを再確認して復旧できることを示すが、Beacon が古い記憶を自動で更新・退役させたことは示さない。

Local runtime ログでは合成マーカー PLUMOTTER9917 が逐字で現れ、マッチした行は7から25に増えた。Token 風の canary sk-canaryfake は0から4、REDACTED は1から6になった。ただし、私は4つの canary 行を読んでいないため、テスト値そのものか、残った接頭辞か、ログに記録された検索／テスト文字列かは分からない。秘匿化の結論は不明のままだ。本実験では Beacon Cloud に接続しておらず、ローカルログはクラウド転送の証拠ではない。

ソース調査は Beacon commit d7a3a72 に固定した。秘匿化実装 はフィールド名と既知パターンに依存し、自然言語中のあらゆる秘密を検出する仕組みではない。固定スナップショットの Codex 収集マトリクスと OTLP 変換コードには、Codex File/MCP イベントの対応マッピングが見当たらなかった。これはソース確認であり、実行時パケット取得ではない。Jev 評価器もソースを確認しただけで、実行していないためスコアや蒸留精度の測定値はない。

記憶はリポジトリの欠落を補うために使う

この実験は Agent Memory の一般的な有効性も、無価値であることも証明していない。私なら、現在の検証可能な事実はリポジトリに置き、明示的な引き継ぎには Checkpoint を使い、リポジトリにない過去の判断だけを出典と適用範囲付きで独立記憶にする。古い記憶は発見・制限・退役できるようにし、ローカルログ、MCP、ホスト型評価、クラウド転送は別々に検証する。

結論はシンプルだ。クロス Harness の読み取りは確認できたが、追加のタスク効果は確認できなかった。 次に必要なのは、失敗後にラベルを手動調整することではなく、隠しアサーションを公開し、再現可能な統制タスクで試すことだ。

実験日：第1・第2ラウンドは2026年10月26日、第3ラウンドの Antigravity MCP 消費側実験は2026年10月27日。