突然ですが、AIコーディングツールを使っていて、こんな経験はありませんか?
- PRレビューで「これ、前回も同じこと指摘しましたよね?」と言われた
- AIが実装した内容の意図や背景が後から見返した時に分からない
- 新しいセッションを開くたびに、プロジェクトの説明を一からやり直している
- 「この設計、なんでこうしたんですか?」と聞かれて、AIが書いたから答えられなかった
- CLAUDE.mdにルールを書いたのに、3ヶ月で誰もメンテしなくなった
- プロジェクトAで踏んだ地雷を、プロジェクトBでまた踏んだ
1つでも当てはまった方は、おそらくこの記事で扱う課題に心当たりがあるはずです。
Claude CodeやCursorのおかげで、コードを書く速度は確実に上がりました。でも「知識が積み上がっている感覚」はありますか? 自分にはありませんでした。
速くなったのは「書く」だけで、「学ぶ」が消えている。この課題を解決するために、knowledgineというOSSを作りました。
knowledgineとは
knowledgineは、開発中に蓄積される知識(デバッグメモ、設計判断、過去の失敗と解決策)を自動で構造化して、AIコーディングツールに渡すためのOSSです。
普段書いているMarkdownノートやGitのコミット履歴から「あのとき何が問題で、どう解決したか」を自動抽出し、Claude DesktopやCursorがそれを参照できるようにします。AIが過去の知見を踏まえたうえでコードを書いてくれるようになる、というのがknowledgineで実現したかったことです。
データはすべてローカルに保存されるので、クラウドに開発ノートを送る必要はありません。
ここから先は、なぜこのツールが必要だったのか、どんな仕組みで動いているのかを書いていきます。
AIコーディングで見えてきた3つの摩擦
1. 記憶はある。でも「使われている感」がない
CLAUDE.mdにプロジェクトのルールを書きました。コーディング規約も、アーキテクチャの方針も全部入れています。
AIはそれを「読んでいる」けど、「覚えて活かしている」感じがしません。セッションが変わればリセット。先週3時間かけて解決したデバッグの知見は、次のセッションでは跡形もなく消えています。
人間のペアプロ相手なら「あ、それ先週やったやつですよね」と言ってくれます。AIにはその「先週」がありません。
2. 同じミスが何度でも帰ってくる
「このAPIはレート制限があるからリトライを入れて」。3回目です。
「このテーブルにはソフトデリートを使って」。2回目です。
AIが悪いわけではありません。「前回こういうミスをして、こう直した」という文脈がどこにも保存されていないのが根本原因です。AIは毎回まっさらな状態で最善を尽くしています。ただ「最善」の基準に過去の失敗が含まれていません。
3. 「なんでこの設計にしたんですか?」に答えられない
チームメンバーから「この認証周り、なんでJWTじゃなくてセッションベースにしたんですか?」と聞かれて、答えられませんでした。AIが書いたからです。
commit messageには feat: add user authentication としか書いてありません。なぜこのライブラリを選んだのか、なぜこの設計パターンにしたのか。意思決定の過程が丸ごと消えています。
コードは残ります。でもコードの「意図」は残りません。
では、この文脈をどうやってAIに渡せばいいのか。最初に思いついたのはCLAUDE.mdでした。
CLAUDE.mdで解決できるか?
最初のアプローチはCLAUDE.mdにルールをひたすら書くことでした。
## プロジェクトルール
- APIコールにはリトライを入れる(3回、exponential backoff)
- テーブル設計はソフトデリート
- 認証はセッションベース(JWTは使わない。理由: ~~)
- Zodでバリデーション、throwしない
最初の1ヶ月は機能しました。でも3つの壁にぶつかりました。
まず、手動メンテが続きません。デバッグで学んだことをCLAUDE.mdに毎回転記する作業は、1ヶ月で慣れ、3ヶ月で義務感に変わり、半年で形骸化します。(自分の場合は2ヶ月で形骸化しました)
次に、「何を」は残せても「なぜ」が残らない。認証はセッションベース とだけ書いても、3ヶ月後には「なんでだっけ?」となります。JWTとの比較検討、トークン管理コスト、プロジェクト規模に対する判断。そういう過程が全部抜け落ちる。
そして、プロジェクトが増えると破綻します。5つを超えたとき、CLAUDE.mdの管理自体が一仕事になりました。しかもプロジェクトAで学んだことがプロジェクトBに共有されない。
CLAUDE.mdは「ルールブック」であって「記憶」ではありません。この違いに気づいたとき、そもそも開発者にとっての「記憶」とは何なのかを考え直しました。
既存のAI記憶ツールでは解決しない理由
既存の「AI記憶」ソリューションを調べました。ChatGPT Memory、Mem0、Zep。どれも同じアプローチです。
AIとの会話ログから「好み・設定・事実」を覚える仕組み、つまり Conversational Memory です。「TypeScriptが好き」「タブよりスペース派」。こういった情報を覚えるのは得意です。
でも開発者が本当に必要としているのは Developer Memory です。
- あのバグは結局何が原因で、どう直したか
- この設計を選んだ理由と、捨てた選択肢
- このライブラリのこのAPIにはこういう罠がある
- 前回のパフォーマンスチューニングで効いた施策
Conversational Memory(会話の記憶)
→ チャットログから好み・設定・事実を記憶
→ 「あなたのことを覚えている」
→ 例: ChatGPT Memory, Mem0, Zep
Developer Memory(開発の知識)
→ コード・コミット・ドキュメントから
「何が問題で、どう解決したか」を構造化
→ 「あなたのプロジェクトの歴史を知っている」
→ 例: knowledgine
会話を覚えるのではなく、プロジェクトの知識を構造化してAIに渡す。これがknowledgineのコンセプトです。
実際にLongMemEvalベンチマーク(長期記憶の評価データセット)で比較すると、Mem0が49.0%、Zepが71.0%に対して、knowledgineは73.2%を達成しています。(ただしknowledgineはルールベースジャッジ、他はLLMジャッジのため、単純比較には注意が必要です)
では、具体的にどうやって「開発の知識」を自動で拾い上げるのか。ここからはknowledgineの仕組みを説明します。
Problem-Solution Pair Mining:知識の自動抽出
knowledgineの核は、Markdownファイルから知識を自動抽出するエンジンです。
たとえば、こんなデバッグメモがあったとします。
# Next.js App Routerでのキャッシュ問題
`fetch`がデフォルトでキャッシュされる仕様を知らなくて、
古いデータが表示され続けるバグに3時間ハマった。
## 解決策
`fetch`に`{ cache: 'no-store' }`を明示的に指定する。
または`export const dynamic = 'force-dynamic'`をpage.tsxに追加。
knowledgineはこのメモを読んで、自動的に構造化します。
- 問題: Next.js App Routerのfetchデフォルトキャッシュによる古いデータ表示
- 解決:
cache: 'no-store'の明示指定 ordynamic = 'force-dynamic' - エンティティ: Next.js, App Router, fetch API, キャッシュ
- 関連: 他のNext.jsメモと自動リンク
内部では ProblemSolutionDetector がパターンベースで「Error:」「Failed to」「TypeError」などの問題キーワードと、解決策のセクションを検出しています。同一ノート内のペアだけでなく、ノート間のペア(問題ノートと解決ノートが別ファイル)も、キーワード類似度(Jaccard係数0.3以上)と時間制約(30日以内)で自動検出します。
次にAIがNext.jsのfetchを書くとき、MCPサーバー経由でこの知識が自動的に渡されます。人間が何もしなくても、メモを書いた時点で知識はシステムに蓄積されています。
ただし、すべての知識を同じ重みで扱うと検索ノイズが増えます。そこで、知識の「層」を分けました。
3層メモリアーキテクチャ
knowledgineは知識を3つのレイヤーで管理します。
| レイヤー | 説明 | 自動昇格条件 |
|---|---|---|
| Episodic(エピソード記憶) | 直近のセッションで得た短期的な知識 | 3回以上参照されると昇格 |
| Semantic(意味的知識) | プロジェクト固有の中期的な知識 | 10回以上参照されると昇格 |
| Procedural(手続的知識) | プロジェクト横断で使える長期的な知識 | 最上層(昇格なし) |
ポイントは「自動昇格」です。繰り返し参照される知識は、自動的にEpisodic → Semantic → Proceduralへと昇格していきます。よく使われる知識ほど長期記憶に定着する、人間の記憶モデルと同じ発想です。
MCPのメモリツール(store_memory / recall_memory / update_memory / forget_memory)を通じてAIアシスタントが直接読み書きでき、バージョン管理にも対応しています。
仕組みはわかった、でもデータはどこに保存されるのか。これが設計上の最大の論点でした。
100%ローカル、$0
開発ノートには機密情報が含まれます。社内のAPI設計、未公開機能の仕様、デバッグログに紛れ込む顧客データ。これをクラウドに送る選択肢は、少なくとも個人開発者向けのv1では、ありませんでした。
knowledgineのデータはすべてローカルのSQLiteファイル1つに収まります。
- 埋め込みモデルもローカルで動作(ONNXランタイム、約23MBのモデルファイル)
- APIキー不要
- ネットワーク接続なしで完全に動作
- DB初期化 4.6ms、マイグレーション 2.2ms
クイックスタート(30秒)
# 1. インストール
npm install -g @knowledgine/cli
# 2. ノートをインデックス
knowledgine init --path ./my-notes
# 3. AIツールに接続
knowledgine setup --target claude-desktop --path ./my-notes --write
Claude Desktopを再起動すれば、AIがノートを参照できるようになります。
セマンティック検索を有効にする場合は、--semantic フラグを追加します。
knowledgine init --path ./my-notes --semantic
約23MBの埋め込みモデルが自動ダウンロードされ、以降はキーワード一致だけでなく「意味的に近い」ノートも検索対象になります。
インストールせずに試したい場合は、デモモードがあります。
npx @knowledgine/cli init --demo --path /tmp/knowledgine-demo
npx @knowledgine/cli search "React performance" --path /tmp/knowledgine-demo/knowledgine-demo-notes
13のAIツールに対応
MCPサーバーとして動作するため、MCP対応のAIツールならどれでも接続できます。setup --target で設定を自動生成します。
| カテゴリ | 対応ツール |
|---|---|
| Anthropic公式 | Claude Desktop, Claude Code |
| AI IDE / エディタ | Cursor, Windsurf, VS Code, Zed |
| CLIエージェント | OpenAI Codex CLI, GitHub Copilot CLI, Gemini CLI, Cline |
| その他 | opencode, Continue.dev, Antigravity |
# 例:Cursorに接続
knowledgine setup --target cursor --path ./my-notes --write
# 例:Claude Code(stdioモード)
knowledgine start --path ./my-notes
AIに提供される11のツール
接続すると、AIアシスタントに以下のツールが追加されます。
知識検索ツール(7個)
| ツール | 機能 |
|---|---|
search_knowledge |
キーワード・セマンティック・ハイブリッド検索 |
find_related |
関連ノートを最大3ホップで探索 |
get_stats |
知識ベースの統計 |
search_entities |
エンティティグラフの検索(人物・技術・プロジェクト・概念) |
get_entity_graph |
エンティティの関係グラフ全体を取得 |
capture_knowledge |
その場で知識をキャプチャ・保存 |
report_extraction_error |
抽出ミスのフィードバック |
メモリ管理ツール(4個)
| ツール | 機能 |
|---|---|
store_memory |
3層(episodic/semantic/procedural)にメモリを保存 |
recall_memory |
層・タグ・日付範囲で検索 |
update_memory |
バージョン管理付きで更新 |
forget_memory |
ソフト削除/ハード削除 |
AIが「この技術について過去に知見がないか?」と判断したとき、search_knowledgeを自動で呼んで関連する知識を返します。人間が「あのメモを参照して」と指示する必要はありません。
knowledgine startを実行しておけばファイル監視が常駐するので、Markdownを保存した瞬間にインデックスが更新されます。
7つのIngestプラグイン
Markdownノート以外のソースからも知識を取り込めます。現在7つのプラグインが実装済みです。
| プラグイン | ソース | 何を取り込むか |
|---|---|---|
markdown |
ローカルのMarkdownファイル | 本文、フロントマター、パターン |
git-history |
Gitコミット履歴 | コミットメッセージ、変更ファイル |
github |
GitHub PR・Issue | コメント、レビュー、ディスカッション |
obsidian |
Obsidian Vault | フロントマター、Wikilink、タグ構造 |
claude-sessions |
Claude Codeセッション | セッション要約、問題解決ログ |
cursor-sessions |
Cursorセッション | セッション内容 |
cicd |
GitHub Actions | 実行履歴、失敗情報、エラーログ |
# Gitのコミット履歴から(直近100件)
knowledgine ingest git-history --path ./my-project
# GitHubのIssue・PRから
knowledgine ingest github --repo owner/repo
# Obsidianのプロパティとリンク構造を活用
knowledgine ingest obsidian --path ./my-vault
# Claude Codeのセッションログから
knowledgine ingest claude-sessions --path ~/.claude/projects
# CI/CDの失敗履歴から
knowledgine ingest cicd --repo owner/repo
fix: NPE when user is null というコミットメッセージがあれば、「NullPointerExceptionの原因はuserのnullチェック漏れ」というProblem-Solutionペアとして構造化されます。
コミットメッセージを丁寧に書いている人ほど、knowledgineの恩恵が大きくなります。
ここまで仕組みの話が続きましたが、実際に使ってみてどうだったのか。自分自身で3ヶ月使った結果を共有します。
3ヶ月間のドッグフーディングで変わったこと
knowledgine自体の開発で、knowledgineを使っています。
一番の変化は、同じ説明を繰り返さなくなったこと。以前は新しいセッションを開くたびに「pnpmモノレポで、packages/coreとpackages/cliがあって、テストはVitest...」と説明していました。今は自動で渡してくれるので、セッション開始から30秒で前回の続きに入れます。
過去の判断も消えなくなりました。「なぜbetter-sqlite3を選んだのか」「なぜMCPプロトコルに賭けたのか」。こういう意思決定の過程がノートに残っていて、AIに渡される。3ヶ月前の自分の判断理由を、今日のAIが参照して一貫した設計判断ができるようになりました。
個人的に一番うれしかったのは、曖昧な記憶をシステムが裏付けてくれること。「前にこういう問題なかったっけ?」と思ったとき、search_knowledgeで実際に見つかる。開発中の判断に自信が持てるようになりました。
LongMemEvalベンチマークでは73.2%のスコアを達成しています。完璧ではありませんが、なかった頃には戻れないレベルです。
最後に、knowledgineで目指している世界について書きます。
今後のビジョン
knowledgineの最終形は「チームの暗黙知をインフラ化する」ツールです。
どのチームにも「あの人に聞かないとわからないこと」があります。デプロイ手順の細かい注意点、特定のAPIの罠、過去のインシデントの教訓。メンバーが辞めたら消える知識、引き継ぎドキュメントに書ききれない知識、Slackのスレッドに埋もれた知識。
これを自動的に掘り起こして構造化し、AIが使える形にする。新しくチームに入った人がAI経由で「あ、これ前に誰かが解決してたんだ」と気づける世界を目指しています。
さいごに
knowledgineはMITライセンスのOSSとして公開しています。
CLAUDE.mdを手動で書き続けるのも、セッションのたびに同じ説明をするのも、同じレビュー指摘を何度ももらうのも。これらを解決したくて作りました。
v0.5.0で、まだ荒削りな部分もあります。でも「会話を覚える」のではなく「開発の知識を構造化してAIに渡す」という方向性には手応えを感じています。
フィードバックはGitHubのIssueでも、Xでも歓迎です。
npm install -g @knowledgine/cli
