このレッスンで持ち帰るもの
- なぜ単一KBに統一しないか（一見矛盾する二重持ちの正当化）
- Obsidian/Notion/GitHubの役割の違い
- Claude Code auto-memoryという第四の保管庫
- 「集めても見返さない墓場」を生まない運用
「全部Notionで」を試した結果
岡本は最初、知識管理を全部Notionで統一しようとした。
3か月続けた結果、
- 起動が遅い（クラウド前提なので、手元でサッと開けない）
- 検索が弱い（マークダウンファイル全文grepの速度に勝てない）
- バージョン管理がない（履歴の差分追跡が難しい）
3つで詰まった。
保管工程は、目的別に複数あったほうがいい。これが今日の核となる主張。
1. Obsidian：速度のため
公式: obsidian.md
ローカルファイル（Markdown）として保管される。クラウドではない。
強み:
- 起動・検索が爆速（手元のファイルを直接開く）
- ファイル単位でVS Codeでも開ける、grep可能
- オフラインで動く
- プラグインで拡張可能
用途:
- Web Clipperの保存先
- 日々の思考メモ
- 一次情報のストック
弱点:
- チーム共有に向かない（同期はCloudの追加設定が要る）
- リッチなページレイアウトには弱い
2. Notion：共有のため
公式: notion.com
クラウド前提。チーム・組織で運用する情報置き場。
強み:
- リアルタイム共同編集
- ページレイアウトが豊か（テーブル・カレンダー・かんばん）
- 公開リンクで外部共有可能
用途:
- AMPL DASHBOARD（チーム運営の中心）
- 組織図・ロードマップ
- 公開可能な業務資料
弱点:
- 起動が遅い
- 検索が弱い
- ローカルバックアップが面倒
3. GitHub：コードと履歴のため
公式: github.com
コードリポジトリと、それに付随するドキュメントの置き場。
強み:
- バージョン管理（git）が標準
- コード関連の検索・差分追跡が完璧
- Issue/PR/Projectsでタスク管理も統合
- 公開リポでオープンソース貢献も可能
用途:
- 全アプリのコード（kgraph57アカウント）
- README・技術ドキュメント
- Issue管理（kgraph57/ai-medicine-tasks）
弱点:
- 文章メインの保管には過剰
- 非エンジニアには敷居が高い
4. Claude Code auto-memory：AIの記憶
~/.claude/projects/*/memory/ に保管される、AI側の記憶。
強み:
- AIが過去の会話・嗜好・プロジェクト文脈を覚えている
- 毎回ゼロから説明する必要がない
- インデックス（MEMORY.md）で全体を俯瞰できる
用途:
- 岡本のプロフィール・文体ルール・進行中プロジェクトの状態
- 「あの件どこまで進んだっけ」をAIが記憶している
弱点:
- AIに完全には委ねない（人間側の主軸はObsidian）
- 補助的な記憶として運用
二重持ちは「重複」ではなく「役割分担」
「ObsidianとNotionの両方持ったら、同じ情報が二重に書かれない？」
このリスクは確かにある。岡本のルールはシンプル。
速度優先の情報はObsidian、共有が必要なものはNotion、両方には置かない。
具体的には：
- 自分しか見ない一次情報・メモ → Obsidianのみ
- チーム・外部に共有する成果物 → Notionのみ
- どうしても両方欲しい場合 → Notion側に置いて、Obsidianに「Notionへのリンク」だけメモ
「同じ情報を別の場所に置く」のは禁止。常にどちらかが原本（source of truth）。
Vault設計の3つのルール
Web Clipperで集めた情報が「墓場」化しないために、Obsidian Vault側の設計を持っておく。
ルール1. フォルダは浅く（3階層まで）
00_Inbox/ ← クリップ直後の置き場
01_Notes/ ← 思考メモ
02_Resources/ ← 参考資料（クリップしたWeb記事など）
03_Projects/ ← 進行中プロジェクト
99_Archive/ ← 古いもの
階層を深くすると、どこに置くか考えるコストが上がる。3階層で止める。
ルール2. タグは行動で決める
カテゴリ（医療/経営/執筆）ではなく、行動（読む/書く/参考にする/捨てる）でタグを付ける。
#to-read 後で読む
#to-write 記事化候補
#reference 引用元として使う
#trash 削除候補
これだと使い道がはっきりするので、見返したときに次のアクションが決まる。
ルール3. 月1で棚卸し
月初に1時間取って、
#trashタグのものを実際に削除- 増えすぎたタグを統合
- 使ってないフォルダを
99_Archive/に移動
これをサボると、Vaultが「集めるだけの墓場」になる。道具のせいではなく、運用のサボりが原因だ。
保管・呼出工程まとめ
| 役割 | ツール | 何を置くか |
|---|---|---|
| 速度 | Obsidian | 一次情報・思考メモ・クリップ |
| 共有 | Notion | チーム運営・公開資料 |
| コード | GitHub | リポジトリ・技術ドキュメント |
| AIの記憶 | Claude Code memory | プロフィール・文体・進行状況 |
4つあるが、役割が明確に分かれている。
「全部一つに統一」を諦めることが、知識管理を破綻させない設計の出発点。
まとめ
- 単一KB（全部Notionなど）は3軸（速度・共有・コード）で必ず破綻する
- 4本柱で役割分担すれば、二重持ちは重複でなく設計になる
- Obsidian = 速度、Notion = 共有、GitHub = コード、Claude memory = AIの記憶
- Vault運用ルール3つ（3階層・行動タグ・月1棚卸し）を守れば墓場化しない
次のレッスンで
最後の工程、出力。
note・X・Vercel・slide-starterを使い分けながら、自分のスタック設計の実践課題を出す。