Tailwindがエンジニア4人中3人を解雇した理由

ダウンロード数過去最高、売上は80%蒸発

今年1月に静かに通り過ぎたニュースが一つあります。

CSSフレームワークのTailwindを開発した会社が、エンジニア4人のうち3人を解雇しました。同時期、Tailwindの月間ダウンロード数は7,500万回、2025年のState of CSS¹調査基準で開発者の採用率51%と、史上最も利用されているCSSフレームワークとなりました。プロダクトの利用量は最高値を記録したにもかかわらず、会社はエンジニアを4人から1人へと削減したのです。

創業者のアダム・ワセン（Adam Wathan）氏が明かした数字はこうでした。公式ドキュメントサイトのトラフィックは2023年比で約40%減少、売上は約80%減少。

これはプロダクトが失敗した事例ではなく、プロダクトでお金を稼いでいた経路が途絶えた事例です。**Tailwindは公式ドキュメントを訪れたユーザーに有料製品を販売して売上を立てていましたが、その流入が減ったことで売上も連動して減少しました。**そしてこのような構造はTailwindだけの問題ではなく、読者の皆さんの会社のプロダクトが使っているオープンソースのサプライチェーン全体に及んでいます。

🚰 AIスロップのせいで外部からの貢献を受け入れる経路が塞がれました

まずは技術面で起きていることから見ていきましょう。

今この記事を読まれているなら、皆さんはたった今cURLというソフトウェアを使われました。ブラウザを開いていなかったとしても、今日スマートフォン、ノートPC、テレビ、自動車のいずれかに触れたなら、やはり使っているはずです。cURLのコアコンポーネントであるlibcurlは、200億回以上インストールされていると推定されています。こうしたコンポーネントが内部に組み込まれていることを普段は意識することなく、私たちは毎日使い続けているのです。

cURLは1996年に初めて公開されたオープンソースプロジェクトです。スウェーデンの開発者ダニエル・ステンバーグ（Daniel Stenberg、55）氏が作成し、現在も彼がフルタイムでメンテナンスを行っています。コントリビューターの名簿には3,000人以上が名を連ねていますが、フルタイムはその彼一人だけです。

「私は長年、cURLの唯一のフルタイム人員でした。残りは全員ボランティアで、出入りも激しい。明日誰が残っているのか、私には分かりません」（ダニエル・ステンバーグ）

エリック・レイモンド（Eric S. Raymond）氏は、こうした人々を「耐力壁のようなインターネットの人々（load-bearing internet people）」と呼びました。建物の荷重を支えているにもかかわらず、誰も目を向けない壁のことです。

ところが今年1月、ステンバーグ氏は6年間にわたって運営してきたバグバウンティ²プログラムを終了しました。6年間で8万6,000ドル（約1億2,000万ウォン）を支払い、78件の実際の脆弱性を修正してきたプログラムです。終了した理由は一つだけでした。AIスロップ（AI slop）³の急増です。

ステンバーグ氏は、6年間にAIで生成された報告のうち、本物の脆弱性を見つけ出したものはただの1件もなかったと明かしました。その代わり、存在すらしない関数を参照するGDBセッションログやレジスタダンプが添付された、一見もっともらしい偽のレポートが押し寄せたのです。

彼は次のように書きました。

「終わりなきスロップの報告は、管理するだけでも深刻な精神的代償を伴い、反論するのにも長い時間を要します。完全に無駄な時間とエネルギーです。そして、私たちが生きていこうとする意欲さえも蝕んでいきます」

同じ月、デジタルホワイトボードツールtldrawの創業者スティーブ・ルイス（Steve Ruiz）氏は、外部コントリビューターによるプルリクエスト⁴の自動クローズを開始しました。彼はAIでコードを書くことに反対しているわけではありません。自身も使っており、チームにも推奨しています。問題は別のところにありました。

「コードを書くのが簡単な部分なのだとしたら、なぜ他人にコードを書いてほしいと思うでしょうか」（スティーブ・ルイス）

AIが作成した貢献は、形式的には正しく見えても文脈を見落としており、コードベースを誤解し、何より作成者がその後の対話に参加しません。以前であれば、新しいコントリビューターがプロジェクトを学びながら、いつか信頼されるメンテナーへと育っていきました。しかし現在では、ツールをプロジェクトに向けるだけで済むため、貢献を受け入れたとしてもその人がプロジェクトを理解する動機が存在しないのです。

レビューのコストは変わらないまま、貢献の作成コストだけがゼロに収束してしまったのです。今年3月に発表されたある論文は、この現象を「共有地の悲劇」と定義しました。個人の生産性向上分が、レビュアーやメンテナー、コミュニティ全体へとコストとして転嫁されているという意味です。

💰 お金が回収されていた経路が途絶えました

今度は経済面です。ここで再びTailwindの話に戻りましょう。

Tailwindのビジネス構造は、次のような連鎖でした。開発者が「divを中央揃えにする方法」を検索する → 公式ドキュメントにたどり着く → ドキュメントの横に掲載された有料製品（Tailwind UI）の広告を目にする → 購入する。ドキュメントのトラフィックこそが売上ファネルだったのです。

大規模言語モデル（LLM）が、この流れから「公式ドキュメントにたどり着く」という段階を消し去ってしまいました。今や開発者はドキュメントを訪れることなく、ClaudeやChatGPTに質問します。皮肉なのは、それらのモデルが回答できる理由が、まさにTailwindのドキュメントやコミュニティの議論を学習したからだという点です。

**プロダクトの利用量は史上最高であるにもかかわらず、売上は5分の1に激減しました。**オープンソースのエコシステムで今起きていることを、これ以上なく端的に物語る数字です。

今年1月、中央ヨーロッパ大学（CEU）の経済学者ミクローシュ・コレン（Miklós Koren）氏の研究チームが『Vibe Coding Kills Open Source』という論文を発表しました⁵。国際貿易モデルをオープンソースに適用した研究ですが、その結論は明快です。

研究チームが6つのコーディングモデルで実験を行ったところ、モデルが頻繁に推奨するパッケージはダウンロード数が大幅に増加するものの、その活動がメンテナーを養うためのエンゲージメントには全く転換されないことが確認されました。ボットはインストールこそすれど、イシューを立てず、ドキュメントを読まず、感謝の言葉を述べることもありません。

論文の結論はこうです。「開発者の収益が完全に直接的なユーザーエンゲージメントに依存している従来のビジネスモデルの下では、オープンソースのエコシステムは広範なAIの導入に耐え抜くことはできない」

コレン氏は次のように語りました。

「開発者の立場からすれば、疑問はこれに尽きます。もし人々の間で人気を得たいのであれば、なぜ機械だけが使うものを作らなければならないのか？」

Stack Overflowでも同様の構造が見られます。ChatGPTのリリース直前には月10万件を超えていた質問数が、現在では1,500件未満にまで落ち込んでいます。回答率も80%から半分程度にまで低下しました。誰もが閲覧できるように蓄積されていた質問と回答が減少し、その場所を大手テック企業が保管する非公開の会話ログが取って代わることになったのです。

🔑 オープンソースを動かしてきたのはコードだけでなく関心と評判でした

私たちはオープンソースを「コードを無料で分け与えること」だと理解してきました。しかし実際には、コードを提供する代わりに、お金ではない別のものを受け取る構造だったのです。

• 表向き — 出ていくもの：コード ／ 入ってくるもの：（なし、無料）
• 実態 — 出ていくもの：コード ／ 入ってくるもの：関心、評判、イシュー報告、ドキュメントのトラフィック、キャリア

実際にオープンソースを動かしていたのは、2行目のほうでした。無償に見えていた労働は、実はお金の代わりに**関心と評判によって報われていたのです。**貢献の実績は職務経歴書の1行となり、ドキュメントの訪問者は有料製品の潜在顧客となり、GitHubのスター数が多ければ次の職を見つける助けになりました。

AIコーディングツールはコードをそのまま生み出しますが、メンテナーへと向けられていた関心まで一緒に届けてくれるわけではありません。**むしろその関心をツール側へと奪い去っていきます。**かつてユーザーがメンテナーに向けていた関心が、今では月額100〜200ドルのサブスクリプション料金となって、ツールを開発したシリコンバレーの企業へと流れているのです。

リッチ・ハリス（Rich Harris、Svelte創始者）氏の言葉が、この論点を的確に突いています。

「ごく最近に至るまで、ソフトウェアを使う特権のためにシリコンバレーの企業へ実質的な賃料を支払うという発想は、まったくもって馬鹿げたものだと見なされていました」

ミアル・リーダーマン・ユケレス（Mierle Laderman Ukeles）というアーティストが、1969年に『メンテナンス・アート宣言』を書きました。彼女は、メンテナンスの労働が創造の労働に比べて常に過小評価されており、社会がメンテナーに「悲惨な地位を与えている」と指摘しました。そして、こう問いかけました。

「革命が終わったあと、月曜の朝にゴミを片付けるのは誰なのか？」

57年前の問いですが、現在のGitHubのイシュートラッカーでまったく同じように繰り返されています。生成AIは創造のためのツールとして設計され、マーケティングされてきました。「メンテナンスを飛躍的に改善します」とアピールするAI製品を、読者の皆さんは目にしたことがあるでしょうか。私はありません。メンテナンスとは、近道が存在しない営みだからです。

それで、私たちのプロダクトはどうなるのか

FTのあるアプリ一つをとっても、2,000個を超えるオープンソースパッケージに依存しています。読者の皆さんの会社のプロダクトも大差ないはずです。その2,000個のうちのかなりの数が、たった一人のメンテナーにぶら下がっており、その一人が今、スロップレポートに疲弊しきっています。

ウェブコミックxkcdの有名な風刺画が、この構造を見事に描いています。「すべての現代デジタルインフラ」と書かれた巨大なブロックの塔が、「ネブラスカ州の見知らぬ誰かが2003年から無報酬で維持してきた」薄っぺらいブロックひとつの上に乗っかっているというイラストです。

GTM戦略を策定する中で技術デューデリジェンスの資料に目を通す機会が多くありましたが、依存関係のリストは通常「ライセンスに問題がないか」だけを確認して通り過ぎていました。私自身もそうでした。誰がこれをメンテナンスしているのか、その人が疲弊し切ってはいないかは、デューデリジェンスの項目に入っていなかったのです。今になって振り返れば、それこそが最大の盲点でした。

今すぐ点検してみる価値のある3点です。

• バスファクター（bus factor）⁶の確認：自社プロダクトのコアな依存関係のうち、直近12か月間のコミットの80%以上が1人の手によるパッケージはいくつあるでしょうか。GitHub Insightsを使えば30分で確認できます。
• 後援の有無の確認：それらのパッケージのうち、私たちが実際に資金を拠出している先はいくつあるでしょうか。大半はゼロのはずです。GitHub SponsorsやOpen Collectiveを通じて月数十ドルを送るだけでも、メンテナーの離脱確率は大きく変わってきます。
• 貢献方針の整備：自社のエンジニアがAIで作ったPRを外部のオープンソースに投げつけてはいないでしょうか。スロップを生み出す側に自社の名前が付いた瞬間、採用ブランディングの面でも大きな傷となります。

Oswarldの視点

正直に申し上げれば、私はこの問題が「AIが悪者だ」という結論に帰結することを警戒しています。

ステンバーグ氏ですら、AIツールそのものに反対しているわけではありません。彼はAI補助ツールを用いて大量の本物のイシューを発見してくれた開発者を公に賞賛しました。彼が語った核心は次の点にあります。

「一般論として、最初にコードを書くこと自体はどのプロジェクトにおいても問題になったことはありません。プロジェクトにおける真の挑戦とは、それを時間をかけて維持し、バグを修正していくことです。（AIは）問題を修正することにはそれほど長けていません。問題を見つけ出すことのほうがはるかに得意なのです」

私がこの構造を見ていて痛感するのは、これは技術の問題ではなく、精算構造の問題だということです。

20年近くGTM戦略を策定しながら幾度となく目にしてきたパターンがあります。市場において真に崩壊するのはプロダクトそのものではなく、価値が創出される地点と、対価が回収される地点が食い違っているビジネスモデルなのです。Tailwindはコードによって価値を生み出し、ドキュメントのトラフィックからお金を回収していました。AIは、その二つをつないでいた検索流入の経路を断ち切ったにすぎません。そもそも二つの地点を結ぶ経路がドキュメント訪問一つだけであったこと自体が問題だったのです。

したがって私は、「オープンソースが死につつある」というよりは、「オープンソースの精算方式が強制的に再設計されている最中なのだ」と捉えています。そしてこの再設計にかかるコストは、結局のところソフトウェアを販売するすべての企業、すなわち私たちが分担して背負うことになります。現在はメンテナーたちが個人の時間と体力を削ってそのコストを肩代わりしてくれています。彼らがこれ以上持ちこたえられなくなれば、私たちが日々使っているパッケージのバグを直してくれる人は誰もいなくなってしまうのです。

カレン・サンドラー（Karen Sandler、Software Freedom Conservancy）氏の言葉が深く心に残っています。彼女は、これらのツールには「誰もが自身が依存しているソフトウェアを自ら修正できるようにする潜在能力」があると語りました。私もその可能性を信じています。ただし、それは勝手に訪れるものではなく、直す技術を持った人間が踏みとどまっていてこそ実現しうる未来なのです。

おわりに

要点をまとめると、次のようになります。

• 外部からの貢献を受け入れる経路が塞がれました。 cURLはバグバウンティを打ち切り、tldrawは外部からの貢献を遮断しました。AIスロップのレビューコストを、メンテナー個人が一人で背負い込んでいます。
• お金が回収されていた経路が途絶えました。 Tailwindは月間ダウンロード数が7,500万回に達する一方で、売上は約80%減少しました。メンテナーが得ていた報酬はお金以上にドキュメント訪問やイシュー報告といった関心でしたが、その関心がAIツール側へと奪われてしまいました。
• コストは私たちに跳ね返ってきます。 自社のプロダクトが依存する数千ものパッケージのメンテナーが、一人また一人と疲れ果てて去りつつあります。バスファクターと後援の有無、この2点だけでも本日確認してみることをお勧めします。

生み出すことは壊すことよりも難しく、維持することは生み出すことよりもさらに困難です。私たちは通常、何かが故障するまでメンテナンスを意識することがなく、メンテナーが立ち去った後になって初めて、そこに彼らがいてくれたことを知るのです。

💬 読者の皆さんの会社のプロダクトが依存しているオープンソースの中で、メンテナーが事実上一人だけというパッケージをご存じのものはありますか？あるいは逆に、AIツールで作成したPRを外部プロジェクトに送ってみた経験がおありでしたら、どのような反応が返ってきたのかも気になります。コメント欄でお聞かせいただければ、次号のトピックとして掘り下げてみたいと思います。

---

💬 上記の問いに関するご経験をコメントでお寄せください · 📨 依存関係の管理に悩んでいる同僚がいらっしゃいましたら、ぜひこの記事をシェアしてください

---

参考資料と関連リンク

主要出典

• Koren, M., Békés, G., & Hinz, J., “Vibe Coding Kills Open Source”, arXiv:2601.15494, 2026年1月. ：本稿の経済学的バックボーンです。国際貿易モデルをオープンソースに適用したアプローチが特に興味深いです。時間がない場合は結論部を読むだけでも十分です。
• Daniel Stenberg, “The end of the curl bug-bounty program”, 2026年1月. ：メンテナー本人の肉声です。数字以上に、文章からにじみ出る疲労感が多くのことを物語っています。
• Steve Ruiz, “Stay away from my trash!”, tldraw blog, 2026年1月17日. ：「コードを書くのが簡単な部分なら、なぜ他人に書いてほしいと思うのか」という問いが、本稿全体の出発点となっています。
• DevClass, “Tailwind Labs lays off 75 percent of its engineers thanks to ‘brutal impact’ of AI”, 2026年1月8日. ：オープンソースの収益モデル崩壊を物語る最も具体的な事例です。

背景知識

• Mierle Laderman Ukeles, “Manifesto for Maintenance Art 1969!”, 1969. ：メンテナンス労働の過小評価を扱った古典的テキストです。ソフトウェアの話ではないにもかかわらず、まるでソフトウェアの話であるかのように読めます。
• xkcd, “Dependency”, xkcd #2347. ：本稿のすべての内容をイラスト1枚で要約しています。

著者 アン・グァンソプ（Oswarld） は世宗大学校 兼任教授、INLEVEL9 戦略コンサルタントです。経歴、研究、著書、最近の活動は著者紹介で更新しています。 最近の活動 · 2026年7月：HEMA-2: A Consolidation-Aware Tri-Memory Architecture with Multi-Channel Scheduling for Lifelong Conversational AI。

📝 用語解説

각주

1. State of CSS：毎年世界中のWeb開発者を対象に実施されるCSSツールの利用実態調査です。業界において採用率の事実上の標準指標として用いられています。 ↩

2. バグバウンティ（Bug Bounty）：外部の開発者がソフトウェアのセキュリティ脆弱性を発見して報告すると報奨金が支払われる制度です。内部の人員だけでは見つけられない欠陥を捉えるための仕組みですが、報奨金が懸かっているため、釣りまがいの報告も殺到します。 ↩

3. AIスロップ（AI slop）：AIが大量に生成した、一見それらしく見えるものの実質のない低品質なコンテンツを指します。コードの領域では「形式は完璧だが文脈が間違っている」報告やコード提案を意味します。 ↩

4. プルリクエスト（Pull Request、PR）：オープンソースプロジェクトに対して「このようにコードを修正してください」と提案を提出する手続きです。プロジェクトの信頼されたメンテナーがレビューして承認して初めて実際のコードに反映されます。提案するのには数秒、レビューするのには数時間かかるという点が現在の問題の核心です。 ↩

5. バイブコーディング（Vibe Coding）：コードを直接読んだり書いたりするのではなく、自然言語で指示を出してAIが生成した成果物をそのまま利用する開発スタイルです。迅速ですが、成果物を検証する能力がなければ問題が生じた際に対処できなくなります。 ↩

6. バスファクター（Bus Factor）：「何人がバスに轢かれたらこのプロジェクトが停止するか」を数える指標です。バスファクターが1であれば、たった一人にプロジェクト全体が依存していることを意味します。 ↩