rtrvr.ai vs Taprun 徹底比較！どっちがおすすめ？実行時LLMと記述時LLMの分岐点

rtrvr.aiとは、DOM解析に特化した実行時LLM型のブラウザエージェントである。

結論から言えば、rtrvr.aiとTaprunは「同じ価格表を並べて比較する相手」ではありません。月額料金が$9.99から$499.99までほぼ一致していても、2つのツールは設計方針のレベルで真逆の道を歩んでいる。ブラウザエージェントを選ぶとき、多くの人は精度ベンチマークや価格を見比べる。しかしその前に決めるべき論点があります。LLMを「実行するたびに呼ぶ」のか、それとも「最初の一回だけ呼んで済ませる」のか。この一本の線の上で、rtrvr.aiとTaprunは違う側に立っています。

rtrvr.aiとTaprunの違い：一目でわかる比較表

まずは両者のスペックを横並びで確認しましょう。細部の違いは後ろのセクションで解説するので、ここでは設計方針の分岐点を把握してください。

表の各行を見ていくと、料金欄だけが完全に一致していて、残りはほとんど別物。これが、rtrvr.aiとTaprunを「同じカテゴリの競合」として扱うと見えなくなる本質です。同価格帯であることは確かな事実ですが、コストが発生するタイミングが違うので、利用量が増えたときの総額カーブも別の形になります。

特に注目したいのが「LLM呼び出しタイミング」の行。rtrvr.aiは毎回の実行ごとに推論を走らせる前提で、その推論を軽くするためにDOM圧縮という技術を積んでいます。一方Taprunは、そもそも実行時にLLMを呼ばない設計。この違いは、Pythonのような実行時評価の言語と、Cのようなコンパイル時評価の言語の違いに近いものがある、と元記事の著者は表現しています。どちらが優れているかではなく、「ワークロードが繰り返されるかどうか」で選ぶべき対象。

rtrvr.aiとは何か、Taprunとは何か

両者の立ち位置を具体的に押さえていきましょう。名前と料金だけでは、どちらを選ぶべきかの判断材料になりません。アーキテクチャの前提が違うので、そこから解説します。

rtrvr.aiの概要と提供形態

rtrvr.aiは、ブラウザエージェント領域における洗練された実行時LLM型のプロダクト。元記事によると、同社はDOM-native処理とSmart DOM Compressionを核技術に据え、ビジョンベースの代替手法と比較して25倍安価、自己申告のベンチマークで81%のSOTA精度を公表しています。

提供形態の幅広さも特筆すべき点。Chrome拡張、Cloudダッシュボード、REST API、MCPサーバー、CLI、さらにはWhatsApp Botまで揃えている。ランディングページには10の競合ツールが名指しで掲載されていて、自社の立ち位置を市場のなかで明確に主張する姿勢が読み取れます。料金は月額$9.99から$499.99までの4段階。

この「多彩な形態で提供する」という戦略は、runtime型エージェントの武器でもあります。なぜなら、LLMを実行時に呼ぶ設計は「その場で状況判断できる柔軟性」を持っているから。Chrome拡張で手動操作の延長として使うにも、CLIでスクリプトから呼ぶにも、MCP経由で他のエージェントに組み込むにも、同じ推論エンジンが動く前提で設計できる。この柔軟性はrtrvr.aiの強みですね。

Taprunが立つ「もう一方の側」

Taprunは、rtrvr.aiとは違う哲学のもとに設計されたツール。2つの構成要素で成り立っています。tap forgeがLLMを一度だけ呼び出して.tap.jsファイルを生成する記述時コンポーネント、tap.runがそのファイルを永久に実行する実行時コンポーネント。一度ファイルが作られれば、LLMは二度と呼ばれません。

ここが決定的な違い。Taprunの実行時には推論パスが存在しない。DOM圧縮も、コンテキスト送信も、モデル呼び出しも不要。生成された.tap.jsは決定的なプログラムとして動作します。runtime型のどのツールよりも高速で、どのツールよりもコストが予測可能。

ただし、その裏返しとして、Taprunは「authoring時に対象サイトの構造を読み切る」ことを要求します。元記事が指摘するのは、runtime型とauthoring型の選択は「ワークロードが繰り返されるかどうか」で決めるもの、という整理。毎回違うサイトを探索する用途なら、毎回推論する意味がある。一方で、同じサイトの同じフローを毎日1000回実行するなら、推論を1回に圧縮したほうが合理的になります。

両者を分ける一本の線「LLMはいつ呼ばれるのか」

rtrvr.aiとTaprunの違いは、機能表の行数では捉えきれない。もっと上流の設計判断にあります。それが「LLMを実行時に呼ぶか、記述時に呼ぶか」という分岐点。この線の上で、すべてのブラウザエージェントツールが左右どちらかに振り分けられる構造になっています。

実行時LLM（runtime）の仕組み

実行時LLMとは、オートメーションが動くたびにモデルを呼び出すアプローチ。毎回の実行が推論パスを含んでいます。最適化の方向性は、その推論パスを「軽くする」こと。具体的には、DOM圧縮で送信するトークンを減らす、アクセシビリティツリーをスクリーンショットの代わりに使う、大型モデルではなく小型モデルを選ぶ、といった工夫。

元記事の整理によると、Browser-based agents、Stagehand、Playwright MCP、そしてrtrvr.aiは全員この側に立っています。それぞれ「どう呼ぶか」は違う。ビジョンベースかDOMベースか、大きいモデルか小さいモデルか、ページ全体か圧縮版か。しかし「呼ぶかどうか」の次元では全員が同じ側。

runtime型の本質的な強みは柔軟性。実行するたびにLLMが状況を見るので、DOMが変わっていても、新しい要素が増えていても、ある程度の適応ができる。ユーザーが毎回違う指示を出しても対応できます。反面、実行のたびに推論コストと推論の不確定性が発生する構造からは逃げられません。

記述時LLM（authoring）の仕組み

記述時LLMは、モデルをセットアップ時の一度だけ呼び出すアプローチ。LLMがサイトを読み、構造を把握し、決定的なプログラムを出力する。以降はそのプログラムが動くだけで、LLMは一切関与しません。

Taprunはこの側に立つツール。tap forgeがLLMを走らせて.tap.jsファイルを生成し、それ以降はtap.runがそのファイルを純粋に実行します。推論コストはゼロ、実行速度は一般的なスクリプトと同等、動作の再現性は完璧。同じインプットに対して同じアウトプットが常に返ってきます。

この設計の制約は明確。新しいサイトや変化するDOMには再authoringが必要になります。逆に言えば、対象が安定しているワークフローであれば、圧倒的な効率を発揮する構造。Pythonとコンパイル済みCの違いに例えるなら、runtime型が「実行のたびに式を評価するインタプリタ」、authoring型が「事前にバイナリに落としておくコンパイラ」に近い関係です。

rtrvr.aiのアーキテクチャを評価する

設計方針の違いを理解したところで、rtrvr.aiの技術そのものを正当に評価しましょう。runtime型として見たとき、rtrvr.aiは相当洗練されたプロダクトです。Taprunと比較するときに「rtrvr.aiは劣っている」と結論づけるのは間違い。両者は違う問題を解いている、というのが正確な理解。

DOM-native処理とSmart DOM Compression

rtrvr.aiの技術的な中核は、DOM-native処理とSmart DOM Compression。ブラウザが表示するページ全体をスクリーンショットとしてLLMに渡すビジョンベース手法と比較して、DOMツリーを構造化データとして直接扱うのがDOM-nativeの考え方。DOMは構造を持ったデータなので、それを活かせば視覚解析より効率よく要素を識別できます。

しかし、そのままのDOMはサイトによっては膨大な量になる。modern SaaSのページは10万トークンを超えるDOMを持つことも珍しくない。ここで登場するのがSmart DOM Compression。重要な構造情報を保持しながら、LLMに送るトークンを削減する圧縮技術です。rtrvr.ai公式の主張によると、この組み合わせによりビジョンベース手法と比べて25倍のコスト効率を実現しているとのこと。

実装の観点から見れば、これは純粋に良い仕事。runtime型というカテゴリのなかで、推論コストを下げる工夫としては洗練されている。ブラウザエージェントの実行時コストが運用の足かせになっている人にとって、rtrvr.aiは有力な選択肢になりうる設計です。

公称ベンチマーク値の読み方

81%のSOTA精度という数字も、rtrvr.ai側の公表値として押さえておくべきポイント。ただし、この数値の読み方には注意が必要です。rtrvr.ai自身が報告しているベンチマークなので、第三者が同条件で再現検証した結果ではありません。また、ベンチマークの定義自体がタスク集合の選び方に依存するので、別のタスクセットでは数値が変わる可能性があります。

ここで大切なのは、この81%という数値が「runtime型のなかで出せる精度」であるということ。Taprunは実行時にLLMを呼ばないので、そもそも同じベンチマークで比較できる土俵にいません。authoringの段階で構造を読み切れたかどうか、という別軸の指標が必要になります。

つまり「81%という数字はrtrvr.aiの優秀さを示す指標ではあるが、Taprunを下回る根拠にはならない」。逆に、Taprunが再現性100%を謳うとしても、それはrtrvr.aiを上回る精度の根拠ではない。両者の指標は比較可能な単位を持っていない、というのが公平な見方。

料金比較｜同じ価格帯でも意味が違う

料金表だけを見ると、rtrvr.aiとTaprunは双子のように見えます。月額$9.99、$29.99、$99.99、$499.99。プランの刻み方まで一致している。しかし、この一致は表面的なもの。課金モデルが持つ意味合いは、設計方針の違いを反映して別の形になっています。

runtime型の課金モデルには、実行回数に応じたコスト増加が構造的に組み込まれています。各プランで月の実行回数や推論量に上限が設けられているのが一般的なパターン。rtrvr.aiがSmart DOM Compressionで25倍効率化しているとしても、実行回数そのものが0にはならないので、回数が増えれば上位プランへの移行が必要になる構造。

一方、authoring型は実行時コストが原理的にゼロです。Taprunの場合、.tap.jsファイルの生成時にLLMを呼ぶので、そこに推論コストが発生する。しかし生成後の実行はただのJavaScriptの実行でしかないので、何回動かしてもLLM関連のコストは一切発生しません。月額プランの上限は実行回数ではなく、authoring可能なフロー数やサポート範囲で切られていく形になります。

この違いは、利用量が増えたときに顕著に効いてくる。同じフローを毎日1000回動かすシナリオを想定してみてください。runtime型なら1000×日数分の推論コストが発生します。authoring型なら、最初の1回だけ。月30日で30000回実行しても、LLMの呼び出しは最初の1回のままです。

運用の予測可能性という観点でも違いが出ます。runtime型は推論コストの累積が月の後半で膨らむので、予算計画が立てづらいケースがある。authoring型は生成時に一度だけコストが確定するので、以降の運用コストが読みやすい。このどちらが合うかは、対象ワークロードの性質次第ですね。

runtime型が強い場面、authoring型が強い場面

どちらが優れているという話ではなく、向いているワークロードが違います。使い分けの軸を具体的に整理していきます。

探索タスクはruntimeの独擅場

初めて訪れるサイトで「ここから商品一覧を取ってきて」「このフォームに入力して送信して」といった、事前に構造が読めない作業はruntime型の得意分野。毎回LLMが現在のDOMを読んで判断するので、サイト側のレイアウト変更にも柔軟に追従できます。

rtrvr.aiのようなruntime型ブラウザエージェントは、以下のようなシーンで強みを発揮する構造です。

• 競合調査で毎回違うサイトを巡回する場合
• 構造が不定形で、事前にセレクタを決め打ちできないサイト
• 1回限りのad hocな指示（「このページの価格だけ教えて」など）
• フォーム構造が頻繁に変わるSaaS画面の操作

要するに「毎回違うことをする」業務。推論コストを払ってでも柔軟性が欲しい場面では、runtime型以外の選択肢は実質ありません。

繰り返し実行はauthoringが有利

反対に、同じサイトの同じフローを毎日回すような業務では、authoring型の強さが際立ちます。一度動作確認が取れた.tap.jsは、以降は純粋なJavaScriptとして実行されるので、推論の不確定性も料金メーターも関係なくなる。

Reddit r/automationの実務者投稿では、「自動化ツールの内側だけで組むと途中でロジックが破綻する」という声が挙がっていました。事前にステップを外で定義してから組むべき、という趣旨。この指摘はruntime型の弱点と地続きで、LLMに毎回判断を委ねる設計は、プロセスが長くなるほど不安定になりやすい。authoring型は生成時にそのロジックを固定してしまうので、この種の破綻が起きにくい構造になっています。

runtime型の構造的な限界

runtime型を使うときに意識しておきたい限界について、公平に触れておきます。rtrvr.aiに限った話ではなく、Browser Use / Stagehand / Playwright MCPなど同じ設計方針のツール全般に共通する話。

コスト最適化では消えない推論の不確定性

Smart DOM Compressionで25倍安く推論できても、推論パス自体は残っています。DOMが変わったり、モデルの判断が揺れたりすると、前回は成功した操作が今回は失敗する、というケースが発生する。コストを下げる工夫と、推論の結果を固定する工夫は別の軸の話。

連鎖するほど累積する曖昧さ

Dev.toのPAX Protocol提案記事では「マルチエージェントチェーンは3番目のエージェントあたりで破綻し始める」という観察が共有されていました。エージェント1の出力の曖昧さがエージェント2の解釈で増幅され、エージェント3に届く頃には元の目的からドリフトしている、という累積誤差の問題。

runtime型で複雑なフローを組むと、これと似た累積ドリフトがステップごとに起こりえます。authoring型では生成時にそのフロー全体が確定するので、この種の累積は起きません。

rtrvr.aiとTaprun、どちらを選ぶか

判断フローはシンプル。以下の軸で切り分けてください。

rtrvr.aiを選ぶべき人
– 毎回違うサイト・違う指示を扱う探索型の業務
– Chrome拡張やWhatsAppなど多様な接点から使いたい
– 柔軟性を優先し、実行回数はそこまで多くない
– MCPサーバー経由で他のAIエージェントと連携したい

Taprunを選ぶべき人
– 同じサイトの同じフローを大量・長期に回す業務
– 実行時のLLMコスト予測を完全にゼロにしたい
– 成果物を.tap.jsとして資産化・バージョン管理したい
– フロー実行の再現性を最優先したい

両方を併用するのも現実的な答え。探索フェーズはrtrvr.aiで動かし、パターンが見えたフローだけTaprunで固定する、という分担なら両者の弱点を相互に補えます。

よくある質問

Q. rtrvr.aiとTaprunは併用できますか？

技術的には両立します。探索段階をrtrvr.aiでこなし、定型化したフローをTaprunの.tap.jsに落とす運用は理にかなった組み合わせ。役割が重ならないので干渉もしません。

Q. LLMを実行時に呼ばない方式で精度は出ますか？

authoring時に生成したコードが対象サイトの構造に合っていれば、実行精度は100%に収束します。決定論的な処理なので、同じ入力なら同じ出力。精度が揺れるのはサイト側のDOMが変わった時で、その際は再authoringが必要になります。

Q. Chrome拡張以外の提供形態は？

rtrvr.aiはCloudダッシュボード、REST API、MCPサーバー、CLI、WhatsAppボットと幅広く展開しています。Taprunはtap forge（authoring）とtap.run（実行）の2コマンド構成で、CI/CDに組み込みやすい設計。

まとめ

rtrvr.aiとTaprunは、料金表だけ並べるとほぼ同じ価格帯の競合に見えます。しかし「LLMをいつ呼ぶか」という上位の設計判断では、まったく違う側に立つツール。

毎回違う指示を飛ばす探索型業務ならrtrvr.ai、同じフローを何度も回す定型業務ならTaprun。迷ったときに戻るべきなのは価格や精度ではなく、自分のワークロードが「毎回違うのか、毎回同じなのか」という一点。ここを先に決めれば、選択はほぼ自動的に定まる構造になっています。