Rokid スマートAIグラスで何を作るか — 実装 2 本でわかった制約から、道案内と売り場検索を設計する

Rokid のスマートグラスで何が作れるか、というネタ出しをしている。候補として挙がっているのは道案内と小売店売り場での商品検索の 2 つ。

結論から書くと、道案内は地図アプリとして作ると標準機能と正面衝突するが、順路のチェックリストとして設計し直せば成立する。売り場検索のほうは後述する 4 つの原則を全部満たし、残る変数は店舗側に API があるかどうかだけになる。

そう判定できるのは、先にアプリを 2 本作って実機まで動かしてあるからだ。スマートグラスのアイデア出しは、ハードの制約を知らずにやると全部「スマホでいいのでは」に着地する。逆に制約を先に押さえると、案の良し悪しがかなり機械的に判定できるようになる。なので、この記事も制約の説明から始める。

Rokid スマートAIグラスというハードウェア

Rokid スマートAIグラス（グローバルでの製品名は Rokid Glasses）は、フューチャーモデル株式会社が日本で展開しているスマートグラスだ。2026 年 9 月時点の公式オンラインショップ価格は 109,890 円（税込）。

ハード面で押さえておきたいのは次のあたり。

ディスプレイ: 光導波路ディスプレイと Micro-LED エンジン。グリーン表示の単色で、最大 1,500 ニト。屋外でも文字が読める明るさがある
カメラ: ソニー製 IMX681（1,200 万画素）、109° 広角、F2.25
チップ: Qualcomm AR1 と NXP RT600 のデュアルチップ構成
バッテリー: 210mAh。メガネを外すと自動的に省電力モードへ移行し、装着すると復帰する
重量: 約 49g
連携: 専用アプリ「Hi Rokid」と Bluetooth で連携。対応 OS は Android 10 以降 / iOS 16.0 以降

標準機能として翻訳・撮影・AI 検索・ナビ・文字起こしが載っている。翻訳はオンラインで 89 言語以上に対応する。うち 8 言語（日本語・英語・中国語・韓国語・ロシア語・ドイツ語・フランス語・スペイン語）は、翻訳モデルを事前インストールすればオフラインでも動く。

この「標準で載っている」リストは、アイデア出しでは引き算の材料になる。翻訳と文字起こしとナビは既にあるので、そこに素朴にかぶせる案は基本的に筋が悪い。

AIUI でアプリはどう作るのか — Craft と `.ink` コンポーネント

Rokid のグラス向けアプリ基盤は AIUI と呼ばれるもので、ブラウザ IDE「Craft」（js.rokid.com/craft）で書く。実機投入にケーブルは要らず、Craft の「パッケージ化」で .aix を作り、スマホの Rokid アプリからグラスへ配信する。

言語は JavaScript で、画面は .ink という単一ファイルコンポーネントで書く。<script def> / <script setup> / <page> / <style> の 4 セクションからなり、感覚としては Vue の .vue に近い。テンプレートは WeChat ミニプログラム互換で、div ではなく view、テキストは text で囲む。条件分岐は ink:if、ループは ink:for。

最小構成はこれくらい。

hello-glass/
├─ AGENTS.md          # エージェントの人格・システム指示
├─ app.js
├─ app.json
├─ package.json
└─ pages/index/index.ink

ただし WeChat ミニプログラム互換と聞いて App({...}) / Page({...}) で書くと実行時に落ちる。AIUI は ES module の default export だった。

// app.js
export default {
  onLaunch() {},
  globalData: {}
};

<!-- pages/index/index.ink -->
<script setup>
export default {
  data: { message: 'hello' },
  onLoad() {},
  onKeyUp(event) { /* タップ・スワイプはキーイベントで届く */ }
};
</script>

操作系は独立した API ではなく、タップ／ダブルタップ／スワイプが Enter / Backspace / ArrowUp / ArrowDown といったキーイベントとして届く。ダブルタップ（Backspace）はホーム操作に使われがちなので横取りせず、スワイプで済ませるのが無難だった。

AIUI 実装 2 本でわかった「効く制約」

競馬天気予報アプリと SwitchBot 連携のスマートホーム操作アプリを作る過程で踏んだ地雷のうち、アイデアの実現性に直結するものを 3 つ挙げる。

1. 実機に `crypto` が無い

SwitchBot API v1.1 はリクエストごとに HMAC-SHA256 の署名を要求する。通常なら crypto.subtle で作れるはずが、Rokid 実機のランタイムには crypto が存在しなかった（ドキュメントには載っているのに crypto is not defined）。btoa もない。

結果として SHA-256 をスクラッチ実装し、HMAC も Base64 も手書きすることになった。

// crypto を使わず、自前の hmacSha256 / base64 で認証ヘッダを作る
function sbHeaders() {
  const t = '' + Date.now();
  const nonce = 'n' + Date.now() + Math.floor(Math.random() * 1e9);
  const sign = base64(hmacSha256(strBytes(SECRET), strBytes(TOKEN + t + nonce)));
  return { Authorization: TOKEN, sign, t, nonce, 'Content-Type': 'application/json' };
}

裏を返せば 署名さえ自前で作れば、中継サーバーを立てずにクラウド API を直接叩ける。これは設計の自由度としてかなり大きい。

なお外部通信には、AIUI Studio でエージェント作成時に Permission の「Network Access（Internet）」を ON にしておく必要がある。

2. TTS（`speechSynthesis`）は途中で止められない

読み上げは Web Speech API の speechSynthesis.speak() を使う。IPC でネイティブに転送されるため音が出るのは実機のみで、プレビューは無音。そして cancel() が未サポートなので、読み上げの途中停止ができない。

日本語の日付読みも不規則で、「29 日」がうまく読めない。読み仮名を直接渡して回避した。読み上げ設計は「短い 1 文を作る」以外に選択肢がない、と考えたほうがいい。

3. エージェント名が予約ワードと衝突する

地味に効いたのがこれ。エージェント名を「スマートホーム」「家電連携」にすると音声アシスタントの予約ワードと衝突し、「操作する機能は提供されていません」と言われて起動できない。「家の確認」のような中立な名前にすると起動した。

音声起動が入口である以上、アプリ名の名前空間がアシスタントと共有されているという前提で設計する必要がある。

3 つに共通しているのは、ドキュメントの記述と実機の挙動がずれるという点だ。crypto も TTS のクセもそうだし、他にも fetch(url, undefined) が Error converting from js 'undefined' into type 'object' で落ちる（引数 1 個で呼べば通る）といった細かいズレがある。

const res = options ? await fetch(url, options) : await fetch(url);

プレビューで動いても実機で落ちることがある。逆に、配信直後だけ実機で落ちて、グラスを再起動したら直ったこともあった（原因はコードではなく配信スタック側だった）。検証は必ず実機で——この原則が徹底的に効く。切り分けには「動く既存アプリとコードを完全一致させて試す」が有効だった。

制約から逆算する設計原則

ハードの素性と、実装で踏んだ地雷をまとめると、AIUI アプリの案は次の 4 つを満たしているかで振るい落とせる。

表示が数行に収まるか — グリーン単色で視界の一部。地図も写真も表も、出す余地がない。答えが「A-7 通路中段」のような短い文字列に落ちるものが向いている
常時動かさずに済むか — 210mAh で、常時ネットワーク接続は現実的でない。「呼ばれたときだけ起動して、答えたら止まる」形に落とせるか
既存の標準機能とかぶっていないか — 翻訳・文字起こし・AI 検索・ナビは標準で載っている。素朴な再実装に価値はない
答えを返す API が既にあるか — グラスから直接 REST を叩けるので、叩き先があるかどうかがそのまま実現性になる

原則 1〜3 はハードの素性から、原則 4 は実装経験から出ている。この 4 つで見ると、冒頭に挙げた 2 つの案の評価はかなりはっきりする。

案 1: 道案内 — 屋内の順路チェックリストに絞れば成立する

そのままだと筋が悪い。ナビは標準機能として既に載っているので、汎用の歩行ナビを作り直す理由がない（原則 3）。

ただし「標準ナビが扱わない経路」に限定すると話が変わる。

屋内・施設内の順路案内 — 工場、倉庫、病院、大規模商業施設。GPS が効かず、一般の地図サービスにデータがない場所。順路はたいてい、既存の台帳や図面として現場にある
業務手順としての順路 — 検針、点検、配送の巡回ルート。「次はどこ」を視界に出すだけで、地図は要らない。原則 1（表示が数行に収まる）を素直に満たす
常時追従をやめる — 曲がり角ごとに測位して追従する作りにするとバッテリーが持たない。チェックポイントで手動送り（スワイプ）にすれば、原則 2（常時動かさない）をクリアできる

つまり道案内は「地図アプリ」ではなく「順路のチェックリスト」として設計すると成立する。これなら表示は 2〜3 行で足りるし、通信も遷移のたびに 1 回で済む。

順路データそのものは、競馬アプリで年間開催日程を .ics からパースしてアプリに内蔵したのと同じ手が使える。静的データで足りるなら、原則 4 を通信なしで満たせることになる。

工場や倉庫、巡回点検といった現場の課題感については、SORACOM の IoT ソリューションは建設・工事現場で求められているかや建築設備メンテナンス視点で SORACOM の IoT を分類し直すでも扱っている。

案 2: 小売店売り場での商品検索 — 4 原則を全部満たす

こちらは 4 つの原則をきれいに全部満たす。

表示が数行に収まる（原則 1） — 答えは「通路番号・棚段・在庫数」の 3 行
呼ばれたときだけ動く（原則 2） — 商品名を聞かれた瞬間にだけ照会する。カメラによる常時棚認識をやるとここで死ぬので、そこはやらない
標準機能とかぶらない（原則 3） — 店舗固有の商品マスタと在庫は、AI 検索では絶対に出てこない
API が既にある（原則 4） — 商品マスタと在庫は基幹システムが持っている。REST の口があるかどうかが、そのまま実現可否になる

想定する利用者は、買い物客より店員だろう。理由は 3 つある。

客に 11 万円のデバイスを貸し出す運用は成立しにくい
店員なら「A-7 通路中段」のような社内コードがそのまま通じる。客向けには変換が要り、表示行数が増える
接客中に手が塞がっている場面こそ、スマホを出さずに答えられる価値が出る

実装上の注意点は 3 つ。ひとつめは、SwitchBot で踏んだ署名の壁がそのまま再来すること。店舗システムの API に署名が要るなら、HMAC は自前実装になる。逆に言えば、それさえ越えれば普通の REST クライアントを書くだけになる。

ふたつめは読み上げで、cancel() がない以上「A-7 通路、中段」の 1 文で言い切る必要がある。長い説明を流し始めると止められない。

みっつめがエージェント名だ。「売り場検索」「在庫確認」のような汎用語は予約ワードと衝突しうるので、店舗固有の名前を付けておくほうが安全だと思う。

なお、ここでいう「API が既にある」は、外から叩ける形で公開されているという意味で読む必要がある。公開されていても形が違えば直接は叩けない例として、kabu ステーション API はクラウド API ではない — localhost:18080 に立つサイドカー型の正体を書いたことがある。グラスから直接 fetch する設計では、この違いが致命的になる。

その他の案

同じ 4 原則で振るうと、他にも通りそうな案がいくつか出てくる。業務系はほぼ売り場検索と同じ骨格で、「答えが短い文字列に落ちる」「呼ばれたときだけ動く」「現場固有のデータなので AI 検索では出てこない」の 3 つが揃う。

案	視界に出す内容	叩く先
設備点検・検針	機器名 / 前回値 / 今回の点検項目	設備台帳・点検履歴
倉庫のピッキング	ロケーション / SKU / 数量	WMS
飲食店ホールの卓別確認	卓番 / 未提供品 / アレルゲン	POS・オーダーシステム
電気工事の結線確認	端子番号 / 線色 / 回路名	結線表（静的データで足りる）
訪問看護・介護の申し送り	利用者 / 前回バイタル / 当日の手順	記録システム
農業の圃場作業指示	区画 / 作業 / 前回散布日	営農記録

どれも実現性を決めるのは原則 4 だけで、既存システムに REST の口があるかどうかに尽きる。結線確認のように、そもそもデータが静的で済むならアプリに内蔵してしまえば通信すら要らない。

個人向けだと次のあたり。

業務用語だけを足す翻訳レイヤ — 翻訳そのものは標準機能なので原則 3 に触れるが、社内用語や製品名の対訳辞書を被せる薄いレイヤなら価値が残る
カレンダー連動の次アポ表示 — 相手名 / 議題 / 前回の決定事項。顔認識ではなくカレンダーを引くのがポイントで、原則 2 とプライバシーの両方をクリアできる
服薬やルーティンのチェックリスト — 道案内を順路のチェックリストとして設計したのと同じ骨格を、時間軸に置き換えたもの

逆に、原則に照らして落ちる案も明確になる。

常時カメラ認識系（棚の欠品自動検出、顔認識など） — 210mAh で常時カメラを回すのは原則 2 で即死する。プライバシーの問題も別に立つ
地図や図面の表示 — グリーン単色で視界の一部、という制約に対して情報量が過大
汎用の AI 検索や文字起こし — 標準機能そのもので、原則 3 に真正面から当たる

ひとつだけ「落ちる」ではなく 未確認 で保留しているのが、プッシュ通知型（ゲート変更の通知、アラート受信など）。AIUI アプリは音声起動が入口なので、バックグラウンドで通知を受け続ける経路があるかどうかを実機で確認していない。ここが空いていれば案の幅がかなり変わるので、優先して調べたい。

まとめ

道案内は、地図をやめて順路のチェックリストにすれば成立する。売り場検索は 4 原則を全部満たし、残る変数は店舗システムに外から叩ける API があるかどうかだけになる。

そして案の良し悪しを分けているのは、AI グラスらしさではなく「答えが 3 行に収まるか」「呼ばれたときだけ動かせるか」という、きわめて散文的な条件のほうだった。

次に試すこと

制約側はだいたい把握できたので、次は「答えを返す API」のほうを調べたい。具体的には、店舗の商品マスタや在庫にどういう外部インターフェースが用意されているのかという話で、ここが空いていると案 2 は実装以前に止まる。

道案内のほうは、まず順路データを静的データとしてアプリに内蔵する形（競馬アプリで開催日程にやったのと同じ手）で、測位なしのチェックリスト型を試してみるつもり。

グラス単体で完結させるか、スマホをハブにして重い処理を逃がすかという分岐もある。ギャップロの記事によれば Android アプリをグラス単体で動かすこと自体は可能とのことだが、同記事の結論はむしろ「重い処理はスマートフォンに逃がすべき」で、単体完結を勧めてはいない。AIUI とは別の選択肢として頭には置きつつ、まずは AIUI で進めるのが素直だろう。

ついでに書いておくと、「ドキュメントにあっても実機に無い」の類は Rokid に限った話ではない。Video Use の「沈黙する失敗」— ffmpeg が成功しても動画が壊れる 5 つの罠と 12 の Hard Rulesでも、ツールが成功を返しているのに実体が壊れている、という同じ形の罠を扱った。実機で確かめる以外に検出手段がないという点で構造が同じだ。