claude-history-ingest

Claude History Ingest — 会話のマイニング

ユーザーの過去の Claude Code の会話から知識を抽出し、Obsidian のウィキにまとめます。会話には豊富な情報が含まれていますが、整理されていません。重要な情報を見つけてまとめるのがあなたの役割です。

このスキルは直接呼び出すことも、wiki-history-ingest ルーター（/wiki-history-ingest claude）経由で呼び出すこともできます。

開始する前に

執筆スタイル： 自然言語の Markdown を作成または書き換える前に、llm-wiki/SKILL.md の「執筆スタイルの解決」セクションを読み、適用してください。フレームワークのスキーマ、出典、安全性、操作ごとの要件が優先されます。 WRITING.md の設定は、新たに作成または書き換える自然言語の Markdown にのみ適用してください。元のコンテンツと構造化レコードはそのまま保持してください。

1. 設定を解決する — llm-wiki/SKILL.md の設定解決プロトコルに従います（インラインの @name による上書き → CWD から上位ディレクトリへ .env を検索 → グローバル設定 → 設定を促す）。これにより OBSIDIAN_VAULT_PATH と CLAUDE_HISTORY_PATH（デフォルトは ~/.claude）が得られます
2. Vault ルートの .manifest.json を読み、すでに取り込まれている内容を確認します
3. Vault ルートの index.md を読み、ウィキにすでに含まれている内容を確認します
4. プロジェクトの絞り込み — 設定から WIKI_SKIP_PROJECTS（カンマ区切りの部分文字列）を読み取ります。以下のすべての手順（スキャン、差分確認、サンプリング、マニフェストへの書き込み）で、名前にいずれかの文字列が含まれるプロジェクトディレクトリを除外します。今回の実行でユーザーが追加のスキップ対象プロジェクトを指定した場合は、それらも追加します。除外は一度だけ、全体で統一して適用してください。コマンドごとに grep -v フィルターを手書きすると、スキャンとマニフェストの手順で不整合が生じます。

取り込みモード

追加モード（デフォルト）

各ソースファイル（会話の JSONL、メモリファイル）について、.manifest.json を確認します。次のファイルのみ処理します。

• マニフェストにないファイル（新しい会話、新しいメモリファイル、新しいプロジェクト）
• マニフェストの ingested_at より更新日時が新しいファイル

通常はこのモードを使います。ユーザーがいくつか新しいセッションを実行し、その差分を取り込みたい場合に適しています。

比較時は移植可能なキーを使用します。 マニフェストのキーは、llm-wiki/SKILL.md の「.manifest.json」にあるソースキーの仕様（v2）に従います。$HOME の下にあるセッションは ~ からの相対パス（~/.claude/projects/.../abc.jsonl）で記録され、展開後のマシン固有のパスでは記録されません。Vault からの相対パスと疑似キーも、もう 2 つの形式です。ファイルが「新規」かどうかを判断する前に、ツールと同じ方法で保存済みのキーを解決してください（~／環境変数を展開し、Vault からの相対パスは Vault ルートを基準に解決します）。そうしないと、すでに追跡されているファイルが新規に見え、再取り込みされます。scripts/manifest.py ヘルパーを使うと、この処理を行えます。

# WIKI_SKIP_PROJECTS と --skip を適用した、新規または変更済みのソース：
python3 "$OBSIDIAN_WIKI_REPO/scripts/manifest.py" delta "$OBSIDIAN_VAULT_PATH" \
  --scan "$CLAUDE_HISTORY_PATH/projects/*/memory/*.md"
# マニフェストに旧形式の絶対パスキーが残っている場合の一度限りの修復：
python3 "$OBSIDIAN_WIKI_REPO/scripts/manifest.py" migrate "$OBSIDIAN_VAULT_PATH" --dry-run

ヘルパーは任意です。利用できない場合は、マニフェストを参照または更新するたびに、同じ解決処理をその場で行ってください。

抽出前の処理（推奨 — 取り込み前に実行）

生の JSONL ファイルは 80〜90％がノイズです。tool_use ブロック、thinking ブロック、progress イベント、file-history-snapshot エントリがバイト数の大半を占めます。scripts/extract-jsonl.py ヘルパーはこれらをすべて除去し、~/.claude/extracted/ にシグナルのみを含むコンパクトな JSON を出力します。これにより、ファイルサイズを 50〜200 倍削減できます（例：12 MB の JSONL → 抽出後は 64 KB）。同じトークン予算で、スキルが1回の実行あたりに読み取れる会話数が5〜10倍になります。

このスキルを実行する前のステップとして、次のコマンドを実行してください。

# First run — extract everything (skip excluded projects)
python3 "$OBSIDIAN_WIKI_REPO/scripts/extract-jsonl.py" --skip tsg,autom8

# Incremental — only sessions modified in the last day
python3 "$OBSIDIAN_WIKI_REPO/scripts/extract-jsonl.py" \
    --since "$(date -v-1d +%Y-%m-%d)" --skip tsg,autom8

抽出したファイルは ~/.claude/extracted/<project-dir>/<session-id>.json に保存され、次の内容が含まれます。

{
  "session_id": "uuid",
  "project": "-Users-name-myapp",
  "cwd": "/Users/name/myapp",
  "start_ts": "...",
  "end_ts": "...",
  "n_turns": 18,
  "n_user_words": 620,
  "turns": [
    {"role": "user",      "text": "..."},
    {"role": "assistant", "text": "..."}
  ]
}

ステップ3で会話を読み取る際は、常に生の JSONL より抽出済みファイルを優先してください。（ステップ3を参照。）

事前に extract-jsonl.py を実行していない場合は、生の JSONL を使用してください。ただし、生のファイルは読み取りに必要なトークンが大幅に多いため、網羅性が低くなります。

会話サンプリングのヒューリスティック

履歴パスには数百件の会話 JSONL が含まれることがあります。すべてを読み取ろうとしないでください。プロジェクトごとに、次のように処理してください。

• プロジェクトにすでにメモリファイル（memory/*.md）がある場合は、まずそれらを取り込みます（事前に抽出されたシグナルです）。その後、マニフェストにまだない会話も処理してください。メモリが豊富なプロジェクトでも、新しい会話は引き続き記録する必要があります。
• プロジェクトにメモリファイルがない場合は、プロジェクトの特徴を把握するために、更新日時が新しい会話を3件だけ読み取ります。上記の抽出済みファイルを優先してください。必要なコストが低いため、生の JSONL 1件分と同じトークン予算で5〜10件を読み取れます。
• サンプリングした内容とスキップした内容を必ず報告してください（例：「agenttower：メモリファイル7件と新しい会話4件を取り込み、変更のない会話14件をスキップ」）。網羅できていない範囲が分かるようにし、黙って見過ごさないでください。

フルモード

マニフェストの状態にかかわらず、すべてを処理します。wiki-rebuild の実行後、またはユーザーから明示的に依頼された場合に使用してください。

Claude Code のデータ配置

Claude Code はデータを2つの場所に保存します。両方をスキャンしてください。

ソース1：~/.claude/（CLI セッション）

~/.claude/
├── projects/                          # Per-project directories
│   ├── -Users-name-project-a/         # Path-derived name (slashes → dashes)
│   │   ├── <session-uuid>.jsonl       # Conversation data (JSONL)
│   │   └── memory/                    # Structured memories
│   │       ├── MEMORY.md              # Memory index
│   │       ├── user_*.md              # User profile memories
│   │       ├── feedback_*.md          # Workflow feedback memories
│   │       └── project_*.md           # Project context memories
│   ├── -Users-name-project-b/
│   │   └── ...
├── sessions/                          # Session metadata (JSON)
│   └── <pid>.json                     # {pid, sessionId, cwd, startedAt, kind, entrypoint}
├── history.jsonl                      # Global session history
├── tasks/                             # Subagent task data
├── plans/                             # Saved plans
└── settings.json

ソース2：~/Library/Application Support/Claude/local-agent-mode-sessions/（デスクトップアプリのエージェントセッション）

最初に事前確認を行ってください。 多くのユーザーは CLI のみを使用しており、デスクトップセッションがありません。以下の構造をたどる前に、空でないことを確認してください。

DESKTOP_SESSIONS="$HOME/Library/Application Support/Claude/local-agent-mode-sessions"
[ -d "$DESKTOP_SESSIONS" ] && find "$DESKTOP_SESSIONS" -name "audit.jsonl" | head -1

何も表示されない場合は、このセクション全体（ソース2とステップ3b）をスキップし、説明にも含めないでください。

Claude デスクトップアプリは、ローカルエージェントモードのセッションをここに保存します。構造は深くネストされています。

~/Library/Application Support/Claude/local-agent-mode-sessions/
└── <outer-uuid>/
    └── <inner-uuid>/
        ├── local_<session-uuid>.json          # Session metadata
        └── local_<session-uuid>/
            ├── audit.jsonl                    # Audit log — tool calls, file reads, commands run
            └── .claude/
                └── projects/
                    └── <path-encoded-name>/   # Same path-encoding as ~/.claude/projects/
                        └── <uuid>.jsonl       # Conversation transcript (same JSONL format as CLI)

すべての local-agent-mode セッションを見つける方法：

# Find all session metadata files
find ~/Library/Application\ Support/Claude/local-agent-mode-sessions -name "local_*.json" -maxdepth 4

# Find all audit logs
find ~/Library/Application\ Support/Claude/local-agent-mode-sessions -name "audit.jsonl"

# Find all conversation transcripts
find ~/Library/Application\ Support/Claude/local-agent-mode-sessions -name "*.jsonl" -path "*/.claude/projects/*"

セッションメタデータ（local_<uuid>.json） — sessionId、cwd、startedAt、model、title などのフィールドを含む JSON ファイルです。トランスクリプトを開く前にこれを読み、セッションのコンテキストを把握してください。

監査ログ（audit.jsonl） — 各行はエージェントの1つのアクションを記録する JSON レコードです。ツール呼び出し（Read、Write、Bash、Edit）、ファイルアクセス、実行したシェルコマンド、MCP 呼び出しが含まれます。エージェントが実際に何をしたかを把握するのに役立ちます。多くの場合、会話テキストだけよりも豊富なシグナルが得られます。フィールド：type、toolName、input、output、timestamp、sessionId。

会話トランスクリプト（.claude/projects/.../<uuid>.jsonl） — CLI の会話 JSONL と同じ形式です。~/.claude/projects/*/*.jsonl と同じ方法で解析してください。

価値の高い主要データソース（両方の場所を合わせた順位）：

1. メモリファイル（~/.claude/projects/*/memory/*.md）— 事前に整理されており、そのままウィキに適した形式です。最も価値があります。
2. 会話 JSONL（~/.claude/projects/*/*.jsonl とデスクトップアプリのトランスクリプト）— 会話の全記録です。情報量は豊富ですが、ノイズも多く含まれます。
3. 監査ログ（デスクトップセッション内の audit.jsonl）— 実行した操作をツール呼び出し単位で記録したものです。会話の記録が少ない場合でも、具体的な操作、ファイルのパターン、コマンドのパターンを抽出するのに役立ちます。
4. セッションメタデータ（sessions/*.json と local_*.json）— プロジェクト、日時、CWD を確認できます。

ステップ 1：調査して差分を算出する

両方のデータ保存場所をスキャンし、.manifest.json と比較します。

# --- Source 1: CLI sessions (~/.claude) ---
# Find all projects
Glob: ~/.claude/projects/*/

# Find memory files (highest value)
Glob: ~/.claude/projects/*/memory/*.md

# Find conversation JSONL files
Glob: ~/.claude/projects/*/*.jsonl

# --- Source 2: Desktop app local-agent-mode sessions ---
DESKTOP_SESSIONS="$HOME/Library/Application Support/Claude/local-agent-mode-sessions"

# Session metadata
find "$DESKTOP_SESSIONS" -name "local_*.json" -maxdepth 4

# Audit logs
find "$DESKTOP_SESSIONS" -name "audit.jsonl"

# Conversation transcripts
find "$DESKTOP_SESSIONS" -name "*.jsonl" -path "*/.claude/projects/*"

統合インベントリを作成し、各ファイルを分類します。

• 新規 — マニフェストに存在しない → 取り込みが必要
• 変更済み — マニフェストに存在するが、ファイルのほうが新しい → 再取り込みが必要
• 未変更 — マニフェストに存在し、変更されていない → 追記モードではスキップ

ユーザーに次のように報告します。「CLI プロジェクトが X 件、デスクトップセッションが Y 件見つかりました。メモリファイル：A 件。会話：B 件。監査ログ：C 件。差分：新規 D 件、変更済み E 件。」

ステップ 2：まずメモリファイルを取り込む

メモリファイルは、すでに YAML フロントマターで構造化されています。

---
name: memory-name
description: one-line description
type: user|feedback|project|reference
---

Memory content here.

メモリファイルごとに、次の処理を行います。

• ファイルを読み込み、フロントマターを解析する
• user タイプ → ユーザーについてのエンティティページ、またはユーザーの専門分野に関するコンセプトページに反映する
• feedback タイプ → スキルページ（ワークフローのパターン、うまくいくこと、うまくいかないこと）に反映する
• project タイプ → プロジェクトのエンティティページに反映する
• reference タイプ → 外部リソースを参照するリファレンスページに反映する

各プロジェクトの MEMORY.md インデックスファイルは簡潔な概要です。まずこれを読み、個別のメモリファイルのうち、全文を読む価値があるものを判断してください。

ステップ 3：会話 JSONL を解析する

必ず最初に事前抽出ファイルを確認します（上記の「事前抽出」セクションを参照）。各会話 ~/.claude/projects/<proj>/<uuid>.jsonl について、対応するファイルが ~/.claude/extracted/<proj>/<uuid>.json にあるか確認します。見つかった場合は、そちらを読み込みます。ユーザーとアシスタントのテキストターンのみがすでに抽出されており、元の JSONL と比べて必要なトークン数が 50～200 分の 1 で済みます。

# Resolution order for each session:
1. ~/.claude/extracted/<project>/<session-id>.json   ← prefer (compact, signal-only)
2. ~/.claude/projects/<project>/<session-id>.jsonl   ← fallback (raw, noisy)

事前抽出ファイルを読む場合： 必要なターンのみがすでに含まれています。turns[].{role, text} を直接反復処理してください。最上位のフィールド（cwd、start_ts、n_user_words など）から、追加の解析を行わずにプロジェクトのコンテキストを把握できます。

元の JSONL を読む場合（フォールバック）： 各行は JSON オブジェクトです。

{
  "type": "user|assistant|progress|file-history-snapshot",
  "message": {
    "role": "user|assistant",
    "content": "text string"
  },
  "uuid": "...",
  "timestamp": "2026-03-15T10:30:00.000Z",
  "sessionId": "...",
  "cwd": "/path/to/project",
  "version": "2.1.59"
}

アシスタントのメッセージでは、content がコンテンツブロックの配列になっている場合があります。

{
  "content": [
    {"type": "thinking", "text": "..."},
    {"type": "text", "text": "The actual response..."},
    {"type": "tool_use", "name": "Read", "input": {...}}
  ]
}

• type: "user" と type: "assistant" のエントリのみを対象にする
• アシスタントのエントリでは、text ブロックを抽出する（thinking と tool_use はノイズのためスキップする）
• cwd フィールドから、この会話がどのプロジェクトに属するかを判断する
• type: "progress" はスキップする — エージェント内部の進捗更新です
• type: "file-history-snapshot" はスキップする — ファイル状態の追跡情報です
• サブエージェントの会話はスキップする（subagents/ サブディレクトリ内にあります）— ユーザーから依頼された場合を除きます

ステップ 3b：監査ログを解析する（デスクトップセッションのみ）

local-agent-mode-sessions/ の下で見つかった各 audit.jsonl を、1 行ずつ読み込みます。各行は、エージェントの 1 つの操作を記録した JSON レコードです。

{
  "type": "tool_call",
  "toolName": "Bash",
  "input": {"command": "npm test"},
  "output": "...",
  "timestamp": "2026-04-10T14:22:00Z",
  "sessionId": "..."
}

監査ログから抽出する情報：

• ファイルアクセスのパターン — エージェントが繰り返し Read または Edit するファイルはどれですか？これらはプロジェクト内で価値の高いファイルです。プロジェクトの参考資料として記録してください。
• シェルコマンド — 繰り返し実行される Bash コマンドから、プロジェクトのビルド／テスト／デプロイのワークフローがわかります。これらを skills/ ページにまとめてください（例：「このプロジェクトのビルドとテストの方法」）。
• ツール呼び出しの順序 — エージェントが常に特定の順番で Read → Edit → Bash を実行する場合、それは記録する価値のあるワークフローのパターンです。
• エラーパターン — 失敗したツール呼び出し（ゼロ以外の終了コード、エラー出力）から、問題点、既知の不具合、繰り返し発生するバグがわかります。
• MCP ツールの呼び出し — MCP ツールの呼び出しから、プロジェクトが連携している外部サービスや API がわかります。

監査ログから除外する情報：

• パターンのない日常的なファイル読み込み（例：設定ファイルを一度だけ読む）
• ノイズにすぎないツール出力（長いスタックトレース、冗長なログなど）。出力全体ではなく、エラーの種類を要約してください。
• コマンド引数や出力に含まれる、シークレット、トークン、認証情報と思われるもの

会話のトランスクリプトと相互参照する： 監査ログからは「何が起きたか」がわかり、会話からは「なぜ起きたか」がわかります。同じセッションについて両方がある場合は、併せて使用してください。監査ログによって、会話の内容を具体的な操作に基づいて確認できます。

監査ログを処理する前に、対応する local_<uuid>.json のセッションメタデータを読み込んでください。cwd、startedAt、title が記載されており、操作の背景を把握できます。

ステップ 4：トピックごとにまとめる

会話ごとに Wiki ページを 1 つ作成しないでください。代わりに、次のようにします。

• 会話をまたいで、抽出した知識をトピックごとにまとめる
• 「認証のデバッグと CI のセットアップ」についての 1 件の会話 → 2 つの別々のトピック
• 別々の日に行われた「React のパフォーマンス」に関する 3 件の会話 → 1 つの統合されたトピック
• プロジェクトディレクトリ名を、自然な最初のグループ分けとして使用する

ステップ 5：Wiki ページにまとめる

各 Claude プロジェクトは、Vault 内のプロジェクトディレクトリに対応します。~/.claude/projects/ のプロジェクトディレクトリ名には元のパスがエンコードされています。それをデコードして、わかりやすいプロジェクト名を取得します。

-Users/Documents/projects/my-Project   → myproject
-Users/Documents/projects/Another-app  → anotherapp

プロジェクト固有の知識とグローバルな知識

見つけたもの	格納先	例
プロジェクトのアーキテクチャ上の決定	projects/<name>/concepts/	projects/my-project/concepts/main-architecture.md
プロジェクト固有のデバッグ	projects/<name>/skills/	projects/my-project/skills/api-rate-limiting.md
ユーザーが学んだ一般的な概念	concepts/（グローバル）	concepts/react-server-components.md
プロジェクトをまたいで再発する問題	skills/（グローバル）	skills/debugging-hydration-errors.md
使用したツールやサービス	entities/（グローバル）	entities/vercel-functions.md
多くの会話に共通するパターン	synthesis/（グローバル）	synthesis/common-debugging-patterns.md

内容のあるプロジェクトごとに、projects/<name>/<name>.md にあるプロジェクト概要ページを作成または更新してください — 名前は _project.md ではなく、プロジェクト名にします。Obsidian のグラフビューではファイル名がノードのラベルとして使われるため、_project.md だとすべてのプロジェクトがグラフ上で _project として表示されてしまいます。<name>.md という名前にすることで、各プロジェクトに固有で読みやすいノード名が付きます。

重要: 会話ではなく、知識 を抽出してください。「3月15日の会話で、ユーザーは X について質問しました」とは書かないでください。知識そのものを書き、会話は出典の帰属として扱います。

新しい/更新されたすべてのページに summary: フロントマターフィールドを書いてください — 1〜2文、200文字以内で、ページを開いていない読者に向けて「このページは何についてのものか?」に答えるものです。wiki-query の低コストな検索経路はこのフィールドを読み、ページ本文を開かずに済ませます。

新しいすべてのページのフロントマターに confidence と lifecycle フィールドを追加してください:

base_confidence: 0.42
lifecycle: draft
lifecycle_changed: <obsidian-wiki memory now --date>

更新時には、lifecycle と lifecycle_changed は変更しないでください — lifecycle の状態を遷移させるのは人間の編集者だけです。

出所をマークしてください — llm-wiki の慣例（Provenance Markers セクション）に従います:

• メモリファイル はほとんどが抽出済みです — ユーザーが手で書き、すでに蒸留されています。複数のメモリファイルから主張をつなぎ合わせている場合を除き、メモリ由来の主張は抽出済みとして扱ってください。
• 会話の蒸留 はほとんどが推論です。多くの対話のターンから一貫した主張を合成しており、しばしば暗黙の推論を補っています。合成されたパターン、セッションをまたぐ一般化、「ユーザーが本当に言いたかったこと」の解釈には ^[inferred] を積極的に適用してください。
• ユーザーがセッションをまたいで考えを変えた場合や、アシスタントとユーザーが互いに矛盾し、その解決が不明確な場合は ^[ambiguous] を使用してください。
• 新しい/更新されたすべてのページに provenance: フロントマターブロックを書き、おおよその内訳をまとめてください。

ステップ 6: マニフェスト、ジャーナル、特殊ファイルを更新する

.manifest.json を更新する

処理したソースファイルごとに、そのエントリを追加/更新します:

• ingested_at、size_bytes、modified_at
• source_type: "claude_conversation"、"claude_memory"、"claude_audit_log"、"claude_desktop_session" のいずれか
• project: デコードされたプロジェクト名
• pages_created と pages_updated のリスト

また、マニフェストの projects セクションも更新します:

{
  "project-name": {
    "source_path": "~/.claude/projects/-Users-...",
    "vault_path": "projects/project-name",
    "last_ingested": "TIMESTAMP",
    "conversations_ingested": 5,
    "conversations_total": 8,
    "memory_files_ingested": 3,
    "desktop_sessions_ingested": 2,
    "audit_logs_ingested": 2
  }
}

ジャーナルエントリを作成し、特殊ファイルを更新する

index.md、log.md、hot.md を 1 回のロックされた呼び出しで更新します:

obsidian-wiki memory sync CLAUDE_HISTORY_INGEST \
  projects=<projects> conversations=<conversations> \
  desktop_sessions=<desktop_sessions> audit_logs=<audit_logs> \
  pages_updated=<pages_updated> pages_created=<pages_created> \
  mode=<mode> \
  --takeaways "Ingested 5 Claude conversations across 2 projects; surfaced patterns in API design and testing strategy."

index.md、log.md、hot.md を手で編集しないでください — このコマンドは、並行して書き込む別のライターがあなたの更新を失わせないようにするロックを取得します。--takeaways は、以前は Recent Activity に書かれていた 1 行の概念的な要約です。省略すると、以前の takeaways は変更されません。

進行中のプロジェクトについて以前よりよく理解できた場合は、次のセッションが引き継げるようにスレッドを記録してください: obsidian-wiki memory todo add "<thread>" --origin projects/<name>.md。

完全な手順については .skills/llm-wiki/references/MEMORY.md を参照してください。

プライバシー

• 要点を抽出して統合し、会話の生テキストをそのままコピーしないでください
• シークレット、API キー、パスワード、トークンと思われるものは除外してください
• 個人情報や機密情報に該当する内容があれば、含める前にユーザーに確認してください
• ユーザーの会話で他の人に言及している場合があります。Wiki に何を含めるか慎重に判断してください

参考資料

データ構造の詳細については、references/claude-data-format.md を参照してください。

Vault への書き込み後の QMD 更新

QMD は検索インデックスであり、信頼できる情報源ではありません。$QMD_WIKI_COLLECTION が空、または設定されていない場合は、この手順をスキップしてください。このスキルが Vault の Markdown を書き込みまたは書き換えた後にのみ実行してください。QMD の更新に失敗しても、Vault の変更をロールバックしないでください。QMD の状態は別途報告してください。

$QMD_CLI が設定されている場合はそれを使用し、そうでない場合は qmd を使用してください。

${QMD_CLI:-qmd} update

出力にベクトルが必要、または埋め込みが古い可能性があると示されている場合は、次を実行してください。

${QMD_CLI:-qmd} embed

次のいずれかでコレクションを検証してください。

${QMD_CLI:-qmd} ls "$QMD_WIKI_COLLECTION"

または、特定のページパスがわかっている場合は次を実行してください。

${QMD_CLI:-qmd} get "qmd://$QMD_WIKI_COLLECTION/<page>.md" -l 5

次のいずれかを記録してください。

• QMD refreshed: update + embed + verified
• QMD refreshed: update only + verified
• QMD skipped: QMD_WIKI_COLLECTION unset
• QMD skipped: qmd CLI unavailable
• QMD failed: <short error summary>