title: "04 知識管理" icon: "📚"

04 知識管理

Claude Code は非常に有能力な AI アシスタントですが、一つ大きな特徴があります。それは「セッションごとに記憶がリセットされる」ということです。今日は覚えていたことも、次回のセッションでは完全从头来过。この問題を解決し、AIとの作業をずっと快適にするのが「知識管理」です。

04-1 問題: AI は前回のことを忘れないけない

Claude Code で作業していて、こんな経験はないでしょうか。

前回選んだ技術構成を忘れてしまって、また一から議論のやり直しになった
前回解決したバグの方法を覚えていれば効率的だったのに
「あのコマンド、どこかで使ったんだけど…」と找不到

これは Claude Code の欠陥ではなく、设计上の特性です。セッションが終わるたびに、AI の文脈はクリアされます。これはセキュリティとプライバシーのためです。しかし、你打ち上げNpcle毎回同じ山脉を登るのは非効率です。

そこで重要になるのが「Single Source of Truth（SSOT）」、つまり「唯一の正しい情報源」という概念です。

04-2 解決策: SSOT（唯一の正しい情報源）を構築する

SSOT とは、特定のテーマに関するすべての意思決定、知識、判断を記録する场所です。AI はこの記録を読み込むことで、前回の続きからすぐに作業を開始できます。

記録すべき内容

具体的に何を記録すれよいでしょうか。以下のカテゴリーを意識しましょう。

技術的な意思決定

なぜ A より B を選んだのか
アーキテクチャの決定理由
使用しているライブラリやツールのバージョン情報

バグと解決策

遭遇したバグの内容
解決までに試したこと
最終的な解決方法

便利コマンド・パターン

よく使うCLIコマンド
定型的な作業フロー
デバッグのコツ

日次ログのフォーマット

毎日作業後に簡単に記録する習慣をつけましょう。フォーマットは以下の通りです。

##2024-06-01

### やったこと
-プロジェクト X のセットアップ完了
- ログイン機能を実装

### うまくいったこと
- カスタムフックで自動バックアップが正しく動作した

### うまくいかなかったこと
- 当初予定していたライブラリ A が環境と合わず切换
- →代わりにライブラリ B を使用することに决定

### 次のアクション
- ユーザー認証のテストを書く
- ドキュメントの整備

このような简単な记录があれば、次のセッションで迷わずスタートできます。

04-3 ファイルの整理方法

記録が増えすぎると找不到になります。以下の原则で整理しましょう。

プロジェクト単位でグループ化する プロジェクトごとにフォルダを分けることで、関連情報が一目でわかります。

命名規則を一貫させる 日付形式は YYYY-MM-DD で统一しましょう。また、前缀に用途を示すキーワードをつけるのがおすすめです（例：todo_、memo_、decision_）。

サンプルフォルダ構成

project/
├── .claude/
│   ├── settings.json          # Claude Code の設定
│   ├── hooks.json # 自動化フック設定
│   └── memory/
│       └── MEMORY.md          # メインメモリー（索引）
├── docs/
│   ├── config/
│   │   ├── 全体マップ_MOC.md   # 全 Topics の索引
│   │   ├── バックログ.md # 未完了タスク一覧
│   │   └── プロジェクト概要.md
│   ├── 01_DECISIONS/
│   │   ├── 技術選定.md         # なぜこの技術を選んだか
│   │   ├── アーキテクチャ.md   # システム構成の記録
│   │   └──  問題と解決.md   # 遭遇したバグと対策
│   └── 02_LOGS/
│       ├── 2024-06-01.md      # 日次作業ログ
│       ├── 2024-06-02.md
│       └── 2024-06-03.md
├── src/                       # ソースコード
├── tests/                     # テストコード
└── README.md                  # プロジェクト概要

この構成では .claude/ フォルダに Claude Code 用の設定とメモリを置き、docs/ フォルダに人が読むドキュメントを配置します。こうすることで、AI 用と人用の情報が混在しません。

04-4 ドキュメンテーションを习惯にする

「記録する時間がない」は，最大的誤解です。記録は5分もかかりません。また、記録する行为自体が思考の整理になり、実業務でも有用です。

毎日5分の投資 作業終了時に、今日何をしたか簡単にメモする習慣をつけます。箇条書きで十分です。

その场その場で记录 决策をした瞬間に、その理由を記録します。あとから思い出そうとしても大致忘れてしまいます。

「あとで書く」は絶対しない その场で書けないなら、书く资格がないということです。思考が新鮮なうちに記録しましょう。

04-5 ツールとしての Markdown

知识管理に Markdown は最適なフォーマットです。

シンプル:メモ帳でも開いて書ける
読みやすい: プレビューなしでも构成がわかる
どこでも動く: PCでもスマホでも、特別なソフト不要
差分が見やすい: Git と組み合わせて変更履歴を管理できる

Claude Code は Markdown を标准で理解できますので、記録した Markdownファイルを直接読ませて、AI と共有知识として活用できます。

graph TD subgraph "🧠 メモリシステム" AUTO["Auto Memory
~/.claude/projects/"] USER["User Memory
~/.claude/CLAUDE.md"] PROJ["Project Memory
repo/CLAUDE.md"] IDX["MEMORY.md
インデックス"] end AUTO --> T1["user: 役割・目標"] AUTO --> T2["feedback: 指導"] AUTO --> T3["project: 決定事項"] AUTO --> T4["reference: 外部参照"] IDX --> AUTO

04-6 応用：CLAUDE.md の 3 層メモリ構造

プロジェクトが増えてくると、「どのルールをどこに書くか」が問題になります。すべてを 1 つの CLAUDE.md に詰め込むと肥大化し（200行超）、逆に「詳細は別ファイル参照」と間接リンクすると AI が本当に読むか怪しくなります。この矛盾を解決するのが 3 層構造 です。

3 層の考え方

層	役割	読み込み
層1: 常時展開	毎回 AI が自動で読む核心ルール	セッション起動時に全プロジェクトで自動
層2: パススコープ	特定の言語/作業のルール	該当ファイルを触る時だけ自動
層3: スキル/参照	スキル・詳細資料	トリガーや強指示で確実に読む

層1 の一元管理（@import）

共通ルール（セキュリティ・コーディング原則・記録・LLMルーティング等）は rules/_shared/ に 1 箇所まとめ、グローバル CLAUDE.md から @import で取り込みます。こうすると:

共通ルールの変更が 1 箇所で済む（DRY 原則）
各プロジェクトの CLAUDE.md は固有内容だけ（重複ゼロ）
グローバルで 1 回 import すれば全プロジェクトに自動で届く

~/.claude/
├── CLAUDE.md          核心ルール（60-80行）
└── rules/_shared/     共通ルール原本（各10-20行）
    ├── セキュリティ.md
    ├── コーディング原則.md
    ├── 記録.md
    └── LLMルーティング.md

設計のポイント

200行以下: メイン CLAUDE.md は核心だけ。詳細は層3（参照資料）へ
具体命令化: 「詳細は〇〇.md参照」より @import で常時展開する方が確実
パス指定ロード: 言語別ルールは層2に（Python触る時だけ Pythonルール読む）
Instruction vs Learning: 人間が書くルール（CLAUDE.md）と AI が蓄積する記憶（memory/）は分離する

この構造は Z.AI が公開しているベストプラクティスに基づいています。プロジェクトが複数にまたがる本格運用で威力を発揮します。