ナレッジオペレーション は何をしますか？
複数のストアにわたって知識を取り込み、整理、同期、検索するための多層ナレッジシステムを管理します。
ライブワークスペースモデルを推奨します:
- コード作業は実際のクローンしたリポジトリで行う
- アクティブな実行コンテキストはGitHub、Linear、リポジトリローカルのworking-contextファイルに置く
- より広範な人間向けのメモは、リポジトリ外のcontext/archiveフォルダに保存できる
- 永続的なマシン間コンテキストはナレッジベースに属し、シャドウリポジトリワークスペースには置かない
いつアクティブにするか
- ユーザーが情報をナレッジベースに保存したい場合
- ドキュメント、会話、データを構造化ストレージに取り込む場合
- システム間（ローカルファイル、MCPメモリ、Supabase、Gitリポジトリ）で知識を同期する場合
- 既存の知識の重複排除や整理を行う場合
- ユーザーが「これをKBに保存」「知識を同期」「Xについて何を知っている？」「これを取り込んで」「ナレッジベースを更新して」と言った場合
- 単純なメモリ想起を超えた、あらゆるナレッジ管理タスク
ナレッジアーキテクチャ
レイヤー1: アクティブ実行の真実
- ソース: GitHub issue、PR、ディスカッション、リリースノート、Linear issue/プロジェクト/ドキュメント
- 用途: 作業の現在の運用状態
- ルール: アクティブなエンジニアリング計画、ロードマップ、ロールアウト、リリースに影響する場合は、まずここに配置する
レイヤー2: Claude Codeメモリ（クイックアクセス）
- パス:
~/.claude/projects/*/memory/ - 形式: フロントマター付きMarkdownファイル
- タイプ: ユーザー設定、フィードバック、プロジェクトコンテキスト、リファレンス
- 用途: セッションをまたいで持続するクイックアクセスコンテキスト
- セッション開始時に自動読み込み
レイヤー3: MCPメモリサーバー（構造化ナレッジグラフ）
- アクセス: MCPメモリツール（create_entities、create_relations、add_observations、search_nodes）
- 用途: 保存されたすべてのメモリのセマンティック検索、関係性マッピング
- クエリ可能なグラフ構造によるセッション間の永続性
レイヤー4: ナレッジベースリポジトリ / 永続的ドキュメントストア
- 用途: 厳選された永続的なメモ、セッションエクスポート、統合された研究、オペレータメモリ、長文ドキュメント
- ルール: コンテンツがリポジトリ所有のコードでない場合、マシン間コンテキストのための推奨される永続ストア
レイヤー5: 外部データストア（Supabase、PostgreSQLなど）
- 用途: 構造化データ、大規模ドキュメントストレージ、全文検索
- 適している場合: メモリファイルには大きすぎるドキュメント、SQLクエリが必要なデータ
レイヤー6: ローカルコンテキスト/アーカイブフォルダ
- 用途: 人間向けのメモ、アーカイブされたゲームプラン、ローカルメディア整理、一時的な非コードドキュメント
- ルール: 情報保存のための書き込み可能だが、シャドウコードワークスペースではない
- 使用禁止: アクティブなコード変更や、上流に存在すべきリポジトリの真実
取り込みワークフロー
新しい知識をキャプチャする必要がある場合:
1. 分類
どのタイプの知識か？
- ビジネス上の決定 -> メモリファイル（プロジェクトタイプ） + MCPメモリ
- アクティブなロードマップ / リリース / 実装状態 -> まずGitHub + Linear
- 個人設定 -> メモリファイル（ユーザー/フィードバックタイプ）
- リファレンス情報 -> メモリファイル（リファレンスタイプ） + MCPメモリ
- 大規模ドキュメント -> 外部データストア + メモリにサマリー
- 会話/セッション -> ナレッジベースリポジトリ + メモリに短いサマリー
2. 重複排除
この知識が既に存在するか確認:
- メモリファイルで既存エントリを検索
- 関連用語でMCPメモリをクエリ
- 別のローカルメモを作成する前に、情報がGitHubやLinearに既に存在するか確認
- 重複を作成しない。代わりに既存エントリを更新する。
3. 保存
適切なレイヤーに書き込む:
- クイックアクセスのために常にClaude Codeメモリを更新
- セマンティック検索可能性と関係性マッピングのためにMCPメモリを使用
- 情報がライブプロジェクトの真実を変更する場合、まずGitHub / Linearを更新
- 永続的な長文追加のためにナレッジベースリポジトリにコミット
4. インデックス
関連するインデックスやサマリーファイルを更新する。
同期操作
会話同期
会話履歴を定期的にナレッジベースに同期:
- ソース: Claudeセッションファイル、Codexセッション、その他のエージェントセッション
- 宛先: ナレッジベースリポジトリ
- クイックブラウジング用のセッションインデックスを生成
- コミットしてプッシュ
ワークスペース状態同期
重要なワークスペース設定とスクリプトをナレッジベースにミラーリング:
- ディレクトリマップを生成
- コミット前に機密設定をマスク
- 経時変化を追跡
- ナレッジベースやアーカイブフォルダをライブコードワークスペースとして扱わない
GitHub / Linear同期
情報がアクティブな実行に影響する場合:
- 関連するGitHub issue、PR、ディスカッション、リリースノート、ロードマップスレッドを更新
- 作業に永続的な計画コンテキストが必要な場合は、関連ドキュメントをLinearに添付
- その後、ローカルメモは付加価値がある場合のみミラーリング
クロスソース知識同期
複数のソースから知識を1か所に集約:
- Claude/ChatGPT/Grokの会話エクスポート
- ブラウザブックマーク
- GitHubアクティビティイベント
- ステータスサマリーを書き込み、コミットしてプッシュ
メモリパターン
# 短期: 現在のセッションコンテキスト
セッション内タスク追跡にはTodoWriteを使用
# 中期: プロジェクトメモリファイル
セッション間の想起のために ~/.claude/projects/*/memory/ に書き込む
# 長期: GitHub / Linear / KB
アクティブな実行の真実はGitHub + Linearに置く
永続的な統合コンテキストはナレッジベースリポジトリに置く
# セマンティックレイヤー: MCPナレッジグラフ
永続的な構造化データには mcp__memory__create_entities を使用
関係性マッピングには mcp__memory__create_relations を使用
既知のエンティティに関する新しい事実には mcp__memory__add_observations を使用
既存の知識を見つけるには mcp__memory__search_nodes を使用
ベストプラクティス
- メモリファイルは簡潔に保つ。ファイルが際限なく大きくなるのを防ぐため、古いデータはアーカイブする。
- すべての知識ファイルのメタデータにはフロントマター（YAML）を使用する。
- 保存前に重複排除する。まず検索し、その後作成または更新する。
- 事実セットごとに1つの正規の保存先を優先する。ローカルメモ、リポジトリファイル、トラッカードキュメントに同じ計画の並列コピーを作成しない。
- Gitにコミットする前に機密情報（APIキー、パスワード）をマスクする。
- 知識ファイルには一貫した命名規則（lowercase-kebab-case）を使用する。
- エントリにはトピック/カテゴリのタグを付け、検索を容易にする。
品質ゲート
ナレッジ操作を完了する前に:
- 重複エントリが作成されていないこと
- Git追跡ファイルから機密データがマスクされていること
- インデックスとサマリーが更新されていること
- データタイプに適したストレージレイヤーが選択されていること
- 関連する相互参照が追加されていること