Amazonは2026年8月26日、オープンソースの分析データベース「DuckDB」を開発するDuckLabsを買収する最終契約を結んだ。取引は通常の完了条件を満たす必要があり、DuckLabsは9月上旬の完了を見込んでいる。AWSが取得するのはDuckDBプロジェクトや知的財産ではなく、アムステルダムに拠点を置く30人超の開発会社である。コードの法的な独立は保たれる一方、実際にロードマップを動かす人材はAWSへ入る。この二層構造を分けて見なければ、買収の意味を取り違える。
なぜ30人超の開発会社をAWSが買うのか
DuckLabsはベンチャーキャピタルから資金を入れず、創業者と開発チームが所有してきた。企業から機能開発やサポートを受託し、その収益でDuckDBを育てる仕組みである。共同創業者のHannes MühleisenとMark Raasveldtは、利用が広がるにつれて小さな会社が支援のボトルネックになり、大規模な営業・運用組織を作れば技術開発へ割ける時間が減ると懸念していた。
AWSとの接点はすでに製品レベルにある。両社は1年以上協業し、DuckDBからAmazon S3 TablesとAmazon SageMaker Lakehouseへ接続する機能を開発してきた。DuckDBは別のデータベースサーバーを立てず、アプリケーション内で分析処理を実行できる。S3上のデータへ計算を近づけたいAWSにとって、DuckLabsの価値はデータベースのブランドより、ストレージと分析エンジンをつなぐ開発力にある。
従来のDuckDBは、ホストとなるアプリケーションの処理に組み込み、手元のファイルをSQLで調べる使い方を広げてきた。この仕組みなら、分析前に大規模なデータベースへ全データを移す工程を減らせる。DuckLabsは今後、利用者がデータベースを意識しない製品の内部にもDuckDBを組み込みたいとしている。AWSの顧客基盤とインフラは、開発者向けエンジンをサービスの構成要素へ広げる経路になる。
取引完了後もMühleisenとRaasveldtはチームを率い、DuckDBの技術方針を担う予定だ。両社はDuckDB、データレイクハウス向けのDuckLake、遠隔接続用のQuackを新しいデータサービスに使う考えも示した。ただし、具体的なAWS製品や提供時期、価格は公表していない。
MITライセンスよりも理事構成が効く
AWSは「DuckDBオープンソースプロジェクトを買収しない」と明記した。DuckDB、DuckLake、Quackの中核知的財産と商標は非営利のDuckDB Foundationが保有し、各プロジェクトは寛容なMITライセンスで公開され続ける。既存コードをAWSが閉じたり、他社による利用やフォークを禁じたりする取引ではない。
MITライセンスが守るのは、公開されたコードを利用、改変、再配布できる自由である。将来どの機能を優先し、誰が継続して保守するかまでは定めない。AWSの方針に不満があればフォークはできるが、中核開発チームと同じ速度でデータベースを維持するには人員と資金が要る。利用企業にとっては、ライセンス表記よりもFoundationの意思決定と外部貢献者が参加できる経路の方が、長期的な選択肢を左右する。
それでも、ライセンスだけでロードマップの中立性までは決まらない。Foundationの公式ページが掲げる現行理事は3人で、議長のMühleisen、理事のRaasveldt、CWIの研究者Peter Bonczである。買収後にAWSへ加わる共同創業者が3議席中2議席を占めるため、法的な知財保有者と日々の開発組織は分かれていても、人の面では重なりが残る。
2021年に作成されたFoundationの定款では、理事の任免を理事会自身が行い、各理事が1票を持つ。通常の決定には在任理事の過半数を代表する投票と、投じられた票の絶対多数が必要だ。個人的な利益がFoundationの利益と衝突する理事は審議と決定から外れる。ただし、それで決定できなくなる場合は、理由を書面に残したうえで理事会が決められる。会社と財団を分けた設計には防波堤があるが、買収後にどの案件を利益相反として扱うかは運用に委ねられる。
v2.0はサーバーと独自拡張へ広がる
買収発表の9日前、DuckDBは2026年秋に予定するv2.0の概要を公開した。これまでの強みだったアプリケーション内での実行に加え、Quackを安定版にして遠隔のDuckDBへ接続できるサーバーモードを導入する。S3のようなネットワークストレージを並列に読み書きしやすくする非同期I/Oも入る。AWSとの組み合わせが生きる範囲は、すでにローカル分析からクラウド上の共有データへ広がり始めている。
もう一つの変化は拡張機能の配布方法だ。現行版では公式・コミュニティーの拡張機能をDuckDB側が集中してビルドし、署名している。v2.0では組織が自前の公開鍵を登録し、自ら署名した拡張機能を独自の保管場所から配布できる設計を進める。AWS以外のクラウド事業者や独立ベンダーも同じ仕組みで接続機能を届けられるなら、技術面の中立性は強まる。
配布の分散を支えるのが、v2.0で導入する安定したC言語のバイナリーインターフェースである。現在はDuckDBの更新に合わせて拡張機能を再ビルドする負担が大きい。新しい仕組みでは、拡張機能がDuckDBの版ごとの差を受けにくくなり、各社が自分の保管場所と署名鍵を管理できる。独立したクラウド事業者が機能を継続提供するうえで、これは諮問委員会への参加より直接的な手段になる。
信頼する保管場所を登録すると、DuckDBは配布元の公開鍵を固定し、照合用のSHA-256指紋を表示する。複数鍵による鍵更新に対応し、登録内容を監査したり削除したりする機能も用意する計画だ。利用企業が拡張機能の配布元を選べるため、AWSのサービス統合と同じ基盤上で他社の機能も管理できる。
ただし、この信頼済み拡張リポジトリは発表時点で開発中である。v2.0の詳細も正式版まで変わり得る。買収によって完成した成果ではなく、買収前から進んでいたロードマップとして評価すべきだ。
技術諮問委員会に議決権はあるのか
DuckLabsは2026年秋、FoundationにTechnical Advisory Boardを設ける。公式説明では、DuckDB、DuckLake、Quackのロードマップに主要な利用者や貢献者が意見を出す場になる。取引完了後にオープンソース技術とコミュニティーへ投じる資源を増やす計画だが、諮問委員会が理事会の決定へどう関与するかは示していない。
諮問委員会の構成、委員の選び方、理事会に対する権限はまだ示されていない。The Registerの取材に対し、Mühleisenも正確なガバナンスと投票権は未決定だと説明した。同紙によれば買収金額も非公表である。つまり、オープンソース継続という約束を実装する制度設計はまだ完成していない。
現行定款では、ロードマップを定める責任も理事の任免権も理事会にある。諮問委員会が意見を出せても、理事会が回答する義務や議決への参加がなければ、AWS以外の利用者が方針を変えられるとは限らない。委員の選出方法と議事の公開範囲に加え、勧告へ理事会がどう応答するかが最初の確認点になる。
MotherDuckは今回の買収対象ではない。既存パートナーシップがどう変わるかは公表されておらず、DuckLabsは今後詳細を共有するとしている。AWS傘下で開発速度が上がったとしても、FoundationがAWS以外の要望を同じ手続きで扱えるか。諮問委員会に実効的な発言経路が設けられ、第三者署名の拡張機能がv2.0で予定通り動けば、DuckDBは企業買収後もベンダーをまたぐ分析基盤として成長できる。
