セカンドブレイン2.0 実装設計書

📌 入力：2026-07-06_x_articles_digest 記事11（Machina）・記事12（チャエン）／chaenmasahiro0425/exbrain リポジトリ実物調査／うちの .claude/rules/・memory/・_stock/discord/・launchd・30_departments/02_CTO/automation/ の現状確認。

1. 現状マップ（記事の4層 × うちの実体）

記事11・12はどちらも同じ「raw / wiki / digest / identity」の4層モデルを提示している。うちの実体を当てはめると以下の通り。骨格は8割方一致しているが、層の「所有者を1人に固定する」という設計思想がうちには明文化されていない。

もう一つの構造的な違い：exbrainは「vault全体が1つのgitリポジトリ」を前提に、raw層の改変をgit diffで検知して自動復元する安全弁を持つ。うちは

• _stock/discord/ が .gitignore で丸ごと除外（git管理外）
• memory/（auto-memory本体）が ~/.claude/projects/-Users-natsumi-workspace/memory/ にあり、workspaceのgitリポジトリの外（git status すると fatal: not a git repository）

という2点で、exbrainのgitベース安全弁がそのままは使えない。これは②夜間コンパイラの設計に直接影響する重要な発見（詳細は2-②のリスク項目参照）。

2. 4ピースの実装設計

①書き手1人固定＋raw不可侵ルール

.claude/rules/second-brain-layers.md として新規作成する条文案（このまま採用可能な形）：

# セカンドブレイン4層モデル：書き手固定・raw不可侵ルール

workspaceの記録を「誰が・どこに・何を書くか」で4層に固定する。層をまたいだ書き込みを禁止することで、同期競合・上書き事故・記憶の劣化を構造的に防ぐ。

## 4層と書き手（唯一の所有者）

| 層 | 場所 | 書き手（これ以外は書かない） |
|---|---|---|
| raw（生ログ・不可侵） | `_stock/discord/`／`notes/drops_inbox.md` | 自動取得スクリプト（discord-daily-rebuild.py）＋ナツミの一次ドロップのみ。**クロちゃんは追記のみ可・書き換え禁止** |
| wiki（編纂知識） | `notes/resources/`（entities/concepts含む）／`20_companies/*/communication_log.md` | 夜間コンパイラ＋クロちゃんの通常編集。出典リンク必須 |
| digest（直近文脈） | `memory/daily/`／`MEMORY.md` | クロちゃん（セッション内 or 夜間コンパイラ後段） |
| identity（人格・線引き） | `memory/user_*.md`／`10_personal/`／CLAUDE.md絶対ルール | ナツミの発言起点でのみクロちゃんが更新提案 → **ナツミの承認後に確定**（plan-confirm-executeに準拠。自動更新禁止） |

## raw不可侵の運用ルール

1. `_stock/discord/*.md` はナツミもクロちゃんも**内容を書き換えない**（誤字修正含め触らない）。訂正が必要なら別ファイルに注記を足す
2. 夜間コンパイラ（second-brain-compile想定）は raw層への書き込み権限を一切持たない（allowedToolsで物理的に不可能にする。詳細は2-②）
3. rawを直接読んで要約・分析する行為（Read）は自由。書き込み（Write/Edit）だけ禁止

## 改訂履歴
- 2026-07-07：初版作成（[2026-07-07_second_brain_2_design](second_brain_design.html) 由来）

• 工数：ルール文の確定＋保存で30分程度。低リスク（既存rules運用の延長）。
• リスク：ほぼなし。ただし「identityはナツミ承認後に確定」の運用は既存のplan-confirm-executeと二重管理にならないよう、rule-governance.mdの「1テーマ1マスター」原則に沿ってこのファイルをマスターにし、他は参照リンクのみにする必要がある。

②夜間コンパイラ

何を作るか：既存の com.natsumi.discord-daily-backup（毎日3:00・discord-daily-rebuild.py）の後段に、second-brain-compile.py（仮称）を追加する。

どう動くか（案）

1. 3:00の生ログ取得完了を待つ（launchdを2本の独立ジョブにせず、discord-daily-rebuild.py の正常終了後に同一シェルから呼び出す形にして競合を防ぐ。exbrainは「未コンパイル日を最大3日分キャッチアップ」する設計だが、うちも同様に前回コンパイル済み日付を system/.compile-state 的なファイルに記録し、抜けを追いかける）
2. claude -p をheadlessで起動。モデルは Haiku（claude-haiku-4-5、フォールバックSonnet 5）
3. プロンプトで読ませるもの：前日の _stock/discord/YYYY-MM-DD_discord_raw.md（生ログ）＋その日の memory/daily/YYYY-MM-DD_daily.md（サマリーがあれば）
4. 更新させる場所：notes/resources/entities/（人物・ツール・組織、③参照）と notes/resources/concepts/（学び・パターンの抽象ページ）のみ。既存記述は消さず追記、出典に _stock/discord/YYYY-MM-DD_discord_raw を必ず付与
5. open-loops.md 相当（未解決の宙ぶらりん）を更新する案もあるが、うちはNotion Tasks DBがタスクの唯一マスターなのでタスク化はしない。あくまで「まだ結論が出ていない検討事項」のメモ欄として使うなら新設可（judgment point候補）

使用モデル・cronタイミング

• モデル：Haiku（安価・ルーティン作業向け）。exbrainと同じ「routine work, routine tier」思想
• タイミング：3:00の生ログ取得後（体感5〜15分後・実測して固定オフセットを決める）

暴走防止3点（exbrainの3原則をうちの環境向けに調整）

1. LLMにgitを触らせない：--allowedTools "Read" "Write" "Edit" "Glob" "Grep" のみ。git操作コマンドはスクリプト側だけが持つ（exbrainと同じ）
2. 書ける層を制限する：プロンプトで明示的に「書いてよいのは notes/resources/entities/ と notes/resources/concepts/ の配下のみ。_stock/・memory/・10_personal/・.claude/・20_companies/のクライアント案件ファイルには一切触れるな」と指示する。ただしこれはプロンプトによる"お願いベース"の制御であり、exbrainのような技術的な強制力（cwd外への書き込みそのものが不可能）ではない（次項のリスク参照）
3. raw変更の自動復元：exbrainはgit checkoutで機械的に復元するが、うちはこれがそのままは使えない（下記リスク参照）。代替案：
   • notes/resources/ 配下（wiki層）は通常どおりworkspaceのgit管理下にあるため、コンパイラ実行後に git diff を取り、意図した2ディレクトリ以外に変更があれば git checkout -- で復元する、という部分的な安全弁は機能する
   • ただし _stock/discord/（gitignore対象・追跡外）と memory/（workspaceの外・別リポジトリですらない）はgit差分検知の対象外。この2つについては、コンパイラ実行前後で対象ファイルの mtime とハッシュを記録し、変化があれば警告する簡易チェック（シェルスクリプト側で実装可能）で代替するか、もしくは _stock/discord/*.md を実行後に chmod 444（読み取り専用）にする技術的な書き込み禁止を追加するのが確実

🚨 リスク（正直に・過小見積もりしない）

1. git安全弁の不完全性：上記の通り、raw層（_stock/discord/）とidentity層（memory/）はどちらもworkspaceのgit管理範囲外。exbrainの「暴走してもgit checkoutで一発復元」という前提がそのままでは成立しない。chmod読み取り専用化などの技術的な担保を別途組む必要がある（判断ポイント③）
2. 週間利用枠の消費有無が未検証：claude -p のheadless呼び出しが、日中のインタラクティブセッションと同じ週間利用制限枠を消費するのか未確認。もし消費するなら、夜間の無人ジョブが翌日のFable 5作業時間を圧迫するリスクがある。本番投入前に軽量プロンプトで1回実測すべき
3. 初回チューニングの手間：exbrainは3ヶ月運用した実績の上のv2なので枯れているが、うちはゼロから作るため「wikiページの粒度」「出典リンクの付け方」「entities新規作成の閾値（乱造防止）」を数日〜1週間 log を目視確認しながら調整する期間が必要。「作ったその日から無人で信頼できる」状態にはならない
4. daily要約が手動生成前提：現状 memory/daily/*.md サマリーは人力生成が多く毎日確実に存在するとは限らない。コンパイラが「サマリーがなければ生ログのみで編纂する」フォールバックを持たないと、抜け漏れが出る

工数見積もり：スクリプト初期実装 2〜3時間＋安全策（chmod・部分git diff検知）実装 1時間＋実測・チューニング期間 1〜2週間（毎朝ログを数分チェック）。「導入した瞬間から手離れする」設計ではなく、最初の1〜2週間は運用監視コストがかかる。

③entities層＋賞味期限メタ

ディレクトリ設計案

新規トップレベル 60_entities/ は作らず、既存の「wiki層の家」である notes/resources/ 配下に揃える（knowledge_workflow.mdの既存パス設計思想と整合させるため）：

notes/resources/entities/
├── people/       # 人物1人1ページ（例：megumi.md／midori.md／makoto.md）
├── orgs/         # クライアント企業・組織（例：prof.md／lsc.md／rexli.md）
└── tools/        # ツール・サービス（例：notion.md／discord_mcp.md）

notes/resources/concepts/
└── <テーマ>.md   # 戦略・学びの抽象パターン1テーマ1ページ

既存資産との関係（判断ポイント候補）

• memory/reference_prof_team.md／reference_midori_writer_projectf.md／reference_makoto_nakamura.md／reference_lukestyle_spelling.md は、内容的にはすでにentities層相当（人物・組織の1ページ完結情報）だが、置き場所がauto-memory（本来はidentity/digest寄りの領域）になっている
• 20_companies/*/communication_log.md は時系列ログであり、entities（現在の状態を1ページに集約したもの）とは性質が違う。両者は共存可能（communication_logがraw〜wiki編纂前の材料、entitiesが編纂後の「今の状態」1枚）

frontmatterの賞味期限メタ

• 全ページ共通で updated: は必須（既に多くのmdで採用済み）
• リサーチ・競合分析・市場動向など「鮮度が命」の資産にのみ expires: を追加：

---
type: research
updated: 2026-07-07
expires: 2026-10-07
---

• 期限切れ検出は④のbrain-lint.sh移植で自動化する想定（LLM不使用・python3の決定論チェックなので導入コストが低い）

工数見積もり：ディレクトリ＋テンプレート作成 30分〜1時間（MVP）。初期の数ページ（プロF関係者・主要クライアント）の埋め込みに1〜2時間。全既存資産のバックフィル（過去のreference_*.mdを全部entities形式に書き直す）は別スコープとし、今回はやらない（Maximizer暴発防止・段階移行）。

④exbrain流用リスト（chaenmasahiro0425/exbrain実物調査結果）

リポジトリは実際にアクセスでき、README（日英）・vault-template/一式・launchd/一式・scripts/一式を確認できた（未調査ではない）。

3. 今夜の残りラン（A/B/C/D/F）への影響

この設計を踏まえて出力先を変えるべきかを確認した結果、大半は変更不要（既存のルーティングルールがすでに正しい層に置いている）。

• B-4 AI分身プロファイル（15問インタビュー）：内容的に完全にidentity層。現状も memory/user_*.md＋10_personal/への保存＋ナツミ発言起点の更新というフローで、今回整理した「identityはナツミ承認後に確定」の原則とすでに一致している。変更不要。強いて言えば専用の memory/user_ai_persona_profile.md（1ファイル集約）にするかは今夜の実行時に決めればよい程度
• C-1 noteネタ10個：wiki/concepts寄りの発信資産。既存のoutput-routing-hatsushin-neta.mdルールに沿ってsns_ideas.md等に置く運用で問題なし。変更不要。将来的に「note ネタの型」が繰り返しパターンとして固まれば notes/resources/concepts/note_idea_patterns.md に昇格させる余地はあるが、今夜のスコープではない
• D-5 分析プロンプト集：ツール・スキル寄りの資産で、現状の.claude/skills/またはnotes/resources/への保存で問題なし。変更不要
• D-6 パーソナルアプリ設計／D-7 プロFアプリ要件定義：クライアント・自分プロジェクト向けの要件定義書。20_companies/prof/等への保存で問題なし（wiki/clients層として妥当）。変更不要

→ 結論：今夜のラン自体の出力先変更は不要。今回の設計が明らかにしたのは「既存のルーティングは概ね正しい」という答え合わせであり、変更が必要なのはあくまで**足りていない自動化の仕組み（②③）**の方。

4. 実行順の提案（関所でOKが出た場合・7/8以降）

Fable 5の無料窓は閉じるため、7/8以降はSonnet/Opusでの通常作業として扱う。

合計工数目安：手を動かす時間としては5〜8時間程度だが、②の監視期間を含めると実質1週間強のカレンダー時間がかかる。「すぐ終わる」タスクではない。

5. 判断ポイント（3つ以内）

1. 夜間コンパイラの安全策をどこまで技術的に担保するか：raw層（_stock/discord/）とidentity層（memory/）はgitの管理範囲外なので、exbrainの「git checkoutで自動復元」がそのまま使えない。chmodでの物理的な書き込み禁止まで実装するか、まずはプロンプト制約だけで様子見するか
2. entitiesの置き場所と既存資産の扱い：新設する notes/resources/entities/ に統一するか、既存の memory/reference_*.md（人物・組織系）をそのまま残して二重管理にするか、それとも段階的に「卒業」させてentities側に一本化するか
3. 夜間コンパイラの claude -p headless呼び出しが週間利用枠を消費するか：本番投入前に実測が必要。消費するなら日中のFable 5/Sonnet作業時間を圧迫するため、導入タイミングやモデル選定（Haiku固定 vs 状況に応じて変更）を再検討する必要がある

関連ファイル

• 2026-07-06_x_articles_digest — 元記事（Machina記事11・チャエン記事12）
• layer3_action_plan — 今週のラン全体計画（今夜の残りラン一覧の出典）
• knowledge_workflow — 既存のナレッジ保存先ルール（notes/resources/構造の既定）
• .claude/rules/rule-governance.md — ルール改訂ガバナンス（1テーマ1マスター原則。①のルール新設時に整合させる）
• .claude/rules/daily_log.md — デイリーログ運用（digest層の現行ルール）
• [外部] chaenmasahiro0425/exbrain — 実装元リポジトリ（README日英・vault-template・scripts・launchd一式を確認済み）

改訂履歴

• 2026-07-07：初版作成。ナツミ承認済み（7/7 03:04「Eを今サクッとやって」）。Machina/チャエン記事2本の検証結果＋exbrainリポジトリ実物調査＋うちの現状（rules 25本・memory 103ファイル・_stock/discordがgitignore対象・memoryがworkspaceリポジトリ外）を突き合わせて4ピースの実装設計を作成。