メモリの書き方

メモリは、アシスタントが後から読めるようにチームが書き残しておく短いMarkdownのメモです。メモリはワークスペースのパスに置かれ、アシスタントがそのパス配下で作業しているときにだけ提示されます。Pathruleで最もよく使われるコンテンツタイプであり、最初に取り組みやすいものでもあります。

このページでは、メモリを書くべき場面、構成の仕方、スコープとバージョン管理の仕組みを説明します。

メモリを書くべき場面

コードからは読み取れず、今後も話題に上りそうなナレッジがあるときは、メモリにしておきましょう。

• 決定事項。 「このリポジトリではすべてSupabase上のPostgresを使う。ORMは導入しない。supabase-jsクライアントを直接使うこと。」
• 落とし穴。 「orders.statusのenumを変更する場合は、スキーマのマイグレーションより先にデータのマイグレーションを実行すること。ほかのスキーマとは順序が逆になる。」
• ポストモーテム。 「2026-04-12に、Stripeのidempotency keyを確認していなかったため、顧客に二重請求するWebhookハンドラーをリリースしてしまった。現在は必ず渡すこと。」
• 規約。 「テストは、別の__tests__ディレクトリではなく、テスト対象のファイルの隣に置く。」
• 暗黙知。 「このフラグがなぜ存在するのかを覚えているのは一人だけ。上流のランタイムの癖があるため、今も必要。」

コードがすでに明確に示していること、毎週のように変わること、完全に個人の好みでしかないことは、メモリにする必要はありません。

構成

どのメモリにもタイトルとMarkdownの本文があります。どちらも短く保ちましょう。

• タイトル: 短く断定的で、サイドバーに収まるもの。「データベースアクセスのパターンに関するメモ」より「Postgresのみ。ORMは使わない。」のほうが優れています。
• 本文: 要点を伝えるのに必要最小限のMarkdown。段落よりも箇条書きのほうがたいてい明快です。役に立つなら例を1つ入れましょう。

決まったテンプレートはありませんが、次の形を基本にすると便利です。

The constraint or fact in one sentence.

Why:
- The reason this matters or the incident that prompted it.

How to apply:
- The concrete thing the assistant should do when the topic comes up.

パススコープ

パスはメモリの半分を占める重要な要素です。どこでメモリが提示されるかはパスで決まります。

• /apps/api/paymentsにあるメモリは、apps/api/payments配下のあらゆる作業で提示されます。
• /apps/apiにあるメモリは、apiディレクトリ全体で提示されます。
• /にあるメモリは、ワークスペースのあらゆる場所で提示されます。

対象にしたいケースをカバーできる範囲で、最も具体的なパスを選びましょう。決済に関するメモリをワークスペースレベルに置いてノイズにするより、決済フォルダに置くほうがずっと有用です。

バージョン管理と同時編集

保存のたびに、編集を始めた時点のバージョンと照合されます。その間に誰かが保存していた場合、相手の変更を上書きするのではなく、あなたの保存が拒否されます。これにより、2人のメンバー同士、あるいは人とエージェントが、気づかないうちに互いの変更を上書きしてしまう事態を防ぎます。

• Pathrule for VS Codeでは、メモリはMarkdownのタブとして開きます。チームメイトの新しい変更を上書きしてしまう保存をしようとすると、Reload、Copy My Version & Reload（先に自分のテキストをクリップボードにコピー）、Keep Mine (Overwrite) の選択肢が表示されます。
• MCP経由では、アシスタントは最後に読み込んだバージョンを渡せます。バージョンが一致しない場合は現在のバージョンとともに競合が返されるので、アシスタントは読み直してから、上書きせずにマージします。

削除も取り消せます。VS Codeでは削除の直後にUndoが表示されます。Pathrule Cloudのワークスペースでは、削除したメモリは完全に削除されるまでワークスペースのアーカイブに残り、オーナーまたは管理者がWebコンソールの設定(Workspace、Archive)から復元するか、完全に削除できます。メモリは通常小さく焦点が絞られているため、実際に競合が起きることはまれですが、このセーフティネットは常に有効です。

書き手

• 人は、Pathrule for VS Code（New Memory… またはSave Selection as Memory）やCLIで書きます。
• アシスタントは、何かを保存するよう頼まれたときにpathrule_write_memory MCPツールを通じて書きます。セットアップ時には、プロジェクト向けのメモリ、ルール、スキルを提案し、承認されたものだけを書き込みます。

ターミナルからなら、メモリの作成はコマンド1つです。--bodyを指定しない場合、CLIは本文を入力するためにエディタを開きます。--bodyで渡したり、テキストをパイプで渡したりすることもできます。メモリを読み返すにはpathrule memory listとpathrule memory read "Exact title" --printを使います。

pathrule memory add --path /apps/api/payments --title "Always pass the Stripe idempotency key"

どちらから書いても、保存先は同じです。人が書いたものをアシスタントが読み、アシスタントが書いたものを人が読みます。各レコードには作成者、最終編集者、作成元が記録され、VS CodeのInfoアクションで確認できるため、AIが書いたメモリも簡単に見分けられます。

メモリの品質をレビュー可能に保つ仕組み

Pathruleは、互いに独立した複数の仕組みによって、メモリを狭い範囲に絞り、確認しやすい状態に保ちます。

• 一般的なドキュメントは自動的に取り込まれるのではなく、セットアップ時に提案されます。実際に使われている指示ファイルとそのインポートチェーン、ツールのルール、意思決定記録のほうが、現役のナレッジであるという根拠が強いからです。
• エージェントは、継続的なナレッジを保存する前にまず提案するよう求められます。実際に保存されたものは、ほかのものと同様に作成者が記録され、バージョン管理され、ワークスペースで確認できるので、開いて編集したり削除したりできます。
• パススコープによってエントリが提示される範囲は限定され、現在のパスの外にあるエントリは、さらに関連度の下限を満たす必要があります。
• 計測された利用状況によって条件を満たすエントリの並び順が変わることはありますが、無関係なメモリがその下限を超えて引き上げられることはありません。
• メモリがコードと食い違っていることに気づいたエージェントは、それをリフレッシュタスクとしてフラグを立てられます。後でアシスタントがそのタスクを拾い、あなたの管理のもとで修正します。詳しくは提案とセルフ監査を参照してください。編集はバージョン管理され、削除は取り消せます。
• 同じパスにある既存のメモリとタイトルが一致する新しいメモリは、2つ目のコピーとして保存されるのではなく、デフォルトで拒否されます。これにより、同じ決定事項が二重に届けられたり、内容が少しずつ食い違っていったりすることを防ぎます。既存のエントリを確認したうえで、意図的にこれを無効にすることもできます(CLIでは--allow-duplicate)。

結果として、大量のアーカイブをワークスペースにコピーするのではなく、範囲を絞った、レビュー可能な少数の決定事項や落とし穴を扱う運用モデルになります。技術的な仕様の全体はPathruleが強い主張を裏付ける仕組みを参照してください。

読み込みと参照

最も関連度の高いメモリは本文全体が届けられ、アシスタントはそのまま活用できます。確度の低い候補はタイトルとIDだけが届き、アシスタントはそれに頼る前にpathrule_read_memoryで全文を読み込みます。こうすることで、確度の高い一致に余計な往復を発生させることなく、不確かな情報をデフォルトのペイロードから外しておけます。

VS Codeでは、Browse Knowledge Here… を使うと、あるパスでのAIセッションが受け取る内容を、親パスから引き継ぐものも含めて確認できます。

アンチパターン

• 「メモ全部」を詰め込んだ巨大なメモリ1つ。 トピックとスコープごとに分割しましょう。長くてグローバルなものより、小さくてパス単位のもののほうが常に優れています。
• コードがすでに示していることを書いたメモリ。 アシスタントはコードを読めます。メモリは「なぜ」と落とし穴のために取っておきましょう。
• 古くなったメモリ。 前提となる決定事項が変わったら、更新するか削除しましょう。アシスタントも食い違ったメモリをリフレッシュタスクとしてフラグを立てられますが、人の目で確認するほうが早く済みます。

ローカルとCloudでの作成

このページにあるターミナルでのaddの例は、Cloudワークスペース向けです。ローカルモードでは、Local Console、VS Code、またはローカルのMCPからエントリを作成・編集します。CLIのナレッジコマンドでは、エントリの一覧表示、読み込み、検索ができます。

次に読むもの

• 優先度付きの制約についてはルールの書き方。
• 再利用できる手順についてはスキルの書き方。
• これらが紐づくワークスペースツリーについては基本概念。