Wiki
Longev AIの学習の仕組み：ルール、データ、予測の検証 Longev AIの核となるのは、ゲスト自身のベースラインに基づいた説明可能な臨床ルールです。その上でプラットフォームは「介入→反応」のデータを蓄積し、予測の誤差をオープンに測定しています。
Updated 2026-08-28 · Sample procedures Luxury Spa & Medical Wellness Hotel Prezident
Contents 要点 ブラックボックスではなくルールに基づく理由 一般平均ではなく個人ベースラインの活用 エンジンの構造レイヤー PMSには存在しない2つのデータセット 予測の検証：空約束ではなく客観的な誤差で評価する ロードマップ よくある質問 参考文献 関連トピック 要点 このページの対象者。 技術監査、医師、投資家など、「これは機械学習なのか、それとも厳格なルールベースなのか」と疑問を持つすべての方に向けて書かれています。ポータル上で実際に検証できる率直な回答です。ルールベースを核とする意図的な設計。 すべての提案は明確なしきい値から導かれ、一文で説明できます。有料の施術を変更できるのは医師のみです。医療の現場において、中身の見えないブラックボックスを承認することはありません。個人に合わせたベースライン。 各種判定は「一般的な平均値」ではなく、滞在中のゲスト自身の平均値と比較されます。安静時心拍数が 62 であっても、それまで一週間 54 だったことが分からなければ意味を持ちません。2つのデータセット。 «ゲストの数値 → 医師の判断»を記録する判定ログと、«前日の施術と運動負荷 → 翌朝ウォッチが記録したデータ»を蓄積する結果ログです。どちらも構造上匿名化されており、JSONL形式で出力できます。検証可能な予測。 プラットフォームは翌日の安静時心拍数、HRV、Body Battery、睡眠スコアを3つのモデルで予測し、それぞれの平均誤差を誇大広告ではなく表形式で明示します。適用の範囲。 Wellness & Lifestyle Intelligence はライフスタイルをサポートするものであり、医療機器ではありません。最終的な判断は常に医師が行います。2026年8月25日更新。ブラックボックスではなくルールに基づく理由 Longev AI は決定論的なエンジンとして設計されています。同じ測定データと同じしきい値からは、常に同一の判定シートが生成されます。これはプラットフォームの隠れた制約ではなく、3つの明確な理由に基づく設計上の判断です。
1つ目の理由は、医師の承認が必要なことです。毎朝のシートは医師が確認してサインするため、すべての行が「なぜそう判断されたのか」に答えられる必要があります（例：«安静時心拍数が平均の 61 に対して 68 — 負担の大きい施術の変更を提案»）。具体的な数値で説明できない提案は出力されません。
2つ目の理由は、規制上の枠組みです。不透明なモデルに基づいて医療処方を勝手に変更するシステムは、医療機器や欧州AI法（EU AI Act）における高リスク区分に該当する可能性があります。そのため当プラットフォームはライフスタイル支援にとどめ、提案と説明を行って医師の判断を待つという立場をとっています（法的枠組み ）。
3つ目の理由は、コールドスタート問題です。データが不足している機械学習モデルはルールベースよりも精度が劣ります。導入したばかりのホテルでは学習データが存在しないためです。ルールベースであれば最初のゲストから確実に機能し、将来のモデルのためのデータ蓄積も初日の朝から始まります（詳細は後述）。
一般平均ではなく個人ベースラインの活用 エンジンのしきい値は、ほぼすべてゲスト自身のデータとの比較に基づいています。ベースラインとなるのは滞在中の平均値です。到着日など測定が不完全な日は除外され、測定日数が 2 日未満の間は個人ベースラインによる判定フラグは立ちません。1泊だけのデータとの比較はコイントスのようなものであり、信頼性のある結論とは言えないからです。医師はこの安全基準を最大 5 日間まで引き上げることができます。
心拍変動（HRV：心拍の間隔のばらつき）には、もう1つの基準があります。Garmin 内の Firstbeat アルゴリズムが約3週間かけて学習する個人の適正範囲です。ホテルの2日間のベースラインよりも長くゲストのデータを蓄積しているウォッチが«適正範囲以下»と判定した場合、コンディションの評価がグリーンになることはありません。ウォッチ側の判定が優先され、評価を厳しめに見積もる方向にのみ働きます。
これらの数値を統合して、その日のコンディション（0〜100 のスコア）が算出されます。Oura リングの Readiness や WHOOP の Recovery に相当するものですが、Garmin のデータを用い、ホテルの医師が調整したルールに従って計算されます。Body Battery が 30 点、HRV と睡眠が各 25 点、安静時心拍数と前日の運動負荷が各 10 点の配分です。データが欠落している項目を一般的な平均値で埋めることはせず、その項目を除外して全体の配分を再計算します。データの重みが全体の半分未満の場合は、無理に判定を下すことはありません。
医師のモーニングシート：コンディションスコア 49 / 100 とその内訳 — 各項目に実測値、ベースライン、判定理由が表示されます × エンジンの構造レイヤー PMSには存在しない2つのデータセット ホテルのPMS（施設管理システム）でもGarmin Health APIを連携して脈拍や睡眠データを取得することは可能です。しかし、学習データセットの核となる2つの要素、すなわち「医師の処方」と「食事の記録」がPMSにはありません。そのため本プラットフォームでは2つのデータセットを独自に蓄積しています。これらは生体データ、処方、栄養管理が同一システム内で統合されて初めて成り立ちます。
判断ログ — «ゲストの測定値 → 医師が下した判断»。ダッシュボードでのすべての医療措置は、その時点のゲストの匿名スナップショット（年齢、性別、滞在日数、夜間の数値、個人の平均値、フラグ）とともに保存されます。これはすでにサポート機能として稼働しており、似た数値が出た際にホテルが過去にどう対応したかを医師が確認できます。結果ログ — «介入 → 反応»。測定が行われた毎朝、プラットフォームは前日の施術と負荷（20:00以降の夕食や飲泉療法の杯数を含む）と、ウォッチが翌朝記録したデータ（個人のベースラインに対する安静時心拍数とHRV、睡眠、Body Battery、コンディション、フラグ）を対にして自動記録します。匿名性とデータ削除。 レコードには氏名も生年月日も含まれません。ヘルスデータ利用の同意が撤回されると、該当ゲストのデータペアも同時に消去されます。これによりデータセットの信頼性は損なわれるどころか、より誠実なものになります。エクスポートは管理画面からJSONL形式の行データで行えます。因果関係ではなく観察結果。 蓄積されたデータペアをもとに、ダッシュボードは「要因の有無」による平均値を表示します（前日の温熱療法、強度の高い施術、基準値を50%超える負荷、遅い夕食など）。比較が表示されるのは双方に5ペア以上ある場合のみで、あくまで「観察結果」として明記されます。朝の体調には無数の要因が絡むため、平均値の差を安易に直接の原因と見なすことはできません。予測の検証：空約束ではなく客観的な誤差で評価する 「プラットフォームの精度が向上している」という主張に対し、監査では具体的な数値を求められます。そのために管理画面には予測検証機能が備わっています。過去の全蓄積履歴に基づき、毎朝の数値（安静時心拍数、HRV、Body Battery、睡眠スコア）を過去に遡って予測し、平均絶対誤差（MAE）を算出します。これにより、予測が平均してどれだけの単位外れているかがわかります。
計算はウォークフォワード（常に過去から未来へ進む手法）で行われます。ある朝の予測はその日より前のデータのみから構築され、負荷係数の学習もその時点までに発生したデータペアのみを用いて更新されます。構造上、未来のデータを参照して答えを合わせることは一切不可能です。
この表はあえて不都合な現実も示せるように設計されています。蓄積データが少ない段階では、ナイーブな«昨日と同じ»モデルのほうが補正モデルよりも精度が高いことがよくあります。これは不具合ではなく正当な結果です。今後のモデルに対するハードルもこの表で定義されています。モデルが本番環境に採用されるのは、見栄えの良い理論ではなく、ホテルの実データでナイーブモデルを一貫して上回ったときだけです。
ロードマップ 現在。 個人のベースラインに基づくルールで運用されています。決定ログと結果ログは自動で蓄積され、予測誤差はボタン操作ひとつで測定されます。今後。 上の表の単純な基準値を安定して上回る十分なデータペアが集まり次第、結果ログに基づく予測モデルを導入します。それまでは、見かけ倒しの«スマート»な言葉は使いません。常に。 自動提案は医師が確認して署名するための下書きに留めます。これは現在の朝の申し送りの運用と同様であり、決定ログに基づく処方提案でも同じ原則を徹底します。よくある質問 これは機械学習ですか、それとも固定ルールですか？ コアとなるのは、ゲスト個人のベースラインに基づく説明可能なルールです。予測の負荷係数や決定ログでの類似症例検索など、学習要素はすでに存在しています。本格的なモデルは結果ログをもとに導入され、その精度はすでに誤差テーブルで測定されています。なぜニューラルネットワークではないのですか？ 処方箋に署名するのは医師であり、説明可能性は好みの問題ではなく臨床上の要件だからです。また、EU AI Actは不透明な健康推奨に対してルールベースよりも厳しい基準を課しています。さらに、データが不足したモデルはルールよりも精度が低く、プラットフォームは現在もデータを蓄積している最中だからです。一般的なPMSがこれを再現できないのはなぜですか？ Garmin Health APIは生体データを提供しますが、医師の処方や食事記録までは渡せません。«介入 → 反応»のデータペアは、これら3つのデータフローが同一の環境で統合されて初めて構築されるものであり、そのデータセットはホテル側に蓄積されます。これらはどこで確認できますか？ ダッシュボードの«設定» → «アシスタント»で確認できます。両方のログカード、要因別の観察データ、予測検証ボタン、JSONLエクスポート機能が揃っています（管理者画面 ）。プラットフォームは因果関係を主張していますか？ いいえ。«要因あり／なし»の平均値はあくまで観察結果として表記されています。因果関係を結論づけるには単一のホテルでは持ち得ないデータ量と研究デザインが必要であり、このページでもその事実を率直に明記しています。参考文献 関連トピック ← All articles 
