オープンソースの建築エディタには、データモデルを確認できること、実行場所を選べること、狭い用途向けの拡張や自動化を追加できることという利点があります。しかし、それだけで既存の設計ワークフローを安全に置き換えられるわけではありません。見るべきなのはデモの見栄えではなく、代表的なプロジェクトが編集、受け渡し、自動化、復旧、アップグレードを通過し、検証可能な証拠を残せるかどうかです。
Pascal Editor はこの評価に適した例です。公式リポジトリは、React Three Fiber と WebGPU を使うローカルファーストの3D建築エディタで、CLI とエージェント向け MCP 接続を備えると説明しています。MIT ライセンスで、viewer、core、editor、node、CLI を公開パッケージに分けています。一方、最初の 1.0 は明示的に beta であり、通常の安定チャネルは 0.x のままです。試す価値はありますが、慎重な試験が必要です。

この画像は GitHub とオープンソースの文脈を示す説明用のものです。Pascal Editor の画面や導入事例ではありません。
守るべき実業務から始める
住宅レイアウト、設備レビュー、コンフィギュレータ、現場キャプチャの受け渡しなど、小さくても実在する業務を一つ選びます。入力、関係者、次工程の出力、失敗のコストを決めます。空のシーンでの見栄えは試験になりません。壁、部屋、階、材質、開口部、寸法、分類、添付情報のうち何を保持すべきかを明文化します。表示用ならメッシュで足りても、調整業務では意味を持つオブジェクトと属性が必要かもしれません。
機能表より先にプロジェクトの寿命を試す
最小の実案件を作成または読み込み、代表要素を編集し、保存、終了、再起動、複製、下流向け出力まで行います。アプリ、プラグイン、入力、出力の正確な版を記録します。使い捨てコピーでは保存中断やプラグイン削除、固定版の更新後に旧案件を開く復旧手順も確認します。Pascal の変更履歴には、保存、読込、複製、同期で材質が落ちる問題の修正があります。公開 issue には保存・読込往復でコレクションが失われる報告もあります。全利用者の障害を示すものではありませんが、永続化を明示的な受入条件にする十分な理由です。
読み込み成功と互換性を混同しない
見た目が正しいインポートでも、後で必要な情報を失うことがあります。実際の交換境界で、代表ファイルを読み込み、重要な属性と関係を調べ、小変更して次のツールへ渡します。ファイル、元アプリ、保持属性、編集可能範囲、出力、未確認点、確認者を短い表にします。「壁を読めた」では不十分です。「このファイルでは壁と階高は保持され、自前分類は未検証」が判断に使えます。地形、垂直モデリング、プラグイン、GLB/STL/OBJ 出力は試験仮説であり、完全な IFC や独自形式の往復保証ではありません。
拡張とエージェントに境界を設ける
プラグイン、自作ノード、テンプレート、保存アダプタ、外部 API には担当、対応版、試験案件、ロールバックを持たせます。AI も同様です。ローカル MCP が構造化ツールを与えても自動的に安全にはなりません。最初は読み取り専用か使い捨て案件に限定し、編集の事前表示、最小権限、変更記録、人の戻し操作を必須にします。エージェントの説明ではなく、変更後のオブジェクト、出力、スナップショットを確認します。MCP 接続に関する公開報告は、使うクライアント、認証、接続寿命を実測すべき理由です。
星や fork、頻繁なリリースは注目度の指標であり、互換性、性能、安全性、専門利用の証明ではありません。検証済み版を固定し、原ファイルを保管し、証拠、未解決リスク、担当、見直し日を記録してください。オープンなエディタはコンフィギュレータ、教育、社内レビュー、エージェント試作には適しても、基幹設計は既存製品に残す判断があり得ます。約束ではなく、実際のシステムの証拠で役割を決めるべきです。
一次情報、製品ドキュメント、実際の利用シーンをもとに、あなたのワークフローに合うツールかどうかを判断しやすくする記事を作成しています。
