Notion AI 料金の衝撃——月$340のCustom Agents、上限設定か再構築か

Notion AI 料金の前提が一夜で変わりました。5月3日まで私のCustom Agentsのコストは$0。それが5月4日には1,000クレジットあたり$10を消費し始め、何も変えなければクライアントOSは約$340/月になるというのが最初の試算でした。

Notion AI 料金のメーターが動き出した日

無料ベータ後半のあいだ、私は実際のクライアント業務用ワークスペース、DVNCクライアントOSの中でNotion Custom Agentsを動かしていました。届いたブリーフを読むトリアージエージェント、進行中の案件状況をまとめる日次ダイジェストエージェント、複数の共有ナレッジベースを正本ページと同期するドキュメント同期エージェント。常時稼働が3つ、イベントで起動するものが数個あり、コスト欄はゼロでした。

Notionが課金メーターをオンにしたのは2026年5月4日です。Custom Agentsは無料ベータから従量課金の正式版へ移行し、料金は1,000 Notionクレジットあたり$10。シートのサブスクリプション料金に上乗せされ、利用できるのはBusinessとEnterpriseプランだけです。機能を残したまま下位プランへ移る道はありません。そもそもPlusとFreeにはCustom Agentsがなかったため、「機能を維持しつつプランを下げる」という選択肢自体が存在しないのです。Business以上で従量課金を受け入れるか、この機能を使わないかの二択です。

切り替え後の最初の48時間は、あえて設定に触れず、そのまま走らせました。欲しかったのは試算ではなく、実際の消費データだったからです。私が追っているあるオペレーターは、同等の構成で1か月に約$337を消費したという実数を公開しています。私の30日予測とほぼ同じであり、この消費が設定ミスではないと分かりました。これが新しい最低ラインだったのです。

一般的な料金解説が見落としがちなのは、ここです。5月4日に起きたのは値上げではありません。値上げなら、ある項目が$40から$55になり、予算を更新すれば済みます。今回は無料から従量課金への転換でした。これは別種の出来事です。エージェントの設定、スケジュール、対象範囲に組み込んでいたコスト前提が、すべて間違いに変わりました。それらの判断は「クレジットコストはゼロ」を前提にしていたからです。最初にやるべきことは支出削減ではなく、すでに消えた前提からワークフローを組み直すことでした。Notionは同年初め、開発者側でも構造的によく似た変更を行っています（外部エージェントのクレジット崖を参照）。パターンが読めても、請求額が減るわけではありません。

Notion クレジットは実際にどこで消えたのか

最初に役立ったのは、エージェントごとの消費量を計測できるようにしたことです。NotionのUIではワークスペース全体のクレジット消費量は見えますが、初期状態のままでは、どのエージェントがメーターを回したのかを明快に分解できません。クレジットはワークスペース全体で共有され、毎月リセットされます。一見すると公平ですが、実際には消費の激しいエージェントが、同じワークスペース内のほかのAIワークフローを気づかないうちに圧迫します。

消費量の約70%を占めていたのは、5つでも8つでもありません。わずか3つのエージェントでした。

圧倒的に大きかったのは、共有の受付ページを巡回して新しいブリーフを分類するトリアージ／受付エージェントです。15分ごと、24/7でチェックする設定でした。ほとんどの巡回では新着がありません。それでも実行されるたびにクレジットは消費されます。変化のないデータを空振りでポーリングし続けることが落とし穴です。エージェントは指示どおりに動いていました。ただし、その指示はメーターが回り始めた瞬間に高価なものへ変わりました。

2番目に大きかったのは、日次のクライアントダイジェストです。進行中の案件ごとに毎日1回実行し、アクティブなクライアント一覧全体へ展開していました。1回あたりのコストは妥当でも、問題は回数です。無理のない単価でも、案件数を掛け、さらに30日を掛けると、それだけで前月のNotion全シート料金を上回る月額になりました。

3番目のドキュメント同期エージェントは、最も興味深いケースでした。1回あたりでは3つの中で最安ですが、編集をトリガーにしていたため、1人が共有ページを編集する1回の作業中に12回ほど起動することがありました。事実上、人間のタイピング速度に連動して実行回数が増える設計です。1,000クレジットあたり$10なら、意図して選ぶ人はいない設定でしょう。

切り替え後の最初の10日間から月額を復元し、外挿すると、概算はこうなりました。トリアージエージェントは当時の巡回間隔で約$160/月。ダイジェストエージェントは現在の案件数で約$95/月。ドキュメント同期は観測した編集量で約$45/月。残りの軽量な4つで約$40/月です。合計は$335〜$345となり、似たワークスペースを運用する別のオペレーターが公開していた数字とも一致しました。

これは、以前紹介した運用スタックの月額$387という基準額に上乗せされます。ここへ$340の項目が加われば、スタック全体が、あらかじめ明確に設定していた上限を超えます。つまり「少額の超過として吸収する」で済む話ではなく、構造的な問題でした。

AIエージェントのコストを決める3つの選択肢

選択肢は3つです。それぞれを実数で比較すると、私のワークロードに合う答えは1つしかありませんでした。同じ数字でも、別の人なら違う結論になります。だからこそ、誰かの推奨をそのまま採用せず、自分の計算を回す必要があります。

選択肢A — 従量課金のまま何も変えない。 実行回数が少なく、1回あたりの価値が高く、請求の予測可能性より総コストの抑制を重視するなら、これが正解です。たとえば1日あたり少数の高価値な処理だけを行い、綿密に絞った成果物1つで人の作業を1時間削減できるエージェントなら、従量課金でも成立します。問題は1,000クレジットあたり$10という数字そのものではありません。どんな実行単価でも採算が取れないエージェントを動かしていることが問題です。このワークスペースの成果を考えると、全面的に従量課金を続ける上限は約$80/月でした。予測はその4倍です。選択肢Aは外れました。

選択肢B — 上限を設け、対象範囲を見直す。 常時ポーリングを止めます。一定間隔で起動するエージェントを、イベント起動または手動起動へ変えます。ダイジェストは案件ごとの実行をやめ、全体をまとめた出力を1つ作る日次バッチ1回へ集約します。ドキュメント同期にはデバウンスを設定し、編集のたびではなく、編集セッションごとに1回だけ起動させます。見直し後の試算は約$70〜$85/月。必要な成果物は維持でき、上限内に収まりますが、トリアージの「即時性」は明確に失われます。現在は15分ごとではなく2時間ごとの実行です。この遅延は、率直に評価すべき実際のプロダクトコストでした。

選択肢C — 自分で管理するインフラ上に再構築する。 最も重いトリアージエージェントをNotionの外へ移します。cronで起動するCloudflare WorkerからClaudeを直接呼び、結果をAPI経由でNotionページへ書き戻す構成です。同種の実装経験がある人なら、初期構築には集中作業で約6〜8時間。私にはその経験があります。継続コストは、すでに支払っているWorkerプランに加え、この処理量ならClaude APIトークンが月に数ドル前半です。同等のセルフホスト型エージェントスタックを公開運用している創業者もおり、1回あたりの実行量が損益分岐点を超えれば、この計算は成立します。

重要なのは損益分岐の計算だけです。私のトリアージエージェントの実行ペースでは、Notionの従量課金は約$160/月。自前インフラへ移すと、継続コストは約$4/月です。構築時間を社内レート$150/時間として余裕を持って評価し、12か月で償却すると、最初の1年は約$100/月。再構築の1年目の総額は約$104/月で、従量課金なら約$160/月です。2年目以降は約$4/月対約$160/月。1年以内に元が取れ、その後も差は積み上がります。

Codexのオファーを評価した際と同じ、オペレーターとしてのP&L規律をここでも使いました。ただし、問いの向きは逆です。前回は無料特典を理由にツールを乗り換えるべきかを判断し、今回は利用中のツールの経済性が足元で変わったため、その周辺を再構築するべきかを判断しています。フレームワークは同じで、方向だけが反対です。

実際に選んだのはハイブリッドです。 最大のコスト項目であるトリアージだけをWorker上に再構築します（選択肢C）。中量級のダイジェストとドキュメント同期には上限設定と対象範囲の見直しを適用します（選択肢B）。残る軽量な4つは、従量課金のまま残します（選択肢A）。

ハイブリッド構成の継続コストは、再構築のリリース後で約$45〜$55/月。1回限りの時間コストは約7時間です。何もしない場合の$340予測と比べると、集中して1回実装することで約$290/月を削減できます。30/60/90日のコスト推移では、1か月目は再構築時間を吸収し、一部を従量課金で動かすため約$110相当（時間コストを含む実質額）。2か月目は定常状態に近い約$55、3か月目は定常状態の約$45です。

今なら変えることがあります。少し気恥ずかしい話ですが、クレジット課金が始まってからではなく、ベータ初日からエージェント別のクレジット消費を計測すべきでした。ベータ期間は、従量課金になった場合に各エージェントがいくらかかるかを正確に測れる無料の機会でした。Notionはクレジット単価をかなり前から公表していたにもかかわらず、私は「無料」を「測定しなくてよい」と捉えてしまったのです。後からエージェント別の消費量を復元するほうが、リアルタイムで測るより時間がかかりました。今では、どのツールにも同じルールを適用しています。

Notion AI 料金で学んだ、常時稼働エージェント導入前のルール

教訓は「Notion Custom Agentsは高すぎる」ではありません。私のエージェントの一部は今もCustom Agents上で動き、今後も残ります。本当に重要なのは、もっと限定的で実用的な点です。無料ベータの自動化は機能ではなく、依存関係グラフ上の負債です。

ベンダーがベータ版の自動化機能を無料・無制限で提供するとき、利用者が手にするのは、まだ存在しない料金モデルを前提にワークフローを組み込める無料の権利です。料金モデルが現れた瞬間、提示された従量課金を受け入れるか、時間に追われながら再構築するかを迫られます。対応コストが最も低いのは、メーターが動き出した後ではなく、その前です。

無料ベータの自動化を重要な経路へ組み込む前に、今は次の確認を行っています。

1. 課金が始まる前に、従量課金版の価格を試算する。 ベンダーがまだ単価を公表していなければ、類似製品をもとに妥当な料金を仮定し、それでもエージェントの採算が合うかを確かめます。
2. 初日から1回あたりのコストを計測する。 無料期間はただ乗りの機会ではなく、測定期間として扱います。
3. 必要になる前に再構築ルートを決める。 経済性が逆転したとき、自分で管理するインフラへ移すエージェントはどれか、構築にはおよそ何時間かかるかを把握しておきます。
4. 常時稼働の実行間隔は、許容できる最も遅い設定に抑える。 2時間ごとの巡回で問題ないなら、設定できるという理由だけで15分ごとにしないことです。実行間隔はコストを調整するダイヤルです。ベータ中なら無料で遅くできますが、後から遅くする代償は高くなります。その頃には、人が速い反応を前提に習慣を作っているからです。

クライアントOSで採用したハイブリッド構成は、洗練されているとは言えません。1つのワークスペースで3種類のコストモデルを並行運用するため、ゼロから設計する場合より設定は複雑です。それでも実際の仕事の形に合っており、課金開始前にこのワークスペースへ設定していた上限内まで月額を戻せます。判断基準として重要なのは、それだけです。

無料ベータの自動化は機能ではなく負債です。組み込む前に価格を見積もらなければ、誰かがメーターをオンにした後、時間に追われながら再構築することになります。

2026年5月4日以降、Notion Custom Agentsの料金はいくらですか？

1,000 Notionクレジットあたり$10で、サブスクリプションと合わせて請求されます。利用できるのはBusinessとEnterpriseプランのみで、FreeとPlusにCustom Agentsが含まれたことはありません。

クレジット課金を避けるため、PlusプランでCustom Agentsを維持できますか？

いいえ。Custom AgentsはFreeにもPlusにも提供されていなかったため、機能を維持できるダウングレード先はありません。Business以上で従量課金を受け入れるか、機能を使わないかのどちらかです。

ワークスペースのクレジットを使い切るとどうなりますか？

Custom Agentsは停止します。Meeting Notesや標準のNotion Agentなど、ほかのNotion AI機能は、基盤となるプランのフェアユース上限まで引き続き利用できます。

エージェントを自前インフラへ移すほうが安くなりますか？

実行量が損益分岐点を超えた場合に限ります。それ未満なら、従量制のクレジット料金のほうが構築・保守にかかる時間より安く済みます。それを超え、とりわけ常時稼働のエージェントが1日に何度も起動する場合は、自分で管理するインフラの優位性が2年目以降に積み上がります。