ウェアラブルデータ分析で「LLMに任せるべきでない仕事」

スマートウォッチや睡眠トラッカーが集める健康データは、ここ数年でかなり細かくなってきました。心拍、睡眠段階、活動量、ストレスらしき反応。以前なら専門機器でしか取れなかったような情報が、日常の中で当たり前に記録されるようになっています。

では、そのデータをLLMに読ませれば、健康アドバイスまで自動で返せるのではないか。そう考えるのは自然です。ユーザーが「最近よく眠れてる？」と聞けば、LLMがデータを見て、わかりやすく答えてくれる。今っぽい発想ですね。

ただ、話はそこまで単純ではありません。ウェアラブルデータをLLMに処理させても上手くいかないケースは多々あります。

成功している実装は、LLMに何でもやらせていません。むしろ、LLMにやらせない仕事をきちんと切り分けています。

健康データをそのまま読めるLLMはまだない

まず押さえておきたいのは、現在のLLMはウェアラブルの時系列データをそのまま理解できるわけではない、という点です。

このことを大規模に検証したのが、2026年に公開された健康時系列データ向けの評価基盤です。扱われたデータはかなり幅広く、ウェアラブルや健康センシングでよく使われる信号がひと通り含まれていました。

評価方法も、LLMに不利なものではありません。長い時系列データをそのままプロンプトに詰め込むのではなく、LLMにPythonコードを書かせ、そのコードでファイルを読み込ませる形式が採られました。時系列を直接読ませるよりも、かなりLLMに配慮した設定です。

それでも、結果はかなり厳しいものでした。

活動認識

腕に装着した加速度センサのデータから日常活動を分類するタスクでは、最も性能の高かったLLMでもスコアは0.17にとどまりました。同じデータに対して、専門のディープラーニングモデルは0.90を達成しています。

もちろん、評価指標によって数字の見方は変わります。ただ、この差は「少し負けた」というレベルではありません。実際の製品にそのまま載せるには、まだ遠い性能です。

睡眠段階分類

脳波、眼電図、筋電図を含む睡眠ポリソムノグラフィデータから睡眠段階を分類するタスクでは、LLM側が0.54、専門モデル側が0.81でした。

活動認識ほど極端な差ではありません。それでも、睡眠や健康の領域で求められる安定性を考えると、まだ十分とは言いにくい水準です。特に、ユーザーがその結果をもとに生活習慣を変える可能性があるなら、なおさら慎重に見る必要があります。

感情分類

皮膚電気活動データから感情カテゴリを分類するタスクでは、LLM側が0.18、専門モデル側が0.72でした。

ストレス検知や瞑想アプリ、メンタルヘルス支援の文脈では、この領域への期待は大きくなっています。ただ、少なくとも現時点では、生のセンサデータからLLMが直接感情を判定するやり方は、まだ成立しているとは言えません。

結果の比較

ここで重要なのは、これらの結果が、LLMに極端に不利な条件で測られたものではないということです。コードを書かせてファイルを処理させる方式は、長い時系列をプロンプトに詰め込むよりもずっと現実的です。しかも、14種類の最新モデルを横断的に試しています。

それでも専門モデルとの差は大きい。つまり、現時点のLLMは、ウェアラブルの生データを直接読んで意味を取り出す道具としては、まだ力不足だと考えたほうがよさそうです。

うまく動いているシステムは何をしているのか

では、ウェアラブルとLLMの組み合わせ自体がダメなのかというと、そうではありません。

2026年には、自然な健康フィードバックを返す実装も複数登場しています。Nature Communicationsに掲載された健康インサイト向けエージェントの研究や、ヒューマンコンピュータインタラクション領域の主要会議で発表された睡眠ケアエージェントの研究は、かなり実用に近い応答品質を示しました。

ここで面白いのは、成功している実装ほど、LLMに生データを読ませていないことです。

LLMに任せているのは、ユーザーの質問を理解すること、必要な計算を組み立てること、返ってきた結果を人間にわかる言葉で説明することです。数値計算やデータ処理そのものは、Python実行環境やデータベースに任せています。

つまり、LLMを「データを読む頭脳」としてではなく、「質問を理解して説明する窓口」として使っているわけです。

Pythonと検索を組み合わせるやり方

健康インサイト系のエージェントでは、LLMが直接データを解析するのではなく、Pythonランタイムとウェブ検索を呼び出す構成が採られています。

参照：Transforming wearable data into personal health insights using large language model agents

たとえばユーザーが「先週の睡眠は普段と比べてどうだった？」と聞いたとします。このときLLMは、いきなり答えを作るのではありません。まず日次の睡眠データを集計するコードを生成し、その結果を受け取ります。必要に応じて参照情報も組み合わせたうえで、最後に自然な文章として回答します。

この方式では、4,000件を超える質問データセットと650時間にわたる人手評価が行われました。客観的な質問への正答率は84パーセント、自由回答では83パーセントが好意的に評価されています。

ポイントは、LLMが計算結果を頭の中で作っているわけではないことです。計算は外に出し、LLMはその結果を扱っています。

データベース問い合わせに変換するやり方

睡眠ケア領域では、少し違う方法が採られています。

マットレス下に設置したセンサと腕時計から得られるデータを正規化してデータベースに格納し、LLMにはユーザーの質問をデータベース問い合わせ言語に変換させます。検索結果の解釈や説明文の生成にはLLMを使いますが、数値の計算はデータベース側で処理します。

各カテゴリ30問、合計90問の合成質問に対して、単純な取得と多くの比較質問で、実行可能なクエリの生成率と意図一致率がともに100パーセントに達しました。

ここでも、LLMの役割は限定されています。データの真実を作るのではなく、ユーザーの問いをデータベースが扱える形に変換し、結果を説明する役割です。

2つの実装に共通する考え方

この2つの実装に共通しているのは、数値的な判断をLLMに任せていないことです。

LLMに「このデータから何が言える？」と丸投げすると、もっともらしい説明は返ってきます。ただし、その説明が本当に計算に基づいているかは怪しくなります。ハルシネーションを完全に排除できないからです。

一方で、Pythonコードやデータベースが返す結果は、入力と処理の流れを追うことができます。間違っていれば、どこで間違ったのかを確認できます。これは製品としては大きな違いです。

ウェアラブル×LLMで信頼性を出すには、LLMに「真実を作らせない」ことが重要です。LLMには、すでに計算された事実をもとに説明させる。この切り分けが、かなり本質的です。

通知のきっかけもLLM任せにしない

もうひとつ、うまく動いている実装には共通点があります。LLMが常にデータを眺めて、好きなタイミングで助言を出すわけではありません。

多くの場合、通知や対話のきっかけは閾値で制御されています。たとえば、ある指標が基準値から上下30パーセント以上外れたときだけ通知を出す、といった形です。

これはかなり現実的な設計です。毎日のように「昨日は少し睡眠が浅かったです」「今日は心拍がやや高めです」と言われ続けると、ユーザーはすぐに疲れます。健康アプリの通知は、親切なようでいて、簡単にノイズになります。

また、LLMに常時解釈させると、ちょっとした変動にも意味を見出してしまう可能性があります。睡眠や心拍は日々揺れるものです。毎回そこに物語をつけると、ユーザーを不必要に不安にさせることもあります。

だからこそ、まずルールで発火条件を絞る。そのうえで、必要なときだけLLMに短く説明させる。このくらいの距離感が、実用上はちょうどよいのかもしれません。

画面のないデバイスとは相性がいい

この設計は、画面が小さいデバイスや、画面を持たないデバイスとも相性がよさそうです。

スマートリング、骨伝導イヤホン、足首装着型センサのようなデバイスでは、スマートウォッチのようにグラフを大量に見せることはできません。だからといって、取得したデータに価値がないわけではありません。

むしろ、そうしたデバイスでは、短い言葉で説明してくれるインターフェースのほうが向いています。

たとえば、次のような一言です。

「昨夜は深い睡眠が少なめでした。昨日より就寝時刻が1時間遅かった影響がありそうです」

このくらいの説明で十分な場面は多いはずです。ユーザーがもっと知りたければ、続けて質問できる。画面にグラフを並べるより、会話で必要な情報だけ取り出すほうが自然なケースもあります。

数値計算は外部で済ませ、LLMは説明と対話に徹する。この形なら、出力はテキストにも音声にも流しやすくなります。メッセージングアプリや音声合成と組み合わせれば、視線を奪わない健康エージェントも作りやすいでしょう。

画面なし・小画面デバイスで活きる理由

ウェアラブルの形が多様化していくほど、画面中心のUIから離れる意味は大きくなります。

設計者が考えるべきこと

ここまでを踏まえると、ウェアラブル領域でLLMを使うときの判断軸はかなり見えてきます。

生センサ処理と言語処理を分ける

まず決めるべきなのは、LLMに何を見せるかです。

生の加速度、心拍、脳波をそのまま渡すのではなく、特徴抽出、統計集計、イベント検出を別の層で済ませてから渡すほうが安全です。LLMに渡すのは、すでに意味づけしやすい形に整理された値で十分です。

Python実行環境を使うのか、データベースで前処理しておくのかは、プロダクトの要件によります。ただ、どちらにしても、生データをLLMに丸投げする設計は避けたほうがよいでしょう。

LLMの仕事は説明と対話に寄せる

LLMが得意なのは、複雑な結果をわかりやすい言葉にすることです。ユーザーの曖昧な質問から意図を汲み取り、必要な情報にたどり着くことも得意です。

一方で、正確な数値計算や時系列データの直接分類は、まだ専門モデルや通常の計算処理に任せたほうが安定します。

LLMの役割を広げすぎると、便利そうに見えて、逆に信頼性が落ちます。役割を狭くすることが、結果的に体験全体の質を上げます。

通知はルールで制御する

通知のタイミングをLLMの判断に任せるのは危うい設計です。

何を異常とみなすのか。どのくらい変化したら知らせるのか。どの時間帯には通知しないのか。こうした条件は、あらかじめルールとして決めておくほうがよいでしょう。

基準値からの逸脱を検出したときだけLLMを呼び出す構成にすれば、通知の予測可能性が上がります。推論コストも抑えられます。何より、ユーザーにとっても「なぜ今この通知が来たのか」がわかりやすくなります。

完全なオンデバイス化はまだ遠い

現状の実装は、基本的にクラウド側のLLMに依存しています。ウォッチやリングだけで完結する形には、まだ届いていません。

当面は、スマートフォンを母艦にし、ウェアラブル側では前処理やデータ取得を担うハイブリッド構成が現実的です。モバイルNPU向けの量子化技術は進んでいますが、ウォッチ単体で長時間安定してLLMを動かすには、まだ制約が大きいと考えたほうがよさそうです。

設計判断のまとめ

残された課題

もちろん、この設計にすればすべて解決するわけではありません。大きな課題は、まだいくつか残っています。

モデル依存とコスト

検証に使われているLLMの多くは、クローズドなプロプライエタリモデルです。長期的に同じ品質を維持できるのか、コストが事業性を圧迫しないのか、モデルがサポート終了になったときにどう移行するのか。こうした問題は、かなり早い段階から考えておく必要があります。

臨床妥当性

もうひとつ大きいのは、臨床妥当性です。

LLMが返す助言が、医療的に見て本当に妥当なのか。ユーザーの行動をよい方向に導くのか。それとも、過剰な不安や誤った自己判断を生むのか。このあたりは、まだ十分に検証されているとは言えません。

多くの研究は、合成データや短期の人手評価で品質を測っています。長期的な利用者追跡や、医療従事者によるレビューを含む検証は、これからの課題です。特にメンタルヘルスや睡眠の領域では、過介入や誤誘導のリスクを軽く見るべきではありません。

今後確認すべきこと

・長期利用で本当に生活習慣が改善するのか
・医療従事者が見ても妥当な助言になっているのか
・通知が不安や依存を生まないか
・モデル変更時に品質を維持できるか
・推論コストを事業として吸収できるか

それでも、現時点で実装可能な範囲は見えてきています。

LLMを、ウェアラブル時系列データを何でも理解する万能装置として扱わないこと。根拠のある数値は外部で作り、LLMはそれを説明し、対話につなげる役割に置くこと。この前提に立てば、ウェアラブル×LLMはすでに製品化を考えられる段階に入っています。

まとめ

ウェアラブル領域でLLMを使うなら、いま最も堅実なのは、LLMに生データを丸ごと読ませない設計です。計算や分類は外部の処理系に任せ、LLMは説明と対話に集中させる。この切り分けが、かなり重要です。

現時点のLLMは、ウェアラブル時系列データを直接理解する道具としてはまだ不十分です。一方で、役割を絞れば、健康フィードバック、睡眠コーチング、ストレス介入のような体験は十分に作れます。

設計上のポイントは、次の4つです。

・センサ処理層と言語処理層を分ける
・LLMの役割を広げすぎない
・通知のタイミングをルールで決める
・当面はクラウドやスマートフォンを前提にしたハイブリッド構成で考える

これは、スマートウォッチだけでなく、スマートリングやイヤホン、低価格バンドのようなデバイスにも応用できます。画面が小さくなるほど、あるいは画面がなくなるほど、短い言葉で必要な情報を返すLLMの価値は大きくなります。

ただし、その価値は「LLMに全部任せる」ことで生まれるわけではありません。むしろ、任せない部分を決めることで生まれます。ウェアラブル×LLMの設計でまず考えるべきなのは、LLMに何をさせるかではなく、何をさせないかです。

本記事の関連研究