ナレッジオペレーション

ナレッジオペレーション は何をしますか？

複数のストアを横断してナレッジを取り込み、整理、同期、取得するための多層ナレッジシステムを管理します。

ライブワークスペースモデルを優先します:

• コード作業は実際のクローンしたリポジトリ内で行う
• アクティブな実行コンテキストはGitHub、Linear、リポジトリローカルの作業コンテキストファイルに置く
• より広範な人間向けのメモは、リポジトリ外のコンテキスト/アーカイブフォルダに保存できる
• 永続的なマシン間コンテキストは、シャドウリポジトリワークスペースではなくナレッジベースに属する

アクティブ化のタイミング

• ユーザーが情報をナレッジベースに保存したい場合
• ドキュメント、会話、データを構造化ストレージに取り込む場合
• システム間でナレッジを同期する場合（ローカルファイル、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に添付
• その後、ローカルメモを追加する価値がある場合のみミラーリングする

クロスソースナレッジ同期

複数のソースから一箇所にナレッジを集約:

• 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キー、パスワード）を編集する。
• ナレッジファイルには一貫した命名規則を使用する（小文字のケバブケース）。
• エントリにはトピック/カテゴリでタグを付け、検索しやすくする。

品質ゲート

ナレッジ操作を完了する前に:

• 重複エントリを作成していないこと
• Gitで追跡されるファイルから機密データが編集されていること
• インデックスと要約が更新されていること
• データタイプに適したストレージレイヤーが選択されていること
• 関連する相互参照が追加されていること