TinyFishの無料検索はAPI料金をなくすが、ウェブを読むコストまではなくさない
TinyFishの無料検索はAIエージェントにとって目に見える料金項目を1つなくすが、ウェブ調査そのものが無料になるわけではない。同社は現在、公開されているレート制限の範囲内で、SearchおよびFetchサービスを従量課金なしで提供している。しかし、取得された各ページは依然としてモデルのトークンを消費し、コンテキスト領域を占有し、ワークフローを長引かせ、無関係な情報を持ち込む可能性がある。
この違いは重要だ。エージェントは単にリンクを集めるだけではない。検索し、結果を選び、ページを読み、内容を評価し、しばしばその過程を繰り返す。取得プロバイダーが制御できるのは、この連鎖の一部にすぎない。最初のAPI呼び出しが無料でも、モデル推論、繰り返されるコンテキスト、失敗した試行にはコストが残り得る。
この発表は、ソフトウェアエージェント向けのウェブアクセスを販売するExa、Firecrawl、Tavily、Parallelなどにも圧力をかける。TinyFishは基本的な取得機能を、より広範な自動化プラットフォームへの入口に変えようとしている。競合各社は、より高い品質、信頼性、制御機能、またはより大きな運用上限によって、有料取得サービスの価値を示す必要がある。
したがって中心的な問いは、TinyFishが検索を無料にしたかどうかではない。明示された制限の範囲では、無料にした。より難しい問いは、その結果がエージェントによる作業完了に必要な計算量と再試行を減らせるかどうかだ。
TinyFishの無料検索は、ワークフローのどの部分に課金されるかを変える
TinyFishは直接的な取得料金を撤廃した一方で、エージェント運用に伴う残りのコストはそのまま残している。
TinyFishは2026年5月4日、SearchおよびFetchへの無料アクセスを発表した。Searchは構造化されたウェブ検索結果を返し、Fetchは選択したページをMarkdown、HTML、またはJSONへ変換する。どちらのサービスも、同社のAPI、ソフトウェア開発キット、コマンドラインインターフェース、Model Context Protocol統合を通じて利用できる。
同社の無料検索に関する発表によれば、開発者はクレジットカードなしで利用を開始できる。アカウントのウォレット残高に資金がない場合でも、SearchとFetchは利用可能なままだ。これは、プロモーションクレジットに紐づく一時的な試用提供よりも実質的な内容だ。
ただし、無料アクセスにはレート制限が適用される。現行の利用上限では、毎分数十回、毎時数百回の検索が可能だ。Fetchは別途の日次上限に従いつつ、毎分100件を超えるURLをサポートする。これらの枠は、実験や中程度の本番ワークロードには十分に寛大に見える。
TinyFishはプラットフォーム内の他の部分については引き続き計測課金している。Agent製品は複数ステップのブラウザ作業を担い、Browserはホスト型のインタラクティブセッションを提供する。これらのサービスは、より長時間稼働するインフラと、より状態を持つ実行環境を必要とするため、ウォレット残高を消費する。
この区分はビジネス戦略を示している。TinyFishは発見とページ抽出を顧客獲得チャネルとして扱う。ワークフローが公開ページの閲覧から、コントロールのクリック、セッション維持、フォーム入力、長時間タスクの実行へ進む段階で収益を得る。
このモデルは、ある層をコモディティ化することで別の層への需要を増やすインフラ事業に似ている。無料の取得呼び出しは開発者をプラットフォームに呼び込める。成功したプロトタイプは、その後、管理されたブラウザ、自動化ステップ、エンタープライズ向け制御、大規模容量への需要を生む可能性がある。
開発者にとって直接的な利点は、実験が簡単になることだ。チームは、クエリやページごとの別料金をあらかじめ見積もることなく、エージェントを最新のウェブ情報へ接続できる。同じチームでも、どれほどのテキストが言語モデルに入力されるかは引き続き監視する必要がある。
この残存コストは、API請求書よりも見えにくい場合がある。検索結果、ページ内容、システム指示、チャット履歴、ツール出力はすべて、限られた領域を奪い合う。この材料をモデルへ送ると、モデルプロバイダーは独自の利用条件に基づいて処理する。
したがって、無料のFetchでも高額なモデルリクエストが発生し得る。一方で、低コストに収まる場合もある。その違いは、返されるコンテンツの量、そのコンテンツの整理度、そしてワークフローが再送する頻度に左右される。
TinyFishの動きは、計算処理を変える前に調達を変える。直接料金がなくなるため、取得機能は承認しやすくなる。それでもエンジニアリングチームは、最初のクエリから最終的に検証された回答まで、ジョブ全体を測定しなければならない。
AIエージェントにおけるウェブ利用の本当のコストは、取得後に始まる
エージェントが支払うのは、情報を届けたエンドポイントだけでなく、処理する情報そのものに対してだ。
複数の製品を比較する調査エージェントを考えてみよう。まず関連ページを検索し、次に仕様、ドキュメント、レビュー、最近の発表を取得する。エージェントは、矛盾する主張を整理する前に、各ソースを要約することもある。
各ステップは、作業中のコンテキストにテキストを追加し得る。コンテキストウィンドウとは、モデルが1回のリクエストで考慮できる入力および生成済みの材料の量を指す。大きなウィンドウは容量を増やすが、不要なテキストを無害にするわけではない。
ナビゲーションメニュー、Cookie通知、関連記事リスト、広告ラベル、重複するページ要素は、すべてトークンを消費する。トークンはモデル処理で使われる小さなテキスト単位だ。トークン数はモデルや言語によって変わるため、文字数に基づく推計はあくまで概算にとどまる。
10月18日のコスト分析は、1つのニュースページを通じてこの問題を示している。TinyFishの基礎となった評価では、同じ記事に対してプロバイダーが返すテキスト量には大きな差があった。
TinyFishがそのページに対して返したのは5,000文字未満だった。Firecrawlは170,000文字以上を返した。Parallelは短い抜粋のみを返しており、その小さな出力量は完全な抽出結果と比較できない。
大まかな換算では、これらの出力は約150トークンから42,000トークン超までの範囲だった。最大の結果は、指示、会話履歴、出力を加える前の段階で、128,000トークンのコンテキストウィンドウのおよそ3分の1を占め得る。
この例は典型的な性能を示すものではない。小規模なベンダー主導テストから選ばれた1ページを扱ったものだ。ただし、取得量と有用な情報量が異なる測定指標である理由は示している。
より大きなレスポンスが自動的に完全性を意味するわけではない。記事に加え、多数のページ要素が含まれている可能性がある。一方で、小さなレスポンスが自動的に優れているわけでもない。正確な回答に必要な根拠を省いている可能性がある。
運用上の目標は、最小限のノイズで有用なカバレッジを得ることだ。カバレッジは、必要な材料をシステムが取得できたかを問う。シグナルは、返された材料のうち、どれだけがタスクに寄与するかを問う。
この違いは、エージェントループの中でさらに重要になる。従来の検索インターフェースでは、人間が結果を確認して開くページを決める。エージェントは、人の介入なしに検索、取得、熟考、再検索、回答の修正を行う可能性がある。
先に得た材料は、後のモデルリクエストに含まれることがある。一部のシステムは繰り返し入力を低い処理料金でキャッシュするが、キャッシュされたテキストもコンテキストを占有する。また、より新しい、あるいは関連性の高い根拠からモデルの注意をそらすこともある。
ノイズの多い抽出は、少なくとも4種類のコストを生む。第一に、モデルがより多くの入力を処理しなければならない。第二に、有用なコンテンツを特定しにくくなる。第三に、ワークフローがより早くコンテキスト上限に達する可能性がある。第四に、回答の抽出に失敗したため、エージェントが追加検索を実行する可能性がある。
これらの影響は積み重なる。単一の質の低いページなら対処可能でも、質の低いページが繰り返されれば、要約、切り詰め、または別のモデル呼び出しが必要になる。取得エンドポイントは無料のままでも、ワークフローは長くなる。
レイテンシも同じ計算に含めるべきだ。検索は素早く返っても、完全な調査タスクにはページレンダリング、モデル推論、ツール選択、再試行が含まれる。ユーザーが体験するのは、最速の単独コンポーネントではなく、全体の所要時間だ。
信頼性も経済性を変える。エージェントがブロック、不完全な抽出、古い結果に繰り返し遭遇すれば、代替ソースが必要になる。エンジニアが広範なフォールバックロジックを構築しなければならない場合、名目上は安価なツールでもコスト高になり得る。
したがって、適切なコスト単位は完了したタスクだ。チームは、根拠に裏付けられた回答に到達するまでに必要なモデルトークン、ツール呼び出し、秒数、再試行回数を測定すべきだ。また、その回答が正確であり続けるかも記録する必要がある。
このジョブ単位の視点は、よくある調達上の誤りを防ぐ。ベンダーは、ある費目を減らしながら、作業をスタックの別の部分へ移すことがある。無料取得には実際の価値があるが、それは単に負担を移すのではなく、総作業量を減らす場合に限られる。
調査負荷の高いナレッジワークでは、収集後にも同じ原則が当てはまる。整理されたソースであっても、その後の整理、比較、再取得は必要になる。構造化されたAIナレッジベースは、ページ全体を新しい会話へ何度も取り込むことなく、有用な根拠を保持できる。
クリーンなFetch結果こそがTinyFishのより強い主張だ
TinyFishにとって最も重要な主張は無料アクセスではなく、より少ないモデル処理で済む、よりクリーンな出力にある。
Searchは候補となるソースを特定する。Fetchはモデルが実際に読む内容を決める。取得層が根拠を維持しながら無関係なページ要素を除去できれば、トークン使用量を抑えつつ、同時に焦点も改善できる。
TinyFishによれば、Fetchサービスは実際のブラウザを通じてページをレンダリングし、クリーンアップされたコンテンツを返す。この手法は、JavaScriptを多用するサイト、動的なインターフェース、基本的なHTTPリクエストでは有用な情報がほとんど得られないページを対象に設計されている。
同社はこの機能を2026年6月2日に評価した。Fetch評価では、ドキュメント、料金ページ、リポジトリ、記事、ニュースサイトにまたがる45件のURLをテストした。
TinyFishは、42件、すなわち93%のURLで有用な結果を得たと報告した。テストの基準では、Tavilyは36件、Exaは33件、Firecrawlは28件、Parallelは26件に達した。
有用な結果の中で、TinyFishは中央値のシグナル比率が90%を超えたと報告している。Exaもページへの到達に成功した場合にはそれに近かった。より大きな差は、特に15件のニュースURLにおけるカバレッジで表れた。
この評価では、有用な結果を、少なくとも1,000文字で、判定されたシグナル比率が30%を超えるものと定義している。TinyFishはこのルールの下で3件の失敗を記録し、その内訳にはコンテンツが少なすぎた2ページと、ノイズが過剰だった1ページが含まれる。
こうした詳細は、見出しのパーセンテージだけよりもテストの情報量を高めている。同時に、いくつかの重要な限界も明らかにする。
TinyFishは評価を自ら実施しており、比較対象となるすべてのプロバイダーと競合している。サンプルは45件のURLに限られていた。コンテンツ品質はAnthropicのモデルが判定し、30%というシグナルのしきい値は方法論上の選択を反映している。
プロバイダーは急速に変化する可能性もある。取得システムは、パブリッシャーの再設計、アクセス制限、ボット対策技術に対応している。6月に測定された結果が、10月にも同一の性能を保証するわけではない。
ニュースページは、TinyFishが報告した優位性の多くを支えた。これは監視・調査エージェントにとって重要だが、ECカタログ、認証済みアプリケーション、政府データベース、ニッチな業界ポータルでの性能を予測するとは限らない。
この評価には、異なる取得アーキテクチャも混在している。インデックス型サービスはクリーンな保存済みコピーを迅速に返せる一方、インデックスに存在しないページを見逃すことがある。ライブブラウザはより新しい材料へアクセスできるが、レンダリングの複雑さや遅延の可能性を伴う。
どちらの手法も、あらゆるワークロードで優位になるわけではない。十分に網羅された公開情報へ繰り返しアクセスする用途には、インデックス型システムが適している可能性がある。一方、鮮度、動的コンテンツ、複雑なページ構造が重要な場合には、ライブレンダリングの価値が高まる。
TinyFishのテストでは、Exaはページに到達できた場合、同様にクリーンなコンテンツを提供した。この結果は、特定のプロバイダーが常により優れたテキストを生成するという単純な主張を弱める。パフォーマンスはクリーニング品質と同じくらい、可用性とアーキテクチャによって左右されることを示している。
Parallelの短い出力には、別のトレードオフがある。簡潔な抜粋はトークン消費を抑えるが、根拠を十分に提示しない可能性がある。断片しか受け取れず、ページが途中で切り詰められたことを検出できなければ、エージェントは慎重な比較を行えない。
注目されたニュース事例におけるFirecrawlの大量出力は、反対のリスクを示している。完全なレンダリングは根拠を保存できる一方で、大量のページ装飾まで取り込む可能性がある。モデルは記事を受け取れるが、ページの中から記事を見つけ出さなければならない。
したがって開発者は、単一のベンチマーク順位をそのまま受け入れるのではなく、代表的なURLでテストすべきである。調達ベンチマークには、実際のアプリケーションを定義するドメイン、言語、ページ種別、鮮度要件を含める必要がある。
テストでは、取得失敗と抽出失敗も分けて扱うべきだ。あるプロバイダーは正しいURLを見つけても、利用できないテキストを返すかもしれない。別のプロバイダーは指定されたURLを適切に抽出しても、検索時には質の低いソースを上位に表示する可能性がある。
最終的な検証となるのは回答品質だ。クリーンなテキストに価値があるのは、エージェントが重要な詳細を保持し、留保条件を理解し、正しいソースを引用できる場合に限られる。過度なクリーニングはトークンを節約できる一方で、意味を変えてしまう文脈を削除することがある。
TinyFishが公開しているベンチマーク集には、検索、フェッチ、ブラウザーエージェントの測定が含まれる。これらの結果は有用な出発点になるが、購入者はベンダーのベンチマークを普遍的な結論ではなく、再現可能な主張として扱うべきだ。
TinyFishの主張で最も強い部分は、測定可能で限定的である点にある。Fetchの出力が、より少ないノイズで必要な事実を一貫して保持できるなら、無料の取得は単なるマーケティング施策を超える。直接費用と後続処理の負担の両方を減らせる。
それが成り立つかどうかは、ワークロードごとに実証すべき問題である。今回の発表により、そうしたテストを低コストで実行できるようになったことが、最も大きな実務上の影響かもしれない。
有料検索プロバイダーは成果全体を正当化する必要に迫られる
TinyFishの無料検索は、競争の軸をリクエスト単価から、精度、カバレッジ、レイテンシー、運用上の信頼へと移す。
Exa、Firecrawl、Tavily、Parallelは、同一の製品を提供しているわけではない。それぞれが検索、抽出、リサーチ、クロール、自動化を異なる形で組み合わせている。単一のエンドポイントを比較すると、プロバイダーが提供するより広範な価値を見落としかねない。
それでもTinyFishの判断は、居心地の悪い比較基準を生み出す。TinyFishが検索とフェッチの両方を無料で提供する中で、なぜ他社の基本的な検索またはフェッチのリクエストには料金がかかるのか、購入者は問うことになる。
競合他社は、より優れた結果によってその問いに答えられる。ソースの関連性が高ければ検索回数を減らせる。より良い抽出はトークン使用量を抑えられる。より高速な応答はユーザー向けタスクを短縮し、より強力な可観測性はエンジニアリング作業を減らせる。
一貫性にも価値がある。エンタープライズチームは、予測可能なランキング、安定したスキーマ、契約上のサポート、アクセス制御、文書化された保持ポリシーを好むかもしれない。無料で利用できることだけでは、こうした要件は満たされない。
規模についても同様だ。TinyFishは無料サービスの制限を公開している。それを超えるアプリケーションには、エンタープライズ向けの容量について協議するか、別のプロバイダーを選ぶ必要がある。大量アクセスを明快に提供するプロバイダーは、リクエストごとに直接料金が発生しても魅力を保ち得る。
製品ごとに、作業の数え方も異なる。検索リクエストは複数の結果を返す一方、リサーチタスクでは多数の検索やモデル呼び出しを実行する可能性がある。ページ抽出は、ブラウザー操作や完了済みの調査と同等ではない。
このため、単純な価格比較はしばしば誤解を招く。異なる単位を並べ、最も安い単位が最も安い仕事を生むかのように示してしまう。自動化ステップ、検索リクエスト、フェッチ済みページ、完成したレポートは、それぞれ異なる量の作業を表している。
TinyFish自身の製品ラインも、この違いを認識している。SearchとFetchは無料である一方、状態を持つブラウザー操作と複数ステップのエージェントは従量課金のままだ。同社は、ウェブ実行にコストがかからないとは主張していない。
代わりに、どこに課金ポイントを置くかを選んでいる。TinyFishは基本的な取得コストを負担し、より深いオーケストレーションを要する作業で課金する。この判断は、競合他社に自社の境界を説明するよう圧力をかける。
この動きは、社内取得システムへの圧力も高める。一部のチームは、独自スクレイパー、ブラウザープール、パーサールール、プロキシサービス、フォールバックプロバイダーを維持している。直接的なインフラ支出は、その判断の一部にすぎない。
Webサイトが変われば、エンジニアは対応しなければならない。抽出失敗、ブロックされたセッション、予期しないスキーマ変更を監視する必要がある。管理された無料サービスが中程度のワークロードを十分に処理できるなら、社内の取得基盤を維持する正当性は低下する。
ベンダー依存は反論となる。無料サービスは、制限、ポリシー、製品戦略を変更する可能性がある。ホスト型システムは、顧客が送信するURLやクエリに関する情報も受け取る。
こうした要因は、機密性の高いリサーチでは重要になる。買収候補、セキュリティ問題、訴訟、未発表の製品計画を調査するチームは、外部プロバイダーを通じてクエリを送る前に、データ処理を精査すべきだ。
Webサイト運営者も、未解決の当事者として加わる。AI取得システムは自動トラフィックを生成する一方、直接訪問を減らす可能性がある。パブリッシャーは、モデル主導の回答で使用されるコンテンツについて、ライセンス、帰属表示、クローラー制御、報酬をますます重視している。
TinyFishは、自社インフラにブラウザーレンダリングと、ブロックされたアクセスに対応するシステムが含まれるとしている。購入者は、アクセスの成功が技術的に可能か、契約上許可されているか、想定用途に適切かを検討すべきだ。
レンダリング可能なページが、著作権、プライバシー、利用規約に関する懸念から自動的に解放されるわけではない。取得プロバイダーは技術的な摩擦を減らせるが、顧客のコンプライアンス義務をなくすことはできない。
エージェントが読む段階から行動する段階へ移ると、この緊張関係はより鮮明になる。公開ページをフェッチすることと、アカウントにログインすること、フォームを送信すること、購入を行うことには異なるリスクが伴う。
TinyFishの商業戦略は、この進展に依存している。無料の取得が有料の実行につながる。より多くの開発者が初期サービスを採用するほど、TinyFishが後続段階を販売する機会も増える。
競合他社は、取得料金を引き下げたり、サービスをバンドルしたり、差別化された品質を強調したりして対応できる。専門的なインデックス、構造化データセット、エンタープライズガバナンス、より高度なリサーチ機能によって競争することもできる。
起こり得る結末は、すべての検索サービスが同一で無料になることではない。基本的な取得は、完了したタスクを改善する証拠なしには販売しにくくなる。プロバイダーは、リクエストを取り巻く要素で競争することになる。
購入者にとって、これは有利な変化だ。チームは実際のワークロードに結び付いたベンチマークを要求できる。リクエスト数を価値の主要指標として受け入れるのではなく、総モデル使用量や完了率を比較できる。
無料というラベルでも、品質、プライバシー、持続性は未解決のまま
最大のリスクは価格欄の外側にある。ベンチマークの独立性、データ処理、レート制限、長期的な信頼性である。
TinyFishの発表は、何が無料なのかについて明快だ。しかし、その広範な効率性の主張には、裏付けとなる証拠の多くがTinyFish自身に由来するため、より慎重さが必要である。
45 URLのFetch調査は、いくつかの弱点を明示している。TinyFishは、自社の商業的利害、小規模なサンプル、主観的な閾値、自動判定の限界を認めている。
透明性は信頼性を高めるが、独立した検証を提供するものではない。外部の研究者は、より大規模で多様なサンプルを用いて結果を再現すべきだ。反復実行、国際的なサイト、長い文書、特殊なレイアウトのページもテストする必要がある。
検索品質には別途の精査が必要である。URLを受け取った後でクリーンなページをフェッチできても、発見の段階では質の低いソースを返すサービスもあり得る。検索評価では、関連性、鮮度、ソースの権威性、重複、一貫性を測定すべきだ。
元の分析で引用された第三者ベンチマークの一つは、回答モデルを固定し、検索プロバイダーだけを変更した。TinyFishは、比較された構成の中で、表示上の総モデルコストと取得コストが最も低かった。
一方で、そのスナップショットでは表示上のSearch Indexスコアも最も低かった。DeepSearchQAの結果は競争力を維持したが、この組み合わせは単純な勝利宣言を複雑にする。
このベンチマークはTinyFish Fetchではなく、共有の抽出レイヤーを使用していた。したがって評価したのは、そのハーネス内におけるTinyFish Searchの効果であり、同社の検索・フェッチスタック全体ではない。
また、その時間指標は推定モデル処理時間と測定済みの検索時間を組み合わせたものだった。この数値を生のAPIレイテンシーとして提示すべきではない。購入者が別々のテスト結果を比較する際には、こうした方法論上の違いが重要となる。
責任ある結論は限定的である。TinyFishには、無料検索がコスト意識の高いエージェントワークフローを支え得るという証拠がある。利用可能な公開データは、あらゆる品質目標において同社が最良のプロバイダーであることを示すものではない。
プライバシーも、もう一つの未解決の問題だ。検索クエリは、商業的意図、顧客の課題、社内の優先事項を明らかにし得る。フェッチされたURLは、チームがどの企業、人、脆弱性を調査しているかを露呈する可能性がある。
組織は、保持、学習、ログ記録、アクセス制御、削除に関するポリシーを確認すべきだ。エンタープライズ購入者は、トラフィックを分離できるか、アクセスを監査できるか、処理場所を制御できるかも確認すべきである。
無料インフラは急速にワークロードを集める可能性があるため、持続性も重要だ。需要急増はパフォーマンスに影響し得るし、寛大なアクセスは悪用を招くこともある。TinyFishは、スロットリング、制限の改定、より厳格な管理を通じて対応できる。
同社が公開している制限は予測可能な出発点を示すが、恒久的な保証ではない。本番設計では、ポリシー変更と一時的な障害を想定すべきだ。
フォールバックは引き続き有用である。あるプロバイダーがページを取得し損ねた場合、過剰なノイズを返した場合、または許容量に達した場合、エージェントはプロバイダー間でルーティングできる。このレジリエンスはエンジニアリングの複雑さを増すが、一社のベンダーが単一障害点になることを防ぐ。
チームは、抽出テキストとともにソースメタデータも保存すべきだ。有用な記録には、URL、取得時刻、コンテンツハッシュ、抽出方法が含まれる。来歴がなければ、ページ変更後に回答を監査することは難しくなる。
クリーンな抽出は、それ自体が誤りを招くこともある。パーサーが開示事項、表のラベル、脚注、近接する留保条件を削除してしまう可能性がある。そうした欠落は、ソースを誤って表現する自信に満ちた要約を生みかねない。
高リスクのワークフローには、ソースレベルの検証が必要だ。エージェントは、金融、健康、法律、セキュリティ、契約上の義務に関する主張について、引用と直接的な根拠を保持すべきである。
人間によるレビューは、すべての低リスクタスクを対象とする必要はない。誤りの影響に応じて強化すべきだ。取得コストが下がるほど、ガバナンスが追い付く前に自動化を拡大したくなる誘惑は強まる。
TinyFishの無料検索は、エージェントをライブWebへ接続する摩擦を下げる。それでも、エージェントが信頼できるソースを選んだか、それを正しく解釈したか、利用する許可を得ていたかという問いには答えない。
こうした未解決の問いが、無料というラベルが重要でありながら不完全である理由を説明している。取得の請求書がなくなっても、コスト、品質、信頼は依然として結び付いている。
TinyFish Free Searchが実際にコストを削減するかを見極めるポイント
TinyFishがエージェントの経済性を変えたのか、それとも請求先を変えただけなのかは、3つの指標によって判断される。
第1の指標は、独立したタスク単位のベンチマークだ。研究者は、同一のモデル、プロンプト、ソースセット、回答評価手法を用いてプロバイダーを比較すべきである。結果には、完了タスクの正確性、総トークン数、経過時間、再試行回数、失敗率を報告する必要がある。
無料の取得機能によって回答品質を落とさずにモデル利用全体も削減できるなら、この証拠はTinyFishの主張を補強する。一方、取得コストの低下が検索回数の増加、より長い推論、あるいは回答品質の低下につながるなら、その主張は弱まる。
第2の指標は、実験を超えた本番環境での採用だ。開発者は無料APIを容易に試せるが、継続的な利用は、変化するWebサイト全体でサービスが信頼性を維持できるかを明らかにする。ケーススタディには、トラフィック量、エラー率、フォールバック頻度、保守工数を含めるべきだ。
意味のある採用は、チームがTinyFishをデモだけでなく反復的なワークロードにも信頼していることを示す。プロバイダーの頻繁な切り替えや大規模なフォールバックロジックは、無料アクセスによって運用リスクが十分には取り除かれていないことを示唆する。
第3の指標は、競合他社の対応だ。Exa、Firecrawl、Tavily、Parallelは、利用枠、バンドル、製品の位置づけを変更できる。また、ソース品質、抽出精度、リサーチ完了度について、より強力な独立測定を公表することも可能だ。
広範な値下げは、TinyFishが市場の基準線を動かしたことを裏付ける。品質重視の対応は、競合他社が購入者はより良い成果には引き続き料金を支払うと考えていることを示す。
開発者は、これらの指標を待ってからサービスを試す必要はない。まずは実際のタスクを代表するセットから始め、すべての検索、フェッチ、トークン、再試行、完了した回答を記録すべきだ。
有用な試験には、容易なページだけでなく、通常は取得処理を破綻させる厄介なページも含める必要がある。最新ニュース、ドキュメント、動的サイト、長いページ、一般的なアクセス制御で保護されたソースをテストすべきだ。
評価では、見栄えのよい整形だけでなく、証拠が保持されているかを採点すべきである。簡潔な回答に価値があるのは、最終回答に必要な事実を保持している場合に限られる。
その後、チームは完全なワークフローを現在のシステムと比較すべきだ。TinyFish free searchが正確性を維持しながら総計算量、レイテンシ、保守負担を下げるなら、その削減効果は実在する。
取得料金をなくす一方で、モデル利用や失敗を増やすだけなら、「無料」というラベルが示すのは一つの構成要素にすぎない。それでも有用な情報ではあるが、完全なコスト分析ではない。
エージェント開発者にとって次の問いは実践的だ。コンテキストの各単位から、どれだけ有用で検証可能な作業が生まれるのか。プロバイダーを選ぶ前に、自社のページでその比率を測定してほしい。TinyFishはこの実験を始めやすくした。その長期的な重要性は、無料の取得機能がエージェントによるタスク完了を一貫して支援できるかどうかにかかっている。
