SERP APIの料金体系は一見シンプルだ。1,000検索あたりの価格と、いくつかの月額プランがある。しかし実際に届く請求書は、チームが予想していたものとは異なることが多い。プロジェクトに必要な検索数は、気づかないうちにコストを左右するいくつもの判断の積だからだ。都市をもう少し追跡する、モバイルを追加する、もう1ページ深く見る、週次ではなく日次でチェックする。こうした選択のたびに、ボリュームは掛け算的に増えていく。
このガイドでは、SERP APIの請求書をその構成要素に分解し、2025年にディープなランク追跡のコストを10倍に押し上げた変更について説明し、使わないデータに料金を払うことなく、必要なデータだけを買うためのワークロード設計の方法を示す。自分の数値とどのプロバイダーの価格表にも当てはめて実行できる小さな計算ツールも含まれている。
要点
- 月間検索数は、キーワード数×ページ数×ロケーション数×デバイス数×エンジン数×月間チェック回数で決まる。各要素は互いに掛け合わされる。
- 現在、最もコストを押し上げる要素は深さだ。Googleが2025年9月に1ページで100件の結果を返すパラメータを廃止して以来、トップ100の追跡には1リクエストではなく10リクエストが必要になった。
- 最も手軽な節約は頻度の調整であることが多い。変動が激しく価値の高いキーワードは日次で、ロングテールは週次でチェックする。
- プロバイダーを比較する際は、表面上の単価だけでなく、何に対して課金されるかを見る。失敗したリクエストやキャッシュされたリクエストがカウントされるか、すべてのエンジンが含まれているか、超過分の扱いはどうかといった点だ。
- まずワークロードを計画し、その後にプランを選ぶ。本記事の例では、段階的なスケジュールにより、優先キーワードのトップ100カバレッジを、すべてを日次でトップ100まで追跡する場合の約8分の1のボリュームで実現した。
実際に何に対して料金を払っているのか
我々のサービスを含め、ほとんどのSERP APIは検索リクエスト単位で課金される。1リクエストは、1つのクエリ、1つのロケーション、1つのデバイス、1つのエンジンにおける、ある瞬間の1つの結果ページを意味する。それ以外のすべては、この単位から導かれる。
| 要素 | 意味 | 一般的な範囲 |
|---|---|---|
| キーワード | 追跡するクエリ | 数十件から数十万件 |
| 深さ | 必要な順位の範囲。10件の結果が1ページであり、1ページが1リクエスト | 10から100 |
| ロケーション | 個別に追跡する国、地域、都市 | 1から数百 |
| デバイス | デスクトップとモバイルで結果が異なるため、両方を追跡するとボリュームは倍になる | 1または2 |
| エンジン | Google、Bing、Yandexなど、それぞれが個別のリクエストになる | 1から3 |
| 頻度 | 各組み合わせをチェックする頻度 | 月1回から1日数回 |
これらを掛け合わせると、規模は一目瞭然になる。500キーワード、2デバイス、5都市、日次チェックでは、1ページ目を超える前に月150,000リクエストに達する。
なぜ深さのコストが10倍になったのか
長年、ランクトラッカーはGoogleに対し、num=100というURLパラメータを使って1ページで100件の結果を要求していた。1回のリクエストでトップ100全体が返ってきたのだ。2025年9月中旬、Googleはこのパラメータを廃止し、これに依存していたツールは、10件ずつページをめくる方式に切り替えるまで、欠落を表示するようになった。
コストへの影響は直接的だ。1つのキーワードのトップ100を追跡するには、今では10リクエストが必要であり、同じ深さのコストが10倍になる。多くのチームにとって、これは「どこまで深く追跡できるか」という問いを、「実際にどこまで深く追跡する必要があり、それはどのキーワードについてか」という問いに変えることになる。ほとんどのクリックは1ページ目に集まるため、多くのキーワードにとって、1ページ目に入っているかどうか、おおよそどの位置にいるかが、意思決定に関わる事実となる。
自分のワークロード用の計算ツール
以下のモジュールは、1つまたは複数の追跡スケジュールに対する月間リクエスト数を計算する。この結果に、各プロバイダーの1,000件あたりの価格を掛け合わせれば、プラン同士を比較できる。
import math
from dataclasses import dataclass
RESULTS_PER_PAGE = 10 # Googleは2025年9月にnum=100の尊重を停止したため、10件ごとに1回の呼び出しが必要になる
@dataclass
class Workload:
keywords: int
depth: int # 必要な順位の範囲: 10、20、100...
locations: int = 1
devices: int = 1 # デスクトップとモバイルを別々に追跡する場合は2
engines: int = 1
checks_per_month: float = 30.0
def calls_per_month(self):
pages = math.ceil(self.depth / RESULTS_PER_PAGE)
return math.ceil(self.keywords * pages * self.locations * self.devices * self.engines * self.checks_per_month)
def summarise(name, workloads):
calls = sum(w.calls_per_month() for w in workloads)
return f"{name}: {calls:,} calls a month"典型的な4つのワークロードで実行する:
from serpcost import Workload, summarise
WEEKLY = 52 / 12 # 週次スケジュールの月間チェック回数
print(summarise("500 keywords, top 10, daily", [Workload(500, 10)]))
print(summarise("500 keywords, top 100, daily", [Workload(500, 100)]))
print(summarise("Tiered: top 10 daily, plus top 100 weekly for 100 priority keywords",
[Workload(500, 10), Workload(100, 100, checks_per_month=WEEKLY)]))
print(summarise("200 local keywords, 5 cities, desktop and mobile, weekly",
[Workload(200, 10, locations=5, devices=2, checks_per_month=WEEKLY)]))500 keywords, top 10, daily: 15,000 calls a month
500 keywords, top 100, daily: 150,000 calls a month
Tiered: top 10 daily, plus top 100 weekly for 100 priority keywords: 19,334 calls a month
200 local keywords, 5 cities, desktop and mobile, weekly: 8,667 calls a month2行目と3行目がポイントだ。500キーワードを毎日トップ100まで追跡すると、月150,000リクエストになる。すべてのキーワードを1ページ目まで日次で追跡し、最も重要な100キーワードだけをトップ100まで週次で追跡すると、19,334リクエスト、約8分の1で済み、それでもランキングレポートが使われるほぼすべての問いに答えられる。
支出を減らす7つの方法
- 深さを意思決定に合わせる。 ほとんどのキーワードは1ページ目まで追跡し、順位が40位から15位に動くことで取るべき行動が変わるキーワードについてのみ、さらに深く追跡する。
- 頻度を段階化する。 価値が高く変動の激しいキーワードは日次で、安定したロングテールキーワードは週次でチェックする。SERPのボラティリティを検知する方法についてのガイドでは、自分のデータからどちらに該当するかを見分ける方法を紹介している。
- 違いが出るロケーションだけを追加する。 都市レベルの追跡はローカルインテントにとって重要だが、情報収集目的のクエリにとってはその重要性はずっと低い。都市レベルのターゲティングが重要になる場合では、その判断方法を解説している。
- 両方のデバイスを追跡するのは、結果が分岐する場合だけにする。 まずサンプルでデスクトップとモバイルを測定し、順位が近ければ一方だけを追跡し、もう一方は抜き取りで確認する。
- クライアントやチーム間での重複を排除する。 代理店は、同じキーワードを同じロケーションで複数のクライアント向けに追跡していることが多い。一度取得して結果を共有する。
- 日内でキャッシュする。 複数のシステムが同じ結果ページを必要とする場合、最初のレスポンスを保存し、再度リクエストするのではなく再利用する。
- 試行ではなく結果に対して支払う。 失敗したリクエスト、リトライ、キャッシュされたレスポンスが課金対象になっているかを確認する。失敗分は、あらゆる請求書に隠れた形で含まれているからだ。
プロバイダーを公平に比較する
1,000件あたりの表面上の価格は、単位がそろって初めて比較可能になる。SERP APIを比較する際は、以下を確認しよう。
| 質問 | 重要な理由 |
|---|---|
| 「1検索」とは1つの結果ページを指すのか、それともさらに深いページネーションには追加のクレジットがかかるのか | 深さの実際のコストを左右する |
| 失敗したリクエスト、空のリクエスト、リトライされたリクエストは課金対象か | 失敗分は、あらゆる請求書に隠れた割合で含まれる |
| すべてのエンジンと結果タイプが含まれているか、それとも別料金か | Googleのウェブ結果以外を追跡するコストを左右する |
| ロケーションとデバイスのターゲティングは同じ料金に含まれているか | 都市レベルやモバイルの追跡で料金が変わるかどうかを左右する |
| プランの上限を超えた場合はどうなるか: 完全停止か、超過料金か、自動アップグレードか | 繁忙月の実際のコストを左右する |
| 結果はライブなのか、キャッシュから提供されるのか、それは明示されているか | データの鮮度を左右する |
クリーンレコードあたりのコストという原則はここにも当てはまる。意味のある数字は、リクエストあたりの定価ではなく、失敗、リトライ、重複を差し引いた後の、使用可能な結果ページあたりの実際の支払い額だ。
自社構築か購入か
プロキシを通じて自前で収集を行う方が、非常に大きなボリュームでは安くつく場合がある。しかしそこには、パース処理、メンテナンス、そしてnum=100の廃止のような変更に対応し続ける作業が伴う。SERP APIは、その作業をプロバイダー側に移す。SEOプラットフォームがSERP APIをどう使っているかでは、その境界線が通常どこにあるかを取り上げており、日次キーワード順位モニタリングの自動化では、SERP APIを使った完全なパイプラインを紹介している。
まとめ
SERP APIの請求額は、キーワード数、深さ、ロケーション数、デバイス数、エンジン数、頻度の積であり、Googleが1ページあたり100件の結果を返すのをやめて以来、深さが最も速く増幅する要素になっている。支出を減らす方法は、1,000件あたりの最安値を探すことではなく、意思決定を左右するリクエストだけを買うことだ。ほとんどのキーワードは1ページ目まで、重要な一部のキーワードはさらに深く、順位が動く場合は日次で、動かない場合は週次で追跡する。
プランを選ぶ前に、自分のワークロードでこの計算ツールを実行し、各プロバイダーの料金を掛け合わせて、同じ条件同士で比較しよう。
出典と参考文献
- Search Engine Journal、Googleが検索結果パラメータを変更、SEOツールに影響、2025年9月。