Arize Phoenix、エージェントが SQL でトレースを照会可能な MCP サーバーを実装

TL;DR

Phoenix には組み込みの MCP サーバーが搭載されており、コーディングエージェントが MCP を介してトレースをクエリできるようになりました。

サーバーには現在、2 つの読み取り専用 SQL ツール「describeSqlSchema」と「executeSql」が用意されています。これにより、エージェントはトレースを手動でページ送りするのではなく、SQL で直接クエリを実行できます。

エージェントはコードモードで使用します。まず短いプログラムを記述し、そのプログラムがサンドボックス内でツールを呼び出します。そして、実行結果のみがモデルに返されます。

サーバーは、モデルから送られた SQL をそのまま実行することはありません。データベースに到達する前に、すべての文がチェックされ、再構築され、制限がかけられます。

8 つの質問からなるベンチマークでは、SQL ツールによる回答コストは、検索のみを行うツールと比較して約 17 分の 1 に抑えられました。

Phoenix には現在、組み込みの MCP（Model Context Protocol）サーバーが搭載されており、コーディングエージェントはコードの記述やデバッグと同じ環境からトレースを検査できるようになりました。

多数のスパンにわたる集計が必要な質問の場合、検索のみを行うツールではコストが高騰します。なぜなら、エージェントはモデルのコンテキストを介してデータをページ送りする必要があるからです。SQL を使うことで作業の形が変わります。フィルタリング、結合、集計はデータベースが処理し、中間結果はサンドボックス内に保持されます。

8 つの質問からなるベンチマークでは、このアプローチにより平均コストが約 17 分の 1 に削減されました。

検索のみを行う MCP の場合：カウント 1 つに 89 ターン必要

エージェントに質問 1 つとサーバー側の検索ツールのみを与えた場合、どのようなことが起こるのか見てみましょう。質問は「高インパクトエラーが発生したトレースはいくつあるか？」です。

これに答えるには、エージェントは各トレースを構成するスパンや、個別のモデル呼び出し、ツール呼び出しを一つずつ確認していく必要があります。まずプロジェクトを列挙し、適切なものを見つけ、1 ページごとにスパンを取得します。しかし、そのプロジェクトに含まれる JSON データ量は一度に処理できる量を超えていたため、エージェントは 1 ページを読み込んで必要な項目を集計し、次のページを取得してこれを繰り返すという手順を踏みました。

19 ページ目を経て正解「99 トレース」が導き出されました。この実行には 89 のターン（対話ステップ）がかかり、約 14 分、トークンコストは 10.35 ドルでした。

この大きなギャップを埋めるのが今回の機能です。データベースには最初から答えが入っていました。エージェントがこれほど高額なコストを支払って再計算する必要があったのは、ツールの設計形式が原因に過ぎません。

検索専用 MCP ツールがエージェントのトレース処理で高コストになる理由

多くの MCP 検索ツールは、データを取得対象オブジェクトとして公開しています。「プロジェクトをリストする」「スパンの 1 ページを取得する」「スパン内の注釈を読み取る」といった形です。この形式は、単一のトレースの詳細情報など「特定の 1 つのもの」を取得したい場合には理想的です。

しかし、「カウント数」「平均値」「パーセンタイル」「複数トレースにわたる内訳」などを求める質問に対してはこの形式が非効率になります。なぜなら、エージェントは関連するすべてのスパンを取得し、集計処理を自分で行わなければならないからです。そのような回答を得る唯一の方法は、関連するすべてのスパンを引き出して、自分で計算を行うことなのです。

この計算処理は、特に LLM のトレースデータにおいて非常にコストがかかります。一般的なインフラストラクチャのログ行は短く、タイムスタンプ、ステータスコード、実行時間といった要素で構成されます。一方、LLM のスパンにはプロンプトとCompletion（応答）が含まれるため、1 行あたりのデータ量がキロバイト単位に達することさえあります。このため、トレースデータをページごとに読み込むのは最も非効率な作業の一つですが、モデルが処理する前に要約を行うことは極めて有効です。

冒頭の例で起きた正是にこれでした。エージェントは 3,624 スパンすべてを取得し、19 ページにわたる JSON の計算結果を逐次追跡して数値を再構築しました。しかし、この数値はデータベースであれば単一のクエリで即座に生成できるものです。各ページがモデルを経由するたびに、ターン（対話回数）が増え、所要時間が延び、コストも膨らんでいきました。

取得対象のオブジェクトだけを渡されていれば、エージェントはスクレイパーのように振る舞います。私たちはそれを、アナリストのようにデータベースを直接クエリできる存在にしたいと考えました。

Arize Phoenix の MCP サーバーがコードモードで SQL を実行する仕組み

そこで、エージェントに対してデータベースへの直接問い合わせを可能にする 2 つのツールを用意しました。これらはすべて Phoenix の MCP サーバー上にあり、いずれも読み取り専用です。

describeSqlSchema は、エージェントにクエリ可能なテーブルとその接続構造を示します。一方、executeSql は単一の読み取り専用 SQL ステートメントを実行し、結果の行を返します。これらのツールを活用することで、エージェントはテレメトリデータの構造を確認した上で、SQL コンソールから質問するのと同じように、正確な問いかけを行うことが可能になります。

この仕組みのコストを抑えているのが「コードモード」です。チャットで一つずつツールを呼び出すのではなく、エージェントが短い Python プログラムを記述します。Phoenix はそのプログラムを制限された Monty サンドボックス内でサーバーサイドで実行し、そこから MCP ツールを呼び出します。中間的なスキーマの参照やクエリ結果はすべてサンドボックス内に留まり、モデルに届くのはプログラムが返す最終値だけです。Phoenix ではリモート MCP サーバーに対してデフォルトでコードモードが有効になっています。

ここで紹介するのは、ベンチマークで使用されるサンプルプロジェクト「trail-gaia」に対する高インパクトエラーの質問へのエージェントの回答例です。このプロジェクトには、低速実行時の 3,624 スパンが含まれています。このデータセットでは、高インパクトエラーとはスコアが 1.0 の trail_error アノテーションを指し、クエリは少なくとも一つの一致するアノテーションを持つ一意なトレース数をカウントします。

result = await call_tool("executeSql", {"sql": """
SELECT COUNT(DISTINCT t.id) AS n
FROM span_annotations sa
JOIN spans s ON s.id = sa.span_rowid
JOIN traces t ON t.id = s.trace_rowid
JOIN projects p ON p.id = t.project_rowid
WHERE p.name = 'trail-gaia'
AND sa.name = 'trail_error'
AND sa.score = 1.0
"""})

return result["rows"] # [[99]]: the only value that reaches the model

今回の実行では、7 ターンで約 33 秒、コストは$0.23でした。一方、従来の方法では 89 ターン、約 14 分、$10.35 かかっていました。回答自体は同じく「99 トレース」ですが、決定的な違いは 3,624 スパンが一度もデータベースから外部へ漏れ出さなかった点です。モデルに返されたのは最終的なカウント値のみでした。

Phoenix がエージェントが記述した SQL を読み取り専用にする仕組み

エージェントが記述する SQL には、厳格な境界線が必要です。Phoenix はモデルが発行したステートメントをそのまま実行するわけではありません。まずクエリを解析し、承認されたテレメトリデータに限定して再構築します。その上でデータベースレベルのチェックを適用し、実行時間と結果のサイズに上限を設けます。

まずは解析から始めます。サーバーは SQL を構造化されたクエリに変換するため、チェックではテキストがどのように記述されているかではなく、クエリが何を行うかに焦点を当てられます。

許可されたテーブルと列のみを対象とします。もしクエリが承認されたテレメトリの範囲外を要求した場合、実行前に拒否されます。

ステートメントを再構築します。Phoenix は解析したクエリから新しい SQL を生成します。データベースが実行するのはモデルの元のテキストではなく、この再構築されたステートメントです。

境界線の維持にはデータベース自体にも役割を担わせます。再構築されたクエリは、SQLite のオーザライザー（権限管理者）または Postgres のクエリプランチェックを通過する必要があります。

すべてのクエリに上限を設けます。クエリは読み取り専用であり、実行時間、行数、結果サイズによって制限されます。

これが核心的な契約です。SQL は読み取り専用で、信頼するのではなく解析され、実行前に境界が設定されます。SQL ツールはデータへの新たな経路を作るものではありません。利用可能なのは、サインインしたユーザーが Phoenix で既にアクセスできるテレメトリの読み取りのみであり、データベース内の何らかの変更を行うことはできません。

ベンチマーク：SQL＋コードモードと検索専用ツールの比較

同じエージェントを 2 つの構成（検索ツールのみ、およびコードモードで動作する SQL ツール）でそれぞれ 3 回ずつテストし、合計 8 つのテレメトリ関連の質問に回答させました。質問の内容は、カウント数、パーセンタイル値、カテゴリ別の内訳、結合処理、時系列トレンドなど多岐にわたります。各回答についてはスコアリングモデルによる自動評価を行い、最終的には手動レビューも実施しました。

ベンチマーク全体の結果では、SQL とコードモードを組み合わせることで 1 問あたりの平均コストは約 0.23 ドルとなりました。一方、検索ツールのみを使用した場合の平均コストは 3.97 ドルでした（つまり、前者は後者の約 17 分の 1 のコストです）。

質問ごとの詳細な結果は以下の通りです：

• Question：SQL $ / Retrieval $ / Retrieval / SQL / SQL turns / Retrieval turns
• High-impact error count：0.23 / 10.35 / 44x / 7 / 89
• p95 LLM-span duration：0.22 / 4.96 / 23x / 6 / 49
• 10-min time buckets：0.28 / 4.76 / 17x / 6 / 100
• Average span duration：0.19 / 3.69 / 19x / 6 / 54
• Five longest spans：0.23 / 3.66 / 16x / 6 / 55
• Breakdown by span kind：0.18 / 1.90 / 10x / 6 / 89
• Tool-related error count：0.22 / 1.71 / 8x / 7 / 67
• Average reliability score：0.31 / 0.70 / 2x / 8 / 13
• Average：0.23 / 3.97 / 17x / 6.5 / 64.5

コストは明らかな違いですが、唯一の違いではありません。スパンを種類ごとにグループ化して内訳を見ると、SQL の実行結果は 6 ターンで正確なカウントを返しました。そのうちの一つの試行では、検索エージェントがプロジェクト全体をページネーションし、保存したファイルを探索した結果、TOOL タイプのスパンが 622 件と報告されました。実際の数は 626 です。この 4 スパン分の誤差は 103 ターンにわたって $2.01 のコストがかかりましたが、スコアリングモデルは依然としてこれを「正解」と判定しました。手作業で十数ページにわたってカウントする際、このような小さなエラーが見過ごされるのはまさにこの手のケースです。

ベンチマークにはまだカバーされていない二つの側面があります。最も複雑な多段階の相関関係は今回のセットに含まれていません。また、最後の行にある単一のフィルタ付きカウントのような単純な検索タスクでは、SQL には圧縮する対象がないため、検索ツールの方がコストを抑えられる可能性があります。手作業で回答を再構築する必要がある場合、つまりデバッグの大半の場面で SQL は有利に立ちます。

コーディングエージェントを Phoenix の MCP サーバーに接続する

Phoenix の組み込み MCP サーバーはバージョン 19.0.0 以降で使用可能で、SQL ツールは v20.2.0 以降で利用できます。Claude Code、Cursor、MCP Inspector、または他の MCP クライアントを Phoenix エンドポイントに接続し、OAuth を経由して認証を行ってください。px CLI を使用すれば設定ファイルを自動生成することも可能です：

Copy

px setup mcp --agent claude # or codex, cursor, gemini, opencode, vscode

手動での設定も可能です。Claude Code の場合は以下のコマンド一つで完了します：

Copy

claude mcp add --transport http phoenix https://your-phoenix-host/mcp

各クライアントの設定詳細については、リモート MCP サーバーのドキュメントをご覧ください。

すでに本番環境のトレースデバッグで使っている質問をそのまま投げかけましょう。「どのツールが最も頻繁に失敗しているか」「レイテンシが集中する箇所はどこか」「今週エラーが発生したトレースはどれくらいあるか」などです。

エージェントはスキーマを検証し、読み取り専用のクエリを記述して回答を返します。すべてのスパンをモデルのコンテキストに転送する必要はありません。

Phoenix はオープンソースであるため、その機能全体を自由に閲覧・設定・無効化できます。セルフホスト環境では、クエリはベンダーのクラウド上のコピーではなく、あなたがすでに運用している SQLite または Postgres データベースに対して実行されます。

Phoenix の MCP 設定ページ。デフォルトでコードモードが有効になっており、サーバー URL はクライアントへの接続準備ができています。各クライアントには、1 行で接続できるコマンドも用意されています。

関連リソース：まずはリモート MCP サーバーのドキュメントから始め、PXI（コーディングエージェントのトレーシングと評価）や Arize Phoenix の今後の展望についてもご覧ください。より広範なスタックについては、「トレースからのエージェント評価構築」や、Model Context Protocol (MCP) および trace に関する用語集エントリも参照してください。

Phoenix の MCP サーバーに SQL が加える価値

観測性ツールはこれまで、チームがシステム内で何が起きているかを理解する手助けをしてきました。今では、エージェントがそのデータを直接クエリして必要な回答を即座に取り出せるようになりました。すべての行を別の場所に移動させる前にデータベースで集計を行うという、データ処理における最も基本的な教訓を、エージェントも活用できるようになったのです。

SQL は汎用性が高いため、基盤として最適です。誰も予想していなかった質問、来週あなたが思いつくような問いにも答えられるからです。

この機能を備えたのは、トレースを読み取るエージェントが、膨大なデータページを収集する段階から、具体的な質問を投げかける段階へと移行できるようにするためです。

ご自身のトレースに指向し、何が正しく機能し、どこで課題を抱えるかを確認してください。フィードバックがある場合は、Phoenix コミュニティの Slack でご連絡ください。

本記事「Arize Phoenix には SQL を使用してトレースを照会できる組み込み MCP サーバーが搭載されている」は、元々 Arize AI の投稿でした。