SQLBot を採用する前に読む: RAG ベース Text-to-SQL の構成とライセンス境界

SQLBot が埋めるのは「SQL を書けない人の最後の一段」

BI ツールは既に多くの組織に入っている。だが、集計軸をひとつ変えたいだけの問い合わせでも、ダッシュボードの編集権限を持つ担当者を待つか、SQL を書ける同僚に依頼するしかない場面は残る。SQLBot はこの待ち時間を削ることを狙ったシステムで、README では「会話式数据分析（ChatBI）」という位置づけが示されている。利用者は自然言語で質問し、システムが SQL を生成して実行し、結果を表やグラフとして返す。対象読者はデータアナリストではなく、業務部門の担当者や、ちょっとした数値を自分で引きたい開発者である。DataEase を手がけるプロジェクトチームによる公開であり、同社の他のプロダクト群と同じ配布チャネルが用意されている点も、導入経路としては分かりやすい。

RAG が効くのはスキーマ理解の部分で、SQL 生成そのものではない

README の「工作原理」節には構成図が1枚置かれているだけで、テキストによる詳細な説明はない。したがって以下の理解は、README の記述とリポジトリ構成から読み取れる範囲にとどまる。SQLBot は大規模言語モデルにテーブル定義やカラム情報、業務用語とカラムの対応といった参照情報を检索させ、その結果をプロンプトに載せたうえで SQL を生成させる。つまり RAG はモデルに「このデータベースには何があり、何と呼ばれているか」を教える役割を担い、生成そのものは LLM の能力に依存する。この分離は重要で、スキーマ情報が貧弱なデータベースでは RAG が参照できる材料がなく、生成精度はモデルの推測に落ちる。逆に、カラム名が業務用語と一致していたり、SQL の例文を整備しておいたりすれば、同じモデルでも結果は変わる。README が「越问越准」の根拠として挙げているのが、カスタムプロンプト、用語集、SQL 例による補正であり、これはまさに RAG 側の材料整備の話である。モデルを差し替えるより先に、この参照データを整えるほうが効く設計だと言える。

Docker 起動と、8000 と 8001 の役割分担

導入手順は README にそのまま載っている。Linux サーバに Docker を用意し、次のコマンドを実行する。

docker run -d \ --name sqlbot \ --restart unless-stopped \ -p 8000:8000 \ -p 8001:8001 \ -v ./data/sqlbot/excel:/opt/sqlbot/data/excel \ -v ./data/sqlbot/file:/opt/sqlbot/data/file \ -v ./data/sqlbot/images:/opt/sqlbot/images \ -v ./data/sqlbot/logs:/opt/sqlbot/app/logs \ -v ./data/postgresql:/var/lib/postgresql/data \ --privileged=true \ dataease/sqlbot

注目すべきはボリュームの構成である。Excel ファイル、アップロードファイル、画像、アプリケーションログ、そして PostgreSQL のデータディレクトリがそれぞれ別のホストパスにマウントされる。最後の /var/lib/postgresql/data は、コンテナ内部に PostgreSQL が同梱されており、その実データがホスト側に永続化されることを意味する。つまり SQLBot はアプリケーションサーバとデータベースを1コンテナにまとめた構成で、外部 DB を必須としない。手軽さの代償として、この PostgreSQL のバックアップやチューニングは利用者の責任範囲になる。--privileged=true が付いている点も見落とせない。特権モードはコンテナに強い権限を与えるため、信頼できないネットワークに直接露出させる構成には向かない。

起動後はブラウザで http://<サーバIP>:8000/ を開き、ユーザー名 admin、パスワード SQLBot@123456 でログインする。この初期資格情報は README に明記されている以上、外部から到達可能な場所に置くなら最初に変更する前提で考えるべきである。8001 が何に使われるかは README に説明がない。ポートが2つ公開されているという事実だけが材料で、役割は不明としか言えない。1Panel アプリストア経由の配布、および内網環境向けのオフラインインストールパッケージも用意されている。

LLM プロバイダは OpenAI 互換 API に寄せてある

README の対応表には12の選択肢が並ぶ。阿里云百炼、千帆大模型、DeepSeek、腾讯混元、讯飞星火、Gemini、Kimi、腾讯云、火山引擎、MiniMax は OpenAI 互換 API として接続し、OpenAI のみネイティブ、そして「通用 OpenAI 互換」として任意のエンドポイントを指定できる。この設計の意味は明確で、独自 SDK を各社ごとに実装するのではなく、OpenAI 互換のリクエスト形式に統一することでプロバイダ間の切り替えコストを下げている。自社でモデルをホストしている場合でも、OpenAI 互換のゲートウェイを立てれば接続できる可能性がある。ただし README はパラメータ名や設定画面の項目までは示していないため、実際にどの設定キーでエンドポイントと API キーを渡すのかは、デプロイ後に管理画面を確認する必要がある。ここは文書化が薄い部分で、導入前に UI を一度触って確認しておきたい箇所である。

権限分離と RAG の材料整備という2つの運用コスト

README は「安全可控」の根拠として、ワークスペース単位のリソース分離と、細粒度のデータ権限設定を挙げている。組織や部門ごとに見せるデータの範囲を分けられるという主張である。ただし README には権限モデルの詳細、たとえばロールの種類や行レベルフィルタの有無までは書かれていない。アクセス制御を導入判断の主要因にするなら、管理画面で実際に確認するまでは確定情報として扱えない。

もうひとつの運用コストは RAG 側の材料整備である。用語集を書き、SQL の例を登録し、プロンプトを調整する作業は、導入時に一度やれば終わるものではない。データベースのスキーマが変われば参照情報も更新が要る。README は「基于用户交互数据持续迭代优化」と述べているが、この反復を誰が回すのかは組織側の設計問題である。放置すれば、生成される SQL は初期状態の精度のまま固定される。

DataEase と SQLBot は競合しない、責務が違う

同じプロジェクトチームが提供する DataEase は「人人可用的开源 BI 工具」と説明される。こちらはダッシュボードやレポートを定義して共有する、いわゆる従来型の BI である。SQLBot はその上で、定義済みのレポートではなく、その場の質問に SQL を生成して答える。比較するなら、固定された指標を継続的に監視する用途は DataEase、一度きりの切り口や探索的な問い合わせは SQLBot、という住み分けになる。実際 README には SQLBot を DataEase に組み込む連携が挙げられており、置き換えではなく併用が想定されている。

別の方向の代替は、汎用の LLM にスキーマ定義を貼り付けて SQL を書かせる運用である。こちらのほうが導入は速い。だが、接続先データベースの管理、ワークスペース単位の権限、用語集や SQL 例の蓄積、Web 埋め込みや MCP 経由の呼び出しといった周辺は自前で作ることになる。SQLBot の価値は生成精度そのものより、この運用まわりの枠組みをまとめて持っている点にある。

ライセンスは GPLv3 そのものではない

リポジトリのライセンス表記は NOASSERTION で、README は FIT2CLOUD Open Source License と説明している。README の記述によれば、このライセンスは本質的に GPLv3 だが追加の制限があり、SQLBot のロゴと著作権情報を置換・改変してはならず、二次開発した派生作品は GPLv3 のオープンソース義務を負う。

この2点は組み合わせると効いてくる。ロゴを自社ブランドに差し替えて顧客に納品する、というタイプの組み込み方は、たとえソースを公開したとしても最初の条件で止まる。SI 案件や OEM 提供を想定している場合、この条項が契約形態に影響する可能性がある。GPLv3 の義務範囲がどこまで及ぶかは個別の利用形態に依存するため、法務判断はここでは扱わない。ライセンス全文はリポジトリの LICENSE ファイルに当たるべきで、README の要約だけを根拠にしないほうがよい。

更新頻度と、同梱 PostgreSQL という運用の重り

リリースは v1.9.0（2026-06-09）、v1.10.0（2026-07-16）、v1.10.1（2026-08-27）と、およそ1か月から2か月の間隔で続いている。活発に動いているリポジトリである一方、このペースはアップグレード作業が定期的に発生することを意味する。Docker イメージを差し替えるだけに見えても、同梱 PostgreSQL のデータディレクトリをホスト側ボリュームに置いている以上、メジャー更新のたびにスキーマ変更の有無を確認する必要がある。

ここがこの製品の一番の重りである。アプリケーションとデータベースが同じコンテナに同居しているため、DB のバックアップ、バージョンアップ、性能調整は SQLBot のリリースサイクルに引きずられる。本番の分析基盤として使うなら、同梱 PostgreSQL をそのまま使い続けるのか、外部のデータベースに逃がせるのかを先に確かめたい。README の起動コマンドは前者を前提とした形にしか見えない。PoC や部門単位の小規模利用ならこの構成は利点だが、全社の問い合わせ窓口にするなら、データの保全と復旧の手順をこの構成に合わせて設計する必要がある。

編集部の結論

既存の BI ダッシュボードで固定レポートを運用しており、その上に「自然言語で聞く」入口を足したいチームに向く。逆に、SQL の正しさを監査ログ付きで保証したい、あるいはロゴや著作権表示を差し替えて自社製品に組み込みたい場合は適さない。最初に確認すべきは、同梱の PostgreSQL を本番運用に使うのか外部 DB に切り替えるのか、そして対象データソースのスキーマ情報が RAG の参照材料として十分な粒度で整っているかである。

公式情報源

1. dataease/SQLBot on GitHub
2. Issues
3. Project website
4. README
5. Releases