どうも おかしん です。
Notion Statusで、Notion AIのAnthropicモデルに関する障害情報が出ていました。
発端になったのは、Notion Statusの2026年6月7日のインシデントです。Notionは、AnthropicのClaude Opus 4.7 / 4.8がdegraded performanceの状態になり、Notion AIでそれらのモデルを選んだユーザーの失敗率が上がっていると説明しました。
影響緩和として、Anthropicモデルをモデルピッカーから一時的に無効化し、リクエストを代替プロバイダーへ迂回したとも説明しています。
一方で、巷では「Opus 4.7 / 4.8の知能が下がったのではないか」「Anthropic内部のソースコード管理に問題があったのではないか」「Opus 4.7 / 4.8が十分にドッグフーディングされていないのではないか」といった噂も見かけます。
ただ、公開情報ベースで見ると、今回まず整理すべきなのはモデルの知能ではなく、Anthropic側の提供基盤でリクエストの成功性が落ちていたことです。
何が起きたのか
Notion側の説明をそのまま整理すると、ポイントは4つです。
| 観点 | 内容 |
|---|---|
| 対象 | Notion AIで選択できるAnthropicのClaude Opus 4.7 / 4.8 |
| 現象 | 対象モデルを選んだユーザーで失敗率が上がった |
| Notion側の対応 | Anthropicモデルをモデルピッカーから一時的に無効化した |
| 迂回策 | リクエストを代替プロバイダーへルーティングした |
つまり、Notion AI全体が止まったという話ではありません。Notion AIの中でAnthropicモデルを使う経路に問題が出て、Notion側がAnthropicモデルを一時的に外し、別のプロバイダーへ逃がしたという話です。
Notion AI security practicesでも、Notion AIは複数のAI Subprocessorの技術を利用しており、LLMについてはNotion自身がホストするものだけでなく、AnthropicやOpenAIのような組織がホストするモデルも利用していると説明されています。今回のStatusで説明されたAnthropicモデルの無効化と代替プロバイダーへの迂回は、このような複数プロバイダー前提の設計とも整合します。
Notion Status上では、2026年6月7日 04:25にIdentifiedとして投稿され、04:43にResolvedになっています。
また、2026年6月5日のNotion Statusにも、Opus 4.7 / 4.8が問題を起こしていた記録があります。単発の一瞬だけというより、6月上旬にNotion AIのAnthropic経路で不安定さが見えていた、と読む方が自然です。
知能低下ではなく、リクエスト成功性の問題
今回の文脈でのdegraded performanceは、モデルの知能が恒久的に下がったという意味ではなく、リクエストの成功性が落ちたという意味で読むのが安全です。
Notion Statusが明示したのは、失敗率の上昇、Anthropicモデルのモデルピッカーからの無効化、代替プロバイダーへの迂回です。ここから分かるのは、Notion AIがAnthropicモデルを使う経路で、ユーザーのリクエストが期待どおり完了しにくくなっていたということです。
Anthropic側のステータスページにも、5月末から6月上旬にかけてClaude Opus 4.7 / 4.8のelevated errorsが複数記録されています。たとえば2026年5月29日のClaude Opus 4.8インシデントでは、Opus 4.8へのリクエストでエラーが増え、修正後にsuccess ratesが通常に戻ったと説明されています。
2026年6月上旬の私の手元でも、Claude Codeを使っていて 529 Overloaded がしばしばありました。AnthropicのAPI errorsドキュメントでは、529は overloaded_error、つまりAPIが一時的に過負荷になっている状態として定義されています。さらに、529はAPIが全ユーザー横断で高トラフィックになった場合にも起きると説明されています。
このあたりをまとめると、今回見えているのは、モデルそのものの知能低下というより、Claude Opus 4.7 / 4.8を提供するバックエンドの不安定さです。大量アクセスが原因なのか、サービング設計の問題なのか、別の運用上の問題なのかは公開情報だけでは分かりません。ただ、利用者から見ると、バックエンドの不安定さは「性能が悪い」「失敗する」「使えない」という体験として表面化します。
影響を受けるサービス
今回の影響を受けた可能性が高いのは、Claude Opus 4.7 / 4.8をAnthropic側のClaude提供基盤から使っていた経路です。
Notion AIでAnthropicモデルを選ぶ経路はその代表です。Notion自身がすべてのモデルをホストしているわけではなく、Anthropicなどがホストするモデルも使う設計であるため、Anthropicモデルの提供側でリクエスト成功性が落ちると、Notion AI上ではClaudeを選んだときに失敗しやすいという形で見えます。
Claude公式やClaude API、Claude Codeのように、Anthropic側のClaude提供基盤に直接または近い形で依存するサービスも、近い時期にエラー増加や過負荷の影響を受けた可能性があります。Claude Statusにelevated errorsが記録されているため、Notionだけの孤立した問題として見るより、Anthropic側の提供基盤で起きていた問題として見る方が自然です。
同一視しないサービス
一方で、Opus 4.7 / 4.8を使えるサービスでも、Notion AIと同様の影響を受けないサービスもあります。大事なのはモデル名ではなく、そのモデルがどこでホストされ、どの提供基盤を通って呼ばれているかです。
まず、Microsoft 365 Copilotの通常経路はNotion AIのAnthropicモデル選択経路とは別物です。Microsoft 365 Copilot architectureでは、CopilotはMicrosoft 365 service boundaryの中で動き、Microsoft Graphを通じてユーザー権限の範囲で組織データにアクセスすると説明されています。
さらにMicrosoftのサービス保証系ドキュメントでは、Microsoft 365 Copilotで使われる大規模言語モデルはMicrosoft 365専用のAzure OpenAI ServiceインスタンスでMicrosoftがホストし、Microsoft 365 service boundary内にあると説明されています。Microsoft Online ServicesのAIモデル整理でも、Azure上でMicrosoftがホストして直接提供するモデルと、AI Subprocessorが処理するモデルは分けて説明されています。
その意味で、Microsoft 365 Copilotの通常経路は、AnthropicのClaude提供基盤をNotion AIから呼ぶ経路とは同一視しない方がよいです。
一方で、Microsoft 365 Copilotの中にもAnthropicモデルを使う経路があります。Anthropic as a subprocessor for Microsoft Online Servicesでは、AnthropicモデルがMicrosoft Online Servicesのsubprocessorとして導入され、Microsoft 365 Copilot、Researcher、Copilot Studio、Power Platform、Agent Mode in Excel、Word / Excel / PowerPoint agentsなどで利用され得ると説明されています。
Copilot CoworkのGet startedドキュメントでも、Coworkの前提条件に「Anthropic enabled in tenant」が含まれ、CoworkはAnthropicモデルをsubprocessorとして使うと説明されています。Microsoft 365 Roadmapでも、Claude Opus 4.7はCopilot Cowork、Copilot Studio、Excelへの展開対象として記載されています。
ここで重要なのは、MicrosoftのAnthropicモデル利用経路は、Notion AIがAnthropicモデルを外部プロバイダーとして使う経路と同じだとは限らないことです。Microsoftは、AnthropicをMicrosoft Online Servicesのsubprocessorとして扱い、Microsoft Product TermsやMicrosoft Data Protection Addendumの下で提供すると説明しています。
ただし、これはMicrosoftがAzure上でホストして直接提供するモデルと同じ分類ではありません。MicrosoftのAIモデル整理では、MicrosoftがAzure上でホストして直接提供するモデルではData does not leave Microsoftと説明されています。一方でAI Subprocessorは、第三者のAI providerがMicrosoftに代わってデータを扱う分類です。さらにAnthropicモデルはEU Data Boundaryやin-country processing commitmentsから除外されるとも説明されています。
そのため、公開情報ベースでは、Anthropicモデルを使うCopilot機能についてAnthropic APIを直接叩いているとまでは書かない方がよいです。同時に、Microsoft自社ホストのモデルとして動いているとも書かない方がよいです。Microsoft 365 Copilotの通常経路はMicrosoft基盤、Anthropicモデルを使うCopilot機能はMicrosoft Online Services上のAnthropic subprocessor経路、と分けて見るのが正確です。
整理するとこうです。
| 区分 | 例 | 読み方 |
|---|---|---|
| Anthropic側のClaude提供基盤 | Notion AIでAnthropicモデルを選ぶ経路、Claude公式、Claude API、Claude Code | 今回のNotion AIの失敗率上昇と近い影響を受け得る |
| Microsoft基盤 | Microsoft 365 Copilotの通常経路、Microsoft 365 service boundary内のAzure OpenAI Service / Microsoft-controlled environment | Notion AIのAnthropic経路とは別物として見る |
| Microsoft Online Services上のAnthropic subprocessor経路 | Copilot Cowork、Copilot Studio、Researcher、Excel Agent ModeなどでAnthropicモデルを使う経路 | Anthropic API直接利用とも、Microsoft自社ホストとも断定しない |
まとめ
今回の件の真相は、公開情報ベースでは「Opus 4.7 / 4.8の知能が下がった」ではなく、「Anthropic側のClaude Opus 4.7 / 4.8提供基盤でリクエストの成功性が落ち、それがNotion AI上の失敗率上昇として見えた」です。
Anthropic内部のソースコード管理ミスや、ドッグフーディング不足が原因だという噂はありますが、公開情報だけでは確認できません。
また、Microsoft 365 Copilotの通常経路のようにMicrosoft基盤で動くサービスまで、Notion AIと同じ影響を受けたと見る必要もありません。見るべきなのは、サービス名やモデル名ではなく、そのモデルがどこでホストされ、どの提供基盤を通って呼ばれているかです。
今回の記事としては、ここまでを押さえれば十分です。Notion AIのインシデントは、モデルの知能低下を示すニュースというより、AIサービスにおけるバックエンドの不安定さが、ユーザーには性能不足として見えることを示したニュースだと思います。
