LLMを活用したシステムを構築する際, 「どのツールがユーザーの入力を処理すべきか」「社内ドキュメントにどうアクセスさせるか」という設計上の問いは避けられない.本稿では, それぞれ異なるレイヤーで機能する3つのツール, Aurelio AIのSemantic Router, 旧DanswerからリブランドされたOSSエンタープライズ検索基盤Onyx, AWSのマネージド検索サービスAmazon Kendra を技術的観点から比較する.
これら3つは競合関係というより, パイプラインの異なるレイヤーを担うコンポーネントであり, 組み合わせて使うことも十分現実的だ.
Semantic Router[Aurelio AI]
概要
Semantic Routerは, LLMエージェントにおける意図分類・振り分けレイヤーを担うPythonライブラリだ.ユーザー入力のベクトル表現と, 事前定義された「ルート」のベクトルとのコサイン類似度を計算し, どのハンドラ[LLM, ツール, 関数など]に処理を渡すかを高速に決定する.
アーキテクチャの特徴
従来のアプローチでは, ルーティング判断そのものにLLMを呼び出すケースが多い.Semantic RouterはこれをLLMを使わずにベクトル類似度のみで解決する.これにより,
- レイテンシが数千msから約100ms以下に短縮
- LLM APIコストのルーティング分が完全に不要
- 決定論的な挙動が保証しやすい[同じ入力 → 同じルート]
エンベディングモデルは差し替え可能で, OpenAI・Cohere・ローカルモデル[sentence-transformers等]に対応している.ルートの定義は RouteLayer にサンプル発話を登録する形で行う.
注意点
- 検索機能を持たない.ドキュメント検索やRAGはスコープ外.
- ルート定義のサンプル数が少ないと誤分類が起きやすい[各ルートに10件以上のutterance推奨]
- ベクトルストアのバックエンド[Pinecone・Redis等]を別途用意すれば分散デプロイも可能
Onyx[旧Danswer]
概要
OnyxはOSSのエンタープライズRAG基盤で, 「社員が自然言語で社内情報を検索・質問できる」プラットフォームを自社インフラ上に構築することを主目的としている.Netflix・Ramp等の企業での採用実績があり, DockerあるいはKubernetes上にセルフホストできる.
検索パイプラインの構成
Onyxの検索は単純なベクトル検索ではなく, 以下の要素を組み合わせたハイブリッド構成をとる.
- ベクトル検索[セマンティック類似度]
- BM25ベースのキーワード検索[完全一致・固有名詞に強い]
- ナレッジグラフ[エンティティ間の関係性を考慮]
- LLMによる回答生成[検索結果を文脈としてRAG]
この多段構成により, 「製品名のスペルミスでもヒットする」「概念的な質問にも答えられる」という実用的な精度を実現している.
コネクタと権限制御
40以上のデータソースへのコネクタが標準搭載されており, 代表的なものとして, Slack, GitHub, Google Drive, Confluence, Jira, Notion, Salesforce, Web crawler等がある.
権限制御はドキュメントレベルのACLまで対応しており, 元のデータソースの権限をOnyxが継承する設計になっている.具体的には, ユーザーがGoogle Driveで閲覧権限を持つドキュメントのみが検索結果に表示される.SSO[OIDC/SAML]やRBACもサポートする.
デプロイ構成
- 開発・小規模向け：docker-compose up
- 本番向け：helm install onyx # Kubernetes + Helm
コアとなるコンポーネントは, APIサーバー・バックグラウンドインデクサー・ベクトルDB[Vespa]・リレーショナルDB[PostgreSQL]・キャッシュ[Redis]で構成される.
Amazon Kendra
概要
KendraはAWSが提供するフルマネージドの企業向け検索サービスで, NLPによる意味理解検索とRAG機能を持つ.インフラ管理が不要な反面, AWSエコシステムへの依存度が高い.
技術的な特徴
Kendraの内部はディープラーニングベースのランキングモデルで, 従来のキーワード検索に比べて自然言語クエリへの対応精度が高い.ベクトルインデックスはユーザーに直接公開されていない設計で, 開発者はRetriever APIを通じてパッセージレベルの関連文書を取得する.
AWSサービスとの統合が最大の強みで, 以下との連携がネイティブに機能する.
- Amazon Bedrock Knowledge Bases：RAGパイプラインの検索バックエンドとして
- Amazon Q Business：エンタープライズAIアシスタントのリトリーバーとして
- IAM：ユーザーコンテキストに基づくフィルタリング
まとめ
AWS環境ならOnyxをKendraに, 非AWS環境やコスト重視ならOnyxをセルフホストする形が標準的な選択になるだろう.
Semantic RouterはLLMパイプラインの入口に置く意図分類・ルーティングレイヤーとして, 低レイテンシかつコスト効率よく機能する.RAGや検索とは別の問題を解くツール.
OnyxはエンタープライズRAG基盤として完成度が高く, セルフホストによるデータ主権の維持とコスト効率を両立できる.40以上のコネクタと文書レベルのACL[Access Control List]は実運用に耐える設計.
KendraはAWSネイティブ環境での運用負荷ゼロというメリットが際立つが, コストとベンダーロックインという代償を伴う.Bedrock / Q Businessとの深い統合を活かせる場面での採用が最も合理的.
| 観点 | Semantic Router | Onyx | Kendra |
|---|---|---|---|
| 主な役割 | ルーティング・意図分類 | 社内検索・RAG基盤 | マネージド検索・RAG |
| レイテンシ | ~100ms | 数秒 | 数秒 |
| インフラ管理 | 不要[ライブラリ] | 要[Docker/K8s] | 不要[マネージド] |
| カスタマイズ性 | 高 | 高 | 低〜中 |
| OSSか否か | MIT | MIT[コア] | クローズド |
| コスト感 | 低[エンベディングのみ] | 低〜中 | 高 |
| ベンダーロックイン | なし | なし | AWS |
2026-03-22.