Webflow代替の自ホスト型CMSにInstaticが選ばれる理由

Webサイトの制作・運用を「ビジュアル編集で完結させたい」と考えると、多くの選択肢は Webflow・Framer・WordPress といった SaaS または WordPress 系に集約されます。しかし、SaaS 型はホスティング費用の増加やデータの持ち出しにくさが、WordPress はプラグイン依存や運用負荷の高さが課題となります。ヘッドレス CMS（Strapi / Payload / Directus）を採用する道もありますが、その場合はビジュアル編集を諦め、フロントエンドを別途構築する必要が出てきます。

「ビジュアル編集」「データの自社保有」「シンプルな運用」を同時に満たす選択肢は、これまで意外なほど少ないままでした。

こうした選択肢の空白を埋める形で登場した OSS が、CoreBunch/Instatic です。Bun ランタイム上で動く単一サーバーに、ビジュアルエディタ・コンテンツエンジン・静的パブリッシャーを 1 本にまとめた MIT ライセンスの自ホスト型ビジュアル CMS で、README 上では Webflow・Framer・WordPress の代替と明記されています。

ただし現在のバージョンは 0.0.x で、README 自身が「Early, on purpose」と明言している段階です。「今この段階で採用してよいか」「Payload・Directus・Strapi とどこが違うのか」「本番運用に耐える設計か」──これらの疑問は、初見の技術者が最初に整理したいポイントです。

本記事では、Instatic の公式リポジトリと公式ドキュメントを一次資料として、4 つの中核機能・3 つのアーキテクチャ特性・類似 OSS との差分・懸念点までを整理し、「自プロジェクトに採用検討する価値があるか」を判断するための材料をまとめます。動作検証は行わず、README・公式ドキュメントに基づく整理に徹します。

Instaticの一言概要と現在地

Instatic（CoreBunch/Instatic GitHub リポジトリ）は、「ビジュアルエディタ・コンテンツエンジン・パブリッシャーを単一の Bun サーバーに統合した自ホスト型ビジュアル CMS」です。README では "The open-source alternative to Webflow, Framer and WordPress." と、代替対象を明示しています。

現時点の主要ステータスは以下の通りです（2026 年 8 月時点、GitHub API 取得値）。

README にも「no open-core asterisks, no 'contact sales.'」と記されており、機能を有償版に閉じ込める設計は取っていません。データベースは SQLite または Postgres から選択でき、DATABASE_URL 環境変数で切り替えます。

一方で、バージョンは 0.0.x で、README 自身が「APIs and workflows can still shift before 1.0」と明記しています。「今この段階で採用してよいか」を検討する場合、この事実は最初に把握しておく必要があります（後述の「選ぶ前に確認すべき懸念と対処」で詳しく整理します）。

Instaticの4つの中核機能

Instatic は README の見出し「One tool, the whole life of a site」の下で、機能を Design / Build / Manage / Analyze の 4 軸に整理しています。特徴は、ヘッドレス CMS では「別ツール」に分かれがちな領域を、1 本のサーバー内で提供している点です。

デザインシステム（Design）

「Core Framework」と呼ばれるデザインシステム基盤が本体に組み込まれています。1 つのブランド色を指定するだけで、tints / shades を含む色階調が自動生成され、流体タイポスケール・スペーシングスケール・ユーティリティクラスも数学的に導出されます。生成されたクラスは単一の framework.css にロックされる仕組みです。

Core Framework はもともと WordPress 界でデザイントークンエンジンとしての実績があり、Instatic ではプラグイン扱いではなくコアシステムとして組み込まれています（開発元は Motion.page および Core Framework の開発チーム）。

コンテンツビルド（Build）

Instatic のビジュアル編集は以下の要素で構成されています。

• Modules: containers / text / images / buttons / video / lists / links / SVG / forms などのブロック群
• Visual Components: typed parameters と named slots による再利用可能な部品
• Templates: サイト共通レイアウト / 投稿タイプ別レイアウト / 独自 404 ページ
• Loops: posts / pages / media / plugin exposed sources のコレクションを任意レイアウトで反復
• CMS ネイティブ Forms: セマンティックフィールドで構築し、送信データを自データテーブルに保存
• AI エージェント: 実際にキャンバスを編集する。Site scope（35 tools）と Content scope（15 tools）に分かれ、Claude / OpenAI / OpenRouter / ローカル Ollama を BYOK で選択可能
• Imports / Super Import: 生 HTML を編集可能ノードへ変換。「Super Import」では静的サイト一式（HTML/CSS/画像/フォント）を pages・style rules・design tokens・media に変換し、単一の undo で全体を巻き戻せる

Modules やコンポーネントの拡張、独自データソースの追加はプラグインシステムを介して行います。詳細は公式ドキュメント docs/features/plugin-system.md に整理されています。

コンテンツ管理（Manage）

Instatic のコンテンツモデルは統一されており、pages / posts / components / custom collections / 任意テーブルはすべて data_tables と data_rows で表現されます。pages テーブルが特別扱いされることもありません。

管理画面は 3 つのワークスペースに分かれています。

• Data workspace（/admin/data）: 独自の post type・data table をスプレッドシート形式のグリッドで検索・ソート・フィルタ・一括操作。custom post type は draft / scheduled / published のワークフローとバージョン履歴を持ちます
• Content workspace: ライティングに集中できるサーフェス。ライブモードでは実サイトのデザイン内で編集できます
• Media workspace: フォルダ / スマートフォルダ / 一括操作 / 使用箇所トラッキング / プラガブルストレージアダプタ

アクセス制御は 38 個の capability から組み立てるロールベースで、トークンベースセッション・TOTP 2FA（シークレットは保存時に暗号化）・失敗時のバックオフ付きロックアウト・危険操作の直前 step-up 認証をサポートします。管理画面全体には ⌘K のあいまい検索コマンドパレットが用意されています。

監査・分析（Analyze）

• カスタマイズ可能ダッシュボード: 12 カラムグリッド上にタイルウィジェットを配置。プラグインもウィジェットを提供できます
• 監査ログ: 追記専用で、ログイン・コンテンツ変更・ロール編集・プラグインライフサイクルなどを記録します
• フォームデータの自社所有: フォーム送信データを自テーブルに格納し、第三者ベンダーに依存しません

現時点で第三者訪問者トラッキング（アクセス解析）は本体に含まれていません。README のロードマップに first-party analytics が明記されており、開発が進んでいる段階です。当面は外部解析ツールと併用する運用が現実解となります（詳細は後述の「選ぶ前に確認すべき懸念と対処」で扱います）。

アーキテクチャ設計の3つの特徴

Instatic のアーキテクチャは、「1 つの Bun サーバーに全部を入れるのに、公開ページはあれほど軽い」という一見矛盾する要件を、レイヤ分割で解いています。設計思想の全体像は docs/architecture.md にまとめられています。

Bun 単一サーバー構成

README の「For developers」セクションに、採用スタックが明示されています。

出典: Instatic README「For developers」

サーバー実装は Bun.serve に手書きのルーターを組み合わせ、DB は単一の DbClient インターフェースを介して SQLite / Postgres を切り替えます。全ての境界バリデーションは TypeBox で実施されます。アーキテクチャルールは src/__tests__/architecture/ に実テストとして常駐しており、規約がコードで守られる作りです。

パブリッシャーの3層設計

公開ページの軽さは、パブリッシャーの 3 層構成で実現されています。設計の詳細は docs/features/publisher.md に整理されています。

1. ディスクベイク: 全ページをビルド時に uploads/published/current/<route>.html として出力。リクエスト時に DB は不要
2. インメモリ LRU: (urlPath, canonicalQuery) をキーにメモ化。無関係なクエリは正規化してキャッシュ汚染を防止
3. 動的島の遅延読込: <instatic-hole> プレースホルダに対して、約 1.1 KB の IntersectionObserver ランタイムが /_instatic/hole/<nodeId> から動的コンテンツを取得

動的ノードは、モジュールの dynamic フラグ・リクエスト依存バインディング・ループソースの requestDependent・VC 定義木の動的性、の 4 ルールで自動検出されます。静的なループ本体は Rule 3.5 で昇格して静的側に寄せられます。

CSS は reset / framework / style / userStyles の 4 つのハッシュ付きバンドルに分割され、CssCollector がモジュール ID でデデュプします。典型ページで 60〜80% のサイズ削減 が期待できると公式ドキュメントに記載されています。

モジュールの Render API は純関数制約で、escapeProps によって全プロップが事前 HTML エスケープされます。DOM / React / await / document への直接アクセスは禁止されており、CSP も CspPlan: Map<directive, Set<source>> として決定論的にシリアライズされるため、同一入力から同一バイト列の出力が得られます。

QuickJS-WASMサンドボックスによるプラグイン隔離

プラグインは独立した JavaScript エンジン（QuickJS-WASM）で実行され、1 プラグイン 1 ワーカーで完全に分離されます。設計は docs/features/plugin-system.md に整理されています。

主要な数値は以下の通りです。

• ヒープ: 64 MB
• スタック: 1 MB
• 評価タイムアウト: 5 秒（スケジュール実行時は最大 5 分）
• 禁止 API: eval / new Function / require / Bun・Node モジュール / WebSocket / 環境変数アクセス
• 提供 API: 標準 JavaScript（JSON / Promise / Map / Set） / crypto.subtle / fetch（許可時のみ）

権限モデルは 3 層で構成されています。

1. VM 層: assertTargetPermission によるサンドボックス内同期チェック
2. ホスト層: apiDispatch.ts による RPC ディスパッチ前検証
3. エディタ層: ブラウザ内 editorApi.ts の権限検証

代表的な権限には cms.routes（HTTP ルート）、editor.code（サンドボックス外・管理画面実行）、network.outbound（許可リスト必須）、cms.content.write などがあります。ライフサイクルは install → activate →（optional）deactivate / migration → uninstall で構成され、フック失敗時は前状態にロールバックされ error ステータスとして保管されます。5 分以内に 3 回クラッシュすると自動再起動が停止する保護もあります。

Node.js プロセス内で直接実行される Node ベースの CMS プラグインとは根本的に異なる隔離モデルであり、サーバーの安定性・セキュリティ境界を明確に引ける点は運用上の大きな安心材料です。

Payload・Directus・Strapi・Webflowとの比較

Instatic が Webflow 代替として位置づけられる一方、ヘッドレス CMS や SaaS ビジュアルビルダーとは何が違うのかを整理します。

比較マトリクス

出典: Headless CMS Showdown（DSRPT, 2026） / Headless CMS Comparison 2026（dasroot） / Payload vs Strapi vs Directus 2026（pkgpulse） / Instatic README（前掲）

Payloadとの違い

Payload CMS は TypeScript ファーストのヘッドレス CMS で、「app と CMS を単一リポジトリで扱える」設計思想は Instatic と近い側面があります。ただし ビジュアルキャンバス編集は持たず、フロントエンドは Next.js 等で別途構築する前提です。パブリッシャーとしての静的 HTML 出力機能も本体には含まれません。

「TypeScript で型安全に CMS スキーマを定義し、フロントエンドの構成を自分たちで管理したい」チームには Payload、「ビジュアル編集・パブリッシャー・API を 1 本で持ちたい」チームには Instatic が向く、という切り分けになります。

Directusとの違い

Directus は 既存の SQL データベースに管理 UI と API を被せる データベースファースト設計です。既存の業務 DB やレガシー DB に管理画面を後付けしたいユースケースが主戦場で、ビジュアルサイトビルダーではありません。

Instatic は自前のコンテンツモデル（data_tables / data_rows）を持つため、既存 DB のラッピングではなく「ゼロから作るサイト」のスタックとして選ぶツールです。

Strapiとの違い

Strapi は最大級のヘッドレス CMS コミュニティを持ち、プラグインエコシステムも豊富ですが、Instatic と大きく異なる点が 2 つあります。

• ビジュアルキャンバス編集を持たない（REST / GraphQL API を提供し、フロントエンドは別途構築）
• プラグインは Node プロセス内で直接実行される（Instatic のような専用サンドボックスは持たない）

「既に大きなコミュニティ・プラグイン資産を活かしたい」場合は Strapi、「プラグインの権限境界を強く引き、ビジュアル編集も 1 本化したい」場合は Instatic が候補になります。

Webflow / Framerとの違い

Webflow と Framer はビジュアル編集の完成度が高く、非エンジニアでも扱いやすい強みがありますが、クローズドソース SaaS であるためデータとコードを自社で保有できず、ホスティングもプラットフォームに依存します。

Instatic は MIT ライセンスの自ホスト OSS で、DB と uploads を自分たちで保持できます。「Webflow / Framer で作ったサイトを自ホストへ移したい」文脈で、静的 HTML 出力・ビジュアル編集・データ所有の 3 点を同時に満たす選択肢として設計されています。

Instaticが選ばれる理由（適する用途）

比較を踏まえると、Instatic が選定候補に入る条件は次のようなプロジェクトです。判断チェックリストとしてご活用ください。

• ビジュアル編集と自ホストを両立したい: Webflow / Framer の体験を保ちつつ、データを自社で保有したい
• データを完全に自社所有したい: 顧客データ・フォーム送信・メディアを外部プラットフォームに預けたくない
• 単一サーバー運用でシンプルな運用体制を作りたい: ヘッドレス CMS + 別フロントエンド + 別パブリッシャーの 3 本立てを避け、運用対象を 1 本に集約したい
• Core Framework のデザイントークンを活かしたい: 色階調・タイポ・スペーシングの数学的スケール生成が要件に合う

逆に、既存の DB をラップして管理 UI だけ後付けしたい場合は Directus、フロントエンドは自分で作りたい・API とスキーマ管理だけ欲しい場合は Payload や Strapi のほうが素直な選択肢になります。

選ぶ前に確認すべき懸念と対処

Instatic には魅力的な設計が並ぶ一方で、現時点では次の 3 つの懸念があります。「今採用するのか」「1.0 を待つのか」を判断するために、隠さずに整理しておきます。

API・ワークフローの変動リスク（0.0.xの現在地）

README の「Early, on purpose」節に、以下が明記されています。

• バージョンは 0.0.x（pre-1.0）
• 「APIs and workflows can still shift before 1.0」

破壊的変更を許容できないミッションクリティカルな本番運用より、まずは小規模な内製サイト・ドキュメントサイト・キャンペーンサイト等で採用し、1.0 リリースに向けて情報をキャッチアップしていく運用が現実的です。長期運用を想定する場合は、README およびリリースノートの更新頻度を継続的に確認する必要があります。

プラグインエコシステムの未成熟

プラグインアーキテクチャ自体は QuickJS-WASM による強固な隔離を備えていますが、公開プラグインの数は Strapi など成熟した CMS と比べればまだ限定的です。SDK の範囲内（HTTP ルート、独自管理ページ、スケジュールジョブ、ループデータソース、キャンバスモジュール、メディアストレージアダプタ、ライフサイクルフック）で自作する前提を持てるチームに向いています。

訪問者解析基盤の未実装

現時点の Analyze は監査ログ・フォームデータ所有・ダッシュボードといった運用系メトリクスが中心で、first-party analytics（訪問者トラッキング）は本体に含まれていません。README のロードマップに開発予定と明記されていますが、当面はサーバーサイド計測ツールやプライバシー配慮型の外部解析サービスと組み合わせる運用が現実解です。

デプロイ・運用の最初の一歩

README に整理されているデプロイ経路は主に次の 4 つです。詳細は docs/deployment にあります。

• Railway ワンクリック（SQLite） — 初回セットアップの最速経路
• Railway Postgres — 複数著者・マネージドバックアップが必要な場合
• Render（SQLite / Postgres） — Render を既に運用している環境向け
• Docker / VPS — 自前インフラで完全に制御したい場合

DB は 初期のデフォルトが SQLite で、「複数著者・マネージドバックアップ・拡張余地が必要になった時に Postgres へ切り替える」ステップが推奨されています。バックアップは 1 文で表現でき、DB（Postgres dump または SQLite ファイル）と uploads フォルダをバックアップすれば全体が保全される 構成です。

Docker / VPS 採用時のイメージ指定例は README に掲載されています。

INSTATIC_IMAGE=ghcr.io/corebunch/instatic:latest docker compose -f compose.prod.yml -f compose.sqlite.yml up -d

出典: Instatic README（Quick Start / Deployment）

更新オペレーションは「最新イメージへの再デプロイのみ」で、DB とアップロードはアタッチストレージに保持されます。運用対象が 1 本に集約されている恩恵が、デプロイ・更新フローの単純さに現れています。

まとめ

Instatic は、Webflow / Framer / WordPress の代替として設計された自ホスト型ビジュアル CMS で、Bun 単一サーバー構成・QuickJS-WASM プラグイン隔離・パブリッシャーの 3 層設計という技術選択によって、「ビジュアル編集・データ所有・シンプル運用」の同時実現を狙っています。MIT ライセンス・SQLite / Postgres 対応・38 個の capability によるロール設計といった、自ホスト CMS に必要な要素は本体に揃っています。

一方で、現時点のバージョンは 0.0.x で、API・ワークフローの変動可能性、プラグインエコシステムの成熟度、first-party analytics の未実装は把握したうえで採用を検討する必要があります。既存の Payload・Directus・Strapi とは主戦場が異なり、それぞれの向き不向きを踏まえて選び分けるのが現実的です。

まず全体像を把握するなら Instatic README、設計思想を掘り下げるなら docs/architecture.md、拡張の作法を知りたければ docs/features/plugin-system.md と docs/features/publisher.md を確認するのがおすすめです。

関連情報

自ホスト型 CMS の導入検討や Web サイト・Web アプリケーションの受託開発をご検討中の方は、お問い合わせフォームからご相談ください。要件整理の段階からのご相談も承ります。

出典

• CoreBunch/Instatic GitHub リポジトリ
• Instatic README
• docs/architecture.md
• docs/features/publisher.md
• docs/features/plugin-system.md
• docs/deployment
• Headless CMS Showdown（DSRPT, 2026）
• Headless CMS Comparison 2026（dasroot）
• Payload vs Strapi vs Directus 2026（pkgpulse）