Cursor で同じ説明を何度も書いていませんか。「このプロジェクトは pnpm です」「テストは Vitest です」「API は tRPC で書いてください」――毎回入れているなら、Memories の出番です。
私は 3 週間ほど Cursor Memories を本気で運用してみました。最初は半信半疑でしたが、結論から言うと “プロジェクトの口グセ” を AI に覚えさせるための機能 として、想像以上に効きました。.mdc ルールとは別レイヤーで効くのが面白いところです。
この記事では、Memories の有効化から、覚えさせるべき内容・覚えさせてはいけない内容の線引き、3.7 で追加された削除 UI の使い方まで、実運用ベースで整理します。
結論:Memoriesは”会話から自動で蓄積される第二のルール”
まず結論を先に出します。Cursor Memories は、会話の中で出てきたプロジェクト固有の事実を Cursor 側が自動で抽出・保存し、次回以降の対話で自動的に参照する仕組みです。
これは .cursor/rules/*.mdc に手で書く「明示的なルール」とは別物です。私の使い分けはこうです。
- .mdc ルール: チーム全員に強制したい規約。Git にコミットして共有するもの
- Memories: 自分が個別に説明してきた小ネタの蓄積。ローカル寄りで、AI が勝手に拾うもの
つまり Memories は、あなたが過去に Cursor に話した内容から作られる、プロジェクト固有の永続知識ベース。プロジェクトの仕様や規約をプロンプトで毎回繰り返さなくて済むようになる、という設計思想です。
なぜ.mdcルールだけでは足りないのか
正直、最初は「.cursor/rules があるならいらないのでは」と思いました。が、運用してみると違いました。
.mdc ルールは「最初から書ける既知の規約」には強いです。でも開発が進むと、こういう小ネタが大量に生まれます。
- 「この API のレスポンスは snake_case で返ってくる(なぜか)」
- 「
legacy_userテーブルは触らない、users_v2を使う」 - 「Storybook の story ファイルは
*.stories.tsx末尾に置く決まり」
全部 .mdc に書いてもいいのですが、規模が膨らむとルールが肥大化して、AI 提案の採用率がむしろ下がる。Memories はこの現場で発生した暗黙知を引き取ってくれる場所だと考えると、役割分担がクリアになります。
Memoriesを有効化する3ステップ
手順自体は拍子抜けするほど簡単です。
1. Settings から Memories を ON にする
Cursor の Settings → Features → Memories のトグルをオンにします。プロジェクトごとに保存されるので、いま開いているワークスペースに紐づきます。
2. 重要事実を会話で”宣言”する
最初のセットアップとして、Composer や Chat で次のように一文ずつ宣言します。
このプロジェクトでは pnpm を使います。npm/yarn コマンドは出さないでください。
テストフレームワークは Vitest です。jest 構文は使わないでください。
DB は Prisma + PostgreSQL です。生 SQL は基本書きません。コツは 1 メッセージ 1 事実にすること。詰め込むと取り違えが起きやすいです。私は最初に 7〜8 個まとめて投げて失敗しました。
3. しばらく普通に使う
ここからは普通に開発するだけ。Cursor が会話の流れから「あ、これは覚えておくべき事実だ」と判断したものを自動で蓄積していきます。
2 週間使ったあとに中身を確認したら、私のプロジェクトでは 23 件の Memories が貯まっていました。半分は自分が宣言したもの、もう半分は会話の中で AI が勝手に拾ったものでした。
3.7で追加された削除UIの使い方
ここが地味に大事です。2026 年 6 月 17 日の 3.7 アップデートで、UI から Memories を削除できるようになりました。自動化スクリプトから古い Memory を削除指示することもできます。
以前は「いらない Memory が混ざっても消しづらい」のが弱点でした。たとえば設計を変えた直後に古い記述が残っていると、AI が古い前提でコードを書いてくる。これがけっこう厄介でした。
運用フローはこうしています。
- 大きな設計変更(DB スキーマ変更、ライブラリ移行など)をしたら、その日のうちに Memories を見直す
- 古い前提を語っているものを削除
- 新しい前提を 1 文宣言する
コードベースが変わったら Memories も一緒にメンテする。Memories は Git 管理外の “頭の中” だと割り切るのが、私が落ち着いた運用です。
覚えさせるべきこと・覚えさせてはいけないこと
3 週間運用してわかった線引きを共有します。
Memoriesに向いている内容
- パッケージマネージャや言語バージョン(pnpm / Node 22 など)
- テスト・Lint ツールの種類と起動コマンド
- ファイル配置の暗黙慣習(コンポーネントは
src/features/*/uiに置く、など) - 「触ってはいけない」レガシー領域の名前
- 命名規則(英語 or ローマ字、camelCase or snake_case)
どれも、いちいち .mdc に書くほどではないが、毎回説明するのが面倒なやつ。Memories の本領はここです。
Memoriesに向かない内容
- セキュリティ要件・コンプライアンス事項 → 必ず .mdc + コードレビューで担保
- API キーや本番接続情報 → 論外。絶対に書かない
- チーム共通の規約 → .mdc に書いて Git で共有する
- 単発の指示(「今日だけ TypeScript の strict を緩めて」) → 会話の中で完結させる
特に “今だけ” の指示が Memory に紛れ込むと事故るので、削除 UI を使って定期的に掃除する習慣をおすすめします。
.mdcルール・MCP・Memoriesの三層運用
ここまで来ると、Cursor の知識基盤は三層で考えるとすっきりします。
| レイヤー | 役割 | 共有範囲 |
|---|---|---|
| .cursor/rules/*.mdc | 明示ルール・コーディング規約 | Git でチーム共有 |
| Memories | 会話から蓄積される暗黙知 | ローカル(個人) |
| MCP サーバー | 外部知識・ツール接続 | チームで共通設定可 |
私の場合、新しいプロジェクトに入ったらまず .mdc を書き、MCP で GitHub と Context7 を繋ぎ、そこから先は Memories に任せる、という順番にしています。ルールはコードのように扱い、Memories はメモのように扱う。これが今のところ一番うまく回ります。
落とし穴:Memoriesが効きすぎて事故った話
一つだけ失敗談を。あるリポジトリで「このプロジェクトは Tailwind CSS v3 を使っています」と Memory に入れたまま、Tailwind v4 に移行しました。
Memory の更新を忘れていたので、Cursor は v3 構文(@apply の古い書き方)を提案し続け、私もしばらく気づきませんでした。気づいたのは CI が落ちてからです。
教訓は単純で、「メジャーアップグレード時の Memories チェック」をリリースチェックリストに入れておくこと。これは .mdc にもコメントとして残しておくと、自分の未来の手間が減ります。
まとめ:今日からやる3つのアクション
Cursor Memories は地味ですが、毎日のプロンプト摩擦をなくす効き目があります。今日からやれることを 3 つに絞ります。
- Settings から Memories を ON にする。今日 3 分で終わります
- プロジェクトの口グセを 5 つだけ宣言する。pnpm / テスト / DB / 命名 / 触らないディレクトリ、で十分スタートできます
- 設計を変えた日に Memories を見直すルールを作る。3.7 の削除 UI を使えば 1 分で掃除できます
.mdc ルールも MCP も MCP もそれぞれ強力ですが、Memories は”自分が AI に何度も説明していた小ネタ”を引き取ってくれる、わりと癖になるレイヤーです。明日のあなたが楽になる投資として、今日 5 分だけ触ってみてください。
参考リンク
- Cursor Changelog — 3.7 で Memories 削除 UI と /in-cloud を追加
- Cursor 3 公式発表(Meet the new Cursor) — Agents Window 中心の新インターフェース
- Releasebot: Cursor Release Notes June 2026 — Customize ページや Auto-review のまとめ