ここ数週間、私は Kadoa のサイトをたびたびチェックしていました。というのも、2026年6月のリブランディングがかなり意外だったからです。ある日は彼らは「AI web scraper」と名乗り、次の日には「Web Scraping OS」と呼んでいました。これはかなり大きな飛躍で、このカテゴリ全体がどこへ向かっているのかをよく示しています。
そこで、読者からも社内メンバーからも何度も聞かれたのがこの疑問です。Kadoa はまだ Thunderbit と比べられるのか、それとも「手早く使えるスクレイピングツール」の枠を完全に抜け出したのか。結論だけ先に言うと、どちらも少しずつ当てはまります。詳しくはこの下で説明します。
まず結論
細かい話に入る前に、要点だけ知りたい方のために、tl;dr をまとめると：
- Thunderbit は、Webページを見ながら「このデータだけ、今すぐ、スプレッドシートに入れたい」と思った瞬間のためのツールです。ワンクリック、スキーマ設計不要、データチームへの依頼も不要です。
- Kadoa は、ガバナンス付きで監視され、継続的に保守されるデータセットを本番運用したい組織向けです。たとえば、金融チームが多くのソースから代替データを毎日取り込み、監査証跡も残したい、といった用途です。
- どちらも「AIスクレイパー」対「手動スクレイパー」という話ではありません。どちらも本当にエージェント型です。違いは、そのエージェントを何のために最適化しているかです。
この最後の点は、思っている以上に重要です。多くの比較記事はこれを単なる機能チェックリストの勝負として扱いますが、実際には、2つの製品が別々の購入者層に向かって進化した、というのが本質です。
一目でわかる比較
| 観点 | Thunderbit | Kadoa |
|---|---|---|
| 主な利用者 | ビジネスユーザー、マーケター、個人運営者、開発者 | エンタープライズ／金融データチーム、中央データ組織 |
| 想定時間軸 | 今すぐ — 目の前のページを抽出 | 本番運用のライフサイクル — パイプラインを構築・承認・保守 |
| セットアップの流れ | One Click Extract をクリック → 自動実行 | プロンプト → スキーマ提案 → パイプライン構築／テスト → 承認 → 定期実行の本番ワークフロー |
| 実行モデル | セッションごとのエージェント型ページ解析 | エージェント支援による保守付きの決定論的パイプライン生成 |
| 保守 | 対応ページでユーザーが再実行 | 自動監視と自己修復（ベンダー説明による） |
| 可観測性 | テーブルプレビュー、微調整 | 成功率、MTTR、出所、SLA ダッシュボード（ベンダー説明による） |
| 利用可能な接点 | ブラウザ拡張、Webアプリ、Open API、MCP Server、CLI | Web Scraping OS プラットフォーム、エンタープライズ導入 |
| 料金 | 公開セルフサーブ料金あり。詳しくは料金ページへ | 営業窓口への問い合わせ制。現時点で公開の料金表なし |
| 最適な用途 | 単発、部門単位、または中程度の頻度で繰り返す業務 | ガバナンス付き、多ソース、継続更新が必要なエンタープライズデータ |
正直に言うと、この表を作るのは想像以上に時間がかかりました。というのも、世の中にある「Thunderbit vs Kadoa」の記事の多くは、どちらにも「AI-powered」とチェックを付けて終わってしまうからです。それでは何も分かりません。
Thunderbit とは？
今の実際の流れは、まさに次のとおりです（古いレビューで書かれている旧 UI ではありません）。
アクセス権のある Web ページを開きます。One Click Extract をクリックします。以上です。Thunderbit のエージェントがページ構造を検出し、内容を読み取り、どの項目が重要かを判断して、抽出準備を始めます。Run Now ボタンも表示されますが、実はクリックしなくても構いません。何もしなければ自動的に開始されます。意図的な1クリックだけで、スキーマ設定もセレクタ指定も不要です。
私はこれを「ツールが邪魔をしない」と表現しています。自動検出された項目が少し違うときは自然言語で修正できますし、対応ページであれば、ページ送りやサブページの拡張もできます。ブラウザ拡張だけでなく、Web App、開発者向けのOpen API、Claude や Cursor のような AI エージェント向けのMCP Server、ターミナル作業向けのCLIもあります。出力先は Excel、Google Sheets、Airtable、Notion です。
これはデータエンジニアリングのスタックに組み込むためのツールではありません。欲しいデータを今すぐ手に入れたい人向けで、チケットを切って待つ必要がないように設計されています。
2026年の Kadoa とは？
ここからが面白いところです。Kadoa の2026年6月の発表では、彼らがWeb Scraping OSと呼ぶものが登場しました。これは「Kadoa Assistant」と呼ばれる仕組みで動いています。彼らの説明する流れは次のとおりです。
- 自然言語で依頼を書く — たとえば「これら12社の競合サイトから、毎日更新される価格データがほしい」
- Kadoa が対象ソースを調査し、最も信頼できる抽出方法を選ぶ（API エンドポイント、埋め込み JSON、ダウンロード可能ファイルなど、最も安定した手段）
- データスキーマを提案する
- 決定論的なパイプラインを構築する — つまり、毎回 LLM が推測するのではなく、実際の抽出コードを生成し、それをテストする
- プレビューを確認して承認する
- スケジューリング、バリデーション、通知を組み込んだ状態で本番稼働する
「Web Scraping OS」という考え方には、自動パイプライン保守、インフラの立ち上げ、可観測性ダッシュボード（成功率、平均復旧時間、SLA 追跡）、データの出所、ガバナンス／コンプライアンスのワークフローが含まれます。これは完全にエンタープライズ向けインフラの言葉で、現在のポジショニングは金融や代替データの用途に強く寄っています。たとえば、監査可能で継続更新されるデータセットを、何十ものソースから集めたいヘッジファンドや資産運用会社のようなユーザーです。
これは「ページをひとつスクレイピングしたい」という用途とは、まったく別の製品ビジョンです。ここは Kadoa を評価したいです。スクレイピングツールからデータ基盤プラットフォームへ軸足を移すのは、単なるマーケティング上のリブランディングではなく、明確な戦略転換だからです。
本質的な違い：即時抽出か、データセットの本番運用か
Thunderbit のワンクリック対話型ジョブ
Thunderbit は、「ページ上にデータが見えている」状態から「それをスプレッドシートに入れた」状態までの距離を、できるだけ短くすることに最適化されています。エージェントが今見ているページ上でリアルタイムに項目を判定するので、スキーマ確認ステップはありません。個人事業主や営業担当なら、まさにこういうものが欲しいはずです。火曜の午後4時に、200件のリードが必要なだけなのに「パイプラインのプレビューを承認」する余裕なんてありません。
Kadoa の承認済み決定論的パイプライン
Kadoa のワークフローは、何かを本番へ流す前に、必ずレビューと承認のゲートを挟みます。これは欠点ではなく、狙いそのものです。もしあなたがトレーディングモデルやコンプライアンスレポートに使うデータセットを作っているなら、6か月間無人で動く前に、人がスキーマへ承認を与える方が望ましいからです。
実行時の解釈と、エージェント生成された保守コード
ここで理解しておくべきなのが、アーキテクチャ上の違いです。Kadoa は、決定論的な抽出コードをエージェントが生成し、それが毎回 LLM 呼び出しなしで実行される方式と、ページ読み込みごとに直接 LLM で抽出する方式を明確に区別しています。これについては、彼らのAI in web scraping に関する公式解説で詳しく説明されています。ここでは公開情報以上の推測はしませんが、要するに Kadoa は、AI 支援によるパイプライン生成の速さと、決定論的コードの信頼性を両立させようとしているのです。対して Thunderbit は、長寿命のパイプライン成果物を最初にコンパイルするのではなく、各インタラクティブセッションごとにエージェント的な解析を使い続ける設計です。
実際の利用シーン
抽象的な機能比較だけでは全体像が見えないので、実際にどう使うかを見てみましょう。
単発のリード／商品／リサーチ用テーブル
たとえば、ディレクトリサイトから会社名、Webサイト、問い合わせメールを含む150社の一覧が必要だとします。私はページを開いて Thunderbit で One Click Extract を押し、1分以内にスプレッドシートを作ります。こういう一回限りのリストのために Kadoa のパイプラインを立ち上げ、スキーマ承認を待ち、定期実行まで待つ、という世界はありません。完全にやりすぎです。
週次の競合監視データセット
次に、15社の競合サイトから価格データを毎週月曜の朝に更新し、チーム全員が信頼して使えるダッシュボードに入れたいとします。これは Kadoa の得意領域にかなり近いです。承認ステップ、監視、そして「競合がサイトをリニューアルしたらどうなるのか」という自己修復の考え方が重要になってきます。Thunderbit も対応プランと対応面では定期抽出ができますが、Kadoa はまさにこの反復的な多ソース用途を中心に設計されています。
多ソースの投資／代替データワークフロー
これは、Kadoa の現在のポジショニングから見てまさに主戦場です。何十もの金融データや代替データソースから取得し、出所追跡や監査証跡も必要なケースです。ここで Thunderbit を選ぶことはしません。製品の設計思想がそもそも違うからです。
AI エージェント連携とデータ配信
RAG パイプラインや、抽出ツールをプログラムから呼び出す監視エージェントを作るなら、Thunderbit のOpen APIやMCP Serverが活きてきます。Claude、Cursor、または対応する AI ホストから Thunderbit を直接呼び出せます。現時点では、Kadoa に公開セルフサーブ API や MCP の提供があるか私は確認できていません。もしそれがあなたのスタックで必須条件なら、Thunderbit の開発者向け機能と同等だと思い込む前に、Kadoa に直接確認してください。
精度、保守、可観測性
Kadoa は、ソースへのグラウンディング、信頼度スコアリング、妥当性／完全性チェックをパイプライン検証の一部として説明しています。また、早期利用企業からの初期成果として、セットアップの高速化や保守負荷の削減といった数値も公開しています。ここははっきり言っておきたいのですが、これらは Kadoa 自身が報告している数値であり、独立したベンチマークではありません。Thunderbit と Kadoa を精度や保守負荷で直接比較した、管理された head-to-head テストは私は見ていません。マーケティングで見かける具体的な割合は、確定した事実ではなく、検証すべき主張として扱うのが妥当です。
Thunderbit 側の精度の話はよりシンプルです。ワークフロー自体がシンプルだからです。すぐにテーブルのプレビューが出て、その場で目視確認しながら項目の指示を微調整できます。しかも、半年間放置されたパイプラインがサイト改修でひそかにズレ続ける、ということが起こりません。そもそも半年放置のパイプラインが存在しないからです。常に新しい状態で抽出します。
両方に共通する正直な注意点もあります。どちらのツールも、すべてのサイトで成功を保証するわけではありません。ログイン壁、強いボット対策、急激なレイアウト変更は、現実に失敗の原因になります。Thunderbit のエージェント型再解析は、対応していて許可されたページでは役立ちますが、「エージェント型」という言葉が CAPTCHA を消してくれる魔法ではありません。
API、MCP、デプロイ
Thunderbit の開発者向け接点はよく整理されています。Open API によるプログラムアクセス、AI エージェント連携のための MCP Server、ターミナルやコーディングエージェント向けの CLI、そして対話的に使えるブラウザ実行とクラウド実行があります。
Kadoa の現在の導入ストーリーは、エンタープライズ向けの Web Scraping OS プラットフォームが中心です。管理されたパイプライン基盤と、より大きな組織向けのガバナンス／セキュリティ機能が売りです。現時点では、Kadoa に公開セルフサーブ API や MCP 連携のドキュメントは見つけられませんでした。もしそれが評価上重要なら、Thunderbit の開発者向けツールと機能的に同等だと決めつけず、必ず先方チームへ確認してください。
料金と購入の流れ
ここは率直に限界をお伝えします。Kadoa の現行公開ページは、2026年6月のリリース時点ではセルフサーブの料金表を公開していません。見込み客には営業窓口への問い合わせかテスト依頼を促す形です。したがって、2つの製品を「月額いくら」で比較したい場合、Kadoa 側ではすぐに壁にぶつかります。これは私が調査をさぼっているのではなく、実際に公開されていないからです。
Thunderbit には、今すぐ確認できる公開の料金ページがあります。
ただし、購入のしやすさで本当に重要なのは、表示価格そのものではありません。調達の摩擦です。Thunderbit なら、登録して数分で抽出を始められます。Kadoa のエンタープライズ向けの流れは、営業との会話、オンボーディング、そして本番前の概念実証期間を前提にしているはずです。もしあなたの組織にすでにエンタープライズ SaaS 向けの調達プロセスがあるなら、それは大きな問題ではないかもしれません。ですが、2人チームなら、かなり重い摩擦コストとして考慮する価値があります。
どちらを選ぶべきか？
Thunderbit を選ぶべき人
- 個人マーケター、創業者、営業担当で、今日中に数ページ分のデータが必要だが、誰かを待つ必要がない
- チームとして Sheets や Airtable へ繰り返しエクスポートしたいが、データエンジニアリング機能がない、または雇う予定がない
- API、MCP、CLI を使って AI エージェント、RAG パイプライン、監視スクリプトを作っている開発者
- 形式的なパイプライン承認フローより、1クリックで使えるテーブルを優先したい
Kadoa を選ぶべき人
- ガバナンス付きの、多ソースかつ継続更新されるデータセットを必要とするエンタープライズまたは金融データチーム
- コンプライアンス、出所、可観測性ダッシュボードが絶対に譲れない条件である
- 営業窓口対応、個別見積もりのエンタープライズ製品に対応できる調達プロセスを持っている、または構築中である
- ワンクリックの速さより、パイプライン保守と自己修復インフラの方が重要である
両方使うべき人
- アナリストがまず Thunderbit で素早くデータ案を検証し、その後、中央のデータチームがそれを Kadoa で保守運用するエンタープライズパイプラインへ落とし込む価値があるか判断する、という流れです。実際、規模拡大中の小さな会社でこのパターンを見たことがあります。まずは機動的に始め、あとで正式化する、というやり方です。
最終評価
私はいつも同じ整理に戻ってきます。Thunderbit は、速度と使いやすさのために作られた対話型エージェントスクレイパーです。Kadoa は、特にリブランディング後は、ガバナンスとスケールのために作られたエンタープライズ向け Web Scraping OS です。機能一覧で比べるだけでは本質を見誤ります。そもそも解こうとしている変数が違うのです。
もし本当にどちらかで迷っているなら、正直なところ、比較記事を鵜呑みにするより、小さな PoC を走らせることを勧めます（この記事も含めてです）。測るべきなのは、最初の実用結果が出るまでの時間、サイト変更に対してどれだけ安定して抽出できるか、用途に対してどれだけ監査可能か、そしてセットアップ時間と保守コストを含めた実質的な TCO です。
このページを見ている多くの人、つまり「コードを書かずに、IT を待たずに、そのデータをどう取り出すか」と考えている人にとっては、Thunderbit のブラウザ拡張 が、おそらく最短で答えにたどり着ける方法です。無料で始められて、5分もあれば問題を解決できるかどうかが分かります。
FAQ
Thunderbit と Kadoa はどちらもエージェント型ですか？ はい。どちらも AI エージェントを使ってページ構造を理解し、手動でセレクタを書かずにデータを抽出します。Thunderbit は、表示中のページごとに対話セッション単位でエージェント解析を行います。Kadoa は、エージェントを使って決定論的な抽出パイプラインを生成・保守し、本番データセットを運用します。
Kadoa Assistant はどのように動作しますか？ Kadoa の公式発表によると、必要なデータを自然言語で説明すると、Kadoa がソースを調査してスキーマを提案し、決定論的なパイプラインを構築・テストしたうえで、承認後に定期監視付きワークフローとしてデプロイします。
Thunderbit にセレクタやスキーマ設定は必要ですか？ いいえ。ページで One Click Extract をクリックすると、エージェントが自動で項目を検出します。Run Now は任意で、何もクリックしなくても抽出は自動で始まります。
Kadoa は毎回ページごとに LLM 抽出を行いますか？ 必ずしもそうではありません。Kadoa は、エージェント生成の決定論的コード（毎回 LLM 呼び出しを必要としない）と、直接的な LLM 抽出を区別しています。この違いは、彼らのアーキテクチャ解説で詳しく説明されています。
繰り返し使うデータセットにはどちらが向いていますか？ 規模とガバナンス要件次第です。Thunderbit は、対応プランでは中程度の頻度で繰り返す業務向けに定期抽出をサポートしています。Kadoa は、可観測性とコンプライアンス制御を備えた大規模・多ソース・継続保守型のデータセット向けに設計されており、現在のポジショニングは金融やエンタープライズデータチームに寄っています。
Kadoa の料金は公開されていますか？ 現時点では公開されていません。Kadoa の現行ランディングページは、セルフサーブの料金プランを載せる代わりに、営業への問い合わせやテスト依頼へ誘導しています。Thunderbit には、直接確認できる公開の料金ページがあります。
どちらのツールもすべてのサイトに対応できますか？ いいえ。どちらも、対応していて許可されたページで最もよく動作します。ログイン壁、強力なボット対策、大規模なサイト改修は、エージェント型かどうかに関係なく、あらゆるスクレイピングツールにとって実際の失敗要因です。「何でもできる」というベンダーの主張は、常に慎重に受け止めるべきです。
