Xでの発表内容

Perplexityは2026年3月11日、Xで自社APIをエージェント開発向けのfull-stackかつmodel-agnosticなプラットフォームとして位置づけた。狙いは統合にある。従来はmodel provider、search layer、retrieval stack、実行環境を別々のベンダーで組み合わせる必要があったが、そのより大きな部分をPerplexity側でまとめて提供する構想だ。

メイン投稿はプラットフォームの方向性を示すものだったが、続くスレッドで製品構成が具体化された。Perplexityは1つのAPI keyでAgent API、Search API、Embeddings API、さらに準備中のSandbox APIを扱うと説明した。スレッド上では、Agent APIがmulti-step workflow向けのorchestrationレイヤー、Search APIがcitation付きのリアルタイムweb context、Embeddings APIがretrieval、Sandboxがagent向けdeterministic code executionを担う位置づけになっている。

公式ドキュメントで確認できる点

Perplexityの公式ドキュメントは、1つのoverviewの下でAgent API、Search API、Embeddings APIのquickstartを並べている。ドキュメントではAgent APIをthird-party modelとweb-search tool/presetにアクセスするレイヤー、Search APIをfilteringとreal-time dataを備えたranked web results、Embeddings APIをsemantic retrieval基盤として説明している。加えて、recent changelogにAgent APIとEmbeddings APIの個別リリースが載っており、Perplexityが単発endpointではなく広いdeveloper platformを組み上げていることが分かる。

PerplexityはXで、Search APIがSimpleQAとSEALでstate of the artであり、リアルタイム更新される200B+ URLsのindexに直接アクセスすると主張した。
同じスレッドでは、pplx-embed-v1-4BがMTEB retrieval、ConTEB、3000万超の文書を使うinternal benchmarkで先行すると述べている。
Sandbox APIについては、まずAgent API内のtoolとして提供し、その後standalone serviceとして公開する予定だと説明した。

なぜ重要か

実務面で重要なのは、agent complexityの管理だ。多くの開発チームは今でも、model、search、retrieval、tool executionの各レイヤーを別々の供給元から組み合わせている。これは運用面の表面積を増やし、コスト、遅延、tracingの管理を難しくする。Perplexityはvertical integrationでこの組み立て負荷を下げられると見ている。

競争戦略としても意味がある。単独の自社modelではなくmodel-agnostic orchestrationを前面に出すことで、Perplexityは自分たちを単なるinference endpointではなくインフラ層として売り出そうとしている。ただし、Xスレッドだけではまだ確定しない点もある。benchmarkやscaleの主張が実際の顧客workloadでも再現されるのか、そして開発者がmodular architectureよりbundled agent stackを好むのかは今後の検証事項だ。

出典: Perplexity X投稿, Perplexity docs overview, Perplexity changelog

#search-api

Perplexity、モデル非依存のエージェント向けフルスタックAPI基盤を打ち出す