WrenAI を採用する前に読む: MDL セマンティック層とエージェント駆動型 text-to-SQL の実際
GenBI (Generative BI) for AI agents, an open-source, governed text-to-SQL through an open context layer that turns natural-language questions into trusted dashboards, charts, and SQL across 20+ data sources, such as BigQuery, Snowflake, PostgreSQL, ClickHouse, Amazon Redshift, Databricks and more.
ひと目でわかる
- これは何？
- WrenAI は AI エージェントに業務文脈を与えるオープンなコンテキスト層と MDL セマンティック層を提供し、ガバナンスされた text-to-SQL とダッシュボード生成を狙う。本稿は README とリポジトリ情報から確認できる範囲で、その仕組み、導入手順、制約、代替手段との違いを整理する。
- 誰に向いている？
- 採用を検討すべきなのは、業務上の定義や承認済みの結合条件がデータベースの外にあり、既存の AI エージェントにそれを参照させたいチームである。逆に、単一 CSV から一度だけグラフが欲しい場合や、ガバナンスなしでエージェントに SQL を書かせて問題ない場合は、この構成は過剰になる。
- 商用利用できる？
- まず確認が必要です。このリポジトリのライセンスは自動分類の対象外なので、商用利用の前に LICENSE ファイルを読んでください。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
WrenAI が埋めようとしている「スキーマの外側」の空白
LLM エージェントに SQL を書かせると、構文は正しいが業務上は誤った問い合わせが返ってくる。README はこの原因をスキーマ情報の不足ではなく、業務上の意味、承認された定義、列挙値、単位、承認済みの結合条件といった「スキーマには無い情報」の欠如として位置づけている。WrenAI が対象とするのはこの層で、データベースの構造ではなく、データベースの外側に散在する業務知識をエージェントが参照できる形にまとめる。想定読者は、Claude Code や Cursor、MCP 経由で既にエージェントを業務データに向けているが、生成される SQL の正しさをレビューする手段を持たないチームである。ドキュメント、Wiki、チャットに埋もれた非構造化知識も同じコンテキスト層に載せる、というのが README の主張の中心にある。
MDL とドライプラン検証: 正しさをプロンプトではなくプリミティブに置く
README が示す処理の流れは、スキーマ認識の検索、MDL による計画、ドライプラン検証、構造化エラーという順序である。MDL はセマンティック層の実体で、業務上の意味や承認済み定義、実績のある問い合わせ例をファイルとして保持する。instructions.md は業務定義を記述するファイルとして README に挙げられており、これらは Git で差分を取れる形で管理される。エージェントが生成した SQL はそのまま実行されるのではなく、ドライプラン検証と行数制限を通り、失敗時にはヒント付きの構造化エラーが返る。ここで注目したいのは、正しさの担保をプロンプトの工夫ではなく、検証・制限・エラー形式という実行時の仕組みに寄せている設計である。エージェント側はオーケストレーションに専念し、判断の根拠はエージェントの推論トレースに残る、という分担になっている。
生成した回答をブラウザ側ダッシュボードとして配備する
WrenAI の特徴は text-to-SQL で止まらない点にある。README によれば、生成した回答は wren-core-wasm を用いたブラウザ側ダッシュボードに変換でき、自分の Vercel または Cloudflare Pages アカウントへコマンド一つで配備できるとされている。サーバ側でクエリを実行して描画する一般的な BI ツールとは異なり、WASM をブラウザで動かす前提の構成である。この設計は配備先の選択肢を広げる一方、ブラウザに渡せるデータの範囲やクエリの複雑さに制約が生じる可能性がある。README にはこの制約の具体的な線引きまでは書かれていないため、採用判断の前に docs.getwren.ai の SDK ページで確認する必要がある。
導入手順: CLI とクライアント側スタブの二段構え
README の Quickstart は、WrenAI がエージェント駆動を前提としていることを明示している。最初の手順は CLI のインストールである。pip install wrenai で DuckDB を含むコアが入り、データソース別の拡張とメモリ機能は pip install "wrenai[postgres,memory]" のように extras で追加する。次に、利用する AI クライアント向けの「1 ファイルのディスカバリ用スタブ」をインストールする。ワークフローのガイドは CLI 内に同梱され、要求時に配信されるため、インストールされたバージョンと内容が一致する仕組みになっている。この点は、外部ドキュメントを参照するツールでよく起きるバージョンずれを避ける設計として評価できる。中国本土のユーザー向けには pip install が遅い場合の回避策が README に記載されているが、本稿で参照した範囲ではその具体的手順の全文は確認できていない。
OSS と Cloud の境界、そして LICENSE 表記の不一致
README は行・列レベルのセキュリティとアクセス制御を Cloud または self-hosted 版の機能として明記しており、OSS 版には含まれない。ガバナンスされた実行をうたう製品としては、この境界が導入判断の分かれ目になる。もう一点、リポジトリのメタデータではライセンスが NOASSERTION と表示される一方、README のバッジと本文は Apache-2.0 と記載している。これは GitHub がライセンスファイルを自動判定できなかったことを示すだけで、法的な解釈は専門家の領域だが、採用前に LICENSE ファイルの実際の条項を直接確認すべき理由にはなる。ライセンスの表示と実際の条項が一致しない状態は、社内の法務レビューで必ず止まる箇所である。
向かないケースと、素のセマンティック層との違い
README 自身が「Skip Wren if」として、単一 CSV から一度だけグラフが欲しい場合や、ガバナンスなしでエージェントに SQL を推測させて構わない場合を挙げている。これは妥当な線引きである。比較対象として README が挙げる「bare semantic layer」は、スキーマ情報のみを定義として持ち、ドキュメントや Wiki にある非スキーマ知識を扱わない。WrenAI はそこに業務定義、例、メモリ、非構造化知識を足し、さらにドライプラン検証と行数制限という実行時のガードレールを加える。伝統的な BI ツールとの違いは、ダッシュボード生成が手動かエージェント駆動かという点にある。ただし、いずれの比較も README の主張であり、本稿では実測していない。
メンテナンス負荷とリポジトリ統合の経緯
2026-05-07 付の告知で Wren Engine が core/ 配下に統合され、旧 Canner/wren-engine リポジトリはアーカイブされた。旧来の Docker ベースのチャット型 BI 製品は legacy/v1 ブランチに tag v1-final として保存され、Wren GenBI Classic と呼称される。リリースは wren-v0.14.0 が 2026-09-08、wren-v0.13.4 と wren-pydantic-v0.3.0 が 2026-09-02 と、コアと周辺パッケージが並行して更新されている。追跡すべき対象が CLI、core、pydantic 連携、WASM SDK に分かれており、バージョンの組み合わせを意識しないと不整合が起きやすい。MDL や instructions.md を Git で管理する設計は差分レビューを可能にするが、その分だけ定義ファイルの更新を継続する運用コストが発生する。
編集部の結論
採用を検討すべきなのは、業務上の定義や承認済みの結合条件がデータベースの外にあり、既存の AI エージェントにそれを参照させたいチームである。逆に、単一 CSV から一度だけグラフが欲しい場合や、ガバナンスなしでエージェントに SQL を書かせて問題ない場合は、この構成は過剰になる。導入前に確認すべきは、リポジトリの LICENSE が Apache-2.0 として認識されていない点の実際の条項、core/ 配下に統合された Wren Engine と CLI のバージョン整合、そして行・列レベルのセキュリティが OSS に含まれないという境界である。
コミュニティノート