MotherDuckはどのようにDuckDBをAI agentの実行基盤へ広げたか

BigQueryを作った経験からの出発点

MotherDuckの起点は、Google BigQueryのfounding engineerだったJordan TiganiがDuckDBを見たことだった。

公式のorigin storyによれば、Jordan Tiganiは「Wow, this is amazing! someone should really build a serverless version」と考え、続けて「if someone is going to do it, why not me?」と自問した。出典

BigQueryで大規模データを扱ってきた人物が、すべてのデータが巨大とは限らない現実に向き合った。

Jordan Tiganiは、データ基盤の価値を最大規模への対応だけでなく、普通のチームがデータを理解しやすくすることへ置き直した。出典

DuckDB Labsとの二人三脚

Jordan Tiganiは、DuckDBを作ったHannes MühleisenとMark Raasveldtに会い、DuckDBをcloud serviceとして育てる協力関係を結んだ。

MotherDuckの公式説明では、DuckLabsはcore technologyとanalytics databaseに集中し、MotherDuckは商用cloud offeringを担う役割分担になった。出典

2022年6月にはSeattleで初期チームが集まり、EasyQueryというコードネームで「データを理解しやすくする」プロダクトを考えた。

ローカルで動くDuckDBを捨てず、必要なときだけcloudへ広げるという方向が、後の製品体験の土台になった。出典

Waitlistからpublic launchへ

2023年6月にMotherDuckはwaitlist付きで発表され、同年9月のpublic launch記事では2,000 usersがqueryし、100人超からfeedbackを受けたと報告した。

ここでの転機は、巨大warehouseの代替を掲げるだけでなく、data analysts、engineers、scientistsがすぐ試せるサービスとして入口を広げたことだった。出典

同じ発表で、Series Bを含む累計調達額$100Mも示された。

資金は単なる規模競争ではなく、DuckDBの軽量な実行モデルをcloud warehouse、data lake query engine、data appsへ展開するための余力になったと読める。出典

共有warehouseから個別のDucklingへ

成長の次の課題は、利用者が増えたときの競合だった。

MotherDuckはHypertenancyでユーザー・顧客・AI agentごとに独立したDuckling computeを割り当て、idle時にはscale to zeroできるモデルを打ち出した。出典

その考え方は、全員を一つの大きな箱に詰めるwarehouseから、利用者ごとに性能とコストを見えるようにするanalytics infrastructureへの転換である。

MotherDuckはSQL warehouseを、データを置く場所から利用者の問いに応答する実行面へ変えようとしている。

AI agentがSQLを実行する場所へ

現在のMotherDuckはMCP ServerでClaude、ChatGPT、Gemini、Cursorなどからデータをqueryでき、回答にtraceable SQLを返す。

Divesは自然言語からinteractive visualizationを作り、FlightsはPython pipelineをスケジュールする。出典 出典

Big Dataへの反省から始まった道のりは、AIがデータへ質問し、SQLを検証し、結果を可視化し、pipelineまで動かす時代の基盤へ接続した。

MotherDuckの現在地は、巨大さを競うwarehouseではなく、ローカルの速さとcloudの共有性を必要な単位だけ組み合わせる選択にある。

従来のcloud data warehouseは、データ量に合わせた巨大な共有クラスタと運用設定を前提にしてきた。

MotherDuckはDuckDBの軽量さをcloudへ持ち込み、ローカルとcloudを同じSQLで行き来したいdata team、customer-facing analyticsを組み込みたい開発者、データを自然言語で探索するAI agentに焦点を当てる。出典

価値の核は「誰でも分析できる」だけではない。

ユーザーごとのDuckling computeでノイジーネイバーを避け、AIの回答には実行SQLを残す。

導入企業が個別のレポート待ちや共有warehouseの競合から抜けたいとき、性能・説明可能性・運用単純化が同時に刺さる。出典 出典

防御力は、DuckDBというOSS engineそのものを囲い込むことではなく、ローカル開発、cloud catalog、per-user compute、MCP・Dives・Flightsを一続きにした運用面にある。

DuckDB ecosystemとの接続が広がるほど、データチームは同じworkflowを継続しやすい。出典 出典

直接のnetwork effectは強くない。

ある顧客のデータが別顧客の価値を自動的に増やすサービスではないからだ。

一方、DuckDBのOSS community、BI・driver・integration ecosystem、AI client対応が増えるほど、MotherDuckへ接続する選択肢は増える。

これはデータ共有ではなく、周辺ツールによる間接的なdistribution効果である。出典 出典

主対象は、DuckDBやPythonを使いながら、共有warehouseの待ち時間・クラスタ運用・顧客別分析の分離に困るdata teamとproduct engineer。

AI agentに社内データを読ませたいが、black-box回答ではなくSQLを検証したい組織にも向く。出典 出典

逆に、全用途で巨大分散warehouseを必要とするチームや、厳格なデータ経路を自社内だけに閉じたい組織は要件確認が必要だと考えられる。

第一に、DuckDBの既存ecosystemとローカル開発体験を捨てずに、共有・権限・serverless運用を追加した。

新しい専用言語ではなく、DuckDB SQL・Python・既存BIから入れるため移行の摩擦が低い。出典

第二に、warehouseをデータチームだけの道具にせず、MCP Server、Dives、Flightsへ広げた。

AI agentがSQLを生成し、可視化やpipelineまで扱える設計は、分析基盤をアプリの操作面へ近づける。出典 出典

MotherDuckの価値はDuckDBとの互換性、データ配置、クエリ特性に左右される。

巨大な分散処理や高い同時実行を常に求める組織では、single-node起点の設計が要件に合わない可能性がある。出典

またAI agentのread-write操作は、権限、リージョン、結果の検証を運用側で設計しなければならない。

MCP docsも結果がremote serverを通過する点を説明しており、データレジデンシーや予期しないusage costは導入前の確認事項になる。出典 出典

初期はDuckDBの開発者・data practitionerに、free Lite plan、docs、blog、startup programでセルフサーブ導入を促す。

2023年のpublic launch時点で2,000 usersと100人超のfeedbackを得たと発表し、製品を利用者との反復で広げた。出典

現在はBusinessの$250/org/month + usageとEnterpriseのcustom pricingで、RBAC、SLA、PrivateLink、isolated computeを必要とする顧客へ拡張する。

MCPとAI-native analyticsは新しい入口だが、query cost・security・residencyの説明責任も増やす。出典 出典

主要チャネル: open_source_ecosystem, developer_relations, content, startup_program, enterprise_sales, partner_ecosystem

新しいdata platformを作るとき、既存の分析エンジンを置き換えることだけが差別化ではない。

MotherDuckはDuckDBのローカル体験を入口に、共有・権限・per-user compute・AI接続を段階的に重ねた。出典

PdMが持ち帰るべきなのは、性能訴求を抽象的に終わらせず、誰の待ち時間を何秒減らし、誰のコストをどう帰属させ、AIの答えをどう検証するかまでプロダクト単位に分解することだと考えられる。

日本企業で展開するなら、既存のPostgres、S3、BI、社内Python workflowを残したまま、部門ごとの分析環境を小さく始められる点を前面に出せる。

まずは経営ダッシュボードや顧客向けanalyticsなど、共有クラスタの競合が痛い用途に限定して導入するのが現実的だろう。出典

AI agent連携では、個人情報・越境処理・監査ログ・read-only既定を法務と先に定義する。

MCPのリージョンと結果経路を確認し、生成SQLのreviewを業務ルールに組み込むべきだと考える。出典 出典