目錄
今週、r/Notion にかなり具体的な体験談が投稿されました。3年間 Notion を使ってきたユーザーによると、ドキュメントと Wiki は今でもチームから高く評価されている一方、本格的に負荷を感じ始めたのは、その後ワークスペースへ追加していった業務システムだったそうです。Linked Databases で構築した CRM、承認フロー、さらに実際のロジックを持つ複数の Tracker。投稿者の経験では、チーム規模が50人を超えたあたりから大規模データベースの動作が重くなり、権限管理や Automation の扱いも複雑になったため、最終的には「業務運用の半分」を外部へ移し、Notion には本来得意なドキュメントと Wiki だけを残すことを検討し始めました。
ただし、「50人」をそのまま Notion の製品上限と考えることはできません。Notion 公式は「50人を超えると不向きになる」という基準を設けておらず、現在も Business、Enterprise、Database page-level access、Sprints、Charts、大規模データベース向けの機能を提供しています。ワークスペースが重くなったり、運用しづらくなったりする原因として大きいのは、むしろデータ構造です。ページ数、Property 数、複雑な Formula と Rollup、Filter／Sort、そしてアクセスの多い1ページで同時にどれだけのデータベースを読み込んでいるかが影響します。つまり、チーム人数はもともと構造の中にあった問題を早く表面化させる要因ではありますが、51人目がログインした瞬間に Notion が使えなくなるわけではありません。
CRM、承認、プロジェクト管理、そのほかの会社業務を Notion に集約しようとしているチームにとって、この問題は単純な料金プラン比較より難しいものです。料金なら翌月プランを変更できますが、数年分のデータ、Relation、Automation、運用習慣が積み上がったワークスペースを移行する作業は、クレジットカードを変更するほど簡単ではありません。ここでは、今週 r/Notion で話題になった複数の投稿から見える共通課題と、ワークスペースを設計するときに先に決めておきたい境界線を整理します。（本記事の情報は2026年8月時点です。Notion の機能・制限は今後変更される可能性があります。）
Notionは50人を超えると使えない？本当の問題は人数そのものではない
3年間使ったユーザーの分岐点｜DocsとWikiは残し、業務システムは外へ移したい
この r/Notion 投稿のタイトルは、問題をかなり端的に表しています。「Notion の中で Docs ではない半分について、代替ツールを探す必要があるかもしれない」という内容です。
投稿者は Notion を3年間利用しており、冒頭では今でもドキュメントと Wiki の機能を高く評価していると説明しています。問題になったのは、その後チームがより多くの業務フローを Notion へ載せ始めたことでした。Linked Databases を使った CRM、Approval Flow、そして実際のロジックを組み込んだ複数の Tracker です。
チームが50人を超えたころから、大規模データベースの速度低下、権限管理の複雑さ、さらに一部のリアクティブな処理を補うために第三者 Automation が必要になる場面が増えたとしています。
ただし、これはあくまで一つのチームの実体験であり、Notion 公式による性能試験ではありません。そのため、「50人を超えたら Notion をやめるべき」というルールとして扱うより、「どのタイミングで設計を見直すべきか」を考えるケースとして見るほうが適切です。
Notion 公式のパフォーマンス資料でも、主要な判断基準としてチーム人数は挙げられていません。むしろ、データベースを重くする具体的な要因として、ページ数の多さ、表示している Property 数、Formula や Rollup の複雑な参照、複雑な Property を使った Sort／Filter、そして1つの Dashboard で同時に大量の Inline Databases を読み込むことなどが挙げられています。
Notion の単一データベースは現在最大250,000 Rowsまで扱えますが、「ハード上限に達していない＝快適に動作する」とは限りません。公式も、大規模 Workspace ではアクセスの多いページに大量の Inline Databases を並べないことや、Formula と Rollup を何層にもわたって参照させないことを勧めています。
こうした問題は5人チームでは目立たなくても、データ量、ユーザー数、業務フローが同時に増えていくと、Dashboard を開くたび、Formula を計算するたび、View を切り替えるたびに以前より遅いと感じるようになります。
「権限はほぼ全部見えるか全部見えないか」は現在では修正が必要
元の Reddit 投稿では Permissions を「basically all or nothing」と表現していますが、この表現をそのまま現在の Notion に当てはめるのは正確ではありません。
Notion の Business と Enterprise では現在、Database page-level access が利用できます。Person Property や Created by Property を基準に、特定の Database Page を誰が閲覧・編集・コメントできるか設定できます。
例えば、サポートチケットなら作成者だけが自分の項目を見られるようにしたり、外部委託者なら割り当てられた Task だけにアクセスさせたりできます。
さらに Notion には Can edit content があり、メンバーはデータベースの中身を編集できても、Properties、Views、Filters、Sorts そのものは変更できないようにできます。Business／Enterprise では Can create も利用でき、ユーザーは新しいデータを作成できても、別途アクセス権を与えられていない既存データは閲覧できない設定が可能です。
そのため、現在の問いは「Notion に細かい権限がないか」ではなく、「現在の権限モデルで、その CRM、承認フロー、業務システムに必要なルールを表現できるか」です。
例えば、部門、顧客、商談フェーズ、ロールなどをもとに大量の動的アクセス制御が必要だったり、Field-level permissions、Audit rules、複雑な承認条件まで求められたりする場合は、専用 CRM や業務データベースのほうが適している可能性があります。
これは「Notion には Row-level permissions がまったくない」という話とは別です。
Notionのデータベースはなぜ使うほど遅くなる？公式が挙げている主な原因
大規模データベースだけが原因ではない｜参照構造と表示方法が重くなりやすい
Notion 公式が挙げているパフォーマンス要因はかなり具体的です。Database Pages が多いほど読み込み時間は増えやすく、Visible Properties が多ければ処理する情報量も増えます。
さらに、Formula、Rollup、Text など複雑な Property を View の Filter や Sort に使うと、計算量はさらに増えます。
見落とされやすいのが Reference Chain です。例えば、ある Formula が別の Formula を参照し、その Formula が Rollup に依存しているような構造です。このような多段参照は、データ量が増えたとき、単純な Status、Date、Select より大きな負荷になりやすくなります。
「Everything in Notion」を目指した Workspace が後から苦しくなる理由もここにあります。
最初は Projects と Tasks の2つのデータベースしかなかったのに、その後 Clients、Meetings、Invoices、Approvals、Objectives、Sprints が追加され、すべてを Relation と Rollup で接続していく。各機能だけを見れば Notion で実現できますが、最終的にはデータベース同士が相互依存するシステムになります。
そうなると、Property を一つ変更しただけで複数の Dashboard や Formula に影響が出ることもあります。
Notion が大規模 Workspace に対して勧めている方法も実務的です。アクセスの多いページには大量の Inline Databases を置かず、必要なら Linked Database と複数 View を利用し、現在開いている View だけを表示する。不必要な Properties は非表示にする。複雑な Filter を適用する前に、Status、Date、Select といった比較的単純な Property で対象 Pages を絞り込む。
つまり、「データが多い」という一点だけではなく、「どう参照し、どう表示しているか」まで含めて設計する必要があります。
50人は問題の原因ではなく、症状が見え始めるタイミングに近い
5人のチームが1日に数件しかデータを追加しないのであれば、かなり複雑な構造でも短期的には問題が見えないかもしれません。
同じ構造を50人が使い、毎日 Tasks、CRM Records、Comments、Approvals、Project Updates を追加すれば、データが増える速度はまったく違います。
Reddit の投稿者が「50人以上」を自分の分岐点として覚えているのは、このためだと考えられます。一方、Notion 公式のパフォーマンス資料が主に扱っているのは人数ではなく、データ量とデータベースロジックです。
そのため、「会社に何人いるか」よりも、以下のような指標を見るほうが実態に近くなります。
Workspace に主要 Database がいくつあるか。1つの Dashboard で何個の View を読み込んでいるか。Formula／Rollup が何段階参照されているか。1日にどれくらい Records が追加されるか。
これらが増えてきたときに初めて、「どの業務は Notion に残し、どのデータは専用システムへ移すべきか」を本格的に検討する必要があります。
生産性テンプレートは1年後も使われている？維持コストもスケールの問題
Workspaceは作って終わりではない｜本当に難しいのは半年後も維持できるか
同じ週、r/Notion では別の投稿者が「Productivity template one year later」のような報告スレッドを作ってはどうかと提案していました。
非常に完成度が高く、管理項目も多い Second Brain や Productivity Templates が、1年後にどれくらい実際に使われ続けているのかを知りたいという問題提起です。
別の関連投稿では、数年間で Second Brain、Habit Tracker、Personal CRM、Content Calendar など数十種類のテンプレートをダウンロードしたものの、現在実際に使っているものはゼロだというユーザーもいました。
友人が使わなくなった理由についても、テンプレートそのものの品質が悪かったからではなく、「そのシステム自体を維持する仕事」が増えてしまったことが多かったと述べられています。
これは50人規模の会社が抱える問題と本質的には同じで、違うのは規模だけです。
個人向けテンプレートでは、毎週 Inbox を整理し、10個以上の Properties を更新し、すべてのメモを正しい Database に分類する必要があるかもしれません。
企業 Workspace では、メンバー全員が CRM Stage、Project Status、Approval、Sprint、Relation を正しく更新し続ける必要があります。
維持に必要な作業量が、その仕組みによって削減できる作業量を上回れば、ユーザーは更新を省略し始めます。データが正しくなくなれば、どれだけ美しく作られた Dashboard でも意味を失います。
そのため Notion の設計を評価するとき、「実現できるか」は最初の質問にすぎません。
次に聞くべきなのは、「半年後も全員がこのルールどおり更新しているか」です。
システムが多数の Property を手動更新する前提で成り立っているなら、業務量が増えたとき、問題になるのは Notion の機能不足ではなく、運用ルールそのものかもしれません。
Notionのプロジェクト管理は十分？小規模チームが成長すると報告指標が必要になる
初のフルタイムエンジニア採用前に、小規模エージェンシーがBurndownとコスト指標を懸念
同じ週、別の r/Notion ユーザーは、小規模エージェンシーで初めてフルタイム Developer を採用する予定だと投稿していました。
現在は Task Templates、SOP、Customer Conversations、会社の Context のほぼすべてを Notion に集約しています。
そのチームが迷い始めた理由は、より構造化された PM／PMO 情報が必要になってきたからです。例えば Automated Burndown、Budget vs Actuals、その他の Productivity Metrics などです。
ここでも「Notion はプロジェクト管理ができない」と単純化するのは正確ではありません。
Notion には現在、Task Databases、Sprints、Dependencies、Timeline、Charts があります。Sprint Database では各 Sprint の完了率を表示でき、未完了 Task を次の Sprint へ自動で移すこともできます。
公式ドキュメントでも、Project Management、Engineering Sprints、進捗管理はデータベースの正式なユースケースとして紹介されています。
違いは、「自分たちで構築できるか」と「製品が最初から用意しているか」です。
Task の完了率、Project Timeline、簡単な Chart を確認する程度なら、Notion でもかなり対応できます。
一方、成熟した Burndown、Velocity、Capacity Planning、Budget Variance、コードの Issue／PR と深く連携したレポートまで必要になると、専用 PM ツールのほうが、自前のモデル設計や維持作業を大幅に減らせる場合があります。
これもチーム規模が大きくなると起こりやすい変化です。
小規模チームなら、誰が何をしているかを全員がだいたい把握でき、会議で確認すれば済みます。
職種が一つ増え、並行するプロジェクトが増えると、管理者は毎週同じ方法で比較できる指標を必要とするようになります。
その結果、自由度の高かった Database に Formula や Report が増え、運用コストも上がっていきます。
Notion Calendarはなぜまだ不満が出る？Database CalendarとNotion Calendarは別物
DatabaseにはCalendar Viewがあるが、Notion Calendar本体は今も独立したインターフェース
今週の別の r/Notion 投稿では、Notion Calendar が登場してから数年経っても、完全な Notion Calendar を通常の Notion Page 内に直接表示できないという不満が投稿されていました。
この指摘は、現在の公式ドキュメントが示している機能範囲とおおむね一致しています。
Notion Database は Notion Calendar と接続でき、Date Property を持つ Pages を Calendar App 上に表示できます。また、Calendar から Database Item を直接作成・編集することもできます。
一方、完全な Notion Calendar App をネイティブ Block として通常の Notion Page に埋め込む公式機能は、現時点では用意されていません。
混同されやすいのは、Notion Page の中にはもともと Calendar View があることです。
この View は、一つの Database 内にある Date Property 付き Records をカレンダー形式で表示するものです。
一方の Notion Calendar は、Google／Apple Calendar と複数の Notion Databases を同時に扱える独立した製品です。
現在、Notion Calendar には最大20個の Notion Databases を追加でき、Calendar 側から Database Pages を直接操作できますが、完全な両者の UI が同一 Page Block として統合されたわけではありません。
そのため、この問題は「Notion には Calendar がない」と書くより、「Notion Calendar と Notion Page のインターフェース統合はまだ完全ではない」と表現するほうが正確です。
もう一つの考え方｜Notionをデータ・知識レイヤーとして使い、すべてのロジックを中に置かない
Notion＋Claudeの事例｜SOP・CRM・会議記録を同じContextに集約する
同じ週には、まったく逆方向の事例も投稿されていました。
ある会社経営者は、SOP、Meeting Notes、CRM を Notion に集約し、その Context を Claude に直接読み書きさせていると説明しています。
Sales Call 後のフォローアップメール作成、Meeting Transcript から KPI を抽出して Database を更新する処理、過去の Newsletter と社内ノートから新しいコンテンツを生成するといった用途です。
投稿者は、この仕組みによって週10時間以上節約できているとしています。
ただし、これはあくまで個人の利用結果であり、投稿者自身の運用コンテンツの宣伝要素も含まれているため、すべてのチームで同じ効果が得られると考えるべきではありません。
この事例で興味深いのは、Notion 自体がすべてのロジックを担当する必要がない点です。
Workspace は SOP、CRM、Meeting Notes、その他の会社 Context を保存する場所として使い、Claude がそれらを読み取り、推論し、必要な結果を生成し、保存するべき内容だけを Notion に書き戻す。
これは、Notion を Knowledge／Context Layer として扱う設計に近く、すべての業務フローを Formula、Rollup、Automation の組み合わせに変換する考え方とは異なります。
もちろん、この設計には別の課題があります。
外部 AI のアクセス権、データセキュリティ、API／サブスクリプション費用、誤った書き込みなどは別途管理する必要があります。
それでも、「Notion はデータを置くのに向いているからといって、すべての処理ロジックまで Notion に置く必要はない」という別のアーキテクチャを示しています。
NotionのWorkspaceが複雑になったら確認したい3つの分岐点
ドキュメントとナレッジはNotionに残し、業務システムは要件で判断する
Docs、Wiki、Meeting Notes、SOP、長期的なナレッジは、通常それほどリアルタイム計算を必要とせず、複雑な権限やトランザクションロジックも必要ありません。
最初に紹介した3年間利用しているユーザーが、CRM や業務フローを移したとしても Notion を Wiki として残したいと考えているのも、このためです。
一方、CRM、Approval、Finance、Engineering Project Management などは、もう少し具体的に要件を確認する必要があります。
条件付き権限が大量に必要か。固定された管理指標を自動生成する必要があるか。大量のトランザクション記録を扱うか。核心的な処理を実行するために第三者 Automation に頻繁に依存しているか。
こうした問いへの答えが何度も「はい」になるなら、同じ Database に Property を追加し続けるより、専用ツールと比較したほうが合理的です。
新しい機能を追加する前に、1年後の維持コストも計算する
美しい Workspace を構築すると、その後の維持コストを過小評価しやすくなります。
Relation、Status、Dashboard、Automation を一つ追加するたび、機能が一つ増えるだけではありません。将来、誰かが理解し、修正し、更新し続けなければならない仕組みも一つ増えます。
テンプレート関連の議論で出てきた「最後には、そのシステム自体を維持しなければならなくなる」という問題は、企業 Workspace にもそのまま当てはまります。
そのため、新しい業務フローを設計するときは、次のような問いを最初から入れておくと実用的です。
このシステムを作った人が半年後に退職しても、ほかの人が理解できるか。データ量が現在の10倍になっても Formula と Dashboard は使えるか。Integration が止まったとき、コア業務まで停止しないか。
こうした問いは、「もう一つきれいな View を作れるか」より、システムが長く使えるかを判断する材料になります。
システム全体が限界になるまで待たず、どのデータを移すか先に決める
Notion からすべてを移行する必要はありません。
最初の Reddit 投稿者自身が考えているのも Split です。Docs／Wiki は Notion に残し、Operational Half だけを複雑なデータや権限に向いたシステムへ移す。
コメント欄でも、CRM が大きくなりすぎたなら CRM だけを移し、一つの業務フローに制限が出たからといって会社全体のナレッジベースを作り直す必要はないという意見が出ています。
実際には、まだ問題なく動いている段階から各システムの Source of Truth を決めておくほうが重要です。
顧客マスターデータは Notion なのか CRM なのか。Engineering Issues は GitHub／Linear なのか Notion なのか。ドキュメントはどこに保存するのか。どのデータは単なる同期表示なのか。
こうした境界線を先に決めておけば、将来一部のレイヤーを移す必要が出たとき、すべてを一度に解体せずに済みます。
Notion には「50人を超えたら向いていない」という明確な線はありません。
今週話題になった3年間利用しているユーザーの「50人超」という経験は、むしろ Workspace のアーキテクチャに負荷が見え始めたタイミングと考えるほうが適切です。
CRM が大きくなり、承認フローが増え、Tracker により多くのロジックが入り、本来ドキュメントツールとして快適だった Notion が、少しずつ業務システムそのものを担うようになった。
Notion 公式のパフォーマンス資料でも、大規模 Workspace を重くする要因として挙げられているのは、データ量、Properties、Formula／Rollup の参照、Filters、同時に読み込む Databases であり、単純な Member 数ではありません。
だから問いを「Notion は Company OS になれるのか」にする必要はありません。
Workspace のそれぞれのレイヤーが何を担当しているかを確認するほうが実用的です。
ドキュメントと会社ナレッジがうまく機能しているなら、そのまま残す。CRM、エンジニアリング管理、承認フローがすでに多くの補助ロジックを必要としているなら、その部分だけ専用システムと比較する。
本当に移行が難しくなるのは、一つの Database が大きくなったときではなく、数年後に誰も「どのシステムのデータが正式な情報なのか」を説明できなくなったときです。
よくある質問 FAQ
いいえ。50人を超えたというのは、今回の Reddit 投稿で一つのチームが Workspace の負荷を感じ始めたタイミングです。Notion は「50人」という利用上限を公表していません。
公式が挙げているパフォーマンス要因は主に Database Pages、Properties、Formula／Rollup、Filters、Sorts、同時に読み込む Database 数などです。そのため、実際の限界はチーム人数ではなく、Workspace の構造とデータ量によって変わります。
今回の事例では、CRM、Approval Flow、複数のロジック付き Tracker で負荷が出ています。
別の小規模エージェンシーでは、Automated Burndown、Budget vs Actuals、PMO 指標が必要になった段階で Notion を再評価していました。
これらは個別ユーザーの経験であり、すべてのチームに当てはまるわけではありません。ただし共通しているのは、業務フローが固定されたデータモデル、細かな権限、Automation、管理レポートを必要とする段階に入っていることです。
いいえ。Business と Enterprise では Database page-level access が利用でき、Person Property や Created by Property を使って、特定の Database Pages に対する View、Comment、Edit の権限を設定できます。
さらに Can edit content や Can create といった権限もあります。
ただし、この権限モデルが専用 CRM の代わりになるかどうかは、必要なアクセス制御の複雑さによって変わります。
現在の公式機能では、完全な Notion Calendar App をネイティブな Block として通常の Notion Page に埋め込む方法は提供されていません。
Notion Database 自体には Calendar View があり、Database を独立した Notion Calendar App に接続することもできますが、この二つは別のインターフェースです。
まず確認したいのは3つです。
日常業務で大量の Properties、Relations、Dashboard を手動更新していないか。コア業務を成立させるために第三者 Automation へ強く依存していないか。複雑な Formula、Rollup、Filter、大量の Views によって Database が遅くなっていないか。
システム自体を維持するために使う時間が増え続けているなら、さらに機能を追加する前に、一部の業務フローを専用システムへ分離する価値があります。