OpenClaw を使用した自然言語データベース クエリ

ビジネスユーザーにはデータが必要です。データベース管理者はクエリを作成します。どのような質問をすればよいかを知っている人と、その答えを得る方法を知っている人の間のこのギャップにより、組織は膨大な時間を費やし、SQL の知識を持つ人に分析のボトルネックが集中します。

自然言語データベース クエリ (text-to-SQL または NL-to-SQL とも呼ばれます) は、このギャップを埋めます。 OpenClaw の NL クエリ機能を使用すると、ビジネス ユーザーは、SQL の知識やデータベース アクセス資格情報がなくても、開発者を待たなくても、平易な英語で質問し、データベースから正確な回答を得ることができます。

これは、多くのツールが提供する CSV 経由の単純なチャットボット エクスペリエンスではありません。これは、複雑な複数テーブルのクエリ、集計計算、日付範囲式、ビジネス用語の翻訳を処理できる、運用グレードの Text-to-SQL です。

重要なポイント

• ビジネス ユーザーは SQL の知識がなくても平易な英語を使用して運用データベースにクエリを実行できます
• OpenClaw は自然言語をパラメータ化された SQL に変換します。SQL への生のユーザー入力は決してありません (インジェクションセーフ)
• セマンティック レイヤーを介したスキーマ理解により、ビジネス用語が技術的なデータベース フィールドにマッピングされます
• 結合、集計、CTE、ウィンドウ関数などの複雑なクエリがサポートされています
• 結果は、コンテキストと視覚化を備えたビジネス向けの形式で返されます。
• アクセス制御により、ユーザーは表示を許可されたデータのみをクエリできるようになります
• クエリ キャッシュにより、データベースの負荷が軽減され、一般的な質問に対する応答時間が短縮されます。
• Odoo、PostgreSQL、MySQL、SQL Server、BigQuery、Snowflake との統合はネイティブです

---

自然言語から SQL への変換の問題

自然言語を SQL に翻訳するのは、一見すると難しいです。 「質問するだけで答えが得られる」という見かけの単純さには、その実装が運用環境で使用できるか、イライラするデモであるかを決定するいくつかの難しい問題が隠されています。

問題 1: 用語のマッピング。 ビジネス ユーザーは「収益」と言いますが、それは invoice_total フィールド、order_amount フィールド、または payment_received フィールドのいずれですか? 「顧客」とは、accounts テーブル、contacts テーブル、または両方を結合したビューを意味する場合があります。ビジネス用語を技術スキーマにマッピングするセマンティック レイヤーがなければ、LLM は推測する必要があり、多くの場合、間違った推測をします。

問題 2: スキーマの複雑さ エンタープライズ データベースには数百または数千のテーブルがあります。 「今四半期の地域別の売上実績」に関する質問には、6 ～ 8 個のテーブルに参加する必要がある場合があります。 LLM には正しい結合を生成するために十分なスキーマ コンテキストが必要ですが、すべてのプロンプトでスキーマ全体を送信するのは非効率的でコストがかかります。

問題 3: あいまいさの解決。 「上位の顧客を表示してください」 — どの指標で上位ですか?どの時期ですか？ 「トップ」にしきい値はありますか?あいまいさを処理しない自然言語クエリ システムは、推測する (そして多くの場合間違っている) か、説明を求める (ユーザーはイライラする) かのどちらかです。

問題 4: 正確性の検証。 生成された SQL が正しいことを単に信頼することはできません。構文検証 (実行できるか?)、意味検証 (意図した質問に答えられるか?)、結果検証 (結果は妥当に見えるか?) の検証が必要です。

問題 5: セキュリティ。 自然言語入力をデータベースに直接渡すことはできません。生成された SQL は、実行前にパラメータ化、検証、およびアクセス制御する必要があります。そうしないと、ユーザーが「show me sales where name = '; DROP TABLE sales;'」と尋ねると、実際の損害が発生する可能性があります。

OpenClaw の NL クエリ アーキテクチャは、5 つの問題すべてに対処します。

---

アーキテクチャ: OpenClaw NL クエリの仕組み

セマンティック層

セマンティック レイヤーは、運用品質の NL クエリの基盤です。これは、エージェントがユーザー言語をデータベース オブジェクトに翻訳するために使用するビジネス概念の構造化された定義です。

セマンティック レイヤー コンポーネント:

ビジネスコンセプトの定義: 「収益」 = SUM(invoice_lines.unit_price * invoice_lines.quantity) WHERE invoice.state = 'posted'。 「アクティブな顧客」 = accounts WHERE account_type = 'customer' AND last_transaction_date > NOW() - INTERVAL '12 months'。

用語の別名: 複数の用語を同じ概念にマッピングします。 「収益」、「売上」、「売上高」、「収入」はすべて収益計算にマッピングされます。 「クライアント」、「顧客」、「アカウント」、「購入者」はすべてアカウント テーブルにマップされます。

関係の定義: テーブルの関係と、どの結合がどの質問に対して正しいかを文書化します。 「顧客に販売される製品」には、注文と注文明細行を介した特定の結合パスが必要です。これをセマンティック レイヤーで一度文書化します。

指標の定義: 計算された指標 (粗利益率、顧客獲得コスト、売上未払い日数) を正確な式で事前定義します。ユーザーはこれらのメトリクスを名前で要求できます。

アクセス制御の定義: どのユーザー ロールがどのテーブル、列、行のサブセットにアクセスできるかを定義します。地域の営業マネージャーは、自分の地域のデータのみをクエリできます。

クエリ生成パイプライン

ユーザーが自然言語の質問を送信すると、OpenClaw はそれを複数ステップのパイプラインを通じて処理します。

ステップ 1 — 意図の分類: 質問のタイプ (検索、集計、傾向分析、比較、ランキング) を分類し、関係する主要なエンティティを特定します。

ステップ 2 — エンティティの抽出: 質問で言及されたビジネス エンティティ (製品、顧客、期間、地域) を特定し、それらをセマンティック レイヤーの概念にマッピングします。

ステップ 3 — 曖昧さの検出: 曖昧な用語を特定し、コンテキスト (前の会話ターン、ユーザー プロフィール) を使用して解決するか、明確な質問を生成します。

ステップ 4 — スキーマの選択: 質問に答えるために必要なデータベース スキーマの関連サブセットを選択します。これにより、無関係なスキーマで LLM コンテキストが圧倒されるのを防ぎます。

ステップ 5 — SQL 生成: 解決されたエンティティ、セマンティック レイヤー マッピング、選択したスキーマを使用して SQL を生成します。出力はパラメータ化された SQL であり、文字列補間は行われません。

ステップ 6 — 検証: 生成された SQL を構文的に検証します。質問に答えていることを意味的に検証します。行数の推定値を確認して、予期しない結果を返すクエリを検出します。

ステップ 7 — アクセス制御の実施: クエリを実行しているユーザーに、参照されているすべてのテーブルと列への読み取りアクセス権があることを確認します。ユーザーのアクセス プロファイルに基づいて、行レベルのセキュリティ フィルターを自動的に追加します。

ステップ 8 — 実行と結果のフォーマット: 検証されたクエリを実行します。ビジネスで読みやすいように結果をフォーマットします。人間が判読できる列名、適切な数値フォーマット、日付フォーマット、および数値の意味に関するコンテキスト。

ステップ 9 — 自然言語による回答: 結果の自然言語による要約を生成します。 「貴社の第 1 四半期の収益は 420 万ドルで、昨年の第 1 四半期から 23% 増加しました。この成長は主にエンタープライズ部門によって牽引されました (+41%)。」

---

サポートされるクエリの複雑さ

OpenClaw の NL クエリ機能は、SQL の複雑さの範囲全体を処理します。

簡単な検索:

• 「製品 SKU-1234 の現在の価格はいくらですか?」
• 「Acme Corp の連絡先情報を見せて」

集計:

• 「前四半期の製品カテゴリ別の総収益はいくらでしたか?」
• 「今年は毎月何人の新規顧客を獲得できましたか?」

複数テーブル結合:

• 「過去 6 か月間に製品 A を購入したが、製品 B は購入しなかった顧客は誰ですか?」
• 「顧客の与信限度額が請求額未満である未処理の請求書をすべて表示します」

時系列分析:

• 「過去 24 か月の月次収益を 3 か月の移動平均とともに表示します」
• 「2024 年第 1 四半期と 2025 年第 1 四半期の営業担当者別の販売実績を比較」

ランキングと上位 N クエリ:

• 「生涯価値で上位 20 人の顧客を表示してください」
• 「返品率が最も高い 10 製品はどれですか?」

コホート分析:

• 「2024 年第 1 四半期に獲得した顧客のうち、現在もアクティブな顧客の割合は何パーセントですか?」
• 「さまざまなチャネルを通じて獲得した顧客の平均顧客生涯価値はどれくらいですか?」

複雑なビジネス上の質問:

• 「注文頻度の低下に基づいて、どの顧客が解約リスクにさらされていますか?」
• 「よく一緒に購入される商品の組み合わせはどれですか?」

---

ビジネス ユーザー エクスペリエンス

ビジネス ユーザー エクスペリエンスは意図的にシンプルになっています。ユーザーは、チャット インターフェイスまたは既存のツールに埋め込まれたクエリ ウィジェットを通じて対話します。

会話インターフェイス:

ユーザー: 「営業担当者の今四半期の売上をノルマと比較して表示してください」

エージェント: 「2026 年第 1 四半期の営業担当者のノルマ達成状況は次のとおりです。

サラとマリアは順調に進んでいます。ジェームズは残り 3 週間でノルマに 128,500 ドル未達です。ジェームズのパイプラインを見て、彼がその差を縮めることができるかどうかを評価したいですか?」

フォローアップの質問: ユーザーは状況に応じてフォローアップの質問をすることができます。 「ジェームズは最終段階でどのような取引を持っていますか？」 — エージェントは、以前の会話から「ジェームズ」がジェームズ・ウィルソンを指していることを理解しています。

説明: ユーザーは「なぜ?」と尋ねることができます。または「どうやって計算したのですか？」エージェントは計算について説明し、基礎となるデータを示します。

視覚化: 傾向データの場合、エージェントは表の横にグラフを生成します。ユーザーは、「これを棒グラフとして表示」または「これを経時的にプロット」など、特定のグラフの種類をリクエストできます。

---

セキュリティ アーキテクチャ

運用データベースにアクセスするシステムでは、セキュリティについて交渉の余地はありません。 OpenClaw の NL クエリ セキュリティ モデル:

読み取り専用接続: クエリ接続には読み取り専用のデータベース権限があります。エージェントが NL クエリ インターフェイスを通じてデータを変更することは構造的に不可能です。

パラメータ化されたクエリ: エージェントによって生成されるすべての SQL はパラメータ化されます。ユーザーが指定した値が SQL 文字列に連結されることはありません。これにより、アーキテクチャ レベルで SQL インジェクションのリスクが排除されます。

行レベルのセキュリティ: アクセス ポリシーはクエリの生成時に適用されます。地域の営業マネージャーは、すべてのクエリに WHERE region = 'North' が自動的に追加されます。カスタマー サービス エージェントは、自分に割り当てられたアカウントのみを表示できます。

列レベルのアクセス制御: 機密性の高い列 (給与情報、SSN、ペイメント カード データ) は、適切なアクセス権がないロールのクエリ可能なスキーマから除外されます。

クエリ検証: 実行前に、生成されたすべてのクエリは、未承認のテーブル参照、制限された列へのアクセス試行、疑わしいクエリ パターン、およびクエリの複雑さの制限 (偶発的または意図的なリソース枯渇クエリの防止) をチェックするセキュリティ検証ステップを通過します。

監査ログ: すべてのクエリ、誰が質問したか、いつ、どのようなデータが返されたかがログに記録されます。これにより、コンプライアンスのレポートと内部関係者の脅威の検出がサポートされます。

---

ビジネスシステムとの統合

Odoo ERP: OpenClaw は Odoo のデータ モデルと緊密に統合されています。ビジネス用語は Odoo のスキーマに自動的にマッピングされます。「販売注文」、「仕入先請求書」、「製造注文」、「在庫移動」はすべて、適切な Odoo テーブルに正しく解決されます。

PostgreSQL および MySQL: 完全なスキーマ イントロスペクションによる直接接続。セマンティック レイヤーは、ビジネス用語を特定のスキーマにマッピングするために実装中に構成されます。

分析データベース: Snowflake、BigQuery、Redshift、Databricks は、分析データをデータ ウェアハウスに一元管理する組織でサポートされています。これらの環境は、運用データベースには不適切な複雑な分析クエリ (大規模な集計、履歴傾向分析) を処理します。

SQL Server および Oracle: Microsoft または Oracle データ プラットフォームを実行している組織でサポートされます。

複数のデータベース: エージェントは複数のデータベースにわたってクエリを統合でき、データ ウェアハウスを必要とせずに CRM (Salesforce) と ERP (Odoo) からのデータを組み合わせる必要がある質問に答えることができます。

---

実装: セマンティック層の構築

セマンティック層は、NL クエリの品質にとって最も重要な実装成果物です。 ECOSIRE は、構造化されたプロセスを通じてセマンティック レイヤーを構築します。

第 1 ～ 2 週目: 発見

• ビジネス ユーザーにインタビューしてよくある質問を収集します
• 技術スタッフによるデータベース スキーマの監査
• 用語の矛盾と曖昧さを特定する
• 最も一般的なビジネス上の質問 50 個に優先順位を付ける

第 2 ～ 4 週: セマンティック レイヤーの構築

• ビジネスコンセプトのマッピングを定義する
• 正確な数式を使用してメトリクス定義を記述します
• 結合関係を文書化する
• アクセス制御ポリシーを構成する

第 4 ～ 6 週目: テストとキャリブレーション

• セマンティック レイヤーに対して 50 の優先質問をテストします
• 不一致を特定し、セマンティック レイヤーを調整する
• テストをエッジケースをカバーする 200 の質問に拡張
• 明確化の質問に対する信頼度のしきい値を調整する

第 6 ～ 8 週目: ユーザー受け入れテスト

• パイロット ユーザー グループに展開する
• 質問処理の正確さに関するフィードバックを収集する
• 実際のユーザーのクエリからの用語をセマンティック レイヤーに追加します
• 質問の正答率を測定する

---

よくある質問

実際の自然言語から SQL への変換はどの程度正確ですか?

設定されたセマンティック レイヤーのスコープ内の質問の場合、標準的なビジネス質問の精度は通常 88 ～ 95% に達します。非常に複雑なマルチステップの分析質問や、セマンティック レイヤーでカバーされていないスキーマ領域に関する質問の精度は低くなります。実際のユーザーの質問を使用してセマンティック レイヤーが改良されるため、最初の 2 ～ 3 か月で精度が向上します。

エージェントは、開発者が直接実行できる SQL を生成できますか?

はい。エージェントはオプションで、生成された SQL を表示、コピー、または自分で変更したいユーザーに公開できます。これは、生成されたクエリから開始してさらにカスタマイズしたいデータ アナリストにとって特に価値があります。インターフェイスには、自然言語、生成された SQL、および結果がまとめて表示されます。

エージェントが質問を理解していないか、質問があいまいな場合はどうなりますか?

エージェントは推測ではなく明確な質問をします。たとえば、「『収益』という場合、請求された収益 (未払いの請求書を含む) と回収された収益 (受け取った支払い) のどちらを意味しますか?」明確な質問は最小限に抑えられます。エージェントは明確なケースを自動的に解決し、区別が本当に回答に影響を与える場合にのみ質問します。

リアルタイムで回答するにはリソースを大量に消費する質問にはどのように対処すればよいでしょうか?

エージェントは実行前にクエリのコストを見積もります。大規模なテーブルをスキャンしたり、高価な操作を実行したりする質問は、分析データベース (利用可能な場合) にリダイレクトされるか、結果が非​​同期で配信されるバックグラウンド ジョブとしてスケジュールされるか、実行時間と必要な確認に関する警告がユーザーに表示されます。

技術者以外のビジネス ユーザーでも、この機能を使用してレポートを作成できますか?

はい。 NL クエリ インターフェイスでは、結果を Excel にエクスポートし、静的レポートを生成し、スケジュールに従って更新される保存されたクエリを作成できます。ビジネス ユーザーは、開発者の支援なしで自然言語クエリから個人レポートを作成できます。保存したクエリは他のユーザーと共有でき、チームが参照できる一般的なクエリのライブラリを徐々に構築していきます。

サポートされていないデータベースは何ですか?

標準 SQL インターフェイスを持たない独自のデータベースやクローズド データベース (一部の NoSQL データベース、カスタム データ ストア) では、統合のために追加の開発が必要になる場合があります。ドキュメント データベース (MongoDB) とキー/値ストア (Redis) には、リレーショナル データベースとは異なるアプローチが必要です。このような場合、ECOSIRE は SQL ではなく適切なクエリ言語を翻訳するカスタム統合を設計します。

---

次のステップ

自然言語データベース クエリは、ビジネス分析における最も永続的なボトルネックの 1 つである、質問を持つ人とクエリを作成できる人との間のギャップを解消します。 OpenClaw の NL クエリ機能は、強力なセマンティック レイヤーで適切に実装されており、すべてのビジネス ユーザーが自分のデータに直接アクセスできるようになります。

OpenClaw カスタム スキルを探索 して、NL クエリ機能やその他のカスタム スキル オプションについて学習したり、データベース評価をスケジュールして、OpenClaw が特定のデータ スキーマやビジネス上の質問にどのようにマッピングされるかを確認したりできます。