発端: Claude の Web 検索は Brave の索引を引いている
Anthropic の副処理者一覧には、Web 検索の用途で 2 社が載っています（2026 年 10 月 9 日に描画して確認）。
| 副処理者 | 対象の製品 | 用途 |
|---|---|---|
| Brave Search | All products | Web Search |
| TurboPuffer | All Products except Claude for Government | Web Search |
Claude に Web 検索をさせたとき、結果の取得元の 1 つが Brave Search の索引です。Brave の索引に無いページは、この経路では Claude の回答に引かれません。
当社が運営する RIKKA M&A（rikkama.jp）とこのサイト（studioc.co.jp）が Brave の索引にどれだけ入っているかを、10 月 6 日に調べました。
- rikkama.jp:
site:rikkama.jpで 1 件だけ。タイトルはドメイン名から作った「Rikkama」、説明文は「We cannot provide a description for this page right now」でした。URL は知られているが、中身は取られていない - studioc.co.jp: サイトマップの 50 URL のうち 2 件（トップと会社情報）。ドメインを移してから約 7 週間たっていました
調べるところから送信の仕組みを作るところまで、Claude Code と進めました。窓口への送信も、Claude Code がヘッドレスのブラウザを操作して 1 件ずつ行っています。以下はその工程と実測値です。
Brave には登録の仕組みが無い
Google の Search Console や Bing の Webmaster Tools に当たるものを探しました。
| 項目 | 結果 |
|---|---|
| 運営者の管理画面（所有権の確認・サイトマップの送信） | 無い。ヘルプの記事 29 本に該当が無く、それらしい URL は 404 |
| IndexNow | 参加していない。参加エンジンの一覧は bing・yandex・seznam・naver・yep・internetarchive・amazonbot の 7 者 |
| URL の送信 | 再取得の窓口が 1 つだけ。1 回に 1 件で、アカウントも所有権の確認も無く、送信ボタンに CAPTCHA が付く |
| 発見の経路 | 自前のクローラーと、Brave ブラウザの利用者が任意で参加する Web Discovery Project |
窓口は、クローラーのヘルプでは noindex を反映させるための再取得の窓口として案内されています。新しいページを登録する手段とは書かれていません。それでも、運営者から Brave に働きかけられる口はこれしかありません。
両サイトとも新しいページは IndexNow で通知していますが、Brave には届いていませんでした。
最初の送信は 403 を受け、索引から消えた
10 月 6 日 12:26 に、rikkama.jp のトップを窓口から送りました。画面の表示は「Submitted / Success」です。約 70 分後の 13:36 に Brave のクローラーが取りに来て、403 を受けていました。
rikkama.jp は当時、日本以外からの要求を止める地域制限を置いていました。Cloudflare が本物と検証したクローラーは通す条件でしたが、Brave のクローラーの要求は 1 件も検証済みと判定されていません。同じ送信元は、送信の直前の 12:20 に、地域制限の無い studioc.co.jp の /robots.txt を 200 で取っていました。
送信の後に site:rikkama.jp を引くと 0 件でした。中身の無かった 1 件も消えています。
地域制限に、Brave のクローラーの UA と送信元の網に絞った例外を入れ、重要な 3 ページ（上位表示を狙う 2 ページと査定の入口）を 15:40 に送りました。
| 送信 | 取得 | 応答 | 索引 |
|---|---|---|---|
| 15:40（3 件） | 16:47〜16:48（約 67 分後） | 3 件とも 200 | 16:51 に 3 件とも実際のタイトルと説明文で出た |
取得から索引まで約 3 分です。検索結果にはパンくずと、よくある質問の 3 問も出ました。ページの構造化データ（BreadcrumbList・FAQPage）を Brave が読んでいます。
翌 10 月 7 日、Brave は前日と違う IPv4 の範囲から来て例外の網を外れ、送った rikkama.jp の 5 ページがまた 403 になりました。Brave の送信元は 1 日で 5 つ以上の範囲にまたがっていました。網を足し続ける代わりに、地域制限そのものを撤廃しました。判断の前に、地域制限が無くても取引は利用規約と本人確認・日本の携帯電話番号の認証で日本の利用者に限られることを確かめています。地域制限が止めていた探索のうち、サイトに存在しないパスは別のルールで止めるようにしました。
Brave は送ったページからリンクを辿らない
16:48 に Brave が取った /valuation は、査定ページ 5 本へのリンクを持っています。その後の 1 時間 40 分、Brave は 5 本を 1 本も取りませんでした。
studioc.co.jp も同じでした。索引に入っているトップと会社情報から技術記事へリンクしているのに、直近 14 日間に Brave が取ったのは /robots.txt の 3 件だけです。記事も /sitemap.xml も取っていません。
**Brave は送られたページは取るが、そこからリンクを辿っていません。**待っていても索引は広がらないので、ページは 1 本ずつ送るしかありません。後日の巡回でリンクを辿るかは、観察した期間が短く確定していません。
同じ日の 17:37 に、Bing の AI Performance で AI の回答に引用された実績のある 6 ページを送ると、約 63 分後に 6 件とも 200 で取られ、索引に入りました。
利用規約を読んで、自動で送ってよいと判断した根拠
両サイトのサイトマップには、計 510 件の URL があります。窓口は 1 回に 1 件なので、手で送れる量ではありません。
最初（10 月 6 日）は、自動化しないと決めていました。Brave の利用規約の「Rules and Conduct」は、次の 3 つを禁じています。
(i) take any action that imposes or may impose an unreasonable or disproportionately large load on Brave’s (or its third party providers’) infrastructure; or (ii) interfere or attempt to interfere with the proper working of the Service or any activities conducted on the Service; (iii) bypass any measures Brave may use to prevent or restrict access to the Service (or parts thereof).
このときは「CAPTCHA は (iii) の措置に当たり、数百件を機械で流すことは (i) にも触れる」と読み、重要なページだけを選んで 1 件ずつ送ることにしました。
10 月 9 日、送る量を増やすにあたって読み直し、判断を変えました。根拠は 4 つです。
- **禁じているのは自動の利用そのものではない。**規約の本文に automated・robot・scrape・crawl の語は 1 つも無く、禁止は負荷・妨害・制限の迂回の 3 つです
- **CAPTCHA を迂回していない。**窓口の CAPTCHA は Proof of Work で、利用者のコンピューターが数学の問題を計算して通る方式です。ヘッドレスのブラウザは Brave のページそのものを開き、同じ計算をして通ります。計算を飛ばしたり、答えを偽ったりはしていません
- **負荷を不釣り合いにしない。**1 日 100 件を 24 時間に均し、約 14 分（864 秒）に 1 件にします。20 件を約 5 分で続けて送る場合（約 15 秒に 1 件）と比べ、負荷の山は約 60 分の 1 です
- **制限が出たら止める。**送信が Success にならないこと（エラー・CAPTCHA が解けない・429）が 1 件でもあれば止めます。制限が出た後も送り続けることは、(iii) の迂回に当たるからです
CAPTCHA のヘルプは、CAPTCHA の目的を、検索結果を scrape しようとする bot を見分けて止めることだと書いています。当社の送信は自分のサイトの URL を窓口へ渡すもので、検索結果は読みません。索引の確認には、後で書く公式の API を使っています。
白黒がついていない点も 1 つあります。search.brave.com の robots.txt は Disallow: /api を置いており、窓口のフォーム自体が送信時に /api/fetcher を呼びます。この関係は白黒がつかないことを示したうえで、窓口をブラウザで使う形を選びました。
送る量の決め方と、止める条件
Brave は送信の上限を公表していません。窓口・ヘルプ・利用規約・コミュニティを読んで、件数の記載はありませんでした。スパムとして扱われたかを直接知る手段も無いので、観測できる 3 つの反応で境目を測ることにしました。
- 送信が Success になるか
- 送ったページを Brave が取りに来るか（エッジのログで見る）
- 取りに来たページが索引に入るか
1 日の枠を 10 → 20 → 40 件と倍々に増やし、どれか 1 つでも悪くなったら止めて前の段に戻す、という決まりです。10 月 9 日 20 時半の台帳の集計は次のとおりです。
| 日 | 枠 | 送信 | 失敗 | 6 時間以内の取得（初めて送った URL） |
|---|---|---|---|---|
| 10-06 | 10 | 10 | 0 | 10/10 |
| 10-07 | 10 | 10 | 0 | 10/10 |
| 10-08 | 20 | 20 | 0 | 20/20 |
| 10-09 | 100 | 77 | 0 | 72/72 |
取りに来た 112 件はすべて、送信の 56〜72 分後（中央値は約 65 分）でした。倍々でも 1 日 100 件でも在庫を送り終える日は同じだったため、10 月 9 日からは「1 日 100 件まで」にしています。
**取られない送信が 1 種類だけありました。**Brave が直近に取った URL の送り直しです。初めて送った URL は 10 月 6・7 日の 20 件すべてが約 1 時間で取られたのに、既に取られた URL を送り直した 7 回は 1 回も取られませんでした。再取得までの間隔は Brave の記載が無く、長さは分かっていません。送り直しは止める条件の割合から外し、最後の取得から 7 日たったら候補に戻すようにしました。
索引に入ったかを数える
索引の数え方は 3 回やり直しました。
1 回目は、Brave の検索結果ページを site: で取って数えていたことです。search.brave.com の robots.txt は Disallow: /search を置いており、10 月 6 日に WebFetch と curl で 12 回取ったのは robots.txt に反していました。以後は公式の Brave Search API で読んでいます。無料分は毎月 5 ドル（1,000 回分）で、こちらの上限を月 900 回に置きました。
2 回目は API の応答の読み方です。同じサイトの結果は 1 件の下の cluster にまとめて返るのに、上位の URL だけを数え、9 件を 5 件と数えていました。
3 回目は、全体の一覧を索引の全数とみなしたことです。site:rikkama.jp は 40 件で「続きなし」と返る一方、site:rikkama.jp/glossary と区切ると、全体の一覧に無い用語集が 4 件出ました。公式の上限でも 1 回の一覧は 200 件までです。
使えたのは 1 ページずつの照会（site:<ホスト><パス>）でした。索引にあれば本人の 1 件、無ければ 0 件を返します（索引にあるページと、一度も送っていないページで確かめました）。今は、取得 200 の 12 時間後に 1 回、ページごとに確かめています。10 月 9 日の夕方の時点で、取得 200 になった 74 ページのうち 71 ページ（96%）が索引に入っていました。
約 14 分に 1 件の自動送信と、それを見張る仕組み
ここまでの判断を、3 本のスクリプトにしました。
| スクリプト | 役割 |
|---|---|
brave_queue.py | 送る候補を出す（① 新着 ② AI の引用実績 ③ Search Console の表示回数 ④ まだ送っていないページ ⑤ 一覧・タグの順。両サイト交互）。送信を台帳に記録し、エッジのログで取得を、Brave Search API で索引を埋める |
brave_drip.py | 864 秒ごとに起動し、候補があれば 1 件だけ、ヘッドレスのブラウザで窓口へ送る |
brave_watch.sh | 30 分ごとに起動し、送信のジョブが 3 時間以上最後まで動いていなければ通知する |
brave_drip.py は起動のたびに止める条件を判定します。
- 送信が Success にならなければ、止めた印を書いて止まる。印を消すまで送らない
- 毎時、送ってから 80 分〜24 時間たった初めての URL のうち、取られた割合が 9 割を下回れば止まる。Brave は 61〜72 分で来るので、80 分で区切っています
- 毎朝、前日の索引の割合が前々日より下がっていれば、その日の枠を 40 件に下げる
- 候補が 0 件になっても止まらず、新しいページを待つ。公開から送るまでは最大約 14 分です
見張り役は python3 を使わず、シェルだけで書きました。送信のジョブが python3 の不調で止まったとき、見張り役まで一緒に止まらないためです。送信のジョブは最後まで終えたときだけ印のファイルを書くので、その古さを見れば「起動していない」と「途中で落ちた」の両方を拾えます。登録した直後、送信のジョブが最初の 1 回を終える前に、まだ無い印を「とても古い」と判定して「16666666 分前」と通知する誤りを出しました。印が無いときは見張りを始めた時刻から数えるように直し、その誤りを再現する自己テストを足しています。
作る途中で、すでに動いていた送信にも不具合を 2 つ見つけて直しました。止める条件の索引の割合を、40 件で止まる全体の一覧で数えていたため、日を追うごとに実際より低く出て、誤って発火するところでした。また、候補を出すたびに記事の公開日を読むため自分のサイトの本文を取りに行っており、864 秒おきの起動で 1 日約 1 万 500 回になっていました。公開日は 1 度読んだら手元に残すようにしています。
10 月 9 日 20 時半の台帳で、送信は 124 回・失敗は 0 件です。索引にあると確かめたページは rikkama.jp が 42、studioc.co.jp が 29 で、studioc.co.jp は送った 29 ページがすべて入りました。
TurboPuffer には送る口が無い
副処理者一覧のもう 1 社、TurboPuffer も調べました。自己紹介は「vector and full-text search engine」で、顧客が自分の API キーで文書を書き込むデータベースです。クローラー・UA・robots.txt・URL の送信窓口の記載はありません。Anthropic にも、掲載を外す窓口はあるものの、載せる窓口の記載はありません。公式に案内されている索引の経路は、Anthropic のクローラーの Claude-SearchBot の巡回だけです。
その Claude-SearchBot（Cloudflare が検証した本物）は、studioc.co.jp に 9 月 11 日から来ておらず、rikkama.jp には 9 月 9 日に記録を始めてから一度も来ていません。両サイトの robots.txt と WAF は止めていません。来ない理由は公式に記載が無く、確定していません。
それでも Claude の Web 検索で両サイトを引くと、10 件ずつ実際のタイトルで出ました。rikkama.jp の 10 件は、すべて Brave へ送った台帳に行があるページです。
まとめ
- Claude の Web 検索の取得元の 1 つは Brave Search の索引です。Brave には運営者の管理画面も IndexNow も無く、働きかけられるのは 1 件ずつの再取得の窓口だけでした
- Brave は送ったページを約 1 時間で取り、数分で索引に入れます。一方でリンクは辿りません。待っていても索引は広がらないので、ページは 1 本ずつ送ります
- 国で絞る地域制限は、Cloudflare が検証しないクローラーを止めます。最初の送信は 403 を受け、中身の無い 1 件まで索引から消えました
- 利用規約が禁じているのは負荷・妨害・制限の迂回で、自動の利用そのものではありません。1 日 100 件を約 14 分に 1 件へ均し、Success 以外が 1 件でも出たら止める形で自動にしました
- 上限を公表していない相手には、観測できる反応（送信の成否・取得・索引）を先に決め、悪くなったら止める条件を置いてから量を増やします。索引の数え方も、一覧ではなく 1 ページずつの照会で確かめてから信じます