DuckDB-Wasm + 生成AI on Next.js で、どなたでも、いますぐ、地理空間情報の分析ができましてよ

本日のデモ

https://trident.yuiseki.net/duckdb

本日のソースコード

https://github.com/yuiseki/TRIDENT

---

タイトルには、文字数の限界で、DuckDB-Spatialという言葉を入れられなかったですわ。
もちろん、今回も、DuckDB-Wasmに加えて、DuckDB-Spatialも活用していますわよ。

https://github.com/duckdb/duckdb-wasm

https://github.com/duckdb/duckdb_spatial

---

はじめに

わたくしは、学術的研究として、生成AIによるSQLクエリ生成、そして、生成AIによる地理空間情報の分析と可視化、といった事例が既に多数あることは知っていますわ。

しかしながら、いったい、どれだけの研究者が、そうした研究を、実際にどなたでもが触ることのできるWebアプリケーションやスマートフォンアプリケーションなどのソフトウェアプロダクトとしてデプロイして、本気で世界を変えたいという情熱を持っているのでしょうかしら？

わたくしは、どのようなアイデアも、ソフトウェアプロダクトとして、どなたでも試せるようにデプロイしてこそ、ようやく世界を変える第一歩目だと考えておりますの。

わたくしは第一歩目を踏み出しました。ぜひ、試してみてくださいまし

https://trident.yuiseki.net/duckdb

上記のURLを開いて、適当に、「北朝鮮と日本はどちらが広い？」などと、入力してみてくださいまし。

コピペ用：

北朝鮮と日本はどちらが広い？

これを入力してSubmitすると、信じられないくらいあっと言う間に答えが表示されるはずですわよ。

この TRIDENT DuckDB (仮) というAIは、他にも様々な地理空間情報に関する質問にお答えいたしますの。

ぜひ、いろいろとお試しくださいませ。

北朝鮮と韓国はどちらが広い？

台湾と韓国はどちらが人口が多い？

日本と台湾の距離は？

TRIDENT DuckDB (仮) は、あなたが考えるよりも速く、これらの質問に答えてくれるはずですしてよ。

ただし、 TRIDENT DuckDB (仮) が現時点で知っているのは、 国家単位での事実 のみですので、その点ご注意くださいまし。

さて、これらの技術の組み合わせが、なぜわざわざこうして記事を書いてご紹介するほど画期的なのか、魅力をお伝えさせていただきますわ。

前回のおさらい：DuckDB-Wasm + DuckDB-Spatial

前回の記事で、DuckDB-Wasm + DuckDB-Spatialによって、Webブラウザ上でPostGISライクなデータベースを構築し、SQLを実行することができるということをご紹介いたしましたの。

https://zenn.dev/yuiseki/articles/d89aaba0eb80c6

• 今回は、Next.jsのReactコンポーネントでDuckDB-WasmとDuckDB-Spatialを読み込んで、とにかくもう好き放題にやれるようになった、という所が画期的なのでしてよ。
• 別にNext.jsでなくてもなんでもよいのですけれど、 たまたま目の前にあった使い慣れた道具がNext.jsだった ので、それを使いましたの。
• 新しい道具を使いこなすよりも、この世界を変えるほうが先ですわよ。

仕組みについて

Next.js でDuckDB-Wasmを動かす（一番難しい）

• ローカル開発環境では問題なく動いても、なぜかVercelにデプロイすると壊れてしまうことがありましたの。
• ガチャガチャと試行錯誤を繰り返した結果、なぜかVercelにデプロイできましたわ。
• 正直、すべてを完全に理解しているわけではございませんので、リポジトリのソースコードをぜひご覧いただきたいですわ。
  • https://github.com/yuiseki/TRIDENT/blob/main/next.config.js
  • https://github.com/yuiseki/TRIDENT/blob/main/src/app/duckdb/page.tsx
  • https://github.com/yuiseki/TRIDENT/blob/main/src/app/duckdb/MyDuckDBComponent.tsx
• この世界を理解するよりも、この世界を変えるほうが先ですわよ。

DuckDB-Wasmによるデータベースのサンドボックス化の重要性

• 一度でもデータベースを運用したことがあるのなら、 リアルなデータベースに、生成AIが出力したSQLクエリを投げたくない のは、当然のことでしょう。
• 実際にPostGISエクステンションが有効になったPostgreSQLデータベースがあったとしますわ。
  • そのデータベースに、生成AIが出力したSQLクエリを投げまくりたいかしら？
    • わたくしはそうは思いませんわ。
  • 生成AIが出力したSQLクエリによって、データベースがグチャグチャにエラーを出したり過負荷でアラートを上げたりするかもしれないのですからね。
• そこで、DuckDB-Wasmによってブラウザ上でサンドボックス化されたデータベースが重要になるのですわ！
• サンドボックス化されたデータベースなら、生成AIが出力したSQLクエリによって万が一過負荷が掛かったりグチャグチャに壊れるとしたら、ユーザーのブラウザのメモリ上にあるデータベースだけということになるのでしてよ。

生成AIによるSQLの出力

• DuckDB-Wasmによってサンドボックス化されたデータベースがあるおかげで、もはや怖いものなどありませんわ。
• ユーザーからの自然言語による質問に基づいて、生成AIにSQLを出力させ、ユーザーのブラウザ上でそのSQLを実行すればいいのですわよ！
• 別に生成AIはOpenAI APIでなくてもなんでも良いのですけれど、 たまたま目の前にあった生成AIがOpenAI APIだった ので、それを使いましたの。
• 新しい道具を使いこなすよりも、この世界を変えるほうが先ですわよ。
• 既存の研究でも示されていますが、生成AIにSQLを出力させる際には、テーブルのスキーマといくつかの例を与えることで、性能が一層高まりますわ。

まとめ

今後の展望と拡張性

• 今回は固定のGeoJSONを読み込んで分析しておりますが、そのGeoJSONのデータ構造は動的に分析されておりますのよ。
• この仕組みがあれば、どのようなGeoJSONデータでも読み込んで、自然言語での質問に応答できるようになるかもしれませんわね。
• さらに、GeoJSON以外でも、DuckDBが対応しているファイルフォーマットにも対応できる可能性がございますわ。
• 今後の展望としては、ローカル生成AIの活用も視野に入れておりますの。
  • 現在はOpenAI APIを使用しておりますが、これには利用料金が発生しますわ。
    • 他の生成AIプロバイダーでも同様のことでしてよ。
  • しかし、ローカル生成AIに置き換えることで、時間さえあれば無限回の試行錯誤が可能となり、気が済むまで何度でも使うことができますわよ！
• ここまで書いて、少し疲れてしまいましたわ。
• 後日、追記するかもしれませんが、本日はここまでとさせていただきますわ。

---

わたくしは、これからも引き続き、こうした革新的なソフトウェアの開発を進めていく所存でございますわ。皆さまが気軽に触れていただけるソフトウェアプロダクトを作り上げることで、少しでも未来に貢献できれば幸いですわよ。

もしこの記事が少しでもお役に立てましたら、ぜひ「いいね」やフォローをしていただけますと、とっても励みになりますわ！今後のアップデートも楽しみにしていただけましたら嬉しいですわよ。

それでは、ご覧いただきありがとうございました。どうぞ素敵な一日をお過ごしくださいませ。