MotherDuck、基盤技術を提供するスタートアップ Tower を買収
本文の状態
日本語全文を表示中
詳細モードで約13分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
The New Stack AI
データウェアハウス企業 MotherDuck は、自社の AI ベースデータパイプラインを支えていたスタートアップ Tower を買収し、同社初の M&A を実行して技術とチームを統合した。
AI深層分析を開く2026年8月25日 22:37
AI深層分析
キーポイント
MotherDuck の初回買収発表
4 年間の歴史で初めてとなる買収として、データインフラスタートアップの Tower とその技術を自社の傘下に取り込んだ。
Tower の技術的特徴と役割
ドイツ発祥の Tower は Python パイプラインをパッケージ化・デプロイ・運用する管理ランタイムを提供し、自然言語でパイプラインを記述して自動生成・実行する「Tower Control」ツールを持つ。
Flights 機能との統合関係
MotherDuck が AI エージェント向けに展開した Python ランタイム機能「Flights」は、実質的に Tower のインフラを基盤としており、同社が買収の決断を下した直接的な要因となった。
買収後の戦略的意図
両社の技術とチームを統合することで、MotherDuck はデータパイプラインの構築・運用を行う AI エージェント領域への参入をさらに強化する方針を示している。
AIの進展による課題認識の変化
AIがデータ移動の問題を解決できるようになったことで、MotherDuckは従来のアプローチを見直す必要が生じた。
重要な引用
"You can rent a feature, but you can't rent a foundation"
"Tower was the key infrastructure underpinning Flights."
"We became their largest customer almost overnight"
"When AI suddenly started to be able to solve data problems, we realized we were thinking about the problem wrong."
編集コメントを表示
編集コメント
データウェアハウス企業が AI エージェントの基盤となるインフラを直接買収する事例は、AI による自動化領域における「プラットフォーム化」の加速を示唆している。特に、開発者が直面する最終工程(Last Mile)の課題解決に特化したスタートアップが買収対象となった点は、実運用レベルでの AI 導入障壁を下すための重要な動きと言える。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。

依存している技術が他社の手にある場合、どうすればよいのか?答えは明白だ。その技術を担うスタートアップを買収することである。データウェアハウス企業の MotherDuck はまさにそうし、すでに自社の AI 構築型データパイプラインを支えていたデータインフラスタートアップ「Tower」を買収した。
この買収は火曜日に発表され、4 年間の歴史において MotherDuck が初めて行った買収となる。これにより Tower の技術とチームが社内に組み込まれ、MotherDuck はデータパイプラインを構築・運用する AI エージェントへの進出をさらに加速させる。
Tower の飛躍
Tower は 2024 年後半、ドイツで創業された。創業者は元 Snowflake エンジニアの Serhii Sokolenko(CEO)と Brad Heller(CTO)だ。彼らの主張はこうだ。「開発者や AI アシスタントがデータパイプラインのコードを書いたとしても、それをパッケージ化し、適切なインフラにデプロイし、認証情報を接続し、運用を維持するのは依然として誰かの仕事である」。Sokolenko は昨年 3 月、The New Stack の取材に対し、これは派手さはないがデータエンジニアリングにおける「最後の 1 マイル」に相当する作業だと語っている。
Tower は本質的に Python パイプライン向けの管理ランタイムだ。コードをパッケージ化し、デプロイし、本番環境で稼働させ続ける。さらに、そのランタイムの上に構築されたツールも提供している。例えばブラウザベースの AI エージェント「Tower Control」では、ユーザーは自然言語で望むパイプラインを記述するだけでよい。
imageTower Control を使えば、ユーザーは自然言語でパイプラインの要件を記述するだけで済みます。
Control はその記述に基づいてコードを生成し、それを Tower アプリとしてデプロイして実行します。これにより、開発者が基盤となるランタイムを手動で設定する必要なく、プロンプトから本番環境までを一貫して処理できる仕組みが実現されています。
imageControl はコードを生成し、Tower アプリとしてデプロイします。
一方の MotherDuck は、オープンソースデータベースである DuckDB を基盤としたサーバーレスデータウェアハウスです。2022 年に設立され、創業者は Google で BigQuery のエンジニアリングリーダーを務めていた Jordan Tigani です。設立以来、同社は約 1 億ドルの資金調達を果たしています。
MotherDuck の当初の訴求点は、速度とローカル計算能力にありました。クエリは DuckDB を介してノートパソコン上で実行可能であり、MotherDuck のクラウド上でも実行できます。あるいは、両方を組み合わせて利用することも可能です。これは、Snowflake や Databricks、BigQuery が採用している「クラウドファースト」モデルとは一線を画すアプローチです。
最近では、この考え方は AI エージェントにも拡張されています。MCP(Model Context Protocol)を活用してエージェントがデータに直接アクセスできるようにしたのです。そして今年 6 月には、Flights という新機能が発表され、より運用寄りの方向へ舵を切りました。Flights は、同じ MCP サーバーを通じて汎用 Python ランタイムを公開する機能で、これによりエージェントはデータパイプラインの作成、実行、スケジュール管理を自在に行えるようになります。
そして驚くべきことに、Tower がこの Flights を支える基盤インフラだったのです。
「一夜にして最大の顧客になりました」
Tower と MotherDuck の関わりは、Flights の登場以前から始まっていました。Tigani 氏によれば、当初 MotherDuck は顧客に対して、データウェアハウスへのデータ取り込みをより容易にするためのサードパーティ製ツールを紹介できないかと探していました。しかし、AI の急速な進展が、同社が解決すべき課題の性質そのものを変えてしまったのです。
「AI が突然、データ問題の解決が可能になったとき、私たちは課題の捉え方を間違っていたことに気づきました」と Tigani 氏は The New Stack に語ります。「Claude は、データの移動を支援するコネクタを書くことで、私たちが取り組んでいた問題を解決できます。しかし、サンドボックス化やジョブスケジューリングについては対応できません。」
そこで MotherDuck は、AI エージェントが生成したコードを安全に実行し、認証情報を管理し、スケジュール通りにジョブを実行できる場所が必要になりました。そして幸運なことに、Tower にはすでにその機能がありました。
「これは私たちの課題を完璧に解決し、Flights の開発を数週間で完了させることができました」と Tigani 氏は付け加えます。
MotherDuck にとって Tower は欠けていた実行層を提供した存在であり、Tower にとってはそれが大きな顧客関係へと発展しました。「一夜にして最大の顧客となり、以来両社のチームは共同で製品を開発し続けています」と Tigani 氏は話しています。
Tower を早期に視野に入れることで、MotherDuck は自社で同様の技術を開発するかどうかを決定する前に、その技術と開発チームの実力をテストする機会を得ました。Tigani 氏によれば、最終的な判断は MotherDuck が望む機能をいかに迅速に顧客に提供できるかにかかっていました。
「自前で開発したくなるのは当然ですが、Tower を試した結果、基盤インフラを安定して動かすために解決すべき課題が山積みであることをすぐに理解しました。そして Tower はまさに私たちが求めていたものでした」と彼は語ります。
結局のところ、Tower が MotherDuck の目指すビジョンの中心に位置するほど、技術を完全に自社で所有する意義は強まりました。MotherDuck 内で作成・スケジュールされたジョブを Tower が実行するようになると、Tigani 氏は主張します、顧客は必然的にそのランタイムのセキュリティ、信頼性、動作に対して MotherDuck を責任ある存在として捉えるようになります。
「私がこれまで関わってきたインフラ企業すべてで再認識した法則があります。機能は借りても、基盤は借りられないのです」と Tigani 氏は言います。「MotherDuck 内のエージェントがジョブを作成してスケジュールした場合、そのジョブを実行するものは私たちの製品です。ロゴが何であれ、それは MotherDuck のものです」
「私がこれまで関わってきたインフラ企業すべてで再認識した法則があります。機能は借りても、基盤は借りられないのです。」
MotherDuck が今後この技術で実現しようとしている事例の一つは、2 月に発表した AI 生成データ可視化機能「Dive」と、Flights を連携させることです。Tower は Flights で実行されるジョブに対して安定した URL を生成できるため、これらのジョブをデータ API として活用し、Dive やその他のフロントエンドから呼び出せるようにします。
Tigani は、ユーザーへのレコメンデーションを表示するアプリケーションの例を挙げています。Dive がそのレコメンデーションを表示するインターフェースを生成し、Flight が作成や変更のリクエストを受け付ける役割を担います。フロントエンドに基盤データに対する広範な書き込み権限を与えるのではなく、Flight によってユーザーが許可される変更内容を制限・検証することが可能です。
「これらを組み合わせれば、リッチなアプリケーションを構築できます」と Tigani は語ります。
Tower の次の章
これらの動きは、Tower の顧客にとって明白な疑問を生みます。スタートアップとしての Tower の売り出しポイントの一つに、「特定のデータプラットフォームに縛られずにランタイムを利用できる」という点がありましたが、今や Tower 自体がそのプラットフォームの一部となりました。
Tower の共同創設者兼 CEO、セルヒー・ソコレンコ氏は、MotherDuck が業界の大手クラウドデータプラットフォームとは異なる種類の「ホーム」を提供すると主張します。彼の考えでは、AI エージェントが登場する以前に確立されたアーキテクチャに合わせて無理やり設計されることなく、Tower はより深く統合されることが可能だと述べています。
「大手クラウドプロバイダーに参入することは、通常、そのレガシーなアーキテクチャに適応することを意味します」とソコレンコ氏は The New Stack に語ります。「しかし、MotherDuck への参加は、データと AI インフラの将来像を共に作り上げていく機会をもたらします。」
ただし、トレードオフも存在します。Tower はデータベースに依存しないことで得られていた広範な互換性の一部を手放し、特定のプラットフォームに特化して構築することに賭けました。これは、多くのシステムを遠巻きにサポートするよりも、より密接な統合によって最終的に優れた体験が生まれるという信念に基づいています。
「Tower の Python による計算リソースを MotherDuck に特化させることで、広範で基本的な接続性を、深くネイティブな実行力へと置き換えています」と同氏は説明します。
ソコレンコ氏の主張では、「ロックイン(囲い込み)」の問題は、次のレイヤーへとシフトします。Tower は MotherDuck とより密接に結びつくことになりますが、MotherDuck 自体が DuckDB を基盤としているため、根本的なデータは依然としてオープンでポータブルなままです。目的は、ランタイム、エージェント、そしてデータウェアハウスを近づけることであって、データを独自システムの中に閉じ込めることではありません。
これが、Tower が MotherDuck のハイブリッド実行モデルに惹かれた理由の一端でもあります。DuckDB を利用すれば、処理をローカルとクラウド間で移動させることが可能であり、これは Tower 自身の方向性と合致しています。
「これは Tower のビジョンに直接合致しており、ビジネスユーザーやエージェントが、ローカルでのデータ探索からクラウド上の本番環境への実行へとシームレスに移行できることを可能にします」と同氏は述べています。
Tower の既存顧客にとって、直近の未来は MotherDuck への移行を意味します。Sokolenko 氏によると、Tower の顧客はすでに MotherDuck と移行経路について協議を進めており、過去に Tower を利用した経験のあるユーザーには、MotherDuck やその広範なエージェント型データ機能の体験を促す招待が行われる見込みです。
Tigani 氏は、MotherDuck が既存の Tower 顧客を「Flights」へ移行させる作業を進めていることを確認しつつ、両製品が完全に同一ではない点にも言及しました。「いくつかの違いがあり、よりシームレスな移行を実現するためにギャップを埋める取り組みを行っています」と彼は述べています。
一方、Tower の技術は MotherDuck 本体により深く統合されていきます。現在、MotherDuck は「Flights」と「Ducklings」の 2 つの独立したサンドボックス型オンデマンドランタイムを提供しています。「Flights」は Tower に支えられており、「Ducklings」はサーバーレスの DuckDB インスタンスです。Tigani 氏によれば、将来的にはこれらを統合し、Ducklings の即座の起動性と、Tower ジョブが提供する堅牢なサンドボックス機能を組み合わせる計画だということです。
エージェント波に乗る
MotherDuck は、データエージェントを単なる質問応答を超えて活用する動きにおいて、決して一人ぼっちではありません。Databricks の「Genie Code」はコードの生成・実行やパイプライン構築、Databricks 内でのデバッグ機能を提供しています。同様に Snowflake も「CoCo」という AI コーディングエージェントを通じて類似の方向へ進んでおり、最新の「Co Automations」では、Snowflake が管理するサンドボックス内で無人のエージェント実行をスケジュールできるようになっています。
詳細は異なりますが、いずれもデータ業界における広範な転換点を示しています。それは、AI エージェントにデータを単に照会するだけでなく、そのデータに基づいて行動し、周辺システムを運用するためのインフラを提供するという方向性です。
「AI によって、5〜10 年前には想像もできなかった有用な機能の構築が可能になりました。プラットフォームはデータ資産の中で最も複雑な部分であり、ウェアハウスベンダーが新たなパターンの中心に立つのに適した立場にあります。」
ティガニ氏は以前から、ほぼこのような未来を予測していました。今年初め、彼はデータエンジニアリングが次第にエージェントの監督問題へと変化していく未来を描きました。具体的には、パイプラインの構築や修復、スキーマやデータ品質の変化への対応といったタスクをエージェントが処理し、人間はその作業を見守るというモデルです。また、彼は LLM の進歩を、データ企業が乗りこなさなければならない波に例えたこともあります。
「私が考えるにはこうです。データプラットフォームベンダーは、顧客の生活をより良くするための新たな機会に対応しているのです」とティガニ氏は語ります。「AI によって、5〜10 年前には想像もできなかった有用な機能の構築が可能になりました。プラットフォームはデータ資産の中で最も複雑な部分であり、ウェアハウスベンダーが新たなパターンの中心に立つのに適した立場にあります。Tower の買収により、データの展開、追跡、スケジューリングを行うためのプラットフォームが整いました。これによって、あの波を乗りこなす準備が整うはずです。」
「機能は借りても、基盤は借りられない」——データパイプラインをすでに支えているスタートアップを MotherDuck が買収した理由
関連記事
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み