第1章 – 最初の課題：POC制作を高速化する
OpenGateは、具体的かつ実務的な課題から生まれました。Mixed RealityやAugmented Reality体験に向けたproof of concept（POC）の制作を高速化することです。Metagateのように短いサイクルで実験を重ねる環境では、毎日が時間との勝負でした。アイデアは豊富で、Meta Quest 3 をはじめとするXRデバイスの性能も向上していましたが、コンテンツへのアクセスとデータ管理を統合する、軽量で動的な一元管理ツールが不足していました。目標は明確でした。より短い時間で、より多くの体験を開発すること。そして、より高い制御性と反復改善の余地を確保することです。
当時、最も柔軟ですぐに使えるツールがGoogle Sheetsでした。リアルタイムで更新でき、共有可能で、Unityからも容易に読み取れるシートがあれば、画像、3D、音声などのマルチメディアassetと動的リンクを使った初期テストを管理できました。URLを1つ入力するだけで、あるいはパラメータや座標を変更するだけで、ヘッドセット内の体験が即座に変化します。クリエイティブチームと開発者が余分な構造を挟まず共同作業できるno-codeソリューションでした。
同時に、シートへ直接接続する小規模なGoogle Apps Script APIも開発していました。これらのscriptは、行の管理を自動化し、特定のデータを抽出し、アクセストークンを生成し、MR体験の設定をリアルタイムで変更することさえできました。各APIは特定の目的に特化した小さなtoolであり、シーン、キャラクター、インタラクティブな仕組みをより速くテストするための加速装置でした。こうして、俊敏で軽量でありながら非常に強力なマイクロインフラが生まれました。
一時的な解決策として始まったこの方法は、すぐに有効性を証明しました。チームは複数のXRプロジェクト を同時に管理でき、中央管理されたsetupから、すでにヘッドセットに読み込まれた体験へリモートで変更を加えられました。シートを開いて値を1つ変えるだけで、デジタル環境をリアルタイムに変化させられます。イベント、展覧会、デモを行き来するMetagateのようなstartupにとって、この柔軟性は不可欠でした。
しかし、限界も明確でした。Google Sheetsを基盤とした方法では本当のスケーラビリティを確保できません。アクセス制御、avatar統合、複雑なシーン管理、NFTプラットフォームとのinteroperabilityに対応する構造化された仕組みもありませんでした。また、シートに紐づくコードは断片的に書かれており、しばしば「vibe coding」的な方法、つまり速くクリエイティブではあるものの、長期的には保守しにくい実装になっていました。
まさにこの時、この暫定的なシステムを、より堅牢でモジュール化され、スケールできるものへ変えるという発想が生まれました。
第2章 – alpha testerとの最初のテスト
Google SheetsとAPIを基盤とするマイクロインフラが動作するようになると、次は実際の現場で試す段階でした。そこで最初のalpha testerとして、Metagateコミュニティに近いアーティスト、開発者、キュレーター、上級ユーザーに参加してもらいました。この軽量で動的なシステムが、Mixed Reality体験の制作と利用を本当に簡単にできるかを検証することが目的でした。
反応はすぐに前向きなものでした。alpha testerが特に評価したのは、Unityプロジェクトを再コンパイルせずにその場でコンテンツを変更できることでした。シート内のリンクを更新するだけで、ヘッドセット内の体験がリアルタイムで変わります。ライブworkshopにも、イベント前のテストにも、新しい可能性が広がりました。
プログラミング経験がまったくないユーザーでも、セルにリンクを貼り付けるだけで3D assetをspawnし、画像や動画を表示できるようになりました。no-codeという特徴は、まったく異なる職種同士の協働を促進するうえで決定的でした。
この初期段階では、まだ本当のUIはありませんでした。インターフェースそのものがシートだったのです。しかし、それだけでアプローチの可能性を理解するには十分でした。XR体験を組み立てるための、新しく直接的で共有可能な方法を見つけた感覚がありました。Mixed Reality体験のセットアップは、現実世界で人が物理的に行っていました。フィジカルとデジタルの中間にある、まさにMixed Realityらしい新しい「builder」の考え方です。
この手応えが、より構造化されたものへ進む決定的な推進力になりました。システムは機能していましたが、進化するにはシートの外へ出て、本当のプラットフォームになる必要がありました。まだ名前さえなかったOpenGateが、本当に誕生しようとしていました。
第3章 – GPT-o3、vibe coding、そしてクリスマス休暇
クリスマス休暇中、予想外のことが起きました。経済系のバックグラウンドを持ち、IT教育を受けていなかったMarco Pizziniが、興味本位で GPT-o3を試し始めたのです。発想はシンプルでした。すでに使っていたシステムを拡張・強化するためのコード作成をAIが支援できるか、確かめることです。
そこから純粋な「vibe coding」の期間が始まりました。直感、生成prompt、そしてすぐに実装されるコードが絶えず往復します。新しいasset形式の統合からユーザーID管理まで、あらゆる新機能をAIの助けで構築しました。厳密なルールがなく、Sheetsと軽量APIを基盤とした既存システムが柔軟だったことで、この期間は非常に実りあるものになりました。
短期間のうちに、本当の製品コンポーネントが現れ始めます。最初のlogin、基本的なavatar管理、初期的なcloudの発想です。すべてまだ手作りでしたが、動いていました。そして何より、技術職ではない人物がAIの支援を受けながら、領域横断的に構築したものでした。
その時、私たちは気づきました。GPTでここまでできるなら、OpenGateは本当に誰でも使えるものになれる。
そして挑戦が始まりました。少なくともweb-app部分について、GPTだけでどこまで行けるのか。
第4章 – webappが形になり始める
最初の実験とテストが成功すると、シートとscriptの集合体を、より堅牢なものに変えたくなるのは自然な流れでした。こうしてFlutterとSupabaseで開発した最初のOpenGate webappプロトタイプが生まれました。目標は明確です。Mixed Reality体験をまたいでasset、ユーザー、interoperableな機能を管理する中央hubを作ることでした。
最初に移行したのは使用頻度の高い機能です。マルチメディアassetをアップロードするcloud、MetamaskやWalletConnectなどのWeb3 walletを接続するインターフェース、3D avatarを作成・保存するためのReady Player Me連携です。さらに、avatarに紐づけたOpenAIベースのAI assistantを管理する基本システムも追加しました。
この方法の強みは、その間もGoogle Sheetsを読み続けていたXRヘッドセット用アプリとの連続性にありました。しかし今度は、同じデータとコンテンツをwebappから直接参照できるようになり、エコシステムを統合できました。
アーキテクチャはまだ初期段階でしたが、徐々にモジュール化していきました。cloud、NFT、AI、avatarという各ブロックを、独立しつつ接続可能なコンポーネントとして設計しました。OpenGateの本当の使命が見え始めます。デジタル世界をつなぐモジュール型の橋になることです。
第5章 – Google Sheetsとの別れ
Google Sheetsからwebappへの移行は予想より速く進みました。最初の数か月は不可欠だったものの、アクセスの安全性、脆弱な構造、複雑なコンテンツや複数シーンを扱う難しさなど、限界が見え始めていました。Supabase backendと動作するFlutter frontendが整うと、webappが中心になりました。
移行は明確に進めました。最初にシートと同じ項目をdatabaseへ複製し、その後ヘッドセットアプリがSupabaseから直接読み込むように変更しました。同時に、新規ユーザー登録もGoogle経由ではなくwebapp上で行うようになりました。その結果、 よりスケーラブルで、安全で、一貫したシステムになりました。
ほどなくして、Google Sheetsはアプリから完全に削除されました。暫定的なtoolとして始まったものは、本格的で統合され、進化できるインフラへ置き換わりました。OpenGateが単なる実験以上のもの、つまりビジョン、ユーザー、現実的な成長可能性を持つプロジェクトになりつつある証拠でした。
第6章 – interoperabilityについてのbrainstorming
webappが安定すると、重要な問いが生まれました。では、これで本当は何ができるのか？ そこで重要なbrainstormingを行いました。現実あるいは仮想のテーブルを囲み、OpenGateの真の可能性を考え始めました。プラットフォーム間の橋になること、異なる世界をつなぐinteroperabilityのtoolになることです。
もはやassetを読み込んだりMixed Reality空間にspawnしたりするだけではありません。構想ははるかに大きなものでした。ユーザーが自分のコンテンツ、avatar、データを持ち運べるようにする。1つのmetaverseから別のmetaverseへ、1つの体験から別の体験へ移動しても、物語とアイデンティティの一貫性を維持する。NFT、Ready Player Me avatar、AI assistant、cloud asset……すべてをどこでも再利用できるようにするという考えです。
この時、OpenGateは本当の接続インフラとして輪郭を持ち始めました。単なるMixed Reality builderではなく、横断レイヤーであり、接続点です。XR、gaming、Web3、デジタルカルチャーのロジックに対応するinteroperabilityインターフェースです。
これはパラダイムの転換でした。Metagateの運用支援toolだったOpenGateは、明確な使命を持つ独立した製品へ変わり始めました。その使命とは、まだサイロ化されているデジタルエコシステムの間に連続性を構築すること。この余地は存在していましたが、こうした解決策の可能性を誰もまだ十分には活用していませんでした。
第7章 – スケーラブルな再構築とヘッドセットアプリの新UI
OpenGateをモジュール型でinteroperableなインフラにするというビジョンが明確になると、弱点がヘッドセットアプリそのものだと気づきました。まだ古いGoogle Sheetsのロジックに依存しており、patch、急ぎのテスト、「その場」で書いたコードが積み重なっていました。動作はしていましたが、脆く、保守が難しく、何よりスケールしにくい状態でした。
そこで別のbrainstormingを始めました。今回はXRアプリのUIを整理し、土台から作り直す方法がテーマです。もともと高速テスト向けに作ったインターフェースには、不要な構造、最適化されていない手順、各要素をhard-codeしたりGoogle Sheetsから直接読み込んだりしていた時代のロジックが積み重なっていました。
代わりに求めたのは、開発者だけでなく最終ユーザーのためのUIです。滑らかで、モジュール化され、一貫性があり、Mixed Reality内で迷わず操作できること。展覧会から協働ゲームまで、異なる種類の体験へ適応できるコンポーネントを備えた、複数プロジェクトで再利用可能な構造を目指しました。
同時に、アプリのモジュールを論理的に分離し始めました。asset、AI、multiplayer、NFT、cloudです。各ブロックは独立して動きながら、互いに通信できなければなりません。これはOpenGateが柔軟なXRシステムへ変わる本格的な転換の始まりでした。
第8章 – BeFutureへの選出とKNOBSの支援
再構築と全体見直しを進めていた時、転機となる知らせが届きました。OpenGateがBeFutureの採択プロジェクトに選ばれたのです。イノベーションと実験を支援するこのプログラムは、私たちに2つの重要なものをもたらしました。信頼性とリソースです。コードを整理し、プラットフォームをより安全で安定し、本番運用に耐えられるものへ変える具体的な機会を得ました。
獲得した資金は数か月後に利用可能になる予定でしたが、そのおかげで今回は明確なビジョンと共有された行動計画のもと、次のステップを正確に計画できるようになりました。特にKNOBSチームと、技術的refactoring、compliance改善、webappのセキュリティ強化に向けた方針を検討し始めました。
目標は大きなものでした。backend全体を整理する、コードをモジュール化する、セキュリティチェックを統合する、loginを強化する、APIを最適化する、そして長期的な堅牢性を確保すること。ただし、この段階ではまだどれも実運用には入っておらず、すべて定義と設計の段階でした。
その間も、最も目に見える部分、つまりヘッドセットアプリの作業は並行して進み、夏に予定されていた最初の公開releaseに備えていました。BeFutureによる本格的な技術作業は、その直後から始まる予定でした。
第9章 – 2つの路線：新UIを開発しつつ、旧UIをMeta Store向けに調整
春の数か月、OpenGateは2つの路線を並行して進めていました。一方でDanieleはヘッドセットアプリの新しいUI/UXを開発していました。最終ユーザーが滑らかで直感的に操作できるよう、全面的に、整理されたモジュール型として再設計するものです。フローの分かりやすさ、スケーラビリティ、視覚的一貫性に特に注意し、ゼロからデザインしました。
しかし、現実の環境で試すために新しいインターフェースを待たないことも決めました。そこでPaoloとGiadaは別の優先事項に集中します。Google Sheets時代の構造が積み重なった旧UIを整理・調整することです。最低限でもMeta Storeで公開できる状態を目指しました。
狙いは実務的でした。限定版であってもできるだけ早く公開する。submissionの手順をテストし、技術的・事務的な障害に遭遇し、複雑で不透明なことも多いMetaの公開policyを理解し始めるためです。将来の問題を先回りし、次のバージョンに備えるための「管理された現実との衝突」でした。リスクを下げることが目的です。
こうしてOpenGateは初めて研究室の外へ踏み出しました。まだ完璧ではない。しかし現実に存在するものになりました。
「最初の製品を恥ずかしいと思わないなら、リリースするのが遅すぎたということだ！」引用。
第10章 – 6月の初回無料releaseとATLAS MEETでのテスト
6月、OpenGate初の公開releaseの時が来ました。UIはまだ暫定的で、Meta Storeのsubmissionを通過できる最低限の調整しかしていませんでしたが、最初のバージョンを無料公開することにしました。まだユーザー獲得が目的ではありません。技術的な安定性と、プラットフォームが実際の環境でどう動くかをテストすることが目的でした。
絶好の機会となったのが、ミラノのMEET Digital Culture Centerが主催するATLAS MEETです。Maria Grazia Matteiから2年連続で招待されました。イベント向けにCall for Artistsを実施し、コンテンツを短時間でヘッドセットへ読み込み、Mixed Realityで表示できるようにしました。
あらゆる面で重要なテストになりました。cloud管理は安定し、システムも耐え、実際にコードを書かずにassetを「spawn」できました。同時に、現場から直接feedbackを集める機会にもなりました。何が動くのか、何が動かないのか、何が分かりにくいのか、どこを改善できるのかを確認できました。
この最初の公開運用は象徴的な瞬間でした。OpenGateはもはや社内プロジェクトやprototypeではなく、人々と出会う準備ができたXRプラットフォームになったのです。
第11章 – 7月の第2releaseとBroletto di Novaraでのテスト
7月にはOpenGateの第2releaseが登場しました。今回は大きな進歩があります。数か月の作業を経て完成した新UIの最初のバージョンです。まだ最終版ではありませんでしたが、Store公開を通過するためだけに作られた前バージョンと比べ、より滑らかで一貫性があり、現代的な体験を提供できました。
テストでは、Andrea Barbara Romitaとの協働とMarta Ballaraの支援により実現したBroletto di Novaraへの招待が重要でした。アートと文化の文脈でOpenGateを、Mixed Reality内のデジタルコンテンツを管理するno-code toolとして紹介し、異なる層が利用できるインタラクティブなデモを行いました。
この体験は非常に有益でした。新しいインタラクションフローによってアプリは実際に使いやすくなり、XRヘッドセットを使ったことがない人にもアクセスしやすくなりました。cloud、avatar、AI機能が統合UIの中で共存し始めました。
第12章 – 8月の第3release：multiplayer、シーン、永続化された世界
8月に公開したOpenGateの第3releaseは、本当の転換点です。ヘッドセットアプリとして初めて本格的に構造化され、完成度を備えたバージョンで、待望されていた機能を搭載しました。マルチシーンシステム、同期multiplayer、そして現実空間におけるオブジェクトの永続化です。
ユーザーは異なるシーン間を移動できるようになり、それぞれのシーンに独自の環境、ルール、コンテンツ、layoutを設定できます。各シーンはリアルタイムで変更でき、さらに再利用可能で、設定はcloudに保存されます。最大の進化は、Mixed Spaceに配置したasset、オブジェクト、要素が初めて保存・同期されたまま残ることです。再起動しても維持され、体験が永続的かつ共有可能になりました。
multiplayerでは、複数のユーザーが同じシーンに入り、同じ位置にあるオブジェクトを見ることができます。共同作業、ゲーム、複数ユーザーによるインタラクティブ展示への道が開きました。共有XR空間へ向けた最初の具体的な一歩です。
releaseからまだ数日ですが、現在は積極的な観察の段階にあります。人々がこのtoolをどう使い、どんなコンテンツを作り、この新しい拡張デジタルプレゼンスがどこへ私たちを導くのかを見極めたいと考えています。
第13章 – KNOBSによるbackendのセキュリティ強化とスケーラビリティ
第3releaseがついにonlineになると、重要な課題に向き合う時が来ました。 backendのセキュリティ強化です。それまでコードは、クリエイティブ上の要件や連続的なテストの流れに合わせ、段階的かつ機能優先で書かれていました。構造自体は動いていましたが、信頼性とスケーラビリティを保証するには、狙いを絞った技術的対応が必要でした。
この段階でKNOBSが実務として加わりました。すでに動いている仕組みを強化し、将来の問題から守るために、既存コードを的確に修正することが役割でした。
優先事項は明確でした。APIキーの保護、アクセスセキュリティの改善、機密変数の一元管理、そして特に、安全にupdateをテストし、増加するユーザーとコンテンツに対応できるより堅牢な構造の準備です。
最新情報や特典を受け取るには、 ニュースレター にご登録ください。
体験動画は Instagram、 YouTube 、 Twitter でご覧いただけます。
関連リンクは Linktree 、または お問い合わせ からご確認ください。
執筆： Marco Pizzini