data tool は、少し変換を増やしただけで急に spreadsheet 的な限界が見えたり、逆に最初から cloud service、scheduler、warehouse 前提で、単にいくつかの file と database table を整形したいだけなのに準備コストが重すぎたりします。

今日取り上げたい slothflowlabs/duckle は、その中間をかなり真面目に狙っている project です。visual ETL / ELT studio、DuckDB execution、local-first workspace、desktop UX を 1 つにまとめ、大規模 data platform の代替を目指すというより、単機で完結する data work を速く、わかりやすく、再現しやすくしています。

公開時点の GitHub page では、この project は約 551 stars、33 forks。主言語は Rust、repository 作成日は 2026-05-21、直近 push は 2026-06-19 です。最新 release は v0.4.1 で、公開日は 2026-06-18。README では現在の状態を public beta と位置づけています。

Project overview

項目内容
Repositoryslothflowlabs/duckle
位置づけローカルファーストの visual ETL / ELT desktop tool
Stars約 551
Forks33
主要言語Rust
実行コアDuckDB
現在の状態Public beta
Latest releasev0.4.1

解こうとしているのは「大規模 data platform 問題」ではなく「単機の data work がまだ面倒すぎる」という問題

duckle でまず良いと思ったのは、README が scope をかなり正直に書いていることです。これは single-machine 向けの tool です。つまり得意なのは、

  • local file と database の間の整形;
  • 小さな team の data preparation;
  • 複数 source を 1 本の pipeline にまとめること;
  • 本格運用の前にロジックを素早く固めること。

この割り切りはかなり実務的です。多くの data task は、最初から Airflow や managed warehouse を必要としているわけではありません。実際に面倒なのはむしろ、

  • tool が散らばること;
  • 中間状態が見えないこと;
  • 一時 script がすぐ増殖すること;
  • あとから他人が再現できなくなること。

duckle は、その面倒さを desktop workspace に引き戻し、canvas 上で pipeline を組み、実行を DuckDB に任せる方向を取っています。

面白いのは low-code であることより、GUI でも black box に寄らないこと

visual data tool の弱点は、作者以外には中身が読めなくなることです。duckle はそこをかなり意識しています。

README では、次の点が繰り返し強調されています。

  • canvas は SQL に compile される;
  • 各 node に live preview がある;
  • workspace は plain files として保存される;
  • Git に入れて diff、branch、review できる。

ここがかなり大事です。team で長く使う tool に必要なのは、派手な drag-and-drop より auditability と repeatability だからです。GUI の中にしか存在しない pipeline は、いずれ運用負債になります。

duckle は visual editor を入口にしつつ、最終的な管理単位を file と Git に寄せています。この姿勢は、単なる no-code app ではなく、ちゃんと developer tool 的です。

DuckDB を本当に execution layer として使っている

もう 1 つ重要なのは、UI の下が単なる script generator ではないことです。README によれば、

  • pipeline graph は SQL に compile される;
  • 実行は DuckDB を通して行われる;
  • local / columnar / vectorized な実行パスを使う;
  • 多くの connector や format は DuckDB を軸に組まれている。

つまり、desktop app の見た目だけ modern にした ETL shell ではなく、実行面を既存の強い analytical engine に寄せているわけです。これなら GUI で組んだものが、そのまま意味のある execution plan に落ちます。

最新の v0.4.1 release でも、作者は managed DuckDB engine を 1.5.4 に上げ、さらに in-app self-update を入れたと書いています。ローカル実行基盤と desktop distribution をきちんと育てようとしているのが見えます。

connector の多さより、「local-first が崩れていないこと」のほうが価値がある

README の capability table はかなり大きく、

  • 300+ nodes;
  • 290+ connectors;
  • file、database、object storage、API、message system、vector DB まで広くカバー;
  • scheduler、MCP server、headless runner、build pipeline まで含む。

数字だけ見ると盛り込み型にも見えますが、見ていて印象が良いのは、この広さが local-first という軸から大きく外れていないことです。

  • app は single-file desktop binary;
  • workspace は自分で選ぶ folder に入る;
  • default で cloud account に依存しない;
  • Git に載せやすい;
  • 単機を超えたら、その先の system へ出力する前提。

つまり「何でも cloud に寄せる platform」ではなく、「まず自分のマシンでちゃんと仕事が進むこと」を優先しています。このバランス感はかなり好印象です。

内蔵 AI assistant も、ここでは役割が限定されていてちょうどいい

最近は何でも AI assistant を入れがちですが、duckle の Duckie は比較的筋が良いです。

README によると、Duckie は Qwen 2.5 Coder 1.5B を llama.cpp 経由でローカル実行し、自然言語の指示から pipeline JSON を生成して canvas に差し込む役目です。しかも model は filesystem や tool access を持たず、出せるのは text だけです。

この制限がむしろ良いと思います。役割は明確です。

  • AI は pipeline の草案を作る;
  • 人間は node、preview、generated SQL を確認する;
  • 実行はローカル engine が担う。

つまり AI は data flow の代替ではなく、最初の組み立てを速くするための補助です。この距離感なら product 全体の方向とも噛み合っています。

desktop で終わらず、CLI / CI 側へ逃がせるのも実用的

この種の tool は、desktop UI の中だけで閉じると team workflow に入りにくいのですが、duckle はそこにも逃げ道を用意しています。

  • workspace を Git に入れられる;
  • headless runner がある;
  • pipeline を server や CI で動かせる executable に build できる;
  • README では GitHub と GitLab の CI / CD も説明されている。

つまり、最初は GUI で pipeline を作り、その後は review、build、schedule に接続できる設計です。個人の desktop utility で終わらず、team の工程に持ち込みやすいのはかなり大きいです。

境界がはっきりしているのも、むしろ長所

README で特に良いのは、無理に万能を装っていないことです。作者ははっきり、

  • これは single-machine, embedded studio である;
  • 1 台を超える規模なら warehouse や object store、lakehouse に出すべき;
  • cluster のふりはしない;

と書いています。

こういう boundary の明確さは、実際には tool の信頼感につながります。よく使われる project は、何でもできるものではなく、「どの仕事にちょうど良いか」がはっきりしているものだからです。

もし今の課題が、

  • CSV、Parquet、SQLite、Postgres、API の整形を頻繁にやる;
  • visual で組みたいが SQL の見通しは失いたくない;
  • workspace を Git 管理したい;
  • local execution と低いセットアップコストを重視したい;

というものなら、duckle は重い data platform よりずっと始めやすいはずです。

まとめ

slothflowlabs/duckle の面白さは、connector 数の多さだけではありません。local-first、visual pipeline、DuckDB execution、file-based workspace、Git-friendly という要素を、かなり一貫した方向で束ねているところにあります。

まだ beta ですが、向いている仕事はもう十分はっきりしています。いきなり大掛かりな data stack を持ち込むほどではない一方、雑な script の寄せ集めからは卒業したい。そういう人にとって、この project はかなり良い落としどころになりそうです。