はじめに
Notion に溜まった仕様書や議事録を、コーディング中にサッと参照したい——そんなとき、Cursor と Notion 公式 MCP を組み合わせるだけで、Embedding も Vector DB も不要で「RAG っぽい」環境が作れます。
Notion の検索結果をそのまま AI のコンテキストに載せて回答してもらえます。この記事では、向く人とセットアップの流れを書きます。
向く人
向く人（自分みたいなケース）:
- Notion に設計書・議事録・FAQ が溜まっていて、コーディング中に参照したい
- 意味検索で数千ページを横断する必要はなく、キーワード・タイトルでピンポイントに引ければ十分
- Embedding や Vector DB の構築・運用を増やしたくない
- Cursor（または MCP 対応の AI エディタ）を普段から使っている
この条件なら、Cursor + Notion MCP、必要ならワークスペースに関連リポジトリを追加するだけで十分です。わざわざ重い RAG 基盤を組む必要はありません。
なぜ「手軽な RAG っぽい」で足りるか
一般的な RAG は Embedding + Vector DB で「意味的に近い文書」を検索します。一方、社内 Notion が設計書・FAQ・議事録で数十〜百ページ程度なら、キーワードやタイトルで十分ピンポイントに引けることが多いです。自前で Embedding パイプラインや Vector DB を用意するコストをかけたくないなら、Notion MCP の意味検索（notion-search）+ MCP で Cursor に渡すだけで、「Retrieve → Augment → Generate」の流れは成立します。いわば軽量 RAG です。
できること: 仕様のピンポイント参照、設計方針・意思決定ログの参照、FAQ の参照。
割り切り: 類似度検索は Notion の検索品質に依存します。数百ページ横断の高精度な意味検索が必要なら、本格RAG（Embedding + Vector DB）を検討してください。
構成の全体像
┌─────────────────────────────────────────────────────────┐
│ Cursor（Composer / Agent） │
│ ┌─────────────┐ ┌──────────────┐ ┌─────────────────┐ │
│ │ Notion MCP │ │ ワークスペース │ │ ローカル要約 │ │
│ │ 検索・取得 │ │ 関連リポジトリ │ │ docs/*.md │ │
│ └──────┬──────┘ └──────┬───────┘ └────────┬────────┘ │
│ │ │ │ │
│ └─────────────────┴────────────────────┘ │
│ │ │
│ コンテキストに載せて回答 │
└─────────────────────────────────────────────────────────┘
│
▼
Notion ワークスペース（仕様・議事録・FAQ）
- Notion MCP: 公式リモート MCP（
https://mcp.notion.com/mcp）です。OAuth のみ。notion-search（意味検索）でワークスペースを検索、notion-fetch（URL/ID 指定）でページ取得できます。 - ワークスペース: 関連リポジトリをマルチルートで開きます。Cursor がコードをインデックスし、Notion の記述と実装の両方を参照できます。
- ローカル要約: システム構成やリポジトリ役割を
docs/に Markdown でまとめておきます。Notion が重い・検索がヒットしないときの補助になります。
セットアップ
1. Notion MCP を Cursor に追加
プロジェクトで使う場合は .cursor/mcp.json を用意します。
{
"mcpServers": {
"notion": {
"url": "https://mcp.notion.com/mcp"
}
}
}
Cursor を再起動し、Composer で初めて Notion のツールを使うときに OAuth 認証を行います。
2. ワークスペースに関連リポジトリを追加
File → Add Folder to Workspace... で参照したいリポジトリを追加します。
{
"folders": [
{ "path": ".", "name": "notion-rag-project" },
{ "path": "../your-product-delivery", "name": "delivery" },
{ "path": "../your-product-backend", "name": "backend" }
]
}
既存リポジトリを「追加で開く」だけです。コピーは不要です。
3. ローカルに要約ドキュメントを置く（任意）
Notion のシステム構成図やリポジトリ一覧を、プロジェクト内に Markdown で要約しておきます。例: docs/プロダクト概要.md / docs/システム構成図.md / docs/リポジトリと役割.md。Notion が落ちている・検索がうまくいかないときでも全体像をコンテキストに載せられます。オンボーディング資料にもなります。
4. ルールで参照の優先順位を書く（任意）
.cursorrules に短く書いておくと、Agent が Notion（仕様の正）→ docs（全体像）→ コード（実装確認）の順で参照しやすくなります。
# プロダクトに関する質問では
# 1) Notion MCP で検索 2) docs/ の要約 3) ワークスペースのコード を組み合わせて回答する
運用のコツ
- Notion MCP のツールは Composer（Agent）でのみ利用可能です。通常チャットでは使えません。
- プロンプトで「何を参照するか」を書くとよいです。「Notion で『○○』を検索して」「docs のシステム構成と、delivery の RegisterProduct の実装も見て」のように書くと、Retrieve の範囲がはっきりします。
- 仕様書は古く、コードが先に変わっていることがあります。「Notion + ワークスペースのコード」の両方を見る指示をすると正確な回答が得られやすくなります。
- 検索がヒットしにくいときは、Notion のページタイトルや見出しを具体的に含めるとよいです（例:「ディスパッチャータグ 設置場所」）。必要なら
docs/に用語一覧やリンクをまとめておきます。
まとめ
Cursor + Notion MCP だけで、Embedding も Vector DB も不要で RAG っぽい環境が作れます。「Notion をコーディング中に検索してコンテキストに載せたい」だけならこの構成で十分です。ワークスペースで関連リポジトリを開き、docs/ に要約を置いておくと、Notion と実装の両方を踏まえた回答がしやすくなります。