← 一覧に戻る

Second-Brain 記録戦略の再設計

2026年4月8日 07:22 更新
MD から自動変換されたページです。内容について質問があれば右下の ? ボタンからどうぞ。

対象読者: 非エンジニア（専門用語は初出時に括弧で解説） 作成日: 2026-04-08 ステータス: 提案（Codex adversarial review 済み）

1. Second-Brain の現在の設計思想

1-1. 基本コンセプト

Second-Brain は「AI非依存の外部記憶」として設計されている。核となる思想は3つ:

  1. AI非依存（vendor lock-in 回避）: ChatGPT・Claude Code・Codex・Gemini、どのAIからでも同じ情報にアクセスできる。特定AIの独自形式ではなく、Markdown（プレーンテキストの書式）で永続化する
  2. 自動蓄積: セッション終了時の hook（自動実行スクリプト）と定期同期で、手動作業なしに会話ログを蓄積する
  3. 秘書のステートレス化: AI秘書は自分では文脈を持たず、Second-Brain に記録された情報が「文脈の主軸」として機能する。秘書が再起動しても継続性が維持される

1-2. 現在の構造

Second-Brain/（2,885ファイル、37.9MB）
├── YYYY-MM-DD_タイトル.md          ← ChatGPT由来（1,375件）
├── YYYY-MM-DD_タイトル_8桁hex.md   ← Claude Code/Codex由来（1,503件）
├── telegram-outbound-YYYY-MM-DD.md ← Telegram送信ログ（少数）
├── README.md
└── _generated/wiki/topics/         ← Karpathy式KB（5トピック、Phase 1完了）

1-3. frontmatter（各ファイル冒頭のメタ情報）の現状

フィールド 内容 件数
date 日付 2,858
title タイトル 2,853
source 記録元（ChatGPT/Codex/Claude Code） 2,850
tags タグ 2,858
session_id セッション識別子 1,627
msg_count 会話ターン数（Codexのみ） 897

注目すべき不在: セッションの「種別」（対話なのか作業なのか）を示すフィールドが存在しない。

1-4. 記録メカニズム

2. 問題点

2-1. 核心: 「保存の美しさ」と「取り出しの有効性」の混同

現在のSecond-Brainには2種類のセッションが混在しているが、区別する手段がない:

セッション種別 目的 検索時に答えたい問い
ユーザー対話 秘書とのTelegram経由の意思決定会話 「なぜそう決めたか」
エージェント作業 秘書がdispatchした実装タスク 「どうなったか」

2-2. 具体的な弊害

1. 検索ノイズの増大 「なぜあの設計にしたか」を探したいのに、関連する実装作業ログが大量にヒットする。逆に「あの実装どうなった？」を探すと意思決定の議論が混入する。2,885件の時点で既に発生しており、年間1,600件ペースで増加中。

2. 情報源優先順位の形骸化 秘書設計書では レジストリ → tmux → Second-Brain → memory → recall の優先順位が定義されているが、Second-Brain 内部が未分化なので、参照時点でノイズの塊になる。優先順位があっても、層内の選別が弱いと意味がない。

3. Karpathy式KB（wiki compile）への悪影響 compile-wiki.sh が全ファイルを原材料として知識を蒸留する際、対話ログと作業ログの区別がつかないため、wiki トピックの品質に影響する可能性がある。「決定の根拠」と「作業の詳細」は蒸留の仕方が異なるべき。

4. 将来の再編コストの先送り 10,000件を超えてから分類を導入すると、過去分の後付け変換（retrofitting）が最もコスト高になる。今やるのが最も安い。

5. 「全部記録している安心感」と「使える知識」は別 蓄積量が多いほど賢くなるのではない。取り出し単位が設計されているほど賢くなる（Codex指摘）。

2-3. 却下された過去の提案と、その教訓

提案 却下理由 教訓
frontmatter type + サマリーのみ記録 サマリー生成でLLMコンテキストを消費する 記録時にLLM推論を要求してはいけない
作業ログはSecond-Brain記録スキップ 「思想から考え直せ」 記録を減らすのではなく、記録の意味を分けるべき

3. 提案する記録戦略

3-1. 基本方針: 「形式統一 + 意味分類」

Codex が最も鋭く指摘した核心を採用する:

「保存フォーマット（Markdown + frontmatter）の統一」と「記録の意味分類」は別物。形式は統一したまま、意味分類だけ追加する。

3-2. 具体的な設計

frontmatter の拡張

---
date: 2026-04-08
title: "秘書との転職方針の相談"
source: "Claude Code"
session_id: "abc12345-..."
record_kind: dialogue          # ← 新規追加
tags:
  - "claude"
---

record_kind の値

値 意味 判定方法
dialogue ユーザーとの対話（意思決定・相談） Telegram起点のsecretaryセッション
agent_work dispatchされた実装タスク secretary が task dispatch で生成したセッション
interactive ユーザーが直接Claude Codeを操作 Telegram以外の直接操作セッション
codex_review Codexによるレビュー source: Codex
chatgpt ChatGPTとの会話 source: ChatGPT

分類は LLM 不要、機械的に行う

ゼロ追加コストの分類方法:

  1. セッションの入口で判定: Telegram bot 由来 → dialogue、agent runner 由来 → agent_work
  2. 環境変数で伝達: sync-recall-to-obsidian.sh を呼ぶ側で RECORD_KIND=dialogue を渡す
  3. 既存メタデータで推定: source フィールド（ChatGPT → chatgpt、Codex → codex_review）
  4. セッション起動元の判定: secretary の dispatch スクリプトが RECORD_KIND=agent_work を設定

3-3. 記録層と検索層の分離

記録層（変更なし）          検索層（新規）
┌────────────────┐     ┌────────────────────────┐
│ 全セッションを  │     │ record_kind で絞り込み   │
│ 生ログのまま    │ ──→ │                          │
│ 完全保存        │     │ dialogue → 意思決定検索  │
│                 │     │ agent_work → 作業結果検索│
│ 要約しない      │     │ 両方 → wiki compile      │
│ 省略しない      │     └────────────────────────┘
└────────────────┘

ポイント: 記録は完全保存のまま。検索時に record_kind で用途別に絞る。これにより:

4. なぜこの方法が最善か

4-1. Codex adversarial review の核心的指摘

Codex（GPT-5.4）による adversarial review で、以下の分析が得られた:

「本当の問題は『dialogue と work が区別できないこと』ではない。『記録システムが retrieval requirements（取り出し要件）から逆算されていないこと』だ。」

この指摘を踏まえ、提案は「取り出し要件から逆算した最小限の構造化」に焦点を当てている。

4-2. 却下された案との比較

評価軸 案1（サマリー） 案2（スキップ） 本提案（record_kind）
context効率 サマリー生成でLLM消費 消費なし 消費なし（機械分類）
情報の完全性 サマリーは原本の劣化コピー 作業ログが消える 全て完全保存
検索性 サマリーの品質次第 存在しないものは検索不能 frontmatterでフィルタ可能
保守コスト サマリー品質の管理が必要 低い 環境変数1つの追加
AI非依存 維持 維持 維持（標準的なfrontmatter）
既存設計との整合 部分的 思想に反する 形式統一を完全維持

4-3. Codex が指摘した5つの脆い前提への対応

Codex指摘 本提案の対応
「同じ形式で残すほど使いやすい」は半分だけ正しい 形式は統一、意味分類を追加
「後段の検索で区別できれば十分」は10K+で破綻 frontmatter で事前分類
「AI-agnostic = 同一スキーマ」は誤り record_kind は vendor-neutral
「分類にはLLMが必要」は怪しい 発生源・経路で機械分類
「単一の主軸 = 単一レイヤー」は別問題 主軸のまま、内部に型を追加

5. 実装手順

Phase 0: 方針確定（即時）

Phase 1: 新規記録への record_kind 追加

変更対象: sync-recall-to-obsidian.sh（とその呼び出し元）

  1. 環境変数の追加: RECORD_KIND を受け取るようにする

    • 未設定時のデフォルト: interactive（ユーザー直接操作）
    • secretary dispatch 時: RECORD_KIND=agent_work
    • secretary 対話セッション: RECORD_KIND=dialogue

  2. frontmatter 生成部分の修正: record_kind: $RECORD_KIND を追加

    record_kind: dialogue  # ← 1行追加するだけ

  3. secretary の dispatch スクリプト修正: タスク実行時に RECORD_KIND=agent_work を環境変数に設定

  4. source ベースの自動判定: RECORD_KIND が未設定の場合のフォールバック

    • source=ChatGPT → record_kind: chatgpt
    • source=Codex → record_kind: codex_review
    • source=Claude Code（環境変数なし） → record_kind: interactive

Phase 2: 過去ファイルの段階的 backfill（後付け分類）

全2,885件を一気に分類する必要はない。段階的に:

  1. 決定的ルールで一括処理できるもの:

    • source: ChatGPT → record_kind: chatgpt（1,219件）
    • source: Codex → record_kind: codex_review（897件）
    • これだけで全体の73%をカバー

  2. Claude Code セッション（734件）の分類:

    • session_id から recall metadata を参照し、Telegram channel 経由かどうかで判定
    • 判定不能なものは record_kind: unknown

  3. unknown はそのまま放置してよい:

    • 必要になったときだけ個別に再分類
    • Karpathy式 wiki compile の際に自然に整理される

Phase 3: 検索・活用の最適化（Phase 1安定後）

想定される境界事例

ケース 対応
対話しながら作業もする混合セッション record_kind: mixed を許容
secretary自身が調査する短いセッション record_kind: dialogue（意思決定の一部）
ユーザーが直接Claude Codeで作業 record_kind: interactive

付録: Codex adversarial review 要旨

核心の指摘

「本当の問題は『dialogue と work が区別できないこと』ではない。『記録システムが retrieval requirements（取り出し要件）から逆算されていないこと』だ。お前が欲しいのは保存の美しさではなく、必要なときに必要な記録だけを、安く、確実に引けることのはずだ。」

5つの脆い前提

  1. 「全セッションを同じ形式で残すほど、後で使いやすい」→ 保存の単純さと検索の有効性は別問題
  2. 「後段の検索や人間の読解で区別できれば十分」→ 10,000件超で破綻
  3. 「AI-agnostic = すべて同じスキーマ」→ frontmatterにtype追加はvendor lock-inではない
  4. 「分類にはLLMが必要」→ 発生源・経路で機械分類可能
  5. 「stateless secretary = 単一レイヤー」→ 主軸であることと単一レイヤーは別

推奨

最も厳しい指摘

「今の "same format for everything" は原則ではなく、実装都合が哲学に昇格しているだけだ。形式統一と意味無差別は別物だ。」

📝 質問モード — テキストを選択してね
✓ 質問を送信しました