Dataherald は、エンタープライズ レベルの自然言語から SQL AI への変換エンジンであり、技術者以外のユーザーでも、SQL ステートメントを作成せずに会話を通じてデータベースに直接クエリを実行できます。

データヘラルド

Dataherald のコアパラメータと統計

Dataherald は、エンタープライズレベルの自然言語から SQL への変換エンジンとして正式に位置づけられています。その中心的な価値は、データ チームが SQL ステートメントを作成することなく、技術者以外のユーザーが日常の会話を通じてリレーショナル データベースに直接クエリできるようにすることです。従来の BI ツールとの根本的な違いは、事前に設定されたダッシュボードや固定レポート テンプレートに依存せず、ユーザーの意図をリアルタイムで分析してクエリ ステートメントを動的に生成し、要件を段階的に絞り込むための複数回の対話をサポートしていることです。

プロジェクト	広報
公式の位置づけ	エンタープライズグレードの自然言語から SQL エンジン
コア機能	NL2SQL、マルチラウンドダイアログコンテキスト、複雑な SQL 生成 (JOIN/サブクエリ/集計/ウィンドウ関数)
サポートされているデータベース	PostgreSQL、MySQL、BigQuery、Snowflake、Databricks、MS SQL Server、ClickHouse、MariaDB、Redshift
ベクトルストレージ	松ぼっくり、アストラ、クロマ
導入方法	セルフホスティング (Docker Compose)、クラウド ホスティング (Enterprise Edition)
入力方法	自然言語（主に英語）
出力形式	SQL ステートメント + クエリ結果 + CSV エクスポート
オープンソースライセンス	Apache-2.0
GitHub スター	~3,600
GitHub フォーク	～264
コードの貢献者	19
最新バージョン	v1.0.3 (2024-04-30、GitHub リリース)
総リリース数	9 バージョン
コア言語	Python (58.5%)、TypeScript (39.3%)
システムコンポーネント	エンジン、エンタープライズ API、管理コンソール、Slackbot

デプロイメント アーキテクチャ: Dataherald は、エンジン (コア NL2SQL エンジン)、エンタープライズ (ユーザー/組織/認証管理)、管理コンソール (管理インターフェイス)、および Slackbot (Slack 統合) の 4 つの独立したコンポーネントを含むマイクロサービス アーキテクチャを採用しています。各コンポーネントは Docker Compose を通じて均一に調整され、オンデマンドでの分割デプロイメントをサポートします。

データベースの範囲の広さ: v0.0.1 から v1.0.3 まで、Dataherald は 9 種類のリレーショナル データベースと 3 種類のベクター ストレージを段階的に統合し、主流の OLTP (MySQL、PostgreSQL、SQL Server)、OLAP (ClickHouse、Redshift)、およびクラウド データ ウェアハウス (BigQuery、Snowflake、Databricks) をカバーしました。これが、単一タイプのデータベースのみをサポートする NL2SQL ソリューションとの主な違いです。

反復リズム: 最初のパブリック リリース v0.0.1 (2023-08)、v1.0.0 (2024-01)、v1.0.3 (2024-04)。その後、GitHub のコミット頻度が大幅に低下し、現在メンテナンス期間中です。選択する際には、コミュニティ活動と長期的なサポートのリスクを評価する必要があります。

Dataherald のユーザーと市場での認知度

Dataherald の市場認識は、主にオープンソース コミュニティのフィードバックと企業の PoC 検証に反映されています。同関係者は具体的な収益データ、有料顧客の数、SLA約束の詳細などは明らかにしていない。

GitHub コミュニティの人気: 3,600 以上のスターと 264 のフォーク。これは、NL2SQL オープン ソース トラックの中の上レベルにあります。類似プロジェクトの比較: SQLChat には約 4,000 のスターがあり、Vanna には約 12,000 のスターがあり、DB-GPT には約 14,000 のスターがあります。 Dataherald の特徴は、4 つのコンポーネント (エンジン + エンタープライズ + 管理コンソール + Slackbot) の完全なセットを提供することです。これは、コア推論エンジンのみを提供するほとんどのプロジェクトよりもエンタープライズ レベルの提供形式に近いものです。

エンタープライズ検証シナリオ: 公式ドキュメントと GitHub README で強調されている典型的な使用例には、SaaS 内の埋め込み Q&A 機能、Slack に基づく自然言語計数ロボット、ビジネス チーム向けのセルフサービス計数ポータルが含まれます。これらのユースケースは、小規模や零細チームではなく、データ ウェアハウスに投資しているものの分析人材が不足している中規模および大規模企業を対象としています。

生態学的協力: このプロジェクトは可観測性のために LangSmith を統合し、スキーマ コンテキスト ストレージとして Pinecone/Astra/Chroma の 3 つのベクトル データベースをサポートし、主流の LLM サービス (OpenAI GPT シリーズ Anthropic Claude、セルフホスト モデル) に接続できます。これは、モデルに依存せず、単一の AI ベンダーに縛られないように設計されていることを示しています。

導入の前提条件: Dataherald の真の価値をリリースするには、企業が既に、①構造化されたリレーショナル データ資産、②明確なスキーマ ドキュメントまたはゴールデン クエリ サンプル (ゴールデン SQL)、および③IT チームが追加の自己ホスト型インフラストラクチャを維持する意欲があることを必要とします。どれかひとつでも欠けてしまうと、着地効果が著しく低下してしまいます。

Dataherald のコスト上の利点

Dataheraldのコスト構造は、「Cサイド/個人ユーザー」、「API/開発者統合」、「エンタープライズ/民営化展開」の3つのレベルに分けて検討する必要がある。

C クライアント/個人ユーザー:

• 明示的なコスト: オープンソース コミュニティ エディションは完全に無料で、Apache-2.0 ライセンスにより任意の使用、変更、再配布が許可されます。個々の開発者は、自分のサーバーの運用コストのみを負担する必要があります (Docker Compose モードで 4 つのコンテナーを実行し、推定最小構成は 4 コアと 8G メモリです)。
• 隠れたコスト: LLM API キー (OpenAI、Anthropic など) を自分で設定する必要があり、LLM 通話料金はトークンによって請求されます。スキーマ スキャン + SQL 生成を含む一般的なクエリでは約 2,000 ～ 8,000 トークンが消費されますが、クエリの複雑さに応じて増加します。頻繁に呼び出しが行われるシナリオでは、LLM API のオーバーヘッドがすぐにインフラストラクチャのコストを超える可能性があります。

API/開発者の統合:

• REST API レイヤー: エンジン コンポーネントとエンタープライズ コンポーネントのオープン ソース バージョンは、開発者が独自のアプリケーションに無料で統合できる完全な RESTful API (プロンプト、SQL 生成、NL 生成、ファインチューニング、その他のエンドポイントを含む) を提供します。
• チューニング コスト: Dataherald は、Golden SQL に基づく微調整 (ファインチューニング) をサポートしていますが、微調整プロセスでは OpenAI トレーニング クレジットが消費され、高品質の Question-SQL ペアのサンプルの準備が必要です。推奨されるサンプル数は 50 ～ 200 で、1 回の微調整にかかるコストは数十ドル程度です。
• 暗黙的な統合コスト: 各データベース接続のスキーマ記述を手動で構成し (または自動スキャンを実行し)、Golden SQL サンプル ライブラリを保守し、LLM で生成された SQL が期待を満たさないという隠れたロジックに対処する必要があります。こうしたエンジニアリングの取り組みは、多くの場合、API 呼び出し自体のコストよりも大きくなります。

エンタープライズ/プライベート展開:

• Enterprise Edition の価格: Enterprise Edition の正式な価格は公開されていません。業界の慣例によれば、サブスクリプション制が採用されていると推測される。通常、請求の次元には、データベース接続の数、API 呼び出しの割り当て、ユーザー シートの SLA レベルが含まれます。 Enterprise Edition の付加価値には、SSO 統合、監査ログ、専用 SLA サポートが含まれます。
• インフラストラクチャ コスト: プライベート デプロイメントでは、企業が Docker を管理して、制限された MongoDB データベース、ベクトル データベース、およびネットワーク構成を実行する必要があります。 1 日あたり 1,000 クエリという中程度の負荷の場合、毎月のインフラストラクチャ コストは 100 ～ 500 米ドルと推定されます (クラウド ホスト + ベクター ストレージ + 帯域幅)。
• 人的運用および保守コスト: システム保守、Golden SQL 管理、およびクエリ品質監視を担当するには、Docker および LLM 呼び出しに精通した開発担当者または運用保守担当者が少なくとも 1 人必要です。この隠れたコストは通常​​、インフラストラクチャのコストの 3 ～ 5 倍になります。

コストの比較: NL2SQL オープンソース ソリューション

ソリューション	オープンソースライセンス	導入の複雑さ	データベースの範囲	微調整サポート	エンタープライズ機能	コミュニティ活動
データヘラルド	Apache-2.0	中 (4 コンポーネント Docker)	9種類のDB + 3種類のベクトルストレージ	✅ 組み込みの微調整 API	✅ 管理コンソール + Slackbot + エンタープライズ	中 (3.6k つ星)
ヴァンナ	マサチューセッツ工科大学	低 (Python ライブラリ)	主にSQLite/PGをサポート	✅ DDL ドキュメント経由でトレーニング	❌ なし	高 (12,000 個の星)
SQLチャット	マサチューセッツ工科大学	低 (ノード ライブラリ)	主にMySQL/PGをサポート	❌ なし	❌ なし	中 (4k スター)
DB-GPT	Apache-2.0	高 (複数のコンポーネント)	複数の DB	✅ サポート	✅ 完全なエンタープライズ機能	高 (14,000 個の星)

コスト差のハイライト:

• Dataherald は、オープン ソース NL2SQL ソリューションで最も完全なエンタープライズ レベルのパッケージ (管理コンソール Slack 統合、マルチテナンシー、監査ログ対応) を提供しており、最初から構築するのではなく「すぐに使える」必要があるチームに適しています。
• すでに LLM API クレジットを持っており、展開の複雑さに対する許容度が低い場合は、Vanna (単一の Python ライブラリのインストール) または SQLChat (Node.js パッケージ) の方が初期起動コストが低くなります。
• DB-GPT は、機能の完全性とコミュニティの規模の点で優れていますが、展開の複雑さも高く、主に中国のシナリオに最適化されており、Dataherald の英語優先の位置付けとは異なります。

Dataheraldの主な機能

• Natural Language to SQL (NL2SQL): 「前四半期の地域別売上ランキング」を入力すると、エンジンが集計の意図を自動的に認識し、GROUP BY および ORDER BY を使用した SQL ステートメントを生成します。中心となるメカニズムは、LLM を通じてユーザーの質問をデータベース スキーマにマッピングし、会話コンテキストを組み合わせて実行可能な SQL を合成することです。従来の BI ツールとの違いは、事前に設定されたレポート構造がなく、ユーザーが任意のクエリ ディメンションを自由に記述できることです。

• 複数回の対話コンテキスト保存: 最初のクエリ結果 (「中国東部のみを表示」または「月ごとに表示に変更」など) に基づいて質問を続けます。エンジンは、プリオーダー SQL のフィルター条件と集計ロジックを保持し、WHERE 句または GROUP BY フィールドを段階的に変更するだけです。ビジネス ユーザーにとってのこの機能の実際の価値は、完全な要件を一度に説明する必要がなく、人間との会話のようにクエリの範囲を徐々に絞り込むことができることです。単一の分析タスクの対話型ラウンドは通常、1 ラウンドから 3 ～ 5 ラウンドに拡張されますが、各ラウンドは意味的に一貫したままです。

• データベース スキーマの自動認識: エンジンは、データベース テーブル構造、フィールド名、フィールド タイプ、主キーと外部キーの関係を自動的にスキャンし、SQL 生成時にフィールドのエイリアスと関連キーを自動的に照合します。スキーマ スキャンの結果は、MongoDB およびベクター データベースに保存されます。 SQL を生成するとき、LLM はユーザーの質問に関連するテーブルとフィールドのみをコンテキストとして取得し、スキーマ全体がプロンプトに詰め込まれてトークンが拡張されることを回避します。

• クエリ結果の自然言語説明 (NL 生成): 生成された SQL ステートメントと実行結果について、エンジンは「この SQL に対してどのようなフィルタリングが行われたか、どのディメンションで集計されたか、ソートの基準は何か」を説明する自然言語説明を自動的に生成します。技術者以外のユーザーにとってのこの機能の重要な価値は、たとえ SQL を理解できなくても、クエリ ロジックが正しいかどうかを理解できるため、AI によって生成された結果に対する信頼を確立できることです。

• Golden SQL の管理とモデルの微調整: 検証済みの「質問と SQL」のペアを Golden SQL コレクションに保存し、これらのサンプルに基づいて GPT シリーズ モデルを自動的に微調整 (微調整) することをサポートします。同様のビジネス クエリに対する微調整されたモデルの精度が大幅に向上しました。これは「使えば使うほど精度が上がる」仕組みで、初期段階では一般的なLLMの知識に依存しており、独自のクエリサンプルを蓄積するにつれて徐々に精度が90%以上に収束していきます。

• 中間ステップの視覚化 (ストリーミング): v1.0.2 で導入されたストリーミング エンドポイントは、スキーマの取得から SQL 合成、結果の実行まで、SQL 生成の中間推論ステップを表示します。これにより、ユーザーと開発者は AI の思考チェーンを確認でき、デバッグと信頼構築が容易になります。

• Slack 統合クエリ ロボット: Slackbot コンポーネントを通じて、ユーザーは自然言語を直接使用して Slack チャネルのデータベースに質問することができ、ロボットはクエリ結果または CSV ファイルを返します。これは、技術的な背景がない運用、マーケティング、営業チームにとって特に便利です。日常のワークフローでデータ取得を完了するために BI ツールを開く必要はありません。

• CSV エクスポートとファイル ストレージ: クエリ結果は CSV に直接エクスポートし、(AWS 認証情報を構成することで) S3 に保存できます。これは、Excel または Google スプレッドシートでの後続の二次分析に適しています。 API 応答ペイロードが大きくなりすぎないように、行数が 50 行を超えると自動的にファイル ストレージを使用します。

Dataherald のモデルとバージョンの進化

Dataherald のバージョン履歴は、プロトタイプの検証からエンタープライズ機能の改善、そしてエコロジカルな拡張に至るまでの進化の軌跡を明確に反映しています。以下はGitHub Releasesの公開情報をもとにまとめたものです。

メインライン リリース

バージョン	発売日	主要な変更点	マイルストーン
v0.0.1	2023-08	初期バージョン、基本的な NL2SQL クエリ関数	プロジェクトの承認、MVP の検証
v0.0.2	2023-09-14	RESTful エンドポイントの再構築、MongoDB コレクション名の標準化、db_connection_id アソシエーションの導入	API 構造の最終化、ラピッド プロトタイピングから標準化への移行
v0.0.3	2023-09-26	LLM 認証情報は、SSH 接続の最適化と非同期スキーマ スキャンをサポートします。エンタープライズ接続機能が強化され、スキャン パフォーマンスが最適化されます。
v0.0.4	2023-10-07	エンドポイントの名前変更 ObjectId 外部キー NL 生成分割	API セマンティクスを明確にし、1.0 に備える
v0.0.5	2023-10-26	llm_api_key フィールドの簡略化された S3 CSV ストレージ、エラー コード システム	構成の簡素化と可観測性の向上
v0.0.6	2023-11-14	CSV生成フラグS3証明書を設定可能	データ エクスポート機能の向上
v1.0.0	2024-01-17	微調整 API、プロンプト/SQL 生成/NL 生成の 3 フェーズ分割ゴールデン SQL コレクション	アーキテクチャの成熟度のマイルストーン
v1.0.1	2024-03-05	ClickHouse は MariaDB 公式サポート、エンドポイントの更新、エラー コードの改善をサポートします。データベースの対象範囲の拡大
v1.0.2	2024-04-04	MS SQL Server、Astra/Pinecone サーバーレスのサポート ストリーミング中間ステップ LangSmith 統合	生態系のつながりと観測性の向上
v1.0.3	2024-04-30	Redshift サポート、複数のスキーマ サポート (PG/BigQuery/Snowflake/Databricks)	企業のマルチスキーマ シナリオに最適な最新バージョン

進化的文脈の解釈

フェーズ 1: プロトタイプ検証 (v0.0.1 ～ v0.0.2): 最初の 2 つのバージョンは主に、「自然言語から SQL へ」のエンドツーエンドのプロセスを完了しました。 v0.0.2 の RESTful API リファクタリングは、その後のすべてのエンタープライズ機能の基盤を築きます。

フェーズ 2: エンタープライズ接続機能の構築 (v0.0.3 ～ v0.0.6): SSH 接続、S3 ストレージへの CSV エクスポートをサポートする複数のデータベース、エラー コード システム、およびその他のエンタープライズに必要だがコアではない AI 機能が徐々に完成します。この段階では、Dataherald チームが、企業における NL2SQL の実装に対する障害は AI の精度だけでなく、データの接続性や運用と保守の可観測性であることを認識していることがわかります。

フェーズ 3: 1.0 アーキテクチャの成熟度 (v1.0.0): v1.0.0 は、元の単一の「質問→回答」プロセスを 3 段階のパイプライン (プロンプト (問題理解) → SQL 生成 (SQL 合成) → NL 生成 (結果解釈)) に分割し、Finetuning API を導入する大きなアーキテクチャ変更です。 3 段階の分割により、各セクションを個別に最適化、キャッシュ、監査できるようになります。これは、エンタープライズ レベルの展開における重要な設計上の決定です。

フェーズ 4: エコロジカルな拡張とメンテナンス (v1.0.1 ～ v1.0.3): ストリーミング エンドポイントを通じて可観測性を向上させながら、データベース カバレッジ (ClickHouse、MariaDB、SQL Server、Redshift) とベクター ストレージ オプション (Astra、Pinecon サーバーレス) の拡大に焦点を当てます。 v1.0.3 以降、プロジェクトはローアクティブ メンテナンス期間に入り、新しい機能バージョンはリリースされませんでした。

候補者の検証とコミュニティへの貢献

メインライン リリースに加えて、Dataherald はプル リクエストと問題を通じて 19 人のコントリビューターの参加を促進し、バグ修正、ドキュメントの改善、マイナーな機能拡張をカバーしています。しかし、全体として、プロジェクトの中核となる開発はチームによって内部的に主導され、コミュニティの貢献者は主にドキュメントと周辺機能に重点を置いています。

バージョン戦略の評価: Dataherald のバージョン命名はセマンティック バージョン仕様 (SemVer) に従っていますが、v0.0.1 から v1.0.3 までにかかる時間はわずか 8 か月で、その後は停滞しました。選択する際には、現在の機能がニーズを満たしているか、コミュニティフォークや自己保守のリスクを受け入れるかどうかを評価する必要があります。

Dataherald の技術的利点

Dataherald の技術的利点は、単一のアルゴリズムの画期的な進歩にあるのではなく、エンジニアリング アーキテクチャの設計、つまり実装、監視、反復可能なエンタープライズ レベルのシステムに LLM の NL2SQL 機能をカプセル化する方法にあります。

3 段階のパイプライン アーキテクチャ

Dataherald は、自然言語クエリ処理を 3 つの独立したステージに分割します。

「」 ユーザー入力 → [プロンプト] → [SQL生成] → [NL生成] → ユーザー出力 ↓ ↓ スキーマ ベクトル検索のゴールデン SQL マッチング 「」

• プロンプト ステージ: ユーザーの自然言語入力を受け取り、会話履歴 (存在する場合) とベクトル データベースから取得した関連スキーマ情報を組み合わせて、LLM に適したプロンプトに組み立てます。重要な最適化は、データベース スキーマ全体を一度に注入するのではなく、ベクトル類似性検索を通じてユーザーの問題に最も関連するテーブルとフィールドのみを選択することです。これにより、トークンの消費が大幅に削減され、LLM の混乱が軽減されます。
• SQL 生成フェーズ: 組み立てられたプロンプトを LLM に送信して SQL を生成します。 Golden SQL 微調整モデルが構成されている場合は、精度を向上させるために最初に微調整モデルを使用します。それ以外の場合は、一般モデルに戻ります。 v1.0.2 で導入されたストリーミング エンドポイントにより、SQL 生成の中間推論ステップ (LLM の思考チェーン、フィールド マッチング プロセスの JOIN 条件の選択) をリアルタイムで表示できます。これは、デバッグと信頼構築に重要です。
• NL 生成フェーズ: 自然言語を使用して、生成された SQL と実行結果について「このクエリが何をしたか」をユーザーに説明します。これは過小評価されていますが、非常に価値のある設計です。技術者以外のユーザーは通常 SQL を読むことができませんが、自然言語解釈を通じてクエリ ロジックが正しいかどうかを迅速に判断し、結果を受け入れるかどうかを決定できます。

スキーマ認識とベクトル検索のコラボレーション

Dataherald のスキーマ処理メカニズムは、Dataherald と単純な Prompt ラッパーの間の核となる境界線です。

1. 自動スキャン: 「POST /api/v1/table-descriptions/sync-schemas」エンドポイントの非同期バックグラウンド タスクを通じてデータベースをスキャンし、テーブル名、フィールド名、フィールド タイプ、コメント、主キーと外部キーの関係を取得します。
2. スキーマ ベクトル化ストレージ: 埋め込みモデルを使用してテーブルとフィールドの説明情報 (名前 + コメント) をベクトル化し、Pinecone/Astra/Chroma ベクトル データベースに保存します。
3. 実行時取得: ユーザーが質問すると、まず質問に対して埋め込みを実行し、ベクトル ライブラリ内の上位 K 関連テーブルとフィールドを取得し、これらのコンテキストのみを LLM プロンプトに挿入します。
4. 増分キャッシュ: スキャン結果は MongoDB にキャッシュされ、完全な再構築ではなく増分更新をサポートします。 「POST /api/v1/table-descriptions/refresh」エンドポイント (v1.0.1 で導入) は、すべてのデータを再スキャンせずにテーブル リストを効率的に更新するように設計されています。

このメカニズムの工学的な重要性は、エンタープライズ データベースには多くの場合、数百のテーブルと数千のフィールドがあることです。それらのすべてが LLM コンテキストに挿入されると、トークンの消費は許容できなくなり、LLM の混乱が深刻になります。ベクトル取得 + 動的インジェクションは、精度とコストの両方を考慮して、3 ～ 8 テーブル内の各クエリのスキーマ コンテキストを制御します。

繰り返しで終了したゴールデン SQL

Dataherald の Finetuning メカニズムは、継続的な最適化プロセスを構成します。

「」 ビジネスクエリ → SQL生成 → 手動レビュー → Golden SQLに保存 → モデルの微調整 → 精度の向上 ↑ 微調整を定期的にトリガーする 「」

• ゴールデン SQL コレクション: 検証された「自然言語の質問 ↔ 標準 SQL」のペアを保存します。各ペアには、質問、SQL、db_connection_id、およびメタデータが含まれます。
• 微調整プロセス: POST /api/v1/finetuning を呼び出して微調整タスクを作成すると、エンジンが Golden SQL を OpenAI 微調整に必要なデータ セット形式に自動的にフォーマットして送信します。微調整が完了したら、「GET /api/v1/finetuning/{id}」を通じてステータスをクエリできます。ステータスが SUCCEEDED の場合、SQL 生成に使用できます。
• 実際の結果: 公式ドキュメントによると、微調整されたモデルにより、独自のビジネス ドメインにおける SQL 生成の精度が大幅に向上しました。正確な値は開示されていませんが、論理的には合理的です。一般的なモデルでは、「売上高」が SUM(金額) であることは理解できますが、企業固有の「純売上高 = SUM(金額) - SUM(割引) - SUM(利益)」は理解できません。微調整後、モデルはこれらのビジネス ルールを学習できます。

モデルの独立性と置換可能性

Dataherald は、基礎となる LLM の抽象化をアーキテクチャ レベルで維持します。エンジンは構成インターフェイスを通じてさまざまなモデルにアクセスし、単一の OpenAI サプライヤーに束縛されません。公式サポートには、GPT-4/GPT-3.5、Claude シリーズ、セルフホスト モデル (OpenAI API 形式と互換性のあるローカル展開経由) が含まれます。この設計は、企業調達において実用的な価値があります。GPT-4 を使用して PoC 検証精度の上限を設定し、オンラインになった後にセルフホスト モデルに切り替えることで、推論コストを削減し、データ主権を制御できます。

マルチテナンシーと権限の分離

Enterprise コンポーネントは、組織全体のユーザー管理、ロール権限、データベース接続の分離を提供します。各データベース接続は独立した LLM API キーを使用して構成でき、読み取り専用モード (UPDATE/DELETE/DDL ステートメントの生成を防止) とデータの非感作をサポートします。これらのメカニズムは、複数部門または複数顧客のシナリオで厳密に必要です。異なる部門は、承認スコープ内のテーブルとデータのみをクエリできます。

データヘラルドの使用方法

Dataherald は、開発者の API 統合からビジネス チームの Slack 対話まで、さまざまな使用シナリオをカバーする複数の入り口と統合方法を提供します。

導入エントリの比較

入口	対象者	起動方法	前提条件
エンジンAPI（コアエンジン）	開発者	Docker Compose はエンジン サービスを実行します	Docker、MongoDB、LLM API キー
エンタープライズ API (フル機能)	開発者/IT管理者	Docker Compose は 4 つのサービスすべてを実行します。 Docker、MongoDB、Vector データベース LLM API キー
管理コンソール (管理インターフェイス)	データアナリスト/管理者	Enterprise で起動、ブラウザ アクセス	エンタープライズ API の実行中
スラックボット	ビジネスチーム	Enterprise で起動、Slack アプリの構成	エンタープライズ API + Slack アプリの権限
REST API	開発者	エンジン/エンタープライズ エンドポイントを直接呼び出す	デプロイされた API ベース URL

迅速な導入と起動 (セルフホスト型)

最小構成要件 (PoC レベル):

「」バッシュ

1. リポジトリのクローンを作成する

git クローン https://github.com/Dataherald/dataherald.git cdデータヘラルド

2. コンテキスト変数を設定します (各サービス ディレクトリの .env.example を参照)

少なくとも必要な設定: OPENAI_API_KEY、MONGODB_URI

3. ワンクリックですべてのサービスを開始する

./docker-run.sh 「」

上記のコマンドは、Engine (ポート 80)、Enterprise (ポート 81)、Admin Console (ポート 3000)、および Slackbot を起動し、Docker ネットワークを自動的に作成します。起動後、「http://localhost:3000」を通じて管理コンソールにアクセスできます。

API呼び出しの例

データベース接続の作成:

「」バッシュ curl -X POST http://localhost:80/api/v1/database-connections \ -H "コンテンツ タイプ: application/json" \ -d '{ "エイリアス": "production_db", "connection_uri": "postgresql://user:password@host:5432/mydb", "llm_api_key": "" }' 「」

スキーマを同期:

「」バッシュ curl -X POST http://localhost:80/api/v1/table-descriptions/sync-schemas \ -H "コンテンツ タイプ: application/json" \ -d '{"db_connection_id": "<接続_id>"}' 「」

自然言語クエリを開始します:

「」バッシュ curl -X POST http://localhost:80/api/v1/prompts/sql-generations \ -H "コンテンツ タイプ: application/json" \ -d '{ "db_connection_id": "<接続_id>", "question": "前四半期の地域別売上ランキング" }' 「」

微調整されたモデル:

「」バッシュ curl -X POST http://localhost:80/api/v1/finetuning \ -H "コンテンツ タイプ: application/json" \ -d '{ "db_connection_id": "<接続_id>", "golden_sql_ids": ["", ""] }' 「」

一般的な使用プロセス

1. 初期化: サービスのデプロイ → データベース接続の作成 → スキーマの同期 → スキャン ステータスが SYNCHRONIZED であることを確認します。
2. 検証: いくつかの基本的なクエリ (単純な SELECT、条件付きフィルタリング) を送信して、生成の品質と実行の正確さをチェックします。
3. サンプルの蓄積: 高頻度のビジネス クエリの場合、検証済みの質問と SQL のペアをゴールデン SQL に保存します。
4. 微調整: 垂直領域の精度を向上させるために、50 以上のサンプルが蓄積された後に微調整がトリガーされます。
5. オンラインにする: Admin Console ロールの権限を設定 → ビジネス チームに公開 → クエリ ログとエラー率を監視します。
6. 反復: クエリ ログを定期的に確認し、新しいクエリ パターンを Golden SQL に追加し、微調整を続けます。

プリセットノート

• ユーザーのデータベース テーブルとフィールド名が英語以外 (中国語など) である場合、Dataherald のスキーマ スキャンと LLM の理解が大幅に低下します。これは、現在のバージョンの主要な言語制限の 1 つです。
• 運用ユーザーの場合は、最初に読み取り専用モードを有効にし、SQL 生成によって予期しない UPDATE/DELETE 操作が発生しないことを確認した後、権限を緩和することをお勧めします。
• スキーマの自動スキャンは、大規模なライブラリの場合は数分かかる場合があります。 v1.0.1 で導入された /refresh エンドポイントにより、増分更新時間を大幅に短縮できます。

Dataherald の製品価格

Dataherald の価格体系は、オープンソース コミュニティ バージョンとエンタープライズ商用バージョンの 2 つのパスに分かれています。エンタープライズ版の正式価格は明らかにされていない。

オープンソース コミュニティ エディション (Apache-2.0):

• 料金: 完全に無料、ユーザー数、クエリ量、データベース接続に制限はありません。
• 含まれるコンテンツ: Engine (コア エンジン) + Enterprise (マルチテナント API) + Admin Console (管理インターフェイス) + Slackbot (Slack 統合) のすべてのソース コード。
• 適用条件: Docker Compose を実行し、MongoDB、ベクター データベース、および LLM API キーを自分で設定するには、独自のサーバーまたはクラウド ホストが必要です。
• 商用利用の制限: Apache-2.0 ライセンスでは自由な使用と変更が許可されていますが、製品を SaaS サービスとして直接再配布することは許可されていません (ライセンス条項に従います)。

Enterprise Edition (価格は非公開):

• 含まれる予定: SSO (SAML/OIDC) 統合、監査ログ、専用 SLA サポート、優先テクニカル サポート、エンタープライズ グレードの導入ガイド。
• 請求額の推測: データベース接続数 + 毎月の API コール + ユーザー シート数に基づく複合サブスクリプション モデル。同様のオープンソース商用化プロジェクト (N8n、Appsmith など) を参照すると、エンタープライズ バージョンの年間料金は 5,000 ドルから 50,000 ドルの範囲になる可能性がありますが、これは業界の推論にすぎず、公式の見積もりが優先されます。
• 入手方法: 見積もりとトライアルを取得するには、公式営業チームに連絡する必要があります。公式ウェブサイトにはセルフサービスの購入入り口がありません。

LLM 通話料金 (Dataherald 製品料金とは別):

• これは Dataherald を使用するための追加コストであり、ユーザーが選択した LLM プロバイダーと通話量に直接依存します。
• GPT-4 の一般的な NL2SQL クエリは約 2,000 ～ 5,000 トークン (入力スキーマ + 質問) を消費し、価格は GPT-4 に基づいて 1 回あたり約 0.01 ～ 0.03 ドルです。高頻度シナリオ (1 日あたり平均 10,000 回) の月額 LLM 料金は、3,000 ～ 9,000 ドルです。
• GPT-3.5-Turbo またはセルフホスト モデルを使用すると、ビルド精度が犠牲になる可能性がありますが、このコストを 10 ～ 30 分の 1 に削減できます。
• LLM 呼び出しのコストは予算モデルで予約することをお勧めします。これは通常、Dataherald 独自のインフラストラクチャのコストを超えます。

Dataherald のアプリケーション シナリオ

シナリオ 1: ビジネス チームが独自にデータを収集する

タスクの説明: 市場運営、販売管理、財務分析などの非技術チームは、データ ウェアハウスからレポートを頻繁に取得する必要があります。従来のプロセスでは、① BI ツールでレポートを申請する → ② データ ウェアハウス チームがスケジュールを設定するのを待つ → ③ オンデマンドで詳細を繰り返し伝達する → ④ 静的レポートを取得する というプロセスが必要です。 Dataherald はこれを次のように簡素化します。ユーザーは Slack または管理コンソールで自然言語で直接質問し、クエリ結果を即座に取得します。

実際の収入:

• 単一のクエリ サイクルは、平均 4 ～ 6 時間から 1 ～ 3 分に短縮されます (差し引き)。
• データ チームは、「SQL の作成 - SQL の変更」の繰り返しから解放され、データ モデリングとガバナンスに集中できます。
• ビジネスチームはスケジューリングを待たずに自由にデータを探索でき、意思決定の応答速度が向上します。

実装検証の焦点: ビジネス ユーザーが「報告を待つ」という習慣を変え、自然言語で積極的に質問するかどうか。そして、一般的なクエリの最初の世代の精度率が 70% 以上に達するかどうか (この値を下回ると、ユーザーは諦めてしまいます)。

シナリオ 2: SaaS 製品の組み込みデータ Q&A 機能

タスクの説明: CRM、ERP、プロジェクト管理などのデータ集約型の SaaS 製品では、エンド ユーザーが複雑なフィルタリング インターフェイスを介して探索するのではなく、自然言語を通じて製品内データをクエリできるようにしたいと考えています。 Dataherald のエンジン API は、製品の「データ分析アシスタント」機能として組み込むことができます。

実際の収入:

• ユーザーの学習コストを削減 - フィルター構文を学ぶ必要がなく、母国語で質問することでデータを取得できます。
• 製品のプリセット レポートの開発とメンテナンスの作業を軽減します。固定レポートは動的生成に置き換えられます。
• ユーザーの粘着性とデータ アクティビティを改善し、受動的閲覧を能動的かつ受動的探索に変えます。

実装検証の焦点: マルチテナントのデータ分離が正確に達成できるかどうか (テナント A のユーザーは SQL インジェクションによってテナント B のデータを見ることができません)。また、同時実行性が高い場合 (SaaS のピーク時間など) のエンジンの応答パフォーマンスが許容範囲内であるかどうか。

シナリオ 3: データ分析の高速化 - 複雑なクエリ スケルトンの生成

タスクの説明: プロのデータ アナリストは、複数テーブルの JOIN、ウィンドウ関数、サブクエリを必要とする複雑な分析要件に直面した場合、Dataherald を使用して SQL スケルトンを迅速に生成し、これに基づいて微調整および最適化します。

実際の収入:

• 特に不慣れなテーブル構造の場合、SQL 書き込み効率が 2 ～ 3 倍向上すると推定されます (スキーマ定義を手動で確認する必要がありません)。
• 低レベルの構文エラーの削減 - AI 生成により、JOIN 条件エラー、GROUP BY の省略、集計関数の誤用などを回避できます。
• アナリストは SQL 構文のデバッグではなく、データ分析とビジネス解釈に集中できます。

実装検証の重要なポイント: 複雑なクエリに対する Dataherald の生成品質 (4 つを超えるテーブルの JOIN、再帰的 CTE、動的 PIVOT)。現在のバージョンでは、非常に複雑なクエリに対する安定性が制限されており、アナリストは生成された結果を完全に信頼するのではなく、確認して修正する SQL 機能が必要です。

シナリオ 4: Slack 埋め込みデータ操作

タスクの説明: 企業は、Slackbot コンポーネントを通じてデータベース クエリ機能を日常の業務コミュニケーション チャネルに組み込みます。経営者がチャネル内で「今週の新規顧客の数」を直接尋ねると、ロボットがデータを返しました。運営スタッフは「地域ごとの分布」を尋ねましたが、文脈は一貫していました。

実際の収入:

• データ取得における摩擦ゼロ — 集計、分析、共有のプロセス全体を、Slack を離れることなく完了できます。
• クエリ結果と会話記録は Slack チャネルに自然に保存され、追跡可能なデータ ディスカッション履歴を形成します。
• 企業内の「データアイランド」効果を軽減します - 技術者以外の役割は、パブリック チャネルでのデータ会話を見て、データ クエリの動作を微妙に学習して模倣します。

実装検証の重要なポイント: 長い会話のコンテキストを維持する Slackbot の機能。 Slack チャネルに表示される機密データのコンプライアンス リスク (PII フィールドをフィルタリングする必要があるかどうか)。

Dataherald の該当グループ

コア適応群衆

• データ アナリスト: Dataherald を使用すると、SQL スケルトンを迅速に生成し、作業の重複を減らし、データの洞察により多くの時間を費やすことができます。適応の前提条件は、アナリストが SQL 監査機能を備えており、AI によって生成された不完全な SQL を修正できることです。不適切なシナリオ: 複雑なクエリに対して厳格な品質要件があり、SQL エラーを許容できない運用シナリオ。

• ビジネス運営/マーケティング/営業チーム: データ チームへの依存を排除​​し、自然言語を通じてデータ レポートを直接取得します。適応の前提条件は、企業のデータ モデルが比較的標準化されており (フィールド名が明確で注釈が付けられている)、クエリ要件が複雑な複数ステップの分析ではなく、主に集計レポート (合計、カウント、ランキング、傾向) に基づいていることです。不適切なシナリオ: 非常に高いデータ精度が必要な状況 (財務調整など)、またはクエリ言語が中国語でテーブル/フィールド名も中国語である場合。

• IT/データ エンジニア: Dataherald システムの導入、メンテナンス、ゴールデン SQL サンプル管理を担当します。適応の前提条件は、チームが Docker の運用および保守能力を備えており、スキーマ構成の継続的な最適化、サンプルの蓄積、モデルの微調整に時間を投資する意欲があることです。適用されないシナリオ: フルタイムの運用および保守担当者がいないチーム、またはデータベースが古いシステム (フィールド名が無意味でコメントされていない)、またはデータの更新頻度が非常に高く (1 分あたりのレベル)、リアルタイムのスキーマ認識が必要なチーム。

• SaaS プロダクト マネージャー/テクニカル リード: データ分析機能を提供するために Dataherald を自社製品に組み込むことを評価します。適応の前提は、製品のデータ シナリオが主にアメリカ/ヨーロッパの英語市場のクエリ指向ユーザーを対象としているということです。適用されないシナリオ: 中国市場をターゲットとした製品 (データ テーブル名とフィールド名が中国語の場合、精度が大幅に低下します)、または高度な権限監査と多層データ分離を必要とする製品。

不適切な境界と前提条件

• 言語制限: Dataherald のスキーマ スキャンと NL 生成では、主な作業言語として英語が使用されます。基盤となる LLM は中国語入力を処理できますが、スキーマ フィールドの説明、エラー メッセージ、およびシステム全体の管理インターフェイスは英語用に設計されています。中国語のテーブル名とフィールド名を使用するシナリオでは、DB-GPT などの中国語の最適化ソリューションを優先することをお勧めします。
• データベースの断片化: 企業のデータベースが 50 以上の独立したインスタンスに分散されている場合、それぞれのインスタンスで接続とスキーマ スキャンの個別の構成が必要になり、メンテナンス コストが直線的に増加します。コア データ ウェアハウスのみにアクセスすることをお勧めします。エッジ データベースには依然として従来の方法が必要です。
• モデル依存関係のリスク: Dataherald は単一のモデルをバインドしませんが、SQL 生成の品質は、選択した LLM の機能に大きく依存します。 GPT-3.5-Turbo などの低コスト モデルを選択した場合、複雑なクエリの精度が実稼働要件を満たさない可能性があります。 GPT-4 を選択すると、推論コストが予算の負担になる可能性があります。 PoC フェーズでは、複数のモデルの組み合わせを同時にテストすることをお勧めします。
• データ セキュリティ監査: Enterprise コンポーネントは基本認証とマルチテナント サポートを提供しますが、担当者は SOC2/GDPR などのコンプライアンス認証情報を開示していません。金融や医療などコンプライアンスの強い業界では、購入前に営業チームにコンプライアンス条件を確認する必要があります。

概要と展望

Dataherald は、エンタープライズ レベルの NL2SQL トラックで高度に設計されたオープン ソース ソリューションを提供します。その核となる価値は、3 段階のパイプライン アーキテクチャであるスキーマ対応ベクトル取得とゴールデン SQL のクローズド微調整メカニズムにあります。これらの設計により、単純な LLM プロンプト ラッパーとは区別されます。

現在の利点:

• 幅広いデータベースをカバーし (9 種類のリレーショナル データベース + 3 種類のベクトル ストレージ)、オープンソースの NL2SQL ソリューションをリードします。
• 完全なコンポーネント (エンジン + エンタープライズ + 管理コンソール + Slackbot)、エンタープライズ レベルの提供形式に近い。
• モデルに依存しない設計で、単一の LLM サプライヤーに縛られず、コストやシナリオに応じた切り替えが可能です。
• Golden SQL + Finetuning によって形成される「使えば使うほど正確になる」関係により、独自のビジネス ドメインの精度が継続的に向上します。

現在の制限事項:

• プロジェクトは v1.0.3 以降、ローアクティブ メンテナンス期間に入っています。半年以内に新しい機能バージョンはなく、コミュニティの貢献は主に限界修復に留まっています。モデルを選択する際には長期的なメンテナンスのリスクを評価する必要があり、必要に応じてフォークのセルフメンテナンス計画を維持する必要があります。
• 中国語の自然言語サポートが不十分 - スキーマのスキャンとフィールド記述の NL 生成は主に英語で行われ、中国語のテーブル名/フィールド名のシナリオ適用可能性は制限されます。
• 超複雑な SQL (5 つを超えるテーブルとの JOIN、再帰的 CTE、動的 PIVOT、複数レベルのサブクエリのネスト) の生成品質は十分に安定しておらず、アナリストによる二次レビューが必要であり、完全に自動化することはできません。
• エンタープライズ バージョンの価格、SLA コミットメント、コンプライアンス認証 (SOC2/GDPR) などの主要なビジネス情報は正式に開示されていません。企業は購入前に販売チャネルを通じて一つ一つ確認する必要がある。

業界の見通し: NL2SQL は「使いやすい」から「使いやすい」に移行しており、Dataherald に代表されるエンジニアリング ルート (スキーマ認識 + クロージャの微調整 + マルチコンポーネントのコラボレーション) は正しい方向です。 LLM の基本的な機能が向上し続けるにつれて (SQL 生成における DeepSeek-V4 や GPT-5 などの新しいモデルの進歩など)、NL2SQL の精度のボトルネックは徐々に緩和されるでしょう。それまでに、エンジニアリングの準備が十分に整っている Dataherald のような中間層プラットフォームが直接恩恵を受けることになります。ただし、プロジェクトがメンテナンスのリズムを再開できることが前提です。そうでないと、よりコミュニティ活動が活発な代替案 (DB-GPT、Vanna など) に機能とエコロジーの点で追い越されてしまいます。

調達/採用リスク評価: Dataherald は、「コア データ インフラストラクチャ」ではなく、「非クリティカル パス データ クエリ アクセラレータ」として導入することをお勧めします。まずはオープンソース版を利用し、小規模な領域（業務チーム1～2、コアテーブル5～10）で、①英語クエリの精度が70％以上に達するか、②自社データベース上でのスキーマスキャンやベクトル検索の性能、③微調整後の効果向上などを重点的に検証し、2～4週間PoCを実施します。 PoC の通過後、より幅広いビジネス シナリオに拡張できるかどうか、エンタープライズ バージョンのサポート サービスが必要かどうかを評価します。プロジェクトが長期間アクティブなメンテナンスに戻らない場合は、よりアクティブなコミュニティを移行ターゲットとして代替案の評価を優先することをお勧めします。

関連ツール: github-copilot、カーソル

バージョン情報

• 安定版リリース ：最初の安定バージョンは、マルチラウンド ダイアログ コンテキスト、複雑な JOIN、およびサブクエリの生成をサポートしています。公式の正確な日付はまだありません。 （~2025-06）
• ベータ ：ベータ テスト バージョンは、基本的な Text-to-SQL クエリをサポートしていますが、正式な正確な日付はまだありません。 （~2025-03）