WebflowのCSSエンジニアだったOleg Isonenが、クラスを捨ててWebstudioを作った理由

ブラウザのキャンバスでCSSを直接操作し、デザイントークンでスタイルを管理する。

書き出したコードはReact/Remixベースで、Cloudflare上のWebstudio Cloudでも自前のサーバーでも動かせる。

無料枠でも全CSSプロパティと無制限プロジェクトが使え、有料プランで独自ドメインやCMS連携、MCP経由のエージェント編集が開放される。出典

Webstudioは、Webflowの内側を知るエンジニアが「作り直す以外に直せない」と判断した場所から始まった。出典

CSSから始まった不満

Oleg Isonenは「I believe that to truly democratize anything, the solution has to be open: open for extension, open for contribution, and open for building on top of it.」と書き、オープンであることを理念の中心に据えた。出典

彼の出発点はCSSの保守性だった。

2014年にCSS-in-JSライブラリJSSを作り、セレクタ管理の難しさと向き合う。

2018年にWebflowへ入社してスタイルシステムを担当すると、初期の設計判断が大規模化後に開発速度を縛る様子を内側から見ることになる。出典

Webflowを離れた理由

「Technical debt in a huge codebase is just something you can't avoid」と本人が振り返るとおり、小さな変更にも数カ月かかる状態が続いた。2021年5月にWebflowを離れ、1年後にCloudflare WorkersとRemixの組み合わせを見て、ビジュアル開発と軽量ランタイムを両立できると確信した。出典

クラスを捨てるという設計判断

WebflowのUXを評価しつつ、Isonenが変えたかったのはスタイルの持ち方だった。

クラスは500個を超えると保守が破綻しやすく、命名衝突と並べ替え不能という制約を抱える。

代わりにデザイントークンとローカルスタイルを「スタイルソース」として合成する方式を採り、Figmaのトークンと同期できる道を残した。出典

オープンコアという商売の形

2023年3月、コアをAGPL-3.0で公開し、Cloudのホスティングと企業向けの権限管理を有料にする方針を明示した。

個人が必要とする機能はオープンソースにし、組織だけが必要とする機能を商用にする、という線引きである。出典

AI時代への転換

2025年からはTailwind対応とInceptionで生成AI側へ踏み出し、2026年にはコアランタイムを再設計してMCPを提供した。

「The agent edits the real site, not a simplified copy made for AI.」と記すように、AI用の別物を作らず、キャンバスと同じプロジェクトをエージェントに触らせる設計を選んでいる。出典

現在、公式サイトは累計251.4Kプロジェクトと146.7Kユーザーを掲げる。

派手な調達発表ではなく、オープンソースとホスティングの組み合わせで利用者を積み上げてきたことが、この数字から読み取れる。出典

刺さるのは、WebflowやFramerで作ったサイトの保守に疲れたデザイナーと、デザインと実装の受け渡しをなくしたいプロダクトチームだ。

クラスの命名衝突や巨大化したスタイルシートではなく、デザイントークンとCSSの意味を保ったまま編集できる点が、作り直しのコストを下げる。

CMSやデータベースに接続しながら、書き出したコードを自社ホスティングへ持ち出せることも、ロックインを避けたい層に効く。

公式サイトは251.4Kプロジェクト、146.7Kユーザーを掲示しており、無料枠からの採用が実際に積み上がっている。出典

Webflowのクラス運用と比べてトークン使用量が65.22%少ないという自社調査も、保守性という訴求を数値で補強している。出典

参入障壁は、CSSを抽象化せずに扱えるデータ構造そのものにある。

CSS Typed Object Modelに近いJSON表現とスタイルソースの合成方式は、後付けでは真似しにくく、MCPによるエージェント編集もこの構造に依存する。出典

加えてAGPLのコアを自社で保守する体制が、フォーク容易性と引き換えに実装知識を蓄積している。

ネットワーク効果は弱めだ。

テンプレートのマーケットプレイスやDiscordのコミュニティは存在するが、サイト制作そのものは利用者間で直接つながらない。出典

一方で、公開されたコアにコントリビューターが集まるほど機能追加が速くなる効果はあり、マーケットプレイスが育えばコンポーネント共有の薄い loop が生まれる余地はある。出典

主な利用者は、WebflowやFramerで制作するデザイナー、制作会社のフロントエンド担当、そしてデザインと実装を分けたくないスタートアップのプロダクトチーム。

マーケティングサイト、ディレクトリ、CMS連携ブログなど、更新が続くサイトに向く。

逆に、大規模なWebアプリの状態管理や、デザインシステムをコードで厳密に統制したい大企業の基幹画面には向かない。

第一に、創業者が競合の内側で働いた経験を、そのまま設計批判ではなく製品仕様へ変換したこと。

クラスではなくトークン、書き出し可能なコード、セルフホストという3点は、Webflowでは構造上直せないと本人が判断した領域だ。出典

第二に、AGPL-3.0のコアとCloud課金を組み合わせたオープンコアの線引きを早い段階で明示したこと。

個人向け機能は公開し、組織向け機能だけを商用にする基準を先に決めたため、コミュニティと収益が同じ方向を向いた。出典

課題は、オープンソースのコアと商用Cloudの機能差が広がると、コミュニティの貢献意欲と収益化が衝突しやすい点だ。

権限管理のような組織向け機能を商用に置く判断は、境界の説明を誤ると反発を招く。出典

また、WebflowやFramerと比べて認知度はまだ低く、大規模サイトでの実績公開も限られる。

AI生成ツールが乱立する領域では、Inceptionのような新機能が既存編集機能の価値を薄めるリスクもある。出典

資金調達やARRは公開されておらず、成長の持続性は外部から検証しにくい。

獲得の中心はオープンソースのリポジトリと技術ブログだ。

GitHubのスターとフォーク、Discordへの流入がそのまま無料利用者になり、無料枠で作ったサイトがそのままCloud課金の導線になる。出典

第二の柱がコンテンツSEOで、WebflowやWordPressとの比較記事、クラスとトークンの調査記事など、比較検索の意図に合わせた記事を継続的に出している。出典

直近はAIエージェント経由の採用を狙い、MCPとCLIを整備してClaude CodeやCursorから使える導線を追加した。

トレードオフは、エージェント利用が増えるほど自社UIの利用時間が減り、課金ポイントの説明が難しくなることだ。出典

主要チャネル: open source / GitHub, technical blog / SEO, Discord community, Product-led free tier, YouTube

学べるのは、競合製品の制約を内側から観察した人間が、その制約を仕様レベルで否定する製品を作ると強いということだ。

機能の足し算ではなく、データ構造の選択（クラスかトークンか）を変えることで差別化が生まれる。出典

同時に、オープンコアを選ぶなら「何を無料にするか」を最初に言葉で定義する必要がある。

境界を曖昧にしたまま成長すると、後から線を引くほどコストが上がる。出典

日本では、制作会社がクライアントごとにCMSとホスティングを分けて納品する商慣行があり、書き出して自社サーバーに置ける点は受け入れられやすい。

一方で、更新だけをクライアントに任せる運用では、Content Modeのような編集専用UIの日本語対応と、運用代行会社向けの権限設計が導入の鍵になる。

制作会社がテンプレートを横展開する用途では、トークンによる一括変更が工数削減として説明しやすい。