Timpibotは、Timpiという分散型検索プロジェクトのために働くクローラーです。ふつうの検索エンジンが1社の巨大なデータセンターにインデックスを集約するのに対し、Timpiは「独立したノード運営者の分散ネットワーク」がインデックス構築を分担する設計を掲げています。Timpibotはその分散ネットワークが使う収集ボットで、集めたインデックスは検索用途だけでなくLLMの訓練にも使われ得る、と第三者観測では説明されています。挙動としては学習・収集系に典型的な“波のある巡回”——収集パス（＝一括収集の実行期間）が始まると1回の来訪で大量のページを取得し、終わるとぱたりと止む——になりやすく、その時々でどのサイトを・どれくらいの頻度で・どこまで深く巡回するかは運営側が決めます。
サイト側から見ると、TimpibotはUA文字列に「Timpibot」を含めて来訪します。運営者はアクセスログ（＝サーバーが記録する来訪履歴）でこの名前を部分一致で数えれば来訪を検知でき、robots.txt（＝クローラーに巡回可否を伝える取り決めファイル）で拒否できます。ただし前述のとおり、Timpibotは公式の検証手段を公開していません。これは、たとえば大手検索エンジンが自社ボットのIPアドレス一覧を機械可読ファイルで配って「このIPからのものだけが本物」と示すのとは対照的で、Timpibotではその照合ができないため、UA名の一致だけでは本物と断定できない、という制約を意味します。
Timpibotは、知名度こそ高くないものの、「無名ボットも把握が要る」ことの典型例です。学習・収集系のボットは大手だけでなく、Timpiのような新興・分散型プロジェクトからも次々に現れます。これらを一括りに無視すると、(1) サーバー負荷の増減の原因が読めなくなる、(2) 自社コンテンツがどんな経路で訓練データに取り込まれ得るかを把握できなくなる、という2つの実害が生じます。一方で、Timpibotのアクセスが多いこと自体は「AI検索で評価が上がった」ことを意味しません。学習・収集系である以上、量は成果ではなく、回答での引用可視化とは無関係だからです。当ラボが学習系と回答系を分けて計測しているのは、この取り違えを防ぐためです。
検証方法が未公開＝UA名の一致は「手がかり」であって「証明」ではありません。| 項目 | 内容 |
|---|
| 所有者 | Timpi（分散型検索プロジェクト。独立ノード運営者のネットワーク） |
| 3分類での位置 | 学習・収集系（AIデータスクレイパー＝訓練用収集） |
| 主目的 | 分散型検索インデックスの構築。集めたインデックスはLLM訓練にも使われ得る |
| UAの手がかり | UA文字列に「Timpibot」を含む |
| 公式の検証方法 | 未公開（IPレンジ照合等の本物確認手段が提供されていない） |
| robots.txtの尊重 | 尊重する前提だが、検証手段がないため実測での確認が要る |
| AI検索での意味 | 訓練データ候補に入り得るだけ。回答引用の証拠ではない |
robots.txtで拒否するなら、`User-agent: Timpibot` の行に続けて `Disallow: /` を書けばサイト全体を対象にできます。部分的に守りたい場合は `/` を対象パスに置き換えます。ただしTimpibotは検証方法を公開していないため、「robots.txtを尊重しているか」を運営者側から確実に検証する手段がありません。確実に止めたいなら、robots.txtに頼るだけでなく、ファイアウォールやWAF（＝Webアプリを守る防御層）でアクセス元IP単位・レート単位の遮断を併用するのが現実的です。
- 所有者・用途：Timpiは独立ノード運営者の分散ネットワークで検索インデックスを作るプロジェクト。そのインデックスはLLM訓練にも使われ得る（第三者観測に基づきます）。
- UA検知の手がかり：アクセスログのUA文字列に「Timpibot」を部分一致で含むかで判別します。
- robots.txtでの拒否例：`User-agent: Timpibot` の行に `Disallow: /` を続けるとサイト全体を拒否できます。
- 検証の限界：Timpibotは公式の検証方法を公開していないため、UA一致はあくまで手がかりです。詐称を排除するには、通信の実測（IP・挙動）で総合判断するしかありません。
Timpiが掲げる「分散型検索」は、既存の検索が一部の巨大企業に集中していることへの対抗として語られる考え方です。従来の検索エンジンは、1社が世界中のWebをクロールし、自社のデータセンターにインデックスを抱え込み、そのランキングも1社が握ります。Timpiのような分散型プロジェクトは、このインデックス構築を独立したノード運営者（＝自前のサーバー資源を提供する参加者）に分散し、特定の1社に依存しない検索基盤を作ることを目指します。Timpibotは、その分散ネットワークが公開Webを収集するための共通の名乗りにあたります。設計思想としては魅力的ですが、サイト運営者から見ると「誰が・どのノードから・どんな頻度で来るか」が読みにくく、集中型の検索クローラーより挙動の予測が難しいという含意があります。
もう1つの含意は「収集の出口が二重」であることです。Timpiのインデックスは、(1) 分散型検索そのものの検索結果を返すために使われるだけでなく、(2) LLMの訓練データとしても使われ得る、と第三者観測は説明します。つまり、検索用途（回答・検索系に近い側面）と訓練用途（学習・収集系の側面）が混在します。当ラボの3分類では、こうした混在型は「主たる出口」で判断するのが実務的で、Timpibotについては訓練にも使われ得る点を重く見て「学習・収集系」に置いています。ただしこの位置づけは一次情報が乏しい前提の暫定判断であり、Timpi側の情報開示が進めば見直す余地があります。混在型のボットを扱うときは、分類ラベルを固定的に信じ込まず、「主目的が変わったら分類も更新する」という前提で運用するのが安全です。
Timpibotのような一次情報の乏しいボットに向き合うときの原則は、「分からないことを分かったふりで断定しない」ことです。用途・頻度・robots.txt尊重の実態のいずれも、公式が明示していない以上、当ラボは第三者観測を引用しつつ「観測に基づく」と明記して扱います。サイト運営者にとっての実践的な帰結は明快で、断定できない相手には“最小権限”の発想——すなわち、積極的に許可する理由がなければ、まずrobots.txtで拒否側に倒し、負荷や実害が無ければそのまま様子を見る——が無難です。回答・検索系のように「許可することで露出という見返りがある」ボットと違い、Timpibotのような学習・収集系は、拒否してもAI検索の露出への直接の損失が小さいためです。
Timpibotを主要ボットと分ける最大の差は「検証手段の有無」です。OpenAIやAnthropic、Perplexityといった主要各社は、自社ボットのIPアドレス範囲を機械可読ファイル（bots.json 等）で公開し、「このIPからのものだけが本物」と運営者が確かめられるようにしています。Timpibotにはこの仕組みがありません。したがって、GPTBotやPerplexityBotなら「UA名＋公式IP照合」で本物を裏付けられるのに対し、TimpibotはUA名の一致という弱い手がかりしか得られず、詐称と本物を切り分ける手段が実運用では限られます。「無名で、かつ検証できない」ボットは、負荷や不審挙動が出たときに、UAを信じるのではなくIP・挙動の実測で総合判断するしかない——この点をあらかじめ設計に織り込むことが重要です。
検証手段の有無が、無名ボットと主要ボットの実務上の最大の差になります。| 観点 | Timpibot | 主要ボット（GPTBot / PerplexityBot 等） |
|---|
| 公式IPレンジの公開 | なし（検証方法未公開） | あり（bots.json 等で公開） |
| 本物確認の方法 | UA一致という手がかりのみ | UA照合＋IP照合の二段で裏付け可 |
| 所有者の情報開示 | 乏しい（第三者観測に依存） | 公式ドキュメントが整備 |
| 実務での扱い | IP・挙動の実測で総合判断 | UA＋IPで機械的に判定可 |
横にスクロールできます
- 方針を決める：自社の公開情報が分散型インデックスやLLM訓練に取り込まれることを許容するか、拒否するかを、自社の考えとサーバー負荷から判断します。
- robots.txtを整える：拒否するなら `User-agent: Timpibot` に `Disallow: /` を書きます。部分的に守るなら対象パスを指定します。
- ログでUAを集計する：Timpibotの来訪を、回答・検索系ボットと混ぜず「学習・収集系」として分けて数えます。
- 検証の限界を前提にする：Timpibotは検証手段が未公開なので、UA名の一致だけで本物と判断しません。負荷や不審挙動はIP・挙動の実測で総合判断します。
- 確実に止めたい場合：robots.txtに加え、ファイアウォールやWAFでIP単位・レート単位の遮断を併用します。
補足として、Timpibotのような「無名かつ検証手段のないボット」は、個別に完璧な対応を狙うより、収集系ボット全体を束ねて扱う運用に組み込むのが現実的です。具体的には、(1) アクセスログを定期的に棚卸しし、見慣れないUAが一定量を超えたら分類（学習・収集系か、回答・検索系か、user-triggeredフェッチャーか）を判定する運用を回すこと、(2) 学習・収集系はまとめて拒否する方針なら、既知の主要ボットに加えてTimpibotのような新顔も随時robots.txtへ追記していくこと、(3) robots.txtを尊重しない可能性を前提に、負荷が実害になる水準を超えたらIP・レート単位の遮断へ切り替える閾値を先に決めておくこと、の3点です。Timpi個別の情報が乏しくても、この「分類して束ねる」運用があれば、新しい無名ボットが現れても同じ手順で処理でき、対応が場当たりになりません。
Timpibotのアクセスが増えました。AI検索で評価が上がった証拠ですか？
いいえ。Timpibotは分散型インデックスの構築とLLM訓練に使われ得る学習・収集系です。量が多くても、AIの回答での引用可視化とは無関係です。成果は回答・検索系の露出で測ってください。
Timpibotをブロックすると何が起きますか？
主にTimpiの分散型インデックスや、それを訓練に使うLLMのデータから自社が外れることです。Timpibotは回答の出典掲載に直結しないため、AI検索の露出への影響は限定的で、サーバー負荷軽減のメリットが上回る場合が多いです。
UAが「Timpibot」なら本物と信じてよいですか？
いいえ。Timpibotは公式の検証方法を公開していないため、UA名の一致は手がかりにすぎず、誰でも詐称できます。負荷や不審挙動があるときはIP・挙動の実測で総合的に判断してください。
分散型検索のクローラーは、ふつうの検索クローラーと何が違いますか？
技術的なアクセスの仕方は似ていますが、集約か分散かが異なります。ふつうの検索クローラーは1社が集中管理するため所有者・IP範囲がはっきりしますが、Timpiのような分散型は独立ノードがインデックス構築を分担する設計で、「誰がどのノードから来るか」が読みにくく、集中型より挙動の予測と本物確認が難しくなります。
