Projectmem

🎉 v0.3.4 がリリースされました — プロジェクトが成長しても要約は簡潔なまま保たれ、コミットは変更したコードに紐づけて記録され、古い情報に関する警告がタイムゾーンに左右されなくなりました。 変更点を見る →

AI を賢くするのではありません。経験を積ませるのです。

コーディングエージェントのメモリ — AI コーディングエージェントのための、ローカルファーストなメモリと判断レイヤーです。すべてのプロジェクトに 1 つの MCP サーバーを。セッションのたびにプロジェクトを読み直す必要も、昨日のバグを繰り返す必要もありません。

ウェブサイト • ガイド • デモ • 変更履歴 • 論文

_{pjm visualize — プロジェクトが解決したすべてのケース、解決までに失敗したこと、そして節約できたことを表示します。.projectmem/events.jsonl からローカルで生成されます。}

🚀 ここから始めましょう — 最初の一度だけ、5 分

*ここに沿って進めれば 5 分です。実行するすべてのコマンド、表示される正確な出力、最後に表示されるダッシュボードまで、実際に見てみたいですか？ その場合は、**完全なセットアップガイド*をご覧ください。

projectmem を初めて使う方、または 0.1.x / 0.2.x からアップグレードする方へ。 0.3.0 以降は 1 つの MCP サーバーですべてのプロジェクトを扱えるため、設定が必要なのは今回が最後です。

1. インストールまたは更新

pip install -U projectmem

2. すでにあるプロジェクトを探す

pjm doctor

コードが保存されている場所（~/Developer、~/code、~/projects、クラウドフォルダー、Windows 上のすべてのドライブ）を確認し、まだ登録されていない、メモリのあるプロジェクトを一覧表示します。見つからなかったものは手動で追加します。

pjm project register "/Users/you/Developer/repos/ossdrop"

3. 登録する

pjm doctor --fix

4. 1 つの設定で、すべてのプロジェクトを AI に接続する

"mcpServers": {
  "projectmem": {
    "command": "/absolute/path/to/python",
    "args": ["-m", "projectmem.mcp_server"]
  }
}

--root も cwd も指定しません。これにより、すべてのプロジェクトを扱えるようになります。クライアントごとの手順（Claude Desktop、Claude Code、Cursor、Antigravity、Codex）はMCP Integration（推奨）にあります。pjm init を実行すると、このブロックに使用中の Python のパスが入力された状態で表示されます。その後、クライアントを完全に再起動してください — MCP サーバーはコールドスタート時にのみ読み込まれます。

5. 設定を確認する

pjm doctor

最新の projectmem が公開されたときにも通知してほしい場合は、--online を追加します。それ以外の場合、projectmem はネットワークに接続しません。必要であれば、--auto を指定すると 1 日 1 回の確認になります。

設定を編集したあと、もう一度実行してください。まだ 1 つのリポジトリに固定されているクライアントがあれば警告します。新しいプロジェクトがエージェントから見えない場合、これが最もよくある原因です。

すべて問題なしですか？ これで完了です。 以降は、リポジトリごとに次の 1 コマンドを実行するだけです。

pjm init

エージェントはプロジェクトがすでに学習した内容を読み込むため、再発見する必要がなくなり、見つけた内容を書き残します。トークンを節約し、同じ失敗を繰り返さず、セッションを超えて残るメモリを実現します。

コーディングエージェントのメモリとは？

コーディングエージェントのメモリとは、プロジェクトの開発中に起きたこと — 発生した問題、試した方法、うまくいった修正、行った決定 — を記録した永続的な記録です。 新しいセッションの開始時に AI コーディングエージェントが読み込めるように保存されます。これがなければ、セッションは毎回ゼロから始まります。

projectmem は、この用途のために構築されたオープンソースのエージェントメモリレイヤーです。ローカル優先の設計で、メモリはリポジトリ内の通常の .projectmem/ ディレクトリに保存されます。クラウドもアカウントもテレメトリもありません。実行可能なネットワーク接続は、ユーザー自身が有効にする更新確認だけです。ネイティブのMCP サーバーが 17 個のツールを Claude Code、Claude Desktop、Cursor、Antigravity、Codex に公開するため、エージェントは自分でメモリを読み込み、作業を記録できます。

チャット履歴を使うメモリツールとは異なり、projectmem は問題、試行、修正、決定、メモといった型付きイベントを保存します。これにより、projectmem の特徴的な機能が実現します。それは、このプロジェクトですでに失敗した方法を繰り返す前に警告する、コミット前警告です。

pip install projectmem
cd your-project && pjm init

🎬 デモを見る

画面収録による完全版チュートリアル — YouTube で視聴

課題

新しい AI セッションは毎回ゼロから始まります。Claude、Cursor、Aider はどれも、昨日の判断を忘れ、失敗したデバッグを繰り返し、生のソースファイルからコンテキストを再構築するために何百万ものトークンを費やします。

問題はモデルではありません。アーキテクチャです。 ステートレスなモデルには記憶の中枢が必要です。

解決策

projectmem は、AI ツールの上位に位置するローカルファーストなメモリ兼判断レイヤーです。失敗した試行、判断、注意点をすべて記録し、その経験を将来の AI セッションに注入します。Git は何が変わったかを追跡します。projectmem はなぜ変わったか、何を試したか、何が失敗したかを追跡します。

インストール

初めての方はこちらから。 → 完全セットアップガイド インストールから、Claude Desktop、Claude Code、 Cursor、Codex、Antigravity の接続、pjm doctor による確認、ダッシュボードを使った メモリの確認まで、一連の手順を最初から最後まで説明します。各手順には実際のターミナル出力が掲載されています。

プロジェクトに記憶を持たせるためのコマンドは 3 つです。

pip install projectmem
cd your-project
pjm init

これで完了です。pjm init は 3 つの Git フック（pre-commit 警告、post-commit 分類、post-merge 追跡）をインストールし、リアルタイムのファイルウォッチャーを自動起動します。利用可能な場合はプロジェクト間のメモリを引き継ぎ、.projectmem/ を作成します。起動したその時点から記録が始まります。

標準のコマンドは projectmem です。素早く実行できるよう、pjm エイリアスもインストールされます。

✨ 0.3.4 の新機能 — 小さく保てるメモリと、信頼できる警告

サマリーが際限なく増えなくなりました。 ノートには上限がありましたが、最近の問題と決定事項にはこれまで記録されたすべてが列挙されていたため、長く使っているプロジェクトではメモリを読むほうがコードを読むよりもコストがかかっていました。未解決の問題はすべて引き続き表示されます。新しい20件は全文で、古いものは ID のみ表示されます。一方、解決済みの問題は新しいものから10件、決定事項は新しいものから15件に制限され、それぞれ省略した内容と確認先を示す行が追加されます。問題が25件、決定事項が60件あるテストプロジェクトでは、サマリーは約2,900トークンから約1,100トークンになりました。 (#19)

コミットは、変更対象のコードに関連付けて記録されます。 自動記録では、git の並べ替え順で最初に見つかった変更パスを使っていましたが、通常は再生成された .projectmem/summary.md でした。そのため、正当なメモリが古いものと判定され、実際のファイルの履歴が失われていました。今後は、コミットの対象となったソースファイルが記録先になります。削除、名前変更、マージ、リポジトリの最初のコミットにも対応しています。 (#20)

古いメモリに関する警告がタイムゾーンに左右されなくなりました。 0.3.3 の高速化では、git のローカル時刻によるコミット日時と UTC のイベント時刻を文字列として比較していました。そのため、UTC より西の地域では最近の古いメモリが警告されず、UTC より東の地域では新しいメモリがすぐに警告されていました。現在はどちらも UTC で比較されます。また、すでに .projectmem/ に記録されているイベントは、ログを書き換えなくても警告されなくなります。

ガイダンスで、ツールの実際の引数名を示すようになりました。 precheck_file と get_issue の引数名が誤っており（ツールが受け取るのは file_path と issue_id なのに、path と id となっていました）、必須の query を指定せずに search_events を示していました。そのため、エージェントがその呼び出しをコピーすると検証エラーが発生していました。エージェントに示されるすべての呼び出しを、ツールの実際のシグネチャと照合するテストを追加しました。 (#18)

アップグレードする場合は、各プロジェクトで一度 pjm init を実行してください。 古いプロジェクトでは、作成時のリリースの AI_INSTRUCTIONS.md と git フックがそのまま残っていたため、どちらの修正も反映されていませんでした。pjm init は、これらの両方を更新するようになりました。以前の指示は AI_INSTRUCTIONS.md.bak として保持され、フック内の projectmem のブロック外にある内容には手を加えません。

そのほか、誤った問題 ID を指定しても後続のコマンドがすべて失敗することはなくなり、pjm precheck が projectmem 自体のファイルについて警告しなくなりました。また、Python 3.13 と 3.14 に対応しました。

#18 と #20 の修正は Rohan Tiwari が、#19 の最初の上限設定は hylin が貢献しました。#18 と #19 は @medium-effort が、#20 は @bigfree が報告しました。

✨ 0.3.3 の新機能 — precheck の実行時間が伸びなくなり、Windows でも最初から最後まで動作

pjm precheck は編集のたびに実行されます。エージェントへの指示でも、最初に呼び出すよう定められているため、そのコストは常に発生します。イベント数 1,200 件のプロジェクトで 26 秒かかり、毎週さらに遅くなっていました。単一ファイルについての質問に答えるために、イベントごとに git log を実行していたためです。今では、イベントがそのファイルに言及した最も古い時点を上限として、ファイルごとに 1 回だけ呼び出すようになりました。

プロジェクトの経過期間に対して、レイテンシーは線形に増加せず、一定になりました。マージコミットを含め、旧アルゴリズムを再実装した結果とも一致しています。ただし、この変更で発生したタイムゾーンのバグは例外で、0.3.4 で修正されています。

廃止した決定が再び表示されなくなりました。 supersedes は 0.1.4 から存在していましたが、エージェントが作業中に実際に読む 2 つの機能、get_context と precheck_file ではフィルタリングされていませんでした。そのため、決定を廃止しても、引き続き提示されることがありました。両方でフィルタリングするようになり、AI_INSTRUCTIONS.md にも決定の廃止方法がようやく記載されました。これまでモデルがその機能を呼び出さなかったのは、この記載がなかったためです。

ブリッジファイルにプロジェクト名が記載され、AGENTS.md も作成されます。 1 つのサーバーがすべてのプロジェクトに対応するため、プロジェクト名の指定がない呼び出しは、推測せずに拒否されます。しかし、エージェントに名前を伝えるものがなかったため、エラーから名前を知り、毎回のセッションで再試行していました。今では名前がブリッジに記載されます。また、CLAUDE.md だけでなく AGENTS.md にも記載されます。Antigravity と Codex は前者を読まないためです。

Windows に関する 6 件の報告を解決しました。 Git フックには bash のシバンが含まれていましたが、Git for Windows では解決できないことがよくありました。解決できないシバンはフックをスキップするのではなく、コミットを中断します。組み込みバイナリのパスは、シェルのエスケープ処理によってバックスラッシュが失われていました。venv のフォールバック先は bin/ でしたが、Windows には存在しません。pjm watch --daemon のプロセスを確認も停止もできませんでした。また、出力に含まれる罫線文字によって、cp1252 のコンソールでは pjm init が完全に失敗していました。しかも、その時点ですでにすべての作成が終わっていたため、コマンドは処理を実行したのに失敗を報告していました。

報告されたどの問題も、コードを読むのではなく、問題を報告したマシン（Windows 11）と 3 つの MCP クライアント（Antigravity、Claude、Codex）で projectmem を実行して修正しました。報告者は @medium-effort です。同氏は 0.3.2 の Windows デーモンサポートにも貢献しました。

✨ 0.3.2 の新機能 — Windows に正式対応

pjm watch --daemon は Windows で AttributeError: module 'os' has no attribute 'fork' によりクラッシュしていました。フォークの代わりに、デタッチされたワーカーを起動するようになり、すべてのプラットフォームでバックグラウンド監視が動作します。

この修正により、その背後に隠れていた 2 つ目のバグも見つかりました。プロセスの生存確認に os.kill(pid, 0) を使っていましたが、これは POSIX の慣用的な方法であり、そのままでは移植できません。Windows では os.kill が TerminateProcess に振り分けられ、シグナル 0 は確認として機能しないためです。そのため、Windows ではウォッチャーを確認も停止もできず、pjm watch --daemon を実行するたびにプロセスが増えていました。どちらも修正済みです。

Windows のデーモンサポートは @medium-effort から提供されました（#13）。

pjm doctor にも 2 つの機能が追加されました。設定を編集する前に、AI クライアントを終了するよう案内するようになりました。設定ファイルにはアプリ自体の設定も含まれているため、クライアントを起動したままにすると、終了時にファイル全体を書き換え、削除したばかりの --root を復元することがあります。また、前回の状態を記憶するようになり、問題のなかった設定が再び固定されると、doctor の動作が不安定になったように見せず、元に戻された設定として報告します。処理はローカルファイルのみを対象とし、マシンの外にデータが送信されることはありません。

✨ 0.3.1 の新機能 — アップグレードのタイミングを確認

どちらのダッシュボードにも、ページを生成したバージョンが表示され、その横にアップデートを確認リンクが追加されました。クリックするまでページからリクエストは送信されません。PyPI の公開 JSON はブラウザーから直接取得され、マシンに関する情報は一切送信されません。コマンドラインでは、pjm doctor --online は一度だけ確認し、pjm doctor --auto は毎日確認するよう記憶します。どちらも、明示的に指定しない限り無効です。

✨ 0.3.0 の新機能 — 1 つのサーバーで複数のプロジェクトを管理

これまでは、MCP の設定は 1 つのリポジトリに紐づいていました。11 個のプロジェクトがあれば、サーバーの設定も 11 個、再起動も 11 回必要でした。**0.3.0 では、1 つのサーバーから登録済みのすべてのプロジェクトを利用できます。**設定を一度貼り付ければ、その後 pjm init を実行したすべてのリポジトリにアクセスできます。

pjm project list          # what this server can reach
pjm project use ossdrop   # the default when a call names no project

log_issue(summary="stars come back empty", project="ossdrop")
→ Logged issue #0019 → ossdrop: stars come back empty

書き込み先のプロジェクトは、書き込みのたびに明示されます。サーバーを共有する場合に危険なのは、「何も動かない」ことではなく、誤ったリポジトリへの書き込みが成功することです。既存の --root 設定は変更せずに引き続き使えます。また、サーバーを特定のプロジェクトに固定すると、要求されてもほかの場所への書き込みを拒否するようになりました。

0.3.0 のその他の変更：

• **修正：新規インストールで MCP サーバーが動作しない問題。**mcp 2.0 で FastMCP の名前が変更され、古いインポートパスで例外が発生するようになっていました。そのため、2026-07-28 以降に pip install projectmem を実行したすべての環境で、インポート時にサーバーが停止していました。⁠@VIVAAN-DHAWAN によって発見され、修正されました。
• **セキュリティ：pjm visualize における保存型 XSS。**イベントの概要がエスケープされずに DOM に渡されており、Git のコミットメッセージがイベントの概要になるため、プルしたブランチに細工されたコミットが含まれていると、ダッシュボードでスクリプトを実行できる可能性がありました。現在はすべての出力先でエスケープされます。
• ダッシュボードを再構築 — 共有可能なメモリーカード、問題 → 試行 → 修正の全過程を記録するケースファイル、作業量を示すツリーマップ、ファイルごとの詳細情報、そして前回開いた場所から表示されるグローバルビューを追加しました。

レジストリーの移行は自動で行われます。0.2.x のパス一覧は初回読み込み時に変換され、同じ場所に .bak が保存されます。

✨ 0.2.0 の新機能 — ワークスペースリリース

0.1.6 では、1 つのプロジェクトのメモリを確認できるようになりました。0.2.0 ではそれをワークスペース全体に広げ、起きたこと（メモリ）とコードの実態（構造）の隔たりを解消します。

• 🌐 グローバルダッシュボード — pjm dashboard では、pjm init を実行したすべてのプロジェクトを 1 ページで確認できます。記録された課題の合計、確認済みの修正、回避できた行き詰まり、節約できたトークン、プロジェクトごとの評価、「要対応」リストが表示されます。カードをクリックすると、そのリポジトリ専用のダッシュボードが新たに生成されて開きます。これはグローバルなビューであり、グローバルなストアではありません。各リポジトリの .projectmem/ は読み込み時に集約され、フォルダーの外に出ることはありません。デフォルトではサーバーレス（静的スナップショット）です。--serve を追加すると、Refresh ボタンでファイルを再読み込みする小さな一時ライブサーバーを起動できます。バックグラウンドデーモンはなく、Ctrl+C で停止します。
• 🧬 構造と関連性 — pjm map --build（pjm init で自動実行）はコードベースを走査し、Python の場合はインポートを解決して実際の依存関係グラフを作成します。Project Map の Graph ビューと Flow ビューに、実際のファイルとそれらをつなぐインポート関係が表示されるようになりました。キャッシュ（structure.json）はコードから生成され、gitignore 対象であり、コミットされることはありません。コードは読み取りのみです。
• 🔥 構造上の失敗ヒートマップ (組み合わせ機能) — 純粋なコードグラフツールにも、純粋なメモリツールにも描けないビューです。失敗を繰り返したファイルが赤く光り、実際のインポートグラフに直接重ねて表示されます。構造はコードから、ヒートマップはメモリから生成され、それらが組み合わされるのはレンダラー上だけです。
• 🗂️ plan.md — 新しい編集可能な意図ファイルです。アイデアや計画、つまりこれからやろうとしていることを記録します。イベントログとは意図的に分けられています。events.jsonl → summary.md には起きたことを記録し、plan.md にはこれからやろうとしていることを記録します。AI はセッション開始時にこれを読み込み、直接編集します。計画がイベントになることはありません。pjm plan / pjm plan "idea" / MCP get_plan()。

すべてが 100% ローカルに保たれます。グローバルダッシュボードは読み込み時に集約するだけで、コードの履歴を集める中央のハニーポットではありません。

グローバルダッシュボード — pjm init を実行したすべてのプロジェクトを 1 つのビューに表示します。評価、課題、節約額、「要対応」リストが読み込み時に集約されます。各カードをクリックすると、そのリポジトリ専用のダッシュボードが開きます。

プロジェクトの記憶は、眺めて共有することもできます。

• 🎬 Showoff — 実際のイベントログからすべて描画される、3 つのアニメーション付きシーンを備えたダッシュボードタブです。Story Replay（ノードごとにプロジェクトの履歴が組み上がる様子を見られます）、Orbit（ファイルがプロジェクトの周りを、公転するファイルの周りをイベントが回ります）、Universe（プロジェクトを回転する銀河として表示します。明るく輝く星はすべて実際の課題、試行、修正、判断です。クリックすると詳細を確認できます）。
• ⏺ 内蔵レコーダー — REC を押すと（10～60 秒）、Showoff がアニメーションの .webm クリップをダウンロードします。クリップはすべてローカルで描画され、「made with projectmem」バッジが付きます。デバッグのストーリーを、ツイートやスタンドアップで共有できます。
• 🗺️ Flow — Project Map のデフォルトビューです。PROJECT → DIRECTORIES → FILES → WHAT HAPPENED → MEMORY を読み取れる、レイヤー式のフローチャートです。繰り返し失敗したファイルは経路上で赤く光り、すべてのファイルに結果を示すチップが表示されます。そして、すべてが events.jsonl のシリンダーへと流れ込みます。Tree ビューと Graph ビューもワンクリックで表示できます。
• 🧵 Time Spine — Timeline のデフォルトビューです。スクロールできるリアルタイムの軸があり、問題は左側に分岐（課題、失敗した試行）、ナレッジは右側に分岐（修正、判断、メモ）します。カードにカーソルを合わせると、関連する課題のスレッド全体が点灯します。従来のリストは「Details」として引き続き利用できます。

Showoff · Universe — 明るく輝く星はすべて、このプロジェクトの記憶に記録された実際のイベントです

Project Map · Flow — ファイルごとに何が起きたのかを示し、追記専用の記憶へと流れ込みます

Timeline · Time Spine — 左には問題、右にはナレッジが表示され、中央では時系列に沿って進みます

きっと気に入る理由

• コミット前の警告 — pjm precheck は、失敗した方法を繰り返そうとしている場合、変更頻度の高いファイルを変更しようとしている場合、または未解決の問題に触れようとしている場合に、コミットする前に警告します。このプロジェクトで記録された失敗に基づいて動作するため、その下支えとしてメモリレイヤーが必要です。警告には行き詰まった方法そのものが表示されるようになりました（「ここですでに失敗したこと：✗ CSS contain:layout を試した」）。また、pjm precheck --snooze 2h で通知を控えめに停止できます。スヌーズ自体も記録されるため、通知を止めたことも監査対象になります。
• 古くなったメモリの検出 (0.1.4 で新登場) — projectmem はメモリを決して削除しません。ファイルを参照するすべての決定は、そのファイルの git 履歴と照合されます。ファイルの内容がその後変わっている場合、メモリに フラグが付けられ（「auth.py への 7 回のコミットより前の情報 — 確認または置き換えが必要」）、人が判断します。pjm decision "new way" --supersedes <id> で、古いイベントをタグ付きのままログに永続的に残し、適切に置き換えられます。
• セッション開始時のブリーフィング (0.1.4 で新登場) — pjm brief は、「どこまで進めていたか？」への答えを 1 画面にまとめます。現在の警告、古くなっている可能性のあるメモリ、未解決の問題、最近の決定、スタック固有の注意点、前週比の差分を含む予防スコアを表示します。
• MCP を使わないエージェント向けのメモリ (0.1.4 で新登場) — pjm export --claude-md は、現在有効な決定、注意点、「再試行禁止 — すでに失敗した方法」の一覧を、CLAUDE.md（または .cursorrules）内のマーク付きブロックにまとめます。Copilot、通常の Claude、ファイルを読み取るあらゆるエージェントが、プロジェクトの判断を引き継げます。
• スマートなコンテキスト注入 — pjm wrap claude（または cursor/aider）は、セッション開始前に、トークン予算に合わせたメモリブロックを AI に注入します。AI は何も知らない状態ではなく、経験を積んだ状態で始まります。
• 推定 ROI スコア — pjm score は、デバッグ時間の削減、回避したトークン数、節約した金額についてツール独自の推定値を添えた評価（A+ → F）を出力します。CI に対応した JSON 出力と、README 用の shields.io バッジも利用できます。
• プロジェクト横断メモリ — あるリポジトリで得た教訓は、いつまでも引き継がれます。ライブラリ固有の注意点、決定、パターンは ~/.projectmem/global/ に保存され、新しいプロジェクトにも引き継がれます。マニフェスト（pyproject.toml、requirements.txt、package.json、Cargo.toml、go.mod）があるプロジェクトには、そのスタックに関する教訓だけが提示されます。
• リアルタイムのファイル監視 — バックグラウンドデーモンが、コミット間で同じファイルが短時間に何度も編集される状況（デバッグセッション）を検出します。バッテリーの状態と gitignore を考慮し、pjm init によって自動起動します。
• ネイティブ MCP サーバー — Claude Desktop、Cursor、Antigravity、Codex、および MCP 対応ツールに接続できます。17 個のネイティブツールにより、AI はコンテキストを読み取り、既知の失敗がないかファイルを確認し、plan.md を読み取り、作業を自動的に記録します。初回リリース時に 4 つすべてのクライアントでエンドツーエンドの動作を検証済みです。0.3.3 の受け入れテストスイートは Antigravity、Claude、Codex で再実行されました。
• インタラクティブダッシュボード (0.1.6 で拡張) — pjm visualize を実行すると、6 つのタブを備えたローカルダッシュボードが開きます。Overview、Story Map（折りたたみ／フォーカス操作付きの失敗ヒートマップ）、ROI Dashboard、Project Map（Flow／Tree／Graph。実際のコード構造を表示）、Timeline（Time Spine／Details）、そして Showoff（動画レコーダー内蔵のアニメーション付きストーリーシーン）です。
• すべてのプロジェクトで 1 つの MCP サーバー (0.3.0 で新登場) — リポジトリごとに設定するのではなく、クライアントの設定は一度だけ行います。呼び出し時にプロジェクト名を指定するか（project="ossdrop"）、現在のプロジェクトを使用します。書き込みのたびに、どのリポジトリに反映されたかが報告されます。また、--root を固定したサーバーは、そのルート外への書き込みを拒否します。既存の単一プロジェクト設定には影響しません。
• グローバルダッシュボード (0.2.0 で新登場) — pjm dashboard は、pjm init を実行したすべてのリポジトリを横断する単一のビューです。評価、問題、節約額、プロジェクトごとの詳細表示を確認できます。これはグローバルな ビュー であり、グローバルな ストア ではありません。各リポジトリのメモリは読み取り時に集計され、そのフォルダーから外に出ることはありません。デフォルトではサーバーレスです。--serve を指定すると、一時的なライブサーバーが起動します（停止するには Ctrl+C を押します）。
• コード構造と判断 (0.2.0 で新登場) — pjm map --build はコードベースを読み取り、実際のインポートグラフを作成します。Project Map はその上に、イベントログから得た失敗のヒートマップを重ねます。繰り返し問題が発生するファイルが、実際のつながりを示す構造の上で赤く光ります。構造キャッシュはコードから生成され、gitignore の対象となるため、コミットされることはありません。
• メモリとは別の意図 (0.2.0 で新登場) — plan.md にはアイデアや計画（これから 行うつもり のこと）を記録し、追記専用のイベントログ（実際に 起きたこと）とは意図的に分けて管理します。pjm plan または MCP の get_plan() を使います。AI は計画を直接編集でき、計画がイベントになることはありません。
• 100% ローカル — クラウド、テレメトリー、アカウントは不要です。コードもメモリも、すべて自分のマシンに保存されます。

比較

_{✅ 対応 · 🟡 一部対応 · ❌ プロジェクト独自のドキュメントでは確認できず · ? ドキュメントに記載なし。各プロジェクトの README、ドキュメント、変更履歴をもとに 2026-10-02 に確認したスナップショットです。設計上の機能を示すものであり、ベンチマーク結果ではありません。修正のご提案を歓迎します — issue を作成。}

_{データベースはなく、常時起動しておくものもありません。MCP サーバーは AI クライアントが起動する stdio サブプロセスで、それ以外はすべて通常のファイルです。唯一のサーバーは、任意で使える pjm dashboard --serve です。Ctrl+C で起動・停止できる、一時的なローカルビューアーです。}

🚧 今後の予定

• 既存の記憶をインポート — pjm import（0.4.0 で提供予定）を使うと、mem0、agentmemory、Letta、Claude のセッションログから projectmem に履歴を移行できます。中核となるイベントの分類（issue、試行、修正、決定、メモ）のみを割り当てるため、役立つ情報だけを取り込み、他のツールの不要な情報は入りません。これまでの判断履歴も一緒に移行できます。

対応してほしいデータソースがある場合は、issue を作成して、どこから移行するのかをお知らせください。

AI が記憶を読む仕組み（トークン効率）

このアーキテクチャは、AI は要約された小さなファイルを読み、大きな生ログからそれらを生成するのはツールであるというルールを中心に設計されています。

ベンチマークではなく推定値です。 0.3.4 の要約そのものを測定したところ、作成から間もないプロジェクトでは約 250 トークン、issue が 25 件、決定が 60 件あるプロジェクトでは約 1,100 トークンでした。未解決の issue が多い場合は、さらに増えます。

AI が events.jsonl を直接読むことはありません。 このファイルはツール（pjm score、pjm context、pjm wrap）用です。ツールが生ログを、コンパクトで AI が読み取れる要約にまとめます。

1つのサーバーで複数のプロジェクトに対応

0.3.0以降、1つのMCPサーバーで登録済みのすべてのプロジェクトを利用できます。設定を一度貼り付けるだけで、その後 pjm init を実行したすべてのリポジトリにアクセスできます。設定を追加したり、再起動したりする必要はありません。

pjm project list          # what this server can reach
pjm project use ossdrop   # the default when a call names no project
pjm project alias ossdrop od

エージェントは呼び出しごとにプロジェクトを選択します。

log_issue(summary="stars come back empty", project="ossdrop")
→ Logged issue #0019 → ossdrop: stars come back empty

書き込みのたびに、どこに反映されたかが示されます。 この応答が重要です。プロジェクトが1つだけの構成では、サーバーの設定を誤ると単に失敗します。しかし共有サーバーは、間違ったリポジトリへの処理が成功する可能性があり、その場合、2つの監査記録が同時に破損します。応答に示された名前が意図したプロジェクトと異なる場合は、処理を止めてください。

呼び出しのルーティング順（優先度の高い順）：

クライアントのルートに対応すると、それらは意図的にアクティブなプロジェクトより優先されます。ルートは現在作業している場所ですが、アクティブなプロジェクトは数日前に設定したモードだからです。両者が食い違う場合、古いほうが誤った選択です。

単一リポジトリの構成には変更はありません。pjm init --mcp-config-single は引き続き固定設定を出力し、既存の --root エントリもこれまでどおり機能します。

MCP 連携（推奨）

対象： Claude Desktop、Cursor、Antigravity、Codex、およびネイティブ MCP に対応するすべてのツール。MCP サーバーはAIにメモリを読み込み、すべての操作を自動で記録させます。

0.3.0以降、設定はリポジトリごとではなく、一度だけ行います。 以下のブロックには --root がありません。サーバーは登録済みのすべてのプロジェクトに対応し、呼び出しごとにそれぞれのプロジェクトを特定します。これを貼り付けると、その後 pjm init を実行したすべてのリポジトリにアクセスできます。設定を追加したり、再起動したりする必要はありません。

"mcpServers": {
  "projectmem": {
    "command": "/opt/anaconda3/bin/python",
    "args": ["-m", "projectmem.mcp_server"]
  }
}

既存のプロジェクトがある状態でアップグレードしますか？ レジストリに記録されるのは、レジストリが導入された0.2.0以降に pjm init を実行したプロジェクトのみです。そのため、それより前のプロジェクトは登録されておらず、グローバルモードではレジストリ経由でルーティングされます。次のコマンドを実行すれば解決できます。

pjm doctor          # what's unregistered, what's stale, what's still pinned
pjm doctor --fix    # register what it found

コードが実際に置かれている場所を検索します。~/Developer、~/code、~/src、~/projects などに加え、Windowsでは固定ドライブすべてを対象とします。プロジェクトはホームフォルダーの下だけでなく、D:\ や E:\ にもよく置かれているためです。検索場所を指定するには、次のようにします。

pjm doctor --path ~/work --path /Volumes/ssd --fix
pjm project scan D:\ E:\ --depth 3     # the same walk, without the other checks

実行するまでは何も検索されず、--fix を指定しない限り何も書き込まれません。アップグレード後、CLI は pjm doctor を一度案内します。wheel のインストールではコードを実行できないため、入力する最初のコマンドが、その案内を表示できる唯一の機会です。

登録済みのプロジェクトが1つなら、これで設定は完了です。呼び出し先は1つしかありません。複数ある場合、AIは project="<name>" を渡すか、pjm project use <name> でデフォルトを設定します。pjm init は、Python のパスを自動入力したこのブロックを出力します。

0.2.xからアップグレードしますか？ 既存の --root エントリはこれまでどおり機能し、固定されたサーバーは要求されても自分のリポジトリ外への書き込みを拒否するようになりました。すべてのプロジェクトで1つのサーバーを使いたい場合は、上記のブロックに置き換えてください。

3 分でできるワークフロー（セットアップは AI に任せましょう）

1. インストールして初期化します。 pip install projectmem を実行し、プロジェクトに cd して pjm init を実行します。または、AI に実行を依頼するだけでもかまいません。
2. projectmem MCP サーバーをセットアップするよう AI に依頼します。 クライアントの設定ファイルを AI 自身で編集できます。（そのための権限が必要です。Auto／accept-edits モードを使うか、確認されたときにファイルの編集を承認してください。クライアントごとの正確な設定は以下のセクションに記載しています。手動で貼り付けたい場合はそちらをご覧ください。）
3. AI ツールを再起動して MCP サーバーを読み込んでから、次のプロンプトでセッションを開始します。

Hi — I use projectmem as this project's memory. Before anything else,
call get_instructions(), then get_summary(), then get_project_map() to
load what we already know. As we work, log issues, attempts
(failed/worked), fixes, decisions, and notes with the projectmem tools,
and call precheck_file(file_path) before you edit a file. Ideas and plans go
in plan.md via get_plan() — never as events.

厳密には、このプロンプトは任意です。MCP サーバーが正しくインストールされていれば、AI は自動的にメモリを見つけます。ただし、このプロンプトを伝えると情報の記録が目に見えて安定するため、おすすめします。

• プロジェクトごとに繰り返します： pjm init と同じ開始プロンプトを使います。
• ウィンドウを閉じたあとに再開する場合： 「リマインダー：ここでは projectmem をメモリとして使っています。」 と一言添えて始めれば、セットアップ全体が前回の続きから再開されます。

手動で設定したい場合は、各クライアントの正確な検証済み設定を以下に記載しています。

Claude Desktop

最も簡単な方法 — UI から設定を開きます：

• macOS： Claude メニュー → Settings… → Developer タブ → Local MCP servers → Edit Config。
• Windows／Linux： 同じ手順（Settings → Developer → Edit Config）が想定されています。ご利用のプラットフォームで異なる場合は、issue を作成してください。内容を更新します。

設定ファイルのパスを直接指定する場合：macOS では ~/Library/Application Support/Claude/claude_desktop_config.json、Windows では %APPDATA%\Claude\claude_desktop_config.json、Linux では ~/.config/Claude/claude_desktop_config.json（移動している場合は $XDG_CONFIG_HOME/Claude/）です。pjm init は、実行したマシンに適したパスを表示します。

次のブロックを貼り付けます。

"mcpServers": {
  "projectmem": {
    "command": "/opt/anaconda3/bin/python",
    "args": ["-m", "projectmem.mcp_server"]
  }
}

このブロックについて、知っておくべきことが 2 つあります：

• python の絶対パスを使用してください（例：/opt/anaconda3/bin/python。または which python を実行して確認できます）。Claude Desktop のサブプロセスはシェルの PATH を引き継がないため、"python" だけでは失敗することがよくあります。
• cwd フィールドはもう必要ありません。また、これまでも当てにできるものではありませんでした。 Claude Desktop の現在のビルド（Epitaxy／Cowork ワークスペースシステムを搭載）は cwd を黙って無視します。そのため、サーバーは cwd=/ で実行され、.projectmem/ を見つけられません。以前のリリースで --root が必要だったのはそのためです。代わりにレジストリを使います。サーバーは実行場所ではなく、プロジェクト名からプロジェクトを見つけます。

"mcpServers": {
  "projectmem": {
    "command": "/opt/anaconda3/bin/python",
    "args": [
      "-m", "projectmem.mcp_server",
      "--root", "/absolute/path/to/your/project"
    ]
  }
}

その後、Claude Desktop を完全に終了し（Mac では Cmd+Q）、再度開きます。MCP サーバーは完全に終了した状態から起動したときにのみ初期化されます。

Cursor

MCP サーバーを登録する方法は 2 つあります。ワークフローに合った方法を選んでください。

1. グローバル（推奨）： Cursor メニュー → Settings… → 左サイドバーの Tools & MCPs → Installed MCP Servers → Add Custom MCP。以下の JSON を貼り付けます。
2. プロジェクトごと： JSON を <project-root>/.cursor/mcp.json に配置します。そのプロジェクトを開いているときのみ有効です。

{
  "mcpServers": {
    "projectmem": {
      "command": "/opt/anaconda3/bin/python",
      "args": ["-m", "projectmem.mcp_server"]
    }
  }
}

このブロックについて知っておくべきことが 2 つあります（Claude Desktop と同じ注意点です）。

• python には絶対パスを使用してください（which python を実行すると確認できます）。Cursor のサブプロセスは、シェルの PATH を確実に引き継ぐわけではありません。
• cwd フィールドは指定しないでください。 Cursor は Claude Desktop と同様に、このフィールドを黙って無視するため、サーバーは cwd=~ で実行されます。0.3.0 以降は、サーバーの実行場所ではなくレジストリ内の名前でプロジェクトを検索するため、この点は問題になりません。

グローバルに登録すれば、1 つのエントリですべてのプロジェクトをカバーできます。サーバーをリポジトリを開いているときだけ有効にしたい場合は、プロジェクトごとの .cursor/mcp.json も引き続き使えます。その場合は、args に "--root", "/absolute/path/to/your/project" を追加してパスを固定してください。

その後、Cursor を完全に終了し（Mac では Cmd+Q）、再起動します。 projectmem は CWD から上位のディレクトリをたどって .projectmem/ も自動検出します（git が .git/ を探すのと同様です）。また、PROJECTMEM_ROOT と --root <path> CLI 引数も尊重します。

Antigravity

Antigravity（Google の AI IDE）は標準の MCP に対応しています。

最も簡単な方法 — UI から設定を開く：

1. Agent ウィンドウ（右側のチャットパネル）を開きます。
2. パネルのヘッダーにある ⋯ Additional Options ボタンをクリックします。
3. MCP Servers → Manage MCP Servers → Add new（または Edit Config）を選択します。

直接編集する場合、ファイルは ~/.gemini/antigravity/mcp_config.json にあります。

次のブロックを貼り付けます。

{
  "mcpServers": {
    "projectmem": {
      "command": "python",
      "args": ["-m", "projectmem.mcp_server"]
    }
  }
}

Antigravity は cwd フィールドを尊重するため、"cwd": "/absolute/path/to/your/project" を追加すれば機能します。ただし、そのサーバーは 1 つのリポジトリに固定されます。省略すれば、同じエントリですべての登録済みプロジェクトに対応できます。

その後、Antigravity を完全に終了し（Mac では Cmd+Q）、再起動します。 MCP サーバーはコールドスタート時にのみ初期化されます。17 個すべての projectmem ツールは、Claude Desktop／Cursor と同じように登録されます。

Codex

Codex は MCP の設定を JSON ではなく TOML 形式で ~/.codex/config.toml に保存します。Settings → MCP Servers → Add MCP Server に UI フォームもありますが、複数のクライアント間で検証した際に、フォームの Save ボタンでは確実に保存されませんでした。ファイルを編集する方法のほうが速く、確実です。

最も簡単な方法 — ~/.codex/config.toml を直接編集する：

既存の設定を維持したまま、次のブロックを追記します。

[mcp_servers.projectmem]
command = "/opt/anaconda3/bin/python"
args = ["-m", "projectmem.mcp_server"]

このブロックについて知っておくべきことが 3 つあります。

• python には絶対パスを使用してください（which python を実行すると確認できます）。Codex のサブプロセスは、シェルの PATH を確実に引き継ぐわけではありません。
• --root も cwd も不要になりました。 以前のリリースでは、多重防御として --root を渡していました（cwd フィールドは Claude Desktop や Cursor とは異なり、Codex では機能するようです）。0.3.0 以降はレジストリによってどちらも不要になりました。このサーバーを 1 つのリポジトリに固定したい場合に限り、args に "--root", "/absolute/path/to/your/project" を追加してください。
• 推論レベルを medium 以上に設定してください。 推論レベルが低いと、Codex はセッション開始時の 3 つの処理のうち get_instructions をスキップし、AI が Setup Mode のワークフロールールを見落とす可能性があります。medium 以上なら、3 つすべてが自動的に適用されます。

TOML を検証します：

python -c "import tomllib; tomllib.load(open('/Users/<you>/.codex/config.toml','rb')); print('OK')"

OK と表示されるはずです。そうでない場合、パーサーが問題のある行を示します。

その後 Codex を完全に終了し（Mac では Cmd+Q）、再起動します。 他のすべての MCP クライアントと同様、コールドスタートが必要です。Codex の MCP サーバーはチャットセッションで最初のツール呼び出しがあるまで起動しません。再起動直後に ps aux でプロセスが見つからない場合は、Codex のチャットにメッセージを送り、もう一度確認してください。

推論レベルに関する注意： Codex のモードセレクターはチャット入力欄の下部にあります。セッション開始時の 3 つすべての処理を実行するには、low ではなく medium に設定してください。設定はセッションごとに保持されます。

初回実行時の権限プロンプト

MCP 対応クライアント（Claude Desktop、Cursor、Antigravity、Codex）で初めて使用する際、AI は projectmem ツールを呼び出す前に毎回権限を求めます。これは想定されたセキュリティ動作です — MCP クライアントは新しいツールごとに明示的な同意を必要とします。各ツールを一度承認すれば、そのセッションではプロンプトは再表示されません。

その他の MCP ツール

MCP 互換のクライアントであればどれでも動作します — ツールの向き先を python -m projectmem.mcp_server に設定し、cwd をプロジェクトルートに設定するか、親ディレクトリをたどる自動検出に任せてください。

公開されている MCP ツール

AI が呼び出せる全 17 ツールです。すべてのリポジトリツールは省略可能な project 引数を受け取ります — 1 つのサーバー、多数のプロジェクト を参照してください:

読み取り側（12 ツール）:

書き込み側（5 ツール）:

CLI リファレンス

コアメモリ

インテリジェンスレイヤー

プロジェクト（グローバル MCP）

可視化とユーティリティ

ログ記録コマンドには、--at "file.py:42" を指定して正確な位置情報を付加できます。

plan.md — メモリとは分けて管理する意図

pjm init は .projectmem/plan.md のひな形を作成します。ここには、アイデアや計画、つまり、これから何をするつもりかをプレーンな Markdown で記述します（アイデア · 進行中の計画 · 次に行うこと · いつか行うこと · 完了）。意図的にイベントログから分けられている唯一のファイルです。

• events.jsonl → summary.md は、実際に起きたことを記録します（追記専用で、書き換えられることはありません）。
• plan.md は、これから行うつもりのことを記録します。PROJECT_MAP.md と同様に、あなた（または AI）が直接編集します。

AI はセッション開始時に get_plan() を通じて内容を読み込み、その場で更新します。アイデアを追加したり、項目にチェックを付けたり、完了した作業を 完了 に移動したりできます。計画はイベントとして記録されないため、意図がメモリの監査履歴に混ざることはありません。pjm plan は内容を表示し、pjm plan "auto-batch the exporter" はアイデアを追記します。チームで意図を共有できるよう、Git にコミットされます（Git で無視されません）。

例：コミット前の警告

$ git commit -m "switch auth to JWT"

projectmem: Pre-Commit Check
─────────────────────────────────────────────
  src/auth/middleware.py
    WARN  What already failed here (2 attempts):
           ✗ tried switching to JWT middleware (2d ago)
           ✗ patched session timeout to 60min (5d ago)
    WARN  HIGH CHURN: 5 changes in last 30 days
    WARN  1 possibly-stale memory cites this file
           decision [evt_9db5a3f8…] "auth uses session
           cookies, 30min timeout" — predates 7 commits
           Confirm it still holds, or retire it:
           pjm decision "..." --supersedes <id>
─────────────────────────────────────────────
3 warning(s). Review before committing.

リファクタリングに集中する間、警告を静かにしておきたいですか？pjm precheck --snooze 2h を実行すると、警告が一時停止し、その操作自体も記録されます。また、すべてのコミットに薄い色の 1 行が表示されるため、警告がないことをチェックに合格したと誤解することもありません。

プライバシーとセキュリティ

デフォルトでは、projectmem は要約済みファイル（summary.md、PROJECT_MAP.md、AI_INSTRUCTIONS.md、issues/）をコミットし、未加工ログと実行時ファイル（events.jsonl、watch.pid、watch.log）を Git の追跡対象から除外します。つまり、チームメイトの AI はチームのナレッジを自動的に引き継ぎます。git clone するだけで、AI はチームが学んだことをすでに把握しています。

完全なプライバシーを確保したいですか？ .gitignore に .projectmem/ を 1 行追加してください。何もマシンの外に出ません。

セキュリティポリシーと脅威モデルの全文：SECURITY.md · プライバシーとセキュリティのガイド

設計原則

• ローカル優先 — クラウドもテレメトリもなく、更新チェックを有効にしない限り、ネットワーク通信もありません。データがマシンの外に出ることはありません。
• プロジェクト単位 — メモリはリポジトリ内にあります。コードを移動すると、メモリも一緒に移動します。
• AI ツールに依存しない — MCP 経由でネイティブに、または Markdown の指示を通じて幅広く利用できます。あらゆる AI ツール、あらゆるワークフローに対応します。

使用技術

projectmem は、次の優れたオープンソースプロジェクトを基盤としています。

• Typer — pjm を使いやすくする CLI フレームワーク
• Model Context Protocol — AI エージェントがローカルのツールとやり取りできる、Anthropic のオープン仕様
• watchdog — クロスプラットフォームのファイルシステムイベント監視（pjm watch の中核）
• D3.js — pjm visualize のインタラクティブな可視化

研究と引用

projectmem は、査読可能な研究論文で紹介されています。

PROJECTMEM: A Local-First, Event-Sourced Memory and Judgment Layer for AI Coding Agents Ripon Chandra Malo, Tong Qiu — University of Utah arXiv:2606.12329 · cs.AI

この論文では、Memory-as-Governance という捉え方を紹介しています。これは、単にエージェントに回答するだけでなく、次の行動に働きかけるメモリを指します。また、設計、決定論的なコミット前判定ゲート、現代のメモリシステム12種類との機能比較、そして実際のプロジェクト10件を対象に2か月間で207件のイベントを記録したドッグフーディング調査について報告しています。

projectmem が研究や執筆に役立つ場合は、次の形式で引用してください。

@misc{malo2026projectmem,
  title         = {PROJECTMEM: A Local-First, Event-Sourced Memory and
                   Judgment Layer for AI Coding Agents},
  author        = {Malo, Ripon Chandra and Qiu, Tong},
  year          = {2026},
  eprint        = {2606.12329},
  archivePrefix = {arXiv},
  primaryClass  = {cs.AI},
  url           = {https://arxiv.org/abs/2606.12329}
}

ライセンス

MIT — 個人利用、商用利用、企業利用に、いつまでも無料で使えます。

より多くの開発者に届けるためにご協力ください

お金は必要ありません。あなたの力が必要です。

projectmem は1人の開発者によって始められ、現在はオープンソースコミュニティの貢献者たちとともに形作られています。スター、シェア、貢献の一つひとつが、プロジェクトの存続と成長につながります。

• リポジトリにスターを付ける — ワンクリックで、プロジェクトを見つけてもらいやすくなります
• X / LinkedIn でシェアする — AIにコードベースを覚え直させるため、開発者が料金を払い続ける必要はないと伝えてください
• issue を作成する — バグ、機能リクエスト、または気軽なフィードバックをお寄せください
• コードに貢献する — PR を歓迎します。大規模な変更の場合は、まず issue を作成してください
• 職場や商用製品で projectmem を利用していますか？ [email protected] までご連絡ください。どなたが私たちと一緒にプロジェクトを展開しているのか知りたいと思っています。無料です。利用の様子を聞けるのが何よりうれしいのです。

スターやシェアはお金より大切です。それでも支援したい場合は、こちらからどうぞ： GitHub でスポンサーになる →