目錄
あるユーザーは毎日複数のNotion Workspacesを行き来して仕事をしていますが、現在のClaudeでは一度にそのうち1つしか接続できません。Claudeに別のWorkspaceを見てもらいたい場合、そのたびに現在のNotion Connectorを削除し、別のWorkspaceを改めて認証する必要があります。投稿で聞かれていたのは非常に単純です。Claudeから複数のNotion Workspacesを同時に見られる方法はないのか、ということです。
これは個別の操作ミスではありません。AnthropicのClaude Code GitHubでは、2026年4月の時点ですでにまったく同じFeature Requestが提出されています。現在は1つのClaude Accountにつき、MCP経由で接続できるNotion Workspaceが1つだけであり、切り替えるにはSettings → Connectorsから手動でDisconnectして再認証する必要があり、その切り替えが既存Sessionsにも影響すると説明されています。このIssueは問題が解決したためCloseされたのではなく、より広い「同一Connectorで複数アカウント／複数接続を扱いたい」というFeature RequestのDuplicateとして整理されました。後者は現在もOpenのままです。
ただし、ここでは制限がどこにあるのかを正確に分ける必要があります。MCP仕様が「1サービスにつき1接続しかできない」と定めているわけではなく、OAuth自体が1つのWorkspaceしか認証できないわけでもありません。Notion公式のMCPドキュメントが説明しているのは、OAuthを完了すると、AI Clientが「認証時に選択したNotion Workspace」の中で、そのユーザーがもともとアクセス権限を持っているコンテンツを読み書きできるという仕組みです。実際に不足しているのはClaude側の現在のConnector UIで、同じNotion Connectorに複数のWorkspace認証を保存し、SessionやProjectごとに切り替える機能がまだありません。
つまり、この話で本当に注目するべきなのは「なぜNotionが複数Workspaceを制限しているのか」ではなく、AI Connectorのアカウント・権限管理が実際の働き方にまだ追いついていないことです。個人プロジェクト、社内Workspace、複数クライアントのデータを分けて管理するのは珍しくありませんが、現在のAIツールでは同じConnectorに1つの接続Slotしか与えられないことがあります。以下では、この制限が実際にどこで発生しているのか、そして現時点で現実的な対処方法を整理します。（本記事の情報は2026年8月19日時点のものです。）
Claudeはなぜ一度に1つのNotion Workspaceしか接続できない？
Notion MCPの認証では、まず1つのWorkspaceを選択する
Notion公式のMCP接続フローは明確です。AI ClientがNotion MCPへ接続するとOAuth認証が必要になり、認証完了後、そのClientは「selected Notion workspace」の中で、そのユーザーがもともとアクセスできる内容を読み書きできます。MCPが既存のNotion Permissionsを回避することはなく、ユーザー自身が閲覧できないPageを、AIだけがMCP経由で突然読めるようになることもありません。
セキュリティ設計として考えると、これは合理的です。同じNotion Accountが個人Workspace、会社Workspace、3つのクライアントWorkspaceへ参加している場合、1回ConnectしただけですべてのWorkspaceを外部AIへ自動的に渡してしまうほうが、もともとの分離境界を壊すことになります。
本当に足りていないのは、その次のUIレイヤーです。同じClaude AccountにWorkspace A、B、Cという3つの正当な認証を保存しておき、新しいChatやProjectを開始するときに、今回どのWorkspaceを使うか明示的に選択できる機能です。
制限の中心はClaude Connectorであり、MCPプロトコルそのものではない
Anthropic GitHubにあるNotion専用Issueでは、現在の問題がかなり明確に説明されています。同じClaude Accountから接続できるNotion Workspaceは1つだけで、Agency、Freelancer、Consultantなど、自社データと複数クライアントデータを同時に扱う人は何度もReconnectする必要があります。投稿者が求めているのは、「複数Workspacesを接続する機能」と「SessionごとにどのWorkspaceを使うか選択する機能」です。
このIssueは後にDuplicateとして整理され、より広いMulti Connector Account問題へ統合されました。現在もOpenになっている別のFeature Requestでも、Claude WebのConnectorsは同じサービスに対して通常1つのアカウント／接続しか保持できず、GitHubやGmailなどでも同様の問題が起きると指摘されています。
そのため、「現在の主流MCPやOAuth Connectorの認証モデルは、1回につき1つのWorkspaceしか認証できない」という説明は広すぎます。より正確なのは、現在のClaude内蔵ConnectorではCredential／Session管理が「1種類のConnectorにつき主な認証を1組保持する」設計に近く、Notion MCPそのものはMCP Clientが複数のServer Connectionを管理することを禁止していない、という説明です。
だから「すべてのWorkspaceを統合する」が最初の答えである必要はない
Notion自体が複数Workspaceを使う運用を提供しており、WorkspaceごとにMembers、Guests、Billing、管理ルールを分けられます。Notion公式の権限ドキュメントでも、Workspaceは単なるフォルダではなく、実際の管理境界として扱われています。
複数Workspaceが、異なる会社、クライアント、管理者を分けるために存在しているなら、Claude Connectorの制限へ合わせてすべてを1か所へ移すほうが、毎回再認証するより大きな代償になる場合があります。特にクライアントのConfidential Dataを扱う場合、もともとの分離には意味があります。
そのため判断の順番は逆にしたほうがよいでしょう。まずAIが実際にどのデータを読む必要があるのかを確認し、そのあとWorkspace構成を変更する必要があるか判断します。Connectorの制限を理由に、最初から情報設計全体を作り直す必要はありません。
複数のNotion WorkspaceをClaudeで使うには？現時点で現実的な3つの方法
方法1：単一のAI Workspaceを作るが、AIが本当に必要な内容だけ移す
現時点では最も導入しやすい折衷案です。1つのWorkspaceをClaudeの主要な入口にし、AIによる検索、要約、書き込みが必要な内容だけを置きます。例えば公開Research、コンテンツ案、作業記録、機密性の低いプロジェクトデータなどです。クライアント契約、財務、個人情報、本当に隔離が必要な内容は元のWorkspaceへ残します。
ポイントは、すべての情報をもう1部コピーした巨大なMaster Workspaceを作ることではありません。意図的に範囲を絞ったAI-readable layerを作ることです。
例えば3つのWorkspaceにそれぞれ10数個のDatabaseがあっても、Claudeが頻繁に見るのがContent Calendar、Research Notes、Tasksの3種類だけなら、この3つだけを対象にします。同期が必要な部分はAPIや第三者Automationで選択的に複製することもできますし、更新頻度が低ければ手動で移す方法もあります。
NotionにはSynced Blocksがあり、公式ドキュメントでもWorkspaceをまたいで同じBlock内容を同期できることが明記されています。ただしSynced Blockは元Blockへのアクセス権限に依存し続けるため、元Pageを見る権限がない人には内容も表示されません。そのため、Synced Blockをそのまま「Workspace間のAI Data Sync」として保証された仕組みと考えるのは適切ではありません。
この方法の最大の利点は、Access Boundaryが明確になることです。Claudeが何を見られるかを、毎回再認証するときにその場で判断するのではなく、データ構造そのものによって先に決められます。
方法2：Workspaceの分離を維持し、Connectorを切り替え続ける
1日にWorkspaceを1〜2回しか切り替えないなら、この問題のためだけに新しい同期構造を作る必要はないかもしれません。
現在のClaude内蔵Connectorでは、Disconnect → Reconnect → Notion OAuthで別のWorkspaceを選択する、という流れが現実的な方法です。Redditの元投稿もこの手順を説明しており、AnthropicのFeature Requestでも現在同じ摩擦が残っていることが確認できます。
この方法は一見かなり原始的ですが、重要な利点があります。AIがその時点でアクセスできるWorkspaceが非常に明確です。
クライアント同士のデータを混ぜてはいけない場合、すべてを集約した巨大なMaster Workspaceを作るより、この方法のほうが説明しやすく、監査もしやすい場合があります。
手順を次のように固定しておくこともできます。
- 現在Claude ConnectorがどのWorkspaceへ接続されているか確認する。
- そのWorkspace Contextが必要な作業をまとめて完了する。
- 切り替える前にDisconnectする。
- Reconnect時にWorkspace名をもう一度確認する。
- クライアントデータへ切り替える前に、新しいChat／Projectを開始し、Contextを混在させない。
きれいな方法ではありませんが、Native Multi-workspace Connectorが登場するまでは、切り替え頻度が低い人にとって依然として最も低コストな方法かもしれません。
方法3：技術に詳しいユーザーなら、Workspaceごとに独立したAPI／MCP接続を作る
毎日本当に複数WorkspaceをまたいだAutomationを同時実行する必要があるなら、Claude Webの内蔵Connectorだけに制約される必要はありません。
Notion公式APIでは、Workspace OwnerがInternal Connectionを作成し、独立したIntegration Tokenを取得できます。これはAPI AutomationやPartner Platformなどで利用できます。Workspaceごとに別々のConnectionを作成でき、各Connectionがアクセスできる内容は、そのWorkspace側の共有設定と権限によって制御されます。
さらにWorkspace A、B、Cそれぞれに異なるIntegration Credentialsを用意し、自作プログラム、Automation Layer、MCP Serverなどを通じて別々のToolとして公開できます。例えば次のような形です。
notion_personalnotion_client_anotion_company
こうすれば、Agent実行時にどのデータソースを使うのか明示できます。
ただし、Claude Web Settingsへ3つのTokenを貼れば終わるわけではありません。MCP Bridge／Server、Credential Storage、Token Rotation、Logging、Error Handling、Permissionsなどを自分で管理する必要があり、明確な指示がない状態でモデルが複数クライアントのデータを自由に横断検索しないよう制御する必要もあります。
そのため、この方法はすでにAPI Workflow、Claude Code、自前Automationを使っているユーザー向けです。「別WorkspaceのあのNoteに何が書いてあったか、たまに確認したい」程度の用途には向いていません。
複数Workspace自体が問題なのではなく、AIが見られる範囲を設計することが重要
Notion MCPはユーザー権限を引き継ぎ、公式自身も広い権限範囲に注意を促している
Notion公式のMCP Best Practicesには重要な説明があります。MCP ToolsはユーザーのNotion Permissionsに基づいて動作し、そのユーザーがもともとアクセス可能なコンテンツを扱えます。そのため公式もPermissionsへ注意するよう明確に案内しています。
これは、「ClaudeからすべてのWorkspaceを一度に見られるようにする」ことが、必ずしも最善の製品設計ではないことを示しています。
Personal、Client、Companyを横断検索できれば便利な人もいます。一方で、別の働き方では明確なデータ分離問題になります。例えばClient Aの提案書を書いているとき、より完全な回答を作るためにAgentがClient Bの過去データまで自動的に検索するのは望ましくありません。
そのため、将来Anthropicが正式にMulti-workspaceへ対応するとしても、理想的な設計は単純な「Connect All」ではないはずです。GitHub Feature Requestで提案されているように、複数Workspaceの認証を事前に保存でき、そのうえでSessionやProjectごとに利用可能なWorkspaceを明確に選ぶ形のほうが合理的です。
「AI-readable layer」の価値は接続の便利さだけでなくBlast Radiusを小さくすること
専用のAI-readable data layerを作る場合、その最大の価値はReconnectの手間がなくなることだけではありません。
権限管理そのものをシンプルにできます。例えばContent ResearchはAI Workspaceへ入れてよいが、Client Contractは入れない、と最初からデータ構造で線を引いておけば、その後Claude、ChatGPT、Cursor、別のMCP Clientへ切り替えても、どのPageをモデルへ渡してよいのか毎回判断する必要がありません。
Notion Enterpriseでは現在MCP Governanceも提供されており、管理者がどのAI AppsをWorkspaceへ接続できるか制限できます。また、Notion MCPは既存Permissionsを回避しません。これは、権限管理が徐々にAI Connectorの正式な管理レイヤーになりつつあり、単に個人が「Connect」を押すだけの設定ではなくなっていることを示しています。
Notion AIの月間利用枠はいくら？66％を固定回数へ換算することはできない
同じ週のr/Notionでは、もう一つかなり具体的な質問がありました。あるユーザーがSettings → Notion AI → Usageを確認したところ、Monthly Allowanceを約66％使用済みで、9月2日にリセットされると表示されていました。しかし「合計何Creditsなのか」「あと何Prompt使えるのか」という絶対値が見つからず、実際あとどの程度利用できるのか疑問に感じていました。
この疑問は、現在のNotion UIにある透明性の限界をよく表しています。Notion公式は6時間UsageとMonthly Usageを表示し、それぞれがどのようにResetされるかも説明していますが、「毎月X Creditsが付与される」という固定換算表や、すべてのタスクをPrompt回数へ直接変換できる公式は公開していません。Notionはさらに、将来allowance sizeやcalculation methodを変更する権利も留保しています。
そのため66％と表示されている場合、確実に言えるのは、そのWorkspaceで今月のallowanceの約3分の2をすでに消費したということです。この数字から「あと34回質問できる」「残り何ドル分」と直接計算することはできません。
Regular Notion AIとCustom Agentsも、現在は完全に別々とは言えない
元の原稿にあった「Custom Agentsは別途Credits制で、2つの仕組みは異なる」という方向性自体は正しいですが、さらに正確にできます。
Personal Notion Agent、Image Generation、Page Translation、Skillsは、まず6時間＋月間Usage Allowanceによって管理されます。一方、Custom AgentsとWorkersは最初からNotion Creditsを直接使用します。
ただし、両者が永久に交わらないわけではありません。Workspace AdminがAllow workspace to use Notion credits after AI limit is reachedを有効にすると、Personal Agentがallowanceをすべて使い切ったあと、Notion Creditsを消費して継続できます。この設定はデフォルトでは無効です。
したがって、より正確な説明は、「Personal AgentとCustom Agentsでは最初の計算方法が異なるが、allowance超過後には両方が同じNotion Creditsシステムへ入る可能性がある」です。
この2つの問題には共通点がある｜UIは使うには十分な情報を見せるが、計画するには足りないことがある
複数Workspace ConnectorとMonthly Allowanceは、一見まったく別の話です。一方はPermissionsで、もう一方はBillingです。しかし2つのReddit投稿でユーザーが困っていることは似ています。システム側は完全な状態を知っていますが、UIから得られる情報は細かい計画を立てるには十分ではありません。
Claudeは現在Notion ConnectorがどのWorkspaceへつながっているか把握していますが、Native Workspace Switcherはありません。NotionはMonthly Allowanceの計算方法を内部では持っていますが、Usage UIでユーザーへ見せるのは主にPercentageであり、固定Credit換算表ではありません。
これが両社による意図的な不透明さを意味するとは限りません。AI ConnectorやUsage Billingはここ2年ほどで急速に増えた新しい機能で、製品UIがまだ追いついている途中とも考えられます。ただ、実際に仕事で使う人にとっては、細部がないことが本当の摩擦になります。このChatからどのClientを検索できるのか分からない、月半ばで66％使用済みなのが危険なのか判断できない、といった問題です。
そのため現時点で現実的なのは、UIが一度にすべて解決するのを待つことではなく、自分自身のAccess BoundaryとAI Usage Boundaryを先に明確にしておくことです。
複数Notion WorkspaceをAIへ接続する前に、まず整理したい3つの権限
第1段階：各WorkspaceでAIに何をさせたいのか整理する
最初から「Claudeに全部見せたい」と考えないようにします。
Workspaceと実際の用途を並べてみます。
| Workspace | AIにしてほしいこと | 機密データの有無 |
|---|---|---|
| 個人 | ノート整理、コンテンツResearch | 低 |
| 会社 | SOP検索、プロジェクト状況確認 | 中 |
| Client A | Meeting Notes整理 | 高 |
| Client B | AI不要 | 高 |
書き出してみると、すべてのWorkspaceを常時接続する必要はないと分かるかもしれません。
例えばClient WorkspaceでAIを使うのが月1回、Meeting NotesをAction Itemsへまとめるときだけなら、手動Reconnectを続けるほうが新しい同期システムを作るより簡単かもしれません。毎日読むPersonal／Companyデータだけが、固定の入口を別途設計する価値のある対象です。
第2段階：Connectorを便利にするためだけに機密データを移動しない
複数Workspacesをもともと意図的に分けているのであれば、ClaudeにWorkspace切り替えボタンが1つ足りないという理由だけで、無理に統合する必要はありません。
特にClient Contracts、Financial Records、Personal Informationなど、もともと異なる管理者、Access Policy、Legal Boundaryが存在する内容では、「AIから全部見られる」便利さより元の分離を維持するほうが重要な場合があります。
一部を集中させる必要がある場合も、Meeting SummaryのようにAIが実際に必要とする派生データだけを複製し、Client Workspace全体をコピーしない方法があります。
第3段階：Connectionは定期的に確認するが、「毎月1回」と固定する必要はない
元の原稿にあった「月1回確認する」という方法は、個人ルールとしては問題ありません。ただし、NotionやAnthropicが推奨する公式のセキュリティ周期ではないため、一般的なBest Practiceとして固定的に書くのは適切ではありません。
より合理的なのは、次のようなイベントが起きたときに確認する方法です。
- Client Projectが終了したとき
- メンバーが離脱したとき
- 特定のAIツールを使わなくなったとき
- Workspace権限を大きく変更したとき
- 新しい機密データソースを追加したとき
Notion Enterpriseの管理者は現在Workspace Levelで、どのAI AppsがMCPを利用できるか管理し、どのExternal AI Appsが接続済みか確認できます。
個人ユーザーも、不要になったConnectionを自分で削除できます。本当に重要なのは、「1年前に一度試したConnectorが今も残ったまま」という状態を避けることであり、必ず毎月1日に設定画面を開くことではありません。
「Notionを使っているのではなく、Notionを整理している」は関連話として使えるが、Connectorの結論へ無理につなげない
今週のr/Notionには、かなり共感を集めた自虐的な投稿もありました。投稿者は土曜日を丸一日使って「Database Templatesを管理するためのDatabase」を作っていた一方、本来のTodoであるreply to emailsは6月から放置されたままで、管理システム自体が新しい仕事になっているのではないかと疑い始めたという内容です。
これはMulti-workspace Connectorと直接的な技術関係はないため、両者が「実は同じ答えに行き着く」と無理につなげる必要はありません。自然な共通点があるとすれば、使い方の問題です。Notionは構造を増やしやすく、AI Connectorはデータへのアクセス範囲を広げやすい。どちらの場合も、新しいものを追加する前に「これは具体的にどんな問題を解決するのか」と確認する価値があります。
Workspaceに何層のDashboardが必要かに固定の正解はありませんし、AIも見られる情報が多ければ多いほど良いわけではありません。あえて入れないものを決めることも、情報設計の一部です。
現在のClaudeでは、同時に保持できるNotion Workspace Connectorは1組だけであり、複数Workspaceを日常的に使う人にとって確かに不便です。Anthropicにもすでに関連Feature Requestが届いています。ただし、これは現在のClaude Connectorの製品上の不足に近く、Notion MCPやOAuthが本質的にそうしか動けないという意味ではありません。
公式にMulti-workspace ConnectionやPer-session Workspace Selectorが追加されるまでは、最適な方法は切り替え頻度によって変わります。たまに切り替える程度ならReconnectを続ける。毎日同じ複数Workspaceデータを読むなら、限定的なAI-readable layerを検討する。大量のWorkspace横断Automationが本当に必要なら、APIや自作MCPを検討する、という順番です。
Connector Switcherが1つないという理由だけで、もともと意味のあるデータ分離をすべて壊す必要はありません。
よくある質問 FAQ
現在のClaude内蔵Notion Connectorを使う場合、実際のユーザー報告とAnthropic GitHub Feature Requestでは、同じClaude Accountに保持できるNotion Workspace接続は1つだけとされています。別Workspaceへ切り替える場合はDisconnectして再認証する必要があります。AnthropicにはMulti-workspaceやMulti Connector Accountの要望がすでに登録されていますが、現時点でNative Workspace Switcherは公開されていません。
単純にそういうわけではありません。Notion MCPのOAuthフローでは1回のConnectionで選択したWorkspaceへ認証しますが、MCPプロトコル自体が1つのClientに1つのServer／Credentialしか持てないと定めているわけではありません。現在より明確な制限があるのは、Claude内蔵Connectorが同じサービスの複数接続をどのように保存するかという部分です。
必ずしもそうではありません。複数Workspaceが異なる会社、Client、権限境界を分けるために存在する場合、統合することでかえって情報漏えいリスクが高まる可能性があります。より慎重な方法は、AIが実際に必要とする機密性の低いデータだけを集約し、そのほかは元のWorkspaceで分離したままにすることです。
技術的には、より高度な構成を作ることができます。NotionではWorkspace OwnerがInternal Connectionsを作成してTokenを取得できるため、Workspaceごとに別々のCredentialを用意し、自作プログラム、Automation、MCP Serverなどを通じてAIへ公開できます。ただし、Claude Webの内蔵ConnectorがこれらのTokenを自動管理してくれるわけではないため、Security、Routing、Error Controlなどは自分で管理する必要があります。
Notionが現在公開しているのは、6時間とMonthly Usage Windowの仕組みです。ユーザーはSettings → Notion AI → Usageから使用割合を確認できますが、すべてのタスクに共通する固定の「毎月X Credits／X Prompts」という分母は公開されていません。またNotionは、allowance sizeやcalculation methodを将来変更する可能性があることも明記しています。
最初の計算方法は異なります。Personal Agentはまず6時間と月間Usage Allowanceを使い、Custom Agentsは実行開始時からNotion Creditsを使用します。ただし、管理者が超過後のCredits利用を有効にしている場合、Personal Agentもallowanceを使い切ったあと同じNotion Creditsを使って継続できます。そのため、2つの制度が完全に無関係とは言えません。