RuView解説｜WiFiセンシングで在室・呼吸を検知しHome Assistantへ流すOSSを検証

市販のWiFiルーターが部屋に満たしている電波は、人が動いたり呼吸したりするだけで乱れる。その乱れを読んで「誰がいるか」「動いているか」を推定するのがWiFiセンシングという領域だ。カメラもウェアラブルも使わない。2026年7月、GitHub Trendingで日次・週間ともに上位に入った ruvnet/RuView は、この WiFiセンシング を Home Assistant や Apple Home に直結させるところまで作り込んだOSS（MIT・GitHubスター約8.6万）である。

ただしこのリポジトリの説明文は強い。「壁越しに見る」「呼吸と心拍を測る」「17キーポイントの骨格を推定」——普通ならここで身構える。しかしRuViewが珍しいのは、リポジトリ自身が「どの主張が検証済みで、どれが未計測か」を分けて公開している点だ。本記事は公式の監査ログ・ベンチマーク研究・モデルカードを突き合わせ、どこまでが実測で、どこからが「そう主張されている」に留まるのかを読み分ける。

この記事はセルフホスト型のセンシング／自動化ツールとしてRuViewを解説します。自動化・運用ツール全般のカバレッジは AI自動化ツール｜ノーコードからコードまで2026年版の比較と選び方 をご覧ください。

WiFiセンシングとは：CSIが「呼吸」に変わるまでの信号処理

WiFiセンシングを理解する鍵は、RSSIとCSIの違いにある。

RSSI（受信信号強度）は「電波がどれくらい強いか」を表すたった1つの数字だ。人が部屋に入れば少し弱くなる、という程度の情報しかない。対してCSI（Channel State Information）は、WiFiが使うサブキャリアごとの振幅と位相を並べたベクトルである。ESP32-S3の場合は56サブキャリア分が取れる。1つの数字ではなく数十次元の「電波の指紋」が毎フレーム手に入る、というのがCSIの本質だ。

人体はこの指紋を変える。電波は壁や家具、そして人体で反射して受信機に届く。人が動けば反射経路の長さが変わり、経路長の変化はサブキャリアの位相にそのまま現れる。胸郭が呼吸で数ミリ動くだけでも位相はわずかに揺れる。つまり、位相の時間変化を周波数で切り分ければ、動きの種類を分離できる可能性がある——これがWiFiセンシングの原理だ。

RuViewはこの原理を素直に実装している。公式READMEに書かれている方式はこうだ。

呼吸が0.1〜0.5Hz、心拍が0.8〜2.0Hzという帯域の分け方は、この分野の標準的なアプローチだ。安静時の呼吸は毎分6〜30回＝0.1〜0.5Hz、心拍は毎分48〜120拍＝0.8〜2.0Hzに収まるので、帯域が重ならない限りバンドパスフィルタで分離できる。裏を返せば帯域が重なる状況では分離できない——激しく動いているときに呼吸と心拍が混ざるのは原理的な話であり、公式のモデルカードも「体動中は呼吸・心拍の精度が落ちる」と制約に明記している。

その手前に、地味だが重要な前処理が並んでいる。市販のWiFiチップから取れるCSIは、そのままでは使えないほど汚いからだ。

・Hampelフィルタ：スパイク状の外れ値を中央値ベースで除去する（hampel.rs・240行）
・SpotFi位相補正：市販NICのCSIには時刻同期の誤差由来の位相オフセットが乗る。共役積（CSI ratio）を取ってこれをキャンセルする（csi_ratio.rs・198行）
・Fresnelゾーン呼吸モデル：送受信間のどこに胸があるかで感度が変わる幾何を扱う（fresnel.rs・448行）
・BVP（Body Velocity Profile）抽出：速度成分のプロファイルを取り出す（bvp.rs・381行）
・STFTスペクトログラム：4種の窓関数つき短時間フーリエ変換（spectrogram.rs・367行）

この5つはいずれも、後述する公式の監査ログでテスト付きの「YES」判定になっている。信号処理の土台部分については、コードが存在してユニットテストが通ることが確認できていると読んでよい。

図のうち推論がどこで走るかは重要な論点なので、§3で改めて扱う。ESP32は「センサー」であって「推論器」ではない、というのが公式監査ログの判定だ。

RuViewの実体：★8.6万・MIT・Rust中心／何を買うと何ができるか

数字の実体をGitHub APIで確認しておく。2026年7月26日時点の実測値は次のとおりだ。

読み方に注意が必要な数字が2つある。

ひとつはリリース数だ。最新タグは v2012（2026-07-24）で、13か月あまりで2000番台まで採番が進んでいる。これは成熟度の指標ではなく、コミット単位で自動リリースを打つ運用の結果と読むのが妥当だ。同じ日に v2007 v2010 v2012 が並んでいることからも分かる。

もうひとつはコントリビューター31人という数字である。内訳を見ると作者が939コミット、2番目が76、3番目が36で、以降は数コミット台に落ちる。実体としては単独開発に近い形であり、31という人数から「大規模な開発体制」を読み取るべきではない。C言語557KBはESP32ファームウェア側、Rust 9.16MBがサーバー側の中核という構成である。

そして最も実務的に重要なのが、できることがハードウェアの段で決まるという点だ。

READMEのハードウェア表を素直に読むと、階層はこうなる。

・$0（手持ちのPCだけ）：Windows / macOS / Linux のノートPCはRSSIのみ。粗い在室と動きの検知まで。公式も「CSI非対応」と明記している
・約$9（ESP32-S3を1枚）：ここからCSIが取れる。在室・動き・呼吸・心拍・転倒検知・複数人カウントが対象範囲に入る
・約$54（ESP32-S3を3〜6枚でメッシュ）：多部屋・多周波スキャン。6チャンネルを渡り歩いてセンシング帯域を3倍にする設計（ADR-029）
・約$140（＋Cognitum Seed）：永続ベクトルストア・kNN検索・witness chain・MCPプロキシ・105種のエッジモジュール（cog）カタログ。Seedは別売の商用アプライアンスで、モデルカードには$131と記載されている
・約$6〜10（ESP32-C6）：WiFi 6と802.15.4の研究向けノード。同じCSIパイプラインをデュアルターゲットのファームで動かす

ここが読者にとって最大の落とし穴になりやすい。「$9で全機能」ではない。105種のcogカタログ、witness chain、永続メモリといった魅力的な機能群は、MITのリポジトリだけで手に入るものではなく、商用アプライアンス側に紐づいている。エッジ向けの軽量モデルをどう配るかという設計思想そのものは、Qualcomm AI Hub Models入門｜エッジAIをスマホで動かす175+最適化モデル集の使い方 で扱ったモデル配布のアプローチと比べると理解しやすい。

なおハードウェアを買わずに評価する道は用意されている。Dockerイメージがシミュレーションデータで動くので、UIと信号処理パイプラインの雰囲気だけなら手元で確認できる。

# ハードウェア不要。シミュレーションデータで評価する
docker pull ruvnet/wifi-densepose:latest
docker run -p 3000:3000 ruvnet/wifi-densepose:latest
# → http://localhost:3000

# ハードウェアが無くても信号処理の決定的な再現検証はできる
python archive/v1/data/proof/verify.py

後者は「Trust Kill Switch」と呼ばれる仕組みで、決定的な参照信号をパイプラインに通し、出力のSHA-256を公開ハッシュと突き合わせる。実データではなく合成信号（乱数シード42）だが、第三者が同じ結果を再現できるという点でこの種のプロジェクトには珍しい設計だ。

「壁越しに呼吸・心拍が測れる」を公式ログで裏取りする

ここが本記事の核心だ。RuViewには docs/WITNESS-LOG-028.md という監査ログがあり、能力ごとに「Claimed（主張）」と「Verified（検証結果）」を並べた35行の表が載っている。「NO」や「NOT MEASURED」の行も消さずに残っているのがこのログの価値だ。

監査ログを読む前に確認すべき「日付」

このログを引用するときに最初に踏むべき注意点は鮮度である。ログのヘッダには監査日 2026-03-01、コミット 96b01008、ワークスペースバージョン 0.2.0、そしてテスト結果「1,031 passed」と書かれている。一方、現在のREADMEのバッジは「Tests: 1463」だ。

つまりこの監査ログは約5か月前のスナップショットであり、今日のリポジトリ状態の証明ではない。以降で引用する行はすべて「2026-03-01時点の監査結果」として読む必要がある。監査という仕組みを用意していること自体は評価に値するが、それを最新状態の保証として扱うと、記事のほうが不正確になる。

呼吸・心拍：実装は確認できる、精度は公表されていない

監査ログの21行目が「Vital sign detection（breathing + heartbeat）」で、判定はYESである。しかし根拠の欄をそのまま読むと、書かれているのは次の内容だ。

vitals クレート（1,863行）、6〜30 BPM / 40〜120 BPM

これが検証しているのは、該当機能のコードが存在し、ユニットテストが通ることである。人間に対して測ったときの誤差ではない。動作レンジ（6〜30 BPM）も精度ではなく、検出器が扱う範囲の宣言だ。

では精度の数値はどこかにあるのか。ベンチマーク文書（docs/benchmarks/ 配下）とHugging Faceのモデルカードを探した結果、胸ベルトやパルスオキシメータのような基準機器と比較した誤差（BPMのMAE、相関係数など）を示す数値は見つからなかった。そしてこの「無い」ことは、モデルカード自身が明言している。

モデルカードには「v2が主張していないこと」という見出しの節があり、要旨はこうだ。これは1部屋・1回の収録・2ノードのデータである。三つ組（triplet）の指標は埋め込みの品質を測るものであり、在室や生体値の下流精度ではない。そのために必要な多クラス・多部屋のラベル付きデータは、この2.4GHzの特徴量については持っていない——と。

さらに制約欄には「健康機能はスクリーニング用であり医療診断ではない」「体動中は呼吸・心拍の精度が落ちる」「部屋固有（新しい部屋にはLoRAアダプタを使う）」と並んでいる。

したがって誇大主張の裏取り結果は、次の一文に集約される。

「NO」と書かれている2行と、「未計測」の1行

同じ監査ログには、主張していないことも明示されている。

#31は前掲のMermaid図で「推論がどこで走るか」を注記した理由そのものだ。エッジデバイスが自律的に推論しているのではなく、ESP32はCSIを送るセンサーで、判定はサーバー側という構成である。READMEには「サーバーは可視化と集約のためのオプションで、ESP32は在室検知・バイタル・転倒アラートについて独立して動く」という記述もあり、この2つは緊張関係にある。監査ログの#31を信じるなら、少なくとも監査時点のファームウェアは推論器ではなかった、と読むべきだ。

「100%の在室検知」が撤回された経緯は、そのまま教材になる

RuViewはかつて「100% presence accuracy（在室検知100%）」を掲げていた。これは現在撤回されている。撤回の理由がモデルカードに詳しく書かれていて、これ自体がベンチマークの読み方の教材になっている。

・当時の指標は、一晩の録画1本で測っていた
・その録画は6,063フレームのうち6,062が「在室」ラベル、「不在」はわずか1フレームだった
・つまり常に「はい」と答えるだけの予測器でも99.98%を取れる
・さらに当時の学習は損失が毎エポック同じ値（0.13517）で張り付いており、最適化が実際には進んでいなかった

現在公表されている82.3%は、これを是正した別の指標である。時間的に離れていない2つのCSIスナップショットを、離れた2つより近くに置けるか——という「held-out temporal-triplet accuracy」で、生の特徴量（66.4%）や未学習の初期化（69.6%）に対して82.3%という数字だ。学習が進んだことは示せるが、在室や生体値の精度ではない、というのが前節で引用した注記につながる。

自分の数字を下方修正して公開する姿勢は率直だ。だが読者として引き出すべき教訓は「だから信頼できる」ではなく、「クラス不均衡なデータで測った精度は、そのままでは何も言っていない」という汎用の読み方である。

「WiFiで骨格」の82.69%は、どのモデルの数字か

RuViewの主張でもっとも誤読されやすいのが姿勢推定だ。READMEには 82.69% torso-PCK@20 という数字があり、既存の公開手法（MultiFormer 72.25%、CSI2Pose 68.41%）を上回るとされている。一方で、端末に載る版の数字は PCK@20 = 3.0% である。同じリポジトリの中に、20倍以上違う数字が並んでいる。

これは矛盾ではない。「WiFiで骨格」が3つの別物を指しているからだ。READMEには「Model weights: what’s real, what’s not（どの重みが本物で、どれがそうでないか）」という節があり、3層に分けて整理されている。

①公開ベンチマーク用のモデルは ruvnet/wifi-densepose-mmfi-pose で、MM-Fiデータセットの random_split プロトコルで82.69%（3モデルのアンサンブル＋TTAで83.59%）。これは5GHz帯・多アンテナNICのCSIを前提とした別モデルである。

②端末に載る版は pose_v1.safetensors で、217サンプルのホールドアウトに対して PCK@20 = 3.0%、PCK@50 = 18.5%。ADR-079が定めた目標「PCK@20 ≥ 35%」に未達であることが明記されている。粗い構造は学べていて右腰は PCK@50 で77%だが、末端や顔の関節はほぼランダムだという。加えて、ランタイムの経路が中央固定の骨格を返す confidence=0 のスタブであり、重みがまだ配線されていない。

③旧アーキテクチャは archive/v1 の DensePoseHead で、kaiming_normal_ の初期化だけ。.pth も .onnx も .safetensors も1つも存在せず、deprecated扱いである。

そして注目すべきは、READMEが読者に対して自分の宣伝を制限していることだ。要旨としてこう書かれている——「first-cut・目標未達・ランタイムはスタブ」という注記なしに、ESP32単体での17キーポイント機能を宣伝してはならない。そのベースラインが計測されるまでは。

技術的な理由も添えられている（issue #509）。単一アンテナ・56サブキャリア・20フレーム窓のCSIには、多アンテナNICの研究が前提としている細かな空間情報が乗らない。だから末端の関節がほぼランダムになる。プロジェクトが立てる数字は公開ベンチマークのものであって、ESP32単体のライブ推定ではない、と自ら線を引いている。

部屋を変えると、ほぼ当てずっぽうになる

姿勢推定を扱うなら、もうひとつ避けて通れない実測がある。同リポジトリのベンチマーク研究 docs/benchmarks/mmfi-wifi-sensing-study.md は、リーク（漏洩）のないプロトコルで測るとWiFiセンシングが崩壊することを、数字で示している。

姿勢推定は同一環境で83.6%、別の人へのゼロショットで64%、別の部屋へのゼロショットでは約10%。27クラスの行動認識では、同一環境88.1%に対して別の人へのゼロショットが10.0%（研究自身が「near-chance＝ほぼ偶然」と書いている）。同研究は、同一環境の高い数字は時間的・被験者的な隣接性によるリーク由来の水増しだと自ら断じている。

さらに率直なのが、効かなかった手法を全部並べている点だ。CORAL（特徴共分散の整合）は被験者間の改善ゼロ、DANN（被験者敵対的学習）もほぼゼロ、アンテナごとの正規化＋SpecAugmentは−4.6ポイント、姿勢の対照学習による事前学習は−2.3ポイント、蒸留も改善なし。学習被験者を増やすアプローチも4→8人で+21ポイントだが24→32人では+0.45ポイントで飽和し、漸近線は約64%だという。研究の結論は「これはチューニングで埋まるギャップではなく、根本的な分布シフトだ」である。

では何が効くのか。設置した部屋での少数サンプル校正だ。別の部屋に対して、校正サンプルが0なら約10%だが、5サンプルで60%、50で70%、200で73%まで回復する。しかもランク8のLoRAアダプタ（約11KB）で被験者間64→72.5%が得られ、フル微調整（2.3MB）の76.2%に迫る。研究の一行まとめは「ゼロショットの不変性ではなく、少数サンプルの現地校正がWiFiセンシングの実装手段である」だ。

実務的な含意は明確だ。RuViewを家に入れるなら「設置して終わり」ではなく「その部屋で校正する」が前提工程になる。そして校正データが約20サンプルを下回ると、かえって悪化しうるとも書かれている。

Home Assistant／Apple Homeへ流す：MQTT 1フラグで生える21エンティティ

ここまでの精度の議論を踏まえた上で、RuViewが実装として面白いのはスマートホーム連携の部分だ。センシングの結果をそのままHome Assistantのエンティティとして生やすところまで作られている。

公式READMEによれば、--mqtt フラグを1つ足すだけでHA-DISCO（Home AssistantのMQTTディスカバリ）でエンティティが自動登録される。ノード1台あたり21エンティティで、内訳は生シグナル11個と、意味づけされた状態10個だ。

意味づけされた10個の中身が具体的で、実際に自動化を書く側の想像を助ける。誰かが寝ている／異変の可能性／部屋がアクティブ／高齢者の無活動アノマリー／会議中／浴室使用中／転倒リスク上昇／ベッドからの離床／動きなし／複数部屋間の移動——というラインナップである。加えてHA向けのBlueprintが3本同梱されている。

Apple Home側はHAP-1.1（HomeKit Accessory Protocol）のブリッジとして見える設計で、HomePodから発見できる。Google HomeとAlexaは、同じHAブリッジ経由か、Matterエンドポイント（ADR-122）として公開する経路が用意されている。READMEは「Siri・Googleアシスタント・Alexaが、カスタムスキルなしで部屋ごとの在室とバイタルを読み上げられる」としている。

導入の手順は、ハードウェア側とサーバー側に分かれる。ESP32-S3を使う場合はまずファームウェアを焼く。

# ESP32-S3にCSIノードのファームウェアを書き込む
python -m esptool --chip esp32s3 --port COM9 --baud 460800 \
  write_flash 0x0 bootloader.bin 0x8000 partition-table.bin \
  0xf000 ota_data_initial.bin 0x20000 esp32-csi-node.bin

# WiFiの接続先と、CSIを送る先のIPを設定する
python firmware/esp32-csi-node/provision.py --port COM9 \
  --ssid "YourWiFi" --password "secret" --target-ip 192.168.1.20

サーバー側はPythonのホイールがPyPIに公開されている。ruview と wifi-densepose は同じコンパイル済みPyO3ホイール（約250KB・abi3-py310・Linux/macOS/Windows対応）で、名前が違うだけだ。

# 本体（どちらの名前でも同じホイールが入る）
pip install ruview

# WebSocket / MQTT クライアントも使う場合
pip install "ruview[client]"

身体に何も付けない非接触センサーとして見たとき、従来の人感センサーとの立ち位置の違いは次のように整理できる。ここは数値の比較ではなく、方式ごとの性質の整理だ。

WiFiセンシングが狙っているのは、PIRの「静止すると消える」という弱点を、カメラを置かずに埋めるという位置だ。ソファで静止していても部屋の照明が消えない、という体験は確かに魅力的である。ただし§3〜§4で見たとおり、その体験を実際に得られるかは校正と精度の前提に依存する。「映像を撮らないからプライバシーに配慮している」という論法そのものは、Plausible Analyticsとは：GA4代替のプライバシー重視OSS解析をセルフホストで自前運用 で扱ったセルフホスト型のデータ主権の議論と同じ構図で読める。

一方で、しきい値を超えたら通知を飛ばすという運用面の設計は、changedetection.io徹底解説：31kスター獲得のWeb変更監視OSS、AI要約・100+通知統合 のような監視系OSSの通知設計とほぼ同じ課題（誤検知とアラート疲れ）に突き当たる。転倒検知が200ms未満で発火する一方、デバウンス3フレーム・クールダウン5秒という設定が入っているのは、まさにこの誤検知対策である。

WiFiセンシング導入前に知っておく穴：モデルが読めない・部屋ごとの校正・Seed依存

READMEには「今日これを試したらどうなるか」に直結する既知の不具合が書かれている。ここを読まずに始めると確実にはまる。

公開モデルが、公式サーバーで読み込めない

Hugging Faceで配布されているモデルは JSONL 形式のRVFコンテナ（model.rvf.jsonl）だが、センシングサーバー側のローダー（v2/crates/wifi-densepose-sensing-server/src/rvf_container.rs）はバイナリ形式のRVFセグメントしかパースしない。そのため --model にJSONLを渡すと、次のエラーになるとREADMEに明記されている。

invalid magic at offset 0: expected 0x52564653, got 0x7974227B

さらに悪いことに、ヒューリスティックモードにフォールバックせず、ライブのパイプラインがnull出力に劣化するという。READMEの回避策は率直で、「JSONLアダプタが入るか、モデルがバイナリRVFで再公開されるまでは、ライブのセンシングサーバーは --model なしで動かせ」「重みのほうはPythonの学習・評価から使え」となっている。

つまり在室判定は当面、学習済みヘッドではなく位相分散のフォールバックで動くことになる。REDAMEの機能表に「モデル不要の位相分散フォールバック」が併記されているのは、この事情と対応している。表向きの「学習済みモデルで在室検知」と、今日動く経路は別だと理解しておくべきだ。

部屋ごとの校正が運用コストになる

§4で見たとおり、別の部屋へのゼロショットは約10%まで落ちる。回復手段は現地校正で、公式研究は校正データの予算を約100〜200のラベル付きサンプルと見積もっている（50付近で70%に届く「膝」があり、約20を下回ると悪化しうる)。部屋ごとにこれを用意する作業が、実運用での主なコストになる。

配布形態としてはランク8のLoRAアダプタ（約11KB）が示されており、部屋ごとに2.3MBのモデルを複製する必要はない。設計としては筋が通っているが、「置けば動く」ではなく「置いて校正する」製品であるという理解が必要だ。

MITの範囲と、商用アプライアンスの範囲

プライバシーは「カメラがない」で終わらない

最後に、この種のツールで最も軽視されやすい点に触れておく。RuViewは映像を撮らない。だが扱うデータは在室・睡眠・呼吸・浴室使用中・離床であり、映像より抽象度が低いだけで、生活と身体に関する情報としてはきわめて機微だ。しかも対象は自分だけでなく、同居者や来訪者にも及ぶ。

設計上有利な点はある。RuViewはクラウドを必要とせず、エッジで完結する構成を掲げていて、判定結果の行き先も自分のHome Assistantだ。データの置き場所を自分で決められることは、この領域では実質的な安全策になる。ただし「誰の何を測っているのか」を同居者に説明できる状態で始めることは、技術的な設定より先に片づけるべき前提である。健康関連の機能について公式が「スクリーニング用であり医療診断ではない」と明記している点も、そのまま受け取るべきだ。

まとめ：RuViewは何ができて、何を代替できるのか

RuViewを評価するうえで、最終的に価値があるのは個々の数字ではなく主張の書き方だと思う。「100%」を撤回して測り直した経緯を残し、端末に載るモデルが目標未達であることを書き、効かなかった手法を全部並べ、部屋を変えると約10%まで落ちることを自分のリポジトリに置いている。この率直さは、WiFiセンシングという「派手な主張がしやすい」領域では例外的だ。

同時に、その率直さを「だから全部信じられる」に変換してはいけない。監査ログは2026-03-01のスナップショットで、テスト数だけ見ても現在と乖離している。公開モデルは公式サーバーで読み込めない。魅力的な機能の一部は別売アプライアンス側にある。★8.6万という数字は、実体としては単独開発に近いプロジェクトについている。

WiFiセンシングは、まだ「置けば動く」段階には来ていない。だが「$9のセンサーとMITのコードで、自宅の電波から在室を読み、Home Assistantに流す」ところまでは、確かに手が届く距離にある。試すなら、まずDockerのシミュレーションで信号処理を眺め、次にESP32を1枚買い、設置した部屋で校正する——という順番が、公式ドキュメントの記述に照らしてもっとも現実的だ。

参照ソース

・ruvnet/RuView（公式リポジトリ・README） — 機能表・ハードウェア階層・Home Assistant統合・既知の不具合・「Model weights: what’s real, what’s not」節の一次情報
・docs/WITNESS-LOG-028.md（能力の監査ログ） — 35行のClaimed/Verifiedマトリクス、監査日2026-03-01・コミット96b01008・当時1,031テストという鮮度情報
・docs/benchmarks/mmfi-wifi-sensing-study.md（MM-Fi汎化ベンチマーク研究） — 同一環境83.6% / 別の人64% / 別の部屋約10%、効かなかった手法の一覧、校正サンプル数ごとの回復曲線
・ruvnet/wifi-densepose-pretrained（Hugging Face モデルカード） — 82.3%の定義、「v2が主張していないこと」、100%在室検知の撤回理由（6,063フレーム中6,062が在室ラベル）、制約事項
・issue #509（ESP32単一アンテナの限界について） — 56サブキャリア・単一アンテナでは多アンテナNIC研究の空間情報が得られないという技術的説明