来歴(プロブナンス) — すべての主張は生バイトまで遡る

エージェントに**「これはどこから得たのか?」**と問えば、連鎖を遡ってバイトまで辿ります。本ページはその連鎖を文書化します。

連鎖

Final story ──► final-story.md
   │ cites story:42
   ▼
Story ──► story.md
   │ cites note_paths[postit:12345, postit:12346]
   ▼
Post-it ──► agent_postits row
   │ source_row_ids=[emails:7891, conversation_turns:55432]
   ▼
Evidence ──► incidents:7891 → file:///incidents/raw/2026-05-18_INC-2026-0142.jsonl
            conversation_turns:55432 → session.jsonl:421:198432
   ▼
Raw bytes ──► 絶対的なグラウンドトゥルース — 決して移動しない

6つのレイヤー。各レイヤーがその下のレイヤーを引用します。最下層(生バイト)は追記専用かつ不変 — 元ファイルは決して書き換えられず、置き換えられるのみです。

なぜファイルが正本か(DBのカラムではなく)

ストーリー、ポスト・イット、ファイナルストーリーは、まずディスク上の.mdファイルとして存在します。DBが保持するのは:

高速検索のためのインデックス
改ざん検出のためのファイル内容のハッシュ
レイヤー間のクロスリファレンス

しかし正本となる真実はファイルです。8つの理由:

DBアクセスなしで人間が読める
Git管理可能(各ストーリーに履歴)
DB破損を耐え抜く
grep可能
バックアップが容易
インシデント時の調査が容易
ORMインピーダンスなし
クラウドとローカルモードで同じ形

これが可能にすること

ニーズ	来歴が提供するもの
「なぜエージェントはこう言ったのか?」	ソースまで遡る — どのポスト・イット、どのメール、どの文かを正確に確認
「これは改ざんされていないか?」	ハッシュチェック — 読み込みごとにDBハッシュとファイルハッシュを照合
「日付Xの時点でシステムは何を知っていたか?」	アーカイブレイヤー — 各ストーリーに日付付きアーカイブ
「この主張を信頼してよいか?」	各ポスト・イットの重要度スケール + ソース行の深さ

コスト特性

レイヤー	コスト特性
Final story	1ファイル、毎日書き直し、ハッシュをDBに格納
Story	ケースファイルごとに1ファイル、新ポスト・イットクラスタで再構築、旧版はアーカイブ
Post-it	アナライザーレンズ×ソースごとに1行、書き込み後は不変
Evidence	取り込まれたソース(メール、会話ターン、写真、ERP行)ごとに1行
Raw	追記専用 — 元ファイルは`~/inbox/`、`~/library/raw/`にとどまる

ストレージは取り込み量に対して線形に増加します。1オフィスあたり1日約100通のメールで、合計約10MB/日 — 1年分の完全な来歴は4GBに収まります。

次に読む

実例 · 1つのAIインシデント 1つのAI安全インシデントで連鎖をエンドツーエンドで演習。

オフィスライブラリこの連鎖を養うライブラリパイプライン全体。

3つのフィーダー来歴がエージェントのコールドスタートへどう流れ込むか。