目錄
この記事の情報は、2026年8月時点のものです。Notion AIのモデル一覧、利用ルール、Creditsの料金体系は今後も変更される可能性があります。実際の設定は、各ワークスペース内に表示される内容を確認してください。
Notion AIの利用上限が2026年8月3日に適用されて以降、モデル選択は単なる好みの設定ではなく、コスト管理の問題になりました。利用者は回答品質だけでなく、6時間のローリング利用枠、月間利用枠、追加のNotion Creditsがどのように消費されるかも判断しなければなりません。問題は、モデル選択画面に「複雑な推論」「高度な推論」「バランス型」など、似た説明しか表示されないことです。公式も、各モデル、プロンプト、ツール操作に対する固定の換算表を公開していません。導入翌日にr/Notionへ投稿された不満は、この問題を端的に表しています。制度上は利用者へ節約を求めているのに、インターフェースには一度のタスクでどの程度の利用枠を消費するのか判断できる十分な情報がありません。
Notion AIの利用上限はどう計算される？6時間枠・月間枠・Notion Creditsを区別する
Notion AIには現在、「プランに含まれる利用枠」と「Notion Credits」という二つの仕組みが存在します。上限を超えた場合には両者が連続して使われることがありますが、用途、ダッシュボードの場所、対象機能は異なります。この違いを理解しないままモデルごとの消費量を記録しても、数値を誤って解釈しやすくなります。
6時間のローリング利用枠は、6時間ごとに一括でリセットされない
BusinessプランとEnterpriseプランの一部のNotion AI機能には、6時間のローリング利用枠と月間利用枠が適用されます。6時間のローリング利用枠は、決まった時刻にすべてリセットされる仕組みではありません。古い利用記録が6時間の範囲を外れるたびに、使用可能量が徐々に回復します。ローリング利用枠を使い切ると、一部のAI機能は、古い利用記録が6時間の範囲から外れるまで一時停止する可能性があります。月間利用枠は請求期間ごとに一度リセットされます。使い切った場合は、管理者がワークスペースでNotion Creditsの継続使用を許可していない限り、次の請求期間まで待つ必要があります。
個人用Notion Agentのチャット、画像生成、ページ翻訳、Skillsは、この利用枠に含まれます。AI Meeting Notesには別途1日10時間の上限があります。Custom AgentsとWorkersは同じ内包利用枠を使わず、直接Notion Creditsを消費します。つまり、「Notion AIの利用上限に近づいている」という問題と、「Custom AgentがCreditsを使い切りそう」という問題は同時に起こる可能性がありますが、管理上は別の問題です。
個人AI利用量ダッシュボードとCreditsダッシュボードは別のページにある
個人AIの利用量は、「Settings → Notion AI → Usage」で確認します。この画面には、6時間のローリング利用量と月間利用量が表示されます。Notion Creditsのダッシュボードは、「Settings → Access & billing → Notion credits」にあり、主にCustom Agents、Custom Agent Autofill、Workers、さらにメンバーが内包AI利用枠を超えた後に追加で使用したCreditsを追跡します。
このインターフェースの分離によって、管理者はすべてのAI活動がCreditsページへ集約されていると誤解しやすくなります。実際には、内包利用枠を超えていない個人Agentの利用は、先にAI Usageページへ反映されます。管理者が「AI上限を超えた後にNotion Creditsの使用を許可する」設定を有効にした場合のみ、その後の追加利用がCreditsダッシュボードへ表示されます。ワークスペースで個人Agent、Custom Agents、Workersを同時に使っている場合、全体の消費状況を把握するには少なくとも二つの画面を確認する必要があります。
Notion AIのモデル説明がどれも似て見える理由
モデル説明が「役に立たない」と批判されるのは、利用者がモデルをまったく理解していないからではありません。意思決定に必要な情報を、インターフェースが示していないためです。r/Notionの投稿では、complex prompts、difficult reasoning、advanced reasoning、balanced reasoningといった説明が挙げられていました。個別に見れば合理的な表現ですが、同じ選択画面に並ぶと明確な違いを判断しにくくなります。投稿者が本当に知りたかったのは、現在のタスクに適したモデルはどれか、強いモデルはどれほど多くの利用枠を消費するのか、Autoが本当に毎回判断し直しているのかという点です。
「複雑な推論が得意」だけでは、具体的な使用場面へ変換できない
モデル説明では、速度、知能、推論能力、コストを使って大まかに分類することがよくあります。Notion公式も、モデル選択画面でspeed、intelligence、costを比較し、軽量モデルは定型的な下書き、簡単なルーティング、分類、構造化コンテンツに使い、より強いモデルは繊細な文章作成、複雑な推論、高い正確性が必要なタスクに残すよう勧めています。
問題は、「複雑」という言葉に実務上の境界がないことです。1ページの会議記録を整理する作業は簡単と考えられます。10件のプロジェクトページを同時に読み、日付と担当者を比較する作業は、おそらく複雑です。しかし、実際にはその中間のタスクが最も多く存在します。例えば、三つのデータベースを読んで企画書を書き直す、20ページの調査メモから矛盾を見つける、既存のプロパティに従って50件のデータを作成するといった作業です。これらのタスクには、最上位モデルの文章力は不要でも、安定したツール使用、長いコンテキスト、多段階の実行能力が必要になる可能性があります。「advanced reasoning」という説明だけでは判断できません。
「何に向いていないか」が書かれていないことは、長所が不足していること以上に問題になる
有用なモデル説明では、長所だけでなく制限も示す必要があります。例えば、短い要約には向いているが長文では細部を落としやすいモデル、文章作成には向いているが大量のデータベース操作ではコストが高くなるモデル、速度は速いが複数回の検証が必要なタスクには向かないモデルといった説明です。現在のモデル選択画面は、それぞれのモデルが「何をできるか」を中心に説明し、「どのような場面では使う価値が低いか」をほとんど示していません。
利用枠が制限された後は、この否定的な境界が重要になります。モデルがある作業を完了できるとしても、それが最も費用対効果の高い選択とは限りません。高性能モデルで句読点だけを修正すれば、結果は良くてもコスト配分は不合理です。軽量モデルで複数データベースにまたがる意思決定を処理し、最初の実行は安くても、その後3回修正する必要があれば、総消費量は高くなる可能性があります。
同じモデルでも消費量が固定されるわけではない
Notion公式は、Custom AgentsのCreditsについて、読み取るコンテンツ量、ステップ数、実行頻度、モデル選択の影響を受けると明確に説明しています。より多くのページを検索する、大規模なデータベースを走査する、より多くのツールを呼び出す、より多くの操作を完了するといった処理は、消費量を増やす可能性があります。高性能モデルは通常、より多くのCreditsを使用します。
したがって、モデル名だけが変数ではありません。同じOpusを使っても、3段落だけを書き直す場合と、複数のデータベースを検索し、ページを作成し、プロパティを変更し、結果を再確認する場合では、コストは同じになりません。「モデルAはモデルBより何倍高いか」という単発テストだけでは、ワークスペースの実際のコストを表せません。より適切なテスト単位は、「モデル＋タスク種類＋コンテキスト範囲＋操作数」です。
NotionのAutoモードは本当に最適なモデルを選ぶのか？
Notion公式はAutoを、「各リクエストに最適なモデルをNotionが選択する」機能と定義し、多くのCustom Agentsで推奨される初期設定としています。2026年1月のリリース情報でも、利用者がGPT-5.2、Claude Opus 4.5、Gemini 3を手動で選択するか、Autoへモデル選択を任せられると説明されています。
この説明から、Autoの製品上の位置づけがモデルルーティングであり、単なる固定モデルの別名ではないことは確認できます。ただし、公式は現在、ルーティング規則、判断に使用する特徴、各モデルの重みを公開しておらず、Autoが最低コストでタスクを完了すると保証しているわけでもありません。Autoが選ぶ「best model」は、品質、速度、ツールとの互換性、提供状況、コスト、システム負荷などを同時に考慮している可能性がありますが、外部から各要素の優先順位を確認することはできません。
Autoの目的は最低価格ではなく、システムが判断する適合性
タスクが複数ページの読み取り、ウェブ検索、データベース作成、プロパティ更新を含む場合、Autoはツール実行の安定性を優先する可能性があります。単純な要約や書式整理であれば、理論上は軽量モデルが選ばれやすくなります。これは製品設計として合理的な方向ですが、Autoがすべてのワークスペースで必ず利用枠を節約することを意味しません。
管理者が本当に必要としているのは、「Autoが最適なモデルを選ぶ」という一文ではなく、検証可能な結果です。例えば、今回どのモデルが選ばれたのか、その理由、予想コストの範囲、タスク終了後の実際の消費量です。Custom AgentのInsightsでは、使用したモデル、ツール、トリガー条件を確認でき、コストが異常に高い実行も特定できます。一方、一般の個人Agent利用者には、同じ程度に詳しいルーティング記録がありません。
AutoがGPT-5.2を指しているように見えても、ルーティングしていない証拠にはならない
複数のr/Notionの議論では、Autoを使用した後にモデル選択画面を開くと、チェック位置が頻繁にGPT-5.2へ移っているため、Autoは同じモデルを固定的に使用しているだけではないかという疑いが出ています。これは利用者の観察であり、Notionが公開した技術説明ではありません。インターフェースの表示方法、デフォルト選択、特定のタスク種類による影響を受けている可能性もあります。
ただし、この観察は製品上の問題を示しています。システムが実際のルーティング結果を表示しないため、利用者はモデル選択画面のチェック位置、回答の文体、利用量の変化から推測するしかありません。Autoが内部で本当にモデルを切り替えていても、外部から検証できなければ、管理者は信頼できるコスト管理手段として扱いにくくなります。Autoは便利な初期設定として使い続けられますが、監視なしでワークスペース全体の予算管理を任せるべきではありません。
Notion AIの利用量を予測しにくい理由｜問題はモデル価格だけではない
公式は、「一つのプロンプトが利用量の何％に相当するか」や「Opusが軽量モデルの何倍消費するか」といった固定換算表を公開していません。個人AI Usageページは割合を表示し、Custom Agentsでは実行後に実際のCreditsを確認できます。公開資料は消費量に影響する要素を説明し、代表的なワークフローの相対差も示していますが、各モデルと各操作の数値倍率を完全には公開していません。
割合表示は上限接近の確認には使えるが、事前予算には向かない
6時間の利用量が20％から25％へ増えた場合、直前の操作で5ポイント消費したことはわかります。しかし、次回の似た操作でも必ず5ポイント消費するとは限りません。コンテキストが長くなる、読み取るページが増える、ウェブ検索の範囲が変わる、ツール呼び出しに失敗して再試行するといった要因で、消費量は変化します。コミュニティでは、一つのプロンプトでローリング利用量が10％増えたという報告もあれば、高性能モデルへの簡単な質問では1％から3％しか増えなかったという報告もあります。これらは個別環境の観察であり、公式倍率として一般化できません。
割合ダッシュボードは燃料計に近く、残量が少ないことはわかっても、各区間で燃料を消費した理由までは示しません。個人利用にはある程度十分でも、チームのコストを管理する必要がある管理者にとっては、各リクエストの明細、モデル、ツールのステップ、失敗時の再試行記録がないと、無駄がどこで発生しているのか特定しにくくなります。
繰り返し修正することは、モデルそのものより多くの利用枠を消費する場合がある
プロンプトが不完全な場合、AIに最初の整理を依頼し、次に書式を追加し、抜けを修正し、さらにデータベースのプロパティを作り直させるという流れがよく起こります。4回の往復は、最初から目標、データ範囲、出力形式、禁止事項を明確にする1回の依頼より多くの利用量を消費する可能性があります。Notion公式も、関連する作業を一つのプロンプトへまとめ、同じ会話スレッドでコンテキストを再利用し、最初に成功条件を明確にするよう勧めています。
ただし、「一度に長い要求を書く」ことも、長ければよいわけではありません。無関係なページをすべてコンテキストへ追加すると、読み取り量が増えます。Agentにワークスペース全体を検索させると、三つのデータベースを指定する場合より高くなる可能性があります。利用量を抑える方法は、単純にプロンプトを短くすることではありません。タスクの境界を明確にし、本当に必要なデータソースだけを開放することです。
Notion AIのモデルはどう選ぶ？モデル説明よりタスクのリスク分類が実用的
公式説明が十分でない場合、ワークスペースごとに独自のモデルポリシーを作成できます。重要なのは、各モデルについて百科事典のような説明を書くことではなく、どのタスクなら小さな誤りを許容でき、どの誤りが大量のやり直しにつながるのかを決めることです。
| タスク種類 | 推奨モデル戦略 | 理由 |
|---|---|---|
| 文体の修正、文章校正、書式整理 | 軽量モデルまたは低コストモデル | 入力範囲が小さく、結果を人が確認しやすい |
| 1ページの要約、日付やタスクの抽出 | 軽量モデル、固定出力形式 | タスク構造が明確で、長い推論を必要としない |
| 分類、タグ付け、簡単なルーティング | 軽量モデルまたはAuto | 反復性が高く、安定性とコストを先に確認しやすい |
| 複数ページの調査、複数資料の比較 | Autoまたは中上位モデル | 長いコンテキストと情報源の差を処理する必要がある |
| 大量のデータベース作成・変更 | Plan Modeまたは小規模テストを先に行い、その後安定したモデルを選ぶ | 一度の誤りが大量の修正作業につながる |
| 重要な企画書、法律・財務関連の下書き | 高性能モデル＋人による確認 | 誤りのコストが高く、利用枠だけで判断できない |
| 長文作成と複数回のブレインストーミング | 外部AIへの移行を検討 | 長い対話は内包利用枠を急速に消費しやすい |
この表は固定された正解ではありません。データベース構造が単純なワークスペースでは、軽量モデルでも安定して処理できます。一方、大量のRelation、Rollup、権限、複数データベース間の規則を持つワークスペースでは、同じタスクでもより強いモデルが必要になる可能性があります。モデルポリシーは、単発の最低価格ではなく、「誤りのコスト」と「やり直しのコスト」から設計する必要があります。
Notion AIモデルの消費量比較表を自作する方法｜テストでは四つの変数を固定する
公式が数値換算表を公開していない状況では、独自の基準を作ることが最も現実的です。ただし、同じプロンプトを異なるモデルへ送るだけでは十分ではありません。少なくともタスク内容、データ範囲、出力形式、許可する操作を固定しなければ、結果を比較しにくくなります。
第1段階：四つの標準タスクを準備する
ワークスペースでよく使うタスクから、それぞれ一つずつ選べます。
1ページの要約：約1,000字の会議記録を、5項目の要約とタスクへ整理する。
構造化抽出：指定ページから氏名、日付、金額、ステータスを抽出し、表へ入力する。
複数ページ比較：指定した三つのページを読み、相違点、矛盾、欠落を列挙する。
多段階操作：一つのデータベースを読み、5件のテストデータを作成し、指定されたプロパティへ入力する。
各テストでは同じコピーを使用し、前回の実行で変更されたデータが次のテストへ影響しないようにします。データベースへの書き込みを含む場合は、本番ワークスペースで繰り返し実験せず、テスト用データベースを使用してください。
第2段階：実行前後の利用量と品質を記録する
個人Agentのテストでは、6時間利用量と月間利用量の前後の割合を記録できます。Custom Agentでは、そのrunで使用したCredits、モデル、ツール、ステップを記録します。公式のCreditsダッシュボードとInsightsを使えば、どのAgent、モデル、失敗後の再試行が高いコストを生んでいるか確認できます。
記録する項目として、日付、モデル、タスク種類、入力ページ数、出力の長さ、ウェブ検索の有無、データベース書き込みの有無、利用量の変化、完了時間、エラー数、人による修正時間が挙げられます。最後の項目は重要です。安いモデルでも20分の手作業による修正が必要なら、一度で完成する高性能モデルより総コストが低いとは限りません。
第3段階：同じタスクを最低3回テストする
AIの出力にはばらつきがあるため、一度の結果だけでは判断を誤りやすくなります。同じモデルとタスクを最低3回テストし、平均利用量と失敗率を確認します。Autoで毎回選択されたモデルが見えない場合でも、利用量、速度、品質は記録できます。ただし、結果は「Auto全体の性能」として扱い、裏側で固定された特定モデルが使われていると仮定してはいけません。
第4段階：毎月再テストし、古い数値を永久的な倍率として扱わない
Notionはモデル、ルーティング、利用量の計算方法を更新します。公式も、利用枠の大きさ、計算方法、対象機能を変更する可能性を明確に残しています。ワークスペースの比較表は、直近の意思決定には使えますが、永久的な料金表として扱うべきではありません。毎月一つか二つの標準タスクを再テストすれば、コストが大きく変化していないか確認できます。
ワークスペース管理者が今できること｜モデル最適化より先に予算の防護策を作る
モデル選択はコスト管理の一部にすぎません。請求額が制御不能になる主な原因は、高頻度のトリガー、広すぎる読み取り範囲、失敗後の自動再試行、メンバーが内包利用枠を超えた後に自動的にCreditsを使い始めることです。
コストが不明な段階では、上限超過後のCredits自動使用を無効にする
「Allow workspace to use Notion credits after AI limit is reached」は初期状態で無効になっています。管理者が有効にすると、メンバーは個人AI利用枠を使い切った後も処理を続けられ、その時点からワークスペースのCreditsを消費します。
小規模チームでは、利用量の基準がまだない段階では無効のままにできます。利用枠を使い切ったら一時停止するため、追加費用へ自動的に移行しません。高い利用量が必要な特定メンバーや期間についてのみ、管理者が有効化を検討できます。この方法は不便ですが、「全員がまだプラン内の利用枠を使っていると思っていたのに、実際にはCreditsが消費されていた」という事態を防げます。
Custom Agentsには個別の上限を設定し、総額だけを見ない
Notion Creditsダッシュボードでは、各Agentの利用量、実行回数、状態、作成者を確認でき、個別のCustom AgentへCredit limitを設定できます。あるAgentの消費が異常に高い場合は、まず停止し、読み取るコンテンツが多すぎないか、ステップが長すぎないか、トリガーが多すぎないか、必要以上に強いモデルを使っていないか確認できます。
各Agentは、一つの安定した作業だけを担当させるのが望ましい方法です。メール受信、分類、調査、執筆、データベース更新、通知を一つのAgentへすべて入れると、完全な仕組みに見えても、コストが増えた際にどのステップが原因か特定できません。複数の観察可能なフローへ分割すれば、支出を制御しやすくなり、モデルの変更も容易になります。
高頻度で価値の低いタスクを優先して修正する
管理者は最も高価なモデルを先に注視しがちですが、毎日数百回実行される単純なタスクを見落とす場合があります。1回の消費量が少なくても、月間コストが低いとは限りません。自動分類、ステータス同期、重複した要約、過度に頻繁なスケジュール実行は、重要な文書を高性能モデルで時々作成するより大きな費用になる可能性があります。
確認は、「実行回数が最も多いタスク」から始め、その後で1回あたりのCreditsと失敗率を確認できます。単純なルールに基づくプロパティ更新であれば、AI自体が不要な場合もあります。Database Automation、Button、数式、Workerへ変更したほうが安定する可能性があります。モデル最適化は、すべてのフローを安いAIへ置き換えることではありません。AIを使わないことが最も安い場合もあります。
ClaudeやChatGPTを契約済みの場合、どの作業をNotionの外へ移すべきか？
外部AIとNotionの境界は、以前ほど明確ではありません。Notion MCPを使えば、Claude、ChatGPT、CursorからNotionページを読み書きできます。ClaudeのリモートConnectorもNotionへ接続でき、Notion自身もClaude Agentsを直接ワークスペースへ導入する機能を試験しています。
これによって、「長い対話を外部へ移す」という方法が現実的になりました。ただし、すべてのタスクを外部へ移すのが適切とは限りません。
外部AIへ移すのに適した作業
長文の初稿、繰り返しのブレインストーミング、コードのデバッグ、大量の文章比較、何度も質問を重ねる調査は、すでに契約している外部AIへ移すのに適しています。これらのタスクは長い会話になりやすく、頻繁にNotionへ書き込む必要がない場合もあります。完成後に、最終稿、結論、構造化データだけをNotionへ保存すれば、長時間の対話でNotionの内包利用枠が消費されるのを抑えられます。
Notionに残すのに適した作業
ワークスペースの権限を使う、データベースを更新する、ページを作成する、既存のプロパティへ入力する、チームの知識を検索する、既存のワークフローへ接続するといったタスクは、Notion内に残したほうが通常は効率的です。Notionの価値はモデルだけではありません。モデルがデータ、権限、操作画面のすぐそばにあることです。少量の利用枠を節約するためにすべての内容を外部へ移し、その後で手動でデータベースへ貼り戻すと、AIコストを人件費へ置き換えただけになる可能性があります。
外部接続でも権限とリスクを考慮する
MCPやConnectorを使用すると、外部AIは付与された権限に基づいてNotionのコンテンツへアクセスします。機密データ、顧客情報、社内文書については、利便性だけで判断できません。管理者は、アクセス可能な範囲、利用者権限、サービス提供者のデータ処理方針、アクセス権を取り消す方法を確認する必要があります。Creditsの節約を目的に、データの露出範囲を広げるべきではありません。
Notionにまだ不足している情報｜必要なのは検証できるコスト表示
現在のNotionは、利用量の割合、Creditsダッシュボード、Agent Insights、モデルの速度・コスト区分を提供し、管理者が一部の制限を設定できるようにしています。これらは「すでにどれだけ使ったか」を管理できますが、「今回送信する前にどれほど使う可能性があるか」という問題を完全には解決していません。
より実用的な改善案は、次のとおりです。
モデル選択画面で、low、medium、highだけでなく、1倍、2倍、5倍などのコスト区分を表示する。
Auto実行後に、実際にルーティングされたモデルと主な理由を表示し、少なくとも管理者が予想どおりだったか確認できるようにする。
各リクエスト完了後に利用量の明細を提供し、モデル、読み取り量、ツールのステップ、再試行、総消費量を表示する。
個人とグループごとに6時間・月間予算の通知を設定できるようにし、上限へ近づいた時だけ通知する仕組みに限定しない。
要約、データ抽出、複数データベースの調査、大量書き込みなどのタスク例を示し、それぞれに適したモデル区分を明記する。
利用枠制度そのものが必ずしも不合理というわけではありません。Notionはモデル、検索、ツール実行、インフラの費用を負担する必要があり、制限によって一部の高負荷な利用がサービス全体を遅くすることも防げます。問題は、コストが日常操作へ入り込んだにもかかわらず、インターフェースがまだ「より賢そうなモデルを一つ選ぶ」段階にとどまっていることです。利用者が利用枠とCreditsを負担するのであれば、製品側も十分に細かい判断情報を提供する必要があります。
Notion AIのモデル選択は、2026年8月以降、回答の文体だけでなく、ワークフロー設計の一部になりました。現時点で最も安定した方法は、個人AI利用量とNotion Creditsを分けて監視し、タスクのリスクに応じてモデル区分を設定し、固定タスクによる直近の基準を作り、不要な上限超過後のCredits支出を無効にすることです。Autoは、事前に分類しにくいタスクのために残せますが、利用枠の節約が証明されたブラックボックスとして扱うべきではありません。公式がルーティングとコストの詳細を提供するまでは、ワークスペース独自のテスト記録が最も信頼できる判断材料です。
よくある質問 FAQ
Notionの新しいAI利用枠は、2026年8月3日に適用されました。BusinessプランとEnterpriseプランの一部のAI機能には、6時間のローリング利用枠と月間利用枠が同時に適用されます。実際の使用可能量とリセット時期は、「Settings → Notion AI → Usage」で確認できます。
利用枠は、BusinessプランとEnterpriseプランに含まれる一部のAI利用量です。Notion Creditsは、Custom Agents、一部のAutofill、Workers、さらに管理者が許可した上限超過後の個人AI利用に使われます。対象機能とダッシュボードの場所が異なるため、同じ数値として扱うことはできません。
公式は、Autoが各リクエストに最適なモデルを選ぶと説明していますが、必ず最低コストのモデルを選ぶとは保証していません。Autoは、品質、速度、ツール機能、そのほかのシステム条件を同時に考慮する可能性があります。そのため、便利な初期設定としては使えますが、Creditsを節約できる保証として扱うべきではありません。
現在、公開された固定のモデル換算表はありません。より信頼できる方法は、同じデータ、同じプロンプト、同じ出力形式、同じ操作範囲で複数回テストし、利用量、エラー率、人による修正時間を記録して、ワークスペース独自の直近基準を作ることです。
外部AIのモデル利用量は通常、外部サービス側のプランに基づいて計算され、Notionの個人AI利用枠を直接消費しません。ただし、Notion MCPやConnectorを通じて操作する場合は、各サービスの利用条件、権限、ツール上の制限が適用されます。長文の対話や初稿作成は外部へ移せますが、大量のNotionデータベースを読み書きする作業では、操作の利便性とデータリスクも比較する必要があります。