WebGL開発で起こる「作ってからできない」

「製品を3Dで見せたい」
「Webブラウザ上で製品を自由に操作できるようにしたい」
「WebGLを使って、これまでにない製品LPを作りたい」

WebGLや3Dを使ったWebコンテンツへの期待は高まっています。

一方で、WebGLを使った開発では、通常のWebサイトとは少し違った難しさがあります。たとえば、

「デザインとしては成立しているのに、スマートフォンでは重くて動かない」
「想定していた質感をブラウザ上で再現できない」
「3Dデータを入れてみたら、読み込みに時間がかかりすぎる」
「実装を進めてから、技術的に難しいことが分かった」

といった問題です。

こうした問題が公開直前に発覚すると、単純な修正では済みません。
設計を変更したり、3Dデータを作り直したり、表現そのものを見直したりする必要が出てきます。

結果として、スケジュールが延びたり、想定以上の工数が発生したりすることもあります。WebGL開発において重要なのは、

「どう作るか」だけではありません。
「そもそも、この仕様は実現できるのか」を作る前に確認することです。

WebGLは「作ってみないと分からない」ことが多い

WebGLは、ブラウザ上で3Dや高度なインタラクションを実現できる非常に自由度の高い技術です。その一方で、

• 3Dモデルのポリゴン数
• テクスチャの容量
• シェーダーやマテリアル
• アニメーション
• ブラウザの性能
• PCやスマートフォンの性能
• 通信環境
• 操作方法
• 画面サイズ

など、さまざまな要素が組み合わさって最終的な体験が決まります。そのため、

「技術的にはできそう」という段階と、
「実際の製品データを使って、想定している端末で快適に動く」という段階には、大きな違いがあります。
特に難しいのは、本格的に作り込んでから問題が発覚するケースです。

完成に近づいてから、

「この表現は重すぎる」
「この3Dデータではスマートフォン対応が難しい」
「この操作方法では使いにくい」

と分かっても、簡単には戻れません。
だからこそ、WebGL開発では「作る前」の検証が重要になります。

AgWORKSが考えるフィジビリティチェック

AgWORKSでは、本制作に入る前に、
「この仕様は本当に実現できるのか」
を確認することを重要な工程として考えています。

これを私たちは、フィジビリティチェック（事前検証）と呼んでいます。

フィジビリティチェックは、単なる「試作品を作ってみる」作業ではありません。
実際の案件で使用する3Dデータや想定する端末、操作方法などを踏まえて、

• 技術的に成立するか
• 想定している表現を実現できるか
• ユーザーがストレスなく操作できるか
• 本制作に進んでも問題がないか

を確認するための工程です。つまり、「作ってから問題を見つける」のではなく、「作る前に問題を見つける」ためのプロセスです。

本制作の前に確認する4つのポイント

AgWORKSでは、WebGL案件の内容に応じて、さまざまな項目を事前に検証します。

1．パフォーマンスは成立するか

まず確認するのが、実際にどの程度の負荷になるのかという点です。
3Dモデルのポリゴン数やテクスチャ容量、描画処理などによって、WebGLの動作負荷は大きく変わります。
特に重要なのがスマートフォンです。
高性能なPCでは問題なく動いていても、スマートフォンでは読み込みが遅かったり、フレームレートが低下したりすることがあります。

そのため、

• 想定端末での動作
• 読み込み時間
• ポリゴン数
• テクスチャ容量
• メモリ使用量
• FPS
• 画面サイズによる負荷

などを確認します。

「動くかどうか」だけではなく、「想定しているユーザー環境で、実用的に動くか」を見ることが重要です。

2．3Dデータ・ビジュアル表現は成立するか

製造業やプロダクト系のWebGLでは、3Dデータそのものも重要な検証対象になります。
CADなどで使用されている3Dデータを、そのままWebブラウザで使用できるとは限りません。
データ量を減らす必要があったり、マテリアルやテクスチャを調整する必要があったりします。

また、

「製品らしい質感を維持したい」
「金属の質感を表現したい」
「細かい形状まで見せたい」

といった要望があっても、すべてをそのままブラウザ上で再現できるとは限りません。そのため、

「どこまで再現するのか」
「何を残し、何を最適化するのか」

を事前に確認します。

3．操作性・UI/UXは成立するか

WebGLでは、3Dモデルが表示できれば完成というわけではありません。ユーザーが、

「どう操作するのか」
「どこを触ればいいのか」
「何が変わったのか」

を直感的に理解できることも重要です。たとえば、

• 回転
• 拡大・縮小
• 視点切り替え
• パーツ変更
• 色変更
• アニメーション
• 情報表示

など、複数の操作を組み合わせる場合があります。
PCではマウス操作、スマートフォンではタッチ操作になるため、同じ仕様でも操作感が変わります。
そのため、実際に操作できる簡易プロトタイプを作り、
「技術的にできるか」だけでなく「ユーザーにとって使いやすいか」まで確認します。

4．データ構造・運用方法は成立するか

WebGLコンテンツは、公開して終わりではありません。実際の運用では、

「製品を追加したい」
「画像を差し替えたい」
「3Dデータを更新したい」
「商品の情報を変更したい」

といったことが発生します。そのため、最初の開発段階から、

• 3Dデータをどのように管理するか
• 画像やテキストをどこで管理するか
• CMSやデータベースとどう連携するか
• 後から製品を追加できるか
• 更新作業を誰が行うのか

といった点も考えておく必要があります。
ここを後回しにすると、公開後の更新や機能追加で大きな改修が必要になることがあります。

「今動けばいい」ではなく、「公開後も運用できるか」まで考えて設計する。

これも事前検証の重要な役割です。

AgWORKSには「作る前に確かめる」ための環境があります

フィジビリティチェックを行うには、単に知識があるだけでは十分ではありません。
実際に試し、動かし、問題を確認できる環境が必要です。

AgWORKSでは、WebGLや3D開発を実際に行ってきた経験をもとに、開発前の検証環境を用意しています。たとえば、3Dデータを実際にWebGL上で表示し、

• ポリゴン数
• データ容量
• 読み込み時間
• メモリ使用量
• FPS

などを確認しながら、実現可能性を判断します。

また、PCだけではなく、スマートフォンなど実際の利用環境を想定して検証します。重要なのは、

「WebGLについて説明できる」ことではなく、「実際に動かして判断できる」こと。

AgWORKSでは、企画や仕様の段階から技術的な検証を行い、「できること」と「難しいこと」を早い段階で明確にすることを大切にしています。

なぜ「作る前」に検証するのか

WebGL案件で避けたいのは、公開直前になって問題が発覚することです。
本制作に入ってから問題が発覚すると、

• 設計を変更する
• 3Dデータを作り直す
• 表現を変更する
• UIを変更する
• 対応端末を見直す
• スケジュールを組み直す

といった対応が必要になります。つまり、問題そのものよりも、「問題を発見するタイミング」が重要なのです。
同じ問題でも、企画段階で分かれば、まだ選択肢があります。

「この表現を少し変える」
「この機能は別の方法で実現する」
「スマートフォンではこの仕様にする」
「3Dデータをこの条件に合わせて最適化する」

といった判断ができます。

一方、本制作が進んでから同じ問題が分かると、変更の影響範囲が大きくなります。だからこそAgWORKSでは、

「作れるかどうか分からないまま作り始めない」

ことを大切にしています。

事例：実際のWebGL開発では、どのように実現しているのか

AgWORKSでは、これまでさまざまなWebGL・3Dコンテンツを開発してきました。
単純に3Dモデルを表示するだけではなく、

• 製品をブラウザ上で操作する3Dコンテンツ
• 製品の組み合わせを確認するシミュレーター
• 3Dモデルを使ったインタラクティブなWebサイト
• バーチャル空間
• 製品やサービスを体験できるWebコンテンツ

など、目的に応じてさまざまな実装を行っています。
実際の事例については、こちらからご覧いただけます。

【WebGL・3D開発の事例を見る】

• WebGL開発事例

特に、製品を組み合わせながら確認するようなシミュレーター開発では、3D表示だけでなく、データ・UI・ルール・システムまで含めた設計が必要になります。

こうした開発では、最初に技術的な成立条件を整理することが、その後の開発をスムーズに進めるうえで重要になります。

「できる・できない」を早く知ることが、プロジェクトを守る

WebGL開発では、最初からすべての仕様を完璧に決める必要はありません。

むしろ、「まだ分からないことを、作る前に確認する」ことが重要です。

どこまでリアルな3D表現が必要なのか。
どの端末まで対応するのか。
どの程度の操作性が必要なのか。
3Dデータはそのまま使えるのか。
どこをシステム化する必要があるのか。

こうした不確定要素を一つずつ確認していくことで、プロジェクトのリスクを減らすことができます。

WebGLは自由度が高いからこそ、「何でもできる」と考えるのではなく、「どうすれば成立するか」を考えることが重要です。

WebGL開発を検討している方へ

「こんなWebGL表現は実現できるのか？」
「この3Dデータをブラウザで使えるのか？」
「スマートフォンでも動かしたい」
「製品シミュレーターを作りたい」
「まだ仕様が固まっていないが、技術的に可能なのか確認したい」

このような段階でもご相談いただけます。
AgWORKSでは、本制作に入る前の技術検証やプロトタイプ制作にも対応しています。

作ってから問題を見つけるのではなく、作る前に確かめる。

WebGL・3Dを使った企画をご検討でしたら、まずは実現可能性についてご相談ください。

• お問い合わせはこちらから。

WebGLで事故らないための資料も公開しています

WebGL案件を進める際に、

「何を確認すればいいのか分からない」
「企画段階で技術的なリスクを整理したい」

という方に向けて、AgWORKSの実務で考えているフィジビリティチェックの考え方を資料にまとめています。

『WebGLで事故らない、作る前のフィジビリティチェック
― WebGL製品LP制作における事前検証の考え方 ―』

この資料では、

• WebGL案件で起こりやすい「事故」
• 作る前に確認しておきたい項目
• パフォーマンスを判断するポイント
• 3Dデータを確認するポイント
• できること・できないことを判断する考え方
• プロジェクトを安全に進めるための事前検証

などを、実務視点で整理しています。

WebGL案件をこれから企画・検討する方は、ぜひご覧ください。

• 資料を無料でダウンロードする

【簡単シミュレーターとは】

パネル方式を採用し、様々なオプションの組み合わせが可能な三協フロンテア様のモバイルスペース。

本体の色、壁・窓・ドア、その他オプションを選ぶだけでお客様の理想の空間をカタチにできます。
そのモバイルスペースのパーツの組み合わせを、スマホから簡単にシミュレーションでき、その結果を見積もりに出力したり、AR表示もできるシステムが「簡単シミュレーター」です。

【簡単につくれる・見れる「だれでもシミュレータ」の機能を採用】

有限会社エージーワークスは「だれでもシミュレータ」をベースに、モバイルスペースという製品の持つ特長に合わせカスタマイズ開発を行いました。
今回のカスタマイズ開発では、だれでもシミュレータの「ウェブ上で3Dデータの登録および管理ができるシステム」「登録データを自動でAR化」など、基本の機能はそのままに、主にUIのカスタマイズを行うことで、モバイルスペースの製品特長に合わせた3Dシミュレーターを、短納期で開発・リリースいたしました。

3分でできる！簡単シミュレータ
https://www.sankyofrontier.com/light_simulator/

ー

開発結果：結果として、こんな状態が解消されました

三協フロンテア様には、もともと莫大な費用をかけて開発された高機能なシミュレータが存在していました。

ただその一方で、

• 操作が複雑で、使いこなせる人が限られる
• 詳しい営業担当者や、本気で検討している一部の顧客しか使わない
• Webからの集客や、初期検討フェーズでは活用しづらい

という課題も抱えていました。

今回開発した「簡単シミュレータ」は、既存の高機能シミュレータを置き換えるものではなく、検討の入口に立つ人のための“間口を広げる仕組み”として位置づけられています。

その結果、お客様は「難しい前提知識がなくても、自分の条件で大まかなイメージを掴める」ようになり、営業担当者は「説明の前に、理解度を揃える」という役割をWebに任せられるようになりました。

結果として、

・高度すぎて使われなかった既存シミュレータとの役割分担が明確になり
・Webからの流入ユーザーを無理なく検討フェーズに乗せられ
・「詳しい人だけが使うツール」から「誰でも触れる入口」へ

という状態が作られています。

ー

「詳しい人しか使えない仕組み」を、「誰でも触れる入口」に翻訳する。

こうした考え方で進めた事例があります。

こんなところにDIC
― 情報が多すぎて、たどり着けなかったケース

高畠ワイナリー ワインデータベース開発
― 専門的な情報を、楽しめる体験に翻訳したケース

ー

高畠ワイナリー様のワインデータベースを開発しました。

高畠ワイナリーのワインを、種別や品種、ブランドやビンテージなどから検索できるシステムになっています。

購入可能の商品は自動でECサイトへのリンクを表示。検索結果からそのまま購入も可能です。

また受賞歴からの検索や、認証情報の表示なども行なっています。

ー

開発結果：結果として、こんな状態が解消されました

高畠ワイナリー様では、多くのワイン情報や受賞歴、詳細なデータを保有していましたが、それらは主に業界関係者や詳しい人向けの文脈で整理されており、一般の来訪者にとっては少し距離のある情報になっていました。

そのため、

・ワインに興味はあるが、何を基準に見ればいいか分からない
・情報量は多いのに、楽しさや選びやすさにつながらない
・滞在時間が短く、記憶に残りにくい

といった状態が起きやすくなっていました。

今回のワインデータベース開発では、専門的なデータをそのまま並べるのではなく、
「知識がなくても、自然に辿り着ける導線」を重視しています。

その結果、

来訪者は
「詳しくなくても、自分の好みや関心からワインを探せる」ようになり、
ワイナリー側としても
「情報を説明する場」から「体験として伝える場」へと役割を広げることができました。

結果として、

・専門知識がないと楽しめなかった情報構造
・情報はあるのに、選ぶ体験につながらない状態
・初めて訪れた人が置いていかれてしまう導線

といった、“分かる人だけのサイト”になってしまう課題が解消されています。

ー

「詳しい人しか使えない仕組み」を、「誰でも触れる入口」に翻訳する。

こうした考え方で進めた事例があります。

こんなところにDIC
― 情報が多すぎて、たどり着けなかったケース

三協フロンテア：簡単シミュレータ
― 「詳しい人だけが使うツール」から「誰でも触れる入口」へ

ー

DIC株式会社様の「こんなところに！DIC」ページの開発を担当しました。
化学メーカーが持つ製品や技術は、私たちの生活のさまざまな場面で使われています。
一方で、製品や技術そのものを説明しようとすると、専門用語や情報量が多くなり、初めて訪れた人にとっては「自分に関係する情報がどこにあるのか」が分かりにくくなります。

そこで今回は、製品や技術そのものではなく、「暮らしの中の場面」を入口にするインタラクティブイラストマップとして設計・開発しました。

イラストの中を自由に見渡しながら、気になる場所を選ぶ。
そこから、その場所で使われている製品や技術へアクセスする。
複雑な情報を、「探して読む」から「触って見つける」体験へ変換した事例です。

情報量を減らすのではなく、「入口」を変える

DIC様が持つ製品・技術情報は非常に多く、専門性も高いものです。
すべてを一覧で見せようとすると、情報量そのものがユーザーにとってのハードルになります。
そこで、

「製品を探してください」ではなく、

「あなたの身近な場所から探してみてください」という入口をつくりました。

生活シーンを描いたイラストマップの中から、ユーザーが興味のある場所を選択。
そこから関連する製品や技術へ自然に移動できる構造としています。

専門的な情報を単純化するのではなく、ユーザーが理解しやすい順番に並べ替える。

これが今回のインタラクティブマップの設計思想です。

「見る」だけではなく、「触って探せる」マップに

今回のマップは、単なるイラストではありません。
画面の中に配置されたキャラクターや乗り物などをアニメーションさせ、ユーザーが触れながら探索できるインタラクティブコンテンツとして実装しています。

マップを自由に探索

マウスやタッチ操作による拡大・縮小、パン操作に対応。
広いイラストの中から、興味のある場所を自分で探すことができます。

イラストそのものをインターフェースに

キャラクターや建物、乗り物などのイラストを単なる装飾として扱うのではなく、情報への入口として設計。

「どこをクリックすればいいのか」を説明する前に、見れば触りたくなるUIを目指しました。

PCからスマートフォンまで

PCだけでなく、スマートフォン・タブレットでも利用できるようレスポンシブに対応。
タッチ操作でもマップを拡大・縮小しながら探索できます。

公開後も、情報を更新しやすい仕組みに

インタラクティブコンテンツは、公開した瞬間が完成ではありません。
製品情報が変わる。
新しい情報が追加される。
リンク先が変更される。

企業サイトとして長く利用していくためには、制作時の表現だけでなく、公開後にどのように運用・更新していくかまで考える必要があります。

今回のコンテンツも、公開後の運用を考慮し、情報を更新しやすい仕組みとして設計・開発しています。

インタラクティブな表現を維持しながら、必要な情報を運用側で変更・追加しやすくすることで、「作って終わり」ではないWebコンテンツを目指しました。

複雑な情報を、「分かる形」に翻訳する

今回の開発で重要だったのは、イラストを動かすことだけではありません。

化学メーカーが持つ専門性の高い情報を、ユーザーが自然に理解できる導線へ変換すること。そのために、

専門的な情報
↓
生活シーン
↓
興味のある場所
↓
関連する製品・技術

という順番で情報へたどり着ける構造をつくりました。
情報そのものを簡単にするのではなく、情報への入り方を変える。
これもWebコンテンツを開発する上で重要な設計だと考えています。

インタラクティブコンテンツは、「見せ方」まで設計する

Web上で動くコンテンツは、単にアニメーションを追加すれば成立するものではありません。
どこを動かすのか。
どこを触れるようにするのか。
どの情報をどの順番で見せるのか。
PCとスマートフォンで、どう操作方法を変えるのか。
そして、複雑な情報をどうすればユーザーに理解してもらえるのか。

AgWORKSでは、情報設計・UI・フロントエンド実装までを一体で考え、インタラクティブなWebコンテンツを開発しています。

「詳しい人しか使えない仕組み」を、「誰でも触れる入口」に翻訳する。

AgWORKSでは、専門的な情報や複雑な仕組みを、そのままユーザーに渡すのではなく、Web上で触れながら理解できる体験へ変換する開発を行っています。

参考事例

三協フロンテア｜簡単シミュレータ
「詳しい人だけが使うツール」から「誰でも触れる入口」へ。

高畠ワイナリー｜ワインデータベース開発
専門的な情報を、楽しみながら探索できる体験へ。

複雑な仕様でも、まずはご相談ください。

「こういうことはWebでできるのか？」そんな段階からでも構いません。

AgWORKSでは、企画・情報設計からUI、フロントエンド、インタラクション、システム実装まで、技術的な検証を含めて一緒に考えます。

技術的に難しい仕様も、まずはご相談ください。

お問い合わせ・ご相談はこちら

https://3d-simulator.com/?uid=comany&n=1&s=067067067067068004011

Xis-Frameとは
オフィスなどに自由に「空間」を設置できる製品。
基本となるフレーム間に、オプションパーツを自由に組み合わせられ、また、カラーや素材も自由に選べる製品になっています。

3Dパーツ制作し「だれでもシミュレータ」で構築
その組み合わせを自由に行えるシミュレータをAgWORKSで制作しました。
シミュレータに使う3Dパーツを弊社で制作、製品の各部位のカラーやオプションパーツが自由に選べるシミュレータシステムには「だれでもシミュレータ」を使用しています。

自由に組み合わせた結果をそのままAR表示、スマホVRでもご覧いただけます。

スマホVRでも表示できます。

Xis-Frameについてくわしくはこちらから

コミュニケーションプレイス Xis-Frame
https://www.comany.co.jp/products/lineup/xis-frame/

日本産科婦人科学会
産婦人科医の医学教育
ウェブサイトを制作しました。

公益社団法人 日本産婦人科医会
産婦人科医の働き方改革
ウェブサイトを制作しました。