Search as Code：PerplexityはいかにAIエージェント時代のために検索を再発明したか

検索ボックスはAIのために作られたものではなかった

検索エンジンをどう使うかを考えてみてほしい。質問を入力し、結果をスキャンし、リンクをクリックし、次に進む。この体験全体はあなた——目を持ち、注意力を持ち、判断力を持つ人間——のために設計されている。

次に、AIエージェントについて考えてみよう。エージェントはブラウズしない。スキャンしない。実行するのだ。一つのタスクの中で、現代のAIエージェントは数分間に何百、何千もの検索操作を実行する必要があるかもしれない——ソースを相互参照し、雑音を除去し、信号をランク付けし、機械的な速度で結論を統合する。 (1)

従来の検索ボックスは、そもそもこのような用途のために設計されたものではなかった。そして、検索が「あるべき姿」とAIエージェントが「必要とするもの」との間のこのギャップこそが、Perplexityの新しい**Search as Code（SaC、検索即コード）**アーキテクチャが埋めようとしているものだ。

---

検索即コードとは何か？

検索即コードは、Perplexityが2026年に導入した新しい参照検索アーキテクチャだ。核心となる考え方はエレガントだ。検索をランク付けされた結果を吐き出す一枚岩のブラックボックス的サービスとして扱う代わりに、SaCは検索の個々の構成要素を、開発者向けSDK内でプログラム可能なプリミティブとして公開する。

SaCを使うAIエージェントは、検索エンジンを単に「呼び出す」だけではない。手元のタスクにぴったり合わせた、オンデマンドのカスタム検索パイプラインを組み立てるコードを書くのだ。 (1)

これは、レストランで固定のセットメニューを注文することと、設備の整ったキッチンを持つこととの違いに似ている。従来の検索は固定メニューだ。検索即コードはそのキッチンである。

モデルは検索プロセスのあらゆるステップに対して、直接的かつきめ細かな制御を獲得する。

• 検索（Retrieval） — 何をどこから取得するか
• ランキング（Ranking） — 結果をどのように採点し優先順位付けするか
• フィルタリング（Filtering） — 何を捨てるか
• ファンアウト（Fan-outs） — 検索を並行してどう分岐させるか
• レンダリング（Rendering） — モデルが消費するために情報をどうフォーマットするか
• 検証（Verification） — 発見事項をどう相互確認し検証するか (2)

これらすべては安全なサンドボックス内で実行され、エージェントは検索プロセス全体を動的に調整するPythonコードを生成する。

---

従来の検索がエージェント的要求に応えられなくなっている理由

Perplexityの研究チームは率直にこう述べている。従来の検索パイプラインは、エージェントの時代においてますます時代遅れになっている。その理由は以下の通りだ。

固定パイプラインは可変タスクに対応できない

従来の検索は、予測可能なパターン向けに設計されていた。1つのクエリが入り、n個のランク付けされた結果が出る。これは、レシピを調べる人間にとっては見事に機能する。しかし、AIエージェントが次のようなタスクを与えられたとき、それは破滅的に崩壊する。

「過去90日間に主要ベンダーが公開したすべての高深刻度CVEを特定し、私たちのインフラスタックと相互参照し、優先順位付けされた修復レポートを作成してほしい。」

このタスクは1回の検索呼び出しには収まらない。数十件の的を絞ったクエリ、ソースの検証、重複排除、集約——すべてが動的に調整される必要がある。 (3)

一枚岩のアーキテクチャは組み合わせ可能性を殺す

現代のAIシステムは組み合わせ可能性——モジュール化されたツールをブロックのように組み合わせる能力——の上に構築されている。一枚岩の検索サービスはこれとは正反対だ。それは一つの巨大で不透明な単位であり、一度にすべてを行い、その途中で何も公開しない。 (1)

中間状態への可視性がない

SaCの最も強力な機能の一つは、検索が進行する中でエージェントに中間状態——候補リスト、ランキング信号、部分的な結果——へのアクセスを与えることだ。従来の検索はこれらすべてを隠している。得られるのは最終出力だけであり、それ以外は何もない。タスクの途中で推論し適応する必要があるエージェントにとって、これは重大な制約だ。 (1)

---

アーキテクチャ：SaCは実際にどう機能するのか

Perplexityのエージェント検索SDKは、SaCの背後にあるエンジンだ。可能な限り原子的なレベルで検索コンポーネントを公開し、パフォーマンスを犠牲にすることなくエージェントに最大限の柔軟性を与える。

流れは次のようになる。

1. タスクが到着する — エージェントが複雑でオープンエンドなタスクを受け取る
2. コード生成 — フロンティアモデルが、カスタム検索パイプラインを定義するPythonコードを生成する
3. サンドボックス実行 — コードが安全で分離された環境で実行される
4. プリミティブの組み立て — エージェントが必要に応じて検索、ランキング、フィルタリング、レンダリングのステップを組み合わせる
5. 実行中の最適化 — エージェントが中間結果を監視し、パイプラインを動的に調整する
6. コンテキストの配信 — 最も関連性が高く、信号の強い情報だけがモデルに返される (1)

これは、従来の検索APIをシェルスクリプトでラップすることとは根本的に異なる。Perplexityは、SaCが単に検索APIを言語ランタイムの中に貼り付けたものではないと明確に述べている——それはエージェント利用のために検索スタックをゼロから再設計したものだ。 (1)

---

実際の結果：数字が語る

SaCは単なる理論的なアーキテクチャではない。Perplexityは厳密にベンチマークを行い、その結果は目を見張るものだった。

公式ベンダーのアドバイザリから200件以上の高深刻度CVEを特定するテストケースにおいて、

• SaCは100%の精度を達成した
• トークン使用量は、非SaCのベースラインと比較して**85.1%**減少した (3)

より広範なベンチマークスイート全体で、SaCは5つのベンチマークのうち4つで他のエージェントベースの検索システムを上回り、広範な調査タスクを評価するために特別に設計された新しいベンチマークWANDRで最大の差をつけた。 (2)

効率性の向上は特に重要だ。エージェント的なワークフローでは、トークン使用量はコストとレイテンシに直接変換される。85%の削減はわずかな改善ではない——それは変革だ。

---

より広い「as Code」運動の中の検索即コード

SaCは孤立して存在しているわけではない。それは、複雑なシステムを透明で、再現可能で、プログラム可能にするという長年の運動の最新の章だ。

これらすべてに共通するテーマは、手動で不透明な、人間主導のプロセスをバージョン管理された、機械実行可能なロジックに置き換えることだ。 (4)

SaCパイプラインはコードであるため、Gitに保存し、プルリクエストでレビューし、CI/CDパイプラインでテストし、失敗したらロールバックできる。検索の動作はソフトウェアの成果物となる——監査可能で、改善可能で、チーム間で共有可能なものだ。

---

これは開発者と企業にとって何を意味するのか

AI駆動のプロダクトを構築しているなら、検索即コードはあなたの仕事に直接的な意味を持つ。

AIエンジニアにとって

検索戦略を第一級のソフトウェアコンポーネントとして設計できるようになった。デバッグする。テストする。バージョン管理する。エージェントやチーム間で共有する。ソフトウェアエンジニアリングの規律が、ついに検索にも適用される。 (1)

プロダクトチームにとって

SaCの上に構築されたエージェント的プロダクトは、より高い精度とより低いコストで、劇的に複雑なタスクを処理できる。上記のCVEの例は、検索が本当にプログラム可能になったときに可能になることの予告編だ。 (3)

コンテンツ制作者とSEO専門家にとって

エージェント検索の台頭は、発見可能性を再構築する。AIエージェントがウェブコンテンツの主要な消費者になるにつれ、構造化された、意味的な、機械が読み取り可能なコンテンツが、キーワードを詰め込んだページを上回るようになる。エージェント向けの最適化こそが、新しいSEOだ。 (2)

---

認識すべき課題

パラダイムシフトに摩擦がないことはない。SaCは実際の課題をもたらす。

• エンジニアリングの壁 — 検索パイプラインをコードとして書くには、多くのチームがまだ持っていないAIエンジニアリングの専門知識が必要だ
• デバッグの複雑さ — 非決定的で、エージェントが生成したコードは、従来のソフトウェアよりもデバッグが難しい
• セキュリティの攻撃対象領域 — サンドボックス内でのコード実行は、慎重に管理する必要がある新たな攻撃経路を生む
• 標準化 — SaCが成熟するにつれ、業界は異なる検索SDK間の相互運用性を確保するための共通標準を必要とするようになる (1)

これらは解決可能な問題だ。しかし現実の課題であり、SaCを採用するチームはそれに備えて計画すべきだ。

---

より大きな構図：機械のために構築されたウェブ

視野を広げると、検索即コードは、はるかに大きな何かの兆しだ。ウェブが機械の消費のために再構築されているのだ。

30年間、ウェブは人間のために構築されてきた。ページは目で読むために設計されていた。検索エンジンは人間の注意を満たすために設計されていた。初期のAI検索システムでさえ、本質的にはAI層を上に載せた人間の検索にすぎなかった。

SaCは、そのパラダイムからの本当の決別を示している。AIエージェントが自分自身の検索パイプラインを書けるようになると、それらは人間のようにウェブを使っているのではない——ウェブを編成しているのだ。インターネット全体を、プログラム可能なデータレイヤーとして扱っているのだ。 (1)

これは小さな変化ではない。知能と情報の間の新しい関係だ。

---

結論：検索の未来はコードで書かれる

検索即コードは、現在AIにおいて最も重大な意味を持つアーキテクチャ上のアイデアの一つだ。検索を固定サービスから、組み合わせ可能で、プログラム可能で、バージョン管理可能なシステムへと変えることで、PerplexityはAIエージェントに、これまで常に必要としていながら決して持てなかったもの——情報をどう見つけ、どう処理するかに対する真の制御力——を与えた。

検索ボックスがなくなるわけではない。しかし検索の未来——自律型エージェント、複雑な調査ワークフロー、そして実世界のAIアプリケーションを動かす種類の検索——はコードで書かれることになる。

そして、そのコードはすでに動いている。

---

参考資料

1. Perplexity AI Research — Rethinking Search as Code Generation — research.perplexity.ai
2. Reddit / r/AIGuild — Search Is Becoming Programmable for AI Agents — reddit.com/r/AIGuild
3. Zeniteq — Perplexity Search as Code Lets AI Agents Write Their Own Search Pipelines — zeniteq.com
4. DevTalk Forum — Rethinking Search as Code Generation – In The News — forum.devtalk.com

---

タグ：検索即コード、SaC、Perplexity AI、AIエージェント、エージェント検索、大規模言語モデル、AIアーキテクチャ、開発者ツール、検索の未来