Grasshopperで開発した便利なプログラムをいかに幅広いユーザーに使ってもらうか、というのは永遠の課題ですよね。
2020年にRhinoから叩けるREST APIをRhino.Inside + Django Rest Frameworkでつくるという記事を書いて以来、Rhino.Computeがリリースされたり、Webアプリケーション周りの技術も進歩していたりと、技術的なハードルがかなり下がってきました。
最近またこういったことに興味を持つ方の話をちらほら聞いたので、2025年時点でのGrasshopperのWebアプリ化戦略について考えてみました。
※この記事ではRhino/Grasshopperに限って書いていますが、Revit/Dynamoなどでも同様のことが言えると思います。
Grasshopperで作ったプログラムを展開するのは難しい
せっかく作った便利なプログラムが社内でなかなか普及しない、という経験をされた方は多いのではないでしょうか？
私自身も組織設計事務所時代に嫌というほど経験しましたが、原因は主に以下の4つではないかと思います。
そもそもRhino+GHユーザーが少ない
設計者の中だけでもRhino+GHを使っている人が限られる上、現場やマネージャ層まで広めようとするとライセンスの問題も出てきます。
使ってほしいのはプログラムなのに、まずRhinoやGrasshopperの使い方から慣れてもらわないといけないという導入の時間的コストも大きくなりがちです。
ユーザーの環境に依存する
RhinoやGrasshopperで実行するプログラムは、インストールされているバージョンの影響を受ける可能性が高いです。
同じプログラムなのにバージョンが違うだけで動かない、入っているプラグインが悪さをして動かない、など個々にサポートが必要になります。
GrasshopperのUIが難しい
元々Grasshopperは設計者がコードを書く代わりにグラフィカルなインターフェイスでプログラムを構築するのエディターとして作られています。
操作してほしいのはスライダーだけなのに、それ以外のコンポーネントが視界を邪魔してわかりにくい印象を与えてしまう、間違ってコードを書き換えてしまい動かなくなる、といったリスクもあります。
メンテナンスが難しい
Grasshopperの場合は.ghファイルを配布して使ってもらう必要があるので、コードを更新するたびに.ghファイルを配布し直して最新のファイルを使ってもらう必要があります。
新しいバージョンが動かない人が出てきたり、そもそも周知が行き届かなかったりして古いファイルを使い続けている人が発生し、結果として複数バージョンのサポートをし続けることになります。
Webアプリ化のメリット
ユーザーの環境やスキルに依存しない
Webアプリ化することでブラウザさえあればアプリケーションが動作するので、（ブラウザごとの対応が必要なケースもありますが）ユーザーの環境に左右されるリスクが大幅に減少します。
また必要な機能を使いやすいようにインターフェイスを作れるので、RhinoやGrasshopperの前提知識を必要とせずに導入することができるようになります。
リッチでユーザーフレンドリーなインターフェイスが作れる
WebのUIに関する技術はかなり成熟しているので、ユーザーフレンドリーでおしゃれなインターフェイスを作ることができます。
またユーザーの種類によってUIを変えて提供することもできるので、そのユーザーにとって必要な情報だけを必要な順番で見せることができます。
メンテナンスしやすい
基本的にWebアプリはサーバーで動作するので、サーバーのコードを更新すればユーザー全員に対してアプリを更新することができます。
サーバーを2つ用意して開発環境と本番環境を分けてリリース前に新機能をテストをしたり、CI/CDパイプラインを構築して自動的に更新がリリースされるようにしたりと、メンテナンスにかかるリスクや労力を大幅に削減することができます。
Webアプリ化する戦略
実際にGrasshopperで構築したプログラムをWebアプリ化しようとした場合、いくつかの方法が考えられます。
プログラムの複雑さや重さ、Rhino/GrasshopperのAPIへの依存度によって適切に選択する必要があります。
1. Webアプリ+Rhino.Computeサーバー
プログラムを移植する工数が少なく、Rhino/Grasshopperの処理をそのまま使えるので、Rhino独自の幾何学処理やプラグインを使っている場合に適しています。
メリット
- サーバーでRhinoを動かしているだけなので、Ladybug Toolsなどのプラグインをインストールしておけば環境シミュレーションも走らせることができます。
- また、Rhino.Computeには独自開発したRhinoプラグインを動かしたり、Grasshopperファイルをそのまま動かしたりする機能のあるので、既存のコードを大きく変更する必要なくサーバーに実行させることができるようになります。
- この場合、WebアプリはRhino.ComputeのREST APIを叩くだけなので、ユーザーが入力した情報をRhino.Computeに渡せるように変換したり受け取った結果を表示する部分のUIを開発するだけです。
デメリット
- Rhino.Computeの開発環境を構築する必要があります。Windows Serverが必要だったり、Rhino.Compute自体の実行コストがかかったりと、開発・運用コストが他の方法よりもかかります。
- Rhino/Grasshopperに依存することになるので、Rhino/Grasshopperのアップデートに対応する必要があります。
2. Webアプリのみ
既存プログラムの全ての処理をWebアプリに移植し、フロントエンドのみで完結させる方法です。
既存プログラムの処理がRhino/Grasshopperに依存していない、もしくは代替可能で、計算処理があまり複雑ではない場合に適しています。
メリット
- フロントエンドで一般的に使われるThree.jsのようなブラウザ上で3Dを扱うためのライブラリには、ブラウザに3Dオブジェクトを表示させる以外にもレイキャストなど簡単な幾何学処理も扱うことができます。
- 処理によってクライアントサイド（ブラウザ）かサーバーサイドどちらで処理を実行するかを設定できます。
- フロントエンドのみで完結するので管理するサーバーも少なくて済み、運用やメンテナンスのコストが抑えられます。
デメリット
- 全ての処理をWebアプリのコードに移植する必要があるので、開発工数が多くなる可能性があります。
- クライアントサイドで幾何学処理を実行する場合は、ユーザーの端末スペックに依存します。
- サーバーサイドで幾何学処理を実行する場合はWebアプリサーバー自体のスペックを上げたり、リクエストを効率よく処理するためのコードを書く必要があります。
3. Webアプリ+ジオメトリ処理サーバー
1と2の中間のような方法ですが、ジオメトリ処理サーバーを別に用意して、Rhino/Grasshopperへ依存しないようにジオメトリ処理をソフトウェアに依存しない形に移植します。
例えば、PythonにはShapelyのように幾何学処理を扱うライブラリがあったり、rhino3dmのようにRhinoのジオメトリを扱ったり簡単な処理ができるようなライブラリもあるので、それらを駆使してサーバー上で幾何学処理を実行するようにします。
もし既存のコードの幾何学処理がRhino/Grasshopperに依存しておらず、移植するのが比較的容易な場合は、この方法が適しています。
メリット
- Webアプリのみの場合に比べて幾何学処理のライブラリが充実しているので、より複雑な幾何学処理も比較的容易に実装できます。
- Rhino.Computeのようにソフトウェアが必要ないので、サーバーで処理する時のオーバーヘッドが比較的少なくなります。
- Rhino.Computeと比べてWindows Serverが不要だったり、Rhino.Computeの課金がないため運用・メンテナンスコストは抑えられます。
- Webアプリのサーバーとは別のサーバーを立てるので、それぞれにとって最適なスペックのサーバーを使うことができます。
デメリット
- Rhino/Grasshopperに依存するようなコードは実行できません。
- Webアプリのサーバーとジオメトリ処理サーバーを別々に構築する必要があるため、2の方法に比べると開発・運用コストがかかる可能性があります。
- ジオメトリ処理サーバーのスペックを上げたり、リクエストを効率よく処理するためのコードを書く必要があります。
これらの方法のメリット・デメリットを表にまとめるとこのようになります。
| 評価項目 | Webアプリ+Rhino.Compute | Webアプリのみ | Webアプリ+ジオメトリ処理サーバー |
|---|---|---|---|
| 開発コスト | 〇 | 〇 | △ |
| 移植の工数 | 〇 | △ | △ |
| 運用コスト | △ | 〇 | △ |
| RH/GHプラグイン対応 | 〇 | × | × |
| 複雑な幾何学処理 | 〇 | △ | 〇 |
| サーバーのOS依存 | × | 〇 | 〇 |
| クライアント負荷 | 〇 | △ | 〇 |
| サーバー構成の複雑さ | △ | 〇 | △ |
| メンテナンス性 | △ | 〇 | △ |
技術選定
幾何学処理を行うWebアプリを開発するときに個人的によく使う技術と、どうやってそれらから必要な技術を選定するかをご紹介します。
フロントエンド
フレームワーク
ほとんどの場合JavaScript/Typescriptを使って書くことになると思います。3Dを扱うのにおすすめのフレームワークがあると言うわけではないですが、フロントエンド開発初心者が新しく始める場合はできるだけリファレンスが多いReactやVue.jsをまずは触ってみることをお勧めします。v0やbolt.new、LovableなどのAIサービスを使う場合もこの辺りの基礎知識があると扱いやすいです。
3Dビューアー
扱うデータ形式よって変わってきますが、代表的なものを挙げておきます。
- Three.js - WebGLを扱いやすくしたライブラリで、3dm、gltf 、STL、objなど汎用的なな3Dオブジェクト形式を扱う場合に適しています。カスタマイズ性が高い分他の2つに比べて元から用意されている機能はないので、必要な機能を自分で実装する必要があります。React向けにはReact Three Fiberというライブラリがあるので、Reactを使う場合はそちらを使うと良いでしょう。
- Babylon.js - こちらもWebGLを扱いやすくしたライブラリで、Three.jsと同じように3Dオブジェクトを扱うことができるライブラリですが、Three.jsよりもゲーム向けに開発されており、ライブエディタやモジュール化機能などが充実しています。
- Open BIM Components(旧IFC.js) - IFCを扱うためのライブラリです。ビューアーとしての機能もありますが、IFCのデータを扱うためのライブラリとしても使うことができます。
- Speckle Viewer - Speckleが提供するビューアーライブラリです。ビューアーとしての機能が充実していて拡張機能も追加できるので、Speckleでデータを管理している場合は特におすすめです。
- APS Viewer - Autodesk関連のデータを扱う場合におすすめです。ACC上のデータを簡単に表示できたり、多くのデータ形式に対応しています。Three.jsをラップする形で開発されていますが、使われているThree.jsのバージョンアップの頻度が高くないので、最新のThree.jsの機能は使えない場合があります。
UIライブラリ
フレームワークによって異なりますが、ほとんどの必要なUIコンポーネントはUIライブラリを使うことで実装できます。今回はReactを例に個人的なおすすめを挙げますが、Vue.jsでも同様のものがあるので参考にしてください。
- MUI - GoogleのMaterial Designを実装したUIライブラリで、コンポーネントも豊富でカスタマイズ性が高いです。
- shadcn/UI - Tailwind CSSを使ったUIライブラリで、依存関係としてインストールすることなく、必要なコンポーネントだけをインストールして使うことができます。
ホスティングサービス
ほとんどの場合はクラウドサービスを使ってホスティングすることになると思いますが、最近はサーバーレスでホスティングできるサービスも増えてきました。ここでは代表的なものを挙げておきます。
- Vercel - ReactやNext.jsのホスティングサービスで、CI/CDの機能も充実していて、GitHubと連携することで自動的にデプロイしてくれます。
- Netlify - Vercelと同じようなホスティングサービスで、こちらもGitHubと連携して自動デプロイが可能です。
- AWS Amplify - AWSのホスティングサービスで、VercelやNetlifyと同じようにGitHubと連携して自動デプロイが可能です。AWSの他のサービスとも連携しやすいので、AWSを使っている場合は特におすすめです。
バックエンド
幾何学処理をバックエンドで実行する場合や、データベースとの連携、認証機能、APIなどを実装する場合はバックエンドを構築する必要があります。
フレームワーク
Webアプリケーションやデータベースとのやり取りを担当するフレームワークです。
Next.jsやNuxt.jsのようにフロントエンドとバックエンドを同時に構築できるフレームワークもあったり、次に紹介するBaaSのサーバーレスなファンクション機能を使うことで独自にバックエンドを構築する必要がない場合もあります。
言語によって異なりますが、代表的なものを挙げておきます。
- Javascript/Typescript
- Express.js - Node.jsのフレームワークで、シンプルで使いやすいです。
- Nest.js - Node.jsのフレームワークで、TypeScriptを使ったオブジェクト指向プログラミングができるので、バックエンド開発初心者におすすめです。
- Python
BaaS
BaaS（Backend as a Service）を使うことで、バックエンドの構築を簡単にすることができます。データベースや認証機能などを提供してくれるので、バックエンドの構築が簡単になります。
- Firebase - Googleが提供するBaaSで、データベースや認証機能などを提供してくれます。規模が大きくなったらGCPとの統合もスムーズにできます。
- Supabase - Firebaseのオープンソース版で、PostgreSQLを使ったデータベースや認証機能などを提供してくれます。アップデートのスピードも早くDev Relも活発でわかりやすい資料や動画が多いので、個人的には気に入って使っています。
- AWS Amplify - BaaSとしての機能も持っていて、データベースや認証機能などを提供してくれます。AWSの他のサービスとも連携しやすいので、AWSを使っている場合は特におすすめです。
幾何学処理
前章でご紹介した通り幾何学処理をアプリに組み込むには、外部のサーバーを建てる方法やWebアプリ内にコードを移植方法する方法などがあります。
外部サービス
- Autodesk Platform Service - Autodeskが提供するAPIで、Autodeskのデータを扱うことができます。Design Automationを使うことでRevitで行う操作を自動化することができます。そのほかにもデータの抽出や変換をするためのAPIが用意されているので、Autodeskのデータを扱う場合は特におすすめです。
ライブラリ／API
- Rhino.Compute - RhinoのAPIを使ったREST APIで、RhinoやGrasshopperの処理をWebアプリで実行することができます。Rhino.ComputeはRhinoのAPIを使っているので、RhinoやGrasshopperの処理をそのまま使うことができます。
- rhino3dm - Rhinoのジオメトリを扱うためのライブラリで、Rhinoが入っていなくてもRhinoのジオメトリを扱ったり簡単な処理ができるようなライブラリです。PythonやJavaScriptで使うことができるので、Webアプリで3dmファイルを読み込んだり書き出したりすることもできます。
- Shapely - Pythonで書かれた幾何学処理ライブラリです。RhinoやGrasshopperに依存しないので、Webアプリで使うことができます。
さいごに
今回ご紹介した内容はあくまで一例であり、実際の開発においてはプロジェクトの要件やチームのスキルセットに応じて適切な技術を選定する必要があります。サービスやライブラリについても、2025年4月時点での私の知識や経験に基づいているため、今後の技術の進化や新しいサービスの登場によって変わる可能性があります。特にWebアプリケーションは日々進化しているので、最新の情報を常にキャッチアップすることが重要です。
Discussion