ブラウザ上で 3D 建築モデルを作成・編集できる OSS「Pascal Editor」は、公開から 1 年未満で GitHub スター 20,000 を超える急成長を見せているプロジェクトです。React Three Fiber と WebGPU をベースに、Web の中だけで建築モデリングを完結させる思想を掲げています。
一方で、若いプロジェクトゆえに「本当に自社プロダクトに組み込んで大丈夫なのか」「SweetHome3D のような成熟した OSS とどう違うのか」「WebGPU 前提で問題ないのか」といった不安を抱える方も少なくないはずです。ドキュメントは英語中心で、日本語での技術解説記事もまだ多くありません。
本記事では、リポジトリのメタデータ・README・公式ドキュメントを一次情報として、Pascal Editor の位置づけ、リポジトリ構成、技術スタック、設計コンセプト、プラグインアーキテクチャ、類似 OSS との差分、採用時に確認すべきポイントまでを整理します。動作検証は行わず、公開情報だけを根拠にした「採用判断のための地図」を提供することを目的としています。記述はすべて執筆時点（2026 年 8 月）の情報である点にご注意ください。
Pascal Editor とは何か
Pascal Editor は、ブラウザ上で 3D 建築（建物）モデルを作成・共有するためのオープンソースエディタです。GitHub リポジトリの説明文には「Create and share 3D architectural projects.」とあり、住宅・商業建築・ゲームの背景モデル・デジタルツインなど、幅広い建築系ユースケースを想定した設計になっています。実装言語は TypeScript、実行環境はブラウザ、描画には WebGPU を採用しています。
一次情報として、以下 2 つを押さえておくとよいでしょう。
- リポジトリ本体: pascalorg/editor（GitHub）
- 公式サイト: editor.pascal.app
一言で表す Pascal Editor の位置づけ
Pascal Editor を一言で表すと、「ブラウザで完結する 3D 建築モデラ＋エディタ SDK」です。公式サイトによれば、機能は「Create → Edit → Present」の 3 段階ワークフローで整理されており、iOS アプリ「Pascal Capture」でスキャンした空間を取り込む、スケッチから AI で立体化する、壁の移動や家具の入れ替えといった編集、ファーストパーソンでのプレゼンテーションといった機能をブラウザ上で完結させています。
同時に、npm パッケージとしても公開されており、コアや Viewer だけを別の Web アプリに組み込むという使い方も想定されています。単なる「Web 版建築エディタ」ではなく、他プロダクトからも部品として利用できる SDK 的側面を持つ点が特徴です。
リリース時期とコミュニティ規模から見るメンテ状況
リポジトリのメタデータからは、以下の状況が読み取れます。
- 作成日: 2025-10-16
- 最終プッシュ日: 2026-07-30
- スター数: 20,434
- Fork 数: 2,642
archived: false（アーカイブされていない）fork: false（フォークではなくオリジナル）
作成からまだ 1 年未満というリリース直後のプロジェクトでありながら、20,000 を超えるスターと 2,600 を超える Fork を獲得しており、直近数か月以内にコミットが継続されています。アーカイブされておらず、他リポジトリからのフォークでもないため、独立したオリジナルプロジェクトとしてメンテナンスが続いていると判断できます。
一方で、リリースから 1 年未満という若さは、API や機能セットが今後も大きく変化する可能性を意味します。この点は後段の採用判断ポイントで改めて触れます。
MIT ライセンスと商用利用の可否
ライセンスは MIT です。MIT ライセンスは商用利用・改変・再配布・私的利用がいずれも許可される緩やかなライセンスで、原則としてライセンス表示さえ維持すれば、自社サービスへの組み込みや改造も可能です。同じ建築系 OSS でも SweetHome3D のような GPL 系のライセンスとは配布・改変・再配布の条件が大きく異なるため、この点は他 OSS との比較で重要な差分になります。
リポジトリ構成と npm パッケージ分割
Pascal Editor は、単一の Next.js アプリではなく、Turborepo によるモノレポとして構成されており、コア機能を複数の npm パッケージに分割しています。この構成が「フルエディタごと採用するか、Viewer だけ部分的に取り込むか」という意思決定に直結します。
モノレポ全体像
リポジトリはおおまかに以下のように分かれています。
apps/editor: Next.js アプリ本体（エディタ画面）packages/core: ノードスキーマ・Scene ストア・Registry・イベントバスなどの中核packages/viewer: 3D レンダリング（React Three Fiber ベース）packages/editor: 編集ツール・パネル・選択・ダイレクトマニピュレーション UIpackages/nodes: ビルトインの Registry Plugin（ノード定義・レンダラ・ジオメトリ・システム）
出典: pascalorg/editor README（GitHub）
4 パッケージの責務分担
README では、公開されている npm パッケージ 4 つの責務が明確に分離されています。
パッケージ | 責務 |
|---|---|
| Node スキーマ／Zustand ベースの Scene state／Registry の契約／空間クエリ／イベントバス |
| React Three Fiber を使った 3D レンダリング、共通レンダーシステム、デフォルトのカメラ・コントロール、post-processing |
| 編集ツール、パネル、選択、ダイレクトマニピュレーション UI |
| ビルトインの Registry Plugin（ノード定義・レンダラ・ジオメトリ・システム） |
出典: pascalorg/editor README（GitHub）
この分割によって、「フルエディタとして丸ごと採用する」以外に、「表示だけしたいので core + viewer + nodes を使う」「編集機能まで組み込みたいので editor も追加する」といった段階的な採用が可能になっています。
Viewer だけを埋め込むという選択肢
README では、公開パッケージを使った導入手順として、以下の抜粋が示されています。
npm install @pascal-app/core @pascal-app/viewer @pascal-app/editor @pascal-app/nodes
出典: pascalorg/editor README（GitHub）
さらに、プラグイン（ビルトインのノード群）は次のようにロードされます。
import { loadPlugin } from '@pascal-app/core'
import { builtinPlugin } from '@pascal-app/nodes'
await loadPlugin(builtinPlugin)
出典: pascalorg/editor README（GitHub）
つまり、外部サイトに「3D 建築モデルの閲覧機能だけ埋め込みたい」というユースケースであれば、core と viewer、そしてビルトインノードを提供する nodes を組み合わせるだけで最小構成を作れる設計になっています。既存の SaaS の一部として 3D プレビューを差し込む、といった採用パターンとも相性がよさそうです。
技術スタックと WebGPU 採用の意味
Pascal Editor の技術スタックは、Web フロントエンドの中でも比較的新しめの構成を積極的に採用しています。README に列挙されている主な技術要素は以下のとおりです。
- React 19
- Next.js 16
- Three.js（WebGPU renderer）
- React Three Fiber + Drei
- Zustand（状態管理）
- Zod（スキーマ検証）
- Zundo（undo/redo）
- three-bvh-csg（CSG 演算）
- Turborepo（モノレポ管理）
- Bun（パッケージマネージャ）
出典: pascalorg/editor README（GitHub）
自チームで受け入れられる技術構成かどうかは、後述する採用判断ポイントで整理しますが、まずは各技術がどこを支えているかを見ていきます。
描画レイヤー: Three.js（WebGPU）と React Three Fiber
3D 描画は Three.js の WebGPU renderer を使い、React 側からは React Three Fiber（R3F）＋ Drei で扱う構成です。WebGPU は WebGL の後継として策定された新しいグラフィックス API で、モバイル・PC の GPU 性能をより直接的に引き出せる設計になっています。Pascal Editor が単なる「Web で動く 3D エディタ」ではなく、比較的重いモデリング・レンダリング用途を想定していることが、この選択から読み取れます。
一方で、WebGPU は主要ブラウザで有効化が進んでいるものの、ユーザー環境によっては使用できない可能性もあります。この点は採用判断のチェックポイントとして押さえておくべきです。
状態管理: Zustand + Zundo と IndexedDB 永続化
シーン全体の状態は Zustand の useScene ストアで保持されます。ストアは nodes（フラット辞書）、rootNodeIds（ルートノード ID の列）、dirtyNodes（更新のあったノード ID の集合）といったフィールドを持ち、CRUD 操作のたびに変更対象のノードを「ダーティ」としてマークします。ミドルウェアには Persist（IndexedDB 永続化）と Zundo（50 ステップ相当の undo/redo）が組み合わせられており、Web アプリ単独で「編集内容の保存」と「操作履歴の遡り」を実現しています（出典: pascalorg/editor README（GitHub））。
Zustand は業務利用も多く、React エコシステムの中では扱いやすい選択です。既存プロダクトが Zustand を採用している場合、Pascal Editor のストア設計は比較的違和感なく受け入れられる可能性が高いといえます。
スキーマ検証（Zod）と CSG 演算（three-bvh-csg）
ノードのデータモデルは Zod で定義されたスキーマとして表現されます。ランタイムに型を検証できるため、プラグインが外部から追加するノードに対しても、スキーマ違反を検出しやすい構造になっています。
また、three-bvh-csg は Three.js 上で CSG（構成的立体幾何）演算を行うライブラリです。Pascal Editor の内部では、たとえば「壁に窓やドアの穴を切り抜く」といった処理でこの CSG 演算が使われています。建築モデリングにとって重要な要素をきちんと OSS のライブラリで賄っている点は、実装面での完成度を示すものといえるでしょう。
主要な設計コンセプト（Nodes・Systems・Registry）
Pascal Editor の設計を理解するうえで鍵になるのが、「Node（データ）」「Registry（3D オブジェクトへの参照）」「Systems（差分更新のロジック）」という 3 つの層の分離です。ECS（Entity Component System）的な発想に近く、シーンが大きくなっても更新コストを抑えられるよう工夫されています。
Node の階層モデル
Pascal Editor では、シーン全体が BaseNode を頂点とするノードの階層として表現されます。README で示されている主な階層は次のとおりです。
- Site（敷地）
- ├─ Building（建物）
- │ └─ Level（フロア）
- │ └─ Wall / Slab / Ceiling / Roof / Zone / Scan / Guide
- │ └─ Item（家具などのアイテム）
このツリー構造はコード上ではネストされたオブジェクトではなく、Record<id, Node> というフラットな辞書として保持され、各ノードが parentId と children のみで親子関係を表現します。フラット辞書 + ID 参照というモデルは、部分更新や差分同期を実装しやすく、大規模なシーンでもデータ操作を単純に保てる利点があります。
Scene Store（Zustand + Dirty Nodes）
Scene Store は Zustand で実装され、以下のようなフィールドを持ちます。
nodes: すべてのノードのフラット辞書rootNodeIds: ルートに位置するノードの ID 列dirtyNodes: 更新のあったノード ID の集合
CRUD 操作のたびに dirtyNodes へノード ID が追加され、後述の Systems 層がその集合を消化する形で処理を進めます。React の再レンダリングと Three.js のシーン更新を分離しつつ、シーン全体の一貫性を保つための重要な仕組みです。
Scene Registry と Renderers
Scene Registry は、ノード ID から実際の Three.js 上の Object3D への参照を保持するマップです。各レンダラは useRegistry フックを通じて自分自身の Three.js オブジェクトを登録し、Systems 側はこの Registry を経由して 3D オブジェクトへ直接アクセスできます。
レンダラ側は NodeRenderer がノードの type によってディスパッチする形で、WallRenderer や LevelRenderer などが呼び出されます。ノードのデータ定義とその見た目（レンダラ）が明確に分離されているため、新しいノード型を追加するときに「データ定義（core 側）」と「見た目（viewer 側）」を独立して実装しやすい構造になっています。
Systems と Dirty Nodes による差分更新
Systems 層には、WallSystem（CSG による窓・ドア切り抜き）、SlabSystem、CeilingSystem、RoofSystem、ItemSystem といったシステムが用意されています。これらは R3F の useFrame の中で毎フレーム呼ばれ、dirtyNodes に積まれた ID のノードだけを対象に処理を行うため、シーン全体を毎フレーム作り直すような無駄がありません。
「変更があった箇所だけを局所的に更新する」という発想は、大規模な建築モデルを扱うエディタにとって不可欠な最適化で、CSG や衝突判定といった計算量の大きい処理でも実用的な応答性を維持しやすくなります。
Event Bus と Spatial Grid Manager
シーン内で発生する操作は、mitt ベースの typed emitter による Event Bus 経由で配信されます。README では、たとえば wall:click や zone:context-menu、grid:click といったイベントが例示されており、UI 側やプラグイン側がこれらを購読することで、コンテキストメニュー表示や独自ツールの起動といった振る舞いを組み込めるようになっています。
また、家具などのアイテムを配置する際の衝突検出や、床スラブの高さ計算のために、Spatial Grid Manager が用意されています。ECS 的な部品分離と、空間データ構造による効率的なクエリを組み合わせている点は、単なる React コンポーネントの集合体ではない、エンジンとしての設計思想を感じさせるところです。
エディタツールとプラグインアーキテクチャ
Pascal Editor はエディタとしての標準ツール群を備えつつ、プラグインによる拡張を明示的にサポートしています。「自社ドメインに固有のノード型（たとえば什器・特殊什器・工場設備など）を追加したい」というニーズに対して、どこまで応えられるかを見ていきます。
標準ツールの一覧と役割
エディタアプリには、以下のような編集ツールが用意されています。
SelectTool: 階層的な選択マネージャ（親から子へ順に絞り込むような選択操作）WallTool: 壁の作成・編集ZoneTool: ゾーン（部屋・エリア）の指定ItemTool: アイテム（家具など）の配置SlabTool: スラブ（床・天井の板）の作成
これらは apps/editor/components/tools/ 以下に配置されており、UI レイヤーとエディタ機能の対応関係が把握しやすい構成になっています。
Plugin マニフェストと NodeDefinition
プラグインは、以下の 3 要素を持つマニフェストとしてエクスポートされます。
id:"company:plugin-name"の形式のネームスペース付き IDapiVersion: 現時点では1nodes:NodeDefinitionオブジェクトの配列
NodeDefinition は Zod スキーマと初期値に加えて、レンダラ、ツール、フロアプラン表現、AI 向けの説明といった要素を選択的に実装できます。データモデルと見た目・操作・AI 記述をひとまとまりにして拡張できるモデルで、独自のノード型を導入するときに、必要なものだけを段階的に埋めていける設計です。
詳細な仕様と受け付け可能な項目は、公式ドキュメントの Plugins ページ にまとめられています。
EditorHostPanel によるサイドバー拡張
エディタ本体のサイドバーには、プラグインが独自パネルを追加できる仕組みも用意されています。プラグインが EditorHostPanel を個別にエクスポートし、registerEditorHostPanel で登録することで、エディタ側のサイドバーに UI が差し込まれます。パネルは error boundary の内側でロードされるため、プラグイン側のバグでエディタ全体が落ちにくい設計になっています。
参考実装として、公式姉妹プロジェクトの pascalorg/plugin-trees（GitHub） が公開されており、プロシージャルな木・花・草の生成と、それらを配置するためのプリセットパネルを実装しています。プラグイン開発を検討する場合は、まずこのリポジトリが実装例として参考になるでしょう。
API v1 のスコープ制限（追加できないもの）
一方で、Plugin API v1 のスコープにはいくつかの制限があります。公式ドキュメントによれば、次のような拡張は現状 API では扱えません。
- 新しいルートやアプリケーションページの追加
- ホストストア（Scene ストアなど）の拡張
- 新しいマテリアルやフロアプラン用のプリミティブの追加
つまり、プラグインが担うのは主に「新しいノード型・レンダラ・ツール・サイドバーパネル」のレベルであり、エディタ本体のシェルやストア構造を書き換えるような拡張は API の対象外です。「独自ページを持ちたい」「サイドバーではなくヘッダーツールバーを丸ごと差し替えたい」といった要件がある場合は、プラグインとしてではなくフォーク・パッチとして対応することになります。
類似 OSS との比較
Pascal Editor の位置を掴むためには、既存の OSS と何がどう違うかを整理しておくのが有効です。ここでは、性質が異なる 2 つの OSS を比較対象として取り上げます。
比較サマリ
観点 | Pascal Editor | SweetHome3D | mehanix/arcada |
|---|---|---|---|
実行環境 | ブラウザ（WebGPU） | デスクトップ（Java） | ブラウザ（Pixi.js / WebGL） |
対象領域 | 3D 建築モデル（建物・レベル・ゾーン・スキャン等） | 住宅設計（家具中心の 2D+3D） | フロアプラン（2D 中心） |
主要技術 | React 19 / Next.js 16 / Three.js（WebGPU） / R3F / Zustand | Java Swing / Java3D | React / Pixi.js / Zustand / Mantine |
拡張モデル | Plugin API v1（npm パッケージ + マニフェスト） | プラグイン jar | 明示的なプラグイン API なし |
ライセンス | MIT | GPL 系 | MIT |
外部埋め込み | npm パッケージで Viewer 等を組み込み可 | 外部埋め込み非対応 | 単体アプリ中心 |
出典（比較対象）:
SweetHome3D との差分（成熟度 vs Web ネイティブ）
SweetHome3D は 2000 年代から続く成熟した OSS 住宅設計ソフトで、Java ベースのデスクトップアプリとして配布されています。豊富な家具ライブラリと、2D 平面図＋ 3D プレビューの同時表示に代表される、家庭ユーザー向けにこなれた操作性が強みです。一方で、実行環境はデスクトップに閉じており、Web アプリからの直接的な埋め込みには適していません。ライセンスも GPL 系で、自社サービスに組み込む場合はライセンス条件を丁寧に確認する必要があります。
Pascal Editor は逆に、Web ネイティブ・MIT・npm パッケージ配布を前提としており、「既存の Web サービスに 3D 建築機能を後付けする」という文脈では SweetHome3D よりも組み込みやすい構成といえます。反面、家庭ユーザー向け UI の完成度や、家具ライブラリの成熟度では歴史のある SweetHome3D に一日の長があります。「デスクトップに閉じた住宅設計ツールが欲しい」のか、「Web サービスの一部として建築モデリング機能を組み込みたい」のかで、選ぶ側が変わる関係にあります。
arcada との差分（2D フロアプラナ vs 3D 建築モデラ）
mehanix/arcada は、React + Pixi.js + Zustand で構築された 2D フロアプラン・インテリアデザインエディタです。ライセンスは MIT、ブラウザで動作するという点で Pascal Editor と共通する部分もあります。特に、Zustand を用いた状態管理という点は両者で共通しており、コード的な取っつきやすさは近いといえます。
一方で、arcada は 2D フロアプランに主眼が置かれ、Pixi.js による 2D WebGL 描画を採用しています。Pascal Editor が Three.js + R3F + WebGPU による 3D 建築モデリングを中心に据えているのとは、描画レイヤーも対象領域も大きく異なります。また、arcada はモノリシックな Web アプリとして構成されており、Pascal Editor のような「Viewer だけ切り出して外部に埋め込む」というモジュラリティは、現時点では想定されていません。
したがって、「2D で十分／プランニングと家具レイアウトが中心」なら arcada、「3D 表現が必須／モジュールとして SDK 的に組み込みたい」なら Pascal Editor、という棲み分けが自然です。
商用製品を検討している場合の判断軸
比較の外側にはなりますが、Planner 5D や Homestyler、Floorplanner のような商用 SaaS を候補としているケースもあるでしょう。これらはユーザー向け UI の完成度・アセットライブラリ・サポート体制が魅力ですが、コードを持たず、価格変動やサービス終了のリスクは常に付随します。「自プロダクトの中核機能に据えるならコードを握れる OSS が望ましい」「機能の一部だけを SaaS として使えれば十分」といった判断軸は、Pascal Editor と商用製品との使い分けにも当てはまります。
Pascal Editor 採用時の評価ポイント
最後に、Pascal Editor を実プロジェクトに採用するかどうかを判断するうえで、事前に確認しておきたい点を整理します。
コミュニティ健全性と若さのバランス
前述のとおり、Pascal Editor は 2025 年 10 月にリリースされた比較的若いプロジェクトです。それにもかかわらず、スター 20,434／Fork 2,642 という規模を獲得し、最終プッシュは 2026 年 7 月と直近まで活発です。archived／fork フラグはいずれも false で、独立したオリジナルプロジェクトとしてメンテナンスが継続していると読み取れます。
一方で、リリースから 1 年未満というのは、外部 API・データスキーマ・パッケージ構成が今後も破壊的に変わる可能性が十分ある期間です。バージョンをピン留めして追随戦略を明確にする、あるいはメジャーリリースを跨ぐ更新には慎重にレビュー時間を割く、といった運用ルールを予め用意しておくのが安全です。
WebGPU 対応ブラウザ／実行環境の前提
Pascal Editor は WebGPU を前提としています。WebGPU は主要ブラウザで有効化が進んでいる一方、企業内の管理端末や古い端末など、環境によっては利用できない可能性が残ります。BtoB 向けのプロダクトに組み込む場合は、対象ユーザーのブラウザ環境を事前に整理し、フォールバック UX（利用不可時にどのようなメッセージを表示するか）を設計しておく必要があります。
React 19 / Next.js 16 / Bun という前提スタックへの適応可否
技術スタックとしては、React 19、Next.js 16 という比較的新しめのメジャーバージョンを前提としています。既存プロダクトが React 18 系や Next.js 14 系にとどまっている場合、まずは自社側のバージョンアップ計画とすり合わせる必要があります。また、開発体験としては Bun がパッケージマネージャとして採用されており、README 上の起動コマンドも bun dev が想定されています（turbo build によるビルドや turbo build --filter=@pascal-app/core による個別ビルドも README に記載されています）。
npm パッケージとしての利用側（自社アプリからの npm install）は Bun を必須としませんが、Pascal Editor 本体の開発・コントリビュートを視野に入れる場合は、Bun を開発環境として受け入れられるかを確認しておくとよいでしょう。
Plugin API v1 のスコープ制限を踏まえた拡張限界
プラグインアーキテクチャは強力ですが、API v1 のスコープには制限があります。新しいルートやアプリケーションページの追加、ホストストアの拡張、新規のマテリアルやフロアプラン用プリミティブの追加といった、エディタ本体のシェル・データ基盤に踏み込む拡張は現状の API では扱えません。詳細は 公式プラグインドキュメント に整理されています。
「独自ノード型と、それを扱うツール・パネルを追加する」というレベルの拡張であれば、API v1 の範囲でおおむね対応可能です。一方、「Pascal Editor をベースにまったく異なる UX の別アプリを作りたい」「エディタのシェル自体を差し替えたい」といった要件がある場合は、プラグインではなくフォークして自前パッチを当てる前提での運用が現実的です。参考実装として pascalorg/plugin-trees（GitHub） を確認し、自社要件がその範疇に収まるかを見極めるのがよいでしょう。
まとめ
Pascal Editor は、React Three Fiber と WebGPU を軸にした、ブラウザ完結型の 3D 建築モデラ／エディタ SDK です。@pascal-app/core・@pascal-app/viewer・@pascal-app/editor・@pascal-app/nodes の 4 パッケージに機能が明確に分割されており、「フルエディタとして採用」「Viewer だけ組み込む」といった段階的な採用がしやすい設計になっています。Node・Registry・Systems の分離や、Dirty Nodes に基づく差分更新、Zod スキーマと CSG 演算を組み合わせたモデリング基盤など、単なる React 製 3D ビューアではなく、エンジンとして構築されている点も特徴です。
競合となる OSS の中では、SweetHome3D のような成熟したデスクトップ製品や、arcada のような 2D フロアプラナと、実行環境・対象領域・ライセンス・拡張モデルの各軸で明確に立ち位置が異なります。デスクトップ配布や 2D 中心の設計で十分なユースケースであれば既存の OSS が向く場面もありますが、「Web サービスの中に 3D 建築機能を組み込みたい」「MIT ライセンスで自社プロダクトに載せたい」「Plugin API を通じて独自のノード型を追加したい」といったニーズには、Pascal Editor が有力な候補になります。
一方で、リリース直後ゆえの API 変動リスク、WebGPU の対応環境、React 19 / Next.js 16 / Bun という前提スタック、Plugin API v1 のスコープ制限は、採用前にチームで確認しておくべき評価ポイントです。まずは pascalorg/editor（GitHub） の README と、公式サイト、そして 公式プラグインドキュメント を一次情報として読み込み、自社の要件との適合度を判断する、というアプローチをおすすめします。
なお、本記事のリポジトリ属性（スター数・Fork 数・作成日・最終プッシュ日）は執筆時点（2026 年 8 月）に GitHub API から取得した値に基づいています。最新の値はリポジトリ本体でご確認ください。
