/ ディレクトリ / プレイグラウンド / Notion
● 公式 makenotion 🔑 自分のキーが必要

Notion

作者 makenotion · makenotion/notion-mcp-server

チームのナレッジベースへの読み書きアクセスをエージェントに付与します。仕様の検索、ページの下書き、データベースのCRUD操作をひとつのMCPで実現します。

Notion公式MCP。ページの読み取り、ブロックの作成、データベースのクエリ、プロパティの更新が可能です。Notionをエージェントが検索・要約・追記できるセカンドブレインに変えます。別途RAGパイプラインを構築せずに社内ドキュメントをAIから参照可能にする最もクリーンな方法です。

なぜ使うのか

主な機能

ライブデモ

実際の動作

notion.replay ▶ 準備完了
0/0

インストール

クライアントを選択

~/Library/Application Support/Claude/claude_desktop_config.json  · Windows: %APPDATA%\Claude\claude_desktop_config.json
{
  "mcpServers": {
    "notion": {
      "command": "npx",
      "args": [
        "-y",
        "@notionhq/notion-mcp-server"
      ]
    }
  }
}

Claude Desktop → Settings → Developer → Edit Config を開く。保存後、アプリを再起動。

~/.cursor/mcp.json · .cursor/mcp.json
{
  "mcpServers": {
    "notion": {
      "command": "npx",
      "args": [
        "-y",
        "@notionhq/notion-mcp-server"
      ]
    }
  }
}

Cursor は Claude Desktop と同じ mcpServers スキーマを使用。プロジェクト設定はグローバルより優先。

VS Code → Cline → MCP Servers → Edit
{
  "mcpServers": {
    "notion": {
      "command": "npx",
      "args": [
        "-y",
        "@notionhq/notion-mcp-server"
      ]
    }
  }
}

Cline サイドバーの MCP Servers アイコンをクリックし、"Edit Configuration" を選択。

~/.codeium/windsurf/mcp_config.json
{
  "mcpServers": {
    "notion": {
      "command": "npx",
      "args": [
        "-y",
        "@notionhq/notion-mcp-server"
      ]
    }
  }
}

Claude Desktop と同じ形式。Windsurf を再起動して反映。

~/.continue/config.json
{
  "mcpServers": [
    {
      "name": "notion",
      "command": "npx",
      "args": [
        "-y",
        "@notionhq/notion-mcp-server"
      ]
    }
  ]
}

Continue はマップではなくサーバーオブジェクトの配列を使用。

~/.config/zed/settings.json
{
  "context_servers": {
    "notion": {
      "command": {
        "path": "npx",
        "args": [
          "-y",
          "@notionhq/notion-mcp-server"
        ]
      }
    }
  }
}

context_servers に追加。保存時に Zed がホットリロード。

claude mcp add notion -- npx -y @notionhq/notion-mcp-server

ワンライナー。claude mcp list で確認、claude mcp remove で削除。

ユースケース

実用的な使い方: Notion

エージェントにPRDのギャップをレビューさせる

👤 PM、テックリード ⏱ ~15 min intermediate

使うタイミング: 仕様書のドラフトを作成し、エンジニアリングチームに共有する前に批判的なレビューを受けたいとき。

前提条件
  • Notionインターナルインテグレーショントークン — notion.so/my-integrations → 新しいインテグレーション → シークレットをコピー
  • インテグレーションに共有されたページ — 対象ページで: ••• → コネクション → インテグレーションを追加
フロー
  1. ページの内容を取得する
    Read the Notion page at <URL>. Summarize in 5 bullets what this spec is proposing.✓ コピーしました
    → 正確な1段落の要約 — エージェントが内容を理解した証拠
  2. 不十分な箇所を特定する
    List every place where the spec is vague: missing error cases, undefined edge behavior, unclear ownership, no rollout plan, no success metric.✓ コピーしました
    → ページ参照付きのギャップ一覧(番号付き)
  3. レビュー用の質問を作成する
    Convert those gaps into 5-10 specific questions a reviewing engineer would ask. Append them to the Notion page as a new 'Open Questions' section.✓ コピーしました
    → 質問ブロックがページに追加される

結果: より精緻な仕様書と、レビュー会議の前に適切な議論を促すOpen Questionsセクションが得られます。

注意点
  • エージェントが仕様書にない内容をでっち上げる — プロンプトで明示: 'only flag gaps; do not invent facts; cite the section where each gap occurs'
  • 長い仕様書はフェッチ時に途中で切れる — ブロック数が多いページはretrieve_block_childrenでページ単位に取得する。単一のget_page呼び出しに頼らないこと
組み合わせ: linear

Linear + GitHubから毎日のスタンドアップページを自動生成する

👤 エンジニアリングマネージャー、スクラムマスター ⏱ ~10 min intermediate

使うタイミング: Notionで毎日のスタンドアップページを運用しており、前日のアクティビティで事前に埋めておきたいとき。

前提条件
  • Notionの「Standups」データベース — プロパティ: Date (date)、Team (select)、Status (rich_text) が必要
フロー
  1. 前日のアクティビティを収集する
    From Linear, list issues moved to Done in the last 24h for ENG team. From GitHub, list merged PRs by our team.✓ コピーしました
    → 統合されたアクティビティ一覧
  2. スタンドアップのコンテンツを作成する
    Format as: Wins (shipped), In-flight (open PRs), Blockers (issues tagged 'blocked'), Today's focus (issues in-progress). Keep each section under 5 bullets.✓ コピーしました
    → フォーマット済みブロック一覧
  3. Notionページを作成する
    Create a new page in the Standups database. Date = today, Team = ENG, and paste the content as structured blocks (h2 per section).✓ コピーしました
    → ページURLが返される

結果: 朝9時の同期ミーティングに向けた事前入力済みスタンドアップページ。慌てて準備する15分を節約できます。

注意点
  • データベースのプロパティ名は大文字小文字が区別され、完全一致が必要 — 初回実行前にretrieve_databaseでプロパティ一覧を取得し、正確なキーをハードコードする
組み合わせ: linear · github

NotionドキュメントをベースにしたSlack対応Q&Aボットを構築する

👤 オペレーションリード、サポートマネージャー ⏱ ~20 min intermediate

使うタイミング: 新入社員が同じ質問を繰り返す。回答はすでにNotionに書かれているが、見つけられないとき。

前提条件
  • オンボーディングドキュメントが既知のNotionスペースにある — 親ページをインテグレーションに共有すれば、すべての子ページがアクセス権を継承します
フロー
  1. ワークスペースを検索する
    Search Notion for pages matching: '[user question]'. Return top 5 page titles and URLs.✓ コピーしました
    → ランク付けされた結果一覧
  2. 最も関連性の高いページを読む
    For the top 2 matches, fetch full content. Quote the passages that answer the question.✓ コピーしました
    → 原文の引用 + ソースURL
  3. 引用付きで回答する
    Answer the user's question in 2-3 sentences, grounded only in those quotes. End with: 'Source: <url>'. If the docs don't actually answer, say so.✓ コピーしました
    → 引用付きの回答、または正直に「ドキュメントにない」と回答

結果: ソースドキュメントへ自分でたどり着ける根拠ある回答が得られます。Slackでの「Xはどこ?」がなくなります。

注意点
  • エージェントがドキュメントにない内容をもっともらしく捏造する — 明示的に指示: 'if the retrieved quotes don't answer the question, reply with I don't see this in our docs — no guesses'
  • Notionの検索はキーワードベースのため、意味的なマッチを見逃す — 結果が不十分な場合、適切なRAGスタック(NotionのコンテンツをベクトルDBに埋め込む)と組み合わせる

会議メモをLinearのイシューに変換する

👤 テックリード、PM ⏱ ~10 min beginner

使うタイミング: Notionで会議のラフなメモを取った後、アクションアイテムを抽出する必要があるとき。

前提条件
  • Linear MCPがインストール済み — linearのガイドを参照
フロー
  1. 会議ページを読む
    Read the Notion page at <URL>. Extract every action item — anything phrased as 'X will do Y' or 'we should Z'.✓ コピーしました
    → 担当者が記載されている場合は担当者付きの一覧
  2. 作成前に確認する
    Show me the action list. For each, propose a Linear title, team, and priority. Do not create yet.✓ コピーしました
    → 人間がレビューするためのドライランテーブル
  3. 承認されたアイテムを作成する
    Create Linear issues for items 1, 3, and 5. Link each back to the Notion meeting page.✓ コピーしました
    → LinearのイシューURLが返される

結果: 会議のアクションが、誰も再訪しないNotionページに埋もれるのではなく、実際にトラッキングされるようになります。

注意点
  • エージェントがすべての情報項目をアクションとして扱ってしまう — プロンプトで指示: 'only items with a clear owner OR a deliverable — drop everything else'
組み合わせ: linear

Notionドキュメントの陳腐化を監査する

👤 ドキュメントリード、DevExエンジニア ⏱ ~20 min intermediate

使うタイミング: 四半期ごとのクリーンアップ — 6か月以上更新されておらず、内容が古くなっている可能性のあるドキュメントを見つけたいとき。

前提条件
  • ドキュメント領域のルートページ — 例: /Engineering/Docs — インテグレーションに共有済み
フロー
  1. 子ページをタイムスタンプ付きで一覧表示する
    List all descendant pages under the 'Engineering Docs' page. For each: title, URL, last_edited_time, last_edited_by.✓ コピーしました
    → 完全なインベントリ
  2. 古くなったページをフィルターする
    Filter to pages last edited more than 180 days ago. Group by top-level section.✓ コピーしました
    → セクションごとの古いページ一覧
  3. レビュー対象としてタグ付けする
    For each stale page, add a callout block at the top: '⚠ Needs review — last updated <date>. Ping <last-editor> to confirm.'✓ コピーしました
    → レビューバナーが追加されたページ

結果: ドキュメント領域の陳腐化が隠れずに可視化され、オーナーが更新または削除の対応を促されるようになります。

注意点
  • 意図的にアーカイブされたページ(ADR、ポストモーテムなど)にバナーを付けるべきではない — タグまたは親ページでフィルターし、/Archive配下や'historical'タグ付きのものを除外する

組み合わせ

他のMCPと組み合わせて10倍の力を

notion + linear

Notion PRDからLinearプロジェクトをスキャフォールドする

Read the Notion PRD at <URL>, extract deliverables, and create a matching Linear project with issues grouped by milestone.✓ コピーしました
notion + github

NotionデザインドキュメントとREADMEを同期する

Read the Notion page '<API Design>' and update the README.md in our api repo to match — open a PR with the diff.✓ コピーしました
notion + sentry

週次エンジニアリング品質レポートをNotionデータベースに投稿する

Pull this week's Sentry error stats per project and create a new page in the Notion 'Weekly Quality' database.✓ コピーしました

ツール

このMCPが提供する機能

ツール入力呼び出すタイミングコスト
search query, filter?: {property, value} ディスカバリー — ワークスペース全体からキーワードでページを検索 1 API call
retrieve_page page_id ページのメタデータ/プロパティを取得 — コンテンツブロックは含まない 1 API call
retrieve_block_children block_id, start_cursor? 実際のページコンテンツを読み取る — next_cursorがなくなるまで繰り返し呼び出す 1 API call (ページネーションが必要な場合あり)
append_block_children block_id, children: Block[] ページまたは特定のブロック配下にコンテンツを追加 1 API call
update_block block_id, {type}: {...} 既存ブロックのテキスト/コンテンツをその場で編集 1 API call
create_page parent: {database_id}|{page_id}, properties, children? 新しいページを作成 — 親ページの配下またはデータベース内 1 API call
query_database database_id, filter?, sorts? 構造化クエリ — データベース内のエントリをフィルター/ソート 1 API call
update_page page_id, properties ページレベルのプロパティ(ステータス、タグ、日付)を更新 1 API call
retrieve_database database_id 書き込み前にプロパティ名/型を確認する 1 API call

コストと制限

運用コスト

APIクォータ
Notion: インテグレーションあたり平均3リクエスト/秒、バーストは許容。大規模利用時は積極的に429を返します。
呼び出しあたりのトークン
ブロック数に応じてページあたり500〜3000トークン
金額
無料 — APIはすべてのNotionプランに含まれます
ヒント
ネストされたブロックが多いページは全読み込みのコストが高くなります。まず検索し、対象ページのみを取得してください。

セキュリティ

権限、シークレット、影響範囲

最小スコープ: read_content
認証情報の保管: インターナルインテグレーションシークレットを環境変数NOTION_API_KEYに格納
データ送信先: すべての通信先は api.notion.com
絶対に付与しない: update_content insert_content

トラブルシューティング

よくあるエラーと対処法

object_not_found

ページは存在するがインテグレーションに共有されていません。ページを開き → ••• → コネクション → インテグレーションを追加してください。

validation_error on create_page

ペイロード内のプロパティ名/型がデータベーススキーマと一致していません。先にretrieve_databaseを呼び出し、正確なキーをコピーしてください。

429 rate limited

Notionのレート制限は約3リクエスト/秒です。書き込み間に350msのスリープを入れるか、append_block_childrenでバッチ処理(100回の呼び出しではなく1回の呼び出しで100ブロックを送信)してください。

Page content looks empty

retrieve_pageはメタデータのみを返します。コンテンツはブロックに含まれます。実際のテキストを取得するにはretrieve_block_childrenを呼び出してください。

代替案

Notion 他との比較

代替案代わりに使う場面トレードオフ
Confluence MCP組織がNotionではなくConfluence/Atlassianを使用している場合権限モデルがより複雑で、エージェントのワークフローは遅くなる傾向があります
Obsidian / filesystem MCPナレッジベースがローカルのMarkdownファイルの場合マルチユーザー同期や権限管理はないが、APIコストゼロで即座に読み取り可能

その他

リソース

📖 GitHub の公式 README を読む

🐙 オープンな issue を見る

🔍 400以上のMCPサーバーとSkillsを見る