問題はエージェントではない – 既存のシステムとAPIはAI向けに作られていない

エンタープライズ環境では、AIエージェントが多数のレガシーAPIと対話する際に大きな課題に直面します。これらのAPIは、多くの場合、10年以上前にエンジニアが命名した規則に従っており、getProcInfo3のような名前で、説明は「ドキュメント参照」としか書かれていないことがよくあります。このようなAPIは大規模言語モデル（LLM）にとってほとんど読み取れません。MCP Bridgeはこの問題に対処するため、ハイブリッド検索とAIエンリッチメント（AI Enrichment）という2つの主要コンポーネントを導入しました。

ハイブリッド検索メカニズム

当初、チームは純粋なベクトル検索を試しました。各ツールの名前と説明をOpenAIの埋め込みモデルで埋め込み、pgvectorに保存し、実行時にクエリします。これは教科書的なデータセットではうまく機能しましたが、エンタープライズAPIでは、類似した埋め込みでも異なる意図を持つツール（get_customer、get_customer_full、get_customer_with_orders）があると失敗しました。次に全文検索（Postgres FTS）を試しました。正確な一致には優れていますが、エージェントの意図とツールの説明の語彙が一致しない場合には効果が薄いことがわかりました。最終的に採用されたのはハイブリッドアプローチです。最初にPostgres FTSが第1パス（BM25スタイルのランキング）を行い、次にpgvectorがその上位候補とより広いセマンティックプールに対して第2パスを実行し、小さな再ランカーが2つの順序付きリストを1つのスコアに統合します。再ランカーはエージェントの最近のコンテキストも考慮します。エージェントが顧客データを扱っている場合、顧客関連のツールが上位にランクされます。

本当の問題：データそのもの

しかし、検索メカニズムがどれほど優れていても、ソースデータの質が最終結果を左右します。例えば、getProcInfo3(custId, opt) → objectというツールでは、シグネチャだけではほとんど情報が得られません。一方、返されるJSONレスポンスには豊富なシグナルが含まれています：custId、billingAddress、accountStatus、primaryContact、assignedManager。レスポンスの形状こそが、このツールが実際に何をするか（顧客アカウントのルックアップ）を明らかにします。

チームは顧客にAPIの名前を変更するよう依頼することも検討しましたが、小規模では可能でも、70のレガシーサービスを持つ顧客には非現実的でした。そこで、AIエンリッチメントを構築しました。

AIエンリッチメントの仕組み

MCP Bridgeは、OpenAI互換のチャット補完エンドポイントを指すことができます（内部ではAzure OpenAIを使用、AnthropicやローカルのLlamaもサポート）。エンリッチメントを有効にすると、プラットフォームは各ツールについて、名前、（多くの場合空の）説明、パラメータスキーマ、レスポンス型定義（OpenAPI、WSDL、.protoから取得）、そして不透明なAPIについてはプローブコールやトレースから取得したレスポンスサンプルを収集します。次に、より明確な名前、ツールの機能と使用タイミングを説明する1～2文、および3～5個のタグまたはエイリアスを生成するようモデルに指示する構造化プロンプトを送信します。出力はスキーマに対して検証され（幻覚パラメータや入出力型のセマンティックドリフトがないことを確認）、エンリッチされたメタデータは元のスキーマとともに保存されます。ツール呼び出しは元の名前とスキーマを引き続き使用し、発見レイヤーのみがエンリッチされたバージョンを見ます。

最も重要なシグナルはレスポンス形状です。名前と説明だけではモデルはgetProcInfo3とgetProcInfo4を区別できませんが、レスポンス（またはサンプル）を見れば機能が明確になります。SOAPサービスの場合、WSDLが通常レスポンス型を提供します。ドキュメントのないAPIについては、MCP Bridgeは一度限りのプローブを実行するか、トレースから抽出します。

重要な点として、エンリッチメントはサービスごとにオプトインであり、元のスキーマは保持されます。エージェントが名前を変更されたパラメータを見ることは決してありません。これにより、ソースAPIからの静かな乖離を防ぎます。

効果とエンジニアリングの詳細

実際の（匿名化された）顧客のSOAPサービスでは、元のgetProcInfo3がget_customer_account_detailsにエンリッチされました。説明は「顧客のアカウントプロファイルを取得します。請求先住所、アカウントステータス、主要連絡先、担当マネージャーを含みます。サポート、請求、または営業アクションを開始する前にアカウント状態を確認するのに役立ちます。」となり、エイリアスも付与されました。

この顧客のサービスでは、エージェントタスクスイートにおけるツール選択精度が41%から89%に向上しました。RESTサービスはすでに妥当な名前を持っていたため、改善は71%から88%と控えめでした。

エンジニアリング面では、エンリッチされた説明が変更されたときに埋め込みが再生成されますが、元の埋め込みも保持され、検索時に重み付け（元×0.3 + エンリッチ×0.7）で組み合わせることで、単独使用よりも優れた結果が得られました。再ランカーは小型の交差エンコーダで、手作業で作成した数百の（意図、ツール、ラベル）トリプルでトレーニングされています。コスト管理として、再エンリッチメントは変更があったサービスに対してのみ夜間に実行され、200の操作があるサービスの完全エンリッチメントパスには通常約30セントのGPT-4クラスの推論コストがかかります。管理UIではヒット率メトリクスが表示され、どのツールがsearch_toolsで発見され、どれが無視されているかを確認できます。これは、どのサービスを最初にエンリッチするかを判断するための最も有用なシグナルです。

おわりに

MCP Bridgeの次のステップはレスポンス後処理（Response Post-Processing）であり、近日公開予定です。ハイブリッド検索とAIエンリッチメントのコードはdocs.mcp-bridge.aiで利用可能です。