目錄
本記事の情報は2026年8月時点のものです。Redditでの報告はいずれも個別ユーザーの使用経験であり、すべてのアカウントに共通する固定の利用量として扱うことはできません。
今週のr/Notionでは、かなり直接的な質問が投稿されました。日常的にNotion AI Agentを大量に使った場合、どのくらいで上限に達するのか、という内容です。投稿者は一般的な質問、Workspace内の情報検索、文書内容のDatabaseへの移動、既存データの整理などに使いたいと考えていました。コメントにはすぐにまったく異なる回答が集まりました。毎日かなり大きな作業をしていても今まで上限に達したことがないという人もいれば、忙しい日は20〜30回ほど問い合わせると制限に達するという人もいます。DeepSeek v4で50回以上問い合わせても、6時間の上限に達しなかったという報告もありました。
これらの報告だけでも、よくある一つの誤解は外せます。Notion AIは「1回質問するたびに固定で1回分消費する」仕組みではありません。どのモデルを使うか、タスクの内容、Context、作業方法などによって使用量は変わる可能性があり、Notionは現在、Personal Agentの各操作がusage percentageへどう換算されるのかという固定公式を公開していません。公式が明らかにしているのは、Personal Notion Agentには6時間ウィンドウと月間allowanceの両方があること、そして関連する作業をまとめる、同じThreadを使い続ける、要求を明確に書く、タスクに合ったモデルを選ぶことで不要な消費を減らすよう勧めていることです。
同じ週には「Everyone’s mad about Notion AI limits but…」というタイトルの別の投稿もありました。ただし、実際に扱っていたのはAI利用上限ではなく、Notion Automationsへの不満です。投稿者は、日付を起点にした一部の基本的なワークフローが今も作りにくいと感じていました。この2つを並べて見ると、単純に「AIの利用枠は足りるのか」と考えるより興味深い点が見えてきます。現在のNotionにはPersonal Agent、Custom Agents、Database Automations、Buttons、Workersが同時に存在しており、すべての仕事を同じツールへ渡す必要はありません。
この記事ではNotion AIで何ができるかをもう一度紹介するのではなく、それぞれの仕組みを分けて、どの作業に本当にAgentが必要なのか、どれなら通常のAutomationのほうが直接的なのか、そして利用枠が限られているときにワークフローをどう組み直せるのかを整理します。
Notion AI Agentはなぜ20回で上限に達する人と、50回以上使っても平気な人がいる？
Personal Notion Agentは「1 Prompt＝固定1回消費」ではない
Notionでは現在、Personal Notion Agentに2段階のusage allowanceが設定されています。1つ目は6時間ウィンドウで、このウィンドウが更新されると使用量もリセットされます。2つ目はBilling Cycle全体に対する月間利用枠で、こちらは次のBilling Cycleに入ったときにまとめてリセットされます。Personal Agent Chat、画像生成、Page Translation、Skillsはいずれもこのallowanceに含まれます。
公開されていないのは、具体的な換算式です。Notionは「1ページ検索すると何％」「10ページ読むと何％」「1回のAgent Actionは普通のPrompt何回分」といった数値を公開していません。そのため、r/Notionで「20〜30 queriesで上限に達した」という人と、「50+ queriesでもまだ大丈夫だった」という人がいても、両者は矛盾していません。単に利用状況が異なるだけです。
コメント欄では、モデル選択による違いを示すような報告も見られます。あるユーザーは主にKimi K3で作業しており、まだNotion AIの上限に遭遇していないとしています。別のユーザーは普段DeepSeek v4を中心に使い、50回以上問い合わせても6時間制限に達していないと報告しています。一方で、より高性能なモデルを使用したところ、午前中だけでallowanceのかなりの割合を消費したという人もいます。これらもReddit上の個別事例なので、固定のモデルコスト表を作る材料にはできません。ただし、「何回質問したか」は比較単位としてあまり適切ではないことは分かります。
公式が実際に勧めているのは「質問回数を減らす」より「やり直しを減らす」こと
Notion自身が案内している利用量の節約方法は、かなり参考になります。1つ目は関連作業を同じPromptへまとめ、何度も往復しないこと。2つ目は同じThreadで作業を続け、Agentがすでに存在するContextを使えるようにし、毎回最初から処理させないこと。3つ目は最初からGoal、Success Criteria、出力形式を明確に伝えること。4つ目はタスクごとにモデルを選び、Quick Edit、要約、FormattingなどにはEfficient Modelを使い、最も強いモデルは複雑な推論やMulti-step Workへ残すことです。
これは、元の原稿にあった「大きな仕事をたくさんの小さな仕事へ分割する」という考え方を少し修正する必要があることも意味します。本当に分けるべきなのは作業範囲であって、同じ仕事を十数個の独立Promptへ細かく分割することではありません。
例えば「この四半期の全部を整理して」は確かに曖昧すぎます。「Projects Databaseの中から7月1日以降更新されておらず、StatusがIn progressの項目だけを確認し、Name、Owner、Last edited dateを一覧にする」と範囲を絞ったほうがよいでしょう。ただし、条件、データソース、出力形式はできるだけ1回で伝えたほうがよく、「まずプロジェクトを探して」「次に日付を見て」「次にOwnerを探して」と分けて聞くと、かえってやり取りが増えます。
Custom Agentsの消費ロジックは比較的透明｜多く読み、多く処理し、高頻度で動かすほど高くなる
ここでは本当に「1つの指示の裏で多くの処理が走る」と言える
Personal Agentのallowanceには公開された換算表がありませんが、Custom Agentsは異なります。NotionはCreditsに影響する4つの主要要素を明確に公開しています。Agentがどれだけ多くのコンテンツを読むか、何ステップ実行するか、どのくらい頻繁にTriggerされるか、そしてどのモデルを使うかです。長いページを読み、多くの情報を検索し、大きなDatabaseをスキャンするほど通常はより多くのCreditsを使います。Tool CallsやMulti-step Workflowが増えれば、1回のRunも高くなります。
そのためCustom Agentについては、「1つの指示＝固定消費1回ではない」とはっきり言えます。
同じ「1件の顧客フィードバックを処理する」という仕事でも、簡単なバージョンならSlackメッセージを1件読み、Ownerを1回確認し、Taskを1件作るだけかもしれません。複雑なバージョンでは、製品ドキュメントを検索し、対象領域を判断し、過去の履歴を読み、Taskを作り、CRMを更新し、さらにSlackへ通知するかもしれません。表面上はどちらも「顧客フィードバックを処理する」だけですが、実際のCredit使用量は当然異なります。Notion公式も、これに近い例を使ってCustom Agentのコスト差を説明しています。
Databaseが大きいほどCustom Agent Creditsが増える可能性はあるが、「Workspaceが散らかっているほど高くなる」は慎重に書くべき
Notion公式で確認できるのは、Custom Agentがより多くのContentを検索し、より長いPagesを読み、より大きなDatabasesをスキャンする必要がある場合、通常はより多くのCreditsを使うという点です。
このルールから、もともと1つのDatabaseだけ読めば済む仕事が、情報が分散しているため5つのデータソースを検索する必要があるなら、コストが上がる可能性があると推測することはできます。ただし、「ページ名が統一されていないとAI利用枠が直接増える」と示す公式テストデータはありません。Personal Agentについては、Workspaceを整理すればallowanceが必ず減ると証明できる公開公式もありません。
そのため、Workspaceを整理する価値はありますが、理由は正確に書く必要があります。データソースが明確で重複が少なければ、Agentが検索範囲を限定しやすくなり、回答の検証もしやすくなります。Custom Agentsについては、その結果として実際に読む量や検索量が減った場合に、初めてCreditコスト上の意味が生まれます。
Personal Notion AgentとCustom Agentsは完全に別々の利用枠ではない
Personal AgentはまずAllowance、Custom Agentsは最初のRunからCreditsを消費する
現在の計算方法を整理すると、次のようになります。
| 機能 | 最初の計算方法 | 上限到達後 |
|---|---|---|
| Personal Notion Agent | 6時間＋月間Usage Allowance | リセットを待つ。管理者が許可している場合はNotion Creditsを利用可能 |
| Custom Agents | 各Runで最初からNotion Creditsを使用 | Credits不足後は停止 |
| Workers | Notion Creditsを使用 | Credits制度に従う |
| AI Meeting Notes | 独立した1日10時間上限 | Personal Agent allowanceは使用しない |
そのため、元の原稿にあった「2つの制度はつながっていない」という説明は正確ではありません。より適切なのは、「最初の計算方法は違うが、Notion Creditsが両者の接点になる」という説明です。
Personal Agentは通常、まずプランに含まれるallowanceを使用します。Workspace管理者がAllow workspace to use Notion credits after AI limit is reachedを有効にしている場合、Personal Agentがallowanceへ達したあともNotion Creditsを使って継続できます。Custom Agentsにはこの内包allowanceがなく、タスクの実行開始時から直接Creditsを消費します。
これがRedditの議論が混乱しやすい理由でもあります。「まだlimitに達したことがない」という人はPersonal Agentについて話しているかもしれませんし、「300 Creditsを2日で使った」という人はCustom Agentの話をしているかもしれません。どの機能を指しているのか確認せず、「AI利用枠」という言葉だけで比較してもほとんど意味がありません。
どの仕事をNotion Agentへ残すべき？ポイントは「検索か書き込みか」ではなくWorkspace Contextが必要かどうか
一般的な質問は外部へ移せるが、「検索が必ず最も利用量を消費する」からではない
元のReddit投稿者が挙げていた用途には、General chats/questions、Workspace Search、DocumentsからDatabasesへのデータ移動、Database Entriesの整理などがありました。
Notion内のデータとまったく関係のない質問、例えば概念の説明、一般的な翻訳、1文だけの修正などで、すでにほかのAIツールを契約しているなら、こうした仕事を外部ツールへ任せ、NotionのallowanceはWorkspaceを読む必要がある作業へ残すことはできます。
ただし、そこからさらに「Notion AIを検索エンジンとして使うのが最も高コストで割に合わない」と書くことはできません。Workspace SearchはもともとNotion Agentの中核用途の一つで、公式も「Notion、Slack、Google DriveなどのConnected Toolsから答えを探す」ことを正式な利用例として挙げています。
検索でも軽いものはありますし、書き込みでも数十ページを読んだうえでMulti-stepの変更が必要になる場合があります。より適切な分流基準は「検索 vs 書き込み」ではなく、次の3つです。
- この作業にはNotion内のContextが必要か？
- 実行範囲を限定できるか？
- 最終結果を簡単に検証できるか？
3つとも明確であるほど、Agentは通常コントロールしやすくなります。
映画Databaseの事例は良い例だが、元の方法は「Notionへ直接伝える」ではない
同じ週の別の投稿には、範囲の狭いタスクとして非常に分かりやすい例がありました。投稿者は長年自分のMovie Databaseを管理しており、以前は映画を見るたびに自分で情報を検索し、Notionを開き、Genre、Year、Ratingを入力し、さらにMovie Calendarへ紐づけていました。しかし、その維持作業が次第に続かなくなっていました。
現在はChatGPTへ「映画タイトル－3 stars」のように直接伝え、その後Notion Plugin／Integrationを通じてGenre、Release Year、Ratingなどの情報を元のNotion Databaseへ書き込んでいます。
したがって、これは「Notionに直接見た映画を伝える」という事例ではありません。実際の構成はChatGPT＋Notion integrationです。
ただし、Agent-friendly Taskの例としては非常に分かりやすいケースです。入力は短く、書き込み先Databaseは固定され、Propertiesも定義済みで、最後に映画名、公開年、評価が正しく入っているか簡単に確認できます。投稿者自身も、最大の変化は複数の手作業を1つのメッセージへ縮めたことで、更新を諦めかけていたDatabaseを再び維持できるようになったことだと説明しています。
「Workspace全体を整理して」のように明確な終了条件がない仕事より、はるかにコントロールしやすいタスクです。
固定ルールならAgentが不要な場合もある｜Automationsは別に考えるべきツール
「Everyone’s mad about Notion AI limits but…」は実際にはAutomationsへの不満だった
今週のその投稿は、タイトルだけを見るとAI利用枠について擁護しているように見えますが、本文はまったく別の話でした。投稿者が本当に問題だと感じていたのはAutomationsで、「Contract Due Dateになったら自動的に次のTaskを作る」といった要件に対し、十分直接的なNative Workflowがないと指摘しています。
「完全に不可能」という表現は少し絶対的すぎます。Notionには現在、Page added、Property edited、Every {frequency}といったDatabase Automation Triggersがあり、Repeating Database Templates、Formulas、Date Remindersもあります。Formulaではnow()を使ってDue Dateがすでに過ぎているかを判断できます。
ただし、投稿者の中心的な不満は残っています。現在も「Databaseの各Rowがそれぞれ設定されたDateへ到達した瞬間、自動的に任意のWorkflowを起動する」という直感的なTriggerはありません。Recurring Automationは固定時刻で動き、Property EditedはPropertyが変更されるのを待つため、「時間が自然に進み、そのRowの日付へ到達する」こととは完全には同じではありません。
明確なルールでできることなら、推論するAgentへ最初から渡す必要はない
これはAI利用枠を考えるうえで重要な境界です。
「毎週月曜日にWeekly Reviewを作成する」「Buttonを押したらStatusをApprovedへ変更する」「毎月新しいInvoice Recordを作る」といった要件なら、Repeating Templates、Buttons、Database Automationsで十分な場合があります。ルールが明確で、大規模モデルに判断させる必要もありません。
文章を読み、その意味を判断し、複数のデータソースを比較したり、Contextに応じて次の行動を選んだりする場合に初めて、Agentの強みが出てきます。
Notionはこの違いをWorkersの設計にも反映しています。公式によると、WorkersはAI decision-makingを必要としないdeterministic workに適しており、1回あたりのコストもCustom Agentsよりかなり低く設定されています。
そのため、利用枠が限られている場合、「どうPromptを書けば節約できるか」より先に考えるべきなのは、「そもそもこの仕事にAIの判断が必要なのか」です。
Notionは整理に強いが長文を書きにくい？それはAI利用枠ではなく作業インターフェースの問題
同じ週には、ResearchをNotionに残してDraftだけ別ツールへ移す人もいた
別の今週の投稿は、Projects、Research、Reading Notes、Content Calendars、Meeting NotesのほとんどをNotionへ入れているユーザーによるものでした。Databaseと整理機能は非常に便利だと感じている一方、本格的に数段落以上の文章を書こうとすると、Sidebar、Database Context、そして「これは一つのシステムである」という全体的な感覚がかえって執筆を不自然にするため、Draftだけ専用のWriting Appへ移し、Researchと整理はNotionへ残しているとしています。
コメント欄にも似た分業をする人がおり、NotionをWriting Organization Layerとして使い、実際の記事本文はEllipsusへ置いているという声がありました。一方で、別のユーザーはこの意見に直接反論し、毎日Notionで文章を書き、本1冊を丸ごとNotionで書き上げたが、まったく同じ問題を感じないとしています。
そのため、「Notionは整理には強いが書けないし、AIでも解決できない」と断定するのは強すぎます。これはどちらかといえばインターフェースの好みです。専用のWriting Environmentが必要な人もいれば、Notionだけでまったく問題ない人もいます。
残しておく価値があるのは、「1つのツールにすべての工程を担当させる必要はない」という考え方です。ResearchとDatabaseがNotionでうまく機能しているからといって、Draftまで必ず同じ場所へ置く必要はありません。反対に、Notionで長文を書くのが好きではないからといって、Knowledge Base全体を別サービスへ移す必要もありません。
「Notionは最大の生産性詐欺」という投稿が問題にしていたのは、AIコストではなく維持コスト
同じ週の別の投稿はかなり強いタイトルで、「Notion is probably the biggest productivity scam」と書かれていました。ただし本文でNotionを詐欺だと告発しているわけではありません。投稿者が気づいたのは、生活をもっと楽に整理したかったはずなのに、いつの間にかDashboardを変えるべきか、Databaseをもう一つ作るべきか、Layoutをもう一度整理するべきかと考えることに大量の時間を使い、本当に終わらせるべき仕事が進まなくなっていたことです。
この事例をAgent利用枠の話と結びつけることはできますが、接点は少し修正する必要があります。
「Workspaceの構造が複雑だからAIが必ず高くなる」とは直接言えません。両方に共通して言えるのは、システムに明確な境界がない場合、人でもAgentでも不要な作業を増やしやすいということです。
人はDashboardを何度も整理し、Agentはタスク範囲が広すぎると、より多くの情報を検索し、より多くのステップを実行する可能性があります。Custom Agentsでは後者が実際にCredits増加につながります。Personal Agentについては、Notionが差を定量化できるほどの情報を公開していません。
Notion AIの利用枠が限られているなら、まずワークフローをこう組み直す
第1段階：まず「Workspace Contextが必要」か「必要ない」かを分ける
会社のProjects、Meeting Notes、CRM、Slack、Google Drive内の情報を知っている必要がある仕事なら、Notion Agentへ残す理由があります。Notion Agentは現在のPage、Workspace、Connected AppsをContextとして使えるからです。
一方、一般的な質問、単純な文章修正、Workspaceに依存しない内容で、すでに別のAIツールを持っているなら、そちらへ移すこともできます。これはNotionが必ず高いからではなく、Workspace Accessという価値を持つallowanceを同時に消費する必要がないからです。
第2段階：タスク範囲を小さくするが、関連作業は同じPromptとThreadへまとめる
「Workspace全体を整理する」から始めないようにします。
例えば、「このProjects Databaseだけを見る」「8月以降のデータだけ確認する」「Status、Owner、Next Stepだけ返す」と範囲を限定します。範囲が明確になるほど、Agentもどこまで処理すれば終了なのか判断しやすくなります。
ただし、同じ仕事を十数個の独立Promptへ分割するのも避けます。Notion公式はむしろ、関連作業を同じPromptへBatchし、同じThreadを使ってContextの再処理を減らすことを推奨しています。
第3段階：固定ルールならAutomations・Buttons・Workersでできないか先に確認する
実行条件を明確なIf／Thenで書けるなら、最初からAgentへ考えさせる必要はありません。
決まった時間に固定ページを作るならRepeating Template、ユーザーが明示的に一連の固定操作を実行したいならButton、Propertyが特定の状態へ変わったときに処理したいならDatabase Automationが使えます。本当に文章の意味を解釈したり、複数の情報源を検索したり、判断を行ったりする場合にAgentへ切り替えます。
この段階はCustom Agentsで特に重要です。読む量、Tool Call、実行頻度が増えるほどCreditsが増えることは、公式が明確に説明しています。
第4段階：すべての質問で最も強いモデルを選ばない
Notion公式はすでに、Quick Edits、Summaries、FormattingにはEfficient Modelを使い、最も強いモデルはHigh-stakes Writing、Complex Reasoning、Multi-step Workへ残すよう直接勧めています。
今週のReddit報告ともおおむね一致しています。一般的な作業にはDeepSeek、Kimi、GLM、Lunaなどを使い、必要なタスクだけより重いモデルへ切り替えているユーザーがいます。これらは公式の価格比較として使えるものではありませんが、実際のユーザーがモデルを階層化している例として見ることはできます。
第5段階：Query CountではなくUsageを見る
Personal AgentはSettings → Notion AI → Usageから、6時間と月間の使用量を直接確認できます。上限へ近づいたときや到達したときにはNotionから通知も表示されます。
Custom AgentsではNotion Credits Dashboardを見るべきです。作成者と管理者は各Runが実際に何Creditsを使ったのか確認できます。Notion公式も、Custom Agentsを導入したばかりのチームに対して、まずUsage Historyを観察し、実際の実行データをもとに必要なCredits量を判断するよう勧めています。
「今日は25回質問した」と数えるより、こちらのほうがはるかに役立ちます。同じ25回でも、使ったモデルや処理量がまったく異なる可能性があるからです。
Notion AIの新しい利用枠制度で最も誤解しやすいのは、すべてのAI操作を同じRequestとして考えてしまうことです。実際にはPersonal Agent、Custom Agents、Automations、Workersはすでに異なる実行メカニズムです。Personal Agentのallowanceには正確なコスト公式が公開されていません。Custom Agentsは読む量、ステップ数、頻度、モデルによってCreditsが計算されます。固定ルールを扱うAutomationsやWorkersは、また別のコスト構造です。
そのため、利用枠が限られたときに有効なのは、単純に「AIをあまり使わない」ことではありません。まずその仕事にWorkspace Contextが必要なのか、モデルによる判断が必要なのかを確認し、そのうえでPersonal Agent、Custom Agent、通常のAutomationのどれへ任せるか決めるほうが、Promptを送るたびに残り何％か推測するより現実的です。
Workspaceを整理する価値は引き続きありますが、「WorkspaceがきれいになるほどPersonal Agentの利用量が必ず減る」という、現在まだ証明されていない公式のように表現する必要はありません。より確実に言えるのは、データソースが明確なほどタスク範囲を限定しやすいことです。Custom Agentsについては、その結果として本当に読むページ数、検索するデータソース、実行ステップが減った場合に初めて、節約されたCreditsがDashboard上の数字として表れます。
よくある質問 FAQ
Personal Notion Agentは、公開された固定の「1 Prompt＝1回消費」という方式では計算されていません。Notionは完全なallowance換算式を公開しておらず、Redditユーザーが使用しているモデル、タスク、Contextも異なります。そのため、Query Countだけを直接比較することはできません。
最初の計算方法は異なりますが、完全に分離しているわけではありません。Personal Notion Agentはまず6時間と月間のallowanceを使用します。管理者が許可している場合、allowanceを使い切ったあとにNotion Creditsを継続利用できます。Custom Agentsは最初のRunから直接Notion Creditsを使用します。
Custom Agentsについては、多くのContentを読み、多くの情報源を検索し、大きなDatabaseをスキャンするほど通常はCreditsが増えることが確認されています。そのため、実際の読み取り範囲を縮小できればコスト面で意味があります。一方、Personal Agentについては、「ページ名を整えるとallowanceが直接減る」と証明できる十分な公式データは公開されていないため、固定ルールとして説明するのは適切ではありません。
「書き込みは検索よりお得」といった単純なルールはありません。Workspace Contextが必要で、範囲が明確で、結果を検証しやすいタスクが適しています。例えば、指定した文書から情報を抽出して固定Databaseへ入力する、指定範囲内のプロジェクト状況を整理するといった作業です。Workspaceのデータをまったく必要としない一般的な質問なら、すでにほかのAIツールを利用している場合はそちらへ移すこともできます。
単純に細かく分割するのはおすすめできません。よりよい方法はタスク範囲を縮小しつつ、1つのPrompt内でデータソース、条件、出力形式を明確に伝え、同じThreadを使い続けることです。Notion公式もBatch Related WorkとReuse Contextを推奨し、Contextの重複処理を減らすよう案内しています。
必ずしも必要ではありません。ルールを明確なTriggerとActionとして書ける場合は、Database Automations、Buttons、Repeating Templates、Workersのほうが適していることがあります。文章を読み、意味を判断し、複数のデータソースを横断して意思決定する必要がある場合にAgentを検討します。