Project Memory について
Project Memoryは、コードフォルダー内の通常ファイルを使って、コーディングエージェントにプロジェクトの記憶を提供するローカルMCPサーバーです。決定事項、問題の履歴、好みを保存し、バックグラウンドサービスなしでセッションをまたいで参照できます。
主な機能
- 01プロジェクトの記憶を閲覧・検索
- 02決定事項、学び、好みを記録
- 03問題の履歴を記録・検索
- 04未解決の問題を追跡・解決
- 05複数セッションにまたがる取り組みを管理
活用シーン
- 01デバッグ前に過去の問題と修正を確認
- 02新しいセッションでプロジェクトの背景を復元
- 03プロジェクトの決定事項や作業上の好みを記録
- 04複数プロジェクトの未解決問題を確認
MCP 対応
MCPサーバーは、問題管理や取り組みの管理を含む、プロジェクトの記憶を読み取り、検索、更新するツールを提供します。記憶自体はディスク上の通常ファイルに保存されます。
設定
ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。
npx -y @kaaustubh/project-memory-mcpPROJECT_MEMORY_ROOTAbsolute path to the folder that holds your projects (the memory root). Defaults to the parent of the script if unset, so set it when running via npx.ローカルサーバーにはマシン上の実行環境(Node.js 18 以上など)が必要です。設定ファイルの場所はクライアントごとに異なります。
ツール
12掲載時のツール一覧 · 3 週間前に更新
このツールにパラメーターはありません。
詳細
project-memory MCP サーバー
AI エージェント(Claude Code、Cursor、VS Code / GitHub Copilot、…)に、コードフォルダー内のプロジェクトについて、各プロジェクトの概要、決定事項、開発中に直面したすべてのバグ/問題を共有する永続的なメモリーを提供する、小規模なローカル MCP サーバーです。
ステートレスです。すべてのツールがディスク上のプレーンファイルを読み書きするため、複数のクライアント(および複数のマシン)で唯一の信頼できる情報源を共有できます。
モデル
| レイヤー | 保存場所 | コンテキストに自動読み込みされるか | 用途 |
|---|---|---|---|
| プロジェクトメモリー | <project>/AGENTS.md | ✅ はい(CLAUDE.md → @AGENTS.md 経由) | 概要、技術スタック、実行コマンド、簡潔な決定事項/学び — 簡潔に保つ |
| 問題ログ | <project>/issues.jsonl | ❌ いいえ | 大量のバグ/問題の履歴 — 必要に応じて取得 |
設計ルール: 長期的に有用で数の少ない情報は AGENTS.md(自動読み込み)に記録します。大量の履歴(バグ)は issues.jsonl(search_issues で検索)に記録します。これにより、常時読み込みされるコンテキストを小さく保ちながら、すべてを検索可能にします。
MCP が制限されている環境でも機能します
組織によっては、ポリシーによりサードパーティ製 MCP サーバーを無効にしている場合があります(例:GitHub Copilot の MCP allowlist enforcement)。 メモリーはサービスではなくプレーンファイルなので、そうした環境でも中核的な価値は失われません。
- メモリー自体は単なるファイルです。
AGENTS.mdはエディターが読み込むことで自動的に読み込まれます — MCP 呼び出しは必要ありません — そのため、プロジェクトの概要、決定事項、学び、設定は引き続き エージェントのコンテキストに反映されます。 - ポリシーの対象は Copilot に限られ、クライアントごとに適用されます。 同じサーバーを Claude Code や Cursor で使う場合には影響しません。また、allowlist / registry-only モードを使う組織では許可できます —
このサーバーは公式 MCP Registry(
io.github.kaaustubh/project-memory-mcp)に公開されています。
対話型のツール(log_issue、search_issues、…)だけが MCP チャネルを経由します。ファイルベースのメモリーは MCP チャネルがなくても引き続き機能します。
ツール
list_projects、get_project、search_memory— プロジェクトメモリーを読み取りますappend_decision、append_learning— 日付付きの箇条書きをAGENTS.mdに追加しますremember_preference— 修正や明示された習慣を、記憶するパターンに変換します(グローバルな習慣ならルートのAGENTS.mdの## Preferencesに、プロジェクト固有ならそのプロジェクトのAGENTS.mdに記録します)。自動読み込みの対象になるため、次のセッションでも反映されますlog_issue— バグ/問題を記録します →issues.jsonlsearch_issues— すべてのプロジェクトを対象に「これまでに同じ問題に遭遇したことがあるか?」を検索します(フィールド指定に対応。任意のtagsフィルターを使用できます)list_open_issues、resolve_issue— バグの追跡/解決を行いますsync_registry— ルートのAGENTS.mdにあるプロジェクト表をディスク上の内容と照合します(新しいプロジェクトの行を追加し、古くなった項目に印を付けます)find_by_file— ファイルパスを指定して、そのファイルに関係する問題や決定事項/学びを表示します(「なぜこのコードはこうなっているのか?」)start_initiative、get_initiative、list_initiatives、update_initiative— 名前付きの複数セッションにまたがる取り組み(コードネーム、計画、更新されていく ToDo リスト)を追跡します。開始したセッションだけでなく、今後のどのセッションからも名前で再開できます。詳しくは以下のイニシアチブをご覧くださいcheck_in、check_out— 作業日の開始/終了を記録し、ディスクから収集した情報(すべてのリポジトリの Git コミット、未コミットの WIP、メモリーへの書き込み、イニシアチブの進捗)をもとにスタンドアップの要約を作成します。翌朝のcheck_inでその要約が返されます — それがスタンドアップです。エージェントを使わずに、いつでも表示できます:npx -y @kaaustubh/project-memory-mcp standup
これらを直接呼び出す必要はありません — エージェントに自然言語で話しかけると、エージェントが適切なツールを選びます。実際にどのように使うかは、以下の日々の使い方をご覧ください。
日常的な使い方
ほとんどは自動で動作します。プロジェクトを開くとAGENTS.mdが自動で読み込まれ(エージェントはすでにプロジェクトを把握しています)、記録も先回りして行われます(オプションのStopフックも利用できます)。必要なタイミングでメモリを呼び出すことが主な作業です。エージェントに話しかけるだけです。
| タイミング | こんなふうに話しかけます | 実行されるもの |
|---|---|---|
| デバッグを始める前 | 「これ、以前にも遭遇したことがありますか? <エラーを貼り付け>」 | すべてのプロジェクトを対象にsearch_issues |
| 別の場所で取り組んだことに着手するとき | 「どのプロジェクトでもいいので、Stripe webhook verification をどう実装したか教えてください」 | search_memory(プロジェクト横断) |
| 分かりにくいコードに出くわしたとき | 「index.jsがこうなっている理由は?メモリを確認してください」 | find_by_file |
| 実際の判断を下した/実際のバグを修正したとき | (何もしなくて大丈夫です。自動で記録され、通知されます) | append_decision / log_issue |
| エージェントの動作を修正するとき | 「いいえ、コミット前に必ずtypecheckを実行してください。覚えておいてください」 | remember_preference(グローバルまたはプロジェクトごと) |
| トリアージ | 「プロジェクト全体で、まだ未対応のものは何ですか?」 | list_open_issues |
| バグを修正したとき | 「pulse_stripe-004を解決してください。…で修正しました」 | resolve_issue |
| 新しいプロジェクトを追加したとき | 「レジストリを同期してください」 | sync_registry |
**大切な習慣はひとつだけです。*デバッグを始める前に、毎回反射的に「これ、以前にも遭遇したことがありますか?」*と確認しましょう。ここでメモリツールが役立ちます。それ以外はシステムが処理します。
**記録内容は通知されます。黙って記録されることはありません。*エージェントが何かを記録すると、1行で通知します。自由に修正してください。「それは記録しないで」、または「やっぱり、これも記録して」*と伝えましょう。
回避手段:PROJECT_MEMORY_HOOK=offを設定すると、1つのセッションでStopフックを無効にできます。uninstall-hookを実行すると、フックを完全に削除できます。
インストール(npm — 推奨)
コード/プロジェクトのフォルダーで、次を実行します。
cd ~/code # the folder that holds your projects
npx -y @kaaustubh/project-memory-mcp install
これにより、現在のディレクトリをプロジェクトのルートとして、MCP設定の保存先があるこのマシン上のすべてのクライアントにサーバーが登録されます。
| クライアント | 書き込まれる設定 |
|---|---|
| Claude Code | claude mcp addを使用したユーザースコープ |
| Cursor | ~/.cursor/mcp.json |
| VS Code / GitHub Copilot Chat | ユーザープロファイルのmcp.json(すべてのワークスペースに適用) |
| GitHub Copilot CLI | ~/.copilot/mcp-config.json(または$COPILOT_HOME) |
| JetBrains Copilot plugin(IntelliJ、PyCharm、WebStorm、…) | ~/.config/github-copilot/intellij/mcp.json |
| Visual Studio(Windows) | %USERPROFILE%\.mcp.json — グローバル、すべてのソリューションに適用 |
| Kimi Code CLI | ~/.kimi-code/mcp.json(または$KIMI_CODE_HOME) |
| Gemini CLI | ~/.gemini/settings.json |
| OpenAI Codex CLI | ~/.codex/config.toml(唯一の非JSONクライアント — TOMLとしてマージ) |
| Windsurf | ~/.codeium/windsurf/mcp_config.json |
書き込みの際は既存のファイルに内容をマージするため、すでに設定済みの他のMCPサーバーはそのまま残ります。また、各クライアントへの書き込みはそれぞれ独立してベストエフォートで行われます。このマシンにインストールされていないクライアントは通知なしでスキップされ、ほかのクライアントへの登録は続行されます。使用するアプリを再起動してから、エージェントに*「このフォルダーにプロジェクトメモリを設定して」*と頼むと、各プロジェクトにAGENTS.mdが作成されます。
Copilotの各環境(VS Code、CLI、JetBrains、Visual Studio):ツールを実行できるのはAgentモードのみです。また、設定の変更を反映するには再起動が必要です。
クローンもグローバルインストールも不要です。MCP設定から
npxを実行し、必要に応じて最新バージョンを取得して実行します。
**チームメモリ(ベータ版の事前登録):**このメモリを自分のマシンだけでなく、チーム全体で共有したいですか?こちらから登録してください:https://github.com/kaaustubh/project-memory-mcp/issues/1
ソースからインストールする場合
git clone https://github.com/kaaustubh/project-memory-mcp.git ~/code/.memory-server
cd ~/code/.memory-server && ./install.sh
インストール後の動作
よくある質問です。「インストールしたら、勝手に何かを始めるのですか?」 そうとは限りません。 サーバーは受動的です。実際の流れは次のとおりです。
- エディターを再起動します。 MCP サーバーは起動時に読み込まれるため、サーバーが利用可能になるのは Claude Code / Cursor / VS Code を次に起動したときです。
- プッシュ層(自動、サーバーではありません): プロジェクトを開くと、エディターが
AGENTS.md(CLAUDE.md→@AGENTS.md経由)を読み込み、モデルのコンテキストに追加します。エージェントがプロジェクトについて「最初から知っている」ように見えるのは、これが組み込みのエディター機能だからです。 - プル層(サーバー、リクエスト時): サーバーはツールを通知した後、待機します。自ら何かをすることはありません。エージェントは、関連性がある場合にのみツールを呼び出します。たとえば、あなたが 「このバグを記録して」 や 「以前も同じ問題がありましたか?」 と言ったとき、またはモデルがツールの利用を有効だと判断したときです。バックグラウンドプロセスやスキャンはありません。
初日は空です。 新規セットアップでは、まだ
AGENTS.mdファイルがないため、自動読み込みするものがなく、プロジェクトのメモリが作成されるまではlog_issueも実行できません。エージェントに 「このフォルダーのプロジェクトメモリを設定して」 と頼んで、一度だけ初期設定を行ってください。AGENTS.mdファイルが作成されます。その後はすべて動作します。
要するに、規約(自動読み込みされるファイル)+エージェントが選んで使うツール+一度限りのセットアップです。魔法でも、デーモンでもありません。
先回りした記録(「これを記録して」と言う必要はありません)
サーバーには常時適用される記録ポリシーが含まれています(接続時にクライアントへ送信され、指示ツールの説明にも含まれます)。そのため、あなたが頼むのを待たずに、エージェントが自ら記録します。
- 報告されたエラーをデバッグする前 → 以前の修正がないか
search_issuesで確認します。 - 重大なバグを修正した後 →
log_issueを呼び出します。 - 実際の判断を下した後や、長く役立つ注意点に気づいた後 →
append_decision/append_learningを呼び出します。 - 動作を訂正した後や、習慣を伝えた後 →
remember_preferenceを呼び出します。一度限りの訂正がパターンとなり、次のセッションでも参照されます。
これは先回りして記録しますが、黙って記録するわけではありません。エージェントは記録した内容を一言で伝え、判断がつかない場合はノイズになる情報を記録せずに確認し、些細な情報や秘密は記録しません。いつでも「これを記録して」や「記録しなくていい」と指示できます。常時適用されるポリシーはベストエフォートです(モデルが指示に従うかどうかに依存します)。確実に適用するには、下記のオプトイン式 Stop フックを追加してください。
確実な記録(オプトイン式 Stop フック)
常時適用されるポリシーは、セッションの途中で忘れられることがあります。Stop フックを使うと、記録が必須になります。エージェントがターンを終了しようとするとフックが一度実行され、次のいずれかに該当する場合は停止をブロックし、記録を一度行うよう求めます。(a)実際の作業(ファイルの編集またはコミット)が行われ、プロジェクトメモリには何も書き込まれていない、または(b)あなたがエージェントの動作を訂正したにもかかわらず、好みが保存されていない場合です。すでにメモリに書き込まれている場合、または変更も訂正もなかった場合は、フックは何もせず、ターンの終了を許可します。
npx -y @kaaustubh/project-memory-mcp install-hook # turn it on (then restart Claude Code)
npx -y @kaaustubh/project-memory-mcp uninstall-hook # turn it off
- デフォルトではオフ — 通常の
installでは追加されません。有効にするには明示的な操作が必要です。 - ループなし — 1 ターンにつき最大 1 回だけ実行され(
stop_hook_activeで制御)、その後はエージェントの停止を許可します。 - セッションごとの停止スイッチ —
PROJECT_MEMORY_HOOK=offを設定すると、アンインストールせずに無効にできます。 - コスト — コードを変更したのに何も記録しなかったセッション、またはエージェントを訂正したのに好みが保存されていないセッションに限り、モデルのターンが 1 回追加されます。それ以外では何も起きません。
自動リコール(オプトインの UserPromptSubmit フック)
記録はループの半分にすぎません。もう半分は、確認することを忘れないことです。リコールフックがそのループを完成させます。プロンプトを送信するたびに、リクエストを過去の課題や決定・学び・設定と照合し、最も関連性の高い結果をコンテキストとして静かに挿入します。これにより、過去の修正や決定が、あなた(またはエージェント)が検索を思い出さなくても浮かび上がります。「これ、以前にもあった?」という習慣が自動化されます。
npx -y @kaaustubh/project-memory-mcp install-recall # turn it on (then restart Claude Code)
npx -y @kaaustubh/project-memory-mcp uninstall-recall # turn it off
- セマンティックマッチング(利用可能な場合) — オプションの埋め込みモデル
(
@xenova/transformers)がインストールされている場合、リコールは意味で照合するため、 共通の単語がなくても、*「ビルドが壊れている」という内容から、「コンパイルエラー」*として 記録された課題が表示されます。完全にオフラインで動作します(モデルは一度取得され、その後 キャッシュされます)。モデルがない場合は、自動的にキーワードマッチングに切り替わるため、 設定は不要で、何も壊れません。 - 関連性がなければ何も表示しません — 簡単なプロンプトや一致する項目がない場合は、何も挿入しません。
- 順位付けと上限 — 現在のプロジェクトの結果が最上位になり、挿入されるのは最大4行です。
- デフォルトではオフ — Stop フックと同様、オプトインです(プロンプトごとにコストがかかります)。通常の
installでは、どちらのフックも追加されません。 - セッションごとの停止スイッチ —
PROJECT_MEMORY_RECALL=offを設定すると、アンインストールせずに無効化できます。
キャッシュを事前に準備する: 大量に記録した後(またはリコールを有効にした後、一度だけ)、
npx -y @kaaustubh/project-memory-mcp reindexを実行してすべてを事前に埋め込み、 最初のリコールで処理が発生しないようにします。ベクトルはプロジェクトごとに派生ファイル.embeddings.jsonにキャッシュされます(安全に削除したり、Git の対象外にしたりできます。 正本は引き続き.jsonlとAGENTS.mdです)。
Stop フックと組み合わせれば、ループが自動的に回ります。Stop フックは内容が 保存されることを保証し、リコールフックは適切なタイミングで内容が呼び戻されることを保証します。
イニシアチブ(セッションをまたいだ名前付き作業の追跡)
決定・学びには完了した事実を記録し、issues.jsonl にはバグの履歴を記録します。
しかし、どちらも名前付きで進行中の、複数セッションにまたがる取り組みを記録する場所ではありません。
「コードネームを付けて、計画と ToDo を追跡し、これまで見たことのないセッションでも名前で再開できるようにしたい」。
そのための機能が start_initiative / get_initiative / list_initiatives /
update_initiative です。
you: "Let's call this HashGate. Track the plan and todos under that name."
→ start_initiative(project, codename: "HashGate", plan: "...", todos: [...])
(new session, days later)
you: "Where did we leave off on HashGate?"
→ get_initiative(project, codename: "hash gate") # case/spacing-insensitive match
you: "Continue where I left off" (no codename given)
→ list_initiatives(project) # or omit project to search everywhere
各イニシアチブは、<project>/initiatives/<slug>.md という独立したファイルに保存されます。そこには計画、
チェックボックス付きの ToDo リスト、日付入りの進捗ログがあり、すべてその場で編集できます。すべての
進行中のイニシアチブへの1行のポインターは、プロジェクトの AGENTS.md にある ## Active Initiatives の
下で同期されるため、新しいセッションでも自動読み込みされるコンテキストから、進行中の内容を
ツール呼び出しなしで確認できます。ステータスを done にするとポインターは削除されますが、
ファイルは履歴として残り、引き続き名前で参照できます。
マシン間での共有
ツールとメモリーの内容は別々に同期します。
- ツール: 同期するものはありません。
npxは常に公開済みバージョンを取得します(ソースから インストールした場合はgit pullを実行します)。 - 内容: 各プロジェクトの
AGENTS.mdとissues.jsonlは、そのプロジェクト自身の Git リポジトリ内に あるため、プロジェクトをクローンすればメモリーも一緒に取得できます。コピーは不要です。
issues.jsonlには実際のバグの詳細が含まれます。コミットするのはプライベートリポジトリだけにしてください。
新規プロジェクトのひな形
ルート配下の新規プロジェクトには、@AGENTS.md を含む <project>/CLAUDE.md と、
## What this is、## Stack & layout、## Run / build / test、## Decisions、
## Learnings の各セクションを含む <project>/AGENTS.md を作成します。
変更履歴
v1.11.1
- 修正:
package-lock.jsonを再生成しました。リリース時にpackage.jsonとMcpServer({version})の文字列のバージョンだけを更新し、ロックファイルを更新していなかったため、package.jsonが 1.9.0/1.10.0/1.11.0 と進む一方で、ロックファイルには1.8.3が記載されたままでした。npm ciが致命的なエラーになることはありません(npm 10/11/12 で確認済み)が、v1.8.3 で CI が完全に失敗したのと同じ種類の不整合です。 - 修正:
scripts/をfilesの許可リストに追加したため、インストール済みパッケージからnpm testを実行できるようになりました。以前はスモークテストが公開 tarball に含まれていなかったため、npm install && npm testを実行するコンテナビルド仕様はMODULE_NOT_FOUNDで失敗していました。リポジトリをクローンした場合にしか動作しませんでした。 - 修正:
startスクリプト(node index.js)を追加したため、CMD がnpm startのビルド/デプロイ仕様が、スクリプト不足で失敗しなくなりました。 - ドキュメント: コンテナ(Glama の Deploy ビルドテスト、または独自のイメージ)でビルドする場合は、
npm ci --omit=optionalを使用してください。通常のnpm ciは、36 KB のサーバーに対して 276 MB のnode_modulesを取得します。そのほとんどは オプションの 埋め込みチェーン(onnxruntime-node、onnxruntime-web、@xenova/transformers、sharp)で、インストール中に事前ビルド済みバイナリもダウンロードするため、ディスク容量や時間に制限があるビルダー、またはネットワークが制限されたビルダーでは失敗します。--omit=optionalを指定すると 25 MB になり、18 個のツールすべてが引き続き登録されます。設計どおり、セマンティック検索はキーワード検索にフォールバックします(v1.6.0)。推奨仕様:Node 20 ·npm ci --omit=optional· CMDnode index.js。
v1.11.0
- 機能:日次作業ログ —
check_in/check_outツールとstandupサブコマンド。 1日の始めに「check in」、終わりに「checkout」と伝えます。checkout では、その日のエビデンスをディスクから収集します。ルート配下のすべてのリポジトリにおける git コミット(AGENTS.mdの有無を問わず、.memory-server自体も含む)、リポジトリごとの未コミットの作業、当日付のメモリへの書き込み(issue/決定事項/学び/設定)、時間枠内に変更されたイニシアチブファイルが対象です。その後、エージェントはこのエビデンスだけをもとに 3~6 項目のスタンドアップ要約を作成して保存します(その日の大半はセッションをまたぎ、終了時のエージェントが見ていない内容であることが多いため、どの MCP クライアントでも使える 2 段階のツールプロトコルです)。翌朝のcheck_inは、直近の稼働日の要約(月曜日なら金曜日の要約)と未完了の項目(未完了の todo がある進行中のイニシアチブ、未解決の issue)を返します。また、npx -y @kaaustubh/project-memory-mcp standup [YYYY-MM-DD]を実行すると、エージェントを介さずにターミナルへ直接表示できます。日次ログはROOT/.worklog/YYYY-MM-DD.jsonに保存され、現地時間とオフセットを記録します。1日に複数回のチェックイン/チェックアウト(昼休みなど)に対応し、チェックアウトを忘れた場合は次のチェックイン時にタイムスタンプから再構成して自動的に終了します。エントリーはWORKLOG_KEEP_DAYS(デフォルトは 10)を過ぎると削除されます。追記専用のメモリファイルとは異なり、意図的に一時的なデータとして扱われます。
v1.10.0
- 機能:
installが Kimi Code CLI(~/.kimi-code/mcp.json、または$KIMI_CODE_HOME。~/.kimi/mcp.jsonを使用する別製品の「Kimi CLI」とは異なります)、Gemini CLI(~/.gemini/settings.json)、Windsurf (~/.codeium/windsurf/mcp_config.json)も登録するようになりました。これら3つはすべて、Cursor 用にregisterMcpがすでに処理している既存のmcpServers/typeなしのスキーマに一致するため、それぞれ1行追加するだけで済みました。 OpenAI Codex CLI(~/.codex/config.toml)には本格的な対応が必要でした。これは初の非JSONクライアントで、TOML の[mcp_servers.<name>]テーブルを使って設定します。TOML パーサーへの依存を追加するのではなく、テキストベースでテーブルを検索し、置換または追記するマージ処理registerMcpTomlを追加しました。これはappendBulletToFileの見出し照合と同じ考え方で、ハード依存をゼロに保ちます。リリース前に実際のバグを発見して修正しました。初期版はテーブルの本文を次のリテラルな[までとして照合していたため、args = [...]配列内の[によってテーブルの途中で切れていました。これを「[で始まる次の行まで」として照合するよう修正し、無関係なテーブルを含む事前設定済みの config.toml に対して、installを繰り返し実行しても冪等であることを確認しました。
v1.9.0
- 機能:イニシアチブ。 4つの新しいツール —
start_initiative、get_initiative、list_initiatives、update_initiative— により、名前を付けた複数セッションにまたがる取り組み(コードネーム、計画、更新されていく todo リスト)を追跡できます。そのため、開始したセッションだけでなく、今後のどのセッションからでも名前を使って再開できます。この機能は、別のエージェントのセッション内だけで使われる「コードネーム」方式で報告された、実際の失敗事例をもとにしています。名前 → セッションの対応を保持する永続的なレジストリがなく、todo がセッション固有のプライベートストアに限定され、見つけるには生のトランスクリプト全体から完全一致の文字列を探す必要がありました。ここでは、イニシアチブごとに Markdown ファイルを1つ保存することで解決しました(<project>/initiatives/<slug>.md— 変更可能なため、todo のチェックボックスをその場で切り替えられます)。さらに、プロジェクトの自動読み込み対象であるAGENTS.mdに新しい## Active Initiatives見出しを設け、その下に同期されたポインターを保存します。これにより、新しいセッションでもツールを一度も呼び出すことなく、進行中の取り組みを確認できます。コードネームの照合では大文字・小文字と空白を区別しません(slugifyは先に camelCase の境界で分割するため、"HashGate"と"hash gate"は同じイニシアチブとして解決されます)。list_initiativesはプロジェクトが指定されていない場合、すべてのプロジェクトを検索します。そのため、「何に取り組んでいたっけ?」と思ったときに、どのリポジトリだったかを覚えている必要もありません。
v1.8.3
- インフラ: 新しい stdio スモークテスト(
.github/workflows/ci.yml、Node 18/20/22 のマトリックス)を使った実際の CI ワークフロー(scripts/smoke-test.mjs— サーバーを起動し、initialize→tools/listのハンドシェイクを実行して、12個すべてのツールが登録されることを検証)と、CodeQL ワークフローを追加しました。以前はどちらも完全に欠けていました。そのため Glama の品質ページには「CI status not available」と「No code scanning findings」と表示されていましたが、これは問題がないという保証ではなく、「一度も測定されていない」という意味でした。 - 修正:
package-lock.jsonを再生成しました。@xenova/transformersがオプション依存関係込みで解決されたことが一度もなかったため、クリーンな CI ランナーでnpm ciが失敗していました。また、npm audit fixも実行し(破壊的変更なし)、@modelcontextprotocol/sdk経由のhono/body-parser/fast-uriに関するアドバイザリを解消しました。既知の問題:@xenova/transformers(オプション依存関係。セマンティック検索を支えます)は、依然としてonnxruntime-web/protobufjs/sharpの依存関係を通じて、重大度「Critical」の CVE 1件と「High」の CVE 4件を取り込みます。修正方法は互換性のない変更を伴う1.4.2へのダウングレードのみですが、意図的にまだ実施していません。フォローアップとして追跡中です。
v1.8.2
- ドキュメント/メタデータ:
glama.json(maintainersを宣言)を追加し、Glama の「No glama.json」プロフィール完成度チェックを解消しました。あわせて、このバージョンの実際の GitHub Release を公開しました(以前は git タグをプッシュするだけでしたが、Glama の「Has a release」チェックでは認識されません。タグではなく Releases API を参照するためです)。
v1.8.1
- ドキュメント: README に Glama の品質スコアバッジを追加しました。awesome-mcp-servers の掲載要件に対応するためです。
/badges/score.svg(実際の SVG)を使用しています。単なる/badgeパスは使用していません。後者はステータスコード 200 を返しますが、0 バイトのimage/pngを配信するため、壊れた画像になります。
v1.8.0
- 機能:
installが GitHub Copilot CLI(~/.copilot/mcp-config.json、または$COPILOT_HOME)、JetBrains Copilot プラグイン(IntelliJ/PyCharm/WebStorm/…)、および Windows 上の Visual Studio(グローバル.mcp.json)にもサーバーを登録するようになりました。これにより、1.7.0 で追加された VS Code の登録と合わせて、Copilot のすべての環境に対応します。各ターゲットの既存設定にマージするため、ほかのサーバーは保持されます。また、それぞれ個別にベストエフォートで処理されるため、インストールされていないクライアントはインストール全体を失敗させることなく、通知なしでスキップされます。クライアントごとにスキーマが異なります(トップレベルキーがmcpServersかserversか、Copilot CLI ではtype: "local"、IDE 埋め込み型ではtype: "stdio")。実装前に、各クライアントの最新ドキュメントを照合して確認しました。5 つすべてのターゲットに対するマージロジックを、1 つのregisterMcp()ヘルパーに統合しました。
v1.7.0
- 機能: 既存の Claude Code と Cursor の登録に加えて、
installが VS Code / GitHub Copilot にもサーバーを登録するようになりました(ユーザープロファイルのmcp.jsonを使用するため、すべてのワークスペースに適用されます)。スキーマは Claude/Cursor とは異なり(serversキー、各エントリにtype: "stdio")、Copilot ツールは Chat の Agent モードでのみ実行されます。
v1.6.2
- ドキュメント: チームメモリーのベータ版登録に関する注記を追加しました(README のインストールセクションと、
installサブコマンドのコンソール出力)。https://github.com/kaaustubh/project-memory-mcp/issues/1
v1.6.1
- ドキュメント: 「MCP が制限されている環境でも動作」を追加しました。ファイルベースのメモリー(
AGENTS.mdの自動読み込み)は、組織がサードパーティ製 MCP サーバーを無効にしている環境(GitHub Copilot の MCP 許可リストなど)でも引き続き機能することを明確にしています。MCP チャネルを使用するのは、インタラクティブなツールだけだからです。
v1.6.0
- セマンティックリコール(ローカル埋め込みモデルを任意で使用)。 リコールフックが、プロンプトに共通する部分文字列があるかどうかではなく、意味 に基づいてメモリーと照合するようになりました。たとえば、"ビルドが壊れている" というプロンプトから、"コンパイルエラー" として記録された問題を見つけられます。任意の依存関係である
@xenova/transformersを通じて、ローカルかつオフラインで動作する埋め込みモデル(Xenova/all-MiniLM-L6-v2)を使用します。ベクトルはプロジェクトごとに派生ファイル.embeddings.jsonにキャッシュされ、コンテンツハッシュをキーとするため、編集または削除された項目は自動的に無効化されます。モデルがインストールされていない場合は、以前のキーワード照合に自動的にフォールバックするため、設定は不要で、機能が壊れることもありません。新しいreindexサブコマンドを使うと、すべてのメモリーを事前に埋め込み、初回のリコールが遅くなるのを防げます。これにより、リコールとsearch_issuesの両方を支える、長らく未実装だった「セマンティック検索」機能が完成しました。キーワード照合は、依存関係ゼロで使える基本機能として引き続き利用できます。
v1.5.0
- 自動リコール(任意の
UserPromptSubmitフック)。 新しいinstall-recall/uninstall-recallサブコマンドで、すべてのプロンプトを過去の問題、判断、学び、好みとキーワード照合し、最も関連性の高い結果をコンテキストとして通知なしで挿入するフックを登録できます。これにより、検索することを覚えていなくても、過去の修正や判断が提示されます。記録とリコールのループのもう一方を完成させます。些細なプロンプトや一致するものがないプロンプトでは通知を出しません(一般的な埋め草の単語は無視されます)。現在のプロジェクトの結果を最も高く評価し、挿入するのは最大 4 行です。デフォルトでは無効です。セッションごとの無効化スイッチはPROJECT_MEMORY_RECALL=offです。
v1.4.1
- パッケージング:公式 MCP Registry へのサーバー掲載に必要な
mcpNameフィールド(io.github.kaaustubh/project-memory-mcp)を追加しました。機能上の変更はありません。
v1.4.0
remember_preference— 修正内容を記憶するパターンにします。 日付付きの箇条書きを## Preferencesの下に書き込む新しいツールです。書き込み先は、globalスコープの場合はルートのAGENTS.md(すべてのプロジェクトに適用)、または単一のプロジェクトです。設定は自動読み込みされるAGENTS.mdに保存されるため、呼び出しに手間はかかりません。「共同執筆者のクレジットは絶対に追加しない」「コミット前に必ず型チェックを行う」といった一度限りの修正が次のセッションでも適用され、再度修正する必要がなくなります。プロジェクトの事実だけでなく、作業の好みについてもセッションをまたいだループを解消します。- 修正を認識する Stop フックと記録ポリシー。 常時適用されるポリシーで、修正後に
remember_preferenceを促すようになりました。また、オプトインの Stop フックがセッション内の行動に関する修正のフレーズ(「これからは……」「いや、……しないで」「必ず……を使って」など)をスキャンします。エージェントに修正を伝えたのに設定が保存されていない場合、停止を一度だけブロックして確認します。これは既存の「コードが変更されたのに何も記録されていない」チェックに加わる、独立した2つ目の理由です。
v1.3.2
- ドキュメント:「日々の使い方」セクションを追加しました。各ツールに対応する自然言語のプロンプト、重要な習慣(「これ、前にもありましたか?」)、および回避策を説明しています。ツールを直接呼び出すのではなく、エージェントに話しかけることを明確にしました。
v1.3.1
- Stop フック:メモリを直接編集した場合も記録済みとして扱います。 以前のフックは
mcp__project-memory__*ツールの呼び出ししか認識していなかったため、AGENTS.md/issues.jsonlを直接編集する(推奨されている記録方法)と、引き続き警告が表示されていました。現在は、AGENTS.mdまたはissues.jsonlで終わるファイルに対するEdit/Writeも記録済みとして扱うため、誤検知がなくなります。 append_decision/append_learning:セクションが重複しなくなりました。 見出しの照合が行全体(^## Learnings$)を対象としていたため、末尾にテキストがある見出し(## Learnings (gotchas …))が見つからず、セクションが重複して追加されていました。現在は見出しの先頭の語句で照合します。
v1.3.0
- 確実な記録(オプトインの Stop フック)。 新しい
install-hook/uninstall-hookサブコマンドで、Claude Code のStopフックを登録できます。セッション中にコードが変更されたのにメモリに何も記録されていない場合、必ず一度記録処理を実行し、ベストエフォートのポリシーを確実なものにします。デフォルトでは無効で、ターンごとに最大一度だけ実行されるためループせず、変更がない場合やメモリへの書き込みが済んでいる場合は何も表示されません。PROJECT_MEMORY_HOOK=offを設定すると、セッションごとに無効化できます。
v1.2.0
- より精度の高い課題検索。
search_issuesは、生の JSON ではなくテキストフィールド(symptom/cause/fix/id/tags)のみを対象に照合するようになりました。そのため、フィールド名による誤検知がなくなります。任意のtagsフィルターを追加し、queryは省略可能になりました(タグのみで検索できます)。 sync_registry。 ルートのAGENTS.mdにあるプロジェクト一覧をディスク上のプロジェクトと照合します。一覧にないプロジェクトの仮行を追加し、ディレクトリが存在しない行を指摘し、未解決の課題数を報告します。これまで手作業だった「新しいプロジェクトを追加 → 行を追加」の手順を自動化します。手動で編集した列は保持されます。apply=falseの場合は差分のみを報告します。find_by_file。 ファイルパスまたはその一部を指定すると、そのファイルに関連する課題(filesフィールド経由)と、決定事項・学び(そのファイルに言及する AGENTS.md の箇条書き)を返します。「このコードがこうなっているのはなぜ?」という疑問に答えるため、コードとメモリを関連付けます。
v1.1.1
- ドキュメントのみ:変更内容に差が出ないよう、変更履歴を npm ページに掲載しました(機能変更はありません)。
v1.1.0
- 先回りした記録。 「これを記録して」と言われるのを待たずに、エージェントが自らメモリに記録するようになりました。常時適用される記録ポリシーを
initializeで送信し、書き込み/検索ツールの説明を指示的な内容にしています。何を記録したかを伝えて確認を促し、不確かな場合は質問し、些細なことや秘密情報は記録しません。明示的な呼び出しによる上書きも引き続き可能です。 - ドキュメント:「インストール後の仕組み」と「先回りした記録」セクションを追加しました。
v1.0.1
npx … installが「command not found」で失敗する問題を修正しました。非スコープ付きパッケージ名に合わせて(npx の解決ルール)、バイナリ名をproject-memory-mcpに変更しました。
v1.0.0
- 初回リリース:
AGENTS.mdとissues.jsonlを使用するステートレスな MCP サーバー、9 つのツール (プロジェクトメモリーと課題追跡)、Claude Code と Cursor 用のnpx … install、および プッシュ/プル型のメモリーモデル。
コメント
AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。