概要
- Brilliant Labs の最も強力な主張は、AI をメガネに搭載できることではない。それは、オープンなカメラとマイク付きのウェアラブルが、ユーザーに脆弱なガジェットのループ管理を強いることなく、視覚的または音声的なコンテキストの繰り返しの瞬間を有用な支援に変換できることである。
- 証拠は、技術的に真剣な開発者プラットフォームを裏付けている：公開リポジトリ、文書化された Bluetooth インターフェース、Lua スクリプティング、モバイルホストアプリ、カメラとオーディオ API、そしてマイクロディスプレイ、マイク、スピーカー、センサー、NPU 級のマイクロコントローラー、300 mAh バッテリーを備えた新しい Halo デザイン。
- 同じ証拠が商業的な問題も示している。Frame と Halo は、ホストアプリ、Bluetooth、クラウド AI サービス、プライバシー制御、充電動作、ファームウェアアップデート、開発者のメンテナンスに依存している。各依存関係がレイテンシー、修正作業、または信頼コストを追加しうる。
- Frame に関する一般ユーザーのシグナルは賛否両論だった。一部の早期採用者はフォームファクターとオープン性を気に入ったが、他のユーザーはペアリング、オンボーディング、アプリの成熟度、カメラの実用性、サポートに対する不満を報告した。これらのシグナルは統制されたテストではないが、受け入れられるウェアラブル AI は繰り返しによって判断されるため重要である。
- Brilliant Labs が一般的なタスク全体で低摩擦でプライバシーを尊重し、一日中使える信頼性を証明できるまでは、最も明確な短期的価値は、開発者および実験的なウェアラブルコンピューティングプラットフォームとしてであり、電話ベースの AI の主流の代替ではない。
製品はアイウェアだが、仕事はインタラクションの受容だ
Brilliant Labs は、機能ごとにあらゆるスマートグラスベンダーと競おうとする小さなハードウェア企業として見られると誤解されやすい。同社の公の立場は、より狭く、同時により野心的である。Brilliant Labs は、AI アイウェアが開発者にとって十分にオープンで、ユーザーの実際の環境にとって十分にパーソナルであることを望んでいる。Monocle はクリップオン式の AR モジュールとしてテーゼを可視化した。Frame はそれをより通常のメガネに近づけた。Brilliant Labs 自身のサイトで現在のフラッグシップである Halo は、カラーマイクロディスプレイ、骨伝導オーディオ、マイク、低消費電力光学センサー、Bluetooth 5.3、Lua インターフェースを備えた ZephyrOS、クロスプラットフォームのモバイルアプリ、クラウドベースの AI エージェントを搭載し、このアイデアをさらに推し進めている。
これらの仕様は重要だが、テストではない。テストは、人がそのインタラクションを受け入れるかどうかである。ウェアラブルアシスタントは、一度答えられるから便利なのではない。それを使うコストが、スマートフォン、ラップトップ、検索ボックス、ノートアプリ、あるいは他の人を使うコストよりも低いときに、ユーザーが再びそれに手を伸ばすかどうかが問われる。その閾値は深刻だ。なぜなら、ウェアラブルは顔に装着されるからだ。社会的な許可、物理的な快適さ、バッテリーの信頼、プライバシーの確信、新しい習慣を要求する。デバイスがコンテキストを逃したり、待ち時間が長すぎたり、バッテリーが早く切れたり、露出しすぎたり、あまりにも多くのリセットを要求したり、繰り返しの修正をユーザーに強いたりするなら、製品が印象的であり続けても、インタラクションは失敗しうる。
したがって有用な枠組みは「グラスが AI を動かせるか」ではない。それは「Brilliant Labs が、日常的な繰り返しのタスクにおいて、コンテキストキャプチャを信頼でき制御可能なものにできるか」である。答えはまだ不確かだ。公開された記録は、真剣なエンジニアリングと一貫した開発者戦略を示している。また未解決の依存関係リスクも示している。Brilliant Labs は単にグラスを出荷しているのではない。ユーザーに、センサーから Bluetooth、電話やホストアプリ、そしてモデルサービス、メモリ制御、ディスプレイレンダリング、オーディオフィードバック、アプリストア配信、ファームウェア更新、開発者ツールに至るチェーンを信頼するよう求めている。どのポイントでの失敗も、ハンズフリーの瞬間を手での修復作業に変えうる。
だからこそ、受け入れられるウェアラブル AI は、発売デモの目新しさよりも優れた基準なのだ。発売デモは、好都合な照明、準備されたタスク、辛抱強い観客を使える。受け入れられた使用には、そのような保護はない。ユーザーは歩き、買い物をし、料理をし、機器を修理し、会議に出席し、標識を翻訳し、名前を思い出し、ルートを確認し、混雑した環境で何かを特定しようとしている。アシスタントは、十分に気づき、わからないときは明確化を求め、注意を妨げずに答えを示すか話し、ユーザーが容易に修正できる方法を提供しなければならない。勝つ製品は、最も魔法のような最初の答えを出すものではない。間違った答えが、ユーザーに装着したことを後悔させないものだ。
Brilliant Labs は、オープン性を制御面として選択した
Brilliant Labs の物語で最も永続的な部分は、オープンな開発者姿勢である。同社の GitHub 組織には、Frame、Noa、アシスタントコンポーネント、ユーティリティ、SDK のリポジトリが含まれる。新しい Brilliant SDK リポジトリは、Halo や Frame と通信するアプリケーションを構築するためのマルチプラットフォームスタックを提示している。これは、デバイス上でユーザースクリプトを Lua 5.3仮想マシンで実行し、ディスプレイ、Bluetooth、IMU、オーディオ、ファイル I/O 等のためのframe.*API を公開することを説明している。ホスト側 SDK は、Bluetooth Low Energy 通信、メッセージフレーミング、画像、テキスト、オーディオ、センサーデータ、タップ、クリックイベントなどのリッチデータタイプを処理する。
これは装飾的なオープンソースレーベルではない。それは Brilliant Labs が約束できることとできないことを形作る。良い面は、開発者がスタックの大部分を調査、適応、拡張できることだ。同社は Python、Flutter、Web Bluetooth のルートに加え、より多くの制御を求めるチーム向けの直接 Bluetooth LE 開発についても文書化している。またハードウェアマニュアルや Lua API リファレンスを提供し、ドキュメントには Halo アプリ用のエミュレータが説明されており、ソフトウェアで Lua スクリプトを実行し、仮想の256×256ディスプレイをレンダリングし、ボタンや IMU イベントを注入できる。小さな会社にとって、これは外部の開発者に実験の負荷の一部を担わせる意味のある試みである。
トレードオフは、オープン性がメンテナンスコストを取り除かないことだ。しばしばそのコストを、最も扱える能力のある人々の手に移動させる。開発者は巧妙な Halo や Frame アプリを構築できるが、ユーザーは依然として同じ物理的および接続性の制約を通じてそれを体験する。デバイスには限られたバッテリー、限られたメモリ、小さなディスプレイ、Bluetooth パケット制限、ファームウェアの動作、ホストアプリがある。堅牢なフィールドツールを望む開発者は、ペアリングの回復、オフライン動作、レイテンシー予算、プライバシー通知、エラー表示、バッテリー状態、アプリストアのルール、パーミッションダイアログ、ファームウェアの移り変わり、iOS、Android、デスクトップやブラウザコンテキストにわたるサポートについて考えなければならない。Brilliant Labs は実験への参入障壁を下げるが、ウェアラブルコンピュータの運用負担を廃止するわけではない。
これは商業的に重要である。なぜなら、ターゲット顧客は単に目新しさを求める消費者だけではないからだ。Brilliant Labs は、最も明確に開発者、ウェアラブルコンピューティング愛好家、早期採用者、アクセシビリティ実験者、フィールドワークの工夫者、ハンズフリーAI インタラクションを評価するチームに語りかけている。それらのユーザーにとって、オープン性は購入の論拠である。それはロックインを減らし、公式アプリが不十分なときでもデバイスを有用にする。しかし主流のユーザーにとって、オープン性は通常目に見えない。主流のユーザーは、接続するか、応答するか、一日を生き延びるか、部屋を尊重するか、ミスから回復するかを見る。Brilliant Labs は両方のオーディエンスを必要としているが、証拠は現在のところ開発者オーディエンスの方が適合していることを示唆している。
アーキテクチャは、モデルが回答する前に電力とレイテンシーの境界を作り出す
Brilliant Labs 自身のドキュメントは、Frame と Halo が従来のアプリランチャーを備えた小さな電話ではないことを明確にしている。これらのデバイスは通常、電話、コンピュータ、ブラウザ上で動作するホストアプリケーションの周辺アクセサリとして機能する。ホストアプリは Bluetooth を介して通信し、カメラ、マイク、スピーカー、ディスプレイなどの機能を制御する。Lua スクリプトは特定の動作のためにグラス上で実行できるが、通常はホストアプリがメインロジックを駆動する。Brilliant が Frame と Halo のために示す例では、Noa モバイルアプリがデバイスに接続し、Bluetooth 経由でセンサーデータを受信し、処理してコンテンツをディスプレイに送り返す。
この設計は賢明である。グラスを軽量で電力制約下に保ちながら、電話やホストがより重い計算、ネットワークアクセス、アプリ配信を処理できる。また、受け入れられるインタラクションはループ全体に依存することを意味する。ユーザーがタップし、話し、または尋ねる。グラスがオーディオ、画像、センサーデータを収集する。デバイスがデータを分割し Bluetooth 経由で送信する。ホストアプリが処理または転送する。クラウドモデルがそれを解釈するかもしれない。応答が返る。ホストがテキスト、画像、オーディオ出力を送り返す。グラスが表示または再生する。ユーザーはその答えが有用かどうかを判断する。
各ステップは最適化できるが、各ステップはまた潜在的な遅延である。公式資料は Noa と Halo の低レイテンシー野心を説明しており、ハードウェアには低消費電力センシングとオンデバイス AI のために選ばれたコンポーネントが含まれている。しかし、公開資料は、通常の環境での繰り返しタスクに対する制御されたエンドツーエンドのレイテンシーベンチマークを提供していない。その不在は重要だ。ウェアラブルレイテンシーはラップトップのレイテンシーのように判断されない。ブラウザでの2秒の遅延は受け入れられるかもしれない。標識、棚、機械、患者、顧客、見知らぬ人の前に立っている時の2秒の遅延は気まずく感じられる。5秒の遅延は、ユーザーに頭を下げさせ、電話をチェックさせ、グラスを放棄させるかもしれない。
モデルのレイテンシーとインタラクションのレイテンシーには違いもある。モデルは正しいリクエストとコンテキストがあれば素早く答えられるかもしれない。ウェアラブルのタスクには、キャプチャ時間、ウェイク検出、音声文字起こし、画像露光、Bluetooth 転送、モバイルオペレーティングシステムのスケジューリング、アプリのフォアグラウンドまたはバックグラウンド動作、ネットワーク可用性、モデルルーティング、メモリルックアップ、応答レンダリング、ユーザーの修正パスが含まれる。Brilliant Labs はそれらの多くの部分を改善できるが、受け入れられるインタラクションテストはそれらすべてを数える。ユーザーはどのサブシステムが停止の原因かを気にしない。
Frame のドキュメントは制約をより明確に示している。Frame のハードウェアマニュアルには、640×400カラーOLED ディスプレイ、20度の視野角光学系、720p 低消費電力カラーカメラ、マイク、グラフィックスとイメージングのための FPGA アクセラレーション、Bluetooth 5.3、210 mAh の内蔵バッテリー、加速度計、電子コンパス、Lua ベースの OS、自身の140 mAh バッテリーを備えた充電ドックが記載されている。それはそのサイズにとって真剣なパッケージだが、無制限の計算面ではない。電力、熱、ディスプレイの明瞭さ、キャプチャ品質、接続性、快適さをトレードオフしなければならない。
Halo は重要な点でプラットフォームを改善している。そのハードウェアマニュアルには、256×256の描画可能領域を持つ0.2インチカラーOLEDoS マイクロディスプレイ、640×480グローバルシャッターカラーカメラ、ステレオマイク、ステレオ骨伝導スピーカー、Arm Ethos-U55 NPU を備えた Arm Cortex-M55 CPU、Bluetooth LE 5.3、300 mAh バッテリー、加速度計、電子コンパス、Lua VM を備えた Zephyr OS、磁気充電コネクタが記載されている。カメラのドキュメントは低消費電力キャプチャを特記し、マイクのセクションでは常時オーディオアクティビティ検出モードを含む複数の電力モードを説明している。これらの選択は直接ウェアラブルループを狙っている。ウェイク検出、コンテキストキャプチャ、オーディオフィードバック、低消費電力動作をサポートする。それら自体では、日常のタスクが信頼できると感じられることを証明しない。
コンテキストキャプチャは製品の約束であり、最も困難な失敗モードである
Brilliant Labs の提案はコンテキストに基づいている。電話アシスタントはユーザーがタイプするか、話すか、写真を添付するのを待つ。ウェアラブルアシスタントは、原則として、ユーザーが見るもの、聞くもの、行うものを利用できる。だからこそ、同社は Noa が視覚とオーディオのコンテキストを理解すること、Halo がカメラ、マイク、IMU、メモリシステムを含むこと、開発者ドキュメントが写真、オーディオ、IMU 値、タップ、クリック、ディスプレイプリミティブを公開することを語る。製品はユーザーの周囲の世界を入力ストリームに変えたいと思っている。
それはまた、失敗の代償が高くなる場所である。グラスが標識を読み間違えたり、誤ったオブジェクトを捉えたり、間違った指示を聞いたり、誤った意図を推論したり、シーンの関連部分を逃したり、古い記憶から答えたりすれば、ユーザーはインタラクションを修復しなければならない。電話での修正は慣れている：テキストを編集する、写真を撮り直す、メニューをタップする、リンクをコピーする、別のアプリをチェックする。グラスでの修正はより難しい。ユーザーは小さなディスプレイ、限られた制御面、音声コマンド、タップ、モバイルコンパニオンアプリ、社会的制約を持っているかもしれない。修正に電話が必要なら、当初のハンズフリーの利点は縮小する。
Brilliant Labs はこれを理解しているように見える。Frame から Halo への移行は、単なる外殻の変更ではない。それはスピーカー、より新しいセンシングパッケージ、NPU 機能を備えた低消費電力プロセッサ、より強いメモリの物語を追加している。同社の Halo の資料は、Noa を、見たもの、聞いたもの、話したものを記憶し、将来の支援をパーソナライズできるクラウドベースの AI エージェントとして説明している。Halo への道のりに関する公式投稿は、プライベートメモリ、環境コンテキスト、日常のノイズから有用なシグナルを見分ける課題を強調している。それらは正しい問題だ。
しかし、メモリはウェアラブル AI において単純な機能ではない。ユーザーが理解し、監査し、修正できる場合にのみ、それは資産である。名前や以前の会話を思い出すメモリアシスタントは、適切な人物を覚え、機密イベントを望まないコンテキストから守り、永続すべきでないものをユーザーが削除または修正できる場合にのみ価値がある。メモリが間違っていれば、エラーが将来の支援を汚染しうる。メモリが正しいが、社会的に表面化するのが不適切なら、製品は信頼の問題を生み出す。ユーザーがすべてのメモリを手動でキュレーションしなければならないなら、支援は雑用になる。
公開プライバシーポリシーは、メモリがパーソナライゼーションとコンテキスト回想をサポートし、ユーザーが個別のメモリまたはメモリプロファイル全体を削除でき、生のオーディオ、ビデオ、完全なトランスクリプトは即時の機能処理を超えて保持されないと言うことでこれに答えようとしている。また、要約されたメモリデータは暗号化された形でプライベートに保存されると言っている。それは有用なコミットメントだ。しかし、実践的な疑問は残る：ユーザーはそれを信頼するのに十分なメモリ状態を見ることができるか？プライバシーの約束は恐怖を減らせるが、受け入れられた使用はまた了解性を必要とする。ユーザーは、グラスが何をキャプチャしたか、何をキャプチャしなかったか、何を保存したか、何を忘れたか、そしてアシスタントの世界の説明が自分のものと異なるときにそれを修正する方法を知る必要がある。
プライバシーはカメラファーストの AI アイウェアにとってエッジケースではない
プライバシーは Brilliant Labs の商業的な問いの中心である。なぜなら、デバイスは顔に装着され、環境をキャプチャするからだ。同社はプライバシーを差別化要因として売り込もうとしている。その利用規約とプライバシー資料は、Halo、Frame、Monocle、Noa、モバイルアプリ、関連するプラットフォームサービスを含む製品とサービスについて説明している。利用規約は、製品がオーディオ、ビデオ、環境、生体情報を処理する可能性があると警告し、ユーザーが自分の管轄区域の録音、監視、プライバシー法を遵守し、録音またはキャプチャされる可能性のある他の人々から必要な同意を得る責任があると述べている。プライバシーポリシーは、クラウド処理が自然言語や視覚タスクにサードパーティプロセッサを使用することがあるが、それらは Brilliant の指示で行動し、自らの目的にデータを使用しないよう契約上制限されていると述べている。
これらの記述は二つの理由で重要である。第一に、プライバシーリスクが理論的ではないことを確認している。ウェアラブル AI アシスタントは、最も有用な質問の多くに、ユーザーの周囲を処理せずに答えることができない。第二に、負担の一部をユーザーに課している。ユーザーは、デバイスの使用がいつ受け入れられるか、いつミュートするか、いつスリープするか、いつメモリを削除するか、いつ全くキャプチャしないかを決めなければならない。一般消費者製品では、その負担は愛好家にとって受け入れられるかもしれない。職場、教育、健康、小売、現場サービス、アクセシビリティの文脈では、それは展開ポリシーの問題になる。
Brilliant Labs 自身の公式な文言も、消費者向け使用と高重要度アプリケーションを区別している。Halo のハードウェアマニュアルは、デバイスは消費者および研究開発向けアプリケーションを意図しており、パフォーマンスと正確性が健康、安全、ミッションクリティカルな操作に重要となる使用については検証されていないと述べている。その境界は真剣に受け止められるべきである。それはグラスが現場作業者、研究者、学生、旅行者、アクセシビリティニーズのある人を助けられないという意味ではない。それは、顧客が静かに開発者デバイスを、間違った答えが誰かを傷つける可能性のある未検証の意思決定システムに変換すべきではないことを意味する。
したがって、受け入れられるインタラクションテストは傍観者を含む。ユーザーがカメラ付きグラスを会議、店舗、教室、診療所、工場、または私有の家に持ち込めば、他の人々が入力フィールドの一部となる。製品はクラウドプロバイダーから技術的にプライベートでありながら、社会的に押し付けがましいことがありうる。ローカルや暗号化されたメモリシステムは、キャプチャされることの不快感を自動的に解決しない。製品には明確なインジケーター、素早いコントロール、ユーザーの意図を明白にするデフォルトが必要である。アシスタントがよりアンビエントになるほど、隠されたキャプチャは受け入れられなくなる。
この点はデータ主権にも影響する。Brilliant Labs は、生メディアの保持を最小化し、メモリを暗号化し、サードパーティモデルの使用を制限することで露出を減らすことができる。しかし、ウェアラブル AI は依然として境界を越える：人の顔から電話へ、電話からクラウドサービスへ、クラウドサービスからウェアラブルディスプレイへ、そして潜在的には公式アプリから開発者製アプリへ。オープンプラットフォームはこれをより柔軟に、より複雑にする。それは開発者にローカルファーストやプライバシー保護設計を構築する余地を与えるが、より強い開発者の規律も要求する。悪いアプリは良いハードウェアポリシーを損なう可能性がある。
バッテリーの主張は、見出しの時間数ではなくタスクの組み合わせで判断されるべきだ
バッテリーはデモが誤解を招く可能性のあるもう一つの場所である。Brilliant Labs のウェブサイトは Halo を終日バッテリーと表現している。Halo ハードウェアマニュアルは合計300 mAh の二つの150 mAh セルを記載し、充電アーキテクチャを説明している。Halo 発売時のプレス報道は最大14時間のバッテリー寿命の数字を繰り返した。Frame に関する以前の報道は、同社の説明を引用して、はるかにタスクに依存した様相を描写していた：同社の当時の内部フレーミングによると、極端な使用では約3時間、頻繁だが通常の使用では約6〜7時間。Frame の公式ハードウェアマニュアルは210 mAh の内蔵バッテリーと140 mAh の充電ドックを記載している。
正確な数字はパターンほど重要ではない。ウェアラブル AI のバッテリーは一つのワークロードではない。アイドルセンシング、ウェイク検出、テキスト表示、カメラキャプチャ、録音、骨伝導再生、Bluetooth 転送、ファームウェア更新、画像処理、モデル呼び出し、継続的メモリ機能は異なる電力を消費する。製品はたまの質問の一日を生き延び、視覚解釈、翻訳、オーディオ応答、開発者の実験の一日では失敗するかもしれない。ユーザーは理論上の最大値を必要としない。自分の特定の使用がタスクが終わる前にデバイスを立ち往生させないという確信が必要である。
Brilliant Labs のアーキテクチャは電力制約とよく整合している。Halo のカメラは低消費電力と説明され、マイクには低電流モードが含まれ、MCU には NPU 級のハードウェアが含まれ、デバイスはより重いロジックをホストアプリに依存し続ける。それは正しい設計方向である。しかし、受け入れられるインタラクションの問いは運用上のものだ：ユーザーはどれくらいの頻度で充電するか、バッテリーが低下するとどの機能が無効になるか、バッテリー状態がどれだけ見えるか、アシスタントはどれほど優雅に劣化するか、充電はどれだけの摩擦を加えるか？
これは些細な人間工学的詳細ではない。Frame に関するある公開された技術レビューは充電アダプターのコンセプトを批判し、アダプターを忘れたり失くしたりしたユーザーは、USB-C ケーブルが利用可能でもデバイスが使えなくなると論じた。別の初期ハンズオン記事は、小さな充電クレードルと充電のために磁気ノーズパッドを取り外す必要性を指摘した。それらは逸話的なシグナルであり、普遍的な欠陥ではない。しかし、バッテリーの信頼が習慣の信頼になることを示している。電話はある程度の充電の不便さを生き延びられるが、それはユーザーが既に電話充電を中心に生活を組織しているからだ。顔に装着するアシスタントはそのルーティンを獲得しなければならない。
バッテリーはまたプライバシーとレイテンシーと相互作用する。より多くのローカル処理はクラウド露出とネットワーク依存を減らせるが、ローカル推論は電力を消費し、モデルサイズによって制限されるかもしれない。より多くのクラウド処理はデバイスの電力を節約し応答品質を向上できるが、接続性、プライバシー、サービスコストの問題をもたらす。より頻繁なセンシングはコンテキストを改善できるが、エネルギーを消費し、社会的懸念を高める。自由な選択はない。Brilliant Labs の設計は、ユーザーと開発者がタスクに適したモードを選択できるように、これらのトレードオフを十分に明示しなければならない。
Noa アプリはショーケースであると同時にボトルネックである
Noa は Brilliant Labs の AI 体験の公の顔である。Google Play のリストは Frame 用 Noa を、GPT 駆動のチャット、ウェブ検索、翻訳機能を備えた Frame AR グラス用のパーソナル AI アシスタントと説明している。ユーザーが Frame をタップし、Noa に尋ね、グラス上で応答を受け取り、アプリ内にチャット履歴を保存する。ユーザーは Noa のスタイル、トーン、応答形式、温度、応答長さを調整できる。Apple App Store のリストはこれらの機能を繰り返し、Noa が開発者向けの例としても機能し、Noa と Frame 間の Bluetooth トランザクションを詳述するハックページを含むと付け加えている。
これは巧妙な製品選択である。公式アプリは購入者に開梱即使用体験を提供しつつ、開発者が通信モデルを学ぶのに十分な詳細を露出する。またモバイル更新とファームウェア更新を通じて出荷後もデバイスを改善できる。Noa のアプリストアのバージョンノートは、2025年初頭を通じてファームウェア更新、カメラ品質改善、ログイン修正、安定性ライブラリ更新を示している。それは積極的なメンテナンスシグナルだ：製品は出荷で停止しなかった。
同じアプリ依存性はリスクでもある。Noa のオンボーディングが不明瞭なら、バックグラウンド実行が信頼できなければ、モバイルパーミッションが変われば、アプリストアのポリシーが変われば、アプリがファームウェアに追いつけなければ、サードパーティモデルのコストが変われば、ホスト OS が Bluetooth の挙動を壊せば、グラスが苦しむ。ユーザーはエレガントなオープンアーキテクチャを体験しない。デバイスは動くか注意を求めるかのどちらかだ。
初期のアプリストアとコミュニティのシグナルは、その緊張を反映している。Apple App Store のページはわずかな評価ベースを示し、一つはこのグラスを未来の一端と呼ぶ好意的なレビュー、もう一つは Frame が期待されたカメラとディスプレイ体験を提供しなかったと訴える否定的なレビューがあった。Google Play は1,000を超えるダウンロード、2025年3月の更新、そしてアプリが位置情報をサードパーティと共有する可能性があると言いつつ、データは収集されないと言うデータセーフティラベルを示していた。アプリのプライバシーラベルは開発者提供であり監査の代わりにはならないが、ユーザーは信頼形成の一部としてそれらを読む。何が収集、共有、保存されるかについてのあいまいさは、受け入れコストの一部となる。
Noa はまたモデル依存性の質問を集中させる。アシスタントが音声、画像解釈、検索、推論にクラウドモデルに依存するなら、Brilliant Labs はサービス品質、コスト、可用性、プライバシーの約束をプロバイダー間で管理しなければならない。より多くの機能をオンデバイスに移せば、モデルサイズ、バッテリー、熱、正確性、更新頻度を管理しなければならない。開発者に代替品をプラグインさせれば、柔軟性を広げつつユーザー体験を予測しにくくする。最も実際的なルートはおそらく階層的だ：ローカルウェイクと制御、可能な場合は効率的なオンデバイス支援、複雑な推論にはクラウドヘルプ、そして境界を見えるようにする開発者コントロール。
初期の Frame のシグナルは、受け入れられた使用がスペックシートよりも難しい理由を示している
Frame は十分な公の使用があり摩擦を明らかにしたので有用な証拠である。それは決して、あらゆるメガネの洗練されたマスマーケット代替品としてフレーミングされたわけではなかった。軽量フォームファクターの開発者向け、オープンソースのウェアラブルだった。一部のレビュアーとユーザーはそれを尊重した。初期のハンズオンライターは、Monocle よりも快適で親しみやすいと評しつつ、それがより成熟したスマートグラスのような消費者レベルのデバイスではないことを強調していた。同じ記事は、オンボーディングとマルチデバイスペアリングの制限、ホスト電話への依存、Frame におけるスピーカーの欠如、発売時のトークンやクレジットの制限、充電クレードルの挙動を指摘した。
別の技術レビュアーは、Frame は主に故障や困難を受け入れる早期採用者向けだと論じた。Reddit のスレッドには、ペアリング、サポート、アプリの成熟度、ハードウェアの信頼性に関するより厳しいユーザーの苦情が含まれていた。Reddit は代表的サンプルではなく、管理された欠陥率として扱われるべきではない。それでも、そのようなコメントはこのカテゴリーにとって重要である。なぜなら、受け入れられるウェアラブル AI は繰り返しのいじりに対して非常に低い耐性しか持たないからだ。ユーザーは、その日が支援に役立つ瞬間を生み出すかどうかを知る前に、デバイスを装着するかどうかを決めなければならない。記憶されたパターンがペアリングのトラブル、リセットピン、不確かなサポート、または素っ気ないアプリなら、ユーザーは装着をやめる。
最も寛大な読み方は、Frame が探索的プラットフォームとしての役割を果たしたということだ。それは Brilliant Labs に、顔に装着する AI アシスタントがオープン性を超えて何を必要とするかを教えた：より良いオーディオ、より完全なセンシングスタック、より明確なメモリ制御、より強い日常的フォームファクター、より良いデフォルトインタラクション。同社自身の Halo への道のりに関する投稿は、チームが Frame の開発と製造から厳しい教訓を学び、Halo の前にチームとサプライチェーンに変更を加えたと述べている。それはハードウェアスタートアップにとって正しい種類の告白である。バージョン1がエンドポイントではなかったことを認めている。
より厳しい読み方は、Brilliant Labs の商業的課題が未解決のままであることだ。小さな会社は愛される開発者デバイスを生産できるが、それでも公式アプリ、カスタマーサポート、モデルサービス経済、ファームウェア互換性、ハードウェア交換の期待を維持するのに苦労しうる。オープンソースは会社が減速した場合にいくらかの価値を保存できるが、消費者は一般に GitHub を通じてメンテナンスすることを期待してグラスを買わない。市場は、Brilliant Labs を、開発者の力のどれだけがユーザーの信頼性になるかによって判断するだろう。
だからこそ Halo が極めて重要である。それは多くの Frame のギャップに対処しているように見える：オーディオ出力、改善されたカメラとディスプレイの選択、より明示的なプライバシー主張、メモリシステム、オンデバイス AI ハードウェア、そしてより明確な自然でマルチモーダルな会話のストーリー。しかし Halo はハードルも上げる。メモリと日常的な AI を約束するデバイスは、開発者のおもちゃよりも信頼できなければならない。アシスタントがよりパーソナルになるほど、ユーザーは間違いに対してより寛容でなくなる。
開発者の経済性はユーザー体験の一部である
開発者の経済性は、しばしば消費者ハードウェアの報道から消えるが、ここでは中心である。Brilliant Labs のプラットフォームは、開発者が自分のためにアプリケーションを構築し維持することを正当化できる場合にのみ、広く有用になる。SDK は Python、Flutter、Web Bluetooth をサポートすることで助ける。ドキュメントは BLE 通信、Lua スクリプト、ファームウェア更新パス、カメラキャプチャ、オーディオストリーミング、メッセージタイプを説明する。コミュニティプロジェクトページは、以前のデバイス向けにプレゼンター表示、QR コードスキャン、ナビゲーション、ワークアウト表示、WebRTC ビデオストリーミングなどの例を示している。それは信頼できるスタートだ。
しかし、Brilliant Labs を評価する開発者は依然として厳しい質問をしなければならない。デバイスはフィールドにどれくらいあるか？API はどれくらい安定しているか？ファームウェアはどれくらいの頻度で変わるか？Frame と Halo の両方がサポートされ続けるか？ユーザーのタスクのどれくらいがローカルで実行できるか？どれくらいがモバイルアプリを必要とするか？どのパーミッションが必要か？アプリはアプリストアのレビューを通過できるか？オフライン状態を処理できるか？誰がモデルコストを支払うか？ログとメモリはどのように削除されるか？ユーザーは Brilliant Labs ではなくアプリ開発者にどれだけのサポートを期待するか？
多くのホビイストにとって、これらの質問は楽しみの一部である。現場作業、アクセシビリティ、訓練、運用ツールを検討するチームにとって、それらは予算である。コストはデバイスの購入だけではない。統合、テスト、例外処理、プライバシーレビュー、ユーザー訓練、バッテリールーチン、サポートスクリプト、アプリメンテナンス、モデル請求、フォールバック手順だ。タスクごとに10秒節約するが、継続的なユーザー修正や管理者サポートを必要とするウェアラブル AI アプリは、電話のチェックリストよりも経済的に悪いかもしれない。
Brilliant Labs は、デフォルトスタックを最良の意味で退屈にすることで、それらの経済性を改善できる：予測可能な BLE 動作、安定した SDK パッケージ、明確なリリースノート、長いデバイスサポート期間、参照アプリ、サンプルプライバシー制御、再現可能なエミュレータテスト、シンプルな回復パス。Python ドキュメントに記述された Halo エミュレータは、開発者がハードウェアなしでインターフェースロジックをテストできるため価値がある。それはハードウェアテストを置き換えないが、反復コストを削減できる。Brilliant Labs が開発を通常のソフトウェア作業のように見せることができればできるほど、真剣なチームが試みる可能性が高まる。
同社はまた、メンテナンスで証明されるまで、ノーコードや自然言語アプリ作成を過剰に主張することを避けるべきである。Halo の Vibe Mode は、発売報道で説明されているように、自然言語コマンドを使用してカスタムアプリケーションを作成する実験的機能だ。それは刺激的だが、生成されたアプリは依然として正確性、セキュリティ、パーミッション処理、更新、削除、サポートを必要とする。一度は動くが後で黙って失敗するユーザー作成アプリは、受け入れられたインタラクションではない。それはさらなる修正負担だ。
ユーザー修正コストはウェアラブル AI の隠れた税である
Brilliant Labs にとって最も重要な経済的変数は、ユーザー修正コストかもしれない。ウェアラブルアシスタントは間違う。聞き間違え、見間違え、過度に一般化し、コンテキストを逃し、古い情報を返し、関係を幻覚し、気まずい記憶を浮上させ、間違った形式で答えるだろう。製品は、ユーザーが素早く自信を持ってそれを軌道修正できれば成功する。
修正コストにはいくつかの層がある。入力修正：ユーザーが質問を繰り返す、写真を撮り直す、頭を動かす、照明を変える。解釈修正：ユーザーがアシスタントに間違ったオブジェクト、人物、場所、意図を特定したと伝える。メモリ修正：ユーザーが記憶されたコンテキストを削除、編集、抑制する。アクション修正：ユーザーがコマンドをキャンセルまたは取り消す。社会的修正：ユーザーが他の人にグラスが何をしているか、なぜキャプチャが許容されるかを説明する。技術的修正：ユーザーが Bluetooth を再接続する、アプリを開く、バッテリーをチェックする、ファームウェアを更新する、スクリプトを再起動する。
各修正は小さくありうるが、繰り返される修正は受容を破壊する。ユーザーは日常のアイウェアよりも開発者キットに対して多くを許容するだろう。開発者は BLE ログを読むのを楽しむかもしれない。通勤者はそうしない。現場技術者は、デバイスが後で主要な手順を節約するなら、再起動を受け入れるかもしれない。顧客対応の労働者は、目に見えるいじりを一切受け入れないかもしれない。アクセシビリティのためにデバイスを使用する人は、予測可能なフィードバックに依存し、あいまいな失敗に対してより少ない忍耐しかないかもしれない。
Brilliant Labs のオープンアーキテクチャは、十分な状態を露出すれば修正を助けることができる。開発者は診断、フォールバックモード、明示的なレビューフローを構築できる。公式アプリはチャット履歴、調整コントロール、ファームウェア状態、Bluetooth トランザクションを表示できる。プライバシー制御はユーザーがメモリを削除できるようにする。デバイスはタップ、クリック、音声コマンド、表示メッセージをサポートできる。しかし、修正は第一級のインタラクションとして設計されなければならず、開発者の後付けとしてではない。ユーザーは事実上「それは間違ったオブジェクトだった」「その記憶を忘れて」「短く答えて」「その主張のソースを見せて」「今ミュート」「今スリープ」「今再接続」「オフラインモードを使え」と言えるべきである。その層がなければ、マルチモーダルインテリジェンスは脆くなる。
ここで Brilliant Labs のブランドの約束と製品の現実が出会う。「オープン」はベンダーロックインに対する強い答えである。それは、一秒で間違った答えを修正してほしいユーザーにとっては弱い答えである。同社はオープン性を目に見える制御に変えなければならない。ユーザーはアシスタントを信頼するために Lua や Bluetooth を知る必要があってはならない。開発者は安全なワークフローを作るためにアプリの挙動をリバースエンジニアリングする必要があってはならない。最良の結果は、深い制御が存在しながら、通常の修正がシンプルなままのスタックだ。
商業的なケースは、ハンズフリーのコンテキストが電話の摩擦に勝る場所で最も強い
Brilliant Labs のアプローチが明らかに理にかなうタスクがある。ユーザーの視野内のプレゼンターノートは電話よりも自然でありうる。QR コードやバーコードスキャナーは手が塞がっているときに有用でありうる。翻訳は頭を下げる必要のないディスプレイの恩恵を受けられる。視覚的識別は、オブジェクト、ラベル、標識、植物、部品、簡単なフィールド観察に役立ちうる。ナビゲーションの合図は、電話をちらっと見ることを避けられるとき有用でありうる。メモリのナッジは、プライバシーと正確性が制御されていれば、名前、以前の会話、繰り返しのルーチンに役立ちうる。
共通のパターンは「どこでも AI」ではない。それは、グラスが実際の中断を減らすハンズフリーのコンテキストだ。タスクが電話の方が簡単なら、電話が勝つ。タスクが大きな画面を必要とするなら、電話かラップトップが勝つ。タスクが高い正確性、監査証跡、説明責任を必要とするなら、未検証のウェアラブルアシスタントは不適切かもしれない。タスクが短く、状況に埋め込まれており、ユーザーが見たり聞いたりするものによって改善されるなら、Brilliant Labs には信頼できる切り口がある。
その切り口は消費者に限定されない。開発者やチームは、訓練補助、軽量テレメトリ、アクセシビリティの合図、研究ツール、検査チェックリスト、コンテキスト表示のプロトタイピングに価値を見出すかもしれない。Halo のハードウェアマニュアルの消費者および研究開発の境界はその方向を指している。それは、デバイスが重要な決定のために認証されているふりをすることなく実験を招待する。それは商業的に正直であり、直接の市場を狭めるが。
価格設定は助けになるが問題を解決しない。公の発売報道では Frame は349ドル、Halo は299ドルだった。これらの価格は多くの実験的なウェアラブルと比較して手頃だ。しかし、真のコストにはユーザーの時間、開発者のメンテナンス、組織のポリシー作業が含まれる。安価なデバイスでも、有用なタスクごとにアプリのカスタマイズ、モデル料金、サポートが必要なら高くつきうる。より高価なデバイスは、それが確実に労働を節約するなら正当化できる。Brilliant Labs はカテゴリーの熱意によってではなく、ユースケースによって後者を証明しなければならない。
最も強力な短期的商業ルートは、Halo をウェアラブル AI 実験のデフォルトのオープン参照デバイスにすることかもしれない。それはすべての購入者が日常の消費者になることを要求しないだろう。十分な数の開発者、研究者、初期のチームがそのプラットフォームを構築するのに十分信頼できると扱うことを要求するだろう。そこから、繰り返されるユーザータスクが出現しうる。リスクは、同社がオーディエンスの間で立ち往生することだ：主流の消費者には技術的すぎ、エンタープライズプログラムには小さすぎ、アプリの多様性を愛好家に依存しすぎる。
インタラクションが受け入れられたことを証明するものは何か
Brilliant Labs のテーゼを格上げするために必要な証拠は単純明快だ。第一に、繰り返しのタスク研究が、目新しさの期間が終わった後も、ユーザーが特定の仕事のためにグラスを電話よりも選ぶことを示すべきだ。単一のデモ、ローンチビデオではなく、日々の選好だ。第二に、エンドツーエンドのレイテンシーがタスクごとに測定されるべきだ：ウェイクからトランスクリプトまで、画像キャプチャから応答まで、メモリ回想から表示まで、翻訳要求から有用な出力まで、オフラインフォールバックとクラウドフォールバック。第三に、バッテリーは見出しのモードではなくタスクの組み合わせによって測定されるべきだ。第四に、プライバシー制御が通常のユーザーでテストされるべきだ：彼らは何がキャプチャされたかを理解し、削除し、ミュートし、デバイスを傍観者に説明できるか？第五に、開発者のメンテナンスは、単純だが有用なアプリをプラットフォーム間で構築、出荷、更新、サポートするのにかかる時間によって測定されるべきだ。
製品はまた、失敗の回復によって判断されるべきだ。ペアリングはどれくらいの頻度で失敗するか？アプリはどれくらいの頻度でフォアグラウンド化される必要があるか？電話がネットワークを持たないとき何が起こるか？デバイスはどのように不確実性を示すか？ユーザーはメモリを修正できるか？アプリはプライベートコンテンツを露出せずにサポートに十分なログを露出するか？Halo が中心になるにつれて Frame はどれくらいサポートされるのか？Brilliant Labs はモデルプロバイダーの変更をどのように扱い、古い動作を壊さないか？
これらの質問は敵対的ではない。それらは顔に装着する AI デバイスに対する通常のデューデリジェンスだ。Brilliant Labs は既にいくつかの良いアーキテクチャ上の選択を行っている：小型のウェアラブルハードウェア、オープンな開発者資料、ホスト側の柔軟性、Lua スクリプティング、BLE ドキュメント、公式アプリ、プライバシー主張、メモリ制御、より能力の高い Halo ハードウェアプラットフォーム。問題は、それらの選択がユーザーの総コストを圧縮するか、あるいは単により多くのコンポーネントに分散させるかどうかだ。
2026年7月現在のありそうな答えは、条件付きである。Brilliant Labs はオープンなウェアラブル AI プラットフォームとして信頼できる。それはまだ主流のユーザー向けの受け入れられた日常的な AI インタラクションとして証明されていない。その最良の見通しは、ユーザーが技術的に寛容であり、タスクがハンズフリーで状況に即しており、プライバシールールが明確で、レイテンシー要件が控えめであり、コンテキストキャプチャの価値が修正負担よりも大きい場所にある。開発者と実験的チームはそれを機能させられる。一般消費者はより多くの証明を必要とするだろう。
この結論は却下と読まれるべきではない。多くの重要なインターフェースは不格好な開発者ツールとして始まる。マウス、スマートフォンカメラ、スマートウォッチ通知、ワイヤレスイヤホンは、それぞれ繰り返される有用性を通じて自分の場所を獲得しなければならなかった。Brilliant Labs はよりセンシティブなインターフェースを追加しようとしている：顔に装着するカメラ、マイク、ディスプレイ、アシスタントだ。そのインターフェースは、それがトリックのように振る舞うのではなく、受け入れられた習慣のように振る舞う場合にのみ価値がありうる。同社の未来は、Noa と Halo が有用な答えを、電話の次の一瞥よりも安く感じさせられるかどうかにかかっている。