「怒り」から生まれたSanityがCMSを捨てて$85Mを集めるまで

Sanityは、コンテンツをデータとして扱う「Content Operating System」を名乗るプラットフォームです。

中心にあるのはJSONドキュメントをリアルタイムに配信するContent Lakeで、React製のオープンソースエディタSanity Studioと、独自のクエリ言語GROQが組み合わさります。

Osloで生まれ、現在は米国と欧州にチームを置いています。出典

出発点はCMSへの苛立ちだった

Sanityは、ノルウェー・Osloのプロダクト開発会社Benglerから生まれました。

きっかけは、建築家レム・コールハースの事務所OMAの新しいウェブサイトでした。

共同創業者のSimen Svale Skogsrudは当時をこう振り返っています。

既存のコンテンツ管理システムはどれも恐ろしく散らかっていて、これが僕らが使える全部なのかと呆れた。コンテンツはデータだ。データベースに入っているんだから、コンテンツAPIが欲しかった

既製のCMSでは要件を満たせず、チームは自分たち用の仕組みを作ります。

それが別の案件でも使われ、やがて顧客から「これは何だ。なぜ既製品より優れているのか」と聞かれるようになりました。

国連の案件と自社プロダクトのどちらを取るかを迫られたことが、会社としての転機だったとSimenは語っています。出典

「怒り」から製品へ

Simenの言葉は率直です。

Sanityはほとんど怒りにまかせて作られました。製品を作ろうと決めていたわけではなく、最初のプロジェクトのために間に合わせのものを作るしかなかった

2019年、HeavybitとAlliance Ventureがリードする$2.4Mのシードを調達します。

翌2020年10月にはThresholdやEv Williamsらが参加する$9.3MのSeries Aを実施しました。出典

コンテンツをデータにする

2021年、SanityはJSONドキュメントをリアルタイムに配信するContent Lakeを発表し、「コンテンツはデータである」という立場を製品の中心に据えます。

同じ年にICONIQ Growthがリードする$39MのSeries Bを調達し、発表時点のチームは50人未満でした。出典

Jamstackコミュニティ調査では、SanityはCMS部門で最も高い満足度を記録し、利用数は前年比48%増。

利用者は10万人を超えていました。出典

CMSを捨ててContent OSへ

2025年5月、Bullhound Capitalがリードする$85MのSeries Cを発表します。

同時に打ち出したのが「Content Operating System」という再定義でした。

CEOのMagnus Hillestadは、資金が必要だったわけではないと書いています。

この時点で資金調達は必要ありませんでしたが、ここ数年の強い業績とContent Operating Systemへの勢いを考えると、今やるのが正しいと感じました

その後も開発は続き、2026年6月のStudio v6ではVite 8への移行でビルド時間の中央値が約4.8倍短くなりました。出典

今

CMSの置き換えではなく、コンテンツを扱う業務そのものの基盤を狙う。

その宣言を、14年分の設計の積み上げで裏づけようとしている段階だと言えます。

Sanityが刺さるのは、マーケティング部門のための点と線のCMSでは足りず、コンテンツを製品データとして複数チャネルへ配りたい開発チームです。

既製CMSでは要件ごとに作り直しが発生するという不満に対し、Content LakeとGROQでスキーマとクエリを自分たちで設計できる点が応えます。

PUMAは再利用可能なコンテンツ5万点、商品カテゴリ1.2万件を毎時取り込む運用に到達しており、単発のサイト制作ではなく継続的な基盤として使われていることがわかります。出典

Content Lakeのリアルタイム配信とGROQ、Portable Textという独自仕様に、オープンソースStudioのエコシステムが重なる点が参入障壁です。

スキーマとクエリが資産化すると、フロントエンドを替えてもContent Lake側は残るため、置き換えコストが上がります。出典

弱めですが存在します。

Studioのプラグインやテンプレート、コミュニティでの知見共有は利用者が多いほど価値が増します。

一方でコンテンツデータ自体は顧客ごとに閉じており、利用者間で直接つながる効果は限定的です。

開発者コミュニティとドキュメントの厚みが実質的な効果の中心です。出典

多言語・多ブランドのデジタル体験を持つ中〜大企業の開発チームと、その隣にいる編集・コンテンツ運用チームです。

EC、メディア、SaaS、製造業のグローバルサイトが典型で、1人で完結する個人ブログや、設定だけで済ませたい小規模店舗は主対象ではありません。

編集者がコードを書かずに運用でき、開発者がスキーマを管理できる分担が前提です。出典

第一に、最初の顧客が「なぜ既製品より良いのか」と聞いた瞬間を製品化の合図にしたこと。

第二に、Studioをオープンソースにして開発者が編集UIまで作り込めるようにしたことで、コミュニティとドキュメントが資産になったこと。

第三に、シードからSeries Cまで同じ投資家層（Heavybit、Threshold、ICONIQ Growth）が継続して支援したことです。出典

公開された大きな失敗はありませんが、リスクは明確です。

CMSカテゴリはContentfulやStoryblok、オープンソースのStrapiやDirectusと競合し、価格と導入の手軽さで比較され続けます。

SSOや監査ログなど統制機能がEnterpriseプランに寄っているため、成長企業が途中で上位プランへ移る必要があり、そこで離脱する可能性があります。

また、AI機能とクォータの従量課金が重なると総コストが読みにくく、稟議の障壁になり得ます。出典

オープンソースのStudioとドキュメントで開発者を獲得し、無料枠で小規模プロジェクトを立ち上げさせ、Growth $15/席でチーム利用に拡張する流れが基本です。

ブログ、年次イベント、コミュニティで認知を作り、大企業案件は営業とソリューションアーキテクトが受ける二層構造になっています。

2026年時点の求人はSalesとCustomer Solutionsが中心で、プロダクト主導からエンタープライズ営業へ重心を移しつつあることが読み取れます。出典

主要チャネル: content_blog, developer_docs, community, events, open_source, product_led, enterprise_sales

自分たちの不満から作った社内ツールは、顧客が「なぜ既製品より良いのか」と聞いた瞬間に製品になります。

そのとき機能を足すのではなく、設計思想（この場合はコンテンツはデータである）を製品の中心に据えると、後年の差別化と説明が一貫します。

買収や大型調達より、思想を言語化して採用し続けたことが効いています。出典

日本では、多ブランドを抱える小売・製造業のサイト再構築で、CMSではなくコンテンツ基盤として提案する余地があります。

ただし編集者がExcelとWordで回している現場では、スキーマ設計の負荷が導入障壁になりがちです。

最初から全社展開を狙わず、1ブランド・1言語で開発者が主導するPoCを作り、編集者がコードを触らずに更新できる体験を見せてから横展開する進め方が現実的だと考えます。出典