巨大な一つの会話に頼らず、長年のChatGPT履歴を整理する

アーカイブが本当に役立つのは、三つの異なる問いに答えられるときです。何が語られたのか。今は何が有効なのか。なぜ変わったのか。

何年分もの内容を一つの「マスター会話」に入れても、この三つを安定して扱うことはできません。古いメッセージが画面に残っていても、必要な情報は限られた作業コンテキストの中で競合します。より堅実な設計は、証拠を保存し、確認済みの小さな現状レイヤーを別に持ち、検索索引は必要に応じて作り直すことです。

元のエクスポートを変更しない

まず、自分で管理できるアカウントのエクスポートを使います。ダウンロードしたアーカイブは変更せず、非公開でバックアップされた場所に保存してください。取得日を記録し、変換前にハッシュを計算します。

sha256sum chat-export.zip > chat-export.zip.sha256

ハッシュは中の発言が正しいことを証明するものではありません。後で処理するファイルが、今日保存したものと同一であることを確認するためのものです。

作業用のコピーを展開し、各会話と各メッセージに安定したIDを付けます。元の順序、時刻、役割、本文、添付ファイルの参照、元ファイル名を残します。Markdownは読むのに便利で、JSONやSQLiteは検索に便利ですが、どちらも元のエクスポートの代わりにはしません。

OpenAIの現在のChatGPT利用ガイドでは、データエクスポートをファイルとして追加し、比較・抽出・再整理に使える一方、重要な結論は元の資料と照合するよう勧めています。この役割分担が適切です。ソフトウェアは構造を提案できますが、アーカイブは確認に必要な証拠を保持します。

証拠と現状を分ける

一つの要約に履歴と真実の両方を担わせないでください。リンクされた二種類の記録を使います。

証拠レコードは、特定の会話に何が現れたかを記録します。

{
  "id": "ev-2024-0612-0042",
  "conversation_id": "chat-2024-0612",
  "message_id": "msg-0042",
  "observed_at": "2024-06-12T09:14:00Z",
  "kind": "user_statement",
  "text": "プロジェクトは見積もりの改訂待ちです。",
  "review": "confirmed"
}

現状レコードは、今どの内容を有効とみなすかを記録し、その根拠となる証拠へ戻れるようにします。

{
  "id": "state-project-orchid-status",
  "subject": "project-orchid",
  "field": "status",
  "value": "見積もりの改訂待ち",
  "effective_at": "2024-06-12",
  "evidence": ["ev-2024-0612-0042"],
  "reviewed_at": "2024-06-13",
  "supersedes": "state-project-orchid-status-v1"
}

この小さな分離で、いくつもの問題を同時に解けます。古い事実は時系列に残り、現在のタスクは小さく保たれ、後の訂正も過去を消しません。そして、新しい回答が「なぜこれが現状なのか」を示せます。

健康に関する機微なメモは、診断ではなく、日付のある本人の報告として保存します。一般的にも、モデルが作れる最も強い解釈ではなく、出典が実際に裏づける範囲を記録します。

AIの提案に状態を持たせる

提案と事実を同じ一覧に入れると、提案が誤った事実へ変わりやすくなります。小さなクレーム台帳を作り、状態を明示します。

  • proposed — 抽出または提案されたが、未確認。
  • confirmed — 所有者が受け入れ、出典で確認できる。
  • rejected — 確認した結果、不適切または誤り。
  • superseded — 以前は有効だったが、新しい確認済み記録に置き換えられた。
  • uncertain — 残す価値はあるが、現状としては使えない。

新しい会話は更新案を作っても構いませんが、現状ファイルを自動で書き換えてはいけません。確認時に採用、修正、却下、統合を行い、その判断と日時も、証拠を上書きせず別のイベントとして保存します。

すべての自動要約を採用するより少し遅く見えます。しかし、放棄したアイデアが現行計画になったり、モデルの推測が個人史に混ざったりしたことを数か月後に発見するより、はるかに速い方法です。

索引は捨てて作り直せるようにする

長く残すべきなのは、元の記録と確認の判断です。検索索引は交換可能なビューにします。

まずメタデータと全文検索から始めます。会話ID、日付、人やプロジェクトのタグ、記録種別、確認状態、本文を索引します。同じ内容が異なる言葉で書かれているために実際の検索が失敗するときだけ、埋め込みを追加します。どの方法でも、断片から元メッセージへの対応を保持し、周辺の会話を開けるようにします。

質問によって参照先を変えます。

  • 「今、何が進行中か」は現状レコードから読む。
  • 「どう変わったか」は日付付き証拠と置換リンクから読む。
  • 「どこから来たか」は元メッセージと周辺の文脈を開く。
  • 「何を忘れているかもしれないか」は確認済み・未確定の証拠を検索するが、自動で現状へ昇格させない。

データベースやベクトルストアが壊れたら、記録から再構築します。記録が索引の中にしかなければ、その索引は別の壊れやすいマスター会話になっています。

バックログを区切って処理する

数百の会話を一度の確認セッションへ入れないでください。小さな単位で完了させてから次へ進みます。

  1. 解釈を加えず、元の会話を正規化する。
  2. 正確なメッセージ参照を付けて、証拠候補を抽出する。
  3. 現状、時系列、保存対象のプロジェクト記録を変え得る候補だけ確認する。
  4. 採用した状態変更と却下判断を書き込む。
  5. 答えが分かっている質問を少数実行し、引用元を一つずつ開く。
  6. 件数、ハッシュ、例外、最後に処理した出典IDをチェックポイントへ保存する。

次の単位は、前回のモデル会話ではなく、保存済みのファイルとチェックポイントから始めます。会話が失敗したりコンテキストを使い切ったりしても、完了分は失われません。

目で追えるフォルダー構造にする

単純な構成で十分です。

archive/
├── raw/                 # 変更しないエクスポートとハッシュ
├── conversations/       # 安定IDを持つ正規化メッセージ
├── evidence/            # 出典付きの事実、判断、タスク、出来事
├── state/               # 小さな確認済み現状レコード
├── reviews/             # 採用、却下、置換された提案
├── indexes/             # 再構築可能な全文・ベクトル索引
└── manifests/           # チェックポイント、版、検証結果

長期保存フォルダーは索引とは別にバックアップします。私的なアーカイブは暗号化し、設計を試すだけのためにコレクション全体を別サービスへアップロードしないようにします。

信頼する前に、答えを知っている質問を十個用意してください。現在のタスク、古い計画、変更された日付、判断、矛盾、いくつかの厳密な出典検索を含めます。正しい現状を返し、それを裏づける出典を開けたときだけ合格です。

小さな実例を見る

私は、書き起こしを変更せず、確認済みの箇所を型付きレコードへ変換し、訂正を置換イベントとして残す小さな「出典から判断まで」の例を作りました。ダウンロードできるJSONで、大きなコンテキストを使わずに証拠と状態の構造を確認できます。Local Knowledge Terminalは、この来歴管理を行う公開プロジェクトです。

この例はプロジェクト内で作成した会議素材を使っており、完成したChatGPTインポーターではありません。再利用できるのは設計上の約束です。出典は動かさず、現状は確認を経て、訂正は残り、索引は再構築できます。

私的なアーカイブが既存の一台のコンピューターに収まるなら、250米ドルのLocal Knowledge Terminalコレクション適合スプリントで、最大12の代表的なソース単位と20の実際の質問を使い、大きな構築へ進む前に適合性を試せます。最初は無料の適合確認で、範囲が決まる前にアーカイブを送ったり支払ったりする必要はありません。

目標は、一つのモデルにすべてを覚えさせることではありません。忘れても、元へたどって回復できるようにすることです。

Leave a Reply