モデル / データセット
EmbeddedLLM/JamAIBase avatar
EmbeddedLLM/JamAIBase

JamAI Base:スプレッドシートUIでRAGバックエンドを組むOSS、その実像と採用判断

The collaborative spreadsheet for AI. Chain cells into powerful pipelines, experiment with prompts and models, and evaluate LLM responses in real-time. Work together seamlessly to build and iterate on AI applications.

スター 1,103フォーク 47PythonApache-2.0

ひと目でわかる

これは何?
JamAI BaseはSQLiteとLanceDBを内蔵し、LLM・埋め込み・リランカーをスプレッドシート風UIとREST APIから扱うRAGバックエンドだ。宣言的な表設計と引き換えに、何を自分で管理し、何を手放すのかを整理する。
誰に向いている?
向くのは、RAGやLLMワークフローの試作を、パイプラインを一から書かずに表の定義で回したいチームだ。特に、社内文書をKnowledge Tableに置き、Chat Tableから参照させる構成を短時間で立ち上げたい場合に噛み合う。
商用利用できる?
できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
今もメンテナンスされている?
されています。最後のコミットは 13 日前です。
何の言語で書かれている?
主に Python です(GitHub の言語統計による)。

回答はプロジェクトの GitHub データ(最終同期:2026年9月15日)と当サイトの分析に基づくもので、法的助言ではありません。

オープンソース詳細解説

JamAI Baseが埋めようとしている溝

RAGを組むとき、多くのチームは同じ作業を繰り返す。文書の取り込み、チャンク分割、埋め込み生成、ベクトルDBへの投入、検索、リランク、プロンプト組み立て、そしてLLM呼び出し。この配管はどのプロジェクトでも似ているのに、毎回書き直される。JamAI Baseはこの配管を製品の側に寄せ、利用者には表の定義だけを残そうとする。READMEの冒頭では、SQLiteとLanceDBを内蔵し、LLM・ベクトル埋め込み・リランカーのオーケストレーションを管理するRAGバックエンドだと説明されている。対象は、Pythonでパイプラインを書けるが書きたくない開発者、あるいはノーコード寄りの操作でLLMアプリの挙動を確かめたいプロダクト側の人間だ。スプレッドシート風UIとREST APIという2つの入口を用意している点が、この想定利用者を裏づけている。

4種類のテーブルが処理の単位になる

JamAI Baseの中心は、行と列ではなくテーブルの種類分けにある。Generative Tableは列をLLMの出力で埋める。READMEはこれを、静的なデータベース表を動的なAIエンティティに変えるものと表現し、RESTエンドポイントが付くと説明する。Action TableはアプリのフロントエンドとLLMバックエンドの間のリアルタイムなやり取りを担い、ユーザー入出力のバックエンド管理を不要にするとされる。Knowledge Tableは文書と構造化データの置き場で、他の生成テーブルに文脈を供給する。Chat Tableはチャットボットの作成と運用を簡略化し、任意のKnowledge Tableの内容をRAG経由で参照できる。つまり、取り込み先、生成の実行単位、対話の窓口が別々のテーブル種別として分かれている。この分離は、パイプラインを1本のコードとして書く場合とは発想が違う。処理の順序をコードで綴るのではなく、どの表がどの表を参照するかという関係として宣言する。READMEがDeclarative Paradigmと呼んでいるのはこの点で、howではなくwhatを定義させるという説明がそれにあたる。

RAGの中身はどこまで見えているか

RAGの品質は前処理と検索で決まる部分が大きい。JamAI Baseはここにいくつかの既定動作を用意している。READMEが挙げるのは、クエリ書き換え、ハイブリッド検索とリランキング、適応的チャンキング、そしてBGE M3-Embeddingの利用だ。ハイブリッド検索はキーワード検索、構造化検索、ベクトル検索を組み合わせるという説明になっている。チャンキングは「最適な方法を自動的に決める」と書かれている。ここは評価が分かれる。既定が用意されているぶん初期の立ち上げは速いが、逆に言えば分割粒度も検索の重みも、少なくともREADMEからは調整点として提示されていない。埋め込みモデルにBGE M3を使う構成が前提に置かれているため、別の埋め込みに差し替えたい場合や、既存のベクトル基盤と同じモデルで揃えたい場合に、どこまで自由度があるかはREADMEからは判断できない。この層を自分で握りたいチームにとっては、抽象化がそのまま制約になる。

動かすまでの入口は2つある

READMEが示す導入経路は明快に2つだ。1つはJamAI Base Cloudのアカウントを作る方法で、無料のLLMトークンが付くと書かれている。もう1つはセルフホストで、docs.jamaibase.comのPython SDKドキュメント内にあるOSSの手順に従う形になっている。リポジトリの主要言語はPython、ライセンスはApache-2.0、デフォルトブランチはmainだ。注目したいのは、READMEにインストールコマンドや環境変数の一覧が載っていないことだ。pip installの行もdocker composeの行もなく、手順はすべて外部ドキュメントへのリンクに委ねられている。この記事の材料の範囲では、具体的な設定キーや起動コマンドを引用できない。セルフホストを検討するなら、まずリンク先の手順を開き、そこで示される起動方法と必要な設定を確認するのが最初の作業になる。UIとREST APIという2つの入口がある以上、どちらを主に使うかで確認すべき項目も変わる。

内蔵DBという選択がもたらす制約

SQLiteとLanceDBを内蔵する設計は、単一プロセスで完結する手軽さと引き換えに、いくつかの境界を引く。SQLiteは書き込みの並行性に制約があり、LanceDBもリポジトリのトピックに挙がっているとおりファイルベースのベクトルDBだ。READMEは「サーバーレス設計が最適な性能とスケーラビリティを保証する」と書くが、これは主張であって、検証可能な数値は材料の中にない。大規模なマルチテナントや、書き込みが集中するワークロードを想定するなら、内蔵DBのままで足りるかを自分の負荷で確かめる必要がある。もう1つの論点はデータの所在だ。埋め込みと元文書がLanceDBのファイルに入るなら、そのファイルの置き場所、バックアップ、再インデックスの手順は運用設計に含めなければならない。ここはREADMEが触れていない領域で、採用可否を左右するのに記述が薄い。

LangChainやDifyと何が違うのか

比較対象として分かりやすいのはLangChainだ。LangChainはライブラリで、検索器、分割器、リランカーを部品として提供し、それらをどう繋ぐかは利用者のコードが決める。JamAI Baseは逆で、繋ぎ方のほうを製品が持ち、利用者には表の定義を渡す。同じRAGでも、LangChainは組み立ての自由度を、JamAI Baseは組み立ての省略を売っている。Difyのようなノーコード寄りのLLMアプリ基盤とも方向は近いが、JamAI Baseはスプレッドシートという既存の操作感に寄せ、さらにREST APIを前面に出している点が違う。APIが主であれば、フロントエンドは自前のアプリで、ロジックだけJamAI Baseに置くという構成が取れる。判断の軸は機能の多寡ではなく、検索やチャンキングの制御をコードで持ちたいか、定義に委ねたいかだ。前者ならLangChain系、後者ならJamAI Baseが候補になる。

更新頻度とライセンスの扱い

リポジトリの情報では、直近のリリースはv0.4(2025-02-14)で、その前がv0.3.1(2024-11-26)、v0.3(2024-11-20)と続く。v0.3系からv0.4までが約3か月、それ以前はマイナー版が短期間に並んでいる。アーカイブはされておらず、最終pushは2026-09-03付と記録されている。バージョン番号が0系であること、そしてREADMEにv1からv2への移行ガイドへの参照があることは、APIやデータ構造が動いてきた履歴を示す。追従コストを見積もるなら、CHANGELOG.mdとVERSIONING.mdを先に読み、自分の構成が移行対象に触れるかを確認するのが早い。ライセンスはApache-2.0で、これは寛容型として知られるが、同ライセンスの条文が自社の改変や再配布にどう及ぶかは個別の判断が必要で、ここで法的な助言はできない。

編集部の結論

向くのは、RAGやLLMワークフローの試作を、パイプラインを一から書かずに表の定義で回したいチームだ。特に、社内文書をKnowledge Tableに置き、Chat Tableから参照させる構成を短時間で立ち上げたい場合に噛み合う。逆に、検索のチャンク戦略やリランカーの重みを細かく制御したい、あるいは既存のDWHやベクトル基盤に処理を寄せたいチームには、抽象化が邪魔になる。採用前に確認すべきは、まずself-host手順が自分の環境で通るか、次にLanceDBのインデックスとSQLiteのファイルがどこに置かれ、バックアップとバージョンアップでどう扱われるか、最後にv1からv2の移行ガイドの対象が自分の構成に当たるかだ。

公式情報源

  1. EmbeddedLLM/JamAIBase on GitHub
  2. License: Apache-2.0
  3. Project website
  4. README
  5. Releases
コミュニティノート

コミュニティノート