DeepBI を導入前に読む: LLM が SQL を書く BI の構成と制約
LLM based data scientist, AI native data application. AI-driven infinite thinking redefines BI.
ひと目でわかる
- これは何？
- DeepBI は対話から永続クエリと可視化を生成する AI ネイティブ BI です。Docker 構成と対応データソースは明確ですが、Python 3.8 系と PostgreSQL 16 への依存、自動レポートが未実装である点は導入判断の前に確認が必要です。
- 誰に向いている？
- 向いているのは、MySQL や PostgreSQL、Doris、StarRocks に既にデータがあり、SQL を書かないメンバーへ分析結果を届けたい小規模チームです。Docker と docker-compose が使える環境なら Install.sh で立ち上げられ、Windows は window_install_exe_EN.zip の exe という選択肢もあります。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 19 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
対話から永続クエリを作るという設計
DeepBI が解こうとしているのは、SQL を書けない人がデータを持っている人を待たずに答えを得る、という問題です。README は機能の第一に「Conversational data analysis」を挙げ、対話を通じて任意のデータ結果と分析結果が得られると説明しています。二番目は「Conversational query generation」で、ここが単なるチャット型の集計ツールとの分かれ目です。生成されるのは一度きりの回答ではなく、永続クエリと可視化です。つまり会話の結果が保存され、後から同じ定義を再利用できる形になります。三番目の Dashboard は、その永続化された可視化を組み合わせて作るものです。
対象読者は BI 専任者を置けないチームです。データは MySQL や PostgreSQL にあるが、集計のたびにエンジニアへ依頼する状態を減らしたい、という動機が想定されています。README が対応データソースとして MySQL、PostgreSQL、CSV/Excel インポート、Doris、StarRocks、MongoDB を列挙している点からも、既存の分析基盤を置き換えるのではなく、その上に会話用の入口を足す使い方が自然です。
8338 と 8339 の二ポート構成、Docker と Ubuntu の二経路
導入経路は三つ示されています。Windows は window_install_exe_EN.zip を配布ページから取得し、解凍して exe を実行します。README は Win10 と Win11 で動作を確認したと記載しています。Docker 経路は docker と docker-compose が前提で、git clone のあとプロジェクトディレクトリへ移動し、./Install.sh を実行します。既定ポートは 8338 と 8339、Web のアクセス先は http://ip:8338 です。起動後は docker-compose start、停止は docker-compose stop、状態確認は docker-compose ps を使います。PermissionError や Permission denied が出る場合は各コマンドの前に sudo を付ける、という指示も明記されています。
Ubuntu へ直接入れる場合は、redis、postgresql、python3.8.17 を自分で用意します。Redis は 127.0.0.1 からパスワードなしでコマンドライン接続できる状態、Python は 3.8.x、PostgreSQL は 16 系が必要と書かれています。仮想環境は pyenv や conda の利用が推奨されています。実行コマンドは . ubuntu_install.sh で、sh ではなくドットで読み込む形に意味があります。スクリプト内で Python の仮想環境を有効化するため、と README が理由を説明しています。ポート番号は Docker 経路と同じ 8338 と 8339 です。
ここで実務上の注意点が二つあります。一つはポートが二つあることです。8338 だけを開けて 8339 を閉じると、Web 画面は出ても一部の通信が通らない可能性があります。もう一つは Python 3.8 系という指定です。3.8 は既にサポートが終了した系列であり、他のアプリケーションと同じホストへ同居させる場合は、バージョン衝突をどう避けるかを先に決める必要があります。README は pyenv や conda を推奨しているので、OS の Python をそのまま使う前提ではないと読めます。
動作環境として README が明示している範囲
検証済みとして README が挙げているのは Mac OS 12.7、13.X、14.1.1、Ubuntu 20.04 と 22.04、Windows11 の WSL 22.04 です。Windows 10 で WSL を使う場合は 22H2 以上が必要と記載されています。サーバーの最低要件は 1 コア 2GB メモリ、推奨は 2 コア 4GB です。
この数字は控えめに見えますが、DeepBI 自身のプロセスだけを指している可能性があります。同じホストで PostgreSQL 16 と Redis を動かす構成なら、それらの分を上乗せして考えるべきです。README にはデータ量やクエリ同時実行数に応じた目安の記載がないため、本番のデータ規模で足りるかは自組織のデータで確かめる以外にありません。
もう一点、対応データソースの一覧には MongoDB が含まれていますが、機能説明の文脈では MySQL、PostgreSQL、Doris、StarRocks、CSV/Excel が中心に扱われています。MongoDB 固有の制約やクエリ生成の対応範囲についての記述は見当たりません。ドキュメントの薄さはここに表れています。
自動レポートはまだ実装されていない
README の機能一覧の四番目は「Automated data analysis reports (to be developed)」です。開発予定と明記されている以上、現時点で完成した機能として数えることはできません。
この一点は導入判断に効きます。DeepBI の説明を読むと、対話から分析が完結する印象を受けますが、実際に提供されているのは対話による分析、永続クエリと可視化の生成、それらを並べるダッシュボードまでです。定期的にレポートを生成して配布する、という運用を期待しているなら、その部分は自前で組むか、別のツールと組み合わせる必要があります。
また、README の機能一覧には「to be developed」以外にロードマップの記載がありません。次のリリースで何が入るかを事前に読むことはできないため、自動レポートを待って導入を決める進め方は取りにくいと言えます。
Superset との違いはクエリを誰が書くか
比較対象として分かりやすいのは Apache Superset です。Superset はデータセットとメトリクスを人間が定義し、その定義に沿ってダッシュボードを組み立てます。定義は事前に固まっている必要があり、新しい切り口が必要になったら誰かがメトリクスを追加します。
DeepBI はこの順序を逆にします。会話からクエリと可視化を生成し、それを永続化してダッシュボードへ積む、という流れです。探索の入口が会話になり、定義は後から残る形になります。
この差は、向く状況をはっきり分けます。指標の定義が統制されていて、全社で同じ数字を見ることが優先される組織では、Superset のほうが適しています。逆に、定義が固まっていない問いを何度も投げる段階や、分析の依頼が特定の担当者に集中している組織では、DeepBI のアプローチが噛み合います。
ただし、生成されたクエリがそのまま永続化される設計は、誤った解釈のクエリがダッシュボードに残り続けるリスクと表裏です。誰が生成物を確認して公開するのか、という運用を決めずに導入すると、後から数字の出所を追えなくなります。README にはこの承認フローに関する記述がないため、そこは導入側の設計課題です。
MIT ライセンスと保守コストの見積もり
ライセンスは MIT です。商用利用を含めて扱いやすい条件ですが、無保証である点は変わりません。README にはサポート窓口として dev@deepbi.com が記載され、問い合わせ先として GitHub の Issue が示されています。
リリース履歴は v2.0.2 が 2024-06-14、v2.0.3 が 2024-06-21、v2.0.4 が 2024-10-08 です。この並びからは、四か月ほどで次の版が出ていることが読み取れます。ただしタグの表記は V2.0.2 と v2.0.2 が混在しており、リリース名の運用が統一されていません。自動化された更新確認を組む場合は、この表記ゆれを前提にしたほうが安全です。
アップグレードの手順そのものは README に記載がありません。Docker 構成なら docker-compose stop の後にファイルを更新して docker-compose start という流れが想像できますが、これは README に書かれた事実ではなく推測です。データベースのマイグレーションがどう扱われるかも記述がありません。運用に乗せる前に、自分の環境で一度アップグレードを試しておく価値があります。
Docker 構成ならホスト側の依存は docker と docker-compose だけなので、Python 3.8 系の維持という負担はイメージの中に閉じます。Ubuntu へ直接入れる構成を選ぶと、この負担がホストの運用に直接乗ります。どちらの経路を選ぶかは、保守コストの見積もりを大きく変えます。
なお、LLM 呼び出しにかかる費用、外部 API へ送信されるデータの範囲、データがどのように保持されるかについては、README に対応する記述がありません。社外へ出せないデータを扱う場合は、導入前にコードと設定を読んで確認する必要があります。これは推測で埋めてよい種類の情報ではありません。
導入するかどうかの分岐点
向いているのは、MySQL や PostgreSQL、Doris、StarRocks にデータが既にあり、SQL を書かないメンバーへ分析結果を届けたい小規模チームです。Docker と docker-compose が使えるなら ./Install.sh で立ち上げられ、Windows なら exe という選択肢もあります。多言語対応として中国語と英語が挙げられているため、日本語の UI を期待する場合は別途確認が要ります。
向かないのは三つの場合です。自動レポート生成を前提にした計画、Python 3.8 系以外で運用したい構成、MongoDB を主要データソースに据える設計です。いずれも README の記述と噛み合いません。
導入前に確認すべきことは具体的に決まっています。Ubuntu の手動構成を選ぶなら、PostgreSQL 16 と Python 3.8.x、パスワードなしで 127.0.0.1 に接続できる Redis を用意できるか。Docker 構成を選ぶなら、8338 と 8339 の両方を開けられるか。そして、LLM 呼び出しのコストとデータの送信範囲が自組織の要件に収まるか。この三点が埋まらないうちは、本番データを接続しないほうが安全です。
編集部の結論
向いているのは、MySQL や PostgreSQL、Doris、StarRocks に既にデータがあり、SQL を書かないメンバーへ分析結果を届けたい小規模チームです。Docker と docker-compose が使える環境なら Install.sh で立ち上げられ、Windows は window_install_exe_EN.zip の exe という選択肢もあります。逆に、自動レポート生成を前提にした計画、Python 3.13 など 3.8 系以外で運用したい構成、MongoDB を主要データソースに据える設計には向きません。最初に確認すべきは、Ubuntu 手動構成の場合は PostgreSQL 16 と Python 3.8.x を用意できるか、Docker 構成の場合は 8338 番と 8339 番のポートを開けられるかです。加えて、LLM 呼び出しのコストと外部送信の範囲はリポジトリの記述からは判断できないため、自組織のデータで試す前にそこを埋める必要があります。
コミュニティノート