Even G2 アプリ開発入門：Even Hub と SDK でHUDアプリを作る

SECTION 01Even Hub とは：Even G2 の開発者プラットフォーム

Even Hub は、Even G2 を販売する Even Realities が展開している開発者向けプラットフォームです。サードパーティの開発者が Even G2 向けのアプリを開発し、ユーザーに配信するための仕組みで、Even G2 を「メーカーが用意した機能だけを使うデバイス」から「自分でアプリを足せるデバイス」に変える入り口になっています。

スマートグラスの多くは、翻訳・通知・ナビといったメーカー純正機能を使うことが前提で、外部開発者に表示面を開放している製品はまだ多くありません。その中で Even Realities が公式に開発者プラットフォームを用意していることは、Even G2 の大きな特徴のひとつだと筆者は考えています。Even G2 という製品そのものの評価については、別記事「Even G2 開発者視点レビュー」で詳しく書いているので、ハードウェアとしての使用感が気になる方はそちらを先にどうぞ。

一方で、日本語圏では Even Hub やその SDK に関する情報がまだ非常に少ないのが実情です。技術記事が数本ある程度で、体系的な日本語の入門情報はほぼ見当たりません。本記事では、筆者が Even G2 向けの話者認識アプリを開発する中で押さえてきた「開発を始める前に知っておくべき全体像」を、公開情報の範囲で整理します。

SECTION 02開発の全体像：グラス単体でコードが動くわけではない

Even G2 のアプリ開発で最初につまずきやすいのが、開発者が書いたコードはグラスの中で直接動くわけではない、という点です。ここを誤解したまま設計に入ると、後で全体をやり直すことになります。

Even G2 は、カメラもスピーカーも搭載しない約36g（メーカー公称）の軽量グラスです。この軽さと電池持ちを成立させるため、グラス側は「Bluetooth でスマートフォンとつながったHUD表示器兼入力デバイス」という役割に徹しています。通信、計算、音声処理、外部 API の呼び出しといったアプリのロジックはすべてスマートフォン側で実行され、その結果として「いま HUD に何を表示するか」がグラスへ送られる、という構造です。

つまり Even G2 のアプリ開発は、マイコンに書き込むような組み込み開発ではなく、「スマホアプリ開発＋表示先がグラス」という感覚に近いものです。この構造から、開発上の特徴がいくつか導かれます。重い処理（音声認識・翻訳・AI 推論など）はスマホ、あるいはスマホ経由のクラウドで実行するので、グラス側の計算資源を気にする必要はほぼありません。グラス自体がインターネットに直接つながるわけではないため、ネットワーク処理も通常のスマホアプリやWeb アプリと同じ考え方で書けます。そしてグラスが担うのは、HUD への表示と、テンプル（つる）のタッチ操作などの入力イベントだけです。

「グラスの中で何でも動く」と期待して入ると肩透かしを食いますが、逆にいえば、普段のアプリ開発・Web 開発のスキルセットがほぼそのまま通用するということでもあります。参入障壁は見た目より低い、というのが筆者の実感です。

SECTION 03even_hub_sdk の概要：Web技術者に近い開発体験

Even Hub 向けのアプリ開発には、Even Realities が提供する SDK（コミュニティでは even_hub_sdk の名前で言及されます）を使います。公開されている開発者向け情報やコミュニティの技術記事を総合すると、その開発体験は「WebView 上で動くアプリを TypeScript 系の技術で書く」ものに近い、と説明できます。

これはつまり、ネイティブの iOS/Android 開発や C/C++ の組み込み開発を新たに学ぶ必要はなく、HTML・CSS・TypeScript といった Web フロントエンドの経験がある人なら、知識の多くを流用して入っていけるということです。モダンな Web 開発で使われるビルドツールやパッケージ管理の流儀がそのまま通じる雰囲気で、筆者のように普段 Web 系の開発をしているエンジニアにとっては、心理的なハードルがかなり低い部類だと感じます。

ただし、ここで意図的に踏み込まないことがあります。本記事では具体的な API の関数名やコード例は書きません。理由は単純で、SDK はまだ若く、仕様の更新が速いからです。執筆時点のコードを載せても、読者が試す頃には変わっている可能性が十分あります。具体的な API リファレンス、初期化の手順、イベントの受け取り方などは、必ず Even Realities の公式ドキュメントの最新版を一次情報として参照してください。本記事の役割は、公式ドキュメントを読む前に「全体の地図」を頭に入れてもらうことです。

SECTION 04HUD に表示できるもの・できないもの

Even G2 アプリの設計でもっとも重要なのが、表示面の制約です。Even G2 の HUD は緑単色の表示で、テキスト中心の情報提示に最適化されています。スマホやARグラスの感覚で「フルカラーの画像や動画をリッチに見せる」ことを想定すると、根本から設計をやり直すことになります。

上のような「視界の先に浮かぶ短いテキスト」が、Even G2 の表示の基本イメージです。できること・できないことを整理すると次のようになります。

制約と書きましたが、筆者はこれを「割り切りによる強み」だと捉えています。緑単色・テキスト中心だからこそ軽量で電池が持ち、見た目も普通のメガネに近い。そして「一瞬チラッと見て読み取れる情報」に表示を絞ることが、結果的に良い UX につながります。設計時の指針としては次の3点が効きます。

• 一瞥で読めること（グランサブル）を最優先にする。歩きながら、会話しながら見る前提で、1画面の情報量を徹底的に削る。
• 文字数の上限を最初に決める。1行あたり・1画面あたりに無理なく収まる日本語の文字数を早い段階で実機確認し、それを超えるテキストは要約・分割する設計にする。
• 「表示しない」という判断をロジックに含める。重要度の低い情報は出さない。HUD は通知をさばく場所ではなく、いま必要な一言を出す場所です。

SECTION 05開発を始める手順：公式ドキュメント → サンプル → 実機

ここまでの全体像を踏まえて、実際に開発を始めるときにおすすめの順序を書いておきます。

まずは公式ドキュメントを通読します。Even Realities の公式サイトから開発者向け情報（Even Hub / SDK のドキュメント）にアクセスし、手を動かす前に一通り目を通す。前述のとおり仕様の更新が速いため、二次情報から入るより、最初に一次情報の現在地を把握するほうが結果的に速いです。アプリの配信フローや規約もこの段階で確認しておきます。

次に、サンプルと既存アプリを観察します。公式が提供するサンプルや、Even Hub 上で配信されている既存アプリを触り、「どんな画面遷移が自然か」「テキストはどれくらいの量で出しているか」を見ていく。HUD アプリの UX はスマホアプリの常識と違う部分が多いので、先人の設計から学べることは多いです。コミュニティの技術記事（日本語では Zenn などに数本あります）も、書かれた時期に注意しつつ参考になります。

そして、これが筆者がいちばん強調したい点ですが、HUD アプリの開発は実機がないと核心部分を検証できません。「この文字数は歩きながら読めるか」「視界のこの位置に出て邪魔ではないか」「明るい屋外で視認できるか」といった HUD 特有の問いは、机上やシミュレーションでは答えが出ないからです。本格的に開発するつもりなら、早い段階で実機を手元に置くことをおすすめします。

なお、Even G2 は海外メーカーの製品なので、入手経路によっては技適や保証まわりの確認も必要です。個人輸入を検討している方は「スマートグラスの技適と個人輸入の注意点」も合わせてどうぞ。

SECTION 06話者認識アプリ開発で得た学び

最後に、筆者が Even G2 向けの話者認識アプリ（「誰が話しているか」を判別して HUD に表示するアプリ）を開発する中で得た学びを、特定の API 仕様に依存しない一般論として共有します。話者認識という技術自体の解説は「話者認識（話者判別）とは何か」に書いたので、ここでは開発設計の話に絞ります。

いちばん効いたのは、役割分担を最初に図にしたことです。「音声の取得と処理はスマホ側、グラスは表示器」という分担を早い段階で明確にしたことで、設計の迷いが激減しました。マイク入力、話者判別、音声認識といった重い処理はすべてスマホ（またはクラウド）側のパイプラインに置き、グラスへは「最終的に表示する短いテキスト」だけを渡す。この一方向のデータフローを崩さないことが、構造をシンプルに保つ鍵でした。

次に痛感したのは、遅延が機能ではなく体験の問題だということです。リアルタイム性が求められるアプリでは、処理パイプラインのどこで何秒かかるかが体験を決めます。技術的に正しく動いていても、表示が会話に追いつかなければ使いものになりません。「精度を少し落としてでも速く出す」「確定前の暫定テキストを先に出す」といったトレードオフの判断が、HUD アプリでは通常のアプリ以上に重くのしかかってきました。

そして最後に効いてきたのが、HUD の文字数制約が仕様そのものを決めるという事実です。セクション04で書いた「一瞥で読める量」の制約は、表示層だけの問題ではありませんでした。長い発話をどこで区切るか、誰の発話を優先して出すか、というアプリの中核ロジックそのものが、最終出力である HUD の文字数制約から逆算して決まっていきます。HUD アプリは「出口の制約」から設計するのが正解だった、というのが現時点での筆者の結論です。

こうした字幕的な使い方の周辺には、聴覚サポートという大きなテーマもあります。関心のある方は「聴こえを助ける字幕スマートグラス」も参考にしてください。

日本語圏の Even G2 開発情報はまだ少なく、開発者が一人増えるだけでエコシステムの景色が変わる段階です。Web 開発の経験がある方なら、思っているより入り口は近くにあります。まずは公式ドキュメントを開くところから始めてみてください。

SOURCES主な参照元