対象読者: 非エンジニア（専門用語は初出時に括弧で解説） 作成日: 2026-04-04 ステータス: Codexレビュー済み（v3 YAGNI縮小版）
┌─────────────────────────────────────────────┐
│ recall / Second-Brain（生データ層） │
│ 2,749件の会話ログがフラットに並んでいる │
│ 自動同期済み。grep検索で引ける │
└──────────────────┬──────────────────────────┘
│ ← ここに断絶がある
┌──────────────────▼──────────────────────────┐
│ memory（永続知識層） │
│ 29件の手動キュレーション済みメモ │
│ MEMORY.md がインデックス │
└──────────────────┬──────────────────────────┘
│
┌──────────────────▼──────────────────────────┐
│ CLAUDE.md / rules（行動ルール層） │
│ AIの振る舞いを規定 │
└─────────────────────────────────────────────┘
| # | 問題 | Karpathyの言葉で言うと |
|---|---|---|
| P1 | 蒸留されない: 2,749件の生ログから知識として抽出されたのは29件だけ（抽出率1%）。3年分の会話に埋もれた知見が再利用されていない | raw/ はあるが wiki/ がない |
| P2 | つながらない: 各ファイルが孤立している。「事業承継」の話と「不動産価格」の話が関連しているのに、リンクがない | バックリンク（逆方向のリンク）がない |
| P3 | 腐る: 古い情報が訂正されない。project_wellness_app_selection.md は「ユーザーが選ぶ予定」のまま放置されている可能性がある | lint（矛盾・欠損チェック）がない |
| P4 | ループしない: 新しい会話で得た知見が、既存の知識ベースに自動的に還元されない。毎回ゼロから調べ直すことがある | Q&A→wiki 還元ループがない |
| P5 | 全文検索頼み: recall search は強力だが、「この人はどんなテーマに興味があるか」「過去3ヶ月で何が変わったか」という俯瞰ができない | 要約・鳥瞰ビューがない |
Karpathy式の本質は「LLMで自動要約してObsidianに置く」ことではない。 「知識を編集可能な中間表現に蒸留して、人間とLLMが一緒に育てること」 がポイント。
topics/ に直接書き込む（新規作成 or 既存マージ）git diff で事後確認（問題があれば git checkout で戻せる）| Karpathyの要素 | 今の環境で対応するもの | 新たに作るもの |
|---|---|---|
| raw/ （生データ投入） | Second-Brain（自動同期済み） | 変更なし |
| LLM自動コンパイル （raw→wiki変換） | なし | compile（topics/直接書き込み） |
| wiki/ （整理された知識） | memory/（手動、29件のみ） | _generated/wiki/（トピック別） |
| Obsidian閲覧 | 既にObsidianで開ける | wiki/ もObsidianに配置 |
| Q&A→wiki還元ループ | なし | セッション終了時にキューへ積む |
| 定期lint | なし | 週次の鮮度・孤立チェック |
選択肢A: Second-Brain/_generated/wiki/ の中（Obsidian内・隔離配置） ← 採用
選択肢B: memory/ の中（Claude Code内）
選択肢C: 別ディレクトリ
選択肢Aを採用する理由:
_generated/ で隔離する理由（Codexレビュー指摘）:
_generated/ 配下に置けば、Obsidianから見える利点は維持しつつ、混線を防げるmemory/ は今のまま残す:
┌──────────────────────────────────────────────────────────────┐
│ Second-Brain（Obsidian） │
│ │
│ *.md（既存の2,749件） _generated/wiki/（新設・隔離） │
│ ├─ 2023-03-08_商工... ├─ topics/ │
│ ├─ 2026-04-04_案C... │ ├─ 事業承継.md │
│ └─ ... │ ├─ AI秘書運用.md │
│ │ └─ ... │
│ ┌──────────┐ └─ _index.md │
│ │ 自動同期 │ │
│ │ (既存) │ Phase 0: 手動でwiki/を書く │
│ └────┬─────┘ Phase 1+: raw→LLM→topics/直接書き込み │
│ │ │
│ ▼ │
│ Session終了 → raw に会話ログ保存 │
└──────────────────────────────────────────────────────────────┘
ポイント: Phase 0 は手動、Phase 1+ でLLMが直接書き込み
Phase 0: raw/ を参考に → 手動で wiki/ を書く
Phase 1+: raw/ → LLM → topics/ に直接書き込み（事後確認は git diff）
_generated/
└── wiki/
├── _index.md ← 全トピックの一覧（MOC = Map of Contents。compileで自動再生成）
├── .last_compiled ← 最終compile日（次回の新着検出に使用）
├── changelog.md ← compile実行ログ
└── topics/ ← テーマ別の知識ページ（compileが直接書き込み）
├── 事業承継.md
├── AI秘書体制.md
├── LINE-Bot開発.md
└── ...
---
title: 事業承継
aliases: [相原家事業承継, 相和不動産]
---
# 事業承継
## 概要（必須）
（2-3文のサマリー）
## 現在の状態（必須）
（最新の状況。日付入り）
## 出典（必須）
- [[2026-03-20_相原家事業承継_全体整理]]
- [[2025-12-15_相和不動産設立...]]
## 経緯（任意: 書けるなら書く）
- 2025-12-15: 相和不動産設立
- 2026-01-xx: タクト契約
- ...
## 関連トピック（任意: リンク先が存在する場合のみ）
- [[LINE-Bot開発]] — 事業管理ツールとしての可能性
## 未解決・要確認（任意: あれば書く）
- 根抵当権のボトルネック（最終確認: 2026-03-20）
ポイント:
[[二重括弧]] はObsidianのリンク記法。これがバックリンクを自動生成するsource_count、confidence、last_compiled は初期では不要 = YAGNI）現在のフォーカス: Phase 1 完了。 Phase 2以降は Phase 1 の使用感を見てから設計する。
やったこと:
Second-Brain/_generated/wiki/ ディレクトリを作成_index.md を作成実装物: ~/.claude/scripts/compile-wiki.sh
処理フロー:
.last_compiled に記録）claude -p --model sonnet に読ませて、既存wikiトピックとの整合性を考慮topics/ に直接書き込み（新規作成 or 既存トピックをマージ上書き）_index.md を自動再生成（topics/ の内容から）changelog.md に処理ログを追記git diff で事後確認オプション:
--dry-run: 処理対象の確認のみ（LLM呼び出しなし）--since YYYY-MM-DD: 指定日以降のファイルを処理--limit N: 処理件数の上限（デフォルト50）日次自動実行: LaunchAgent で毎朝9時に実行（com.aiharataketo.compile-wiki.plist）
Codexレビュー: LGTM取得済み（2026-04-04、Critical 0件）
| 既存の仕組み | 影響 | 対策 |
|---|---|---|
| Second-Brain 自動同期（Stop hook） | なし | _generated/ は raw とは別ディレクトリなので干渉しない |
| memory/ | なし | wiki/ とは役割が別。memory は「AIへの指示」、wiki は「整理された知識」 |
| recall search | 要対応 | Phase 0 で _index.md を開く手順を用意（後述）。エイリアス実装は Phase 1 |
| CLAUDE.md | なし | ルール層は変更しない |
| plan-viewer 自動変換 | なし | plans/ と wiki/ は別パス |
| Obsidian iCloud同期 | 低リスク | _generated/ 配下なのでノイズは限定的。更新頻度も低い |
recall との導線について（Codexレビュー指摘）:
_index.md を開く手順だけ用意（Obsidianで _index を検索、またはターミナルで cat する）alias wiki='cat .../_index.md'）を .zshrc に追加iCloud競合への現実的な対策:
.conflict ファイルを残して人間が判断 セッション1: 事業承継について相談
│
▼
queue に積まれる → compile → 候補メモ生成
│
▼ 人間が確認
wiki/事業承継.md が更新される
│
セッション2: 不動産の相場を調べる
│
▼
同じフロー → wiki/不動産投資.md が更新
→ 事業承継.md にもリンクが追加（関連トピック）
│
セッション3: 「事業承継と不動産、全体でどうなってる？」
│
▼
LLMが wiki/ を読むだけで全体像を把握できる
（raw/ 2,749件を検索する必要がない）
注意: 複利は自動では回らない
Phase 0 完了後:
| # | 基準 | 測定方法 |
|---|---|---|
| S1 | Obsidianでwiki/ のグラフビューが表示される | 目視確認 |
| S2 | 3トピックのうち少なくとも1つについて、raw検索なしで wiki だけを根拠に要約回答できる | 新規セッションで試す |
| S3 | raw/ の既存ログを壊していない | recall search が正常動作 |
Phase 1 の成功基準は Phase 0 の使用感を見てから定義する。
Phase 0 [手動パイロット] ✅ 完了
└→ _generated/wiki/ 作成、3トピック手書き、Obsidian確認
Phase 1 [compile] ✅ 完了（2026-04-04）
└→ ~/.claude/scripts/compile-wiki.sh 実装、Codex LGTM
Phase 2〜3 ← Phase 1 の使用感を見てから設計する
各Phaseは独立して価値を出せる。途中でやめても壊れない。
以下は設計の縮小判断の根拠であり、現時点の実装対象ではない。
初版(v1)→v2 に対してCodex（GPT-5.4）のレビューを実施。v3（YAGNI縮小）でも再レビュー済み（Critical 0件）。
| 指摘 | 対応 |
|---|---|
| Phase 1 の compile が wiki に直接書き込むのは品質不安定。話題が混ざるセッションで誤追記が起きる | 候補メモ（candidates/）生成 に縮小。wiki反映は人間確認後 |
| Phase 2 の Stop hook に LLM判定+更新を入れるのは複雑すぎる。失敗の切り分けが困難 | queue.jsonl に積むだけ に縮小。wiki更新は別コマンド |
| wiki/ を Obsidian 直下に置くと人間メモとノイズが混ざる | _generated/wiki/ に隔離配置 |
| recall CLI から wiki が見えないとUXが二重化する | Phase 1 で CLI導線（エイリアス）を用意 |
| 指摘 | 対応 |
|---|---|
| 「LLMは下書き係、人間が編集責任者」が不明確 | §2-1 に大原則として明記 |
source_count, confidence は初期では維持コスト高い |
フロントマターから削除（YAGNI） |
| 「追加API費用なし」は期待値を誤らせる | 「処理時間と精度が主な制約」に書き換え |
| 矛盾検出は難しすぎる（Phase 3には重い） | Phase 4以降に延期。初版は鮮度+孤立のみ |
| iCloud競合はファイルロックだけでは不十分 | 小ファイル分割+低頻度更新+.conflict 保全 |
| YAGNIリストに「自動リライト禁止」「自動マージ禁止」がない | 追加 |