9月1日、Keenable AIが「Keenable SELECT: an agent that searches the web in SQL」と題した記事を公開した。AIエージェントがWebを検索して報告書を生成するツールは増えているが、「検索条件をSQLで書く」という発想は異色だ。このアプローチがなぜコスト面・再現性の面で理にかなっているのか、仕組みを追いながら整理していく。

Keenable AIは同名のAIスタートアップで、今回公開されたショーケースページでは、エージェントが実際に実行したクエリと結果セットの全軌跡が公開されており、動作の中身をそのまま確認できる。プロダクトとしての完成度よりも「設計思想の提示」に重きを置いた公開形式だ。

AIによるWebリサーチの問題点と、SQLという解法

現在主流のWebエージェントはおおむね同じ構造を持つ。検索APIで複数のリンクを取得し、各ページをLLM（大規模言語モデル）に読ませて要約・集計させる。ページ数が増えるほどトークン消費は線形に増え、コストと精度のトレードオフが避けられない。

Keenable SELECTはこの構造を根本から変える。SQLクエリそのものがWebを検索する設計だ。

SELECT name, WEB_SEARCH(name || ' founding year'), ...
FROM companies
WHERE ...

WHERE句でまずフィルタリングを行い、生き残った行に対してのみWEB_SEARCHやWEB_FETCHといった「セマンティックオペレーター」を実行する。WEB_SEARCHはキーワード検索の結果URLリストを返し、WEB_FETCHは指定URLの本文テキストを取得する。LLMが呼ばれるのはフィルタリング後の行ごとのフィールド抽出時のみに絞られるため、元記事によれば1回のクエリで1,000ページ以上を検索・フィルタリングしながらもトークン消費を最小化できるという。「検索→読解→集計」という処理をSQLのパイプラインに落とし込んだ設計であり、条件の指定がプロンプトではなくクエリの文法として表現されるため、意図が明示的になるという副次的な利点もある。

MCPサーバーとしての構造

Keenable SELECTの実体はMCPサーバーとして実装されている。MCP（Model Context Protocol）はAnthropicが提唱・主導するオープン仕様で（公式仕様）、LLMとツールを連携させる標準インターフェースとして普及しつつある。ClaudeをはじめとするAIエージェントがツールを呼び出す際の共通プロトコルとして、2024年末以降に急速に採用事例が増えている。

このサーバーが提供するメインツールは2つだ。

• select: DuckDBのSELECT文を受け取り、結果行を返す。結果はサーバー側にIDとともに保存され、後続クエリから参照できる。クエリをまたいだ「メモリ」として機能する仕組みだ。
• generate_html_report: ブリーフ（指示文）と結果セットのIDを受け取り、HTMLレポートを生成して共有可能なリンクを返す。

SQLエンジンにはサーバーレスで動作する高速な分析用エンジンであるDuckDBを採用している。WEB_SEARCHやWEB_FETCHといったセマンティックオペレーターはDuckDB外部でサーバーが処理し、結果を通常のカラムとしてDuckDBに戻してから最終的なSQLを実行するアーキテクチャだ。

2段階のエージェント構成

レポート生成は2つのエージェントが連携して担う。

リサーチエージェントはシンプルなツールループで動作する。selectツールを持ったLLMが、自分でクエリを書いて実行するサイクルを回答が得られるまで繰り返す。ツール呼び出し・結果・回答はイベントとしてストリーミングされ、会話は蓄積されたトランスクリプトの上で継続できる。フォローアップ質問にも対応する設計だ。

レポートエージェントはサーバー内部で動作する第2のエージェントだ。ブリーフと結果セットの行データ、オーサリングガイドを受け取り、Pythonのサンドボックスセッション上でHTMLページを生成する。結果セットはdataframeとしてPythonセッション内に保持されるため、LLMがデータを再入力する必要がない点も効率化に寄与している。

レポートの公開時には、サーバーがドラフトをレンダリングしてスクリーンショットとJavaScriptエラー数を返却し、エージェントが問題を修正して再公開するサイクルを繰り返す。このサイクルには試行回数の上限（バジェット）が設定されており、上限に達した時点での最終ドラフトのみが公開リンクとして残る仕組みだ。

SQLによる検索制御が持つ意味

「AIがWebを検索して報告書を書く」という機能自体は珍しくない。Keenable SELECTが面白いのは、検索・フィルタリング・集計のロジックをSQLに押し込んだ点にある。

エンジニア視点で整理すると、このアプローチには3つの実用的な利点がある。

• コスト制御がクエリで完結する: WHEREによるフィルタをLLM呼び出しより前に実行することで、トークン消費を抑える構造がSQLの文法として自然に表現される
• 再現性の確保: クエリが残るため、どのデータをどう集めたかの軌跡が追いやすく、検索条件の監査・修正がしやすい
• インターフェースの汎用性: SQLは既存ツールやエンジニアの知識と親和性が高く、プロンプトより条件指定が明示的になる

AIエージェントの「制御しにくさ」が課題とされる中、SQLという長年の標準的な問い合わせ言語を制御インターフェースに据えたアプローチは、実運用を意識した設計として興味深い。

詳細はKeenable SELECT: an agent that searches the web in SQLを参照していただきたい。