「scriptを捨てない」自動化、Windmillが埋めるコードとno-codeの間

「no-code と、昔ながらの自前スクリプトの間にある sweet spot を作りたい」。Windmill の YC launch post で、創業者 Ruben Fiszel はそう書いた 出典。ノーコードは問題が製品の想定どおりなら速い。でも少し外れると拡張しにくく、技術的負債にもなる。一方、Python や SQL を書き続けるだけでは、実行環境・secret・権限・schedule の面倒が残る。その間を埋めるのが Windmill の出発点だった。

Palantir の分散システムから、もっと小さい仕事へ

Ruben は EPFL でコンピュータサイエンスを学び、Stanford でコンパイラ研究に関わり、Palantir で大規模分散システムを経験した。

YC のプロフィールによれば、その後は multi-party computation のスタートアップで engineering team を率いた 出典。

大規模な計算基盤を知る彼が狙ったのは、巨大な一枚岩ではない。

チームの中に散らばる「本当は毎日回すべきスクリプト」だった。

script を、実行できる部品にする

2022 年、Windmill は YC Summer 2022 に参加し、Launch HN で姿を見せた 出典。

Python、TypeScript、Go、Bash、Rust、SQL の script を、webhook、cron、workflow、internal app に変換する。

parameter から UI を出し、dependency、credential、permission、retry を面倒見る。

YC の説明にある通り、目標は business logic に集中させることであって、インフラを再発明させることではない。

この設計は Retool、Pipedream、Airplane、Temporal、n8n、Airflow と競合しながらも、どれか一つの棚だけには収まらない。

internal tool を作る日もあれば、夜間バッチを直す日もある。

Windmill はその両方を、コードを捨てずに扱おうとした。

AI agent 時代に runtime を捨てなかった

2025 年から 2026 年にかけて、Windmill は AI agent steps、AI sandboxes、workflow-as-code を連続して公開した 出典。

新しい AI 専用プロダクトを別に立てるのではなく、checkpointing、parallelism、fault tolerance を備えた既存 flow の中に agent を置く。

この選択は派手なデモより地味だが、本番では効く。

agent が Stripe に触れるなら credential を渡し切るのでなく、sandboxed capability にする、というブログの問題設定にもその思想が出ている 出典。

Windmill が勝つかどうかは、広い製品面を小チームでどこまで磨けるかにかかる。

だが Ruben が最初に書いた「低コードとゼロからのコードの間」という席は、AI が script を量産するほど、むしろ重要になっている。

書く量が減っても、それを安全に動かす仕事は消えないからだ。

Windmill の PMF は、「社内の小さな自動化」が本番運用に育つたびに、cron・権限・secret・リトライ・UI を別々に用意しなければならない痛みにある 出典。

Python や TypeScript の既存スクリプトを出発点にし、parameter から UI を生成、webhook・schedule・flow へ拡張できるため、no-code の硬直性とフルスクラッチの運用負債の間を埋める。

公式は Community Edition、Cloud、self-host を同時に提供する。

まず無料で導入して、複数チーム・認証・監査・実行基盤の要求が生じたところで Team / Enterprise に進む、開発者起点の導線だ 出典。

コードを UI・API・schedule・workflow に横断的に接続する runtime と、self-host 可能な OSS 配布が堀の候補だ 出典。

既存スクリプト、workspace、secret、権限、監査が積み上がるほど別製品への移行コストは増す。

ただしライセンスやホスティングの選好は企業ごとに異なり、OSS だけで防御力が完成するわけではない。

継続的な DX、運用信頼性、enterprise 機能の実行が堀を実体化できるかが要確認だ。

直接的なネットワーク効果は弱い。

ある会社の workflow が他社の実行価値を自動的に高めるわけではない。

一方で hub、GitHub、公開テンプレート、connector、記事が「次の利用者の初速を上げる」間接効果を作る。

YC の launch post でも API・汎用タスク向け script library を OSS community と育てる方針が明記されている 出典。

Python / TypeScript 等で社内業務、データ処理、API integration、AI agent を動かす開発者と platform team。

ノーコードだけでは足りず、しかし cron・queue・secret・UI を都度組み立てたくない組織が中心だ 出典。

特に self-host、PostgreSQL、細かな権限管理を重視するチームには、SaaS 専用 automation より検討余地がある。

最大の強みは「workflow 製品」ではなく runtime・editor・secret manager・OAuth・RBAC・app builder を一体で持つことだ。

YC は Python、TypeScript、Go、Bash、Rust、SQL を扱い、branching / parallelism / retries を組める点を明示している 出典。

Rust / TypeScript / Svelte / PostgreSQL という性能と self-host を意識した構成、GitHub と Hacker News を軸にした OSS 配布も効く。

2026 年には workflow-as-code と AI sandbox を追加し、AI agent を作る開発者にも既存の durable execution を再利用できる形にした 出典。

公開 ARR・MRR・調達総額は本記事の一次情報では確認できず、収益の厚みは要確認である。

YC の公開プロフィールは従業員 7 人と記載しており、広い製品面（workflow、internal tools、apps、AI sandbox、deployment）を小チームで保守する複雑さはリスクだ 出典。

競合も強い。

Temporal は durable execution、Retool は enterprise internal tools、n8n は automation、Airflow は data orchestration に深く根を張る。

「全部入り」は導入を容易にする一方、用途が明確な顧客には過剰に見える可能性がある。

GitHub・Hacker News・ドキュメント・技術ブログで開発者を獲得し、self-host 可能な Community Edition を入口にする PLG が中心 出典。

コンテンツは単なる release note でなく、Windows automation、AI Discord bot、workflow-as-code の実装例として課題検索に接続している。

Cloud と Enterprise は RBAC、credential、deployment、監査、運用支援を必要とする組織へ拡張する。

AI agent のためだけに別 runtime を増やさず、既存の flow に sandbox・MCP を足す戦略は、既存ユーザーへの upsell と新規需要の両方を狙える。

主要チャネル: hn, github, community, content

「workflow を売る」のではなく、すでに存在する script を本番の部品へ変える入口は強い。開発者に新しい DSL を覚えさせず、既存言語を残したまま schedule・retry・UI を与えるからだ 出典。

同時に、製品の守備範囲を広げすぎると説明が難しくなる。

Windmill のような横断基盤は、特定の job-to-be-done ごとのテンプレートと導入事例で「何に使うのか」を継続的に具体化する必要がある。

日本では情シス、データ、事業部がそれぞれ Excel・SaaS・Python script を抱え、個別自動化が属人化しやすい。

self-host と RBAC を備えた「コードを残した automation platform」は、内製チームの共通実行基盤として余地がある。

ただし国内導入では日本語ドキュメント、監査要件、オンプレミス / 国内リージョン、運用支援が判断材料になる。

まずは Slack / Google Workspace / kintone といった国内で多い連携の実例を増やすのが現実的だ（意見）。