microCMS無料プランの転送量20GB｜止まる原因と対処

「microCMSの無料プランはAPIの呼び出しが無制限だから、アクセスが増えても大丈夫」——個人のブログや小さなメディアをmicroCMSで始めたとき、多くの人がこう考えます。

結論から言うと、microCMSの無料プラン（Hobby）は呼び出しの回数ではなく、データ転送量が月20GBを超えた時点で、即時にAPIが止まります。止まったAPIは、Teamプラン以上へ上げるか、翌月1日の午前9時を待つまで戻りません。しかも転送量には、CDNのキャッシュから返った分も、管理画面で画像を表示した分も数えられます。

株式会社Fyveは、私たちが運営している別のメディアサイトで、2026年10月23日にこの上限に実際に届き、本番の記事一覧とサイトマップが見本の記事に入れ替わる事態を経験しました。この記事では、公式の決まりを一次情報で確かめたうえで、何が転送量に数えられるのか、なぜ私たちのサイトは20GBに届いたのか、止まったときの戻し方と、止まらない作り方を順に説明します。

microCMSの無料プランの転送量は月20GB。超えるとAPIが止まる

まず、公式の料金ページとヘルプに書かれている決まりを整理します。数字はすべて2026年10月27日時点で、microCMSの料金ページ（microcms.io/pricing）で確認したものです。表示価格は税抜き・1サービスあたりの月額です。契約の前には、最新の料金ページを確認してください。

料金ページには、APIのリクエスト数は全プランで「無制限」と書かれています。ここで誤解が生まれます。無制限なのは呼び出しの回数であって、転送量ではありません。無料プランで止まる原因は、回数ではなく「何GB運んだか」です。

止まるのは「即時」、戻るのは「翌月1日の午前9時」

microCMSのヘルプ「Hobbyプランでデータ転送量が20GB/月を超えた場合はどうなりますか？」には、次のように書かれています。

• データ転送量が20GB/月を超過した場合、即時にAPIが停止する
• Webサイトなどから直接APIを呼んで表示している場合は、コンテンツが正常に表示されなくなる場合がある
• APIが停止した場合、Teamプラン以上にアップグレードすると、APIが再開する（管理画面の「サービス設定」＞「お支払い」から自分で操作できる）
• データ転送量のカウントは毎月リセットされ、APIの停止は翌月1日の午前9時に解除される

前触れのない「即時停止」で、猶予期間はありません。月の前半で20GBに届けば、残りの日数はずっとAPIが使えない状態になります。

有料プランは止まらないが、超えた分は後から請求される

Team以上のプランは、上限を超えてもAPIは止まらず、超えた分が後から請求されます。ヘルプ「データ転送量の請求はどのように行われますか？」によると、集計は毎月1日の午前10時ごろに前月分（1日〜末日）を対象に行われ、次の支払いのタイミングで「データ転送量×従量単価」が加算されます。従量単価は集計した時点で使っているプランの単価が使われるため、月の途中で下のプランに戻すと、使ったときより高い単価で請求される場合がある、とも注意書きがあります。

私たちのサイトで起きたこと：一覧とサイトマップが見本の記事に戻った

ここからは、私たちが実際に経験したことです。止まったのは、fyve.co.jpとは別に運営しているメディアサイトで、数百本の記事をmicroCMSの無料プランから読んで表示していました。記事を書くのはAIで、人がmicroCMSの編集画面で記事を書く運用ではありませんでした。

2026年10月23日、このサービスの転送量が月20GBに届き、APIが止まりました。翌10月24日の未明に確認した時点で、本番サイトは次の状態でした。

• 記事一覧のページ・サイトマップ・RSSが、開発中に入れていた数本の見本の記事に入れ替わっていた
• 記事ページのうち1本は404になっていた
• ほかの記事ページは、止まる前に作られた版がそのまま表示されていた

原因は、サイト側の作りにありました。APIの取得に失敗したとき、エラーにせず「見本の記事」に切り替えて表示する作りにしていたのです。開発中は便利だった仕組みが、本番では「止まっていることに気づきにくく、しかも間違ったサイトマップを検索エンジンに出し続ける」動きになりました。ページが真っ白になるより、見本の記事が並ぶほうが一見まともに見えるぶん、発見が遅れます。

サイトマップが見本の記事に入れ替わると、検索エンジンに存在しないURLを知らせ、本物の記事のURLを知らせない状態になります。サイトマップと検索エンジンへの登録の関係は、次の記事で実体験から説明しています。

「検出-インデックス未登録」はサイトマップが原因？実体験から解説

microCMSの転送量に数えられるもの・数えられないもの

「なぜ20GBも使ったのか」を考えるには、まず何が転送量に数えられるのかを知る必要があります。microCMSのドキュメント「データ転送量」（document.microcms.io/manual/data-amount）の記述を表にまとめます。

いちばん見落としやすいのは、CDNのキャッシュに当たっても転送量は減らないという点です。microCMSのコンテンツAPIはCloudFrontというCDNを経由して返りますが、キャッシュはサーバー側の負荷と応答の速さに効くもので、転送量の計上からは外れません。「キャッシュが効いているから大丈夫」は、無料プランの上限に対しては成り立たないのです。

もう1つは、画像の重さです。ヘルプ「データ転送量を節約する方法は？」は、転送量の多くを占めるのは画像の取得だと説明しています。コンテンツAPIのJSONは1回あたり通常数KBなのに対し、画像は1回で数MBになることがある、という書き方です。同じヘルプには、1MBの画像を表示するページに月100万回アクセスがあると、約1TBになるという計算例も載っています。

なぜ私たちのサイトは20GBに届いたのか

止まった後に作りを見直すと、原因は2つありました。どちらも、記事が数本しかない開発の初期には問題にならず、記事が数百本に増えてから効いてきたものです。

原因1：60秒ごとに、全記事を本文ごと取り直していた

サイトは、一定時間ごとにページを作り直す仕組みで動いていました。その間隔が60秒で、しかも作り直すたびに全記事を本文ごとAPIから取り直していました。記事一覧に要るのは題名・日付・説明文だけなのに、本文のHTMLまで毎回運んでいたことになります。

原因2：ビルドのたびに、同じデータを約1,700回取り直していた

サイトを公開し直す（ビルドする）たびに、ページごとに同じAPIを呼ぶ作りになっていて、10月19日までのビルドは1回で約1,700回APIを取り直していました。記事を1本足して公開するたびに、この回数が走ります。

どのくらいで20GBに届くのか（仮の計算）

実際に何GBのうち何が画像で何が本文だったかは、私たちは測っていません。そこで、考え方を示すために仮の数字で計算してみます。

• 全記事を本文ごと1回取ると2MBになる、と仮定する
• 60秒ごとに取り直すと、1日に1,440回。2MB×1,440回＝約2.9GB／日
• この速さなら、約7日で20GBに届く

実際には、作り直しはアクセスがあったときだけ走るなど条件で回数が変わりますし、ここに画像の取得とビルドの分が乗ります。大事なのは数字そのものではなく、「取得1回の重さ×回数」で決まるという構造です。記事が増えると1回の重さが増え、間隔が短いと回数が増える。この2つが掛け算で効きます。

20GBに近づいていることの見分け方

止まる前に気づくための入口は、管理画面と通知の2つです。どちらもmicroCMSのドキュメント「データ転送量」に書かれています。

管理画面の「データログ」で、月の途中の合計を見る

• 管理画面の「サービス設定」→「データログ」→「データ転送量」で確認できる
• グラフは月ごとの合計と日ごとの転送量を表示し、カーソルを合わせると「当日の転送量」と「月初から当日までの合計」が出る
• 見られるのは直近3か月まで。それより前のデータは確認できない
• 同じ画面の「コンテンツ取得回数」で、GET APIとメディアの取得回数を日ごとに見られる

日ごとの転送量に、月初から同じ高さの棒が毎日並んでいるなら、アクセスではなくサイト側の取得の作りが原因である可能性が高い、と読めます。アクセスが原因なら、記事が読まれた日に山ができるはずだからです。

無料プランは10GB・16GB・20GBで通知メールが届く

• Hobbyプランでは、転送量が10GB・16GB・20GBに届いた時点でそれぞれ通知される
• 通知は管理者ロールのメンバーにメールで届く
• 任意の値（GB単位・最大10個）で通知を設定できるのは、Team・Business・Enterpriseプラン

つまり無料プランで最初の警告が来るのは、上限の半分の10GBです。ここで一度、通知が誰のメールに届くのかを確かめておいてください。管理者ロールのメンバーが普段見ていないアドレスだと、10GBと16GBの警告が誰にも読まれないまま、20GBで止まることになります。

キャッシュが効いているかを確かめる

キャッシュは転送量を減らしませんが、作り直しの回数が想定どおりかを確かめる手がかりにはなります。ヘルプ「コンテンツAPI（GET）のキャッシュはどのように利用されますか？」によると、レスポンスヘッダの x-cache が「Hit from cloudfront」ならキャッシュ、「Miss from cloudfront」ならオリジンからの応答です。

curl -I "https://（サービスID）.microcms.io/api/v1/（エンドポイント）" -H "X-MICROCMS-API-KEY: （APIキー）"

止まったときの戻し方は3つ

無料プランでAPIが止まったときに取れる手は、次の3つです。どれが正しいかは、記事をどう書いて、どう出しているかで変わります。

1. Teamプラン以上に上げる

いちばん早い戻し方です。ドキュメント「料金プランの変更」によると、有料プランは14日間の無料トライアルから始まり、トライアル終了時点から1か月先払いで請求が始まります。ここで気をつけたいのは、支払い情報を登録しないままトライアルが終わると自動的にHobbyへ戻り、その時点で上限を超えていれば、即座にメディア配信とAPIが停止すると書かれていることです。トライアルで一時的に戻しても、根本の作りを直さなければ、トライアル明けにもう一度止まります。

2. 翌月1日の午前9時まで待つ

費用はかかりませんが、それまでサイトは止まったままです。月の後半に止まった場合や、止まっても読者が困らないサイトなら選べます。ただし、私たちのように失敗時に見本の記事を出す作りになっていると、待つ間ずっと間違ったサイトマップを検索エンジンに出し続けることになるので、この選択肢は取れません。

3. 記事を書き出して、サイトのリポジトリに置く（私たちが選んだ方法）

私たちはこの方法を選びました。理由は、記事を書くのがAIで、原稿がすべて手元にあり、microCMSの編集画面を誰も使っていなかったからです。CMSが担っていたのは「原稿を置いて配る」役だけで、それなら原稿から直接HTMLを書き出してサイトに置けば足ります。

手順は次のとおりでした。

1. 手元の原稿から、記事ごとのデータを書き出すスクリプトを作る
2. 画像もmicroCMSから外し、WebPに変換してサイトに置く
3. 止まる前の本番の記事と、題名・説明文・日付・本文のHTMLが一致することを、全記事で機械的に照合する
4. 一致を確かめてから公開する。公開の手順は1本のスクリプトにまとめ、microCMSへ記事や画像を上げていた古いスクリプトは止めた

3の照合で、違いは1本だけでした。その違いも、手元の原稿のほうが正しい（本番側の抜粋と説明文の日付が古かった）ものでした。照合をせずに書き出しに切り替えると、「止まる前と同じものが出ているか」を誰も保証できません。移し替えのときは、移す前の状態を正解として突き合わせるのが要です。

この方法をすべての人には勧めません。社内の人がmicroCMSの編集画面で記事を書き、下書き・予約公開・レビューの機能を使っているなら、CMSをやめると運用が回らなくなります。その場合は、1のアップグレードと、次の章の作りの見直しを組み合わせるのが現実的です。

外部サービスの都合で止まったものを、手元の正本から別の形に移し替えた例として、メール配信サービスを乗り換えた記録も参考になると思います。

SendGridからResendへ移行した実案件の手順とハマりポイント

20GBで止まらない作り方：5つの見直し

無料プランのまま使い続けたい場合も、有料プランで超過の請求を抑えたい場合も、見直すところは同じです。私たちの原因と、microCMSの公式ヘルプの内容から、効くものを5つにまとめます。

1. 必要な項目だけを取る（fieldsで本文を外す）

コンテンツAPIの一覧取得には、取得する項目を指定する fields パラメータがあります（ドキュメント「GET /api/v1/{endpoint}」）。記事一覧やサイトマップに本文は要りません。fields=id,title,publishedAt のように必要な項目だけを指定すれば、1回の取得の重さが大きく下がります。私たちの原因1は、ここを指定していなかったことでした。

2. 作り直しの間隔を延ばす、または更新したときだけ作り直す

60秒ごとに作り直す必要がある記事は、ほとんどありません。間隔を延ばすだけで回数が減ります。さらに、microCMSにはコンテンツの更新時に外部へ知らせるWebhookの機能があるので、「記事を更新したときだけ作り直す」作りにすれば、記事が変わらない日の取得はほぼゼロにできます。

3. ビルドのときの取得を1回にまとめる

ページごとに同じAPIを呼んでいると、ページ数のぶんだけ取得が走ります。ビルドの最初に1回だけ全件を取り、各ページはその結果を使い回す作りにすれば、原因2の約1,700回は、記事の数に応じた数回の一覧取得で済みます。

4. 画像を軽くする、またはCMSの外に置く

転送量の多くを占める画像には、microCMSの画像APIが効きます。ヘルプ「データ転送量を節約する方法は？」の比較では、1.14MBのJPEG画像が次のように軽くなっています。

• ?fm=webp（WebPに変換）で750.41KB、約36%削減
• ?q=50（品質を50に）で466.72KB、約60%削減

同じヘルプは、表示サイズに合わせて小さくする（w・h）、画面幅に応じて読み分ける、遅延読み込みをする、動画は埋め込みか外部ストレージから配信する、も挙げています。ただし、画像APIで変換しても変換後のサイズで転送量に数えられる点は変わりません。私たちは画像をWebPにしてサイト側に置き、microCMSから配信すること自体をやめました。

5. 失敗したときに「見本の記事」を出さない

私たちの被害を大きくしたのは、APIの失敗時に見本の記事へ切り替える作りでした。本番では、取得に失敗したらビルドを失敗させて直前の正しい版を出し続けるか、エラーとして目に見える形にするほうが安全です。見本のデータは開発環境だけで使い、本番の設定では読まないようにしておきます。

そのうえで、正本（原稿）を外のサービスだけに置かず、手元にも持っておくことです。今回、私たちが止まっていることに気づいたその日のうちに戻せたのは、原稿がすべて手元にあったからでした。CMSが止まっても、正本が手元にあれば別の形で出し直せます。

よくある質問

APIの呼び出しが無制限なのに、なぜ止まるのですか？

無制限なのは呼び出しの回数で、止まる条件はデータ転送量（運んだデータの量）だからです。無料プランの転送量は月20GBで、超えると即時にAPIが止まります。

CDNのキャッシュを効かせれば、転送量は減りますか？

減りません。microCMSのドキュメントは、CDNのキャッシュから転送された分も転送量に含めると明記しています。減らすには、1回に運ぶ量（本文を外す・画像を軽くする）か、取得の回数そのものを減らす必要があります。

APIが止まったら、microCMSに入れた記事は消えますか？

公式のヘルプが説明しているのは「APIが停止する」ことと「Teamプラン以上へのアップグレードで再開する」「翌月1日の午前9時に解除される」ことで、コンテンツの削除には触れていません。ただし、止まっている間はAPIから記事を取り出せないので、原稿を手元に持っていないと、書き出して別の形で出す手は取れません。

止まったのが月の途中なら、どうするのがよいですか？

残りの日数と、編集画面を使っているかで決まります。編集画面で人が書いているならTeamプランへのアップグレードが早く、原稿を手元に持っていて編集画面を使っていないなら、書き出してサイトに置く方法も選べます。どちらの場合も、取得の作りを直さないと翌月また同じ時期に止まります。

まとめ

• microCMSの無料プラン（Hobby）は、データ転送量が月20GBを超えると即時にAPIが止まる。呼び出し回数の「無制限」とは別の話（2026年10月27日時点）
• 止まったAPIは、Teamプラン以上へのアップグレードで再開するか、翌月1日の午前9時に解除される
• 転送量には、CDNのキャッシュから返った分、管理画面での画像表示、画像APIの変換後のサイズも数えられる
• 無料プランの通知は10GB・16GB・20GBで、届くのは管理者ロールのメンバー。宛先を確かめておく
• 止まらない作りは、必要な項目だけ取る・作り直しを減らす・ビルドの取得をまとめる・画像を軽くするかCMSの外に置く・失敗時に見本を出さないの5つ

私たちの場合、上限に届いた直接の原因は「60秒ごとに全記事を本文ごと取り直す作り」と「ビルドのたびの約1,700回の取得」でした。どちらも記事が少ないうちは表に出ず、数百本に増えてから効いてきます。microCMSでサイトを育てている方は、記事が増えてきたところで一度、データログの日ごとのグラフを見てみてください。株式会社Fyveでは、こうしたサイト運用で実際に起きたことを、これからも記録として公開していきます。