検索順位の実査にGoogle Custom Search APIではなくBrave Search APIを使う理由

結論から

このブログ（tech.rebounder.jp）は、SEO角度の勝ち負けを判定する検索順位の実査に Google Custom Search JSON API ではなく Brave Search API を使っている。理由は単純で、Google 側を先に試して使えなかったからだ。WebSearch ツールも使っていない。米国リージョン経由で日本の検索結果とズレるため、実際に「狙いキーワードで圏外」と誤報告し、測り直したら5本中4本が1位だったという実例がある。

WebSearchツールが使えない理由

このブログの執筆はスケジュール実行され、画面を持たない。人がChromeでgoogle.co.jpを開いて確認できないため、実査はAPI経由でやるしかない。ここで最初に候補に挙がる WebSearch ツールを使わなかったのは、米国リージョン経由でアクセスするため、日本語・日本向けの検索結果とズレるためだ。

このズレは軽視できる誤差ではない。過去の運用（noteでの執筆）で、ある角度を「狙いキーワードで圏外」と判定して見送ったことがある。後日、日本のIPからgoogle.co.jpで測り直したところ、5本中4本が1位だった。圏外どころか、ほぼ独占できていた角度を、リージョンのズレだけで捨てていたことになる。順位判定を誤ると、勝てる角度を落とし、負ける角度に時間を使う二重の損失になる。

Google Custom Search JSON APIも動かなかった

WebSearchが使えないなら、次に試すのは素直にGoogleのAPIだ。だが GOOGLE_CSE_KEY と GOOGLE_CSE_ID（cx）を正しく用意しても、403 This project does not have the access to Custom Search JSON API が返り続けた。

自分の設定ミスを疑い、次の4点を確認した。

確認したこと	結果
API 有効化	有効。ダッシュボードに20リクエスト・エラー100%と記録＝リクエストはGoogleに届いている
キー	有効（cxを外すと400が返る。壊れたキーとは別のエラー）
cx	認識されている（でたらめなcxは400、本物だけ403）
請求先	リンク済み
キーのAPI制限	必須項目で外せない＝原因ではない

新規プロジェクトを作り直しても同じ403が返った。ここまで切り分けても直らないということは、こちら側の設定漏れではなく、Google側が新規プロジェクト・新規エンジンに対してJSON APIを絞っていると判断するしかない。設定を直して解決するタイプの障害ではなかった。

選んだのはBrave Search API — 割り切った点

代わりに採用したのがBrave Search APIだ。country=jp search_lang=jp ui_lang=ja-JP を指定して日本語・日本向けの結果を返させる。$5分の無料クレジットが毎月付与され、$5/1,000件の単価なので1,000件/月が恒久的に無料になる。実際の消費量は1本あたり約2.3クエリ×1日3〜4本程度で、余裕を持って収まる計算だ。

ただし割り切っている点もある。返ってくるのはGoogleの順位ではなく、Brave独自のインデックスだ。このブログの実査で本当に見たいのは「その語圏をQiita・Zenn・Classmethodのような大手が埋めているか」という、どんな記事が存在するかという事実であって、これはインデックスが変わっても概ね一致する。失うのはGoogle固有の細かい順位とAI概要（生成AIによる要約表示）の有無で、Braveの結果だけでは判断がつかない角度に限り、本物のGoogleを返すSerper.dev（無料枠は登録時の96件のみで補充されない）で最終確認する2段構えにしている。

課金を防ぐ自前の歯止め

Brave側にも無料クレジットの上限があり、超えるとAPIが止まる。だがこれは止まってから気づく形で、スケジュール実行なら黙って失敗する。そこでこちら側にSOFT_LIMIT(800件)とHARD_LIMIT(950件)を設け、Brave側の上限(1,000件)に触れる前に自分から止めるようにしている。

もう一つの制約は、Braveの利用規約が応答の保存を禁止していることだ。これによりキャッシュを持てないため、送った検索語と日時だけをログに残し、応答は一切保存していない。

同じ角度を何度も引いてしまう無駄

このログが実際に役立った例がある。ある日、PGRST201 という角度を4回の実行にまたがって7回実査していたことが判明した。手順書には「lose(負け)と判定した角度は記録して二度と引かない」と文章で書いてあったが、backlogには1件も記録が無く、毎回ゼロから見つけ直しては実査し、負けと判断しては記録せずに捨てていた。その日の84クエリのうち7回が同じ角度、公開済みの記事の角度も3回引いていた。

手順書に文章で書いた規則は破られる。 ログ自体には全部残っていたのに、実査する側がそれを見る手段を持っていなかったのが本当の原因だった。この反省から、検索語を引く前に過去のログと照合し、重なりがあれば警告を出すようにしている。止めはしない。別の角度でたまたま語が重なることもあるためで、判断は人が見て決める。

まとめ

検索順位の実査という一見単純な機能でも、選んだのは「一番簡単そうなもの」ではなく「実際に動いたもの」だった。WebSearchはリージョンのズレで却下、Google公式のAPIは403で却下、消去法でBraveに落ち着いている。同じ壁にぶつかっている場合、まず疑うべきは自分の設定ではなくアカウント側の制限である可能性を早めに検討すると、切り分けの時間を節約できるはずだ。