サービスラインナップ
これまでの実績
AgWORKSの技術
エージーワークスについて
LOGIN
2026.08.15

オリジナル商品をユーザー自身にデザインしてもらうため、デザインシミュレータを導入したい。
そう考えたとき、最初に「どんな機能を入れるか」を考えるケースは多いかもしれません。
画像をアップロードできるようにする。文字を入力できるようにする。色を変更できるようにする。デザインした商品を3Dで確認できるようにする。完成したデータを保存できるようにする。
もちろん、これらはデザインシミュレータを構成する重要な機能です。
ただ、実際にシステムを開発していくと、機能そのものより先に考えておかなければならないことがあります。
それは、「この商品を、Web上でどのように扱うのか」ということです。
同じように見える商品でも、変更できる部分、デザインできる範囲、印刷方法、素材、サイズ、製造工程などは異なります。商品によってシミュレータの仕組みも変わるため、最初に商品をどう定義するかによって、その後の開発や運用のしやすさが大きく変わります。
デザインシミュレータを作ることが目的なのではなく、自社の商品をユーザーがデザインし、注文し、実際の商品として受け取るまでの流れを、どのようにシステムとして成立させるか。
そこから考える必要があります。
【自社の商品をシミュレータ化できるか相談する】
デザインシミュレータを作るとき、商品を一枚の画像や3Dモデルとして考えてしまうと、開発の途中で仕様が複雑になることがあります。
実際の商品には、色、サイズ、素材、パーツ、デザイン可能な範囲、印刷方法など、さまざまな条件があります。
例えば、ある部分には画像を配置できるけれど、別の部分には配置できない。商品カラーによって使えるデザインが変わる。印刷方法によって利用できる色や画像に条件がある。サイズによってデザイン可能な範囲が変わる。
ユーザーから見ると、単に「商品をデザインしている」だけでも、システム側ではさまざまな条件を判断しながら画面を表示する必要があります。
そのため、シミュレータの開発では、商品の見た目を再現するだけでは十分ではありません。
商品を構成している要素と、それぞれの条件を整理し、それをシステム上で扱える形にしていく必要があります。
ここを最初に整理しておけば、後から商品を追加したり、仕様を変更したりするときにも対応しやすくなります。
デザインシミュレータの打ち合わせでは、「画像を入れたい」「文字を入れたい」「3Dで見たい」といった機能の話から始まることがあります。
しかし、機能だけを先に決めてしまうと、実際の商品との関係が分からなくなることがあります。
例えば、「カラー変更」という一つの機能を考えても、単純に画面の色を変えるだけなのか、実際の商品として選択できるカラーを変更するのかでは意味が違います。
「画像を配置する」という機能も、どこにでも自由に配置できるのか、印刷可能な範囲だけに限定するのか、商品の面ごとに設定するのかによって、必要な仕組みは変わります。
だからこそ、AgWORKSでは機能を並べてシミュレータを作るのではなく、まず商品そのものを確認し、その商品をWeb上でどのように扱うべきかを考えます。
商品がどのような構造になっているのか、どこを変更できるのか、どこにデザインできるのか、最終的にどのようなデータが必要になるのか。
そうした情報を整理したうえで、必要な機能を決めていきます。
3Dシミュレータの場合、この考え方はさらに重要になります。
商品を3Dモデルとして表示するだけなら、商品全体を一つのモデルとして扱うこともできます。
しかし、ユーザーが商品の色やパーツを変更したり、特定の場所にデザインを配置したりする場合には、3Dモデルの構造やUVマッピング、テクスチャの扱いまで考える必要があります。
これらはシミュレータの画面を作り始めてから考えるものではありません。
商品をシミュレータ化する段階で、3Dデータの構造とシステム上の機能を合わせて考える必要があります。
AgWORKSでは、3DCGのモデリングやUVマッピングから、WebGLを利用したブラウザ上の3D表示まで扱っているため、商品データとシステムの両方を確認しながら設計できます。
商品設計を考えるうえで、もう一つ重要なのが「シミュレータの中で完成したデザインを、その後どうするのか」ということです。
ユーザーがブラウザ上でデザインを完成させたとして、そのデータを保存するだけなのか、注文情報として利用するのか、印刷用データまで生成するのか、担当者が確認してから製造するのか。
ここまで決めなければ、シミュレータに必要なデータ構造も決まりません。
画面上で正しく表示できればよいデータと、印刷や製造に利用するデータでは必要な情報が異なる場合があります。
AgWORKSでは、Webシステムだけでなく、グラフィックデザインや印刷入稿についても経験があるため、デザインを作る画面だけでなく、その後の工程まで含めて検討できます。
「シミュレータでデザインできる」ことと、「シミュレータで作ったデザインを商品にできる」ことは、同じではありません。
商品化までを考えて初めて、必要な機能やデータの持ち方が決まってきます。
【デザインから入稿・製造までの流れを相談する】
デザインシミュレータを導入した後、「次の商品も対応したい」という話になることがあります。
最初の商品だけを前提にシステムを作っていると、新しい商品を追加するたびに大きな改修が必要になることがあります。
商品ごとに異なる部分と、共通して利用できる部分を分けておくことで、商品追加に対応しやすくなります。
例えば、商品ごとに3Dモデルやデザイン可能範囲が違っていても、ユーザーがデザインを作成する基本的な仕組みは共通化できる場合があります。
商品カラーや印刷方法、素材、サイズなどについても、システムそのものを変更するのではなく、管理するデータを変更することで対応できる設計にできる場合があります。
もちろん、すべての商品を同じ仕組みで扱えるとは限りません。
だからこそ、最初の商品を作る段階で「この先、商品が増えたらどうするか」を考えておくことが重要になります。
システムは公開したら終わりではありません。
実際にユーザーが使い始めると、商品を追加したい、デザイン素材を増やしたい、注文方法を変更したい、既存のECと連携したいなど、当初は想定していなかった要望が出てくることがあります。
また、商品そのものが変わることもあります。
新商品が追加される。既存商品の仕様が変更される。印刷方法が増える。価格体系が変わる。
こうした変化に対応できるかどうかは、シミュレータの開発時にどのような商品設計を行ったかによって変わります。
AgWORKSでは、自社サービスやWebシステムを実際に開発し、その後の運用や機能追加まで行ってきました。
その経験から、最初に必要な機能だけを作るのではなく、その後どのように商品や機能を増やしていくのかも含めてシステムを考えます。
シミュレータを一度作って終わるのではなく、事業の成長に合わせて使い続けられる仕組みにすることが重要になります。
デザインシミュレータというと、どうしても「デザインする画面」の開発が中心に見えます。
しかし、実際に必要になるのは、その画面の裏側にある商品設計です。
これらを整理したうえで、必要な機能を設計していきます。
AgWORKSがデザインシミュレータを開発するときも、最初から機能一覧を作って画面を組み立てるのではなく、商品と業務の流れを確認するところから始めます。
3DCGやWebGLによる3D表現、グラフィックデザインや印刷、Webシステム開発、自社サービスの運用など、それぞれの領域で培ってきた経験を組み合わせ、商品をWeb上で扱える形にしていきます。
デザインシミュレータを導入したいと考えたとき、「どんな機能を付ければいいのか」がまだ決まっていなくても構いません。
現在の商品がどのように販売され、どのようにデザインされ、どのように注文され、最終的にどのように製造されているのか。
その流れが分かれば、そこからシステムとして必要なものを整理できます。
そこから、どのようなデザインシミュレータにできるのかを検討します。
【自社の商品をシミュレータ化できるか相談する】