Open WebUIコミュニティ、MCPの引用フィールドマッピングを提案　イベントAPIへの依存軽減を目指す

Open WebUIで始まった新たな議論では、MCPナレッジベース統合の焦点がソースの表示に移った。10月8日、コミュニティメンバーが管理者設定による引用フィールドマッピングを提案し、翌日、Classic298は、外部MCPツールは現在もイベントAPIを通じてソースを送信できると強調した。したがって、今回の提案の実質的な価値は統合時の結合度を下げることにあり、プラットフォームがMCP引用にまったく対応していないという意味ではない。コミュニティでの議論

公式ドキュメントによると、外部のOpenAPIツールとMCPツールは、指定したチャットメッセージのイベントエンドポイントにsourceイベントを送信できる。ENABLE_FORWARD_USER_INFO_HEADERSを有効にすると、ツールへのリクエストにチャットIDとメッセージIDが含まれる。ソースデータは、段落とリンクを表すdocumentおよびmetadataの2つの対応配列で渡される。この方法はネイティブのツール呼び出しモードに対応する一方、サービス側でOpen WebUIのイベントインターフェースを扱う必要がある。イベントドキュメント

新提案では、接続設定で結果リスト、タイトル、本文、URL、ドキュメントIDに対応するフィールド名を指定する。ホスト側でまずMCPのテキストコンテンツ内にあるJSONを解析し、マッピングに従ってソースイベントを作成したうえで、ドキュメントごとにグループ化する。固定の応答形式を持つ検索サービスや、MCPゲートウェイ経由のサービスでは、単一のチャットインターフェースに合わせてサーバーを変更する作業を減らせる可能性がある。また、マッピングを特定の接続とツールに限定することで、ツール名だけを根拠に引用解析が適用されるのを防げる。提案とプロトタイプ

デプロイ時には、「ツールが返すコンテンツ」と「ツールが送信する引用イベント」を区別する必要がある。公式の開発ドキュメントによると、ネイティブモードで結果からソースを自動生成するのは、固定で組み込まれたツールのみだが、Pythonツールは引き続き引用を能動的に送信できる。以前のチュートリアルに記載されているself.citationフラグは、現在は機能しない。引用が欠落している場合、エンジニアはまず、どのデータ経路が使われているかを確認すべきだ。ツール開発ドキュメント

現時点でマッピング案は、提案者がv0.11.4で行った限定的なテストにとどまり、PRにはなっていない。今後は、上流で採用されるか、管理画面で設定を保持できるか、大量の結果やサードパーティ製MCPサービスと互換性があるかを見極める必要がある。企業のRAGチームが評価すべきなのは、引用の追跡可能性とサービス間の結合コストだ。現段階では、検証可能な統合基盤として公式のイベントインターフェースを使うのが適切である。テスト上の制約