WrenAIとは？自然言語→SQL（Text-to-SQL）をエージェント駆動で回すOSSのGenBI基盤

WrenAI は、AIエージェントに「自然言語の質問」を渡すと、信頼できるSQL・チャート・ダッシュボードを返させるためのオープンソース基盤です。いわゆる Text-to-SQL（自然言語→SQL）を核にしつつ、WrenAI自身はそれを一歩越えて GenBI（Generative BI／生成的BI） と名乗ります。ポイントは、LLMに素のスキーマだけを渡さないこと。業務上の意味・承認済みの定義・過去にうまくいったクエリ・アクセス制御をまとめた「オープンなコンテキスト層」を土台に置き、その上でエージェントに SQLを生成させ、ダッシュボードとしてデプロイさせ、知識をGit管理させる——ここまでを一続きにするのが WrenAI の狙いです。

WrenAI（Canner/WrenAI・GitHubスター16,570・コアはApache-2.0）は、2026年に設計を大きく作り替えました。以前の「Dockerで立てるチャット型BIアプリ」は legacy/v1 に退避し、現行版は CLI とエージェント（Claude Code・Cursor・MCPクライアントなど）から動かす 前提に変わっています。まずは公式のアーキテクチャ図で、全体像を一枚で掴んでおきましょう。読者が知りたい「①結局これで何ができる／②何を解決する／③何を代替できる」の順に、この記事で一次情報から解きほぐします。

RAGそのものの全体像（仕組み・構築・ベクトルDB選定）は RAGとは？仕組み・構築・ベクトルDB選定までの2026年実装マップ にまとめています。本記事はその中でも「構造化データ（データウェアハウス）に対する検索付き生成をどう根拠づけるか」という一角を、WrenAIを題材に一次情報で深掘りする位置づけです。

WrenAIとは — 自然言語→SQLをエージェント駆動で回すGenBI基盤

まず「①結局これで何ができるのか」から答えます。WrenAIを一言で言えば、手元のAIエージェントを『社内データに強いアナリスト』に変えるための土台です。READMEの表現を借りれば、WrenAIは「エージェントが生成（generate）・デプロイ（deploy）・統制（govern）を行うためのオープンソースGenBIエンジン」で、SQLの答え1つから、共有可能なダッシュボードまでを、22以上のデータソースにまたがって扱えるとされています。

ここで効いてくるのが、その下に敷かれた層です。WrenAIは「スキーマが教えてくれないもの」——業務のセマンティクス（意味）、承認済みの定義、良い例、記憶、ガバナンス、さらにドキュメントやWiki、チャットに散らばる非構造の社内知識——を、エージェントが実際に信頼して使える形にまとめます。READMEは「生成的BIは、その土台となる文脈の質以上にはならない（Generative BI is only as good as the context it stands on）」と述べ、Wrenこそがその文脈だと位置づけています。

次に「②何を解決するのか」です。従来、社内データにLLMで質問しようとすると、二択で悩みがちでした。片方は生のエージェントにSQLを書かせるやり方で、素早い代わりに「列名から意味を推測して外す」「承認されていないJOINを勝手に組む」といった、もっともらしいが誤った答えが混じります。もう片方は従来型BIツールで、正確な代わりに定義がそのツールの中に閉じ込められ、エージェントからは触りにくい。WrenAIは、この間を開かれたコンテキスト層で埋めようとします。定義や意味づけをBIツールの外——バージョン管理できるファイル——に置き、エージェントも人も同じ文脈を参照できるようにする、という発想です。

そして「③何を代替できるのか」。WrenAIが置き換えを狙うのは、「一つのベンダーのUIに閉じたセマンティック定義」や、「プロンプトに手で書き込んだ業務ルール」です。README自身も、Wrenが向くのは「エージェントに信頼できるBI（単なるSQLではなく、答え＋ダッシュボード）を作らせたい人」「業務ロジック（定義・区分値・単位・承認済みJOIN）がDBの外にあってエージェントが取り違え続けている人」だと明言し、逆に「1つのCSVから使い捨てのチャートが欲しいだけ」ならWrenは不要だとも書いています。この線引きの率直さは、導入判断の材料として有用です。

2026年の再設計 — Docker版チャットBI（Classic）から現行のエージェント駆動へ

WrenAIを理解するうえで避けて通れないのが、この世代交代です。当サイトが重視する「英語圏では動いているが、日本語ではまだ整理されていない」情報が、まさにここにあります。

READMEの告知によれば、2026年5月7日に Wren Engine が本リポジトリの core/ に統合され、それまで別リポジトリだった Canner/wren-engine はアーカイブされました。同時に、以前のDockerベースのチャット型BI製品（wren-ai-service や wren-ui を docker compose で立ち上げる、あのWrenAI）は 「Wren GenBI Classic」 と名を改め、legacy/v1 ブランチ（タグ v1-final）に保存されています。READMEは、このClassicには新機能もセキュリティ修正も入らないと明記しています（保守されたホスティング版が必要なら商用の「Wren AI Commercial」を案内）。

つまり、現行の main ブランチにあるWrenAIは、アーキテクチャの世代が違う別物と考えるのが正確です。旧世代が「サーバー群を立てて、専用Web UIでチャットする」BIアプリだったのに対し、現行世代は「あなたのエージェントの中に住む」設計に振り切っています。入り口はWeb UIではなく CLI と『スキル』で、Claude Code・Cursor・Cline・Codex といった手元のAIクライアントがWrenを駆動します。

この転換は、単なる作り直しではなく思想の変更です。旧世代では、セマンティック定義や会話履歴がアプリ（とそのDB）の中にありました。現行世代は、それらをGitで管理できる開かれた資産に出す。READMEの言葉では「知識は、バージョン管理でき、証跡（evidence）にリンクされたファイルに宿る——セマンティックモデル（MDL）、会社の定義（instructions.md）、うまくいったことの記憶。レビュー可能で、Gitフレンドリーで、誰か他人のUCの中に閉じ込められない」。“Never locked inside someone else’s UI” という一節は、この世代交代の要約と言えます。

コンテキスト層（MDL・記憶・ガバナンス）がText-to-SQLの精度を決める

この記事の技術的な核が、「なぜコンテキスト層があるとSQLが当たるのか」です。当サイトの読者が一番知りたい「WrenAIは結局何を解決するのか」に、正面から答える章でもあります。

生のLLMエージェントに「今四半期の売上トップ10顧客は？」と聞くと、エージェントはテーブル定義（スキーマ）を頼りにSQLを組み立てます。ところが実務では、revenue が税抜きか税込みか、active の定義は何か、顧客と注文を結ぶ承認済みのJOINはどれか——といった知識は、スキーマには書かれていません。結果、エージェントは推測で埋め、もっともらしいが微妙に間違ったSQLを返します。WrenAIはこの隙間を、3種類の文脈で埋めます。

1つ目：MDL（Modeling Definition Language）＝意味の層。 MDLは、テーブルの生スキーマの上に「業務としての意味」を重ねる定義です。READMEの「What’s Included」によれば、MDLは モデル・列・関係（relationships）・ビュー・キューブ（cubes）・メトリクス（metrics）、そして 行レベル／列レベルのアクセス制御（RLAC／CLAC） を表現します。つまり「この列は売上（税抜き）」「顧客と注文はこの関係で結ぶ」「この部署はこの行しか見えない」といったルールを、エージェントが読める形で持たせられます。エージェントはSQLを組む前にこのMDLを取りにいくため、推測の余地が減ります。

2つ目：記憶（Memory）＝過去の層。 アーキテクチャ図では、コンテキスト層の中に 「Memory：LanceDB schema index + NL-SQL recall」 が描かれています。READMEの「What’s Included」も、業務の意味を instructions.md や queries.yml としてバージョン管理しつつ、ローカルの LanceDB 記憶インデックス（ハイブリッド検索）で想起（recall）すると説明します。これは、過去にうまくいった質問→SQLの対応を検索で引き当て、新しい質問の下敷きにする仕組みです。ここが、本記事をRAG（検索拡張生成）の文脈で扱う理由でもあります。WrenAIは、構造化データに対する生成を「スキーマの検索」と「過去クエリの検索」で根拠づける——ベクトル検索の使い所としては、ドキュメントRAGとは別レイヤーの応用と言えます。LanceDBのようなベクトル/ハイブリッド検索の土台を選ぶ観点は、ベクトルデータベース比較2026の記事も参考になります。

3つ目：ガバナンス（Governed access）＝統制の層。 アーキ図の3本目の柱は「列レベルの可視性（column-level visibility）」です。READMEは統制実行の要素として 関数（functions）・dry-plan・行数制限・アクセス制御 を挙げます。中でも dry-plan（実行前の計画検証） は重要で、エージェントが組んだSQLを実際に走らせる前に妥当性を検査し、構造化されたエラー（ヒント付き）を返す、とされています。人間のアナリストが「まずEXPLAINで確かめる」のに近い安全弁を、エージェントのループに組み込む発想です。

この3層が、質問から答えに至る1本の流れとしてどう働くのかを、模式的に示すと次のようになります（READMEのQuickstart記述に基づく概念図で、内部実装の詳細は公式ドキュメントを参照）。

重要なのは、この流れの多くが READMEとアーキテクチャ図が説明する設計であり、編集部が実機で走らせて検証したものではない点です（本記事は一次情報の整理に徹し、実行検証は行っていません）。また、README の「What’s next」には value profiling・rich retrieval・構造化エラー・golden evalランナー などが「今後」の項目として並んでおり、すべてが現時点で完成しているわけではないことも、READMEに沿って正確に押さえておきます。

GenBIの3拍子 — Generate（生成）・Deploy（デプロイ）・Know（知識化）

WrenAIが「Text-to-SQLではなくGenBI」と名乗る根拠が、この3拍子です。順に、READMEの記述に沿って何が起きるのかを見ます。

Generate（生成）。 エージェントは、業務の質問をガバンドなSQLとチャートに変えます。前章のとおり、スキーマ対応の検索・MDLプランニング・dry-plan検証・構造化エラーが働き、「自信満々に間違える」代わりに正しさを保とうとします。ここは従来のText-to-SQLと重なる部分ですが、MDLと記憶で根拠づける点が差分です。

Deploy（デプロイ）。 WrenAIの個性が強く出るのがここです。READMEは、任意の答えを wren-core-wasm（WebAssembly）で動くブラウザ完結のダッシュボードに変え、自分のVercelやCloudflare Pagesアカウントへ1コマンドでデプロイして、共有可能なURLを返す、と説明します。BIツールのサーバーにデータやダッシュボードを預けるのではなく、あなたのインフラに配るという形です。ダッシュボードのロジックがWASMでブラウザ側に載るため、配布のハードルが低い、という設計意図が読み取れます。

Know（知識化）。 3拍子の締めが、生成の正しさを支える知識をファイルとして残すことです。セマンティックモデル（MDL）、会社の定義（instructions.md）、うまくいったことの記憶——これらがレビュー可能・Gitフレンドリーな形で蓄積され、次の生成をさらに賢くします。READMEの「Fast at first. Deep when you need it.（最初は速く、必要なときに深く）」という表現が、この積み上げ型の価値観を言い当てています。

動かし方 — CLIとエージェントで進めるワークフロー（READMEの手順）

ここからは「どう動かすのか」を、READMEのQuickstartに沿って紹介します（コマンドは公式READMEの記載どおり。実行結果は環境依存のため、ここでは出力の再現は載せません）。WrenAIはエージェント駆動が前提で、人がコマンドを叩き続けるのではなく、エージェントにワークフローを進めさせる設計になっています。

まず、CLIを入れます。コアには DuckDB が同梱され、データソースや記憶機能は「extras」で足す形です。

# コアCLI（DuckDB同梱）
pip install wrenai

# データソースや記憶のextrasを必要に応じて追加
pip install "wrenai[postgres,memory]"

次に、手元のAIクライアント向けに発見用スタブ（スキル）を入れます。READMEによれば、このスタブは約50行で、Claude Code・Cursor・Cline・Codex などを自動検出し、エージェントに「wren skills get <name> でワークフローガイドを取りにいく」「wren ask "<質問>" --guided|--direct で質問を整形する」ことを教えます。ガイドの実体はCLIの中にありインストール版に常に一致するため、情報が古くなりにくい、という設計です。

# AIクライアントを自動検出してスキルを追加
npx skills add Canner/WrenAI

あとは、プロジェクトのディレクトリでエージェントに話しかけると、エージェントが対応するワークフローガイドを取得して進めます。READMEが挙げる代表的なコマンドは次のとおりです。

# 初期セットアップ（プロジェクト作成＋最初のクエリ）
wren skills get onboarding
# 業務文脈を足す（MDL・instructions・記憶を書く）
wren skills get enrich-context
# ダッシュボードを組んでデプロイ
wren skills get genbi

# 日々の利用
wren query --sql '...'            # MDLセマンティック層を通してクエリ
wren ask "<質問>" --guided        # 弱めのエージェント向けに質問を整形
wren ask "<質問>" --direct        # 強めのエージェント向けに質問を整形

READMEは、自前のDBがなくても バンドルされたサンプルデータセット jaffle_shop を使えば、実際のウェアハウスに対して数分でエンドツーエンドを試せる、としています。「まずは軽く、必要になったら深く」という導入曲線が、スキル方式に落とし込まれているのが特徴です。なお、wren ask の --guided／--direct は、質問を受け取るエージェントの賢さに合わせてプロンプトの形を変えるためのフラグ、と説明されています。

他のText-to-SQL／BIツールとの違い — Vanna・Dataherald・DB-GPT・従来型BI

WrenAIの立ち位置を、隣接するOSS・アプローチと並べて整理します。優劣ではなく、守備範囲とアプローチの違いとして読んでください。各ツールの内部仕様までは本記事で実測していないため、他ツールの特徴は各プロジェクトの公表内容に基づく「〜とされる」表現に留めます（スター数・ライセンスはGitHub APIでの実測値・2026年7月23日時点）。

この並びから見える WrenAI の性格は、「Text-to-SQLの正確さ」を出発点にしつつ、その上に『セマンティック層』と『デプロイまでのGenBI』を積む、という統合志向です。VannaやDataheraldが「自然言語→SQL」という一点で研ぎ澄まされたツールだとすれば、WrenAIはセマンティックレイヤー（dbtのセマンティック層やCubeのような発想）とBIのダッシュボード化を、エージェント前提でひとまとめにする方向に広げています。逆に言えば、シンプルに『SQLだけ欲しい』用途では、より軽量なText-to-SQLライブラリのほうが噛み合う場面もあるはずです。ここは要件次第で、README自身も「使い捨てチャートだけならWrenは不要」と率直に線を引いています。

なお、WrenAIのメモリ層のようにエージェントの状態や記憶を検索で引くという発想は、単体のデータベース製品としても各所で試みられています。エージェント向けの検索・状態ストアという観点では、SeekDBの実機検証記事も、レイヤーの違いを掴むのに役立ちます。ドキュメント側のRAG（非構造テキストの検索拡張生成）については、知識グラフ型のLightRAGの解説と読み比べると、「構造化データのRAG」対「非構造テキストのRAG」という切り口が立体的に見えてきます。

どんなチームに向くか — 成熟度・ロードマップ・ライセンスの注意点

最後に、導入判断のための現実的なチェックポイントを、README・LICENSE・実測値から整理します。

向いているチーム。 README自身の言葉を借りれば、WrenAIが噛み合うのは次のような状況です。AIエージェントに、単なるSQLではなく信頼できるBI（答え＋ダッシュボード）を作らせたい。業務ロジック（定義・区分値・単位・承認済みJOIN）がDBの外にあって、エージェントが取り違え続けている。文脈を、ベンダーのUIに閉じ込めず、開かれた・レビュー可能な・バージョン管理された形で持ちたい。すでにClaude CodeやCursor、MCPクライアントを日常的に使っている開発チームなら、既存のワークフローに載せやすい設計になっています。

成熟度の見立て。 ポジティブな指標として、開発は活発です。Wren Engine のコア統合は2026年5月、最新リリースは wren-v0.13.1（2026-07-21）、直近のコミットも2026年7月と、動いているプロジェクトです。一方で、現行アーキテクチャ自体が2026年に再設計されたばかりであり、README の「What’s next」には 監査ログ・レート制限・承認ワークフロー・データフロー検査・golden evalランナー・rich retrieval などが「今後」として並びます。つまり、統制（ガバナンス）まわりの一部は発展途上です。PoCやエージェント開発の基盤としては十分実用的でも、厳密な統制が要る本番では、必要な機能が現時点で揃っているかを自環境で確認するのが安全です。

「まず試す」なら。 最小の入り口は、pip install wrenai でCLIを入れ、npx skills add Canner/WrenAI でお使いのAIクライアントにスキルを足し、サンプルデータセット jaffle_shop に対してエージェントに質問させてみることです。ここまでなら自前DBも不要で、現行版の「エージェント駆動でSQLとダッシュボードが出てくる」感触を、READMEの手順どおりに確かめられます。そのうえで、自社のセマンティクスをMDLと instructions.md に書き起こす価値があるか——それが、WrenAIを本採用するかどうかの分かれ目になるでしょう。

よくある質問

WrenAIについて、検索・導入検討でよく挙がる疑問を、READMEとLICENSE、実測値に基づいて整理します（詳細は各回答のとおり）。設計や挙動に関する記述は、断りのない限り公式READMEおよびアーキテクチャ図に基づくもので、実機検証を経たものではありません。

参照ソース

・Canner/WrenAI（公式リポジトリ） — README・LICENSE・アーキテクチャ図・リリース情報の一次ソース。本記事のスター数（16,570）・最新リリース（wren-v0.13.1）・直近コミットはいずれも2026年7月23日時点のGitHub API実測値。
・WrenAI 公式ドキュメント（docs.getwren.ai/oss） — Quickstart・GenBIアプリの構築とデプロイ・Concepts（コンテキスト/MDL/記憶）・データソース接続・Agent SDKの一次資料。
・The missing context layer for AI agents over business data（公式ビジョン記事） — WrenAIが「コンテキスト層」を掲げる背景。
・LICENSE（マルチライセンス：Apache-2.0／CC BY 4.0／AGPL-3.0） — 各パスの対応表と商標の扱いの一次ソース。