目錄
本記事の情報は2026年8月時点のものです。Notionは、今後も利用枠の大きさ、計算方法、対象機能を変更する可能性があるとしています。
Notion AIの新しい利用制度は2026年8月3日に開始され、r/Notionでは、もう一つ注目すべき利用報告が出始めています。一部のユーザーは月間利用枠を使い切る前に、別の上限へ先に到達しています。あるBusinessユーザーは、4つのドキュメントページを整理しただけで、内容をスキャンし、改善案を出し、その後一連の整理作業を実行したところ、4ページを終えた時点で6時間利用ウィンドウの上限に到達したと報告しています。その時点で月間利用枠の消費はまだ19％でした。この二つの数字が同時に出ていることは、「19％使った」という数字だけを見るより参考になります。現在のNotion AIには月間総量だけでなく、短時間の利用量と請求サイクル全体の総量という二種類の制限が同時に存在するからです。
すでにNotion Agentを文書整理、執筆、データベース作業へ組み込んでいるユーザーは、今後「1か月でどれだけ残っているか」だけではなく、作業をどの時間帯に集中させるかも管理する必要があります。この二つの上限は、到達したときの対応方法も完全には同じではありません。さらにNotionは現在、パーセント表示が何Token、何回のモデル呼び出し、何ドル分のコストに相当するのかを公開していないため、コミュニティは実際の利用事例からおおまかな消費パターンを探っている段階です。
Notion AIには実際に二つの利用上限がある：6時間ウィンドウと月間利用枠
月間利用枠は請求サイクル全体でどれだけ使ったかを見る
月間利用枠は、ここ数日r/Notionで最もよく見かけるパーセント表示です。例えば「1営業日で31％使った」「3日で34％使った」といった数字は、すべてこの層を指しています。Notion公式の説明では、月間ウィンドウはワークスペースのbilling cycleに沿って計算され、次の請求サイクルが始まると一度にリセットされます。月間利用枠を先に使い切った場合、対象となるNotion AI機能は次のbilling cycleまで一時停止します。ただし、ワークスペース管理者がNotion Creditsによる継続利用を有効にしていれば、そのまま利用を続けることもできます。
このパーセントは長期的な利用ペースを見るのに向いています。例えば月初の数日だけで30％を消費しているなら、同じ使い方を続ければ月末前に上限へ達する可能性が高いと判断できます。ただしNotionは、100％が何Token、何回の固定リクエストに相当するのかを公開していません。そのため、「1日10％なら毎日○回使える」と単純計算することはできません。同じパーセントでも、タスク、モデル、読み込むデータ量、実行ステップによって実際の作業量は大きく変わる可能性があります。Notion公式が現在示している対策も、タスクの規模に合ったモデルを使う、Contextの重複処理を減らす、最初から要件をまとめて伝える、といった内容にとどまっています。
6時間ウィンドウは短時間に集中して使える量を制限する
もう一つが6時間ウィンドウです。Notion公式では現在これをsix-hour windowと呼び、ダッシュボード上の短期利用状況についてはrolling usageという表現も使っています。このウィンドウが更新されると利用量はゼロへ戻ります。短時間でこの層の利用枠を先に使い切ると、月間利用枠がまだ大量に残っていても、個人用Notion Agent、AI画像生成、ページ翻訳、Skillsなどの対象機能が一時的に利用できなくなる可能性があります。
これが、「4ページを処理して月間利用率は19％」という投稿で最も興味深い点です。投稿者が行った作業は単純に4回質問しただけではなく、各ページについて文書内容をスキャンし、分析し、その後、提案された整理作業を実行するという流れでした。4ページが完了したところで短期ウィンドウは上限へ達しましたが、月間利用率はまだ19％でした。コメント欄では、同じBusinessプランを使う別のユーザーが、自分はさらに多くの作業をしているにもかかわらず月間利用率は12％しかないと報告しています。二人の差は、ワークフロー、Prompt、モデル選択、実行ステップ、ページ量などから生じている可能性があります。これも、4ページという数字そのものを「Notion AIは一度に4ページしか整理できない」という基準にしてはいけない理由です。
なぜ6時間ウィンドウと月間利用枠を別々に見る必要がある？
月間利用枠が81％残っていても、その時点では完全に使えないことがある
月間利用枠だけを見ていると、不思議な状況に遭遇することがあります。ダッシュボードではまだ8割程度残っているのに、Notion Agentが突然動かなくなるケースです。これは計算ミスではなく、もう一つの6時間ウィンドウが先に上限へ達した可能性があります。Notion公式でも、二つのウィンドウは同時に計算され、短期ウィンドウを使い切った場合は、更新されるまでプラン内のallowanceが再び使えるようにならないと明記されています。
つまり、月間利用枠が答えるのは「このbilling cycle全体でどれだけ余裕が残っているか」であり、6時間ウィンドウは「この時間帯にどれくらい集中して使えるか」に近い指標です。長時間続けて大量のページを整理したり、複数ステップのタスクを実行したり、集中的に文章制作をしたりすると、月間上限より短期上限のほうが先に現れる可能性があります。
ただし6時間上限に達しても、必ず6時間待つしかないわけではない
最も誤解されやすい点の一つが、Creditsは月間利用枠にしか使えず、6時間ウィンドウには使えないという考え方です。Notion公式の現在の仕組みはそうではありません。BusinessまたはEnterpriseのワークスペース管理者がSettings → Notion AIでAllow workspace to use Notion credits after AI limit is reachedを有効にしていれば、メンバーはプラン内allowanceを使い切った後、Notion Creditsへ切り替えて利用を続けられます。ウィンドウが自然に回復するまで待つ必要はありません。この設定はデフォルトではオフになっているため、Creditsを有効にしていないワークスペースでは待つ必要があります。
そのため、「月間利用枠が足りなければCreditsを買えるが、6時間上限は利用ペースを調整するしかない」という説明は完全には正しくありません。より正確には、追加でCreditsを使いたくない場合、短期上限には利用時間や作業方法を調整して対応することになります。一方、追加料金を払ってもよく、管理者がCreditsを有効にしている場合は、どちらの上限に達してもCreditsを使って継続できます。別途考える必要があるのは、それがコスト的に見合うかどうかです。
7日目には34％利用の報告も：Kimi K3 Max Effortを3日使うとどれくらい？
Businessプランで1日2〜4時間、3日で月間利用率34％
8月9日の別のr/Notion投稿では、かなり詳しい利用条件が共有されています。Businessプラン、Kimi K3、Max Effortを使用し、主にcreative writingを行い、1日約2〜4時間利用したところ、3日後に月間利用率が34％まで上がったというものです。投稿者はその結果、執筆作業をChatGPTへ戻し、完成した文章をGoogle Docsなどの文書ツールへ移すことを検討しています。
この数字は参考になりますが、「Kimi K3 Max Effortなら必ず3日で3分の1の利用枠を消費する」と結論付けることはできません。Redditの投稿は一人のユーザーの実際の利用環境だけを示しており、同じPrompt、同じ文書量、ほかのモデルとの比較対象はありません。現時点で言えるのは、このユーザーの使い方では消費ペースがかなり速かったということだけです。Notionも、モデルや推論強度ごとの固定消費倍率を公開していません。
「高性能モデル＋最高推論強度で消費が掛け算になる」という根拠はない
元の記事にあった「二つの消費が掛け算になる」という表現は削除する必要があります。現在確認できる情報では、モデル選択がallowanceの使用量に影響することは分かっており、Notion公式も、簡単な編集、要約、フォーマット整理にはより効率的なモデルを使い、高能力モデルは重要な文章作成、複雑な推論、複数ステップの作業へ残すよう勧めています。ただし、モデルそのものとMax Effortがそれぞれ何倍消費するのか、両者に固定された乗算関係があるのかについて、Notionは公開していません。
より現実的な確認方法は、固定した一つのタスクを選び、同じ入力データ、同じPromptでモデルや推論設定を変えてテストし、6時間と月間パーセントの変化を見ることです。こうしたテストでも、自分のワークスペースに限った経験値しか得られませんが、他人の34％という数字から自分のコストを逆算するよりは信頼できます。
RedditではBYOKを求める声も：上限到達後に自分のAPIキーを使えない？
BYOKを求める理由は無料化ではなく、別の支払い経路を残してほしいから
8月9日のr/Notionには、Usage credits - BYO keyというタイトルの議論も登場しました。コメントでは、Notionが内蔵AI利用量を制限するなら、少なくとも利用枠を使い切った後にBring Your Own Keyを使えるようにし、自分のAnthropic、OpenAI、そのほかのモデルAPIキーで継続できるようにしてほしいという意見が出ています。この要望の中心は、「Notionに無料で無制限AIを提供してほしい」というものではありません。同じワークスペースのインターフェースを維持したまま、別のモデル費用の支払い経路を選べるようにしてほしいというものです。
現在Notionには、個人用Notion Agentへ自分のモデルAPI Keyを直接入力するネイティブ機能はありません。新しいClaude Agentsの説明でも、Claude AgentsはNotion Creditsで課金され、自分のAnthropicアカウントへ切り替えることはできないと明記されています。一方でNotionはMCPを提供しており、Claude、ChatGPT、Cursorなど外部AIツールをNotionワークスペースへ接続し、外部ツール側からNotionの内容を読み書きできます。これはNotion AgentへBYOKする仕組みではなく、操作インターフェースそのものを外部AIツールへ移す方法です。この二つは区別する必要があります。
これが、コミュニティの一部でClaude＋Notion MCPへ移行する人が出ている理由でもあります。34％利用の投稿コメントでも、チャットインターフェースをClaudeへ移し、MCP経由でNotionを操作しているというユーザーがいました。ただし、MCPのほうが必ず安いという意味ではありません。費用は外部AIのサブスクリプションやAPIへ移り、Notion MCPの権限やプラン制限も考慮する必要があります。それでも別のワークフローとしては成立します。
AIをまったく使わないNotion Formulaが、ちょうど別のヒントを与えている
「2週間ルール」はFormulaだけで実現、Notion AIの利用枠を一切使わない
同じ日、r/Notionではまったく別タイプの人気投稿もありました。あるユーザーが、自分の映画・ドラマ管理用トラッカーに「2-week rule」というFormulaを作った事例です。作品を見終わった後は14日間のクールダウン期間に入り、Formulaが評価できるまで残り何日かを表示します。14日が過ぎるとReady to rateへ変わります。まだ視聴中の場合や、連載作品で最新話まで追いついていない場合は、評価できない状態を維持します。このロジック全体はStatus、Caught Up、Finished Onという三つの項目とNotion Formulaだけで実現されており、AIは一切呼び出していません。
この投稿自体はAI利用上限問題とは直接関係ありません。ただ、同じ週の話題として見ると示唆があります。Notionで実用的なワークフローの多くは、もともとFormula、Relation、View、Button、Automationの上に作られてきました。要件が「固定条件を満たしたら特定の結果を表示する」というものなら、大規模言語モデルに判断させる必要は通常ありません。こうした処理をルールベースの機能へ残せば、AI allowanceを消費しないだけでなく、出力も予測しやすくなります。
6時間上限に達した後、Notion AIの使い方をどう調整する？
大きな作業を大量のPromptへ分割するのではなく、「同じ会話」と「別時間帯」を分けて考える
1日の午後に大量のページをスキャンすることが多い場合、最初に思いつくのはタスクを細かく分割することかもしれません。ただし、ここにはもう一段判断が必要です。Notion公式はむしろ、関連作業をできるだけ一つのPromptへまとめ、同じ会話の中で既存Contextを再利用することを推奨しています。毎回背景を最初から説明し直すと、追加処理が増える可能性があるからです。
そのため、より適した方法は「20ページ整理」を20個の独立した新規会話へ機械的に分けることではありません。急ぎでなければ、複数のバッチを別々の6時間ウィンドウへ分散し、同じバッチ内では目的、範囲、出力形式をできるだけ最初にまとめて伝えるほうが合理的です。これなら短期利用ペースを調整しながら、Promptを分けすぎてContextを何度も読み直す問題も避けられます。
よく使う作業ごとに「必要モデル表」を作る
高性能モデルを使ってはいけないわけではありません。重要なのは、どの仕事に本当に必要なのか分かっていることです。複数文書にまたがる矛盾チェック、大量の推論が必要な調査、重要な対外文書などには高能力モデルを残し、タイトル修正、フォーマット整理、定型内容の要約などは、より効率的なモデルから試すことができます。Notion公式も同じ方向で、すべての作業に最も強いモデルを固定するのではなく、タスク難易度に合わせてright-size modelを選ぶよう勧めています。
利用頻度が高い場合は、1週間だけでも、タスク種類、使用モデル、推論設定、作業前後の6時間パーセント、月間パーセントを記録してみるとよいでしょう。Notionが固定倍率を公開していない以上、自分の利用状況から作った小さな記録のほうが実用的です。
まず一度、「これは本当にAIの判断が必要か？」と確認する
要件を「AならBを表示する」「日付から14日経過したらステータスを変える」「フィールド更新後に別Viewへ移す」のように明確なルールとして書ける場合、Formula、Button、Database Automationのほうが適しています。NotionのデータベースAutomationは、指定条件が発生した後に決められた処理を実行できます。Formulaも日付、条件分岐、文字出力を処理でき、個人用Notion AIのusage allowanceを消費しません。
Notion Agentへ残す価値が高いのは、自然言語の理解、複数のワークスペース情報の読解、固定できない内容の判断、新しいコンテンツ生成などが必要な作業です。これは単に利用枠を節約するためではありません。確定的な仕事は確定的なツールへ任せ、ルールとして固定できない部分だけをAIに担当させるという設計です。
Notion AIの新しい利用制度が導入されて6日が経過し、コミュニティに集まった事例から、月間利用枠だけが作業を止める制限ではないことがかなり見えてきました。4つの文書を整理しただけで6時間ウィンドウへ到達しながら月間利用率は19％だった例と、Kimi K3 Max Effortを3日間長時間使って月間利用率が34％になった例では、利用方法がかなり異なります。それでも共通しているのは、「表示されるパーセントから事前に実際の作業量を換算しにくい」という問題です。
現時点で現実的なのは、数件のReddit投稿から万能な利用量公式を作ろうとすることではありません。まず、自分が到達したのが6時間ウィンドウなのか月間ウィンドウなのかを確認し、その後で、作業時間帯を変える、モデルを切り替える、固定ロジックをFormula／Automationへ戻す、Creditsを有効にして継続する、といった選択肢を考えることです。Notionはすでに二つのパーセントをUsageダッシュボードへ表示していますが、モデルとタスクの換算方法が公開されない限り、この試行錯誤の期間はしばらく続きそうです。
よくある質問 FAQ
6時間ウィンドウは短時間のうちに対象Notion AI機能をどれだけ使えるかを制限し、ウィンドウが更新されると使用量はゼロへ戻ります。一方、月間利用枠はbilling cycle全体の利用量を累積し、次の請求サイクルが始まるとまとめてリセットされます。両方が同時に計算されるため、月間利用枠が大量に残っていても、6時間上限へ先に到達する可能性があります。
このReddit事例では、単純に4ページを読むだけではなく、各文書をスキャンし、整理案を作り、その後一連の処理を実行していました。その結果、4ページ終了時点で6時間ウィンドウが上限へ達し、月間利用率は19％でした。これはそのユーザーのワークフローで起きた結果であり、Notion AIが一般的に4ページまでしか処理できないという意味ではありません。
必ずしもそうではありません。BusinessまたはEnterpriseのワークスペース管理者が、AI上限到達後にNotion Creditsを使う設定を有効にしていれば、メンバーはCreditsへ切り替えてそのまま利用を続けられます。有効にしていない場合は、6時間ウィンドウが更新されるまで待つ必要があります。このCredits継続設定はデフォルトではオフです。
現在確認できるのは、BusinessプランでKimi K3 Max Effortを使い、1日2〜4時間creative writingを行ったユーザーが、3日後に月間利用率34％になったという事例です。Notionはモデルや推論強度ごとの固定消費倍率を公開していないため、この一例だけからKimi K3 Max Effortがすべてのユーザーで同じ速度で利用枠を消費すると判断することはできません。
現在、個人用Notion AgentにはネイティブのBYOK機能はありません。新しいClaude Agentsについても、自分のAnthropicアカウントではなくNotion Creditsで課金されると明記されています。別の方法としてNotion MCPを使い、Claude、ChatGPT、Cursorなど外部AIツールをNotionへ接続することはできますが、これはNotion Agentへ直接API Keyを入力する仕組みとは異なります。