家電ごとの電力ログを AI に読ませる — 生のログ・1時間の表・コードの実行で、答えの正しさはどう変わるか

スマートプラグなどで家電ごとの電力を記録すると、短い間隔の W の値が並ぶ電力ログが何万行もたまる。どの家電がいちばん電気を使ったのか、夜のあいだ何 W が流れ続けているのかを、その行を眺めて読み取るのは人には難しい。そこで AI に読ませたくなるが、ログをそのまま貼るのか、集計してから渡すのか、計算まで AI に任せるのかで、答えの正しさと費用がどれだけ変わるかは、試してみないと分からない。

そこで、英国の家庭の電力ログを公開している REFIT（CC BY 4.0、2013〜2015 年の計測）から 2 軒・各 1 週間を取り出し、家電ごとの電力量・待機電力の目安・最も使った日を AI に答えさせ、pandas で計算した正解と照合した。当サイトの家電は測っていない。AI は claude -p（モデルは Claude Sonnet 5.5）と、手元の GPU で動かした gemma4:12b（Gemma 4 12B）の 2 つで、各条件 1 回の実行である。

※本記事にはアフィリエイト広告（PR）が含まれます。

先に結果を書く。この実行では、1 時間ごとに集計した表を渡すと、claude -p は 2 軒とも 13 問すべて正解した。一方、公称 8 秒ごとの生のログをそのまま貼ると、手計算では正確に集計できないとして数値を返さず、費用は 1 回 1.78〜1.82 ドルかかった。同じ生のログをファイルで渡し、Python の実行を許すと全問正解し、費用は 0.02〜0.05 ドルに収まった。手元の gemma4:12b は、思考を出力させたままでは答えにたどり着かず、思考を切ると 13 問中 4 問と 2 問しか合わなかった。電力ログは、集計してから渡すか、AI に計算させる。これがこの実行から読める使い方だ。

使った電力ログ — 英国の家庭の公開データ REFIT から 2 軒・各 1 週間

REFIT: Electrical Load Measurements (Cleaned) は、英国ラフバラの 20 軒で家全体と家電 9 台の消費電力（W）を記録したデータで、University of Strathclyde が公開している。記録の間隔は公称 8 秒、期間は 2013〜2015 年で、ライセンスは CC BY 4.0 である。家全体は電流を測る送信機（CurrentCost）で、家電は 1 台ずつコンセントに挿すプラグ型の計測器（IAM、Individual Appliance Monitor）で測っている。どちらも計測当時の機材だ。論文によると、参加者は同意のうえで計測された。

データは配布元のページから、清掃済みの 20 軒分の圧縮ファイルを取得した。使ったのはそのうち 2 軒、各 1 週間だけである。House 2 は電気ケトル・電子レンジ・トースターを測っている家、House 1 は電気の暖房器具（Electric Heater）を測っている家だ。どちらも、家全体の値に太陽光の発電が混じらない家を選んだ。論文によると、House 3・11・21 では発電が消費として家全体の値に足される。なお、この 2 軒のファイルは、同じ著者が Zenodo に公開した写しとも MD5 が一致した。

週は、2014 年 11 月 3 日以降で、7 日ともデータが 23 時間以上ある最初の月曜〜日曜とした。その結果、House 2 は 2014-11-17 の週、House 1 は 2014-11-03 の週になった。家と週の選び方は、AI に聞く前に決めて固定している。

CSV の見出しは Appliance1〜9 で、家電の名前は書かれていない。そのため名前は、配布元の README にある家電の一覧に従った。ただし、論文の表と名前が割れた列が 2 本ある。House 1 の Washer Dryer（論文では Tumble Dryer）と、House 2 の Overhead Fan（論文では Cooker Hood）だ。この 2 本は採点から外した。

データの性質にも触れておく。REFIT の家は、どれも主な暖房がガスのセントラルヒーティングだ（論文）。したがって 11 月の週の値でも、エアコンや電気ストーブで暖房する家の冬の電力量の目安にはならない。また計測器は電流だけを測り、電圧を 240 V と仮定して W を出している。論文は家全体の計測器の相対誤差を約 6% とし、太陽光の無い家では電力会社のメーターとの差が概ね 12% 未満だったと書く。以下の「正解」は、このデータに対する正解であって、その家が実際に使った電力量の正解ではない。

冬の家電の電気代と故障を、測る・直す・作るの順に整理した全体像は 家電の電気代と故障に AI で向き合う — 冬の前に測る・直す・作るをそろえる理由と、EU の修理する権利で変わったこと（2026-11-02 公開） にまとめた。本記事はそのうち「測る」にあたり、手元にたまった電力ログを AI でどう読むかを扱う。

出典表示: データは REFIT: Electrical Load Measurements (Cleaned)（作成: David Murray、監修: Lina Stankovic・Vladimir Stankovic、University of Strathclyde、DOI 10.15129/9ab14b0e-19ac-4279-938f-27f643078cec。Zenodo の写しは DOI 10.5281/zenodo.5063428）で、ライセンスは CC BY 4.0 である。論文は Murray, D., Stankovic, L. & Stankovic, V., Scientific Data 4, 160122 (2017)、DOI 10.1038/sdata.2016.122。本記事の表の数値は、当サイトが 2 軒・各 1 週間分を集計・加工したものだ。

正解は pandas で計算し、許容の幅を決めてから照合した

電力量は、各行の W に次の行までの秒数を掛けて足した。式で書くと、kWh＝Σ（P_i×Δt_i）÷3,600,000 である。P_i は行 i の電力（W）、Δt_i は次の行までの秒数で、1 kWh は 3,600,000 W・秒にあたる。8 秒を一律に掛けていないのは、実際の行の間隔が不揃いだからだ。たとえば House 1 の先頭の 20 行では、間隔が 1〜15 秒だった。論文も、電力量を「読みに次の読みまでの時間差を掛けたもの」として計算している。

欠けたデータの扱いも決めた。次の行まで 120 秒を超える区間は、欠測として数えない。清掃済みのデータは 2 分未満の欠けを前の値で埋め、2 分を超える欠けを 0 で埋めているので、その境目に合わせた。さらに、Issues 列が 1 の行も数えない。Issues は、プラグの計測の合計が家全体を超えた行に付く印だ。データのある時間が 23 時間未満の日は集計から外すが、対象の 2 週は選び方の条件どおり 7 日ともこれを満たしている。

日と夜間の区切りは、Unix 列の時刻を英国の現地時刻に直して決めた。正解はこの定義どおりに pandas で計算し、AI の答えは次の幅で採点した。kWh と W は正解の ±5% 以内（小さい値では ±0.05 kWh と ±5 W の大きいほう）を正解とする。家電の名前と日付は、一致したときだけ正解とした。

問いの中身と、その定義は次のとおりだ。

• 週の電力量: 家全体と、採点する 8 台の家電それぞれの 7 日間の kWh
• 最も使った家電: 週の kWh が最も大きい家電。計測した 9 台の中での最大で、家全体で最も電気を使った機器という意味ではない
• 待機電力の目安（夜間の最小値）: 夜ごとに 01:00〜05:00 の家全体の 4 つの 1 時間値から最小を取り、7 夜の中央値を W で出したもの
• 最も使った日: 家全体の kWh が最も大きい日と、その日の kWh

最も使った家電を「9 台の中で」と限るのには理由がある。論文の表によると、計測期間全体でプラグの計測が捉えたのは家全体の電力量の 35%（House 1）と 33%（House 2）で、残りは測っていない家電などだ。また、待機電力の目安の取り方、電気ケトルの使用の数え方（1500 W を超える連続運転、60 秒以内の途切れはつなぐ）、許容の幅は、外部の基準ではない。この実験のために、実行前に決めた定義である。

pandas で電力量を足し上げる手順に慣れていないなら、データの読み込み・加工・可視化を例題で追える入門書から始めると早い。AI を使った分析の進め方まで扱った版が 2026 年 10 月に出ている。

Pythonではじめるデータ分析 良質メニュー100【AI対応版】（SBクリエイティブ・書籍）

¥3,520 （2026/10/27 10:00時点 | Amazon調べ）

Amazon

＼楽天ポイント4倍セール！／

楽天市場

ポチップ

渡し方は 3 つ、モデルは 2 つ — 1 時間の表・生のログ・コードの実行

この記事では、公称 8 秒ごとの行がそのまま並ぶ CSV を「生のログ」と呼ぶ。生のログを貼る条件では、時刻を英国の現地時刻に直し、列の見出しを Appliance1〜9 から家電の名前に置き換えた CSV（時刻・家全体・家電 9 台・Issues の 12 列）を、行はそのままで問いと一緒に渡した。House 1 は電気ケトルを測っていないので、ケトルの問いが無く 10 問になる。一方の 1 時間の表は、正解と同じ方法（行ごとの時間差を掛けて足す）で pandas が作った Wh の表で、Wh は整数に丸めた。1 時間の Wh は、その 1 時間の平均の W と同じ数になる。

claude -p は、Claude Code（2026-10-26 時点で 2.1.310）を対話なしで動かす使い方である。モデルは --model で指定し、出力に記録されたモデルの ID は claude-sonnet-5-5 だった。組み込みツールなし（--tools ""）、MCP なし（空の設定と --strict-mcp-config）、設定ファイルも読まない最小の構成にして、ホームの外の空のフォルダから呼んだ。システムプロンプトは、3 つの渡し方とも --system-prompt で「You are a careful data analyst.」の 1 文に置き換えた。このフラグは Claude Code の既定のシステムプロンプトを丸ごと置き換える。Anthropic のモデル一覧によると、Claude Sonnet 5.5 のコンテキストは 100 万トークン、知識の締切は 2026 年 6 月だ。単価は入力 2 ドル・出力 10 ドル（100 万トークンあたり、2026 年 10 月時点）である。

手元のモデルは、Ollama 0.40.11 で動かした gemma4:12b だ。Gemma 4 12B は Google DeepMind が 2026-06-03 に公開した Apache 2.0 のモデルで、この実行で使った gemma4:12b のビルド（ダイジェスト 6114515d63c1）は 11.9B パラメータ・Q4_K_M の量子化で、ダウンロードは 8.0GB である（Ollama のページにある 7.7GB のほうは MLX 用の別のビルド。ダウンロードの大きさは VRAM の使用量ではない）。GPU は RTX 5070 Ti（VRAM 16,303 MiB）で、温度は 0 にした。Ollama の文書によると、VRAM が 24 GiB 未満なら既定のコンテキスト長は 4096 トークンだ。そこで、コンテキスト長（Ollama の num_ctx。入力と出力を合わせて扱えるトークン数の上限）を 32768 と指定した。

生のログは claude -p にだけ渡し、手元のモデルには渡していない。参考までに、Claude が数えた生のログの入力は約 44〜45 万トークンで、Ollama のページが示す gemma4:12b のコンテキストの最大（256K）より多い。トークンの数え方はモデルごとに違うので、これは目安の比較である。

もう一つ断っておく。最初の実行の後に、結果の原因を切り分けるための条件を 3 つ足した。gemma4:12b の思考を切る条件、コンテキスト長を 65536 に広げる条件、そして claude -p に Python の実行とファイルの読み取りだけを許し、生の CSV をファイルで渡す条件（上の表の 3 行目）だ。どれも実行前に決めた条件ではなく、各 1 回の実行である。また、AI に渡したのはデータ（CC BY 4.0）と問いだけで、配布ページの文章は渡していない。

結果 — 1 時間の表なら全問正解、生のログを貼ると数値が返らなかった

費用は claude -p が返した total_cost_usd である。これはクライアント側の推定で、実際の請求額とは違うことがある。この実行では、claude -p のどの呼び出しも、入力を 1 時間のプロンプトキャッシュに書き込む形で課金されていた。公式の料金表では、Claude Sonnet 5.5 の 1 時間のキャッシュの書き込みは 100 万トークンあたり 4 ドルで、通常の入力（2 ドル）の 2 倍である。前の呼び出しのキャッシュを読んだ回は無い。手元のモデルは API の費用が 0 で、電気代は含めていない。表の数はすべて、各条件 1 回の実行での値だ。

1 時間の表を渡すと、claude -p は 2 軒とも 13 問すべて正解した

1 時間の表を渡した claude -p は、House 2・House 1 とも 13 問すべてを許容の幅に収めた。入力は約 6,300 トークン（6,360 と 6,342）、費用は 0.07〜0.09 ドル、時間は 28〜38 秒である。168 行の表なら、週の合計も、夜ごとの最小値の中央値も、AI が表から読み取って答えを返した。

正解の週の電力量は次のとおりだ（英国の家庭、2014 年 11 月の 1 週間）。値は 1 時間の表の Wh を足したもので、生のログから直接足すと小数第 3 位が最大 0.007 kWh ずれる。

House 2 で最も使った家電は食器洗い機で、週 11.6 kWh だった。続いて冷凍冷蔵庫が 5.922 kWh、洗濯機が 4.27 kWh、電気ケトルが 3.735 kWh である。House 1 では 2 台目の冷凍庫（Freezer(2)）が 4.613 kWh で最も多く、電気の暖房器具はこの週 0.168 kWh しか使っていない。最も使った日は、House 2 が 2014-11-23（12.566 kWh）、House 1 が 2014-11-03（11.348 kWh）だった。

生のログをそのまま貼ると、手計算では集計できないとして数値を返さなかった

生のログを貼った claude -p は、House 2 で 11 問中 1 問、House 1 で 10 問中 0 問しか正解しなかった。数値を間違えたのではなく、ほとんど数値を返さなかった。House 2 の返答はこうだ。

全部の値を正確に出すには、数万行の集計をコードで実行する必要があります。このチャットにあるCSVを手計算で処理すると、小数3桁の kWh や小数1桁の W は確実に誤るので、数値を作って返すことはしません。

House 2 で答えたのは電気ケトルの使用回数だけで、7 回と答えて正解（7 回）と一致した。夜間の 10 分移動平均の最小は「93 W 台前半と思われます」と書いたが、数値としては返さなかった（正解は 93.4 W）。House 1 では、数値の代わりに計算のコードを返した。夜間の最小は目視の概算として「約 153 W 前後」と書いたが、これも数値としては返さなかった（正解は 153.1 W）。参考までに、その日の家全体の正解は、House 2 の月曜が 10.164 kWh、House 1 の月曜が 11.348 kWh である。

費用は House 2 が 1.784112 ドル、House 1 が 1.81501 ドルで、入力は 443,334 トークンと 450,596 トークンだった。1 時間の表の回と比べると、入力は桁違いに多い。公式の料金表によると Claude Sonnet 5.5 は 100 万トークンまで同じ単価で読め、公式の文書によると claude -p に標準入力で渡せる量は 10MB までだ。約 56〜58 万字の CSV は、どちらの上限にも収まる。つまり、渡せることと、正しく集計できることは別だった。

数値を作らずに断ったことは、もっともらしい数字を並べられるよりは扱いやすい。外れた数字は、正解と照合しなければ外れていると分からないからだ。とはいえ、1 回 1.78 ドルあまりを払って返ってきたのは、ケトルの回数と、集計はコードで実行する必要があるという指摘だった。

同じ生のログをファイルで渡し、Python の実行を許すと全問正解した

同じ生の CSV をファイルとして作業フォルダに置き、claude -p に Python の実行とファイルの読み取りだけを許した。すると、House 2 は 11 問中 11 問、House 1 は 10 問中 10 問を正解した。AI は pandas で CSV を読み、行ごとの時間差を掛けて足すコードを書いて実行した。正解を作ったのと同じ考え方の計算を、AI 自身がコードで組んだことになる。

費用は House 2 が 0.047413 ドル、House 1 が 0.0239014 ドルで、入力は 30,168 トークンと 18,349 トークン（うち 23,650 トークンと 15,274 トークンは、同じ実行の中で AI が自分の前のやり取りをキャッシュから読み直した分）、時間は 32.4 秒と 20.7 秒である。生のログを貼った回の 1.78〜1.82 ドルに対して、0.02〜0.05 ドルで全問に答えが返った。

ただし、この条件は最初の実行の後に足したものだ。生のログを貼った回に AI 自身が「数万行の集計をコードで実行する必要があります」と答えたので、その道具を渡して確かめた。また、コードは手元の PC で動くが、claude -p に渡した問いや AI が読んだ内容は Anthropic の API に送られる。

手元の gemma4:12b は、思考を出すと答えに届かず、思考を切ると多くを外した

gemma4:12b は、思考（Ollama の think。答えの前に考える過程を出力する機能）を指定しない条件では思考を出力し、その途中で止まって答えを返さなかった。num_ctx が 32768 の回では、House 2 の入力 7,319 トークンに対して出力が 25,449 トークンに達した。足すと 7,319＋25,449＝32,768 で、コンテキスト長ちょうどで止まったことになる（Ollama の done_reason は length、約 2.7 分）。コンテキスト長を 65536 に広げても、出力が 58,217 トークン（House 1 は 58,106）まで伸びて同じように止まり、約 6 分かけて答えは出なかった。

思考を切ると、gemma4:12b は 4〜11 秒で答えを返した。ところが、正解は House 2 で 13 問中 4 問、House 1 で 13 問中 2 問だった。House 2 で合ったのは、洗濯機とトースターの週の kWh、最も使った家電（食器洗い機）、最も使った日の 4 問である。House 1 で合ったのは、待機電力の目安（夜間の最小値）と最も使った日の 2 問だった。

外れた答えの一部を並べる。

週の kWh の答えは、採点した 18 問中 12 問が正解より小さく、そのうち 8 問は正解の 3 分の 1〜半分ほどだった。答えた値には、小数点以下が .545・.345・.555 のようにそろうものが多い。House 1 のパソコンのように、正解（0.023 kWh）より大きく出た値もある。なぜこうなったかは、この実験からは分からない。

待機電力の目安は 108 W と 178 W — 夜間の最小値が表すもの

この実験で「待機電力の目安（夜間の最小値）」と呼んだのは、夜ごとに 01:00〜05:00 の家全体の 4 つの 1 時間値から最小を取り、7 夜の中央値を出した値だ。1 時間の Wh はその時間の平均の W と同じ数なので、そのまま W として読める。7 夜の中央値なので、1 夜だけ低い値や高い値があっても動きにくい。

中央値は、7 つの値を小さい順に並べた 4 番目である。House 2 なら 89・101・106・108・120・123・124 の 4 番目で 108 W、House 1 なら 172・172・174・178・178・180・191 の 4 番目で 178 W になる。英国の家庭の 2014 年 11 月の値で、いまの家庭の値ではない。

この値は、使っていない家電がコンセントから受ける電力だけではない。家全体の 1 時間の平均なので、夜も動く冷蔵庫・冷凍庫の分が入る。House 1 は冷蔵庫 1 台と冷凍庫 2 台を、House 2 は冷凍冷蔵庫を測っている。しかも、同じ夜間でも定義を変えると値が変わる。生のログの問いで使った月曜 1 日の 10 分移動平均の最小は、House 2 で 93.4 W、House 1 で 153.1 W だった。

日本の公的な定義も見ておく。資源エネルギー庁のエネルギー白書2020 は脚注で、待機電力を次のように説明している。

待機時消費電力とは、リモコンやマイコンなどを組み込んだ家電機器が、その機器を使っていないときでもコンセントにつながっていることで消費される電力のことをいいます。

続く脚注には、資源エネルギー庁の 2012 年度（平成 24 年度）の待機時消費電力調査による値として、世帯の年間 4,432 kWh のうち待機電力が 228 kWh、割合で 5.1% とある。これは 2012 年度の日本の値で、現在の値ではない。家電 1 台ずつの待機を数えるこの定義と、家全体の夜間の最小値は別のものだ。

EU にも待機電力の上限がある。欧州委員会の説明によると、規則 (EU) 2023/826 は家庭用・事務用の電気・電子機器の待機やオフの電力に要件を定めている。測り方の国際規格には IEC 62301 があり、現行の第 3 版（IEC 62301:2026、2026-05-22）は待機などのモードの電力の測り方と報告の仕方を定める規格で、上限値は決めていない。こうした上限は製品 1 台について定めたものだ。それに対して REFIT は家全体の電流を測り、240 V を仮定して W にした値である。だから本記事の 108 W・178 W は、EU の上限とは比べない。

電力ログは集計してから渡すか、計算させる

この実行から読めるのは、電力ログの渡し方の違いだ。1 時間ごとに集計した表なら、claude -p は 2 軒とも全問正解し、費用は 1 回 0.07〜0.09 ドルだった。生のログでも、ファイルで渡して Python の実行を許せば全問正解し、費用は 0.02〜0.05 ドルだった。生のログをそのまま会話に貼った回だけが、1.78〜1.82 ドルを使って答えをほとんど返さなかった。

1 万 2 千行あまりの W の値から 1 日の kWh を出すには、行ごとに時間差を掛けて足す計算を、家電の列の数だけ繰り返す必要がある。AI 自身も、手計算で処理すると小数の桁が確実に誤ると書き、コードで実行する必要があると答えた。言い換えると、この実行で AI がうまく果たしたのは、集計の手順をコードに書くことと、集計した結果を読むことだった。集計そのものは pandas の数行で済み、AI に頼まなくてもできる。

一方で、手元のモデルで読む利点もある。欧州データ保護監察機関（EDPS、EU の機関）は 2012 年 6 月 11 日のプレスリリースで、スマートメーターのデータは、家の中で家族が何をしているか、休暇や仕事で留守にしているかまで追えると指摘した。電力ログは生活の記録なので、PC の外に出さずに読めるならそれに越したことはない。ただし、この実行では手元の gemma4:12b は正しく読めなかった。思考を出すとコンテキスト長 32768 でも 65536 でも上限を使い切って答えが出ず、思考を切ると 13 問中 4 問と 2 問しか合わなかった。手元の GPU にどの大きさのモデルが載るかの見積もりは 手元のVRAMで動くモデルを見積もる — 量子化とメモリ計算の基礎（2026-08-25 公開） で、クラウドと手元のどちらに仕事を回すかの考え方は クラウドAIの請求書を見てローカルAIを考え直す — 手元のGPUで回る仕事と回らない仕事（2026-08-24 公開） で扱った。

外に出す場合も、渡す量は絞れる。1 時間の表にも、いつ家電を使ったかは残る。問いに要る期間と列だけを渡せば、外に出る生活の記録は少なくなる。また、データそのものを渡さずに、列の名前と定義だけを伝えて集計のコードを書かせ、手元で実行する形もありうる。ただし、この形は本記事の実験では試していない。

電力ログを PC の外に出さずに読みたいなら、手元の GPU でモデルを動かす方法を一通り試しておくと、何が任せられて何が任せられないかを自分で確かめられる。

これからはじめる！生成AI＆ローカルLLMプログラミング（日経BP・書籍）

¥2,750 （2026/09/20 10:08時点 | Amazon調べ）

Amazon

＼楽天ポイント4倍セール！／

楽天市場

ポチップ

自分の電力ログを 1 時間ごとに集計してから AI に渡す手順

ここからは、手元の電力ログで同じことをする手順を書く。前提は、スマートプラグや Home Assistant などから書き出した CSV が手元にあることだ。製品ごとの書き出しの仕様は扱わず、どの製品でも確かめる点だけを並べる。

1. CSV の中身を確かめる

最初に、3 つを確かめる。時刻の列がどの時間帯（UTC か日本時間か）で書かれているか。電力の列が、その時点の電力（W）なのか、累計の電力量（kWh）なのか。そして、行の間隔が一定か。本記事のデータでも、公称 8 秒の行の間隔は実際には不揃いで、時刻の扱いにも確かめきれない点が残った。ここを曖昧にしたまま AI に渡すと、AI も同じところで迷う。

2. pandas で 1 時間ごとの Wh にする

電力（W）の列がある場合は、本記事の正解と同じ考え方で集計する。列の名前（time・power_w）は例なので、手元の CSV に合わせて書き換える。

import pandas as pd

df = pd.read_csv("plug_log.csv", parse_dates=["time"]).sort_values("time")
df = df.set_index("time")

# 次の行までの秒数。120 秒を超える区間は欠測として数えない
dt = df.index.to_series().diff().shift(-1).dt.total_seconds()
dt = dt.where(dt <= 120, 0)

# W×秒÷3600＝Wh を 1 時間ごとに足す。covered_s はデータのある秒数
hourly = pd.DataFrame({
    "wh": (df["power_w"] * dt / 3600).resample("1h").sum().round(1),
    "covered_s": dt.resample("1h").sum(),
})
hourly.to_csv("plug_hourly_wh.csv")

covered_s を一緒に出しておくのは、欠測のある時間の Wh が小さく出るからだ。covered_s が 1 時間（3,600 秒）を大きく下回る時間は、AI に渡す前に除くか、問いの中で扱いを決めておく。なお、このコードは時間の境目をまたぐ区間を分けていないので、covered_s が 3,600 秒をわずかに超えることがある。この表の各行は、その 1 時間の開始時刻で表示される。01:00 の行が 01:00〜02:00 の Wh で、夜間の 01:00〜05:00 の 4 つの 1 時間値は 01:00〜04:00 の 4 行にあたる。

累計の電力量（kWh）の列がある場合は、各 1 時間の最初の読みをその開始時刻の累計値とみなし、次の 1 時間の最初の読みとの差を、開始時刻の行に付ける。こうすると、上の表と同じく 01:00 の行が 01:00〜02:00 の電力量になる。

start_kwh = df["energy_kwh"].resample("1h").first()
hourly_kwh = start_kwh.diff().shift(-1)

00:00・01:00・02:00 の累計値が 100・101・103 kWh なら、00:00 の行に 1、01:00 の行に 2 が付く。02:00 の行は、次の 1 時間の読みが無いので空になる。1 時間ごとの最後の読みの差（resample("1h").last().diff()）では、同じ例で 01:00 の行に 1、02:00 の行に 2 が付き、1 時間後ろの行にずれる。なお、読みが正時ちょうどでない場合は、最初の読みを開始時刻の値とみなすぶんだけ近似になる。

3. 定義を書いた問いと一緒に渡す

1 時間の表を渡すときは、問いに定義を書く。本記事の実験でも、待機電力の目安や電気ケトルの使用の数え方を問いの文に書いて渡した。例えば次のような問いになる。

添付の表は、1 時間ごとの電力量（Wh）です。列は time、wh、covered_s です。
1. 7 日間の合計を kWh で、小数 3 桁まで出してください。
2. 待機電力の目安として、01:00〜05:00 の 4 つの 1 時間値の最小を夜ごとに取り、
   7 夜の中央値を W で出してください。
3. 計算に使った式も書いてください。

表が大きくなる場合や、生のログのまま渡したい場合は、会話に貼らずにファイルで渡し、コードの実行を許す。この実行で、生のログに全問正解したのはこの形だった。

4. 答えの一部を自分で検算する

最後に、AI の答えのうち 1 行で出せる値は、自分で確かめる。たとえば期間全体の kWh は、集計した表の合計を 1000 で割れば出る。

print(hourly["wh"].sum() / 1000)

この 1 行の値と AI の答えが合っていれば、少なくとも合計の読み取りは合っている。合わなければ、AI がどの行を読み落としたかを問い直す手がかりになる。

手順の前提になる電力ログは、電力モニタリング付きのスマートプラグで取れる。書き出しの形式と間隔は製品ごとに違うので、買う前に仕様を確かめたい。

TP-Link Tapo スマートプラグ ミニ（Matter対応・電力モニタリング）

¥1,409 （2026/09/29 08:58時点 | Amazon調べ）

Amazon

＼楽天ポイント4倍セール！／

楽天市場

ポチップ

この実測で言えないこと

結果を読むときの限界を、まとめて書いておく。

• 各条件 1 回の実行: 2 軒・各 1 週間（生のログは各 1 日）を、各条件 1 回ずつ AI に読ませただけだ。同じ問いを繰り返したときに答えがどれだけ揺れるかは測っていない。数はすべて「この実行ではこうだった」という値で、モデルの一般的な能力を示すものではない。
• 後から足した条件がある: gemma4:12b の思考を切る条件、コンテキスト長 65536 の条件、claude -p にコードの実行を許す条件は、最初の実行の後に原因を切り分けるために足した。
• 英国の家庭、2013〜2015 年のデータ: 主な暖房はガスで、計測器は電流だけを測り 240 V を仮定している。正解は「このデータに対する正解」で、その家の実際の消費の正解ではない。日本の家庭や、電気で暖房する家の冬の目安にはならない。
• 時刻の扱い: 日と夜間の区切りは、Unix 列を UTC とみなして英国の現地時刻に直して決めた（配布元の README は列の説明で Unix 列を「UNIX TIMESTAMP (UCT)」と書いている）。対象の 2 週は英国の夏時間ではない 11 月で、Time 列の時刻とこの変換の時刻は全行で一致した。論文は夏時間を補正したと書いているが、Time 列と Unix 列のどちらをどう補正したのかは確かめきれていない。01:00〜05:00 は、この変換での時刻である。
• 待機電力の目安は待機電力そのものではない: 夜間の最小値には冷蔵庫・冷凍庫のように夜も動く機器が入る。清掃済みのデータは 2 分を超える欠けを 0 で埋めているので、0 W があっても待機 0 W とは区別できない（対象の 14 夜の 1 時間値の最小に 0 W は無かった）。
• 家電の名前: 配布元の README の一覧に従い、論文と割れた 2 列は採点から外した。
• モデル: クラウドは claude-sonnet-5-5、手元は gemma4:12b（Q4_K_M、温度 0）だけを試した。ほかのモデルや大きさ、設定では試していないので、「手元のモデルは電力ログを読めない」とは言えない。モデルが REFIT のデータを学習で知っているかどうかも確かめていない。
• 費用: total_cost_usd はクライアント側の推定で、請求額とは違うことがある。円には換算していない。電気料金の単価や電気代の金額は、本記事では扱っていない。

まとめ — 電力ログを AI に読ませるなら、生のまま貼らない

• 英国の家庭の公開データ REFIT から 2 軒・各 1 週間の電力ログを取り出し、pandas で作った正解と AI の答えを照合した。当サイトの家電は測っていない。
• この実行では、1 時間ごとに集計した表を渡すと、claude -p（claude-sonnet-5-5）は 2 軒とも 13 問すべて正解した（費用 0.07〜0.09 ドル）。
• 生のログ（1 日で 1 万 2 千行あまり）をそのまま貼ると、手計算では正確に集計できないとして数値を返さなかった。費用は 1 回 1.78〜1.82 ドルで、答えたのは House 2 の電気ケトルの回数（7 回、正解）だけだった。
• 同じ生のログをファイルで渡し、Python の実行を許すと全問正解し、費用は 0.02〜0.05 ドルだった。
• 手元の gemma4:12b は、思考を出すとコンテキスト長を使い切って答えが出ず、思考を切ると 13 問中 4 問と 2 問しか合わなかった。電力ログは生活の記録なので手元で読む利点はあるが、この実行では正しく読めなかった。
• 待機電力の目安（夜間の最小値）は House 2 で 108 W、House 1 で 178 W だった。冷蔵庫など夜も動く機器を含む家全体の値で、製品ごとの待機電力の上限とは比べられない。
• 自分の電力ログを AI に読ませるなら、pandas で 1 時間ごとに集計し、定義を書いた問いと一緒に渡す。生のまま読ませたいときは、ファイルで渡してコードの実行を許す。そのうえで、合計のような 1 行で出せる値は自分で検算する。

参照

• REFIT: Electrical Load Measurements (Cleaned)（University of Strathclyde の配布ページ）
• REFIT: Electrical Load Measurements (Cleaned)（Zenodo の記録 5063428）
• Murray, Stankovic & Stankovic「An electrical load measurements dataset of United Kingdom households from a two-year longitudinal study」Scientific Data 4, 160122 (2017)
• Creative Commons Attribution 4.0 International（legal code）
• Anthropic の Models overview
• Anthropic の Pricing
• Claude Code の CLI reference
• Claude Code の非対話の実行（headless）
• Ollama v0.40.11 のリリース
• Ollama の文書「Context length」
• Ollama のモデルページ gemma4:12b
• Google「Introducing Gemma 4 12B」
• Google「Apache License 2.0｜Gemma」
• EDPS プレスリリース EDPS/10/12（2012-06-11、スマートメーター）
• 資源エネルギー庁「エネルギー白書2020」第2部第1章第2節
• 欧州委員会「Standby, networked standby and Off mode」
• IEC 62301:2026（IEC Webstore）

ブラウザだけでできる本格的なAI画像生成【ConoHa AI Canvas】

swiftwand

X

AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。 初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI. Practical tips that anyone can start using right away.