Claude Code × Notion MCP連携完全ガイド — コネクタ版とローカル版の使い分け、CLAUDE.mdでの権限設計まで【2026年版】
Claude CodeとNotionをMCPで連携する2つの方法(公式コネクタ/ローカルIntegration)を実際に設定して比較。CLAUDE.mdでの操作ルール設計、複数クライアントのワークスペースを混同しない運用、詰まりやすいポイントまで解説する。
エンジニアのゆとです。
複数のクライアント案件を掛け持ちしていると、議事録・タスク・仕様メモがそれぞれ別のNotionワークスペースに散らばっていく。この記事では、Claude CodeとNotionをMCPで繋いで「議事録を投げるだけでタスクDBに反映される」状態を作るところまでの手順と、実際に運用してみて気づいた注意点をまとめる。
Notion公式のMCP連携方法は「公式コネクタ（OAuth・ワークスペース全体接続）」と「ローカルIntegration（Notion API・ページ単位の権限）」の2種類ある。既存の解説記事はどちらか片方の手順を説明するものが多く、「どっちを選ぶべきか」「フリーランスが複数クライアントのワークスペースを混同しないための設計」「CLAUDE.mdでNotion操作のルールを縛る方法」までセットで書いた記事は見当たらなかった。自分が実際に両方設定して使ってみた上での結論を書いていく。
結論 — まずこの表で選ぶ
先に結論から。個人開発・自分専用の用途なら公式コネクタ、複数クライアントを掛け持ちするフリーランスや「このDBだけ触らせたい」場合はローカルIntegrationを選ぶ。
| 観点 | 公式コネクタ（Remote） | ローカルIntegration |
|---|---|---|
| セットアップ | claude mcp add一発+ブラウザOAuth | Integration作成+Node.js環境+ページ権限付与 |
| 権限の粒度 | ワークスペース全体（オールオアナッシング） | ページ/DB単位で個別に権限付与できる |
| 認証方式 | OAuth（対話的な認可が必須） | Internal Integration Secret（トークン） |
| 向いている人 | 個人のワークスペースを丸ごと使いたい人 | 複数クライアントを分離したいフリーランス・法人利用 |
| 詰まりやすさ | 低い（コマンド1つ） | 中（Node.js・環境変数・権限付与を手動で行う） |
自分は当初コネクタ版だけで済ませようとしたが、複数クライアントのワークスペースを1つのClaude Codeセッションから触れる状態は事故のもとだと気づいて、案件ごとにローカルIntegrationへ切り替えた。理由は後述の「セキュリティと運用の注意点」で書く。
なぜNotionをClaude Codeの知識ベースにするのか
以前、ObsidianとClaude Codeを連携させる記事を書いた。ローカルのMarkdownファイルにダイレクトアクセスできるObsidianは、セットアップの手軽さでNotionに勝る。それでも自分が案件によってNotionを選ぶのには理由がある。
一番の理由はシンプルで、クライアントが既にNotionで案件管理をしているケースが圧倒的に多いからだ。自分専用のナレッジベースを作るならObsidianの方が快適だが、「クライアントの議事録DB」「タスクDB」「仕様書ページ」が最初からNotion上にある以上、そこにClaude Codeを繋いだ方が二重管理にならない。
もう一つは、Notionがデータベース（プロパティ・ビュー・リレーション）を持っている点だ。Obsidianのファイルシステムと違い、Notionは「ステータス」「担当者」「期限」といった構造化プロパティを持てる。議事録から抽出したタスクを「ステータス: 未着手」「担当者: ゆと」という形でそのままタスクDBに流し込めるのは、Notionならではの強みになる。
方法1: 公式コネクタで接続する（最短ルート）
一番手早いのはAnthropic公式のNotionコネクタを使う方法だ。ターミナルで以下を実行する。
claude mcp add --transport http notion https://mcp.notion.com/mcp実行後、Claude Code内で /mcp コマンドを打つとブラウザが開き、Notionのログイン画面に飛ぶ。ワークスペースを選んで認可すれば接続完了だ。現時点でNotion MCPはOAuthの対話的な認可が必須で、CI/CDのような非対話環境から自動認可する仕組みはまだない。
スコープの使い分け
claude mcp addには--scopeオプションがあり、接続範囲を制御できる。
| スコープ | 範囲 | 向いている場面 |
|---|---|---|
local（デフォルト） | 今のプロジェクトのみ | 案件Aのリポジトリ内だけでNotion接続を使いたい |
project | .mcp.jsonでチームと共有 | チームメンバー全員に同じNotion接続を配りたい |
user | すべてのプロジェクトで有効 | 自分専用ワークスペースを常時繋いでおきたい |
自分は複数クライアントを掛け持ちしているので、userスコープは使わない。案件ごとのリポジトリ直下でlocalスコープの接続を張り、案件Aのセッションでは案件AのNotionしか見えない状態を保つようにしている。
# 案件Aのリポジトリ直下で実行（このプロジェクトだけに紐づく）
cd ~/projects/client-a
claude mcp add --transport http notion https://mcp.notion.com/mcp --scope local接続後、どれくらいコンテキストを消費しているかは/contextコマンドで確認できる。MCPサーバーごとの使用トークン数が表示されるので、Notion MCPのツール定義がどれだけコンテキストを圧迫しているか把握しておくといい。
方法2: ローカルIntegrationで接続する（権限を絞りたい場合）
コネクタ版はワークスペース全体に接続されるため、機密性の高いDB（契約書・請求情報など）が同じワークスペースにあると、それも見える状態になる。ページ単位で権限を絞りたい場合は、Notion APIベースのローカルIntegrationを使う。
事前準備
Node.js v18以上が必要。入っていない場合は先にインストールしておく。
node -vIntegrationの作成とトークン取得
Notionの「Integrations」管理画面で新規Integrationを作成し、「Internal Integration Secret」を発行する。このトークンは他人に見せてはいけない機密情報だ。
接続先ページへの権限付与
Integrationを作っただけではどのページにもアクセスできない。Notion側で「このページ・DBだけIntegrationに公開する」設定を個別に行う必要がある。対象のページを開き、右上の「•••」メニューから「コネクト」→ 作成したIntegration名を選んで許可する。
ここが公式コネクタとの決定的な違いで、「議事録DBだけ見せる」「契約情報のDBは見せない」という制御がページ単位でできる。
MCPサーバーとして登録する
claude mcp addでコマンド起動型のMCPサーバーとして登録する。
claude mcp add notion-local -- npx -y @notionhq/notion-mcp-server \
--env OPENAPI_MCP_HEADERS='{"Authorization": "Bearer ntn_xxxxxxxxxxxx", "Notion-Version": "2022-06-28"}'.mcp.jsonに直接書く場合はこうなる。
{
"mcpServers": {
"notion-local": {
"command": "npx",
"args": ["-y", "@notionhq/notion-mcp-server"],
"env": {
"OPENAPI_MCP_HEADERS": "{\"Authorization\": \"Bearer ntn_xxxxxxxxxxxx\", \"Notion-Version\": \"2022-06-28\"}"
}
}
}
}トークンをリポジトリの.mcp.jsonに直書きしてGitにコミットしてしまう事故は実際によく見る。この設定ファイル自体は.gitignoreに入れるか、環境変数を別ファイルから読み込む構成にしておいた方がいい。シークレットの扱い方は以前まとめた記事の方が詳しいので、そちらを参照してほしい。
再起動後、claude mcp listでnotion-localが接続済みになっていれば設定完了だ。
CLAUDE.mdでNotion操作のルールを設計する（差別化の核心）
ここまでは接続手順で、既存の解説記事にも書かれている内容だ。ここから先の「Claude Codeに何をしていいか・何をしてはいけないかを覚えさせる」部分が、既存記事のほとんどが触れていないポイントになる。
DBのプロパティ構造をCLAUDE.mdに書いておく
Notion MCPはDBのプロパティを都度探索することもできるが、毎回それをやるとコンテキストとAPI呼び出しの無駄が発生する。案件のリポジトリ直下に置くCLAUDE.mdに、よく使うDBの構造を先に書いておくと動きが安定する。
# CLAUDE.md — 案件A Notion運用ルール
## よく使うDB
- タスクDB（データベースID: xxxxxxxx）
- プロパティ: 名前(title) / ステータス(select: 未着手・進行中・完了) / 担当者(person) / 期限(date)
- ステータスの初期値は必ず「未着手」にする
- 議事録DB（データベースID: yyyyyyyy）
- プロパティ: タイトル(title) / 日付(date) / 参加者(multi_select) / タグ(multi_select)
## 命名規則
- 議事録ページのタイトルは「YYYY-MM-DD_会議名」形式
- タスクのタイトルは体言止め（「〜する」で終わらせない）書き込み前に確認させるルール
Notion MCPのcreate-pagesやupdate-page系のツールは、一度実行すると即座にワークスペースに反映される。誤操作を防ぐため、破壊的な操作の前には必ず確認を挟むルールをCLAUDE.mdに書いておく。
## やってはいけないこと
- 既存ページの内容を全削除して書き直す操作は、必ず事前に確認を取ってから実行する
- タスクDBの既存レコードのステータスを「完了」に一括変更するような操作は行わない
- 議事録DB以外のDBへの書き込みは、明示的に指示されない限り行わない
## 推奨行動
- 新しいタスクを作る前に、同じタイトルのページが既に無いか検索で確認する
- 議事録から抽出したタスクには、必ず元の議事録ページへのリンクをプロパティに残すObsidian連携の記事でも書いたが、CLAUDE.mdは「禁止」だけでなく「代替行動の提案」まで書ける。Notionのような書き込み即反映のツールと組み合わせるときは、この事前確認ルールの有無で事故率がかなり変わる。
実践ワークフロー3選
ワークフロー①: 議事録からタスクDBへの自動登録
Zoomやteams等で録画した会議の文字起こしを渡し、議事録DBへの新規ページ作成とタスクDBへのタスク登録を一度に行う。
> この議事録テキストを読んで、議事録DBに新規ページとして保存して（日付は今日）。
> その中で「誰かがやると決まったこと」をタスクDBに個別のタスクとして登録して。
> 担当者・期限が議事録内で明言されていればプロパティに反映して、不明な場合は空欄のままにして「不明な場合は空欄のままにして」という一文が地味に効く。これがないと、Claude Codeが担当者を推測で埋めてしまい、後から見返したときに「これ誰が言ったんだっけ」という混乱が起きる。
ワークフロー②: リポジトリの技術ドキュメントをNotionのWikiページに同期
コードベースのREADMEやアーキテクチャメモを、クライアントが見るNotionのWikiページに転記する作業を自動化する。
> ~/projects/client-a/README.md と ~/projects/client-a/docs/architecture.md を読んで、
> Notionの「開発者向けWiki」ページの内容を更新して。
> 章立てはREADMEの見出し構造をそのまま使い、
> コードの実態とWikiの記述が食い違っている箇所があれば一覧にして教えてコードとドキュメントの乖離をClaude Codeが検出してくれるのが便利で、「Wikiに書いてあるセットアップ手順が古い」というよくある問題を機械的に洗い出せる。
ワークフロー③: 週報の下書き生成
タスクDBの今週分の完了タスクを集計し、週報の下書きを作る。
> タスクDBから今週ステータスが「完了」になったタスクを全部取得して、
> クライアント向け週報のフォーマットで下書きを書いて。
> 議事録DBの中から今週の会議も拾って「今週の主な議論」セクションに入れてDBのフィルタ・集計をMCP経由で行える点はObsidianにはない強みで、「今週やったこと」の棚卸しがワンコマンドで済む。
セキュリティと運用の注意点
コネクタ版の「ワークスペース全体接続」が持つリスク
公式コネクタで接続すると、Claude Codeはそのワークスペース内のすべてのページ・DBに（読み取り可能な範囲で）アクセスできる状態になる。個人ワークスペースなら問題になりにくいが、クライアントのワークスペースに契約書・請求情報・他クライアントの案件メモが同居している場合は話が変わる。
自分は一度、案件Aのコネクタをuserスコープで繋いだまま案件Bの作業をしていて、Claude Codeが「関連しそうな情報」として案件Aのページを参照しようとしたことがあった。実害はなかったが、ヒヤリとした。それ以来、コネクタ版は個人の検証用ワークスペースだけに使い、クライアント案件は必ずローカルIntegrationでページ単位に絞るようにしている。
複数クライアントのワークスペースを混同しない設計
フリーランスで複数案件を並行していると、この「混同しない設計」が最も現実的なリスク対策になる。自分がやっているのは次の3つだ。
- MCP接続は必ず
--scope localで、案件のリポジトリ直下に紐づける（userスコープでグローバルに繋がない） - 案件ごとにIntegrationを分けて発行する（1つのIntegrationを使い回さない）
- CLAUDE.mdの冒頭に「このセッションで触っていいNotionワークスペースは案件Aのみ」と明記する
3つ目は地味だが効果がある。Claude Codeはセッション開始時にCLAUDE.mdを読むため、「今このセッションで触っていい範囲」を言語化しておくと、複数MCP接続がある状態でも誤った参照が減る。
トークンの取り扱い
Internal Integration Secretは漏洩するとワークスペースの許可範囲すべてに書き込みできてしまう機密情報だ。.mcp.jsonや設定ファイルへの平文保存は避け、環境変数やシークレット管理ツール経由で読み込む構成にしておく。この辺りの具体的な運用は以前まとめた記事にまとめてある。
よくある詰まりポイント
OAuth認証が何度やっても通らない
コネクタ版の認証が失敗し続ける場合、一度Notion側の「接続済みアプリ」設定から既存の接続を解除し、claude mcp remove notionで登録を消してから再接続すると直ることが多い。ブラウザのCookie状態が古いままだと認証フローがループすることがある。
同名タイトルのページを誤認識する
Notion MCPはページタイトルで検索・特定することが多いため、「議事録」のような汎用的なタイトルのページが複数あると、意図しないページを更新してしまうことがある。ページタイトルに日付やプロジェクト名を含める命名規則をCLAUDE.mdに書いておくと、この誤認識をかなり防げる（前述の「命名規則」セクション参照）。
ツールが多すぎてコンテキストを圧迫する
Notion MCPは検索・ページ取得・DB操作など複数のツールを一括で提供する。他のMCPサーバー（GitHub、Playwright等）と同時接続していると、ツール定義だけでコンテキストの一部を消費する。/contextで現在の消費内訳を確認し、常用しない案件のNotion接続はセッションの合間にclaude mcp removeで外しておくと軽くなる。
書き込みはできるのに反映が遅れて見える
Notion側のキャッシュ・同期の関係で、Claude Codeが書き込み完了を返してきてもNotionアプリ側の表示更新に数秒のラグが出ることがある。ブラウザやアプリを一度リロードすれば反映されているケースがほとんどで、MCP側のエラーではないことが多い。
Notion vs Obsidian、結局どっちを使うべきか
Obsidian連携の記事でも書いたが、自分は今も個人のナレッジベースにはObsidianを使い続けている。ローカルファイルシステムに直接アクセスできる手軽さは、Notion MCPのAPI経由アクセスより明らかに軽い。
一方でクライアントワークがNotion上で完結している以上、そこにClaude Codeを繋ぐ選択肢は無視できない。「個人の思考の壁打ちはObsidian、クライアントに見せる成果物とチーム共有情報はNotion」という役割分担が、自分にとっては一番しっくりきている。
どちらか一方に統一しようとせず、案件の性質で使い分ける方が現実的だ、というのが半年ほど両方運用してみた上での結論になる。
まとめ
Notion MCPには「公式コネクタ（ワークスペース全体・OAuth）」と「ローカルIntegration（ページ単位・APIトークン）」の2つの接続方法があり、個人利用ならコネクタ、複数クライアントを扱うフリーランスや機密情報のあるワークスペースではローカルIntegrationが向いている。
接続方法そのものより重要なのが、CLAUDE.mdでの操作ルール設計だ。DBのプロパティ構造・命名規則・書き込み前の確認ルールを明記しておくことで、書き込み即反映というNotionの特性による誤操作リスクを大きく下げられる。
複数案件を並行するフリーランスは、--scope localでの接続とIntegrationの分割発行を徹底するだけで、ワークスペースの混同という一番現実的なリスクをほぼ潰せる。設定の手間は増えるが、案件間の情報を混ぜないという一点において、この手間は惜しまない方がいい。
関連記事
