私がEven G2を選んだ理由の一つは、自分でアプリを作れることだった。

完成した機能を使うだけのスマートグラスではなく、欲しいものがなければ、自分で載せられるかもしれない。

その可能性に惹かれた。

そして実際に、ニュースを読むための「NEXORA」と、歌や演奏を助ける「UTAORA」を作った。どちらもEven Hubで一般公開まで進んだ。

目の前のレンズへ、自分が考えた画面が浮かぶ。

その瞬間は、かなり感動する。

ただし、ここまで来て分かったのは、スマートフォンの画面を小さくして載せればよいわけではないということだった。

PCのシミュレータでは整って見えた画面も、実際の視界へ置くと、読める量や操作のリズムをもう一度考え直す必要がある。審査へ出す段階では、グラス側だけでなく、スマートフォン側の設定画面まで一つの製品として成立させなければならない。

Even Hubには、未来へ続く入口がある。

同時に、その入口には、通常のWebやスマートフォンとは異なる作法がある。

この記事では、実際に二つのG2向けアプリを作り、実機に合わせて設計を磨き、審査へ届けた経験から、Even Hubの面白さと、いま知っておきたい制約をまとめたい。

「製品」を買ったはずが、「場所」を手に入れた

THE APP LIVES BETWEEN DEVICESレンズの中だけでなく、スマートフォンからG2までが一つのアプリ。

WebViewで動くWebアプリを、bridgeとBluetoothがG2の表示・入力へつなぐ。

PHONEEven App
HTMLCSSJavaScript
WebView
GLASSESEven G2表示 ＋ 入力
処理スマートフォン側視界と操作G2側

普通、ガジェットの価値は、購入した時点で搭載されている機能によって決まる。

翻訳ができる。通知が見える。ナビが出る。メモが読める。

メーカーが作った機能が便利なら、その製品は便利だ。足りなければ、できないことがそのまま製品の限界になる。

Even Hubが面白いのは、この関係を少し変えたところにある。

Even Realitiesは、G2向けアプリを外部の開発者が作り、テストし、公開できる基盤を開いている。公式ドキュメントによれば、アプリの中身はHTML、CSS、JavaScriptやTypeScriptで書く標準的なWebアプリだ。

ただし、処理はグラスの中で直接走るのではない。スマートフォンのEven Realities App（以下、Even App）内にあるWebViewでアプリが動き、JavaScript bridge、Even App、Bluetoothを経て、G2の表示と入力へつながる。レンズ側は、Webページをそのまま映す小型ブラウザではない。

開発の流れも分かりやすい。

  1. 標準的なWeb技術でアプリを書く。

  2. PC上のシミュレータで画面と操作を試す。

  3. QRコードから実機へ読み込ませる。

  4. 配布用ファイルへまとめる。

  5. 開発者ポータルから審査へ出す。

2026年には、minimal、音声認識、画像、長文表示という四つの公式starter templateに加え、Claude CodeやCodexから使える13種類のAI coding skillも公開された。最初の一歩は、私が着手した時よりさらに近くなっている。

作れる人が増えるほど、メーカーが想定しなかった使い方も増える。

ここでG2は、完成した一製品から、誰かが新しい用途を持ち込める「場所」へ変わる。

同じメガネに、ニュースとコード譜を載せた

TWO APPS, ONE PAIR OF GLASSESニュースとコード譜。違う困りごとが、同じレンズへ入った。

EDIFORCEが実際に制作したNEXORAとUTAORAの一次画面。生成した製品UIではない。

NEXORAニュースを選び、あとで読む
NEXORAのEven G2連携設定画面

自社UI。画面内の媒体名は情報源の選択肢であり、各社との提携を示すものではない。

UTAORA演奏中のコード譜を視界へ
UTAORAのG2へ送る機能を含むホーム画面

自社UI／自社制作プロモーション画面。第三者コンテンツや個人情報は含まない。

私たちが作った二つのアプリは、用途がかなり違う。

NEXORAは、ニュースや「あとで読みたい」情報を扱うアプリだ。G2では見出しや要点を一瞥し、保存や選択を行い、長く読む作業はスマートフォンへ返す。2026年8月17日の確認時点では、Even Hubでv0.5.10が一般公開されていた。

もう一つのUTAORAは、歌詞とコード譜を扱う。歌っている時、楽器を弾いている時、手は塞がっている。そこで、顔を大きく動かさずに次のコードや歌詞を確認できるようにした。2026年8月9日の確認時点では、Even Hubでv0.2.6が一般公開されていた。

ニュースと、コード譜。

同じメガネでも、解決したい困りごとはまるで違う。

この二つが同じ端末へ入ったこと自体が、私にはEven Hubの価値をよく表しているように思える。

純正機能を増やすだけでは、世界中の小さな困りごとを拾いきれない。けれど、外部の誰かが作れるなら、「それを欲しいのは自分だけかもしれない」と思う用途にも、形になる可能性が残る。

スマホの画面は、小さく畳んでもメガネには入らない

REPACK, DON'T SHRINKスマホの全部ではなく、視界に必要な三枚だけを選ぶ。

眼鏡向けUIは縮小ではない。情報をいったん広げ、いま見る意味があるものだけを詰め直す編集である。

SDKで使うG2のcanvasは576×288ピクセル、16階調のグリーン系表示だ。カメラもスピーカーもない。基本の入力は、テンプル部分のタッチパッドによるスワイプ、タップ、ダブルタップ。必要ならR1リングも使える。

この条件へ、スマートフォンのUIをそのまま縮小するとどうなるか。

だいたい、見づらく、操作しづらく、何が大切なのか分からない画面になる。

スマホのUIは、小さくなる魔法のスーツケースではない。メガネへ持っていくなら、中身を一度すべて広げて、本当に必要なものだけを詰め直す必要がある。

NEXORAなら、記事全文を視界へ押し込むのではなく、いま見るべき見出しと、保存するかどうかの判断を置く。UTAORAなら、細かな編集機能ではなく、演奏中に次の一行へ進めることを優先する。

G2向けに作る作業は、画面を小さくすることではなかった。

視界へ入れる価値がある情報を選ぶ、編集の仕事だった。

シミュレータの次に、本当の設計が始まる

PC上のシミュレータは、骨格を作るにはとても便利だ。画面の配置を変え、タップやスワイプを試し、短い時間で何度もやり直せる。

けれど、そこに見えているのは、あくまで机の上の画面だ。

実際のG2では、視界の中に情報が浮かぶ。少し長い文章は、PCで眺めた時以上に存在感がある。指で操作できる種類も少ない。歩いている時、演奏している時、ほかのことへ注意を向けている時にも、邪魔をせず意味が伝わらなければならない。

NEXORAでは、一覧を何段も辿る構造より、固定した少数のText containerへ必要な情報を流し込む構造を選んだ。UTAORAでも、編集機能を増やすことより、歌詞やコードを読み、次へ進むことを優先した。

これは「シミュレータが間違っていた」という話ではない。

シミュレータで作れるのは動く骨格までで、実機ではじめて、視界に置く道具としての設計が始まる。

画面には「8席」しかない

EIGHT SEATS, CLEAR PRIORITIES置ける量が少ないほど、何を見せるかをごまかせない。

公式資料では、Imageは最大4個、TextやListなどその他のcontainerは合わせて最大8個。

OTHER CONTAINERS最大8席
  1. 01タイトル
  2. 02本文
  3. 03操作
  4. 04状態
  5. 05補助
  6. 06入力
  7. 07余白
  8. 08次の一手
IMAGE CONTAINERS最大4枠
  1. 01
  2. 02
  3. 03
  4. 04

上限は、詰め込むためではなく、優先順位を決めるための設計条件。

公式資料では、1ページあたりImage containerは最大4個、TextやListなどその他のcontainerは合わせて最大8個置ける。

私は、この制約を「画面には8席しかない」と考えるようになった。

タイトルに一席。左側のメニューに何席。右側の本文に一席。入力を受け取るための見えない役割にも一席。

全部埋まっているバスへ、九人目を乗せることはできない。だから、表示枠を増やす前に、どの情報へ一席を渡すのかを決めなければならない。

宣言するcontainer数と、実際に置く数も一致させる必要がある。画像には一枚あたりの大きさにも上限がある。

制約を知らないと、設計で解くべき問題を、実装だけの問題として追いかけてしまう。

制約を理解すると、設計の問いへ変わる。

この一席には、本当に何を座らせるべきか。

空間が小さいからこそ、情報の優先順位をごまかせない。表示できるものを増やすより、いま必要なもの以外を削る方が重要になる。

審査で教えられた、「アプリ」の本当の範囲

BUILD TOWARD THE REAL WORLD机の上の画面から、視界の中の道具へ。

実装、シミュレータ、QR実機確認、申請用build、審査を一続きの設計として進める。

  1. 01WEB実装HTML / CSS / JavaScript
  2. 02DESKシミュレータ画面と操作の骨格
  3. 03VISIONQR実機確認視界と指で確かめる
  4. 04PACKAGE申請用buildmanifestと権限を整える
  5. 05PUBLIC審査・公開一つの製品として届ける

NEXORAを最初に申請した時、修正が必要になったのはG2上の表示ではなく、Even App側の設定画面だった。

私たちの実装では、G2へ描画するためのSDK処理と、スマートフォン側の通常画面を十分に分離できていなかった。その結果、設定画面を正しく表示できなかった。

そこで、スマートフォン側の設定は通常のDOM UIとして独立させ、G2 bridgeを使う画面と分離した。修正後、審査を通過した。

ほかにも、実際に通信する外部originはmanifestのallowlistへ登録し、接続先のCORSも整える。マイクを使うなら権限を宣言する。公開済みversionは差し替えられないため、修正版はversionを上げて再審査へ進む。

一つひとつは、分かってしまえば難しくない。

けれど、分かる前は「なぜ動かないのか」が見えにくい。SDK、G2本体、スマートフォンのHost WebView、申請manifest、審査環境が重なって、一つのアプリを作っているからだ。

それでも、「作れる」は強い

ここまで読むと、考えることが多い話に見えるかもしれない。

けれど、その多くは、G2上の一画面だけを作るのではなく、Host側を含むアプリ全体を設計する仕事だと理解すると整理しやすい。

公式資料で表示上限やmanifestの役割を確認し、シミュレータ、実機、申請用buildを段階的に検証する。制作中から公開までを一続きの設計として扱うことが、遠回りを減らしてくれた。

それでも私は、G2を評価する時に「外部から作れること」を大きく数えたい。

閉じた製品では、弱点はそのまま限界になる。

開いたplatformでは、弱点の先に誰かの工夫が入る余地がある。

NEXORAもUTAORAも、Even Realitiesが最初から用意していた使い方ではない。ニュースをあとで読むことも、演奏中にコード譜を見ることも、私たちが欲しいと思ったから生まれた。

メーカーが想定していない未来を、利用者の側から試せる。

その余白は、純正機能の数だけでは測れない、platformの資産だ。

最初のG2アプリは、小さくていい

これからEven Hubを触るなら、最初から多機能なアプリを作る必要はない。

  1. 一目で分かる一つの情報を決める。

  2. 一回の操作でできる一つの判断を決める。

  3. 長い作業はスマートフォンへ戻す。

  4. 公式templateとsimulatorで骨格を作る。

  5. 早い段階で実機へ入れ、実際の視界と指で確かめる。

アプリの中心となるデータや判断は共通のcoreへ置き、スマートフォン、Web、時計、メガネには、それぞれに合う薄いUIを持たせる。私たちはNEXORAを作る中で、この「一つのcore、複数の入口」という考え方へ辿り着いた。

メガネには、すべてを載せなくていい。

視界へ置く意味があるものだけを載せればいい。

まだ完成していない。だから、未来を試せる

Even Hubは、何も考えずに使える完成されたplatformではない。

表示できる量は少ない。入力も限られる。スマートフォン側のWebView、Bluetooth、G2の表示、manifest、審査までを、一つの製品として考える必要がある。

けれど、NEXORAもUTAORAも、公開まで運ぶことができた。

そしていま、自分たちが欲しかった情報が、自分たちの作った形でレンズの中にある。

まだ完成していないから、勧められないのではない。

まだ完成していない場所へ、つくる側として参加できる。

それがEven Hubの、いちばん面白いところだと思う。

一次資料・開発資料

注記：NEXORAとUTAORAの開発・申請に関する記述は、EDIFORCEによる一次経験と保存済みの実装・検証記録に基づく。製品・SDK・審査仕様は更新されるため、開発時には最新の公式資料と適用される利用規約を確認してほしい。EDIFORCEはEven Realitiesとは独立した第三者開発者である。