AIエージェントが自分で検索パイプラインを書く — Perplexity「Search as Code」の設計思想

検索を10回呼んで、結果をフィルタして、もう5回呼んで、さらにランキングし直す。

AIエージェントに複雑な調査を任せると、こんなループが延々と回る。1回のタスクで数十万トークンが消え、レスポンスは遅く、コストは膨らむ。従来の「ツール呼び出し」型の検索は、エージェントが賢くなるほど非効率になるというパラドックスを抱えていた。

Perplexityが6月5日に発表したSearch as Code（SaC）は、この問題に対する構造的な回答だ。エージェントが固定APIを何度も叩くのではなく、Pythonコードを生成して検索パイプラインそのものを組み立てる。結果、あるCVE調査タスクではトークン使用量が85%減少し、精度は100%を維持した。

3層アーキテクチャという設計判断

Search as Codeの構造は明快だ。

第1層: モデル（制御プレーン） — ユーザーやエージェントの指示を分析し、必要な検索・処理パイプラインを設計、それを実装するPythonコードを生成する。

第2層: コンピュートサンドボックス — 生成されたコードを安全に実行する環境。制御フロー、バッチ処理、リトライ、フィルタリング、ジョイン、集約——こうした決定論的な操作をモデルのコンテキストウィンドウの外で処理する。

第3層: Agentic Search SDK — Perplexityの検索スタックが「組み合わせ可能なプリミティブ」として公開されている。非同期ファンアウト、重複排除、再ランキングといった操作をコードから直接呼び出せる。

従来のアプローチでは、エージェントが1回検索し、結果をコンテキストに入れ、次の検索クエリを考え、また検索する——というループをモデル推論の中で回していた。SaCでは、この一連の操作がPythonスクリプトとして一括で実行される。モデルが介在するのはパイプラインの設計段階だけだ。

なぜPythonなのか

Perplexityのチームはランタイム言語としてPython、Rust、TypeScript、Bashを検討したという。最終的にPythonを選んだのは、LLMのコード生成精度が最も高い言語であることと、データ処理のライブラリエコシステムが充実しているためだ。

サンドボックス内でSDKプリミティブを呼び出すコードは、1回の推論ターンで数千のオペレーションを実行できる。これが「ツールコールのループ」と決定的に違う点で、エージェントは検索戦略を宣言的に記述し、実行はサンドボックスに任せる。

実績: 288Kトークン → 43Kトークン

Perplexityが公開したベンチマークでは、200件のCVE（脆弱性情報）のベンダーアドバイザリを調査するタスクで、従来パイプラインが288.7Kトークンを消費したのに対し、SaCは42.9Kトークンで同じ精度を達成した。

CEOのAravind Srinivasは、OpenAIのResponses APIとAnthropicのManaged Agentsに対して「5つのベンチマークのうち4つで上回った」と主張している。数字の検証は第三者による追試が必要だが、アーキテクチャの方向性としては合理的だ。コンテキストウィンドウの中でループを回すよりも、決定論的な処理を外に出すほうが効率的なのは自明だから。

今すぐ試す方法

SaCは現在、2つの経路で利用できる。

Agent API — $0.005/web_search呼び出し ＋ モデルトークン料金。OpenAI互換のAPIエンドポイント（https://api.perplexity.ai）を使い、OpenAI/Anthropic/Google/xAIの各モデルをPerplexityの検索ツール付きで呼び出せる。単発の検索はSearch API（$5/1,000リクエスト）で十分だが、「検索→評価→再検索」のループが必要ならAgent APIのSaCが力を発揮する。

Perplexity Computer — SaCがデフォルトの検索メソッドとして組み込まれている。ユーザーがComputerでリサーチタスクを実行すると、裏側ではSaCが動いている。

正直な評価

強い点。 アーキテクチャの設計は筋が通っている。検索をコード生成の問題として再定義することで、エージェントの自由度とコスト効率を同時に改善できる。85%のトークン削減は、大規模なリサーチタスクをAPIで回すケースで直接的なコスト削減につながる。

気になる点。 まず、SaCの性能はモデルのPythonコード生成能力に依存する。生成されたコードにバグがあれば、検索結果が歪む。サンドボックス内のエラーハンドリングがどの程度堅牢かは、実運用してみないとわからない。

また、Perplexityの検索スタックに深く依存するため、ベンダーロックインのリスクがある。SDKプリミティブはPerplexity固有のものであり、他の検索エンジンには移植できない。

何が実現可能になるか

SaCが示した「検索をコードで制御する」という発想は、単なるAPI改善を超えた含意がある。

例えば、社内ナレッジベースの検索とWeb検索を同一パイプラインで組み合わせ、重複排除やクロスリファレンスを自動化するエージェントが作れる。従来は各データソースを個別に叩いて結果をLLMにまとめさせていたが、SaCなら検索戦略そのものをコードとして表現できる。

また、検索パイプラインがコードとして残るため、「なぜその情報を見つけたのか」のトレーサビリティが確保される。どのページを取得し、どの候補を棄却し、どのランキングステップが最終回答を形作ったかが追跡可能だ。監査やコンプライアンスが重要なエンタープライズ用途では、これは大きい。

検索インフラの覇権争い

Search as Codeは、AI検索を「ツール呼び出し」から「コード生成」に再定義する試みだ。開発者にとってはPerplexity API Platformから今すぐ試せる。

ただし、これは「Perplexityの検索スタックに乗る」という選択でもある。OpenAIはResponses APIでツール呼び出しの改良を進め、GoogleはGeminiのグラウンディングAPIで自前の検索インフラを押し出している。AI検索のインフラレイヤーで誰が勝つかはまだわからない。SaCのアーキテクチャが業界の方向性を決めるのか、Perplexity固有の武器で終わるのか——今後1年の動きに注目だ。