Coder DB - AI Memory Enhancement System

Coder DB - AI メモリ強化システム

Claude Desktop と MCP サーバーを使用したデータベース統合により、コーディング能力を高める AI アシスタント向けの構造化メモリシステムです。

概要

このシステムでは、複数の種類のデータベースを活用して、コーディング支援のための包括的なメモリシステムを構築します。

1. Qdrant ベクトルデータベース：コードパターンのセマンティック検索と取得に使用します
2. SQLite データベース：アルゴリズムの構造化された保存とバージョン管理に使用します
3. ナレッジグラフ：コーディング概念間の関係の表現に使用します

データベースの使用ガイド

Qdrant メモリストレージ

コードスニペット、パターン、ソリューションを意味に基づいて保存・取得します。

保存する内容：

• 説明付きの再利用可能なコードパターン
• 複雑な問題に対するソリューション
• ベストプラクティスとデザインパターン
• ドキュメントの断片と説明

拡張メタデータ：

• 言語とフレームワークの詳細
• 複雑度（シンプル、中級、上級）
• 依存関係と要件
• 品質指標（循環的複雑度、ドキュメントの網羅率）
• ユーザーからのフィードバックと評価

使用例：

# Storing a code pattern
information = {
    "type": "code_pattern",
    "language": "python",
    "name": "Context Manager Pattern",
    "code": "class MyContextManager:\n    def __enter__(self):\n        # Setup code\n        return self\n    def __exit__(self, exc_type, exc_val, exc_tb):\n        # Cleanup code\n        pass",
    "explanation": "Context managers provide a clean way to manage resources like file handles.",
    "tags": ["python", "resource management", "context manager"],
    "complexity": "intermediate",
    "quality_metrics": {
        "cyclomatic_complexity": 2,
        "documentation_coverage": 0.85
    },
    "user_rating": 4.5
}
# Store in Qdrant

SQLite アルゴリズムデータベース

適切なバージョン管理を行いながら、アルゴリズムの構造化されたカタログを管理します。

データベーススキーマ：

• algorithms：アルゴリズムの基本情報（名前、説明）
• algorithm_versions：アルゴリズム実装の各バージョン
• algorithm_categories：ソート、検索、グラフなどのカテゴリ
• performance_metrics：各実装のパフォーマンスデータ
• improvements：バージョン間で追跡された改善点
• change_logs：変更の理由や背景を含む詳細な変更ログ

バージョン差分：

• アルゴリズムの各バージョン間の差分を保存します
• バージョン間のパフォーマンス改善を追跡します
• 変更の理由を記録します

クエリ例：

-- Find all sorting algorithms with performance metrics
SELECT a.name, a.description, v.version_number, p.time_complexity, p.space_complexity
FROM algorithms a
JOIN algorithm_versions v ON a.id = v.algorithm_id
JOIN performance_metrics p ON v.id = p.version_id
JOIN algorithm_category_mapping m ON a.id = m.algorithm_id
JOIN algorithm_categories c ON m.category_id = c.id
WHERE c.name = 'Sorting'
ORDER BY a.name, v.version_number DESC;

-- Get change logs for a specific algorithm
SELECT v.version_number, c.change_description, c.rationale, c.created_at
FROM algorithm_versions v
JOIN change_logs c ON v.id = c.version_id
WHERE v.algorithm_id = 5
ORDER BY v.version_number;

ナレッジグラフの統合

コーディングの概念、パターン、ソリューション間の複雑な関係を表現します。

高度なオントロジー：

• アルゴリズム
• デザインパターン
• コード概念
• 問題の種類
• ソリューション
• フレームワーク
• ライブラリ
• 言語

多様な関係タイプ：

• IMPLEMENTS（アルゴリズム → コード概念）
• SOLVES（デザインパターン → 問題の種類）
• OPTIMIZES（アルゴリズム → パフォーマンス）
• RELATED_TO（任意の要素 → 任意の要素）
• IMPROVES_UPON（ソリューション → ソリューション）
• ALTERNATIVELY_SOLVES（ソリューション → 問題の種類）
• EXTENDS（パターン → パターン）
• DEPENDS_ON（ソリューション → ライブラリ）
• COMPATIBLE_WITH（フレームワーク → 言語）

グラフ分析：

• 頻繁に共起するパターンを特定します
• コーディング手法における新たな傾向を発見します
• 問題領域とソリューションのアプローチを対応付けます

使用ワークフロー

1. 問題解決の強化ワークフロー

新しいコーディングの問題に直面した場合：

1. コンテキストの収集：

   • 問題と制約を明確に定義します
   • パフォーマンス要件と環境の詳細を特定します
   • プロジェクト固有の考慮事項を記録します

2. メモリへの問い合わせ：

   • 順次的思考を用いて問題を分解します
   • 類似するソリューションを Qdrant に問い合わせます：qdrant-find-memories("efficient way to traverse binary tree")
   • 言語、複雑度、品質指標で結果を絞り込みます
   • 関連するアルゴリズムをアルゴリズムデータベースで確認します：SELECT * FROM algorithms WHERE name LIKE '%tree%'
   • 関連する概念や代替アプローチをナレッジグラフで調べます

3. ソリューションの適用：

   • REPL でソリューションをテストし、検証します
   • パフォーマンス特性を記録します
   • 代替案と比較します

4. フィードバックループ：

   • 成功したソリューションを詳細なメタデータとともに Qdrant に保存し直します
   • パフォーマンス指標と使用時のコンテキストを記録します
   • ナレッジグラフのつながりを更新します

2. パターンの学習と保存

有用なパターンを見つけた場合：

1. ドキュメントの自動生成：

   • AI ツールを使用して初期ドキュメントを生成します
   • 詳細な使用例を含めます
   • エッジケースと制限事項を記録します

2. 品質評価：

   • リンターと静的解析ツールを実行して、コード品質を確保します
   • 品質指標を計算して保存します
   • ベストプラクティスに照らして検証します

3. メタデータの拡充：

   • 明確な例を使ってパターンを記録します
   • 包括的なメタデータ（言語、複雑さ、依存関係）を追加します
   • 管理された語彙に基づき、一貫性のあるタグ付けを行います

4. ナレッジの統合：

   • 適切なタグと説明を付けて Qdrant に保存します
   • 関連する概念とのナレッジグラフ上のつながりを作成します
   • アルゴリズムの実装であれば、SQL データベースにも追加します
   • コンテンツの類似性に基づいて、自動的につながりを提案します

3. プロジェクトのセットアップとボイラープレート

新しいプロジェクトを開始する場合：

1. テンプレートの選択：

   • プロジェクトテンプレートのライブラリから選択します
   • プロジェクトの要件に合わせてカスタマイズします
   • 言語、フレームワーク、テストツールを選択します

2. セットアップの自動化：

   • 適切なディレクトリ構成でプロジェクト構造を生成します
   • 適切な .gitignore を設定してバージョン管理をセットアップします
   • リンティングツールとコード品質ツールを設定します
   • テストフレームワークを初期化します

3. ベストプラクティスの統合：

   • メモリーシステムを検索し、関連するボイラープレートコードを取得します
   • プロジェクトの種類に応じたベストプラクティスを取得します
   • 保存されているドキュメントテンプレートを初期セットアップに使用します
   • プロジェクトの要件に基づいて CI/CD を設定します

セキュリティとデータの整合性

1. アクセス制御：

   • 機密性の高いコードリポジトリに対するロールベースのアクセス制御
   • メモリーの閲覧と変更に対する権限

2. バックアップと復旧：

   • Qdrant および SQLite データベースを定期的にバックアップします
   • ナレッジグラフをバージョン管理します
   • データ破損に備えた復旧手順を用意します

3. 機密情報：

   • 機密データを削除するために、コード例をサニタイズします
   • 保存する前にコードスニペットを検証します
   • 機密性の高いパターンにフラグを付け、アクセスを制限します

モニタリングと分析

1. 使用状況の追跡：

   • 最も頻繁に取得されるパターンを監視します
   • ナレッジの不足を特定するため、検索クエリのパターンを追跡します
   • ユーザーの評価とフィードバックを記録します

2. パフォーマンス指標：

   • データベースの応答時間を監視します
   • メモリーの使用量とスケーリング要件を追跡します
   • 使用状況のパターンに基づいてクエリを最適化します

メンテナンスのガイドライン

1. 量より質：品質が高く、十分にドキュメント化されたコードのみを保存します
2. 定期的なレビュー：保存したパターンを定期的に確認し、更新します
3. コンテキストを含めた保存：保存する各パターンに使用コンテキストを含めます
4. バージョン管理：改善内容とバージョンを SQLite で追跡します
5. 一貫したタグ付け：検索性を高めるため、管理された語彙を使用します
6. パフォーマンスの最適化：データベースクエリを定期的に最適化します
7. フィードバックの統合：使用状況のフィードバックに基づいてパターンを更新します

はじめに

1. 最初のコードメモリーを保存します：

   qdrant-store-memory(json.dumps({
       "type": "code_pattern",
       "name": "Python decorator pattern",
       "code": "def my_decorator(func):\n    def wrapper(*args, **kwargs):\n        # Do something before\n        result = func(*args, **kwargs)\n        # Do something after\n        return result\n    return wrapper",
       "explanation": "Decorators provide a way to modify functions without changing their code.",
       "tags": ["python", "decorator", "metaprogramming"],
       "complexity": "intermediate"
   }))
   

2. 後で取得します：

   qdrant-find-memories("python decorator pattern")
   

今後の機能拡張

• 保存前の高度なコード品質評価
• バージョン管理システムとの統合
• 使用パターンから学習して検索性を向上
• ドキュメントの自動生成
• シームレスにアクセスできるカスタム IDE プラグイン
• マルチモーダルな保存（コード、図、説明）
• クエリ用の自然言語インターフェース
• パフォーマンスベンチマークデータベース
• MCP サーバーと DB のインストールスクリプト

MCP サーバー

MCP（Model Context Protocol）サーバーは、AI モデルが Coder DB メモリーシステムとやり取りするための標準化されたインターフェースを提供します。FastAPI と Uvicorn を使用して構築されています。

プロジェクト構成（mcp_server/）

mcp_server ディレクトリには FastAPI アプリケーションが含まれています：

mcp_server/
├── core/                 # Core logic, Pydantic models, configuration
│   ├── __init__.py
│   ├── config.py         # Application settings
│   └── models.py         # Pydantic data models
├── database/             # Database connectors and SQLAlchemy models
│   ├── __init__.py
│   ├── qdrant_connector.py # Logic for Qdrant vector database
│   ├── sqlite_connector.py # Logic for SQLite relational database
│   └── sql_models.py     # SQLAlchemy ORM models for SQLite
├── routers/              # FastAPI routers for different API endpoints
│   ├── __init__.py
│   ├── algorithm.py      # Endpoints for /algorithm
│   ├── health.py         # Endpoint for /health
│   └── memory.py         # Endpoints for /memory
├── tests/                # Unit and integration tests
│   ├── __init__.py
│   ├── test_algorithm_api.py
│   ├── test_health.py
│   └── test_memory_api.py
├── main.py               # Main FastAPI application setup and startup
└── pyproject.toml        # Project dependencies and metadata (using Poetry)

（注：requirements.txt は以前のセットアップの一部です。pyproject.toml と Poetry のみを使用する場合は削除できます。）

セットアップと実行

このプロジェクトでは、依存関係の管理とパッケージ化に Poetry を使用します。

1. Poetry のインストール（まだインストールしていない場合）： Poetry のウェブサイトに記載されている手順に従ってください。

2. 依存関係のインストール： pyproject.toml があるディレクトリ（自己完結型の Poetry プロジェクトとして作成した場合は mcp_server ディレクトリ、大規模な Poetry プロジェクトのサブパッケージとして mcp_server を配置している場合は、このリポジトリのルート）に移動し、次を実行します：

   poetry install --with dev # --with dev includes testing dependencies
   

   仮想環境（このプロジェクト用のものが存在しない場合）を作成し、すべての依存関係をインストールします。

3. 環境設定（任意ですが推奨）： アプリケーションでは、mcp_server/core/config.py で定義された設定を使用します。uvicorn を実行するディレクトリ（通常はリポジトリのルート、またはそこから実行する場合は mcp_server/）に .env ファイルを作成すると、これらの設定を上書きできます。 .env ファイルの内容例：

   # mcp_server/.env or project_root/.env
   # QDRANT_HOST="your_qdrant_host_if_not_localhost" # Overrides default 'localhost'
   # QDRANT_PORT=6334                               # Overrides default 6333
   # QDRANT_API_KEY="your_qdrant_api_key_if_any"
   # SQLITE_DATABASE_URL="sqlite+aiosqlite:///./custom_mcp_data.db" # Overrides default ./mcp_server.db
   # SQLITE_ECHO_LOG=True                           # To see SQLAlchemy logs
   

   利用可能な設定については、mcp_server/core/config.py を参照してください。

4. 開発サーバーの実行： Poetry 環境が有効になっていることを確認してください（たとえば、pyproject.toml があるディレクトリで poetry shell を実行します）。または、コマンドの前に poetry run を付けてください。 リポジトリのルート（mcp_server フォルダーがあるディレクトリ）から、次を実行します：

   poetry run uvicorn mcp_server.main:app --reload --host 0.0.0.0 --port 8000
   

   サーバーは http://127.0.0.1:8000 で利用できます。

   • 対話型 API ドキュメント（Swagger UI）：http://127.0.0.1:8000/docs
   • 代替 API ドキュメント（ReDoc）：http://127.0.0.1:8000/redoc

テストの実行

開発用の依存関係をインストールした状態で（poetry install --with dev）： リポジトリのルートから：

poetry run pytest

mcp_server/tests/ ディレクトリ内のテストを検出して実行します。

API エンドポイント

サーバーでは現在、次の主要な API エンドポイントを公開しています。リクエスト／レスポンスモデルの詳細を確認し、実際に試すには、サーバーの実行中に /docs URL にアクセスしてください。

• システムエンドポイント（タグ：System）

  • GET /：サーバーの基本情報を提供します。
  • GET /health：シンプルなヘルスチェックエンドポイントです。{"status": "OK"} を返します。

• メモリ管理エンドポイント（タグ：Memory Management、プレフィックス：/memory）

  • POST /memory/store：新しいメモリ項目（コードパターン、解決策、ドキュメントのスニペットなど）を Qdrant ベクトルデータベースに保存します。
    • リクエストボディ：StoreMemoryRequest（MemoryItem を含む JSON オブジェクト）。
    • レスポンス：StoreMemoryResponse（保存された項目の ID とステータスを含む JSON オブジェクト）。
  • POST /memory/find：自然言語クエリやフィルターに基づいて、Qdrant 内のメモリ項目を検索します。
    • リクエストボディ：FindMemoryRequest（クエリ文字列、件数制限、言語、タグ、複雑さなどの任意のフィルターを含む JSON オブジェクト）。
    • レスポンス：FindMemoryResponse（一致する MemoryItem のリストと件数を含む JSON オブジェクト）。

• アルゴリズム管理エンドポイント（タグ：Algorithm Management、プレフィックス：/algorithm）

  • POST /algorithm/store：新しいアルゴリズム、または既存のアルゴリズムの新しいバージョンを SQLite データベースに保存します。
    • リクエストボディ：StoreAlgorithmRequest（バージョンを含む Algorithm データを含む JSON オブジェクト）。
    • レスポンス：StoreAlgorithmResponse（保存または更新されたアルゴリズムの ID とステータスを含む JSON オブジェクト）。
  • POST /algorithm/find：名前またはカテゴリで SQLite データベース内のアルゴリズムを検索します。
    • リクエストボディ：FindAlgorithmRequest（name と category の任意のフィールドを含む JSON オブジェクト）。
    • レスポンス：FindAlgorithmResponse（一致する Algorithm のリストと件数を含む JSON オブジェクト）。

• コレクション管理エンドポイント（タグ：Collection Management、プレフィックス：/coder/collections）

  • POST /coder/collections/create：新しい Qdrant コレクションを作成します。
    • リクエストボディ：CreateCollectionRequest（collection_name と任意の model_name を含む JSON オブジェクト）。model_name を省略した場合は、サーバー設定で指定されたデフォルトの埋め込みモデルが使用されます。モデル名とベクトルサイズは、コレクションのメタデータに保存されます。
    • レスポンス：コレクション名と適用された埋め込みモデル情報を含む確認メッセージ。
  • GET /coder/collections/{collection_name}/info：特定の Qdrant コレクションの情報を取得します。コレクションの設定と関連付けられた埋め込みモデルのメタデータが含まれます。
    • パスパラメーター：collection_name。
    • レスポンス：コレクションの詳細（ステータス、ポイント／ベクトル数、設定）と埋め込みモデルのメタデータを含む JSON オブジェクト。

埋め込みの管理

サーバーでは、Qdrant にメモリを保存・検索するために、実際のテキスト埋め込み（FastEmbed ライブラリ経由）を使用するようになりました。

• デフォルトモデル：サーバーにはデフォルトの埋め込みモデル（例：sentence-transformers/all-MiniLM-L6-v2）が設定されています。特定のモデルが指定されていない場合、新しいコレクションのデフォルトのベクトルサイズには、このモデルの次元数が使用されます。
• コレクション固有のモデル：/coder/collections/create エンドポイントからコレクションを作成する際に、別のサポート対象 FastEmbed モデルを指定できます。選択したモデル名とそのベクトル次元数はコレクションに関連付けられ、メタデータに保存されます。この次元数は、Qdrant でそのコレクションのベクトルパラメーターを設定する際に使用されます。
• 動的な埋め込み：メモリを保存または検索する際：
  • システムは、対象の Qdrant コレクションのメタデータを確認して、適切な埋め込みモデル（およびそのベクトル次元数）を特定します。
  • このモデル固有のメタデータがないコレクション（例：外部で作成されたコレクションや、この機能の実装前に作成されたコレクション）にメモリを保存または検索する場合は、サーバーに設定されたデフォルトの埋め込みモデルとその次元数が使用されます。
  • 既存のコレクションを対象としない store_memory 操作では、create_coder_collection を使用してコレクションの作成を試みます。この暗黙的な作成でモデルが指定されていない場合は、デフォルトモデルとその設定が新しいコレクションに適用されます。
  • その後、実際のテキスト（例：memory_item.explanation や memory_item.code）が、特定されたプロバイダーを使用して埋め込まれてから Qdrant に送信されます。
• サポート対象モデル：EnhancedEmbeddingModelManager には、サポート対象の FastEmbed モデルとそのプロパティの定義済みリストがあります。このリストは拡張できます。

ナレッジグラフ（Neo4j）との統合（初期実装）

サーバーに、ナレッジグラフデータベースとして Neo4j との初期統合が追加されました。これは3つ目のコアデータベースタイプであり、コーディングの概念、保存されたメモリ項目、アルゴリズム間の複雑な関係を表現し、クエリできるようにします。

• 目的：

  • 「メモリ項目 X は言語 Y を使用する」「アルゴリズム Z は概念 A の一種である」「概念 B は概念 C と関連している」といった関係をモデル化します。
  • 保存された知識の、より高度なコンテキスト理解、発見、ナビゲーションを可能にします。
  • 将来の分析機能（例：接続の多い概念の特定、グラフの経路に基づく関連メモリの提案）の基盤として機能します。

• セットアップ要件：

  • Neo4j のインスタンスが稼働していること（制約で IF NOT EXISTS 句をサポートするバージョン 4.4 または 5.x を推奨）。
  • 接続パラメーター（URL、ユーザー、パスワード、データベース名）は、mcp_server/core/config.py または環境変数（例：NEO4J_URL、NEO4J_USER、NEO4J_PASSWORD、NEO4J_DATABASE_NAME）で設定する必要があります。デフォルト値は、URL が bolt://localhost:7687、ユーザーが neo4j、パスワードが password、データベース名が neo4j です。
  • neo4j Python ドライバー（例：neo4j>=5.17.0）がプロジェクトの依存関係に追加されています（pyproject.toml を参照）。

• 初期化：

  • アプリケーションの起動時に、サーバーは非同期 Neo4j ドライバーを初期化します。
  • また、主要なノードプロパティ（例：KGConcept.name、KGMemory.memory_id、KGAlgorithm.algorithm_id）の一意性を確保するため、基本的なスキーマ制約の作成も試みます。これらの操作は冪等です。

• 現在のナレッジグラフのスキーマノード（初期定義）：

  • :KGConcept：抽象的な概念を表します。
    • プロパティ：name（文字列、一意）、type（文字列。例：'language'、'framework'、'tag'、'methodology'、'algorithm_category'、'memory_type'）、description（任意の文字列）、created_at（日時）。
  • :KGMemory：Qdrant に保存され、グラフにリンクされる MemoryItem を表します。
    • プロパティ：memory_id（文字列、一意。通常は Qdrant のポイント ID または内部 UUID）、name（文字列、メモリー項目の名前）、type（文字列、'code_pattern' などのメモリー項目の種類）、created_at（日時）。
  • :KGAlgorithm：SQLite に保存され、グラフにリンクされる Algorithm を表します。
    • プロパティ：algorithm_id（整数、一意。SQLite の主キー）、name（文字列）、category（文字列）、created_at（日時）。

• リレーションシップ（初期定義）：

  • メモリー項目は、汎用リレーションシップ [:KG_RELATED_TO {type: "SPECIFIC_REL_TYPE"}] を使用して概念にリンクされます。リレーションシップの type プロパティに意味上の関係を格納します。例：
    • (:KGMemory)-[:KG_RELATED_TO {type: "USES_LANGUAGE"}]->(:KGConcept {name: "Python"})
    • (:KGMemory)-[:KG_RELATED_TO {type: "TAGGED_WITH"}]->(:KGConcept {name: "asyncio"})
    • (:KGMemory)-[:KG_RELATED_TO {type: "IS_OF_TYPE"}]->(:KGConcept {name: "code_pattern"})

• ナレッジグラフの API エンドポイント（プレフィックス：/kg）：

  • POST /kg/concept：:KGConcept ノードを作成またはマージします。
    • リクエストボディ：KGConcept モデル（name、type、description）。
    • レスポンス：作成またはマージされた概念の詳細。
  • POST /kg/link_memory_to_concept：メモリー項目を概念にリンクします。存在しない場合は :KGMemory ノードと :KGConcept ノードを作成してから、リレーションシップを作成またはマージします。
    • リクエストボディ：LinkMemoryToConceptRequest（memory_id、memory_name、memory_type、concept_name、concept_type、relationship_type）。
    • レスポンス：リンクの確認。
  • GET /kg/memory_item/{memory_id}/related_concepts：指定された :KGMemory ノード（memory_id で識別）に直接リンクされたすべての :KGConcept ノードと、リレーションシップの種類を取得します。
    • レスポンス：名前、種類、説明、リレーションシップの種類を含む概念の一覧。

• ナレッジグラフの自動更新：

  • POST /memory/store エンドポイントを通じて新しい MemoryItem が保存されるとき：
    1. Qdrant の memory_id を使用して、対応する :KGMemory ノードを Neo4j に作成またはマージします。
    2. メモリー項目の language（存在する場合）、各 tags、およびその項目自体の type（例：'code_pattern'）に対する :KGConcept ノードを作成またはマージします。
    3. 次に、適切な KG_RELATED_TO リレーションシップ（例：type: "USES_LANGUAGE"、type: "TAGGED_WITH"、type: "IS_OF_TYPE"）を使用して、:KGMemory ノードをこれらの :KGConcept ノードにリンクします。
  • これにより、新しいメモリーが追加される際に、ナレッジグラフ内で自動的にコンテキスト化されます。

この初期の Neo4j 統合により、Coder DB のビジョンで示されている、より高度な知識表現やグラフベースのクエリ機能を構築するための基盤が整います。今後は、スキーマの拡張、リレーションシップの種類の追加、アルゴリズムのグラフへの統合、より複雑な分析クエリの開発に取り組む予定です。