Perplexity APIのFast Searchと標準webを比較：料金・速度・検索品質

Perplexity APIはFast Searchと標準webのどちらを選ぶべきか

範囲が明確で繰り返し可能な処理にはFast Searchを、情報源を1つ見落とすだけで判断が変わり得る調査には標準webを選びます。 料金とレイテンシではFastが優位です。一方、検索品質と回答可能性では標準webが勝ります。本番環境のエージェントは、すべてのクエリを一方に固定せず、両者を振り分けるべきです。

Perplexityの現行Fast Searchガイドでは、日常的なエージェント処理にはfast、まれで難しい、または曖昧な質問には標準のweb設定を推奨しています。この比較に用いた料金とベンダー測定値は、2026年9月24日にPerplexityの公開中のページで確認しました。

サポートエージェントを開発する個人ビルダーなら、定型的なドキュメント検索やステータス確認はfastから始め、結果が空、または根拠が弱いときだけwebへ引き上げます。標準webを1回使う追加費用$0.004は、見落としによって人の確認が必要になる場面では小額です。しかし、低リスクの検索を何千回も繰り返すなら無駄になります。

市場調査プロダクトを作る資金調達済みの創業者なら、企業、政策、競合に関する曖昧な質問は標準webに任せるべきです。既知の情報源の確認、製品の提供状況、定期モニタリングにはFastも使えます。画面上の検索ボックスが1つでも、ワークロードには2種類の検索クラスがあります。

ミッドマーケット企業のCTOなら、社内のリプレイ検証でFast Searchが必要な情報源一式を維持できると確認するまでは、調達、セキュリティ、規制、インシデント調査に標準webを使います。リクエスト単価が5分の1でも、アナリストが根拠資料を修復しなければならないなら、安くはありません。

Perplexity Fast SearchのAPI：Photonで何が変わるのか

Fast Searchで変わるのは検索に使う計算予算であり、エンドポイントや結果スキーマではありません。 Perplexityは2026年9月24日、自社開発の検索・ランキングエンジンPhotonを基盤とするこのモードを公開しました。現行のFast Searchドキュメントでも、同じPOST /searchエンドポイントが同じ順位付きresults[]配列を返し、リクエストにsearch_type: "fast"を加えるだけで利用できることを確認できます。

search_typeを省略すると、Perplexityは標準のwebを使います。ここでいう「標準」は、一般ユーザー向けPerplexityアプリのデフォルト言語モデルではなく、Search APIの標準検索モードです。どちらのモードも、後続処理に使えるタイトル、URL、スニペットに加え、任意で公開日と更新日を返します。

Photonのリリース説明によれば、このエンジンはクエリに必要なデータだけを読み込み、ディスク待機を重ねて処理し、バッチを考慮したキャッシュを使います。Perplexityの公式アーキテクチャ図には、ブローカーとシャードを通るリクエスト経路が示されています。こうした設計が高速性の根拠です。ただし、意図的なランキング上のトレードオフが消えるわけではありません。Fast Searchは計算量を抑える代わりに、広範な検索品質の一部を手放します。

Perplexity Photonはエンジンであり、第3のモードではない

PhotonはPerplexityの検索スタックを支える基盤です。APIで選べるのは引き続きfast、web、そして独立した検索タイプのpeopleです。開発者がPhotonを直接選択したり、デプロイしたり、別形式のレスポンスオブジェクトを受け取ったりすることはありません。

現行SDKには実務上の注意点があります。PerplexityはPythonライブラリのバージョン0.43.4と0.43.5について、新しい値が直接のバリデーションで拒否されるため、extra_body={"search_type": "fast"}の利用を案内しています。TypeScriptの例では、型定義が追いつくまでSDK 0.38.5で"fast" as anyにキャストしています。HTTPを直接呼び出せば、どちらの一時的なクライアント側制約も回避できます。

Perplexity APIの料金比較：10,000リクエストで$10対$50

勝者はFast Searchです。 現行のPerplexity料金表では、Raw Fast Searchは成功した1,000リクエストあたり$1、標準webは成功した1,000リクエストあたり$5で、Search APIに追加のトークン料金はありません。

同じ処理量にそろえると、計算はシンプルです。

• 10,000回のFast Search： 10,000 × $0.001 = $10。
• 10,000回の標準web： 10,000 × $0.005 = $50。
• 差額： $40。Raw検索費用を80%削減できます。

ただし、この$40だけでエージェント全体の請求額は決まりません。結果を読むモデル、追加取得、再試行、検証、人による確認は後段で発生します。Fastが本当に安いのは、10,000回のバッチ全体で追加作業を$40より増やさない場合だけです。

成功しても結果が空なら料金は発生する

POST /searchが成功すれば、results[]が空でも課金対象です。現行の料金ルールでは、不正なリクエスト、レート制限を受けたリクエスト、上流側の障害は課金されません。したがって、空結果率は品質だけでなく予算の指標でもあります。

バッチ処理で変わるのは請求額であり、品質判断ではない

Perplexityのマルチクエリ・クイックスタートでは、関連するクエリを1リクエストに最大5件まで含められます。成功したマルチクエリのリクエストは1課金単位ですが、各クエリは引き続きレート制限に数えられます。20件のクエリを各モード4リクエストにまとめれば、合計費用は**$0.024です。40件を個別のシングルクエリとして送る場合は$0.12**になります。

1回あたりのレイテンシ比較にバッチ処理を使ってはいけません。5件のクエリを含むペイロードはリクエストの処理量を変え、クエリ単位の所要時間を見えなくします。まず各モードで20回のシングルクエリを比較し、モードの判断が固まってからバッチ処理を別に検証します。

Agent APIのツール料金は別の予算項目にする

Agent APIのツール料金表には別の標準料金があり、fastのweb_searchは1,000回の呼び出しあたり**$1**、標準webは1,000回の呼び出しあたり**$2.50**で、選択したモデルのトークン料金が加わります。これはRaw Search APIの$1と$5の料金とは異なります。また、Fast SearchとAgent APIにある別のfastプリセットは、同じ語が使われていても別物です。

既存のPerplexity・Exa・Tavilyのコスト比較は、どのプロバイダーを選ぶかに答える記事です。今回の判断はさらに1段深く、Perplexityをすでに採用した後の選択です。

レイテンシはFastが優位、ただしベンダー測定という注記付き

Perplexityの測定では、勝者はFast Searchです。 Perplexityの公式レイテンシ図は、Fast Searchのシングル呼び出しについてp50で160 ms、p95で230 msと報告しています。周辺のリリース文や現行のFast Searchガイドには、標準webを同条件で測ったp50とp95が掲載されていません。そのため、両者の正確なレイテンシ比は示せません。

パーセンタイルには意味があります。p50は中央のリクエスト、p95は95%のリクエストが完了するまでの上限です。検索を複数回、順番に実行するエージェントは、中央値より遅い側の裾の影響を強く受けます。1回のツール呼び出しの遅れが、計画全体を止めるためです。

したがって、レイテンシ重視の処理はFastに任せるのが妥当です。ただし、本番での答えはワークロードごとに異なります。ネットワーク距離、フィルター、要求する結果数、抽出コンテキスト、バッチ処理、再試行ポリシーは、いずれもエージェントが体感するエンドツーエンド時間に影響します。ベンダーの数値は基準値であり、あらゆる実装に対するサービスレベルの保証ではありません。

Mikhail Basyukの実務家としての見方は、適切な基準を示しています。250 ms未満のp95に価値があるのは、タスクに必要な関連性が保たれる場合だけです。速度と根拠は同じダッシュボードで見る必要があります。

情報源の網羅性では標準webが優位

難しい調査や曖昧な調査では、標準webが勝者です。 Perplexityの社内検索評価図では、Fast Searchの関連性スコアは2.21、標準は2.45で、差は0.24ポイントです。回答可能性は0.567対0.596で、2.9パーセントポイントの差があります。

関連性は、順位付けされた情報がクエリに適合しているかを測ります。回答可能性は、回答を裏付けるだけの情報を検索で見つけられたかを測る指標です。Fastはすばやく結果を返しても、次のモデルに渡す根拠が薄い場合があります。そのため、幅広い政策上の質問、複数企業の比較、見解が分かれる主張は、fastが軽快に見えても標準webに任せるべきです。

一方、Perplexityはベンダー集計図で、一見すると逆の結果も報告しています。公開されている6つのエージェント型ベンチマークから選んだ3,554件のタスク全体で、Fastはモデルと検索の推定総コスト**$59.73で64.3%、標準は$187.60で64.0%**でした。ベンダーは、fast構成が同程度の総合タスク品質を保ちながら約68%安いと説明しています。

この2つの結果は矛盾しません。総合的なエージェントは、モデル自身の知識や推論、繰り返し呼び出しで弱い検索を補える場合があります。また、選ばれたタスクでは、情報源の欠落が毎回不利になるとは限りません。コンプライアンスや事業調査にRaw検索システムを使う場合、後段のモデルが欠けた文書を補ってくれると想定してはいけません。

より広いAI検索APIガイドでも、各ベンダーに同じ運用原則を適用しています。次の決定論的なチェックを通過できる根拠一式が得られる範囲で、最も安い検索レベルを選ぶという考え方です。

Perplexity Search APIでsearch_typeをfastに設定する方法

同じリクエストを2回使い、search_typeだけを変えます。 query、max_results、search_context_size、フィルター、地域、クライアントの場所は同じ条件に固定します。現行のSearch APIリファレンスでは、webが標準で、max_resultsのデフォルトは10、抽出コンテキストサイズのデフォルトはhighです。比較時は両方を明示し、将来APIのデフォルトが変わっても再実行結果が変わらないようにします。

次の2つのリクエストは、そのまま実行できます。

set -euo pipefail
: "${PERPLEXITY_API_KEY:?Set PERPLEXITY_API_KEY first}"

QUERY='Which CRM has the stronger current EU data residency and audit-control evidence?'
COMMON=$(jq -nc --arg query "$QUERY" '{
  query: $query,
  max_results: 10,
  search_context_size: "high"
}')

for MODE in fast web; do
  jq --arg mode "$MODE" '. + {search_type: $mode}' <<<"$COMMON" |
    curl -sS 'https://api.perplexity.ai/search' \
      -H "Authorization: Bearer $PERPLEXITY_API_KEY" \
      -H 'Content-Type: application/json' \
      -o "$MODE.json" \
      -w "$MODE\tHTTP %{http_code}\t%{time_total}s\n" \
      --data-binary @-
done

この記事の制作時には、Perplexity APIの認証情報を利用できませんでした。そのため、レイテンシ、網羅性、空結果率、回答の裏付けについて、独自の測定結果は提示していません。以下の手順は小規模なペア比較であり、Perplexityによる6ベンチマークの調査を再現するものではありません。

事業調査向けのクエリを20件用意します。内訳は、権威ある情報源が明確な具体的検索10件と、複数の情報源を要する曖昧な質問10件です。実用的な固定セットには、現在のSaaS料金、クラウドの上限、規制の日付、対応国、セキュリティ統制、最近の提出書類、ベンダー比較、政策の影響、総コストに関する質問、賛否それぞれに信頼できる根拠がある主張を含められます。

シングルクエリ単位では、後段のモデル呼び出しを含める前の成功した40件のRawリクエストは$0.12です。内訳はfast 20回で$0.02、標準web 20回で$0.10です。

重要なのは平均結果数ではありません。弱いリンクの山より、少数の一次情報のほうが優れている場合があります。価格とレイテンシを意味ある指標にするのは、有用な網羅性と根拠に支えられた回答です。

切り替えで実際に発生するコスト

リクエスト本文の変更は簡単ですが、運用ポリシーの変更には作業が伴います。 ワークロードを標準webからfastへ移す際、データ移行も新しいエンドポイントも不要です。それでも、検索動作、キャッシュID、監視、障害処理は変わります。

キャッシュキーにはsearch_typeを含めます。広い検索範囲に料金を払った標準webのリクエストに、キャッシュ済みのfastレスポンスを黙って返してはいけません。同じ理由で、コンテキストサイズ、結果数、フィルター、国、言語もキーに含めます。

すべてのリクエストと後段の主張にモードを記録します。これがないと、情報源の採用率低下がモデルドリフトや偶発的な検索ノイズに見えてしまいます。ルーターには、empty_results、missing_primary_source、ambiguous_query、high_impactのようなエスカレーション理由も明示的に残します。

再試行もモードを意識して扱います。同じモードでタイムアウトを再試行するのは可用性対応です。fastからwebへの再試行は品質上のエスカレーションで、料金も変わります。両者を同じカウンターで数えてはいけません。

Fast Searchへ切り替えるべきでないケース

次の条件に当てはまるなら、Fast Searchを一律のデフォルトにしてはいけません。

• 契約、規制、セキュリティ、金融、医療情報、インシデント対応を扱い、情報源の見落としが重大な結果を招くエージェント。
• 既知の事実確認よりも、情報源の多様性を要する曖昧な質問がワークロードの中心である。
• 採用できる根拠の評価基準がなく、「速い」ことだけが目に見える成功指標になってしまう。
• プロバイダーアダプターやSDKが新しいenumを拒否し、チームが文書化された回避策や直接HTTPを安全に使えない。
• 成功した空レスポンスを通信障害と分けて記録していない。
• すべての回答ですでに必要な人の確認コストに比べ、標準webの追加料金が無視できる。

より良い移行方法は、ルーティングを使った段階展開です。繰り返し可能なクラスを1つだけfastへ移し、webをエスカレーション先として残し、採用できた根拠を比較してから対象を広げます。

月曜日に実行すること

全体のデフォルトを変える前に、シンプルな検索ポリシーを導入します。 繰り返し可能で影響の小さい検索はfastへ、曖昧または影響の大きい質問はwebへ送ります。そして、根拠が不合格なら、弱い回答をそのまま返さず自動でエスカレーションします。

作り物のデモではなく、先週のリクエストから始めます。製品の通常業務を代表する20件を選び、具体的な検索と曖昧な質問に分け、上記とまったく同じペアを再実行します。40件のシングルクエリがすべて成功した場合、Raw検索料金は$0.12です。

火曜日に確認するのは4つです。リクエストのp95レイテンシ、成功した空レスポンス、有用な情報源の網羅性、回答の裏付けスコアです。具体的検索グループでFastが根拠の基準を満たすなら、そのクラスだけを移します。曖昧な質問グループで一次情報を取りこぼすなら、総合ベンチマークの結果にかかわらず標準webを維持します。

これがPhotonの事業上の意味です。単一の安価なグローバル設定ではなく、実用的な検索リスクルーターを作れます。許容度の高いクエリでは1,000回あたり$1を使い、広い検索がより高価な見落としを防げるときだけ追加の$4を支払います。

よくある質問

ルーティング、検証、コストの論点を1枚で整理したい方は、AI Business Workflow Audit Checklistをダウンロードして、月曜日に最初の検索リスクルーターを設計してください。