エッジでの AI 実行：ブラウザ内で実ワークロードを実行するプレゼンテーション

InfoQ ホームページ

プレゼンテーション一覧

エッジでの AI 実行：ブラウザ内で直接、本物のワークロードを実行する

プレゼンテーションを見る

所要時間：49:08

/presentations/local-ai-browser-inference-privacy/en/slides/slide-1787569871512.jpg)

概要

ジェイムズ・ホールは、クラウドプロバイダーからローカルのエッジデバイスへ AI ワークロードを移行することの戦略的かつ技術的な必要性について語ります。WebGPU、Transformers.js、DuckDB を活用した実践的なアプローチを紹介し、JavaScript でネイティブに近いパフォーマンスを実現する方法を解説します。実際のケーススタディを通じて、データプライバシーリスクの最小化、ブラウザ推論の最適化、そして厳密な評価スイートの構築方法を伝えます。

プロフィール

ジェイムズ・ホールは Parallax のテクニカルディレクター兼創設者です。AI およびソフトウェアコンサルティングを率いています。また、月間ダウンロード数 4,000 万件に達する、最も広く使われているオープンソース JavaScript ライブラリのひとつ「jsPDF」の生みの親でもあります。

コンファレンスについて

ソフトウェアは世界を変えています。QCon London は、開発者コミュニティにおける知識とイノベーションの普及を促進することで、ソフトウェア開発を強化します。実践家主導のこのカンファレンスは、チーム内でイノベーションに影響を与える技術リーダー、アーキテクト、エンジニアリングディレクター、プロジェクトマネージャーを対象に設計されています。

INFOQ EVENTS

9 月 17 日午後 1 時（EDT）

PR の向こう側：エージェント型ソフトウェアデリバリーの新たなコントロールプレーン

登壇：モヒット・スーマン氏（Harness 上級プロダクトマネージャー）

10 月 8 日午後 12 時（EDT）

AI が開発を加速させる中、CI パイプラインは追いつけるか？

登壇：エリック・メタジ氏（Datadog ソフトウェアデリバリー担当プロダクトマーケティングマネージャー）、ロヒン・チャンドラ氏（Datadog CI/CD 最適化担当プロダクトマネージャー）

トランスクリプト

ジェームズ・ホール： 自己紹介と背景について少しお話しします。私がこれまで取り組んできたことへの文脈をお伝えし、なぜローカルで実行するのか、その意義について解説します。随所デモを挟みながら、現在の技術が実際にどう見えるか、体感していただけるように努めます。

また、これらの仕組みが高レベルでどのように動作するかを説明し、いつそれを使うべきかの指針をお伝えできれば幸いです。同時に、私が経験した失敗や落とし穴も共有します。多くの戦傷と過ちから学んだ教訓を、皆さんにも役立てていただければと思います。

背景

少し背景をお話しします。私は 15 年前にテックコンサルティング会社を立ち上げました。私たちが手掛けるのは、顧客のためのデジタルプロダクトの構築です。街路灯から車の遠隔ロック解除、AI ダッシュボードまで、実に多様なプロジェクトを受注してきました。

私の専門は JavaScript です。長年にわたり、ブラウザの可能性を最大限に引き出すような挑戦的な開発を行ってきました。2012 年、私は SPC700 エミュレータの移植に取り組みました。これはスーパーファミコン（SNES）に搭載されていたサウンドチップのエミュレーションです。当時は Emscripten の黎明期であり、C++ を JavaScript に移植することも可能でした。大量の Uint8 アレイや巨大な数値配列を操作する中で、当時まだ新しい Web Audio API と連携させることに成功しました。自分でも驚くほどの成果でした。

しかし、多くの人はこうしたプロジェクトを見て「一体何の意味があるのか？」と疑問を抱くでしょう。

エッジでの技術探求は、こうした実験的なプロジェクトを通じて非常に価値があります。2009 年まで遡りますが、私は当時「jsPDF」というライブラリを作成しました。このライブラリは今でも私の頭に残っており、最近ではダウンロード数が急増しています。おそらく、人々が AI を活用して請求書生成ソフトウェアを構築しているのでしょう。

実際、毎日数百通のメールや多数のオープンな PR（プルリクエスト）が寄せられていました。AI による批判が高まる以前から、私は自動的に PR をクローズしていました。こうした活動を通じて、多くの面白く興味深いプロジェクトや対話が生まれました。ライブラリを作ったことは後悔していませんが、PDF という形式自体は苦手です。

また、私は AI のリサイクルプロジェクトの外部アドバイザーも務めています。もう一人のアドバイザーは英国ファッション繊維協会の会長です。私たちは、自動仕分け技術を活用して繊維廃棄物を削減する方法を探っています。以前から AI とその応用に強い関心を持っており、街路灯の点検プロジェクトでは故障の自動検知や予知保全に取り組んできました。

数学的な理論が現実世界の問題解決にどう結びつくかを明確に理解できる時、私たちは特に喜びを感じます。人々を巻き込み、さまざまな応用例について議論するイベントも開催しています。

私が LLM（大規模言語モデル）に触れたのは、スタートアップで働いていた時が最初です。私たちは Kotlin と React を使ってウェブブラウザを開発し、そこに LLM を組み込んで自動タグ付けや分類を行う仕組みを実装しました。これは ChatGPT が登場する前の話です。

当時は OpenAI に「私たちが作っているアプリはこれです。機能はこうで、リスクが想定される領域はここです」と説明して承認を仰ぐ必要がありました。彼らは各ユースケースに対して非常に慎重でした。もちろん、ChatGPT のリリース後は状況が一変し、審査の厳格さは緩みました。おそらく金銭的な要因も影響したのでしょう。

このプロセスは非常に興味深く、多くのことを学ばせてくれました。また、LLM を活用したコンプライアンスプラットフォームも立ち上げ、「Tech Innovation of the Year」を受賞しました。チャットボットの構築については詳しくなりましたが、同時に「なぜ作らない方がいいのか」という理由についても深く理解するようになりました。

この経験からは、数多くの教訓と戦傷のような痕跡を得ています。

結果として、現在は当たり前になっている多くのシステムを構築することになりました。製品の一部として、独自の LLM 評価および観測プラットフォームも開発しました。また、チャットボットを利用するユーザーは非常に自由度が高いため、彼らを特定の体験へと誘導する必要があることも発見しました。そこで考案されたのが「チェックリスト」の概念です。構造化出力に相当する独自の実装もありましたが、当初は非常に簡素なもので、ユーザーを特定のパスへ導くための試みでした。

この取り組みを通じて多くのことを学びました。その成果が、英国の大規模な iGaming 企業からの注目につながりました。私たちは Timeform チームと協力し、機械学習モデルと LLM を融合させるプロジェクトに着手しました。これは Amazon Web Services が実施した概念実証（PoC）を引き継ぐ形となりました。同社では、競馬の着順をある程度の精度で予測することに成功していませんでした。F スコアは 0.5〜0.6程度で、単なるランダムな推測よりもわずかに良い程度でした。

しかし私たちは、様々な技術を組み合わせることで、わずか数週間で F スコアを約 0.9 に引き上げることに成功しました。このプロジェクトを通じて得た知見は、本発表の基盤となっています。現在、新しい組織との協業の中で培った考え方や、産業用 IoT（IIoT）における大量データの扱い方——データをどう解釈し、可視化し、トレンドをどう測定するかといった課題——も、今回の枠組みの背景にあります。

ローカル vs クラウド

今日は、ローカル環境とクラウドの違いについて少しお話ししましょう。多くの人が今や、最も手軽な選択肢であるため、ついついクラウドを選んでしまいがちです。そこには強力なモデルが用意されており、抵抗の少ない道だからです。

しかし、こうしたプロバイダーを利用し、契約を結び、顧客データを含むすべてのデータを企業に送信するケースが増えています。この仕組みの問題点は、エンドユーザーがその結果について深く考えずに、ますます多くの個人情報を開示してしまうことです。私は、これらの組織内におけるログプラットフォームのあり方に少し懸念を持っています。

従業員がデータにアクセスする際のチェックとバランスは本当に機能しているのでしょうか？例えば、米国政府からログの開示を求められた場合でも、企業が約束通り行動してくれると本当に信頼できるのでしょうか？

このように、サーバーサイド推論にはいくつかの重大な欠点があります。プライバシーの問題だけでなく、インターネット接続が不安定な状況や、全く接続できない状態への対応も課題です。

多くの国では Wi-Fi の電波状況が非常に不安定で、列車に乗っている間や信号圏外にいる場合などは特に顕著です。また、ネットワークの遅延も問題となります。リアルタイムの動画や音声処理を必要とするアプリケーションでは、この遅延は致命的な影響を与えます。例えば背景ノイズを除去する機能において、ユーザーがイギリスからアイルランドにあるデータセンターへデータを転送し、さらにエンドユーザーに戻すという経路をとれば、その遅延は体感できるほど顕著になります。

コストもユーザー数に比例して増加するため、サービスが成功すればするほどコスト負担が大きくなるというジレンマに陥ります。例えば、最新の OpenAI モデルを活用した超人気アプリを構築し、100 万人のユーザーを獲得した場合、推論コストを支払うのはその 100 万人すべてになるのです。

JavaScript で動作する、人間に匹敵するレベルの文字起こし品質を、簡単なデモでお見せします。

Whisper モデルは元々 OpenAI チームによって開発されたもので、その重み（weights）もオープンソース化されています。過去 4 年ほどで、この種のモデルを改良・発展させる取り組みが世界中で行われており、その精度は驚くほど向上しています。現在では、適切な句読点の付与や固有名詞の認識、さらには特定の業界における専門用語の正確な処理も可能になっています。

これらの高度な機能は、すべてウェブブラウザ上でのデバイス内実行（on-device）でも実現可能です。こうした事例はすでにいくつか見られています。私と Ian の親友である Nick Payne が開発したアプリケーションもその一例で、こちらはローカルの文字起こしモデルを活用して、プライバシーに配慮した完全な会議メモ作成ツールとして機能します。

私が以前、ローカルモデルの能力を披露するために作ったデモの一つでは、まだ Claude などがワンショット（one-shot）処理に対応できる前段階の技術でした。

この仕組みでは、ローカルモデルがログプローブ（log probes）を解析し、確率計算を行うことで、各トークンが発生する可能性を可視化できます。多くの商用モデルプロバイダーは、自社の最先端モデルの逆解析を防ぐため、こうした情報を隠蔽しています。ただし、最近では一部の API でこの情報が公開されるようになりました。ローカルモデルを利用する大きな利点の一つは、こうした生データにアクセスできることです。

もしすべてのログプローブが平坦で突出した値がない場合、そこにはハルシネーション（幻覚）のリスクがあることを意味します。つまり、モデルが確信を持って選択できていない状態だからです。これはタラット氏の話ですが、私とニックはロンドンのスタートアップ「Granola」が開発したアプリを逆解析しました。彼らはオーディオインターフェースに直接アクセスできる、非常に興味深い Mac API を活用していました。

また、会議の開始と終了時刻を自動的に把握できる便利な機能も用意されています。ニック氏はこれらの知見をオープンソースの Taps ライブラリとしてまとめ、オーディオインターフェースへの接続も容易に実現しています。

このシステムは、ローカルモデルを巧みに組み合わせた構成を採用しています。ベースとなるのは Electron アプリで、UI は HTML と React による JavaScript で構築されています。そして、Apple Neural Engine でネイティブに動作するローカルモデルと実際に連携します。

具体的には、NVIDIA の Parakeet やストリーミング対応のモデル、Alibaba が提供する要約用モデルなどが利用可能です。さらに、音声指紋認識や本人識別モデルも搭載されており、これらは大幅な精度低下を招くことなく量子化が可能で、ダウンロードに適したサイズに抑えられています。

ローカルモデルを利用する選択肢は、もはや一つではありません。数年前まで唯一の手段は、自前で API を用意し、モデルの重みを持ち込んで可能な限り圧縮し、量子化（Quantize）して 8 ビット整数から 4 ビットや 2 ビットに変換し、通信回線で転送してブラウザや Electron アプリ、デスクトップアプリケーションにキャッシュするというものでした。これが当時の唯一の方法でした。

しかし、このエコシステムは驚くほど進化を遂げました。それでもなお課題は残っています。現在、Chrome チームが取り組んでいる問題の一つが、同じオリジン（Same Origin）におけるキャッシュの制限です。この標準規格が正式に承認されれば、ウェブサイトや Web アプリで特定の場所で使用したモデルを、他の場所でも再利用できるようになります。

これは「自分で用意する AI」の活用ルートです。このアプローチでは、WebGPU を基盤とした WebLLM を使用します。また、Hugging Face が提供する Transformers.js もあり、こちらは ONNX Runtime を利用しています。さらに、TensorFlow などローカル推論を提供する他のプロバイダーも存在します。

組み込み AI は非常に新しい技術で、つい最近まで性能はあまり期待できるものではありませんでした。私は Chrome の初期プライベートベータリストに参加しており、その当時 Gemini Nano のごく初期バージョンを試していました。当時はレシピページからレシピ情報だけを抽出し、記事や余計な情報を排除するブラウザ拡張機能を作ろうとしましたが、プロンプトとの格闘が必要で、意図した動作をさせるのに苦労しました。

しかしその後、技術は飛躍的に進化しました。現在の Nano Gemini モデルは以前よりもはるかに良くなり、また意味のある組み込み API が多数提供されるようになりました。

プロンプト API だけでなく、翻訳機能や要約機能、言語検出機能も利用できるようになりました。各社がこぞってこれらの標準化を進めており、Chrome や Firefox をはじめとする主要ブラウザベンダーや組織メンバーも、同じような API の方向性で合意を形成しています。

ポケットの中にあるハードウェアの性能が飛躍的に向上している今、こうした可能性を探らないのは惜しいことです。現在、デバイス上ではより高性能なニューラルプロセッシングユニット（NPU）や、AI 処理に特化した専用 GPU が利用可能になっています。

すべての処理をクラウド上のサム・アルトマン氏のもとへ送るだけでなく、そのメリットとデメリットを比較検討し、別の解決策を探る余地があるはずです。

Transformers.js は本当に素晴らしいツールだと思います。ここには非常に魅力的なモデルが多数用意されており、それらと対話する方法も多岐にわたります。

JavaScript ネイティブで動作し、CPU 上では通常の JavaScript として実行できますが、自身で最適化を行う能力も備えています。かつて私が js-snes-player を開発していた頃は、最適化技術は全く存在せず、1 サイクル内で実行できる計算量は極めて制限されていました。しかし、Wasm やその他の技術が発展したことで、CPU での実行速度が劇的に向上しました。

現在では WebGPU を介して GPU に直接アクセスできるようになり、推論処理をネイティブに近い速度で実行することが可能になりました。これは非常に印象的な進化です。

何より重要なのは、すべての処理がデバイス上完結することです。API 呼び出しもサードパーティによる処理も一切不要です。また、新しいバックエンドも登場しています。WebNN はまだ初期段階ですが、今後は Android や iOS のスマートフォンに搭載された専用 GPU で動作できるようになるでしょう。

オンデバイスで動作する機械学習モデルを検討する際、モデルのサイズを比較することは非常に役立ちます。SQL 文の生成や要約といった基本的なタスクにおいては、小さなモデルでも極めて高い性能を発揮します。一方で、モデルが大きくなるほど、より複雑なタスクへの対応力も向上していきます。

現在観られるトレンドとして、異なる層や領域に対して可変幅量子化（variable width quantizing）を適用するなど、これらのモデルをいかに効率的に圧縮するかという工夫が次々と生まれています。これは非常に有用なアプローチです。

機械学習の世界には「すべてのモデルは間違っているが、その中には役に立つものもある」という有名な格言があります。私は、AI を活用したアプリケーションを開発する際、この言葉こそが最も重要だと考えています。モデルの出力を表面的に信じるのではなく、テストと検証を通じて「どの範囲でこのモデルが有用か」を明確にし、ユーザーにとって安全に利用できるかを判断する必要があります。

評価基準の設定や評価スイートの構築は、プロジェクトの初期段階で行うべき作業であり、ここが最も多くの労力を要する部分です。実際、モデル自体の統合は比較的容易な作業ですが、その周囲にあるテスト、検証、セキュリティ対策など、周辺要素の整備こそが真の難所となります。

ブラウザ内で推論を実行する際の最適化には、さまざまなアプローチがあります。ただし、ご自身でモデルの量子化を行うことは、十分な知識がない限り推奨しません。代わりに、精度の変更は可能です。多くのアプリケーションにおいて、期待されるほど品質が著しく低下することはありません。例えば、7GB のモデルを 2GB に圧縮しても、品質の低下は限定的です。

先ほども触れた通り、ハードウェアアクセラレーションには WebGPU を、汎用的な CPU フォールバックには Wasm（WebAssembly）を利用できます。これらは非常に便利です。また、WebNN の規格も今後 1〜2 年以内に実装される見込みです。

さらに、カーネルの融合やカスタム演算子の導入、事前コンパイルされたルートの利用も可能です。モデル固有のグラフ最適化やキャッシュ処理など、多様な手法が用意されています。WebLLM はこれらの機能を効果的に提供しており、ユーザーは利用したいモデルを自由に選択できます。

実際に、この技術があなたのユースケースで機能するかを試すことができます。私が期待しているのは、こうした技術の利用者が増え、クロスオリジンキャッシングの仕組みが普及すれば、最終的には Llama 3 のようなモデルを搭載したデスクトップマシンが出荷されるようになることです。そうなれば、その環境を信頼して利用できるようになるでしょう。

現時点ではまだ完全には実現されていませんが、未来を見据えて準備しておく必要があります。これが私が非常に楽しみにしているプロジェクトです。このプロジェクトこそが、NPU によるアクセラレーションへの直接的なアクセスを実現し、モバイルデバイスであっても超高速な処理を可能にします。これは、ウェブ技術を基盤としつつプライバシーに配慮したアプリケーションを構築する上で目指すべき転換点です。

私の顧客の一人は、厳格な規制が適用される分野で活動しています。彼らは産業用 IoT の情報を、商業的な大規模言語モデルを経由させることを望んでいません。

実は、こうした処理をすべてローカルで実行する意義は大きく、多くの興味深い実験の余地があります。特に「DuckDB」と呼ばれる非常に高速なデータベースが注目されています。この DuckDB には WebAssembly (Wasm) 版があり、その速度は驚くほど速いのです。

当社の顧客の中には、Redshift から大規模なデータセットを抽出して分析する際、通常であれば比較的迅速に完了するはずのワークロードでも、ローカル端末上で最適化された DuckDB を使用した方が結果が得られるケースがあり、その速度に驚いたという声があります。データを Parquet 形式でエンコードしておけば、ブラウザ上でもローカル実行が可能です。

この手法が特に威力を発揮するのは、データから洞察を得るためにさまざまなクエリの組み合わせを試す際です。LLM をミニ・データサイエンティストとして活用し、多角的なアプローチを次々と試し、出力を確認して迅速に反復していくことが可能になります。私たちは現在、仮想化された CLI を用いてこの手法を実践しており、これについては後ほど詳しく説明します。

ローカル AI の非常に優れた活用事例の一つとして、トークン分類モデルのような超小型モデルの利用があります。例えば、名前付きエンティティ認識（NER）モデルは極めて軽量で、プレーンテキスト上でも動作します。正規表現などを使わずに、「これは人名のようだ」「これは住所のようだ」といった情報を自動的に抽出できます。

これらの情報を抽出した後は、サーバーへ送信する必要がなくなるよう、処理をローカル完結させることができます。あるいは、入力内容が患者データに見える場合は警告を表示することも可能です。コンプライアンス対応が必要なアプリケーションでは、ユーザーが扱う業務領域が極めて機密性が高いにもかかわらず、「機密情報や文書のアップロードは禁止」という指示を出しても、多くのユーザーは最初に大量の患者データや臨床研究資料をコピー＆ペーストして UI に貼り付けてしまう傾向があります。

このような状況では、この技術が非常に役立ちます。例えば、「これらの理由により、データは処理できません」といったアラートを即座に表示できるからです。

実は現在、ブラウザのサポート体制は以前と比べて格段に向上しています。数年前までは難しかったものが、ついに Safari も強力なサポートを提供し始めました。Firefox がそれに続き、Chrome が最初に対応しました。現在は非常に良好な状況です。事実上、他の主要ブラウザも Chrome ベースであるため、広範な対応が可能となっています。

これらのモデルはテキスト処理だけでなく、多様な用途に活用できます。例えば、メタ（Meta）のプロジェクトの一つから生まれた面白い事例があります。テキストと感情のみを入力するだけで音楽を生成できるのです。「エレクトロ・ポップ調の曲を作って」と指示すれば、心地よい楽曲が即座に生成されます。その品質は驚くほど高いものになっています。

これまでお話ししてきた通り、ブラウザ内での推論には大きなメリットがありますが、同時に落とし穴もあることを知っておく必要があります。どのワークロードに最適化すべきかを慎重に見極めることが重要です。

特定のワークロードにおいては、推論コストをサービス側からユーザーのデバイスへシフトさせるのは非常に理にかなっています。特に WebRTC を活用する動画中心のアプリケーションでは、サーバーを経由して通信を中継するのではなく、ピアツーピアで直接接続できるため、このアプローチが有効です。

実際に優れた事例も存在します。おそらく多くの人が利用している Google Meet では、クライアント側で背景除去を行うために非常にシンプルなモデルを採用しています。これは素晴らしい工夫です。

では、どのワークロードにハイブリッドなアプローチを適用し、どこまでを完全ローカル処理とし、どこをサーバー側に任せるべきかを見極める必要があります。現時点での課題として、より大規模なモデルは複雑な推論能力を必要とするため、依然としてサーバー側で処理する方が適しているケースが多いです。

重要なのは、実行したいワークロードと、それに最適なモデルの種類が一致しているかどうかを確認することです。

What Should You Measure?

モデルの導入において最も重要な作業は、測定と基準への適合確認です。ブラウザ内での実行かクラウド利用かの判断には、何を測るべきでしょうか。

まず「最初のトークン生成までの時間」を確認しましょう。これは LLM における指標で、モデルの起動やウォームアップから最初のトークンを生成するまでの所要時間を指します。驚くことに、非常に小さなモデルであればローカル環境での実行は極めて高速です。実際、サーバーとの往復通信に要する時間が全体を占める大きな割合を占めています。

特に数十万トークン単位でデータを転送する場合、全体のレイテンシやダウンロード時間を考慮する必要があります。例えば、毎日利用される会議議事録の文字起こしアプリの場合、ユーザーが 500 メガバイトのモデルをダウンロードすることに満足するでしょうか？こうした計算を行い、最適な選択ができるよう調整することが重要です。

次に「トークン処理速度」も確認しましょう。実際に出力や補完を行う際のスピードはどれくらいでしょうか。そして最も難しいのが「精度」の評価です。

LLM を評価者として活用する方法もありますが、私は常に「単純なコードでできることは AI に任せない」と推奨しています。すべてを AI で行う必要はありません。多くの AI オーケストレーションや評価スイートでは、AI 自体を検証するためにさらに別の AI を使う傾向がありますが、それは必ずしも必要ではありません。

Privacy by Architecture, Not by Policy

エッジで AI を活用した製品を設計することで、ユーザーに対して大きな恩恵をもたらすのが、ポリシーに頼るのではなく、アーキテクチャの決定そのものによってプライバシーを守れる点です。以前お話ししたように、AWS のような大規模なクラウドプロバイダーが今後どうなるかは誰にもわかりません。彼らが情報追跡を強制されたり、異なるログファイルが公開されたりする可能性はないでしょうか？こうしたリスクは、必要なデータをローカルに留めることで回避できます。

先ほどお話しした会議メモの例をもう一度取り上げましょう。Granola など多くの会議メモアプリでは、端末で録音された生音声データがそのままクラウドへ送信されています。これらのプロバイダーの中には、API キーが誤って公開されるなど、セキュリティ侵害が発生した事例もあります。

ユーザーデータを処理するだけでさえ、ログが記録され続ける現状は、まるで有害廃棄物を扱うようなものです。極めて機密性の高い情報を取り扱うべきではないという感覚に陥ります。

Meta の Ray-Ban スマートグラスでも同様の問題が存在します。常時録画が行われ、データセンターへ送信されるか、人間が問題解決のためにレビューやタグ付けを行っている可能性があります。こうした状況に対して、あなた自身はどれほど満足していますか？また、ユーザーたちはどう思っているのでしょうか。

製品に AI を組み込む際、私は心から推奨したいのは、一歩引いて考えることです。単にチャットボットを製品に追加するだけで終わらせないでください。私がそう言う理由は、自然言語処理のような機能が魅力的ではないと思っているからです。むしろ、それらは非常に魅力的だと考えています。その理由はいくつかあります。

まず、社内開発者やステークホルダーほど忍耐強いユーザーにとって、これは非常に難しい課題です。彼らは、自社のプロダクト内でこのチャットボートが実際に何に優れているのかを解明するために、5 分もチャットでやり取りする時間など持ち合わせていません。過去にオンラインサポートのチャットボットを利用した際、結果はまばらだったという経験から、ユーザーはすでに「チャットボット疲れ」を感じ始めています。

もちろん、自然言語処理（NLP）機能をプロダクトに追加しないよう勧めているわけではありません。意味があるならぜひ導入すべきです。ただし、最初に取り組むべき手段として「チャットボートを付け加える」という安易な発想は避けるべきでしょう。

責任と技術的権限を持つあなたには、LLM やモデルとは何か、構築しているソフトウェアが実際に何に得意なのかを判断し、ユーザーのためにその選択を下す力があります。それを極めてシンプルに提供することが重要です。

AI ダッシュボード製品を開発する場合、最初に提示すべきは「何でも聞いてください」というオープンエンドな問いかけではありません。一般ユーザーは想像力が不足しているかもしれませんが、パワーユーザーにはそれが当てはまりません。実際、90% の人はさっと入り用を済ませてすぐに終わらせたいと考えています。

では、そのツールが何に得意なのかを探り出し、提案を表示させるのはどうでしょうか？また、背景でこれらの有益な洞察を既に処理し、生成可能な成果物の例を示しておくことはできませんか？

必要であれば、その後で自然言語による微調整や追加の提案を加えることができます。「このグラフを変更したい」「これを行いたい」「あれを行いたい」といった要望です。これはパワーユーザー向けの機能となります。

「そのままにしておけばいい。前面に出す必要はないし、AI が必要な場合以外は無理に AI にする必要もない。馬鹿げた話に聞こえるかもしれないが、多くの顧客と接する中でよくあるのが、『最優先事項は AI だ』という要望だが、実際にはそうではないケースが多いのだ。

SQL クエリや正規表現（regex）のような、よく設計された既存の技術で十分解決できる問題に対して、単に「AI が使えるから」という理由だけでモデルを適用するのは落とし穴である。本当に問題が複雑で曖昧な場合のみ、モデルを使うべきだ。

ローカルファーストのアプローチにおけるもう一つの落とし穴は、最初のダウンロードが非常に重く感じられることだ。ここでは積極的なキャッシュ戦略が必要であり、進行状況を表示してユーザーに安心感を与えるべきだ。理想を言えば、読み込みの過程を他の処理フローに自然に組み込んでしまい、ユーザーがそれに気づかないようにするのがベストだ。

Instagram が登場した際、誰もがその速さに驚いた。なぜあれほど高速なのか、誰も理解していなかったからだ。写真を撮ってフィルターを選び、「送信」ボタンを押すと、ほぼ瞬時に完了していた。

これはまだモバイルネットワークが非常に不安定だった時代の話だ。しかし、ユーザー体験は極めてスムーズだった。実は単純なトリックに過ぎないのだ。ユーザーが写真を撮って次のステップに進んだ瞬間から、背景で写真のアップロードが始まる。そしてフィルターを選択して送信ボタンを押している間、バックエンドに送るのは単にフィルターのテキスト名だけで、実際の画像処理は遠隔サーバー側で行われる。

読み込み時間を別のプロセスの中に隠せるのであれば、これほど効果的な方法はない。重要なのは、ユーザーが感じる「待ち時間」の長さだけだ。ユーザーが気にするのは、実際の重さではなく、自分がどう感じているかということだからだ。

データサイエンスの世界では、「AI は不要で、良い SQL クエリがあれば十分だ」というジョークが定番です。しかし、私はその発想を逆転させたいと思います。実は AI を活用して SQL クエリを書くことこそが、非常に優れたユースケースなのです。

先ほどのデモで DuckDB の例をご紹介した通り、この分析エンジン全体をブラウザ上で実行することが可能です。データから興味深い角度や洞察を見つけ出すには、いくつかのアプローチがあります。例えば、ブラウザ内で疑似的な CLI（コマンドラインインターフェース）を実行し、LLM にコマンドや引数、そして SQL を記述させる方法です。さらに、jq セレクターを使ってデータを処理することで、最小限のトークン数でデータから価値ある洞察を引き出すこともできます。

また、SQL 作成に特化した、より小さく高速なモデルも存在します。ブラウザ上で推論を行うべきか判断する際の簡単な基準は、「そのデータが機密情報を含むかどうか」です。例えば、患者の個人情報が含まれる可能性がある場合は、注意が必要です。

機密情報（PII）が含まれる可能性がある場合、ローカル推論の利用が強く推奨されます。たとえデータが最終的にクラウドに保存されることになっても、PII を保管する予定がないのであれば、少なくともその部分を削除処理することは可能です。これは有害廃棄物と同じで、ログファイルや S3 バケットに残したくありません。PII の処理が業務の目的でない限り、サーバー周辺に存在させるべきではありません。選択肢として残す必要はありません。

データに機密性はないものの、高品質さや複雑な要件を求められる場合は、クラウド API を利用するのが適切です。ローカルで十分なモデルが見つかるなら、そちらを利用すべきです。常に言えることですが、AI である必要性がないのであれば、AI は使わないことです。

Models in Action

今日は、私が非常に面白いと感じているいくつかのモデルをご紹介します。まず、画像を入力して音声と視覚を統合したデモがあります。例として使っているのはパンの写真ですが、この小さなデモは非常に興味深いです。

このシステムは 2D のピクセルマップを受け取り、各ピクセルの奥行き（深度）を推定することができます。また、QCon のロゴを使ったテスト画像も用意しました。これは WebGL への変換処理を行っており、技術的な進化が急速に進んでいることを実感できる素晴らしい例です。

フレーム単位での動画追跡など、非常に興味深い処理も可能になっています。ただし、この処理はプロセッサへの負荷が高いため、今回は少し速度を上げて表示しています。画面内の動きのあるすべての要素をマッピングし、インタラクティブな UI を構築することで、旗印を選択するとカメラがパンする際にその旗を追いかけるような動作を実現できます。

背景をぼかしたり、特定の部分を強調したりする用途に非常に役立ちます。実は、ローカルモデルの活用事例として、背景をぼかす処理が特に有効です。

在宅勤務をしている方にとって、背景で子供が行き交ったり、片付けられていない荷物があふれたりするのはよくある光景です。こうした状況でも、リアルタイムで背景を除去する処理を瞬時に行えるようになりました。WebRTC を介して送信する前に、ローカル端末でこの処理を実行しない手はありません。WebRTC はピアツーピア型のビデオ会議ソリューションであり、個人間の通話であれば、わざわざクラウドを経由する必要は全くないからです。

テキストベースのモデル例をいくつかご紹介します。これは Chrome 組み込みのプロンプト API のデモですが、実際にかなり優秀です。

以前はそうではありませんでしたが、今ではコード1行でプロンプトを設定できます。テキストを渡すだけで、ブラウザ内で完結して補完処理を行えます。ネットワークへの呼び出しは一切不要です。

このモデルは QCon のウェブサイトで学習されたことが明確にわかります。QCon に来るべき素晴らしい理由をすべて知っているからです。

さらに、制約付きサンプリングや構造化出力にも対応しています。JSON などの形式で結果を取得することも可能です。

非常に便利です。例えば、「QCon に参加するメリット」を短い JSON ブロックとしてリストアップすれば、すぐに完了します。

Sam Altman にお金を払う必要はありませんが、美しい UI にレンダリングできる JSON を手に入れることができます。もし可能なら、ユーザーに長いテキストの壁を見せるのは避けるようお勧めします。

LLM を活用する際は、必ず何らかの形で構造化し、見やすい UI 要素を組み合わせることをお勧めします。これにより、ユーザーが理解しやすくなるだけでなく、「壁のようなテキスト」による疲労感も軽減されます。

その一例が「Duck-UI」という製品です。こちらは無料で試すことができます。すべてブラウザ上で完結する仕組みで、ここでは数年前の QCon の登壇データをまとめた CSV ファイルを読み込んでいます。データについて質問すると、WebLLM が SQL を生成し、GPU 上で実行します。その後、クエリは Wasm で処理され、結果が返されます。このプロセスでは、データは一切ブラウザ外へ流出しません。

こうしたデータベースは、100〜500MB 程度のデータセットサイズに適しています。意外なほど多くのデータを収容できるのです。

Measuring What Good Looks Like

モデルを実装する際、重要なポイントの一つは「成功とは何か」をどう測るかです。どんな指標もホワイトボードに書き出せますが、多くの関係者が本当に気にするのは、それが自らの関心事項にある指標の改善につながっているかどうかです。例えば、「意思決定までの時間」や「意思決定の質」、あるいは「人間の判断との一致度」などが挙げられます。

プロジェクトを開始する際は、こうした基準を最初に明確に設定し、可能な限りデータベースに保存します。そうすることで、モデルの評価スイートを構築できるからです。では、LLM の出力品質はどのように測るべきでしょうか？

通常のソフトウェア（LLM を使わないもの）では、動作が決定論的であるため、自動化テストで囲むだけで済みます。しかし LLM の場合は話が複雑です。出力が長く、変動する可能性があり、評価が非常に難しくなるからです。

LLM から出力される推論結果を手動で一つずつレビューする代わりに、思考の質をより適切に評価・ランク付けできる別のモデルを活用できます。つまり、判断を行う「審査役」モデルは、判断される対象となるモデルよりも優れた性能を持つべきです。

実際には、最先端のモデル（フロンティアモデル）を用いて、ブラウザ内で動作する比較的弱いモデルの評価やテストを行うのが効果的です。

クラウド環境でもデスクトップ環境でも、AI プロジェクトを推進する際には、専門家が直感的に理解できるような視覚的な評価スイート（Eval Suite）を構築することを強くお勧めします。金融機関の顧客確認（KYC）や医療記録の管理など、どのような用途であっても、現場の担当者が操作・理解できる UI を設計する必要があります。AI が何を行っているかを可視化し、専門家がそのプロセスを確認できるようにすべきです。

これは単なるエンジニアリングの問題として扱うべきではありません。

製品の80%から90%は、このテストと評価の仕組みにかかっています。特にAIを多用する製品を開発する場合、その品質が本当に優れているかどうかを判断するのは、あなたよりも詳しい専門家たちです。彼らにどのようにテスト結果を伝え、どう改善につなげるかが重要になります。

例えば、パスポートの文字を読み取るツールを作るとしましょう。これは比較的リスクの低い用途かもしれません。空港でのチェックインや搭乗手続きなどに使われるケースです。こうした場合、テスト用のデータ（フィクスチャ）を保存しておく必要があります。具体的には、スキャンしたパスポート画像そのものです。理想としては、読み取りがうまくいかないような「 awkward な」パスポートのスキャン画像を使うのがベストでしょう。

次に、期待される結果を記述したJSON形式のデータを用意します。「これが正解だ」という基準です。そして、実際にモデルが出力した結果とこれを比較します。

このモデルを取り巻くユーザーインターフェースは、以下のような構成になります。左側にテスト用データ（フィクスチャ）を表示し、中央に期待される正解を示し、右側には実際の出力結果を並べます。このような形で視覚的に明確にする理由は、後からさまざまなパラメータや設定を調整して品質を向上させる作業を行う人々が、直感的にどこを改善すべきかを把握できるようにするためです。

では、どのような調整が可能でしょうか？最もシンプルなのは、基盤となるプロンプトを変更することです。LLM においては当然のようですが、プロンプトの変更が製品の品質向上に寄与しているのか悪化させているのかを把握できていない製品チームは、実際に多く存在します。

多くの場合、チームは「なんとなく良くなった」という感覚だけでリリースを決めてしまいます。これは極めて危険な行為です。なぜなら、その判断は完全にランダムだからです。誰かがプロンプトを変更した際、すべてのエッジケーステストを再実行し、「改善されたのか、悪化させたのか」を明確に把握できる仕組みが不可欠です。一見当然のように思えますが、この点を見過ごしている人が非常に多いです。

もちろん、使用している基盤モデル自体を切り替えることも可能です。例えば、より高性能な大規模モデルへ移行するといった調整です。また、そのモデルを動作させるためのハネス（ワークフロー）を変更することもできます。私は「エージェント的」という用語はあまり好きではありませんが、AI が複数のステップを経て結果を生成するような、一連の処理フローを指しています。

できる限り厳格なガードレールが必要だと考えています。Vercel Labs チームが手がけた「just-bash」という素晴らしいプロジェクトがあります。これは TypeScript だけで書かれた、ブラウザ内で完結する Bash 環境です。

新しいコマンドを TypeScript で記述すれば、好きなコードを実行できます。LLM は非常に短く簡潔な CLI 風の構文を使ってこれらのコマンドをつなぎ合わせることができます。これは MCP のように巨大な JSON ブロックを操作してつなぐよりもはるかに優れています。なぜなら、MCP ではトークンを大量に浪費してしまうからです。

こうした仮想化された Bash 環境を使えば、LLM は結果を得るために試行錯誤しながら反復処理を行うことができます。これは Claude Code が行うこととよく似ています。人々はベクトルデータベースにコードベース全体をインデックスしたり、華やかな手法をいろいろ試しがちですが、結局のところ LLM は「cat」や「grep」、「head」といった基本的なコマンドを使うのが実は最も得意なのです。

なぜ、その LLM が非常に得意としている単純で堅牢なツールを、完全に隔離された環境（サンドボックス）内で利用しないのでしょうか？LLM はこれが本物の Bash ではないことを知りませんし、オペレーティングシステムの特権も持っていません。例えばネットワークへのアクセスもできませんが、LLM にとっては問題ありません。

LLM を実際の CLI に直接接続して危険な作業を行わせるのではなく、疑似的な CLI（フェイク CLI）に接続する方が賢明です。この仕組みを確立すれば、評価用テスト（evals）を再実行しやすく、専門家が「本番環境への展開に適しているか」を明確に判断できるようになります。

私の意見では、直感や雰囲気だけで製品をリリースしようとするあらゆる道は、結局破滅へと繋がると考えています。

最後にいくつかの戦略についてお話しします。これまでモデルの選定や技術的な側面について多く語ってきましたが、実際には AI アプリを改善する上で最も重要なのは、地味で平凡な作業です。

エンドユーザーとの対話や専門家の意見聴取、プラットフォームの信頼性確保（失敗時の自動リトライなど）、データの適切な準備と記述、フィードバックによるエンドツーエンドのワークフロー最適化、そして評価スイートを通じた視覚的なテストと検証——これらすべてが重要です。つまり、小さな調整を繰り返し、レビューと評価を継続的に行うことが求められます。

今日皆さんに覚えておいてほしいのは、データが機密情報を含む場合はローカル処理を行うことです。自宅にある誰かの音声や動画データを扱う場合、アップロードしたくないコンテンツが含まれないよう、事前処理を施すことをお勧めします。個人識別情報（PII）を転送前に削除したいなら、そのようにしてください。

実際のワークロードと、本番環境で遭遇する可能性のあるエッジケースに基づいてベンチマークを取ることも忘れないでください。楽しい時間を過ごし、素晴らしいものを創り上げてください。Transformers.js は非常に優れた出発点です。Bash も非常に楽しく使えますので、ぜひ試してみてください。

トランスクリプト付きの他のプレゼンテーション をもっと見る

録画日：2026 年 8 月 31 日