Agent APIのすべてのエフォートレベルを改善

Perplexity Agent APIのエフォートレベルを使うと、開発者はタスクごとにコスト、速度、調査の深さのバランスを選択できます。本日より、すべてのエフォートレベルでクエリあたりのコストが下がり、調査品質は向上または同等を維持しています。最も広範かつ包括的な調査向けに、新しいultraレベルも利用可能になりました。effort="fast", のようにレベルを名前で指定するリクエストには、更新された構成が自動的に適用されます。

調査エージェントを構築するには、タスクごとにコスト、速度、深さの適切なバランスを選ぶ必要があります。Agent APIのエフォートレベルは、その判断をユーザーに代わって行います。各レベルは、特定のタスクタイプに合わせてモデル、ステップ予算、検索設定、ツールを定義したバンドル構成です。Perplexityは各レベルを継続的に評価・更新し、現在のコスト以下で最高の調査を提供します。

これらの改善は、2種類の変更によってもたらされました。予算、コンテキスト処理、抽出によって各実行のコストが下がり、スキル、モデル選択、並列エージェントによって回答の品質が向上または維持されました。

mediumのパフォーマンスはBrowseCompとDSQAで55%から77%に向上し、コストは約90%減少しました。BrowseCompとDSQAは公開されている調査ベンチマークで、WANDRは複数のエンティティにまたがる長い調査タスクを対象としたPerplexity独自のベンチマークです。xhighは、サンドボックスでのコード実行、長時間にわたるツール使用ループの継続、多数の情報源の同時処理といったエージェント的な作業を行います。xhighは、2026年8月の構成の約25%のコストで動作しながら、WANDRスコア76.5%を維持しました。

深い研究のリクエストでは、回答するまでに数十回の検索を実行し、数百ページを読み、エビデンスを確認することがあります。こうしたアクションの一つひとつが、コンテキストにトークンを、請求額にコストを加えます。制限がなければ、エージェントは回答を改善しないまま、コストを押し上げコンテキストを圧迫するアクションを取り続けます。そのコストの大部分は、次の5つの要因によって生じます：

予算配分。予算が設定されたエージェントは、タスクを完了する前にステップを使い切り、実行を早期に終了してしまうことがあります。逆に、固定予算のないエージェントは実行を続け、最終的な回答を改善しないままコストが発生し続ける可能性があります。
コンテキストのオーバーヘッド。検索結果や取得したページにはエビデンスが含まれていますが、放置するとコンテキストウィンドウはすぐに無関係な情報で埋まってしまいます。コンテキストウィンドウのコストはステップからステップへと持ち越され、過負荷になったウィンドウはエージェントのパフォーマンスを低下させる可能性があります。
ワークフローの選択。タスクが異なれば、必要なアプローチも異なります。単一の事実の検索、マルチホップの質問、幅広い情報源の調査には、それぞれ異なるワークフローが必要です。モデルに任せると、非効率なワークフローを選んでしまうことがよくあります。利用可能なすべての戦略をエージェントのプロンプトに詳述しても、この問題は解決しません。追加の指示はステップごとにトークンとして持ち越され、モデルが各指示に従う確実性は時間とともに低下します。
モデルの選択。より大きなモデルに切り替えても、追加コストに見合ったパフォーマンスの向上が得られるとは限りません。新しいモデルは話題性や公開ベンチマークスコアとともに登場します。しかし、ベンチマークでの向上はデータ汚染によるものだったり、モデルの過学習を反映していたりする可能性があります。実際のタスクで評価しなければ、モデルを変更しても品質は上がらずコストだけが上がることがあります。
マルチエージェントのスケーリング。単一のエージェントが1回の実行で検索、読み取り、推論できる情報源の数には限りがあります。複数のエージェントを並列で実行すると、最も要求の厳しいタスクで品質が向上しますが、コストも増加し、適切に扱わなければ複雑さも生じます。

これらの課題をそれぞれ解決したことで、パフォーマンスを落とすことなく、各エフォートレベルのコストを削減できました。

各エフォートレベルには、次の3つの要素で構成される固定の調査予算があります：

ステップ制限：エージェントが実行できるターン数
ツール呼び出し：1つのリクエストにおけるツール呼び出しの総数の上限。1つのステップで複数のツールにまたがる複数の呼び出しを同時に行えるため、ステップ制限だけでは1ステップ内で発生するアクションの数を制御できません。
予算リマインダー：残りのステップ数を定期的に通知することで、エージェントがタスクの途中で予算を使い切ることなく、優先順位を付けて回答を書く余裕を残せるようにします。

予算は中心的なトレードオフです。ステップが多いほど回答は良くなりますが、ステップごとにコストが発生します。openai/gpt-6-lunaでは、ステップ制限を1から15に引き上げると、BrowseComp + DSQAの精度が41%から80%に向上する一方、クエリあたりのコストは$0.0017から$0.0152に上昇します。スコア約2倍に対し、コストは約9倍です。

ステップ制限だけでは調査コストを制御できません。同じ5ステップの予算でも、openai/gpt-6.1-terraはopenai/gpt-6-lunaよりも多くのツール呼び出しを行います。これは、より高性能なモデルほど1つのステップで複数の呼び出しを行う傾向があるためです。エフォートレベルは、ツール呼び出しとステップの両方に上限を設けています。これらのモデルでは、ツール呼び出しの上限はステップ制限と同じくらい重要です。

各エフォートレベルはこれらの制限を調整しますが、エージェント自身も、リクエストを遂行するために残りのステップとアクションがいくつあるかを把握している必要があります。この情報がないと、ステップやアクションを使い切り、調査が完了する前に回答せざるを得なくなることがあります。予算は実行の開始時に提示され、エージェントが上限に近づくとリマインダーが届くため、結果を検証して提供する余裕が確保されます。highでは、リマインダーはステップ予算とツール呼び出し予算の両方を対象とします。

予算リマインダーありとなしの2つのエージェントを、3人のキャストの経歴から1990年代のテレビシリーズを特定するBrowseCompタスクでテストしました。リマインダーありのエージェントは、予算40ステップのうち13ステップで正解にたどり着きました。予算リマインダーなしのエージェントは40ステップをすべて使い切り、正解を見つけられませんでした。このエージェントのループは予期せず終了し、モデルは残りの調査予算を把握していませんでした。リマインダーはエージェントの集中を保ち、残りのリソースを効果的に優先順位付けするのに役立ちます。

長時間実行される調査タスクでは、モデルのコンテキストウィンドウが検索結果、取得したページ、途中のメモで埋まっていきます。いっぱいになると、エージェントは作業を停止しなければなりません。

コンパクションにより、コンテキストウィンドウを埋め尽くすことなく長時間の実行を継続できます。コンテキストがしきい値を超えると、エージェントはそれまでの作業を、見つかった内容と残りの作業をまとめた短い要約に置き換えてから、処理を続行します。

コンパクションでは、システムプロンプト、元のリクエスト、エージェントがすでに読み込んだスキルの3つが常にコンテキストに保持されます。コンパクションのたびに、エージェントは2つの短い指示を受け取ります。1つ目の指示は「タスクが完了するまで作業を続けてください」です。これにより、エージェントが要約を終了地点とみなすのを防ぎます。2つ目の指示はこれまでに行われたコンパクションの回数を伝え、エージェントが残りの調査タスクを計画できるようにします。長時間の実行でも元の目標と計画が見失われず、品質を落とすことなく長いループのコストが削減されます。

エージェントが読むすべてのページはコンテキストに追加され、エージェントはそれを以降のすべてのステップで持ち越します。Webページには、ナビゲーション、定型文、その他のコンテンツなど、質問とは無関係な情報が含まれています。

fetch_url は、ページ全体をエージェントに渡すのではなく、まず抽出パスを実行します。ページのテキストは、エージェントの現在のタスクとともに、より小さなモデルに送られます。そのモデルは関連する箇所のみを、エージェントが引用できるよう原文どおりに返します。ある評価では、5,561トークンのページが293トークンに削減され、追加の関連コンテキストのための余裕が生まれました。

fetch_url を抽出付きで high エフォートレベルで使用したところ、クエリあたりの入力トークンが約50%削減されました。抽出によりベンチマークのパフォーマンスも向上し、抽出なしの場合はクエリあたり$0.094で83.5%だったのに対し、クエリあたり$0.073で88.0%を達成しました。

Web検索は、エージェントによるあらゆる調査リクエストの中核です。エージェントの検索方法に、次の3つの変更を加えました：

検索あたりのコンテキストを拡大：各検索で返される結果が、2Kトークンから最大4Kトークンに増えました。エージェントは必要な情報をより早く見つけられるため、検索回数が減り、コストも下がります。

新しいスニペットエンジン：検索結果にはクエリにより合致したスニペットが付与されるため、エージェントが無関係なテキストで過負荷になることはありません。
高速検索：1Kリクエストあたり$1.00のFast Searchは、各検索呼び出しのコストとレイテンシーの両方を削減します。

Perplexity Searchチームは、幅広いタスクで検索結果の取得品質を継続的に改善しています。最近のアップデートでは、コード、開発者向けドキュメント、リファレンスページ、法務、規制関連のコンテンツで改善が見られました。

多数の検索を並列で実行する必要があるタスクもあれば、少数の長いドキュメントを精読する必要があるタスクもあります。

しかし、すべてのワークフローをエージェントのシステムプロンプトに読み込むと、コンテキストのオーバーヘッドが増え、単純なタスクでモデルのパフォーマンスが低下する可能性があります。そこで、スキルは段階的開示を用いたツリー構造に整理されています。モデルは作業を進めながら関連するスキルと指示を読み込み、無関係な情報はコンテキストから除外します。各スキルのコストは、モデルがそのスキルがタスクに適していると判断して読み込むまでは名前と説明だけで済みます。読み込んだ時点で完全な指示がコンテキストに追加され、モデルは規定のワークフローに従います。

個々のスキルの貢献度を測るため、ベースラインのエージェントがそのスキルを読み込んだタスクで、スキルを1つずつ取り除いて品質とコストを比較します。こうしたアブレーションにより、どのワークフローがエージェントに役立ち、調査効率にどう影響するかがわかります。

以下のWANDRベンチマークの実行例は、エージェントが特定のタスクに対して適切なワークフローを選択している様子を示しています。複数のエンティティを調べる必要性を反映して、ワイド検索とファンアウトのガイダンスはすべてのタスクで読み込まれました。人物検索が読み込まれたのはタスクの6%のみで、それも質問が人物に関するものだった場合に限られました。

別のWANDRタスクのテストでは、エージェントはロンドンの推論エンジニアを見つけるために、ファンアウトパターンを備えた人物検索スキルを読み込みました。39の役職用語を117のクエリに展開し、1回目の結果を43件の一意のプロフィールに統合して、さらにスクリーニングを行いました。人物検索スキルは、無関係なコンテキストを追加することなく、この展開を通じてエージェントを導きました。以下の抜粋はエージェントのスクリプトを改変したもので、ヘルパー名は説明用です。

code1

text

Python

# roles contains the 39 role variants selected by the agent.
queries = []
for role in roles:
    queries.extend([
        {"query": f"Google DeepMind {role} London"},
        {"query": f"Google {role} London"},
        {"query": role, "company": "Google", "location": "London"},
    ])

results = pplx_sdk.search.people_many(
    queries, limit_per_query=50, concurrency=8
)

profiles = {}
for result in results:
    if not result.ok:
        continue
    for profile in result.result:
        if "linkedin.com/in/" not in profile.url:
            continue
        url = profile.url.split("?")[0].rstrip("/")
        previous = profiles.get(url, {})
        if url not in profiles or len(profile.summary or "") > len(
            previous.get("summary") or ""
        ):
            profiles[url] = {
                "url": url,
                "title": profile.title,
                "summary": profile.summary,
            }

チェックポイントは、長時間実行されるタスクでエージェントを支援するもう1つのワークフローです。チェックポイントパターンはバッチプログラミングに由来します。スクリプトが長いリストを処理する際、最後まですべてをメモリに保持するのではなく、結果が得られるたびにディスクに書き込みます。スクリプトが途中でクラッシュしたりエラーが発生したりしても、何も失われません。次の実行ではすでに保存された内容を読み込み、中断したところから再開して、失敗した項目のみを再試行します。

別のWANDRタスクでは、エージェントは188人のエンジニアのプロフィールをスクリーニングする必要がありました。エージェントはチェックポイントパターンを読み込み、作業しながら各結果を記録しました。1回目のパスでは160件のプロフィールを抽出しましたが、28件で失敗しました。エージェントがスクリプトを再実行すると、すでに記録済みのプロフィールはスキップされ、残りの28件のみが再試行されました。チェックポイントがなければ、不正なレコードが1件あるだけで188件すべてを再取得しなければならなかったでしょう。Pythonの抜粋（改変）。入力ページ、スクリーニング指示、スキーマ、インポートは省略。ヘルパー名は説明用です。

code 2

text

Python

checkpoint = Checkpoint("research/profile-screening")
config = instruction + json.dumps(schema)
config_id = hashlib.md5(config.encode()).hexdigest()[:6]

def checkpoint_key(page):
    url_id = hashlib.md5(page["url_in"].encode()).hexdigest()[:10]
    return config_id + url_id

pending = [
    page for page in pages if not checkpoint.has(checkpoint_key(page))
]
for offset in range(0, len(pending), 20):
    batch = pending[offset : offset + 20]
    inputs = [
        json.dumps({
            "url": page["url_in"], "content": page["content"][:30_000]
        })
        for page in batch
    ]
    results = pplx_sdk.llm.extract_many(
        inputs,
        instruction=instruction,
        output_schema=schema,
        chunk_size=5,
        concurrency=4,
    )
    for page, result in zip(batch, results):
        if not result.ok or result.result.error:
            continue
        checkpoint.record(
            checkpoint_key(page),
            [{"url": page["url_in"], **result.result.result}],
        )

チェックポイントは成功した結果を記録するもので、再試行は開始しません。指示とスキーマをキーに含めることで、スクリーニング基準が変更された場合に再処理がトリガーされるようにしています。

すべてのテストで品質と効率が向上したわけではありません。エージェントがタスクを開始する前にすべてのスキルを事前に読み込む方法も評価しました。BrowseCompとDSQAでは、事前読み込みによってコストが13%増加しました。調査の軌跡が長く、取得したコンテンツが入力トークンに占める割合が大きくなるWANDRでは、事前読み込みによってスコアも低下します。これらの結果から、段階的開示を引き続き採用することが裏付けられました。

モデルの能力が進化するにつれ、各エフォートレベルに最適なモデルも変わります。Perplexityは、新しいモデルの発表と提供状況を監視する自動調査ループを採用しています。モデルが利用可能になるとすぐに評価が開始されます。

新しいモデルがリリースされると、自動化されたエージェントがそのモデルを評価ハーネスにかけます。推論エフォート、ステップとツール呼び出しの予算、ツール構成を網羅的に試し、すべての実行を現在のエフォートレベルと比較して品質とコストの両面でスコア付けします。実行結果が後退した場合、エージェントはその原因を調査し、設定を調整して、評価を再実行します。候補モデルが現在のモデルに置き換わるのは、同等以下のコストで品質が上回った場合のみです。

公開ベンチマークは有用ですが、そのスコアが必ずしも実際のタスクに当てはまるとは限りません。たとえば下のグラフは、BrowseCompではベースラインを13.3ポイント上回ったものの、社内のエンタープライズ、法務、金融の調査タスクでは対応するベースラインを大きく下回った候補モデルを示しています。

単一のエージェントが1つのループでカバーできる情報源には限りがあります。複雑なタスクでは、複数のエージェントが並列で動作し、それぞれが問題の異なる部分を連携して担当します。

プライマリエージェントはオーケストレーターです。spawn_agentを呼び出して子エージェントを作成し、それぞれに具体的で焦点を絞ったタスクを割り当てます。各子エージェントは、独自のモデル、ツール、ステップ予算を使い、個別のコンテキストで独自の調査ループを実行します。子エージェントは結果を親に報告し、親は子エージェントにフォローアップの割り当てを送ったり、進捗を確認したりできます。オーケストレーターと子エージェントはメッセージをやり取りして、エビデンスを共有し、障害を知らせ、次のステップを調整します。新しい情報が届くとオーケストレーターは割り当てを改良し、作業が完了すると結果を1つの回答にまとめます。

Agent APIは事前定義されたエージェントロールをサポートしており、オーケストレーターはカスタム指示を持つ子エージェントを作成できます。

ultraエフォートレベルでは、1つのタスクで3つのエージェントを並列に実行します。各エージェントはタスク全体を独立して調査するため、異なるエビデンスが得られます。4つ目のエージェントがそれらの調査結果を統合し、重複を排除して、最終的な回答を作成します。

WANDRでは、ultraはタスクあたり$21.71で85.9%のスコアを記録しました。これはテストした構成の中で最高のスコアです。

エフォートレベルは継続的に評価・改善されています。ユーザーが選択するレベルによって、タスクにどれだけの調査を行い、どれだけのコストがかかるかが決まります。ステップとツール呼び出しの予算、そして残りが少なくなったときのリマインダーにより、リクエストは予算内に収まります。コンパクション、抽出、改良されたスニペットにより、コンテキストはエビデンスに集中した状態に保たれます。スキルはタスクに合ったワークフローを選び、並列エージェントは1つのループでカバーできる範囲を広げます。自動評価ループは、同じコストで調査品質を向上させる場合にのみ新しいモデルを採用します。

新しいモデルや構成が評価で実力を証明するにつれ、各エフォートレベルは今後も進化し続けます。レベルを名前で呼び出すと、こうした改善が自動的に反映されます。バージョンを固定すると、構成は固定されたままになります。

Agent APIを試して、ご自身のワークロードでエフォートレベルを比較してみてください。エフォートレベルの詳細は、Agent APIのエフォートに関するドキュメントでご確認いただけます。

調査のコスト

調査予算の管理

コンテキストの管理

コンパクション

必要なものだけを取得する

焦点を絞ったWeb検索

適切なワークフローの選択

モデルの選択

マルチエージェントのスケーリング

今後の展望