このページは、TOMORI が室温の目安をどう計算し、どこまで確からしいと考えているかを公開するものです。モデルを変えたときは、このページも同時に更新します。
1. 何を計算しているか
TOMORI の室温目安は、建物を「ひとつの熱のかたまり」とみなす単一ゾーンの RC 一次系モデルで計算しています。外の気温と日射から求めた実効外気温に、その建物の時定数 τ（外気の変化にどれくらいの速さで追従するか）を当てて、1時間刻みで室温を積分します。機械学習は使っていません。建築環境工学で確立した手法です。
積分は区間内線形（一次ホールド）で行っています。以前は階段近似（明示オイラー法）を使っていましたが、日変動する入力で解析解と最大 0.27℃ ずれることがわかったため、2026-08-05 に変更しました。現在の最大誤差は 0.012℃ です。
2. 何を入力にしているか
- 外気温（実況）＝気象庁アメダスの観測 JSON
- 外気温・雲量（予報）＝MET Norway Locationforecast 2.0
- 日射＝外部から直接は取得していません。実況は日照時間から Ångström–Prescott 式で、予報は雲量から Kasten–Czeplak 式で推定し、どちらも使えないときは日射の寄与を 1 に固定して縮退させます。
- 建物の属性＝築年帯・構造・窓種別・向き（利用者の申告）。不明な項目は保守的な既定値に落とします。向きが不明なら日射のゲインをゼロとして扱います。
- 基準値（WHO 18℃ ほか各国の室温基準）＝コードには持たず、法域パック（jurisdiction pack）というデータファイルから読んでいます。
時刻の扱いは EnergyPlus Weather（EPW）の規約に合わせています。気温のような状態量はその時刻の瞬時値、日射量のような積算量は直前1時間の積算＝区間の中点の代表値として扱います。
3. 準拠している規格・文献
- ISO 13790 / ISO 52016-1 系の軽量な動的熱モデル（5R1C）
- EnergyPlus Weather（EPW）の時刻規約
- Ångström–Prescott 式（日照時間→日射）、Kasten–Czeplak 式（雲量→日射）
- WHO Housing and Health Guidelines (2018)
4. モデル全体の検証結果
2026-08-16 に、札幌・2019年通年（8,760時間）で、構造の異なる3棟（木造 τ=8.0h／鉄骨 τ=13.5h／RC・SRC τ=51.2h）に対して、日射の与え方だけを変えた4系列で検証しました。中心値の絶対誤差の中央値は、最も悪い系列（日射を諦めた縮退）で 0.633℃、日照時間から推定した系列で 0.084℃ でした。全12ケースが合格ライン ±3℃ と参考基準 ±2℃ の両方を通過しています。
ただしこれはモデル構造が破綻していないことの確認であって、あなたの家の目安がこの精度で当たるという意味ではありません。 検証は3棟・1地域・1年ぶんです。
5. 既知の限界
- 家ごとの較正はまだ動いていません。 実測が貯まった家について、その家専用に係数を補正する仕組み（家ごと較正）は設計済みですが未実装です。したがって現在の表示はすべて「未較正」であり、誤差はあなたの家について検証されていません。表示しているバンド（±3℃）は未較正時の保守的な既定値です。
- 係数テーブルの値は暫定です。 時定数 τ と日射の温度換算値は標準的な文献値から生成した初期値で、実測による調整はこれからです。
- 在室者や家電の発熱は 0 として扱っています。留守・無人を前提とした見守り用途に寄せた保守的な仮定です。
- 隣の建物による日射のさえぎり（天空率）は、まだ計算に入れていません。
- 検証は札幌の1年ぶんです。他の気候区分・他の年での確からしさは検証していません。
- 建物属性は利用者の申告であり、TOMORI は正しさを検証していません。
6. 誤差指標の算出方法
画面に出す「較正点 n 件・誤差 ±X℃」は、その家の実測と、同じ時刻に対する推定との差から求めます。n はその家の較正に使えた実測の点数、X は差の絶対値の中央値です。外れ値（窓開け・来客など）は中央値と MAD で除いてから計算します。
家ごと較正が未実装のあいだ n は 0 であり、その場合は「未較正・誤差未検証」と表示します。 数字が出せないときに、それらしい数字を作って出すことはしません。
7. 集計（同条件の中央値）の作り方
同条件の中央値は、実測（observed）だけで作ります。種火（seed）と推定（predicted）は算入しません。公開するセルは、記録が 10 件以上あり、かつ異なる物件が 5 件以上あるものに限ります。満たさないときは、より広い範囲のセルへ繰り上げ、それでも満たさなければ公開しません。公開する中央値は 0.5℃ 単位に丸めます。内部では丸めずに保持しています。
8. 推定値への異議
このページに書いた方法で計算した推定値について異議がある場合は、
利用規約 第19条第2項の連絡先で受け付けます。対象の建物または地域と、異議の理由（実測値をお持ちの場合はその値）をお知らせください。
8-2. 建物単位の表示停止（オプトアウト）と推定値への異議
この建物の所有者・管理者の方は、推定値への異議を申し立てることができます。また、この建物の推定値の個別表示を停止（オプトアウト）することができます。停止しても、地域の集計値からこの建物が取り除かれるわけではありません。所有・管理の確認方法と、いただいた申し出の件数・対応結果の公表については、下記の連絡先へお問い合わせください。
9. 記録が後から書き換えられていないことの確かめ方
TOMORI は毎日1回、その日に書いた記録すべてをひとつの値（ルート）に畳み、外部の公開リポジトリ
tomori-anchor-bot/tomori-anchors に刻んでいます。刻んだ後で記録を書き換えると、再計算したルートが刻まれた値と合わなくなります。第三者が自分で計算して確かめられることが、この仕組みの目的です。
2026-09-10 ぶんの記録から刻んでいます。それ以前のぶんは刻んでいません。また現時点で対象は建物日記（観測点ごとの日次の行）だけで、住人の方の記録と記録資産コースの記録は含まれていません。これらは今後この仕組みに加えます。
刻むのはルートだけです。記録そのもの・観測点の番号・記録した方に関わる情報は、いっさい外部に置いていません。ファイル anchors/年/月/日.txt の中身は空白区切りの1行で、順に「日付・ルート・畳んだ記録の件数・モデル版」です。一度刻んだ日のファイルは上書きしません。
ルートは次の手順で再計算できます。
- 記録1件を JSON にする。キーは辞書順に並べ、
as_of・written_at・content_hash の3つは含めない。
- その JSON の SHA-256 を求める（これがその記録のハッシュ）。
- その日のすべての記録について同じことをし、記録の保存先パスの辞書順に並べる。
- 隣り合う2つのハッシュを連結して SHA-256 を求める。件数が奇数のときは最後の1つを複製して対にする。
- 値が1つになるまで前の手順を繰り返す。残った値がルート。
得られた値が anchors/年/月/日.txt の2番目の値と一致すれば、その日の記録は刻んだ時点から変わっていません。刻む操作は GitHub 上の署名付きコミットとして残るため、刻んだ日時もあわせて確認できます。
刻んだ元の記録そのものは、観測点ごと・1日ごとに
/diary/{観測点番号}/{年-月-日} で読めます（例：
/diary/14163/2026-09-10）。ブラウザで開くと表示用のページを、プログラムから読むと同じ中身の JSON を返します。このページに出ている値のハッシュが、上の葉の一覧の中の同じ行と一致します。
10. この文書の更新
モデル・入力データ源・集計方法を変更するときは、この文書を同時に改版し、版番号・日付・変更理由を残します。特定の物件や地域を狙った変更は行いません。
改版履歴：v1.2（2026-09-12）＝観測点日記の公開経路（9節）を追記。v1.1（2026-09-10）＝記録の改竄防止（9節）を追加。v1.0（2026-08-29）＝初版。