Simba を採用する前に見るべき評価機構と構成の実態
OpenSource Production ready Customer service with built in Evals and monitoring
ひと目でわかる
- これは何？
- Simba は RAG ベースのカスタマーサービス支援を TypeScript と Python で自己ホストするプロジェクトで、検索・生成の評価を組み込み、npm ウィジェットでサイトに接続する。評価を後付けにしない設計が最大の特徴だが、マルチテナントや分析はロードマップ上の未実装で、運用前提の判断が必要になる。
- 誰に向いている？
- Simba は、RAG の検索精度と生成品質を自分で測りながら内製したい小規模チームに向く。逆に、複数顧客のデータ分離が要件にある場合や、分析ダッシュボードの完成度を前提にした導入は時期尚早だ。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 90 日前です。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
Simba が埋めようとしている「AI 品質が測れない」問題
カスタマーサービス向けのチャットボットを組むとき、多くのチームが最初にぶつかるのは、回答が良くなったのか悪くなったのかを判定できないという壁だ。README はこの点を問題として明示し、ブラックボックス型のサービスと対比して、評価とカスタマイズを設計の中心に置くと述べている。想定読者は、既製の SaaS チャットボットでは自社データの扱いやモデル選択を制御できないと感じている開発チームである。Simba は TypeScript を主要言語としつつ、Python パッケージ simba-core と npm パッケージ simba-chat-widget を併用する構成を取る。つまり、バックエンドの RAG 処理は Python、フロントエンドとサイト埋め込みは JavaScript という分担になっている。評価を別プロダクトとして後から足すのではなく、リポジトリの一部として持たせるという判断が、このプロジェクトの輪郭を決めている。
FastAPI、Celery、Redis、ベクトルストアというデータの流れ
README に掲載された構成図は、サイトに埋め込んだウィジェットが Simba API に問い合わせ、API がベクトルストアと LLM にアクセスする流れを示している。API は FastAPI で、ベクトルストアは Qdrant または FAISS が図の例として挙がる。文書の取り込みは Celery のワーカーが担当し、そのタスクキューとして Redis が置かれる。取り込み経路が API の応答経路から分離されている点は実務上大きい。PDF やドキュメントのパースとチャンク化、埋め込み生成は時間がかかる処理で、これを同期の HTTP リクエストで回すとチャットの応答が詰まる。Celery と Redis を挟むことで、投入した文書が非同期にベクトルストアへ反映される。裏を返せば、Redis とワーカープロセスの稼働が前提であり、API サーバーだけを立てても取り込みは動かない。構成図から読み取れるのはここまでで、再試行や失敗時の挙動についての記述は README にはない。
Docker と pip という二つの起動経路
起動方法は README で二通り示されている。Docker を使う場合はリポジトリを clone し、.env に OPENAI_API_KEY を書いてから、DEVICE を指定して make を実行する。CPU なら DEVICE=cpu make build && make up、NVIDIA GPU なら DEVICE=cuda make build && make up という形だ。ダッシュボードは http://localhost:3000 で開く。Docker を避ける場合は pip install simba-core の後、simba server と simba front の二つのコマンドを叩く。開発者向けには Claude Code 用の /setup コマンドが用意され、/setup --all で Python、フロントエンド、npm パッケージの依存とインフラサービスをまとめて立ち上げる。--backend、--frontend、--services に分割して実行することもできる。サイトへの組み込みは npm install simba-chat-widget の後、SimbaChat コンポーネントに apiUrl と theme を渡す。apiUrl には自分の Simba インスタンスの URL を指定する。theme は light の例が載るが、他にどの値が有効かは README からは分からない。
差し替え可能なコンポーネントと、その代償
カスタマイズ表では、ベクトルストアに Qdrant、FAISS、Chroma、埋め込みに OpenAI、HuggingFace、Cohere、LLM に OpenAI、Anthropic、ローカルモデル、リランカーに Cohere、ColBERT、クロスエンコーダ、パーサーに Docling、Unstructured、PyMuPDF が挙がる。選択肢を並べること自体は難しくない。難しいのは、どの組み合わせが評価指標の上でどう効くかを切り分ける作業で、Simba はそこを測る枠組みを同じリポジトリに置くことで、差し替えのたびに検索精度や生成品質を比較できるようにしている。ただし README には、これらの選択がどの設定キーで切り替わるのかの記載がない。コンポーネント名の一覧はあっても、設定ファイルの場所やスキーマは示されていない。導入を検討するなら、まずリポジトリ内の設定ファイルを読んで、切り替えが環境変数なのか設定ファイルなのかを確認する必要がある。ここは README だけでは判断できない部分だ。
評価指標が示すもの、示さないもの
Simba が追跡するとされる指標は三つに分かれる。検索側は precision、recall、relevance score。生成側は faithfulness、answer relevancy、latency。会話側はユーザー満足度と解決率である。検索と生成を分けて測る設計は理にかなっている。回答が外れたときに、文書が見つからなかったのか、見つかった文書を LLM が正しく使えなかったのかで、直す場所が違うからだ。ただし README は指標の名前を列挙するにとどまり、各指標の計算方法や、評価用データセットをどう用意するかには触れていない。ユーザー満足度や解決率についても、どのように収集するのかの説明はない。評価フレームワークが「ある」ことと、それが自分のユースケースで意味のある数値を出すことは別問題である。導入判断の前に、評価用の質問と正解の組をどう与えるのかをドキュメントで確認したい。
向かないケース: マルチテナントと分析の現在地
roadmap を見ると、core evaluation framework、npm chat widget、streaming responses にはチェックが付いている。一方、multi-tenant support、advanced analytics dashboard、webhook integrations、fine-tuning pipeline は未チェックだ。これは重要である。複数の顧客企業のデータを一つのインスタンスで扱い、テナントごとに文書と会話を分離する必要がある製品を考えているなら、この機能はまだ実装されていない。advanced analytics dashboard も同様で、README が挙げる会話分析の指標がどの程度ダッシュボード上で可視化されるのかは、現時点の記述からは確定できない。単一組織のサポート窓口に導入するのか、複数テナントの SaaS に組み込むのかで、このプロジェクトの適合度は大きく変わる。後者を前提にするなら、roadmap のチェックが付くまで待つか、分離の仕組みを自分で実装する覚悟が要る。
比較対象としての Dify と、設計思想の違い
自己ホスト型で RAG チャットボットを組む選択肢としては Dify が挙がる。Dify はワークフローとエージェントのオーケストレーションをノーコードの画面から組み立てる方向に重心があり、プロンプトやノードの構成を GUI で管理する。Simba は逆で、パイプラインの各段をコードと設定で持ち、その上に評価を載せる。どちらが優れているかではなく、変更を加える場所が違う。Dify では画面の操作が成果物になるため、変更履歴やレビューの流れが GUI の外に出にくい。Simba では埋め込みモデルやリランカーの差し替えがコード側の作業になり、差分として追える。評価指標を CI に組み込みたい、モデルを定期的に乗り換えて数値を比較したいという要求があるなら、Simba の構成のほうが素直に噛み合う。逆に、非エンジニアがプロンプトを調整する運用を想定するなら Dify の画面のほうが現実的だ。
ライセンスと保守の見取り図
ライセンスは Apache-2.0 で、リポジトリの LICENSE ファイルに基づく。商用利用や改変、再配布を許容する寛容なライセンスだが、これは法的助言ではないので、自社製品への組み込み方は必要に応じて法務に確認してほしい。保守の観点では、直近のリリースが v0.4.0 で 2025-03-11、その前が v0.3.0 で 2025-03-07、v0.2.0 が 2025-03-06 と、短期間に版が並んでいる。0.x 系である以上、設定や API の互換性が今後も保たれるとは限らない。Python パッケージ simba-core と npm パッケージ simba-chat-widget という二つの配布物があり、アップグレード時は両方の版を揃える必要がある。Docker で動かす場合も DEVICE の指定とイメージの再ビルドが絡むため、更新手順を自分の環境で一度通しておくほうがよい。ドキュメントは simba.mintlify.app に置かれている。
編集部の結論
Simba は、RAG の検索精度と生成品質を自分で測りながら内製したい小規模チームに向く。逆に、複数顧客のデータ分離が要件にある場合や、分析ダッシュボードの完成度を前提にした導入は時期尚早だ。着手前に確認すべきは roadmap で未チェックの multi-tenant と advanced analytics の実装状況、そして .env に置く OPENAI_API_KEY 以外のモデル切り替えが設定ファイルのどこで行われるかである。
コミュニティノート