実写webVRを活用したwebサイトの制作 | コンセプト策定からFigmaデザイン、React実装、Splineで3D制作、 ホスティングして公開まで
※無我夢中で語っていると13,000文字を越える特大ボリューム記事になってしまいました。
人生で一度だけ、トラックに足を踏まれたことがあります。
大晦日になると毎年行っていた地元の神社。中学3年生の大晦日もその神社の前で低めの段差に友人数人と腰掛けていると、横切った軽トラックに自分の右足だけぐにゅりと踏み潰されました。しかし完全なる無傷だった為、怪我人としても扱われなかった微妙な痛みだけが残る不遇な体験でした。
その出来事から約10年後、今回ご縁がありその地元の神社のwebサイトを制作させて頂くことになりました。
そこで、自分自身今まであまり技術的な発言や発信をしたことがなかった事に気づいた為、今回技術面をメインに一つのwebサイト制作プロジェクトにおける自分の着手フローを順番に淡々と書いてみます。
一つ大きな特徴として、実写3DでのwebVRを活用したwebサイトになっています。
3DやVR等のwebXRを活用したwebサイト制作に興味がある
webサイト制作の全体的な流れに興味がある
webデザイナーとして、実装（フロントエンド）の流れを把握したい
フロントエンドエンジニアとして、webデザインの制作プロセスを把握したい
といった課題がもしあられたら、少しでも何かしらの価値を提供できたら幸いです。
↓ 今回制作したwebサイト
↓デザインデータ(Figmaリンク)
↓ GitHubでソースコードも大公開しています。
興味のある技術をふんだんに使いモダンな神社のサイトを制作する
今回ご協力頂いた神主さん。
今回のwebサイト制作において、可能性を感じているXRを活用させてくれないかというのと、制作後に一連のプロセスをポートフォリオとして公開させてくれないか（この記事のこと）という要望に対して快く了承して下さりました。
実際の着手の際にも、的確にアドバイスを頂いたり、プロジェクト全体を通して心地よいやりとりで最後まで制作させて頂きました。
夜遅くまでお時間を頂いたり、頂きたい素材や文言の連日による対応、誠にありがとうございました。
0: プロジェクトの概要
お見積もり等のお仕事としてのご提案の後に、制作において携わらせて頂く範囲をお打ち合わせさせて頂きました。
以下が今回のwebサイト制作における介入領域です。
サイトコンセプトの策定・デザイン
VR空間の制作全般（素材撮影やデザイン・実装）
サイトの実装全般
サーバーのホスティング
独自ドメインの取得
メールアドレスの取得・先方環境への導入
サイト公開後の保守
最初から最後まで携わらせて頂きます。
そしてXR導入、更に昔から知る地元の神社ということもあり、着手前からすでに身が引き締まります。
絶対に良いものを作れると感じましたし、結果的に作れました。
今回アサインしてくださったメンバー
曽我(趣味はけん玉)
僕1人でした。よろしくお願い致します。
１： デザイン
着手期間：約10日
神社についてのヒアリングからコンセプト策定、ワイヤーフレーム制作、ビジュアライズ、各素材の編集・制作まで。
1-1: ヒアリング
まずは、当社についての全体的な概要をお伺いします。
普段クライアントにお伺いする内容は、制作において必ず必要になってくる基本的情報から、ミッションビジョンバリュー等の根本的な方針にあたる部分、現状の課題、そこから顧客や今後の運営戦略を見据えた短・中・長期的な目処の内容になります。
今回は神社という特殊なケースなのと、運用よりも制作がメインのため、当社の御由緒に関してと制作に関する内容がメインになりました。
具体的には、御祭神や地域的な特徴、御祈願で扱うものやその他大切にしている概念、今後のご展望、今回制作するwebサイトにおいて期待する効果、現在の顧客等をお伺いします。
最終的に実際にお会いしてのお伺いと御由緒をまとめた紙面の略記を頂き、残りの基本的な内容はテキストベースの自作テンプレートにてご回答頂きました。
1-2: サイトコンセプト策定
ヒアリングで頂いた内容を元に、今回制作するサイトのコンセプトを策定します。基本的にはこのサイトコンセプトがサイト自体の存在意義になってくるため、耐久度を精査しながら策定します。
しかしコンセプト策定はマーケティングフレームワークに関してや、リサーチに関しての内容、さらにブランド作りの内容にも深く触れてくる為、この領域だけで最低でも50,000文字は欲しいところです。
そうなるととんでもなく大長編記事になる為、またの機会に置いといて今回は深い内容に関しては端折ります。
今回行った他社のリサーチですが、類似ジャンルに値するwebサイトと、地域的競合に値するwebサイトの大きく2種類に分別して行いました。
前者に関しては和を扱う中規模の個人ブランド（無形商材や商材無しだと◎）が参考になりそうです。コンバージョンの概念が薄いような文化的・カルチャーを扱うサイトは、相応のブランディングに重きを置くことが重要になる個人ブランドとサイトコンセプトが類似してくるかなと考えました。
後者に関しては、Google mapで近所の神社を探し、webサイトの有無やwebへの力の入れ具合を見ていきます。Googleで地域名で検索し、ヒットするアフィリエイト記事で紹介されている神社もチェックしていきます。
今回そこまでの数をリストできなかったのですが、最終的に前者後者合わせて25ほどのwebサイトをリスト化しました。
これらを比較し出てきた傾向の中から、目立ったような共通点は以下でした。
和はビジュアルが魅力的になりやすい為、伴ってビジュアルやサイトギミックに力を入れているサイトが多い（別ジャンルとの比較的）
海外も視野に入れていると見られる所も多い
近隣地域はwebに力を入れている所は少ない。競合はほぼ皆無。
これを参考に、当社が他社と比べた時の強み・弱みをヒアリングシートを元に定義していきます。
これも大きくブランドとしての側面と地域的な側面の2種類に分けられますが、その中でも際立ったものは以下です。
御祭神の知名度・由緒が強い
近隣地域も包括した、場所としての所縁が深い
真後ろに大きな山があり、自然との調和が高い
地域全体を通して過疎もなく治安も悪くない、ゆったりとした土地
対して、交通アクセスは少し劣る印象です。高速からも遠く、最寄りの駅からは10分ほど歩いて頂くことになります。
これらをまとめると、徐々に当社のポジショニングが明確になってきました。それをサイトコンセプトとして一言にまとめます。以下となりました。
「 自然に囲まれた素朴な神社の歴史、存在、空気を最大限に感じられるサイト」
このようなサイトを目指します。
1-3: サイト構成制作
他社リサーチによって並行してサイト構成も明確になってきます。
そこで今回webサイトに求められる機能は以下になりました。
鎮座地や主祭神について等の当社の由緒の掲載
美しい景観、立地感、素朴で純粋な空気感の表現
境内や年中行事、ご祈祷や授与品等の当社にまつわる情報
主要移動手段での交通アクセスの表示
近隣組合の紹介
随時更新可能なお知らせやご案内情報の投稿機能
これに伴って必要なページを定義、遷移を設計していきます。
特徴としては、トップページで神社自体の美しい景観、素朴で純粋な空気感を大きく表現する点です。
他社のサイトにおいてもトップページはダイナミックに画像を使用したり、スライドショー等により景観の美しさを表現しているところが多かったです。
今回はこのトップページをwebVRを用いてインタラクティブな体験を設計することにより、その要件は満たせます。なんならその点はwebVRの方が大きく軍配が上がります(今後その傾向はより強くなるので、こういった活用の仕方も少しずつ増えてきそうです)
ここで、デザイナーが実装まで携わることの大きな利点として、技術的要件定義を同時に行いつつサイト構成を設計できる点だと再認識しました。
技術的、時間的負荷がどこにかかるかが把握できるので、ある程度工程の見通しを見積りながら進められます。
デザインだけしていた時はこのあたりの感覚がなくて、実装時の現実味と表現上の理想論の差に悩むことも少なくなかったです。
1-4: ワイヤーフレーム制作
サイト構成で定義した内容を元にワイヤーフレームを制作します。
ワイヤーフレームの目的としては先方との認識の共有が9割なので、今まで定義した内容をできるだけビジュアルで理解して頂けるように心掛けていきます。
個人的に意識している点としては、ワイヤーフレームのページ遷移にも大まかなトランジションを付けることです。
インタラクティブな要素が多いwebサイトであればあるほど、動きがあるのとないのとで想像で補完する見え方がかなり変わってくるので、重要度が低くなければワイヤーフレームの段階で動いているものを見て頂きたいです。
使用ツールはFigma。
脱Adobeしてしばらく経ちますが、簡易的な画像レタッチやベクターデータ編集、プラグイン導入でgifやmp4でも出力できるFigmaの恩恵を全身に浴び散らかすことでAdobeを使わずに成り立っています(後はBlenderとCapcutとProcreate)。
最悪どうしても必要な時は再度登録すれば良いだけだと思っています。
1-5: デザインルール、トンマナ設計
必要なデザインがある程度明確になったので、デザインルールを設計していきます。
どういった順序で進めるかはデザイナーにより好みがあると思うのですが、自分の場合は「レイアウトコンセプトを一文に言語化する」ということをしています。
「素朴なシンプルさと、その中に隠れたさらりとした強い動き」
サイトコンセプトを上手く表現できそうなレイアウトコンセプトになりました。
ここは口に出したほうが頭の整理がつきやすい派なので、ボソボソと1人で話しながら進めるのが好きです。
この時に出先(スタバ等)で作業の場合は、あらかじめボソボソする耐久度の高い席をチョイスします。
この席チョイスを妥協すると、隣の人に舌打ちされながら席を移動されたり、どこからか視線を感じ続けるので作業効率に影響してしまいます。
フォントの選定やフォントサイズもここで行います。
今回は実装段階で使用するライブラリであるNext.jsの新機能、next/font を使用したいので、google font の中から今回のデザインに合うフォントを探していきます。
結果、メジャーなしっぽり明調を使用することにしました。
かわいいフォントは使うだけでウキウキしますね。
フォントサイズは、幅広い年齢層が予想される為に小さくても16px程度にとどめたいです。
実際にはremで指定するので、実機チェックを細かく挟みながら調整していきます。
1-6: デザインカンプ制作
ここで具体的なデザインの制作に取り掛かります。
コンポーネント制作→各ページ制作→遷移制作、というFigmaデザイン制作の一般的な流れを外れずに進めていきます。
画像ロゴ等のビジュアルに関しては次の工程でレタッチや編集を加えてから本置きするので、一旦は仮置きで用意していきます。
PCがメインで、SPは１ページ分のみ制作してデザインルールを固めてから、残りは直実装で進めていくことにします。
デザインの解像度がPCのレイアウトを組んだ段階で高く維持されているので、SPで大きな仕様変更をしない限りは得に問題はなさそうです。
チームプレイだとこうはいかないので、ワンマンの醍醐味かもしれません。
1-7: 画像素材レタッチ
あらかじめ頂いていた画像素材の中から、ビジュアライズの段階で選定した素材のレタッチをしていきます。
レタッチツールはFigma。今回は合成系も行わず人物も扱わないのでFigmaの色調補正でも十分だと判断しました。
各項目で使用する画像を並べて1画面内に収め、全ての色感を均一化していきます。
最終的には少しだけ色味の入れた調整レイヤーをオーバーレイで全てに適用し、トーンを統一します。
神紋（ロゴ）に関しては、ベクターのデータがなかった為頂いた画像をベクターデータ化。 画像のベクターデータ化に関しては、最近出た革命的なツールを頼り切っています。
以前まで、Figmaでモノクロに色調補正→adobe captureにインポート→svg化してエクスポート→Figmaで成型というフローで処理していたのが、このツールで3秒で出来るようになってしまいました。
1-8: ロゴアニメーション制作
ベクターデータにした神紋を使って、トップページで使うロゴアニメーションを制作します。
使用ツールはRive。インタラクティブなビジュアルを様々な形式で出力できます。
小川を表現している下半分の部分にさらさらとした抜け感が出るように、３秒程度でアニメーションするように制作。
フェードインとフェードアウトは実装時に処理する為、ひとまずこれでiframeで書き出しておきます。
iframeで出力するメリットとしては、後ほど細かいディティールの変更が必要になった際に親のエディターから編集を加えただけで、コードは触らずデプロイもし直さずに即時変更反映される点が魅力的です。
1-9: マップイラスト制作
境内を紹介するページにて使用する、地図のイラストを制作します。
こちらはiPadのイラストツール Procreate で手書きしていきます。
手書きの雰囲気を大切にしつつも、やわかくしすぎないラインを意識しました。
これで、デザイン周りのほとんどは完成しました。
２： 実装
着手期間：10日
要件定義からテスト環境でのチェック、各API導入、スタイリング、SEO対策まで。
実装に関しては反省点が多くあります。今後に活かすためにも言語化しておきます。
2-1: 要件定義
コンセプト周りをはじめ、全体的な要件はデザイン前に済んでいるので、機能的側面での要件定義を行います。
といってもwebサービスでもないので、技術的負荷のある機能も少ないです。以下になりました。
お知らせ投稿
Google map埋め込み
お問い合わせフォーム
VR表示
VR表示に関しては後述します。
2-2: 環境構築
要件を元に環境を構築していきます。
大まかな部分の仕様は以下になりました。
JSライブラリ : React - Next.js 13 (App Router)
スタイリング : scss
ホスティング : Vercel
CMSサービス : Sanity
いわゆるJamstack です。
Sanityにした理由は、adminページをシンプルで簡単なUIで管理して頂きたいなとサーフィンしていたところ、UI的にも機能的にも良さそうだったので採用しました。
ヘッドレスCMSはcontentful しか触った事がなかったので、テストプロジェクトで一度技術検証をしました。
勉強の為にもTypescriptを使用したくてテストプロジェクトで触ってみたのですが、実運用はスピード感でご迷惑をおかけしそうなので見送りました。
Tailwindは、コードの見通しが悪くなるのが嫌で今の所あまり好きじゃないです。後述しますが今回命名規則もキレイじゃないので、そのあたりの手間が払拭できるのは魅力なのでしょうか？
2-3: コンポーネント設計・実装
デザインカンプに従ってコンポーネント設計をしていきます。
数ヶ月前にNext.jsが13で新しくApp Routerをリリース、今回こちらを導入しています。
様々なアップグレードがあり、ディレクトリの仕様も大きく変更されています。
実装自体もデザインカンプの段階で実装を見据えてコンポーネント設計していた為にサクサクと進みます。
しかしこの時に気づけばよかったんですが、コンポーネントの階層を簡略化してしまったことにより後々のページレイアウトの段階で少々苦戦します。
ヘッダー、ハンバーガー等のロジック部分も実装していきます。
つまづいた箇所としては、PCヘッダーでのドロップダウンロジック。
details・summary タグで実装したのですが、summaryをホバーした時にdetailsを展開させようとuseStateをかけた時に、全てのdetailsが展開されてしまう事になってしまいました。
すなわち、メニュー項目①をマウスホバーさせるとメニュー項目①②③④も展開される感じです。
結果的にスマートな解決法がわからず、メニュー項目ひとつずつにuseStateを定義していくパワープレイで事なきを得ました。
今回意匠面で重要視している箇所である、各ページのファーストビューアニメーションも実装。
トップページを除いて比較的動きに頼らずレイアウト自体もシンプルなデザインの為、目を惹きつけるさりげないワンポイントの重要度が高くなっています。
そこで初めにビジュアルが少しだけ目立った動きをしてくれることで、定義したデザインコンセプトらしく、素朴なのにリッチな体験を感じて頂けます。
2-4: API設計・実装
ページを揃える前に、技術的負荷の高いAPI部分から実装していきます。
心理的安全性の確保が優先です。
今回APIを使用する箇所は以下です。
お知らせ、新着情報のCMS
お問い合わせのコンタクトフォーム
アクセスのGoogle map埋め込み
CMS以外は難易度は高くなく、CMSで使用するSanityも技術検証済みなので安心して進めます。
コンタクトフォームはメールが届けばそれでよかったのでWeb3Formsを採用。
この段階で独自ドメインが使用可能状態であれば、それでメールアドレスまで取得してしまってコンタクトフォームにそのまま導入したのですが、独自ドメインの候補をまだお伺いできていなかった為、一旦自分のアドレスで動作チェックします。
2-5: ページ、ルーティングの設計・実装
APIが一段落した次に各ページをレイアウトしていきます。
基本的にはデザインカンプに従って、制作しておいたコンポーネントを呼び出していく作業です。
ここでコンポーネント設計の重要さを痛感します。
結果的に得た教訓としては、１コンポーネント１機能だということです。
今回の場合、１コンポーネント１パーツで設計していた為、コンポーネントという機能自体の能力を活かしきれないケースが数箇所発生していまいました。
例えばファーストビューの役割を担うトップビジュアルのコンポーネント。
こちらもtopVisualというコンポーネント内に各要素を実装してしまいました。
結果として、各ページにおいてpropsで代入する量が多くなったのと、多少のイレギュラーなレイアウトの際に対応できず、バラしてページ内で逐一再構築して対応しています。
我ながらとんでもない無駄だなと反省。これが機能ごとにコンポーネント化して、それをバンドルしたコンポーネントを使用しておけば大幅に時間と労力と間抜けさを省く事ができました。
ページ遷移間のトランジションにFramer-motionを使用。
実は未解決なのですが、マウント時のフェードインは効いていますがアンマウント時のフェードアウトが効いていません。
マウント時は効いている為に優先度が高くなくなったので妥協した点ですが、いまだに原因解明できておらず進行形で究明しています。
2-6: 共有、調整、修正
この段階まできたところで一度ビルドしてVercelドメインのものを先方と共有します。
全体的な見え方や過不足等を精査頂き、フィードバックを反映していきます。
2-7: metadata制作
トップページを除いてほぼ完成の目処が立ってきたところでmeta周りを設計します。
サイトコンセプトを見直してポジショニングに従い、適切なワードを設定してSEOへの好影響を考慮していきます。
今回は絶対条件としてローカルワード（地域名や歴史上の固有名詞等）では必ずヒットしなければならない為、ローカルワードを優先度高く反映させます。
その点に関しては今後の運用方針に関してのお打ち合わせの際に、歴史的価値を感じて参拝してくださる方に対してのニーズを悦楽的に情報を提供することで楽しんでいただけるように、当社が扱う御祭神や御由緒にまつわる情報は豊富に提供するような運用の話もしています。
そんなふうに進めていた矢先にエラーに遭遇。
Next.js 13から追加されたmetadata APIを使用していたので、そこでのエラー。
調べてみるとこのmetadata API、サーバーコンポーネントでしか使用できない仕様のようです。対して現状の多くのページファイルの上部にはこの文字が。
検討の結果、全てのページをラップすることにしました。
今後App Routerを触る際はラップ前提で設計します。
３： 3Dデザイン
着手期間：約3日（デザイン、実装）
コンセプト策定から素材撮影、UI設計、ビジュアライズ、実装まで。
3-1: 要件定義
ワイヤーフレームの制作あたりのタイミングで、同時進行でVR部分の要件定義をしておきました。
実写ベースの3Dオブジェクトを表示
インタラクティブなギミック
各ページへの遷移
実運用可能範囲の容量
実写にこだわる理由は、実写のVRを活用したwebサイトを自分自身が見たことがなかったからです。
実写が使えるのであれば使うに越したことはないのですが、これまで使われてこなかったのはそれ相応の障壁がある為だなと感じていました。
なので今回は挑戦的なニュアンスも多分に含んでいます。
3-2: 技術検証・構成案作成
軽く要件定義が済んだ段階で、実際にそれを実現するための構成案、技術検証を行います。
構成案① ツアー
主要エリアまたは主要ポイントをVR上でツアーのように回る体験案です。
これは過去に個人的興味で技術検証も済んでいたので解像度が高いです。
そして体験もリッチで視覚的かつ直感的。新しいweb表現のメジャーな形になるんじゃないかと本気で思っています（すでにチラホラとは見かけますね）
しかし今回において大きな課題があります。
実写３Dであるフォトグラメトリはサイズ容量がどうしても大きくなってしまう点です。
伴ってサイトパフォーマンスが下がってしまうのがかなり深刻です。
個人的に、XRにおける現状の技術と浸透度において重要なことは「リッチなのに軽い」ことです。
この差が高ければ高いほどユーザーの体験満足度は高くなると仮定しています（現状のマジョリティにおけるバイアスを利用しての仮説です）
実際の過去に技術検証で自分が制作したプロトタイプのパフォーマンスがこちら。
このサイズをweb上で表示させると、１０秒手前ほど真っ白の画面を眺めさせられてしまいます。
Netflixで映画視聴中に4件ほど連続で通知が来た時の気分ですね。
ただこの点に関しては、数年後には素材自体の軽量化で早く解決されると予想しています。
根拠としては、最近出たAIによる3Dオブジェクト制作サービスは、フェイクメッシュを利用しての大幅サイズ圧縮化によるコンテンツ提供に成功しています。(サービス名を失念。ソース不十分の為消しておきます)
そうなるとノーマルマップを必要とせずパフォーマンスを出せるようなマテリアル等が普及して、結果的に本当の3Dの民主化が加速しそうです。
フェイクメッシュの領域はとても期待しているので、しばらくは賢い人たちに両手を合わせて待っている事にします。
構成案② バックグラウンドライド
スクロールに伴って背景のVR空間がインタラクティブに反応する体験案です。
ライド型のアトラクションっぽい体験設計になるのでバックグラウンドライドと名付けましたが、既存の名称を見つけ次第しれっと記事を変更しておきます。
この案の場合、ユーザーに負担頂くアクションがスクロールのみになるので概念に悩むことなく体験して頂けます。
加えてバックグラウンドでの処理により多少の画質的なクオリティに目を瞑っても気づかれにくい設計になるので、容量を効率よく落とすことができサイトパフォーマンスを上げられます。
サイト実装段階中もしばらくはこの案でいくことを想定して進めていたのですが、3D実装を進めようとiPhoneでデバイスチェックした時に深刻なことに気付きました。
モバイルデバイスでスクロールロジックが反応されていません。
サイト実装側のインタラクションには反応しているのですが、spline上で実装されているスクロールロジックは一切を無視しています。
コードで扱えるsplineの出力形式は3種類あるので（iframe, viewer, code embed）一番自由度の高いcode embedで、react-three-fiberを使用して挑戦しましたが反応せず。
原因があまりわかっておらず、時間も余裕があるわけではなかったので違う案を考えることにしました。
構成案③ Spatial
先日、Appleより待望のVision proの発表がありました。
Appleらしく既存のハイプの混じったワードチョイスを避け、Vision Proによる空間体験型インタフェースを「Spatial design」と表現しました。
今回それに近い体験設計をラフで描いてみたところ、なんか良い感じになりそうだったので最終的にこのspatialな案を本格的に肉付けしていくことに決定。
そこでパフォーマンスとの勝負をどう乗り切るかを考えていたところ、1ヶ月ほど前にお気に入りのフォトグラメトリソフト Polycam から「360」という機能がリリースされたのを思い出しました。
この機能は、パノラマとして左右に360度の写真を撮ると、上下の余白をAIに補完させて完全立体空間のビジュアルとして出力する、というもの。
スカイボックスにテクスチャとして貼り付けて使用する為出力自体は二次元の画像。３Dメッシュ生成してマテリアルまで生成してくれるフォトグラメトリよりは断然軽い仕上がりになります。
このspatialの案だったら十分これでも体験は機能すると考え、これで行くことに。
3-3: 素材撮影
サイト実装も終盤に差し掛かっていたタイミングで、構成案で仮説立てたものを成立させる為に、実際にPolycam で撮影をしに現地へ。
運悪く梅雨に入ってしまったタイミングのため、天候にしばらく見放される形になっていました。
今日の午前中が微妙に晴れるとのyahoo天気のお告げを浴びて伺ったところ、予想以上の微妙さに仕上がりが不安になります。
なんとかならないかとFigmaを駆使してレタッチを試みたところ、なんとかなりました。
この画像をメインビジュアルとして使用していきます。
3-4: VR実装
要件定義に伴って、制作したビジュアルを使用してSpline上でインタラクションを実装していきます。
Splineは3Dをとても手軽にあらゆる形式で出力できるツールです。
しかししばらくヘビーユースしてみて感じたのは、Splineは色々と少しクセが強いツールです。
クセの一部を連ねてみます。
"spline"というワード自体がクリエイティブにおける常用語なので、イシューを検索しても別の媒体ばかりヒットし検索性が悪い(spline 3d等でも同様)
notionで作られた公式のDocsには、タイトルだけ書かれて本文空白の謎のページが数枚存在する
位置座標系のアニメーションを設定すると、高確率で"0"と"-180"を間違えて出力する（並行移動したいだけなのにスターフォックスみたいな回転をしだす。伝わってほしい）
プレビュー画面で視点に設定外の挙動をさせると、エディター画面のカメラの座標位置が同期してバグる（このバグはやばすぎて笑ってしまう）
これだけ見るとポンコツなのですが、前提のできることがかなり高機能なので仕方がないと割り切れます。その上で自分は有料プランユーザーです。
そんなクセと闘いながら実装していきます。
グラフィカルで直感的なインターフェースなこともあり、実装自体は半日あれば大方完成します。
トーンは最終的にSpline上のポストプロセスで最終調整してサイトのビジュアル全体と馴染ませていきます。
3-5: Next.jsに埋め込み
Spline上で実装が済んだものをNext.js上に埋め込みます。
といってもとても簡単で、Splineをコードで出力し、それをNext.jsにコピペするだけです。
あとは必要なライブラリをプロジェクトにインストールすると出力されます。
ここで、Spline上で実装したインタラクションがNext.js上でも動作するかを特に確認しておきます。
それとSplineにはmedia queryのような概念は存在しないので、モバイルデバイスとPC両方で成り立つレイアウトにする必要があります（または実装サイドでSplineプロジェクトを出し分けするか）。
Splineの埋め込み作業が済んだら、プレビューでパフォーマンスを確認します。
画像素材の軽量化により、想定より結構軽くwebVRが実現しました。
しかし表示までまだ少しタイムラグがあるので、この時間内にロゴアニメーションを実装します。
framer-motionで4秒ほどのフェードアウトアニメーションを指定し、ロゴアニメーション部分にデザインパートで制作したRiveのプロジェクトiframeコードを埋め込みます。
これで、webVRとサイト実装のほとんどが終了しました。
4: サイト公開
着手期間：1日
修正・調整から独自ドメイン取得、メールアドレス取得、サイト公開まで。
4-1: 修正・調整
公開までに必要なほとんどの要素が揃ったので、Vercelへビルドして先方と最新の状態の全体共有をします。
最終的な文言の調整等も反映していき、細かいバグ等を修正していきます。
4-2: 独自ドメイン取得
実装中にお伺いしていた独自ドメイン候補を取得します。
今回取得したドメイン"or.jp"は日本国内の法的期間専用の属性型ドメインです。
初めて取得したのですが、法人登記に関しての所在地や名前、登記日等の情報を厳密に審査され、ドメインでサイトの信用度はたしかに変わるなこれはと再認識。
数回入力違いによるエラーで返されましたが、無事信用のおけるドメインを取得することが出来ました。
4-3: メールアドレスの取得
取得した独自ドメインでメールアドレスを取得していきます。
個人的にメールアドレスの取得が少し苦手で、過去に数回苦戦した記憶があります。
まずはドメインを取得したお名前.comでメールアドレスを取得します。
お名前メールというものがあったので、それを契約。
それをVercelのDNSレコードと接続。送受信共に上手くいきませんでした。
色々試しましたが上手くいかないので、お名前メールを解約してさくらのメールボックスを新規契約。
こちらでVercelと紐付けたところ、上手く送受信が機能しました。
お問い合わせフォームのAPIとも紐付け、自分の環境ではメール周りは正常に動作しました。
先方の環境でも何度か試した後に受信送信を確認。
メールアドレスの取得もなんとか完了しました。
4-4: サイト公開
最後に取得した独自ドメインをVercelに紐付け、本番用ドメインとしてビルドします。
こちらもすでに数回ビルドしている為にスムーズにビルドが完了し、独自ドメインでサイトが公開されました。
これで調整・修正作業を除いた、サイト制作の全てフローが完了しました。
おわりに
WebVRを活用したwebサイトの制作をデザインコンセプト策定からサイト公開まで細かくみていきました。
web上でのXRのあり方は、個人的に真剣に向き合いたいテーマなので、今後このようなクリエイティブが増えてくると嬉しいし、それに自分が携われると光栄この上ないです。
ご覧頂き、ありがとうございました。
この記事が気に入ったらサポートをしてみませんか？