オンデバイスAIとは？

クラウドAIでは、入力をインターネット経由でデータセンターへ送り、そこでモデルを実行します。大規模な計算資源を利用しやすい一方、通信環境とサーバーとのデータの往復が必要です。

エッジAIは、データが生まれる場所に近い計算資源を使う、より広い概念です。店舗内のサーバーや家庭のゲートウェイで処理する場合も含まれます。[1] オンデバイスAIは、その中でも利用者の端末そのものが推論を行います。

1. 原データの移動を減らせる

音声や生体信号を端末内で処理し、必要な結果だけを残せば、通信経路やサーバーに置かれるデータを少なくできます。AppleのCore MLも、CPU、GPU、Neural Engineを利用した端末内推論を支援しています。[2]

2. 反応を速く、通信なしでも使える

ネットワークとの往復が不要なため、音声入力やインタラクティブなフィードバックなど、短い応答時間が求められる処理に適しています。設計によっては、圏外でも利用できます。

3. 個人に合わせられる

各人の声や使い方へ端末内で適応できれば、個人データを中央へ集めずに個人化できます。端末上で音声認識モデルを個人化した研究は、その可能性と同時に、メモリ使用量、学習時間、性能のトレードオフも報告しています。[3]

端末には、メモリ、電池、保存容量、発熱の上限があります。クラウドで動くモデルを、そのまま腕時計やスマートフォンへ移せるとは限りません。そのため、モデルの小型化、量子化、処理の一部だけを端末で行う構成などが使われます。

計算を軽くすれば、誤差の出方が変わる可能性があります。機種ごとの性能差、OSが処理を中断する条件、モデル更新の方法も考えなければなりません。オンデバイスAIは、常にクラウドより高速、高精度、省電力という意味ではなく、何を端末に置くかを選ぶ設計です。

音声には、会話内容だけでなく、話者の特徴や周囲の状況も含まれます。心拍、PPG、呼吸などの生体信号は、長時間、継続的に生まれる個人的なデータです。必要なのが短い判定や傾向であれば、すべての原データを保存・送信する必要はありません。

例えば端末内で「取得、品質確認、特徴抽出、推論」までを行い、外部へ出す情報を利用者に必要な結果だけへ絞ることができます。ただし、処理する場所と推論内容の正しさは別問題です。端末内で「ストレス」や「感情」を推定しても、そのラベルが科学的に妥当とは限りません。

オンデバイス化はデータの扱いを改善できますが、曖昧な現象を確実な答えへ変える技術ではありません。

オンデバイスAIは、プライバシーを守るために使える設計手段です。しかし、それ自体が安全性の証明ではありません。確認すべきなのは原データだけではなく、入力、特徴量、推論結果、エラーログ、バックアップ、解析SDKが何を保存・送信するのか。誰がアクセスでき、利用者が削除できるのか。モデルの更新経路が保護されているかです。

GoogleのML Kitのように推論を端末上で行うSDKでも、診断や利用状況の把握を目的として端末情報や性能指標などを収集する場合があります。[4] 「推論がローカル」と「通信が一切ない」は同じではありません。NISTのPrivacy Frameworkも、保存場所だけでなく、処理目的、透明性、管理、削除を含む継続的なリスク管理を求めています。[5]

フェデレーテッドラーニングも万能ではない

フェデレーテッドラーニングは、原データを各端末に残し、端末で計算した更新情報を集約して共通モデルを学習する方法です。[6] これはオンデバイス推論とは別の技術です。また更新情報の共有方法によっては、元の学習データの一部を推定できることも実験的に示されています。[7]

すべてを端末に閉じ込めることが、常に最善とは限りません。即時性や機密性が重要な処理は手元で行い、大きな計算が必要な処理だけを、明示的な同意とデータ削減を伴ってクラウドへ委ねる。現実には、そうしたハイブリッド設計も重要になります。

LumoがオンデバイスAIを重視する理由も、声や身体反応が、その人自身に属する繊細なデータだからです。オンデバイスAIの本質は、巨大なモデルを小さな端末へ詰め込むことではありません。

必要な計算をデータの近くに置き、何を外へ出すのかを説明できるようにする。