Notion Workers の​料金が​増える​理由｜​本番の​同期で​測った​クレジットと​減らし方

Notion Workers の料金は、実行1回ごとに使う Notion クレジットで決まります。2026年11月時点の公式の目安は、1回 $0.0023 です。

弊社の本番の同期で料金を大きく動かしたのは、1回の重さより、実行の回数でした。返り値を細かく分けていた時期は、1日約800回・約156クレジットを使っていました。

分けるのをやめた後は、1日約50回・約10.9クレジットになりました。1回あたりのクレジットは、前後でほとんど変わっていません。

この記事は、Notion Workers の同期を作る人・任されている業務の担当者・情報システムの担当者に向けて書きます。

弊社の同期での実測（2026年9月〜10月）と、2026年11月2日に読んだ Notion の公開の文書で整理します。料金は変わりうるので、決まりは2026年11月時点のものです。

2026年11月時点の​料金の​決まり

公式のヘルプ（Workers の料金のページと、Notion クレジットのページ）に書かれている決まりは、次のとおりです。

項目	2026年11月2日に読んだ公式の文書
何で払うか	Notion クレジット。ビジネスとエンタープライズのプランに足すアドオン
1回の数え方	同期は実行ごとに1回、エージェントのツールは呼ばれるごとに1回、ウェブフックは1件のイベントを処理するごとに1回。同期の1周を何回と数えるかは書いていない
1回の目安	$0.0023（1,000クレジットで10ドルなので、約0.23クレジット）。動いた時間や処理の量で増減する
クレジットの単価	月払いは1,000クレジットで10ドル（毎月リセットされ、余りは繰り越さない）。年払いは1,000クレジットで13ドル
ベータの間	無料。使った分は残高から引かれない。将来はクレジットが要る

公式の例では、Salesforce の商談を15分ごとに同期すると、月2,880回で6.62ドル、662クレジットです。1日96回の実行で計算しています。

Notion クレジットの新しい仕組みは、既存のワークスペースでは2026年11月2日から始まると、公式のヘルプにあります。同じ日に読んだ Workers の料金のページは、ベータの間は無料としたままでした。

原因: 弊社の​同期で​料金を​動かしたのは、​1回の​重さより​実行の​回数

公式の開発者向けの手引きでは、同期は予定の時刻ごとに、関数 execute を hasMore: false が返るまで繰り返し呼ばれます。予定の既定は30分ごとです。

公式のヘルプは、execute を繰り返す1周を何回と数えるかを書いていません。弊社の CLI の値では、execute の呼び出しごとに1回でした。

1本の同期でも、返す値を何回に分けるかで、1回の起動の実行の回数が変わります。1日の実行は、同期ごとの「1日の起動の回数×1回の起動で返す回数」の合計になります。

弊社の同期で、1回あたりのクレジットは、分けていた時期が約0.20、分けるのをやめた後が約0.22でした。どちらも公式の目安の約0.23に近い値です。

1日の実行は約795回から約50回へ約16分の1に、1日のクレジットは約14分の1になりました。この同期の料金の差は、ほとんどが回数の差です。

同じワークスペースのほかの小さな同期2本は、同じ7日の1回あたりが約0.28と約0.42でした。1回の重さは同期の作りで違います。

弊社の​同期で​測った​クレジット

弊社は、お客様の Salesforce のデータを、毎日 Notion のデータベースへ同期する仕組みを、Notion Workers で作っています。

1つのワーカーに、定期の同期18本をまとめた構成です（2026年10月23日のコード）。2026年10月8日の時点では、毎日の同期は17本でした。

項目	分けていた7日（2026年9月28日〜10月4日）	分けるのをやめた後の7日（2026年10月20日〜26日）
1日の実行	約795回	約50回
1日のクレジット	平均 約156（151.5〜161.5）	平均 約10.9（10.6〜11.8）
1回あたり	約0.20クレジット	約0.22クレジット
30日に直すと	約4,700クレジット（月払いで約47ドル）	約330クレジット（月払いで約3.3ドル）

数は、Notion の CLI の ntn workers usage --json --all で2026年10月27日に取った、日ごとの値です。日は UTC で区切られています。

ベータの間に CLI が出す値で、請求された額ではありません。公式のヘルプも、CLI の値を見込みのクレジットと呼んでいます。

回数が増えていた理由

2026年9月、日本語の値の文字化けを避けるため、同期が1回に返す値を24,000バイト以下に分けました。文字化けの原因と直し方は、Notion Workers の同期で日本語が1文字だけ化ける理由にまとめています。

分けると、全件を返す同期は「行の数÷1回の行の数」だけ実行が出ます。約4万行の問い合わせの表の同期は、それだけで1日約480回でした。

直し方​: 1回に​返す量を​増やし、​実行の​回数を​減らす

前後の差を作った直し方は、1回に返せる量を増やしたことです。返す値の ASCII でない字を \uXXXX で書き出す形に替え、1回の上限を約1MBにしました。

2026年10月8日に本番へ入れた後、その時点の毎日の同期17本の1周は、実行41回・約3分で終わりました。その後の1日の実行は約50回です。

ASCII の書き出しの部品とその確かめ方は、上の文字化けの記事に載せています。

確かめたこと: 差分の同期が、毎日ほぼ全件を返していた

元のシステムの夜間の一括更新で、更新日時が毎日ほぼ全行で進んでいました。差分の同期でも、毎日ほぼ全件を返していました。

これは原因を確かめたところまでで、元のシステムの側は直していません。今は、1回に返す量を増やしたことで、回数を抑えています。

今の設定: 予定の頻度

弊社は、定期の同期18本のうち16本を1日1回、2本を6時間ごとにしています。前後の7日で、この設定は変えていません。

公式は、遅い予定から始め、要るときだけ頻度を上げるよう勧めています。予定の既定は30分ごとなので、同期を足すときは頻度を確かめます。

確かめ方​: CLI で、​1日の​実行の​回数と​クレジットを​並べる

料金が増えていないかは、CLI の使用量を日ごとに並べ、1日の実行の回数と、1回あたりのクレジットを見て判定します。

次のコードは、ntn workers usage --json --all の出力を読み、ワーカーごとに日ごとの数を並べます。項目の名前は、2026年10月に弊社が取った出力のものです。

# usage_daily.py  使い方: ntn workers usage --json --all > usage.json && python3 usage_daily.py usage.json
import json
import sys

for w in json.load(open(sys.argv[1], encoding="utf-8")):
    print(w["worker"]["name"])
    for d in sorted(w["dailyUsage"], key=lambda d: d["day"]):
        credits = d["creditsMicro"] / 1e6  # クレジットの百万分の1の単位で入っている
        runs = d["sandboxCount"]           # その日の実行の回数
        per_run = credits / runs if runs else 0
        print(f'  {d["day"]}  実行 {runs:5d} 回  {credits:8.2f} クレジット  1回 {per_run:.3f}')

1日の実行が「同期の本数×1日の起動の回数」より大きく多ければ、1回の起動で何回にも分けて返しています。1回あたりが公式の目安の約0.23より大きく上回るなら、1回の処理の量を見直します。

弊社の同期では、このコードの数で、分けていた時期の1日約795回と、直した後の約50回を確かめました。1日の値は UTC の区切りなので、日本時間の朝の9時で日が替わります。

前後の差は、1つの反映の前と後の比べです。同じ反映で SDK の版を 0.4.0 から 0.9.2 に上げるなど、ほかの変更も入れたので、1回あたりの差がどれによるかは切り分けていません。

落とし穴: 実際に​踏んだ​もの

• 反映した日は、回数が跳ねた反映するたびに、全部の同期がその場で1周走りました。2026年10月5日は反映が3回重なり、1日約2,100回・約410クレジットでした。
• 1時間あたりの実行の上限に当たった公式の既定は、同期の実行が1時間に600回です。分けていた時期は、多くの同期を一度に動かした日に上限に当たり、同期が待たされました。
• 画面では確かめられなかった公式は、管理者とワーカーを作った人が、Notion クレジットの画面の Workers の札で見られると書いています。弊社は2026年10月27日に画面を開きましたが、Workers の札を見つけられず、CLI の数で見積もりました。
  • 開いたアカウントが、ワーカーを作ったアカウントかは確かめていません。新しいクレジットの仕組みが既存のワークスペースで始まる、11月2日より前のことです。
• 文字化けの直しが、回数を増やしていた2026年9月に返り値を24,000バイト以下に分けた後、1日の実行は約800回になりました。化けは止まりましたが、1日のクレジットは今の形の約14倍でした。

自力で​どこまで​やれるか

CLI の使用量を日ごとに並べ、1日の実行の回数を見るところまでは、上のコードで自力でできます。予定の頻度を下げるのも、設定の1行です。

自力の壁は次の2つです。

• 1回に返す量を増やすには、返す値の書き出しを変え、文字化けしないことを全件で確かめ直す必要がある
• 差分の同期が全件を返している原因は、元のシステムの更新のされ方にあり、元のシステムの側を調べないと分からない

外注する​場合の​判断基準

外注の分かれ目は、同期の実行の回数を、元のシステムのデータの増え方と合わせて見積もれるかです。外注するなら、見積もりを比べる前に次の3点を確かめてください。

• 同期ごとの1日の実行の回数を、行の数と1回に返す量から見積もるか
• 差分の同期が全件を返していないかを、元のシステムの更新日時の動きで確かめるか
• 反映の後に CLI の使用量を見て、回数が見積もりどおりかを確かめるか

ゴムマリでは、ほかのシステムのデータを Notion などへつなぐ同期の設計・構築・受け入れの照合（件数・値の一致）・保守を、システム連携・API 開発として承ります。

料金は、連携1本（接続先2つ・片方向・定期の更新）で初期50万円から、保守は月3万円から、期間は2週間からです。

同期の書き込み先になる Notion のデータベースの設計と構築から頼む場合は、業務データベースの開発・構築（Notion 対応）で承ります。料金は初期30万円から、保守は月3万円から、期間は2週間からです。

進め方は相談からご連絡ください。

Notion Workers の開発で頼めることは、Notion の構築と開発にまとめています。

次の​一歩

まず、ntn workers usage --json --all を取り、上のコードで日ごとの実行の回数を並べてください。回数が同期の本数より桁で多ければ、1回の起動で何回に分けて返しているかを見ます。

同期の返り値を分けている理由が文字化けなら、Notion Workers の同期で日本語が1文字だけ化ける理由の ASCII の書き出しで、分けずに返せます。

Salesforce で消した値が Notion に残る件は、Salesforce から Notion への同期で消した値が残る理由にまとめています。

関連記事: Notion Workers の同期で日本語が1文字だけ化ける理由／Salesforce から Notion への同期で消した値が残る理由