同期の台帳は静かに壊れる。手元のデータベースは「763件」と言っていた。信用をやめて、21 の AI プラットフォームにブラウザで直接入り、各プラットフォーム自身の API をページ内から叩いて ID 単位で突き合わせたら、実在したのは約 400 件だった。
これはそのギャップの監査記録だ。数字は 2026-08-18 に実際のアカウントで測ったもので、仮定の話はひとつもない。
対象は、実際に使っているアカウントから収集した AI エージェント資産 — 会話・プロジェクト・スキル・指示ファイル・メモリ — の台帳 763 行。Claude、ChatGPT、Gemini、Grok、Perplexity、Kimi、Qwen ほか、あわせて 21 プラットフォーム。
検証の方法は道具より大事なので先に書く。
fetch（credentials: 'include'）でそのプラットフォーム自身の一覧 API を呼ぶ。ページネーションは最後まで回す件数が一致していても、中身が別のリストということはある。何があるかを教えてくれるのは ID の差分だけだ。
763 と 400 の差は 1 個のバグではなかった。独立した 3 つの故障モードで、どれもダッシュボード上は健全に見える。
| 故障モード | 何が起きるか | 確認できた行数 |
|---|---|---|
| 幽霊 | プラットフォーム側で消えたものが DB に残り続ける | 最低 173 |
| 取りこぼし | 実在するのに DB に入っていない | 最低 63 |
| 誤検出 | 全員に配られる既定物・例文を、ユーザー資産として計上 | 最低 109 |
構造に注意してほしい。幽霊と誤検出は台帳を水増しし、取りこぼしは目減りさせる。部分的に相殺する。つまり合計件数は、3 つの故障をすべて隠すことが保証された唯一の指標になる。
ページサイズ上限が件数になっていた。 あるプラットフォームのスキル欄は台帳上 100 件。ユーザーが実際に入れたのは 4 件だった。残り 96 は全ユーザーに表示される公式カタログで、「100」という数字自体、一覧 API の page_size 上限がそのままアカウントの事実として記録されたものだった。
設定画面の例文がメモリになっていた。 実際には 8 件の保存情報があるのに、収集器は 8 件すべてを取りこぼし、代わりに設定画面のプレースホルダ（「例：〜」の 2 行）をユーザーデータとして保存していた。ダッシュボード上では、このセルは「動いている側」に見えた。
最初から存在しないファイルが 42 行。 ローカルのルールディレクトリを指す指示ファイル 42 行の参照先パスが、このマシンに存在しなかった。削除されたのではない。一度も存在したことがない。それでも収集器は 42 行を書いた。
この全行が、成功を報告したジョブによって書かれた。ここが本題だ。
収集器の改良ではない。読み直し監査（read-back audit）を一級の操作にすることだ。同期のあとに対象を再読して ID を両方向に diff する。「プラットフォームが全員に配る既定物」を、マッチャが知っているべきカテゴリとして扱う。そして一度きりではなく、スケジュールで回す。
複数のツールでエージェントを運用しているなら、一度数えてみてほしい。プラットフォームをひとつ選び、台帳の言い分を書き出し、そのプラットフォーム自身の API を最後のページまでめくる。最初の diff は大抵 10 分で出るし、空であることは滅多にない。
*この監査は untactit — AI エージェントのスキル・指示・メモリを一元管理する基盤（プレローンチ）— の開発過程のものです。ここで書いた読み直し検証は、そのままプロダクトの設計原則になっています。配信先を読み直さない配信は、台帳が腐る経路そのものだからです。*