UltraRAG を採用する前に読む、MCP サーバ構成と YAML オーケストレーションの実際
A Low-Code MCP Framework for Building Complex and Innovative RAG Pipelines
ひと目でわかる
- これは何？
- RAG パイプラインの構成要素を MCP サーバとして分離し、YAML で制御構造を組む低コードフレームワーク。研究探索と業務プロトタイプのどちらに向くかを、確認できる範囲で整理する。
- 誰に向いている？
- UltraRAG は、RAG の各段を独立した MCP サーバとして切り出し、条件分岐やループを含む制御構造を YAML で書きたい研究チームと、UI から対話デモまで短時間で組み上げたい試作担当者に向く。既存の本番 RAG があり、リランカやクエリ書き換えの挙動をアプリ側のコードで細かく制御しているチームには向かない。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
UltraRAG が埋めようとしているのは配線の手間であって、検索精度ではない
RAG の実装で時間を食うのは、埋め込みモデルの選定やプロンプトの調整よりも、検索、再ランク、生成、評価をつなぐ配線のほうになりやすい。試すたびに Python のスクリプトが分岐し、実験の再現に必要な設定がコードのあちこちに散る。UltraRAG はこの配線部分を対象にした道具で、Retriever や Generation といった中核コンポーネントを独立した MCP サーバとして標準化し、呼び出し側の MCP クライアントがワークフローを編成する、という分担をとる。README は開発者向けの説明として、条件分岐やループのような制御構造を YAML の設定ファイルだけで書けると述べている。想定読者も明記されていて、研究探索と産業向けのプロトタイピングである。検索品質そのものを上げる仕組みではなく、実験の組み替えと再現を楽にする側の道具だと理解しておくほうが正確だ。
MCP サーバと MCP クライアントに分けるという設計判断
構成は二層である。下層に、機能ごとに切り出された MCP サーバが並ぶ。検索器、生成器、その他の処理がそれぞれ独立したサーバとして扱われ、新しい機能は関数レベルのツールとして登録すればワークフローに組み込める、というのが README の説明である。上層には MCP クライアントがいて、複数のサーバを順に呼び、ループさせ、条件で分岐させる。この分担の利点は再利用性で、同じ検索サーバを別のパイプラインから呼べる。代償は呼び出しの間接化である。関数呼び出し一つのためにプロトコルを経由するので、処理の流れはコードを上から読むだけでは追えなくなる。README とリポジトリ構成から確認できるのはここまでで、サーバが同一プロセス内のオブジェクトなのか、別プロセスの常駐なのかは判別できない。この点は実測しないと決められない。
YAML で書ける範囲と、書けない範囲
README が挙げる制御構造は逐次、ループ、条件分岐の三つで、反復的な RAG のロジックを数十行の YAML で書けるとしている。設定ファイルで表現できるということは、実験の差分が diff として残るということでもある。パラメータとプロンプトを YAML 側に寄せておけば、同じパイプラインの変種を並べて比較しやすい。ただし YAML はデータ形式であって言語ではない。分岐の条件式が複雑になったり、複数のサーバの戻り値を突き合わせて中間状態を作ったりする処理は、いずれ設定ファイルの表現力の外に出る。そのときに逃げ道が用意されているのか、それとも MCP サーバ側にロジックを押し込むしかないのかは、README からは読み取れない。低コードという言葉が効くのは、制御の分岐が shallow なうちだけだと考えておいたほうがいい。
UltraRAG UI は何を肩代わりし、何を肩代わりしないか
UI は単なるチャット画面ではなく、編成とデバッグとデモを兼ねた作業環境として説明されている。中心は Pipeline Builder で、キャンバス上での構築とコード編集が双方向に同期し、パイプラインのパラメータとプロンプトをその場で調整できる。AI アシスタントが構造設計からパラメータ調整、プロンプト生成までを支援するという記述もある。組み上がったフローはワンクリックで対話システムに変換でき、ナレッジベース管理の部品も統合されているため、文書 Q&A 用の知識ベースを UI から作れる。ここで肩代わりされるのは、試作を人に見せるまでの時間である。逆に肩代わりされないのは、検索精度の評価設計や、サーバのスケーリングである。UI が便利だからといって、パイプラインの品質が上がるわけではない。
v1、v2、v3 が並存しているという現実
リリース履歴を見ると、2025 年 1 月の 1.0、同年 8 月の 2.0、2026 年 1 月の 3.0 と、一年で三つの系列が積み上がっている。README は v1 と v2 のコードをそれぞれ別ブランチで参照できると明記しており、過去の実験を再現するにはそのブランチを読む必要がある。3.0 の告知では、ブラックボックス的な開発をやめ、推論ロジックの各行を可視化するという方向が示されている。つまり設計思想自体がこの一年で動いている。新規に始めるなら 3.0 系のドキュメントに合わせるのが素直だが、既存の論文実装を引き継ぐ場合は、どの版の API を前提に書かれているかを最初に確認しないと、後で書き直しになる。
評価とベンチマークの扱い
標準化された評価ワークフローが組み込まれ、主要な研究用ベンチマークがすぐ使える状態で用意されている、と README は説明する。指標の管理とベースラインの統合を統一することで、実験の再現性と比較の効率を上げるという主張である。加えて ModelScope 上に UltraRAG_Benchmark というデータセットが公開されている。ここで注意したいのは、評価の枠組みが用意されていることと、自分の用途で良いパイプラインが組めることは別だという点である。公開ベンチマークで比較しやすい構成は、そのベンチマークの設問形式に最適化されやすい。社内文書の Q&A のように設問形式が違う用途では、同梱の評価をそのまま回しても判断材料にならない。
代替としての DSPy と、設計思想の違い
同じ問題、つまり RAG の配線と実験管理に別の答えを出している道具として DSPy がある。DSPy はパイプラインを Python のモジュールとして書き、プロンプトを人手で書く代わりに、指標を定義してコンパイラに最適化させる方向をとる。制御構造は Python そのものなので表現力に上限がなく、条件式も任意に書ける。代わりに、実験の差分はコードの差分になり、非エンジニアが設定を触ることは難しい。UltraRAG は逆で、制御構造を YAML に寄せて宣言的にし、部品は MCP サーバとして外に出す。設定を触る人の敷居は下がるが、YAML で書けないロジックが出た時点で、どちらの道具も結局はコードを書くことになる。どちらが優れているという話ではなく、設定を誰が触るのかで選ぶべきものである。
Apache-2.0 で配られていることの意味
ライセンスは Apache-2.0 で、リポジトリはアーカイブされていない。商用利用を含めて扱いやすい部類に入るが、リポジトリのライセンスはリポジトリのコードに適用されるもので、同梱あるいは別途取得するモデルやデータセットには別の条件が付きうる。README は AgentCPM-Report を Hugging Face 上で、UltraRAG_Benchmark を ModelScope 上で案内しており、これらは配布元の条件を確認する必要がある。Apache-2.0 は特許条項を含む点で MIT より整理されているが、これは法的助言ではなく、導入時に法務へ確認する論点の指摘である。更新頻度は高く、既定ブランチへの push は 2026 年 9 月に及んでいる。追従コストは、バージョンを固定して使うかどうかで大きく変わる。
編集部の結論
UltraRAG は、RAG の各段を独立した MCP サーバとして切り出し、条件分岐やループを含む制御構造を YAML で書きたい研究チームと、UI から対話デモまで短時間で組み上げたい試作担当者に向く。既存の本番 RAG があり、リランカやクエリ書き換えの挙動をアプリ側のコードで細かく制御しているチームには向かない。導入前に確認すべきは 3 点で、第一に v1、v2、v3 のうちどの系列を読んでいるか、第二に MCP サーバをどのプロセス構成で動かすか、第三に Apache-2.0 の範囲で同梱モデルやデータセットがどう扱われるかである。README の記載だけでは、MCP サーバ間の呼び出しが同一プロセス内で完結するのかネットワーク越しになるのかが判別できない。この一点が、レイテンシ要件の厳しい用途で採用できるかどうかを分ける。
コミュニティノート