目錄
それまで正常に動いていたNotion AI MCPのワークフローが、8月末、最初のTool Callで突然止まりました。画面には、あるツールのoperation typeが前回の管理者承認後に変更されたため、続行するには管理者の再承認が必要だと表示されました。さらに厄介なことに、問題が起きた多くのワークスペースでは、エラーが案内する再承認の入口自体が見つかりませんでした。MCPを完全に削除して再接続しても失敗するケースもありました。
当初は、Notionが新しいMCP権限ガバナンスを導入したものの、フロントエンドが追いついていないように見えました。しかし、その後の情報から、そのようには解釈できないことが分かりました。Notionは8月30日、一部のNotion AI MCP Tool Callsが失敗していると正式に認め、エンジニアリングチームの対応後、同日夜に復旧を発表しました。事故は約6時間36分続きました。8月29日のr/Notionの議論にも同じ現象が見られます。ConnectionsとTool Listは正常なのに、実行時だけoperation typeエラーが出た人や、同じMCPがAgentでは動くのにNotion AIでは失敗する人もいました。
したがって、今回の出来事自体は、ユーザーが突然管理者承認を一度忘れたというより、プラットフォーム側のMCP実行障害に近いものです。ただし、エラーメッセージにまったく参考価値がないわけではありません。Notionは実際、外部ツールを読み取り、書き込み、実行リスクに応じて、より細かく制御する方向へ進んでいます。区別すべきなのは二つです。今回のエラー原因について公開された技術的RCAはまだありません。一方、NotionがMCPとAgentの権限制御を増やしていることは、公式製品資料で確認できます。
本記事の情報は2026年8月31日時点のものです。Notion MCP、Custom Agents、Connectionsの管理画面は今後のバージョンで変わる可能性があります。
Notion AIの「operation typeが変更された」エラーでは何が起きたのか？
8月29日から同様の報告が相次ぎ、8月30日にNotionがMCP Tool Call障害を正式に認めた
8月29日、r/Notionには、以前は正常だったNotion AIのMCP Connectionsが突然すべて実行不能になったという報告が相次ぎました。エラーはいずれも、ツールのoperation typeが前回のAdmin Approval後に変わったため、管理者による再承認が必要だという内容でした。ある例はwhoamiを名指しし、別の例ではすべてのMCP Toolで同じ問題が起き、Connectionを削除して再追加しても改善しなかったと報告されています。
8月30日になると、Notion Statusが正式に障害通知を掲載し、一部のNotion AI MCP Tool Callsが失敗しており、エンジニアリングチームが問題を特定して対応していると発表しました。最終的に同日22時49分に復旧を告知しました。この時系列は重要です。ユーザーが見た「管理者に再承認を求めてください」という表示は、必ずしも管理者の設定漏れを意味しません。少なくともこの大量発生事例は、すべてのユーザーがApproval Buttonを探し当てて解決したのではなく、Notion側の修復で収束しました。
したがって、同じメッセージに遭遇したとき、最初から自動化全体を再構築すべきではありません。まずNotion Statusとコミュニティで同時多発の報告があるか確認します。相互に無関係な複数のMCP Serverが同時に失敗し、AuthenticationとTool Discoveryは正常なら、単一のConnectionだけを原因とみなすのは適切ではありません。
operation typeとは何か？MCPのRead／Write欄と直接同一視はできない
MCPにはツール動作の注記があるが、Notionはこのエラーがどの項目に対応するか公開していない
MCP Tool Definitionには、ツール名、説明、Input Schemaのほか、annotationsを含めることができます。そこにはreadOnlyHint、destructiveHint、idempotentHint、openWorldHintがあります。これらはMCP Clientに対し、Toolが読み取り専用か、データを変更・破壊する可能性があるか、外部世界へ接触するかを示せます。
しかしMCP仕様自体が、AnnotationはHintであって安全の保証ではないと明記しています。Clientも信頼できないServerの説明を無条件に信じてはいけません。さらに重要なのは、Notionがエラーメッセージ内のoperation typeをreadOnlyHintと同一だと説明する公開文書はなく、Tool Annotation、Input Schema、その他のTool Definitionのどの変更が再承認を必ず発生させるかも明らかにしていないことです。
したがって、元稿の「サーバーがReadからWriteへ変わると、以前のApprovalが失効する」は、リスクを理解する例としては使えても、今回の事故で確認された技術的原因としては書けません。whoamiが遮断されたことも、Notionが宣言の変化だけを比較している証拠にはなりません。事故中は大量のFalse Blockingが起き、最終的にNotionがプラットフォーム側で修復したからです。
Notionは実際にMCPツールをReadとWriteに分け、Writeをデフォルトで厳しくしている
Custom AgentのMCP Toolsを個別に制御できる
今回の事故からoperation typeの内部実装は証明できませんが、Notionの現在のCustom Agentsは、MCP Tool Riskをユーザーに見える設定として実装しています。Custom AgentのSettings → Tools & Accessを開き、MCP Connectionを展開すると、Serverが提供するToolsを確認し、個別に有効化または無効化できます。
NotionはこれらをRead ToolsとWrite Toolsに分類します。Search、Fetch、List、Viewのように主に情報を取得するツールはReadです。Create、Update、Delete、Send、Postなど外部データを変えるツールはWriteです。Read Toolは自動実行に設定できますが、Write Toolはデフォルトでユーザー確認が必要です。Agentが人の確認なしに外部システムのデータを直接変更・削除するのを防ぐためです。
これが現時点で公式資料に裏付けられた「Operation Risk Control」です。Toolがデータを変更できるかどうかがHuman Confirmationの要否に影響するという概念は、確かにエラーメッセージと近いものです。しかし、「8月29日の事故は、Notionが全ToolのOperation Type変更を検出し、正しくすべて遮断した」とまで推論することはできません。
なぜRead ToolとWrite Toolを分ける必要があるのか？
AI Agentと固定自動化の最大の違いは、モデル自身がTool Callを選ぶ可能性
従来のAutomationは、Form受信後にDatabase Recordを作成し、Emailを送信するというように、フローが事前に固定されています。配備前に各手順が何をするか分かっています。Agentは異なり、ユーザーが与えるのは目標です。モデルはその場のContextに応じてSearch、Fetch、Create、Update、SendなどのToolsを自ら選ぶ可能性があります。
AgentがSearchとFetchだけを持つなら、判断を誤っても主なリスクは、誤ったデータを読む、誤ったContextを取得する、使うべきでない情報を回答に入れることにとどまる場合が多いでしょう。同じAgentがUpdate、Delete、Send、Postも持つと、エラーは正式Databaseの変更、Emailの送信、データ削除といった外部Side Effectへ直結する可能性があります。
これが、NotionのPrompt Injection安全文書が最小権限を繰り返し求める理由です。公式はSensitive Workflowには本当に必要なPage、Database、Toolだけを与え、外部Toolに書き込みが不要ならRead-onlyを維持し、非Read-only ToolにはHuman Confirmationを残すよう推奨しています。AIができることが増えるほど、安全制御も「このConnectionを接続できるか」から、「このToolを自動実行できるか」まで細かくなる必要があります。
Notion MCPのOAuth権限はどこまで広いのか？
Hosted Notion MCPは基本的にログイン利用者のWorkspace権限に従う
Hosted MCPについてNotionの公式説明は明確です。MCP Toolsはログイン利用者がもともと持つNotion Permissionsで動作し、AI Toolは接続したWorkspace内でその利用者が本来アクセスできる内容を読み書きできます。これは従来のNotion API Integrationで一般的なPage-level Sharingとは大きく異なります。Hosted MCPはUser-based OAuthであり、Claude、Cursor、ChatGPTなどのAI Clientが現在の利用者としてNotionを操作することを主な目的としています。
したがって、「Hosted Notion MCPへ接続する」ことを、Agentに小さなDatabase一つだけを開放することだと理解すべきではありません。OAuth利用者がProjects、Clients、Meeting Notes、その他のPrivate Pagesへアクセスできるなら、Notion MCPに接続したAI Clientも原則として同じ権限範囲で作業できます。
本当に狭いデータ境界が必要なWorkflowで、Promptに「他のページを見ないで」と書くだけでは不十分なのもこのためです。固定プログラムが特定の数個のDatabaseだけを扱う要件なら、従来型Notion API Integrationのほうが明確なPage／Database Access Boundaryを作りやすい場合があります。Hosted MCPを使うなら、ログインする身分自体の権限もリスク評価に含める必要があります。
EnterpriseのMCP Governanceが管理するのはAI AppとClientで、今回のエラーにある単一Tool Approvalではない
EnterpriseはApproved AI Appsリストを作成できる
Notion Enterpriseは現在、Settings → Connectionsで、どの外部AI AppとMCP Clientがワークスペースへ接続できるかを管理できます。管理者はモードをApproved Listへ切り替え、Claude、Cursor、ChatGPT、その他MCP対応Clientを明示的に許可できます。未承認のツールは過去にTokenを取得していても、Notionが以降のCallを遮断します。
管理者はDisconnect All Usersで既存のNotion MCP Connectionsをすべて失効させることもできます。その後、ユーザーは再Authenticationが必要で、現在承認済みのAI Appからしか再接続できません。企業がOktaなど対応Identity Providerを使っていれば、管理者がEnterprise-managed Connectionを作成し、各メンバーが個別にOAuthを完了する手順を減らせます。
これらは「どのAI AppがNotion MCPへ接続できるか」を管理します。一方、Custom AgentのTools & Accessは「あるAgentがどのMCP Toolsを使え、実行時に確認が必要か」を管理します。両方ともApprovalと呼ばれるため混同しやすいですが、同じものではありません。
現在の公式公開文書に、「Tool Operation Typeが変わったら、ここで単一Toolを再Approveする」と記載したEnterpriseページはありません。したがって、8月末のエラーが管理者にModule Settingsで再承認するよう求めたとしても、既存のEnterprise Connections文書から、公式に記載されていない操作手順を補うことはできません。
Custom MCP Serverにはさらに別の権限制御がある
BusinessとEnterpriseではCustom Agentを自作MCPへ接続できるが、まずAdminが導入可否を決める
Notion Custom Agentsは現在、事前統合されたMCP Connectionsに加えて、カスタムHosted MCP Serverにも接続できます。Custom MCPを使うには、Workspace AdminがまずCustom MCP Serversを許可し、その後、メンバーが自由にConnectionを導入できるか、Approved Connectionsリストからのみ選べるかを決めます。
実際にConnectionを作ると、各Custom Agentは独自のMCP Connectionを持ち、最初にAuthenticationを実行したユーザーの外部サービスCredentialsを使います。ConnectionはAgent間で自動共有されません。Agent AがFigmaへログイン済みでも、Agent Bが同じConnectionを自動取得するわけではありません。
見落としやすい権限効果もあります。Custom Agentに十分な権限を持つユーザーは、自分自身が外部サービスへ別途ログインしていなくても、Agentを通じて接続済みのMCP Toolsを使える可能性があります。したがって、MCP ConnectionのAuthentication身分、誰がAgentを使えるか、Tool自体が何をできるかという三層を合わせて見る必要があります。
なぜ8月末の事故はガバナンス機能の更新だと誤解されたのか？
エラーメッセージが実際に操作できる政策のように具体的だった
ユーザーが目にした文言は非常に具体的でした。Toolのoperation typeが変わったため、Adminの再承認が必要だというものです。ところが画面には対応する再承認の入口がなく、再Authenticationも必ずしも有効ではありませんでした。この種のメッセージは、システムが以前より厳しくなっただけだと誤解させやすいものです。実際には当時、リスク変更のなかったTool Callまでまとめて遮断される可能性がありました。
その後の時系列で状況は明確になりました。Notionが発表したのは「MCP Governance更新のお知らせ」ではなく、Statusシステム上のIncidentでした。タイトルも一部のNotion AI MCP Tool Callsが失敗していると明記し、Engineering Teamの対応後に復旧しています。したがって、今回はサービス障害とするのが最も妥当です。
ただし、この障害は通常見えない安全層を偶然浮かび上がらせました。Notion AIのTool Runtimeは、単に「ServerがToolを示し、モデルが呼びたければすぐ実行する」仕組みではないことがうかがえます。少なくともClient、Connection、Tool Risk、Confirmationの間に追加のPolicy Checkがあり、今回はその一層が誤作動し、正当なTool Callまで止めたと考えられます。
Hosted Notion MCPは古いLocal MCP Serverを置き換えつつあるのか？
Remote版が公式の中心で、旧Open-source Serverは積極的な保守を終了
Notionが最初に提供したのは、自分でダウンロードして配備できるnotion-mcp-serverでした。既存のNotion API EndpointをMCP Toolsへ変換するものです。その後、Notionは自社HostedのRemote MCP Serverへ移行し、OAuth接続を採用しました。Tool InterfaceもAPIの一対一ラッパーではなく、Agent向けのSearch、Fetch、Create Pages、Update Pageなどとして再設計されています。
公式GitHub Repositoryには現在、チームが積極的にサポートするのはRemote Notion MCPだけであり、旧Local Serverは将来Sunsetする可能性があると明記されています。RepositoryのIssuesとPull Requestsも積極的には処理されません。公式Developer DocsもLocal ServerをLast Resortに位置づけ、Headless WorkflowがBearer Tokenを必要とし、User OAuthを完了できない場合などに限って利用理由が残るとしています。
Hosted Serverには、更新をNotionが管理するという別の違いもあります。Notionは、利用者がnpm Packageを各自更新しなくても、ServerのTool、Descriptions、内部実装を直接変更できます。Notion-flavored Markdownにより、Agentがページを読み書きする際、深く階層化されたBlock JSONを繰り返し処理する必要も減り、一般的な操作をより少ないTool CallsとTokensで完了できます。
しかし、この利点はTool Surfaceがサービス側で継続的に進化することも意味します。8月末の事故がHosted Tool Definition Changeによって本当に起きたかは、公式RCAがないため既知の原因とは書けません。言えるのは、Hosted ModelによってToolの更新が速くなり、それらへ依存するワークフローでは、サービス状態とSchema Changeを外部依存として管理する必要性が高まるということです。
Notion MCPで突然operation typeエラーが出たときの確認方法
まずNotion Statusを確認し、Connection全体をすぐ壊さない
Tool Listが残り、Authenticationも正常なのに、すべてのTool Callで同じPolicy／Approval Errorが突然出るなら、Notion StatusでNotion AI、MCP、Connectionsの障害を確認します。8月30日の件が典型で、再接続はすべての例を解決せず、最終的にNotionのプラットフォーム側修復が必要でした。
次に、すべてのToolが失敗するのか、特定ConnectionまたはToolだけか確認
Custom MCP Server一つだけが失敗し、他のMCPは正常なら、Server Authentication、Tool Definition、Credentialの問題に近いでしょう。Search、Fetch、Whoamiなど無関係なToolが一緒に失敗し、異なるServerでも同じメッセージが出るなら、単一Toolの動作が本当に突然変わった可能性は低くなります。
サービス復旧後も続く場合はAuthenticationをやり直す
Notion公式のMCP Troubleshootingは、Authenticationに問題がある場合、Disconnect／Clear Authentication後にOAuthをやり直すよう案内しています。この手順はStatusが正常で、問題が単一Connectionだけに残るときに適しています。プラットフォーム障害中に何度もConnectionを作り直すためのものではありません。
Custom AgentならTools & Accessを直接確認
Custom Agentでは、Settings → Tools & AccessからMCP Serverが提供するTools、現在Enabledのもの、各ToolがRun Automatically、Always Ask、Always Allowのどれかを確認できます。実際に書き込み、削除、送信するToolは、不確かなときに確認手順を残すほうが、完全無人化のためすべてAlways Allowにするより安全です。
本番の書き込みフローには復旧ポイントを残す
本番Databaseの更新、外部メッセージ送信、削除を行うWorkflowで、Agentの書き込みを全面禁止する必要はありません。しかし、Write ToolにHuman Confirmationを残す、Agentを指定Databaseだけに制限する、大量変更をまずDraft／Suggested Editsとして生成し、確認後に適用するなど、エラーを発見・復旧できる設計は必要です。
Notionは8月28日、Agentがまず行単位の変更案を提示し、人が一つずつ承認できるSuggest Editsを追加したばかりでした。品質管理が必要な文書Workflowでは、Agentが直接すべて変更した後にAudit Logで誤りを探すより、この設計のほうが一般に制御しやすくなります。
自作MCP ServerではTool Definitionをどう変更すれば安全か？
Breaking Changeは明示的にバージョン化するのが望ましいが、Clientの再確認を常に防げる保証はない
MCP Tool NameはClientがToolを識別する重要な名前です。既存Toolが単純な照会から外部データを変更するものへ変わったのに、まったく同じ名前と説明を使い続ければ、既存のPrompt、Agent Policy、Approval Assumptionがすべて実態とずれやすくなります。そのため、カスタムServerで明確なBehavioral Breaking Changeがある場合、新しいTool Nameを作るか、少なくともVersion、Description、Annotationを同時に更新し、呼び出し側が再評価できるようにすることを検討できます。
ただし、これを「名前を変えればNotionのoperation type Errorは二度と起きない」と説明してはいけません。Notionは内部Approval Cacheの規則を公開していないため、Tool Name、Schema、Annotationのどの変更が再確認を求めるかについて、依存できる正式契約はありません。
確実なのは、MCP仕様がreadOnlyHint、destructiveHint、idempotentHint、openWorldHintなどの動作説明を提供していることです。Server Authorは正しく設定すべきですが、Client側は依然Hintとして扱い、Serverの自己申告だけで本当の安全境界を作るべきではありません。
Notion MCPとNotion APIの違い
MCPはAIがツールを選ぶ用途、APIは固定的で予測可能なプログラムフローに向く
Notion MCPの中心的な利点はAgent-friendlyであることです。AI ClientはまずToolsをDiscoverし、自然言語の要件に応じてSearch、Fetch、Create Pages、Update Pageなどを自ら組み合わせられます。Remote MCPはNotion-flavored MarkdownとNotion AI Semantic Searchも利用でき、大量のページ操作をBlock JSONで直接処理するよりLLMに適しています。
Notion APIは決定論的なBackend Workflowに向きます。プログラムが明確なEndpointを直接呼び、Authentication、入出力、エラー処理を開発者が制御できます。File Upload APIなど、MCPにまだない機能も使えます。Remote Notion MCPはUser-based OAuthを使用し、現在Bearer Tokenをサポートしないため、人がまったく関与しないHeadless Automationには必ずしも適しません。固定のServer-to-serverワークフローでは、引き続きAPI Integrationを検討する必要があります。
つまり、どちらかがどちらかを置き換えるわけではありません。「AIがContextに応じてデータを探し、次の操作を判断する」要件ならMCPが自然です。「毎朝8時にA Databaseの3項目をBへ同期する」要件なら、従来のAPIやWorkerのほうがテストしやすく、Agent Decisionをフローへ入れる必要も少なくなります。
今回の事故で本当に変えるべきなのは、すべてのWrite Toolを取り除くことではない
8月末のoperation type Errorは最終的にNotion AI MCPのサービス障害だったと判明しました。個人ワークスペースでApproval Buttonを一つ押し忘れたわけではなく、影響を受けたすべてのMCP Serverが同じ日にTool動作を変更したという証拠もありません。ここを誤ると、その後の「NotionはMCP全体を再承認制にしている」という推論もずれてしまいます。
それでもエラーメッセージがもっともらしく見えたのは、Notionの現在の製品方向と重なるからです。EnterpriseにはAI App Allowlistがあり、Custom AgentsはToolごとにRead／WriteとConfirmationを設定でき、Prompt Injection資料はLeast PrivilegeとHuman Confirmationを主要防御策として繰り返し挙げています。AI Agentが実際にデータを変更できるようになれば、Tool Permissionの細分化はすでに進んでいる事実です。ただし、今回のIncidentはその傾向の正式な発表ではありません。
Notion AutomationやMCPワークフローに依存する人にとって、今後の実用的な準備は、このError Messageを暗記することではありません。どのWorkflowがReadだけか、どれがWriteするか、どれに人が必ず必要か、どれが単一のMCP Service Failureで完全停止してはいけないかを区別することです。そうすれば、次にプラットフォーム更新や障害に遭遇したとき、ベンダーの修復を待つべきか、自分のConnectionを修正すべきか判断しやすくなります。
よくある質問
必ずしもそうではありません。2026年8月29〜30日にこのメッセージが大量発生した際、Notionは一部のNotion AI MCP Tool Callsの障害を正式に認め、プラットフォーム側で修復しました。その波は「管理者が未承認だった」だけでは説明できません。今後、単一ワークスペースで再発した場合も、まずStatusとConnectionを確認してから、実際の設定変更があったか判断すべきです。
必ずではありません。通常のAuthentication障害ではDisconnect後にOAuthをやり直すことがNotion公式Troubleshootingで推奨されていますが、8月末の障害中にはConnectionを完全に削除・再作成しても失敗したという報告がありました。プラットフォームIncidentが未修復なら、再承認を繰り返してもServer-side Errorは通常解消しません。
現時点の公式文書には、今回のメッセージと完全に対応する「単一Tool Operation Type Re-approval」の手順はありません。EnterpriseにはAI App／MCP Client Approved Listがあり、Custom AgentではToolごとの有効化とConfirmationを管理できますが、どちらもエラーが指したModule Re-approvalページと直接同一視できません。
接続したWorkspace内では、Hosted Notion MCPは利用者自身のNotion Accessで動作し、公式にもMCP Toolsは利用者が本来アクセスできる内容へアクセスできると説明されています。これはデフォルトで数ページだけを開く低権限Integrationではありません。より小さなデータ境界が必要なら、Authenticationの設計を変えるか、固定Page Scopeに適したIntegration構成を使う必要があります。
Read ToolはSearch、Fetch、List、Viewなど主に情報を取得します。Write ToolはCreate、Update、Delete、Send、Postなど外部システムを変更します。NotionはデフォルトでWrite Toolの実行前に確認を求め、Read Toolはリスクが許容できる場合に自動実行へ設定しやすくしています。
一般的な用途ではHosted Notion MCPを優先すべきです。公式はRemote Serverを積極的に保守する版とし、旧Open-source notion-mcp-serverの積極保守を終了し、将来の退役可能性も示しています。ただしRemote MCPはUser OAuthに依存しBearer Tokenをサポートしません。完全無人のHeadless WorkflowでToken-based Authenticationが必要なら、Notion APIや自主管理の統合を検討する余地があります。
AIが自然言語に応じて検索・読み取りを行い、次のTool Callを自ら選ぶならMCPが向きます。固定スケジュール、データ同期、精密な権限、File Uploadのような決定論的フローはNotion APIのほうが制御しやすい場合が多いでしょう。両者は併用でき、すべてのAutomationをAgent Workflowへ変える必要はありません。