賃貸市場の「本当の家賃トレンド」をデータで暴く――5ヶ月・1,365物件の分析から見えたこと

本記事は、AI連携でどこまで自動化できるかを検証したものです。記事の中身の妥当性については十分には検証できていませんが、作業過程で検証を何回か繰り返しています。元データの取得方法は過去記事を参考にしてください。では、以下がClaude codeを使って解析、生成した分析結果の記事です。


「最近、家賃が上がっている気がする」――そう感じている人は多いだろう。物価高騰が続く中、賃貸市場にも影響が出ているという報道は絶えない。では実際のところ、家賃は本当に上がっているのか。

筆者はある地域の賃貸物件データを約5ヶ月間・38時点にわたってスクレイピングし、統計的な手法で「本当の家賃トレンド」を分析した。単純な平均値の変化ではなく、物件の条件(広さ・築年数・設備など)を揃えた上で比較するという、ヘドニック価格指数的なアプローチを用いた。結果は、多くの人の直感を裏切るものだった。


データの概要

  • 収集期間: 約5ヶ月(38時点)
  • 生データ: 8,592レコード
  • 分析対象物件数: 1,365件(重複・外れ値除去後)
  • 物件タイプ: 賃貸アパート・マンション・一戸建て(ある地方都市周辺)

注目すべきは、大手賃貸サイトは同一物件の掲載コードを定期的に更新する仕様があることだ。そのまま集計すると同じ物件が複数カウントされてしまう。この問題を解決するため、Union-Find(素集合データ構造)というアルゴリズムを用いて同一物件を連結し、正確な集計を実現した。


発見①「家賃は上がっていない」――条件を揃えると見えた真実

まず、シンプルに取得日ごとの平均家賃をプロットすると、月▲380円という下落トレンドが確認された(p<0.001)。「家賃が下がっているじゃないか」と思うかもしれない。

ところが、物件の条件(広さ・築年数・設備・階数など44変数)を重回帰モデルで除去した後の「残差」で同じ分析をすると――

トレンド: 月▲106円、p値=0.190(統計的に有意でない)

つまり、条件を揃えると家賃変動はゼロに近い。物価高騰の影響は、少なくともこの地域・この期間においては賃貸市場には波及していなかったということだ。

生データで見えていた「下落トレンド」の正体は、安価な物件の大量新規掲載によるミックス効果だった。


発見②「2月の急落」は本物か

データを眺めていると、2月上旬に平均家賃が突如▲1,500円近く急落する場面があった。

要因金額
物件ミックスの変化(安価物件の大量掲載)▲1,000円
本物の需要緩和(条件考慮後も残る下落)▲500円
合計▲1,500円

急落の3分の2はミックス効果で、残り3分の1が実態のある需要緩和だった。このような「見かけの変動」と「実態の変動」を区別するには、条件考慮済みの分析が不可欠だ。


発見③「1月は割高、2月以降は割安」という季節性

条件考慮済みの残差を月別に見ると、明確な季節パターンが浮かび上がった。

時期残差(条件考慮済み)解釈
11〜12月±500円程度安定
1月+1,000〜+2,000円需要ピーク・割高
2月以降▲400〜▲800円需給緩和・割安

1月は引越しシーズン前の駆け込み需要で、同じ条件の物件でも約1,000〜2,000円高く成約されていた。逆に2月以降はその反動で割安感が出ている。

賃貸を探すなら、1月ではなく2〜3月以降の方がコスト効率が良いという示唆が得られる。


発見④ 家賃を決める最強の変数は「追焚」だった

重回帰分析で44変数を投入したところ、最も家賃との相関が高かった変数は意外にも「追焚(お風呂の追い焚き機能)の有無」(相関係数r=0.670)だった。

順位変数相関係数
1追焚設備あり+0.670
2専有面積(㎡)+0.651
3総戸数(棟の規模)-0.584
4仲介手数料額+0.526
5礼金+0.459

追焚が最強の予測変数になった背景には、地域の入浴文化や生活習慣が影響している可能性がある。また、「大規模物件(総戸数が多い)ほど家賃が低い」という結果は、管理コストの規模の経済を反映していると考えられる。


発見⑤ 「2LDKは割高、1LDKは割安」という構造的価格差

間取り別に条件考慮済みの残差を分析すると、興味深い構造が浮かび上がった。

間取り残差解釈
2LDK+1,000〜+3,000円一貫して割高
1LDK▲1,000〜▲2,000円一貫して割安
1K季節性あり(1月に割高)需要変動大きい

同じ面積でも、2LDKはファミリー向けの需要プレミアムが乗っており割高になる傾向がある。一方1LDKは供給過多気味で割安。カップルや二人暮らしなら1LDKも候補に入れると費用対効果が高い。

賃貸市場の家賃トレンド分析グラフ(条件考慮済み)
賃貸市場の家賃トレンド分析グラフ(条件考慮済み)

分析に使ったモデルの精度

最終的に採用したモデル(重線形回帰・44変数+交互作用2項目)の精度は以下の通り:

指標
R²(決定係数)0.750
調整済みR²0.699
RMSE4,506円
VIF>10(多重共線性)なし

実際の家賃と予測値の誤差が平均±4,500円程度に収まっており、賃貸物件の価格モデルとして実用的な精度が得られた。


まとめ:賃貸市場の「見えない構造」

今回の分析から得られた主要知見をまとめる。

  1. 物価高騰は賃貸家賃に波及していない(少なくともこの地域・この期間)
  2. 家賃の下落トレンドは物件ミックスの変化が原因で、実態は横ばい
  3. 1月は割高、2月以降は割安というサイクルが存在する
  4. 追焚・専有面積・大規模物件の規模が家賃を最も強く説明する
  5. 2LDKは割高、1LDKは割安という構造的価格差がある

賃貸物件を探す際、これらの知見を活用することで、より合理的な意思決定ができるだろう。


分析の補足・免責事項

本分析は特定の賃貸情報サイトのデータをスクレイピングして実施したものであり、市場全体を代表するものではない。また、「掲載から消えた = 入居決定」という推定には不確実性が伴う。分析期間が約5ヶ月と限られているため、年間の季節変動を完全には捉えられていない点にも注意が必要だ。

本記事の分析コードはPython(pandas・scikit-learn・statsmodels・scipy)を使用して作成した。


どうだろうか、素人が使いこなすには難しいかもしれないが、分かっている人が分析する分には効率的な作業を行える。課題は本当にわかっているか、ちゃんと検証できているかだろう。 この資料を生成するまでの過程は、別の記事にしてみよう。


関連記事

Claude MCP 連携ガイド 総合インデックス ─ WordPress・Buffer・スマートホームまで実践記録

このページは、Claude の MCP(Model Context Protocol)を使ったさまざまな外部サービス連携について、実践記録・トラブル対応・活用事例をまとめた総合インデックスです。記事が追加されるたびにこのページも更新されます。

MCPとは何か

MCP(Model Context Protocol)は、Claude などの AI が外部ツールやサービスと直接やり取りするための仕組みです。従来の AI チャットは「会話するだけ」でしたが、MCP を使うと Claude が実際にアクションを起こすことができます。

たとえば、Claude に「この内容でブログ記事を書いて WordPress に投稿して」と指示すると、Claude が自分でWordPressにアクセスして記事を作成・投稿できます。「SNSに投稿して」と言えばBufferを通じてスケジュール投稿もできます。プログラミングの知識がなくても、日本語で指示するだけで複雑な自動化が実現できる──それがMCPの可能性です。

MCPでできること(概念図)

指示の例MCPが動かすサービス実現できること
「記事を投稿して」WordPress下書き作成・タグ付け・公開
「SNSに流して」BufferX・Instagram等へのスケジュール投稿
「HSAとhsBoxの連携設定を支援して」hsBox / ChromecasthsBoxの連携設定支援をしスマートデバイスに連携設定用のQRコードをキャスト
「このページを確認して」Claude in Chromeブラウザを操作して情報収集・フォーム入力

現在の連携状況

サービスMCPツール状況達成レベル
WordPressclaudeus-wp-mcp✅ 稼働中記事作成・タグ・カテゴリー操作が可能。編集者権限で安定動作。
Bufferbuffer MCP✅ 稼働中SNSチャンネルへのスケジュール投稿が可能。
Claude in ChromeClaude in Chrome🔄 試験運用中ブラウザ操作・スクレイピング・フォーム入力などを検証中。
hsBox / スマートホームhsBox API連携🔜 計画中音声操作・スケジュール・デバイス制御との連携を検討中。
Google Drive / Gmail未定📋 将来構想ドキュメント管理・メール自動化を将来的に検討。

連携別 記事インデックス

🔷 WordPress 連携

Claude Desktop に claudeus-wp-mcp を接続し、WordPress への記事投稿・編集・タグ管理などを自動化します。Xserver 環境での構築・運用記録を中心にまとめています。

Claude Desktop × WordPress MCP連携:何度目の正直か、すったもんだした設定記録

🔷 Buffer 連携(SNS投稿自動化)

Buffer の MCP を使って、Claude から X(Twitter)・Instagram などへのソーシャルメディア投稿を自動化します。記事公開と同時に SNS 投稿を流す、といった運用が可能です。

  • 📋 記事準備中

🔷 Claude in Chrome(ブラウザ操作)

Claude がブラウザを直接操作して、ウェブページの確認・情報収集・フォーム入力などを行います。RPA(ロボティック・プロセス・オートメーション)的な使い方が可能です。

  • 📋 記事準備中

🔷 hsBox / スマートホーム連携(計画中)

hsBox は複数メーカーの家電を統合するスマートホームプラットフォームです。Claude との MCP 連携により、音声・スケジュール・外部イベントと連動した高度なホームオートメーションが実現できると期待しています。

現在は hsBox の API を活用した YouTube ライブキャストや緊急地震通報などを実装済みです。MCP 経由で Claude から直接 hsBox を操作できるようになれば、さらに柔軟な自動化が可能になります。

MCP連携で気をつけること

実際に構築・運用してわかった注意点をまとめます。詳細は各記事をご参照ください。

① セッション冒頭に権限・制約を明示する

Claude は前の会話を覚えていません。毎回のセッション冒頭に「このサイトのMCPユーザーは編集者権限です」「wp_health系は使わないでください」といった制約条件を伝えることで、Claude の思い込みによる無駄なデバッグを防げます。

② 接続確認は低権限エンドポイントから順に

MCP が繋がらないと感じたとき、いきなり管理者権限が必要なエンドポイントを試すのは禁物です。get_taxonomies(認証不要)→ get_posts(編集者権限)の順に確認し、どこで止まるかを特定してから原因を追うのが正しい手順です。

③ アプリケーションパスワードは更新後に必ず保存

WordPress のアプリケーションパスワードを再生成した後、「プロフィールを更新」ボタンを押し忘れると保存されません。更新後はブラウザ上の完了メッセージを必ず確認してください。

このページについて

このページは随時更新されます。新しい連携記事が公開されたり、トラブル対応の知見が増えたりした場合に内容を追加・更新していきます。

MCP連携の構築・運用でお困りの点があれば、各記事のコメント欄からお気軽にどうぞ。


関連記事

Claude MCP × WordPress連携でハマった落とし穴──wp_healthの403は「接続失敗」ではなかった

ClaudeのMCP(Model Context Protocol)を使ってWordPressと連携する環境を構築しました。昨日まで正常に動いていたのに、今日は突然つながらない──そんなトラブルを経験しました。結論から言うと、原因はClaudeの思い込みによるデバッグミス(とアプリケーションパスワードの保存忘れ)でした。同じ失敗を繰り返さないための記録として残します。

環境

  • サーバー:Xserver(hoscm.xsrv.jp)
  • MCPプラグイン:claudeus-wp-mcp
  • MCPユーザー権限:編集者(Editor)
  • 接続設定:wp-sites.json(Claude Desktop

何が起きたか──事象の時系列

昨日まで正常に動作していたMCP連携が、今朝から突然失敗するようになりました。Claudeは接続確認のために wp_health__test_auth を繰り返し実行しましたが、すべて403エラーが返ってきました。

手順実施内容結果
wp_health__test_auth で接続確認❌ 403エラー
WP Fastest Cache を無効化❌ まだ403
CloudSecure WP Security を無効化❌ まだ403
Xserver WAF を調査❌ 関係なし
アプリケーションパスワードを再生成❌ まだ失敗
PowerShellで認証テスト✅ 通った
「更新ボタン押し忘れ」に気づく原因判明
パスワード正しく保存・再起動❌ まだ失敗
wp_healthではなく通常エンドポイントで確認✅ 正常動作!

本当の原因は2つあった

原因①:アプリケーションパスワードの「保存ボタン押し忘れ」

WordPressのアプリケーションパスワードを再生成した後、プロフィール画面の「プロフィールを更新」ボタンを押さずに離脱していたため、新しいパスワードが保存されていませんでした。これが真の認証失敗の原因でした。

PowerShellで認証テストをしたところ通ったことで、この事実が判明しました。パスワード更新後は必ずブラウザ上で「更新完了」のメッセージを確認してください。

原因②:wp_healthエンドポイントは編集者権限では使えない

Claudeが接続確認に使い続けた wp_health__test_auth は、管理者権限が必要なエンドポイントです。このサイトのMCPユーザーは編集者権限しか持っていないため、パスワードが正しくても403が返り続けます。これは「接続失敗」ではなく「権限不足」による正常な拒否でした。

エンドポイント必要権限編集者での結果
get_taxonomies不要(公開情報)✅ 正常
get_posts編集者✅ 正常
create_post編集者✅ 正常
get_settings管理者❌ 403
wp_health__test_auth管理者❌ 403

無実だったプラグインたち

今回の騒動で無効化・調査したプラグインやセキュリティ設定は、すべて無関係でした。

  • WP Fastest Cache:.htaccessを書き換えていたが、無効化しても403は続いた → 無関係
  • CloudSecure WP Security:セキュリティプラグインだが、無効化しても403は続いた → 無関係
  • Xserver WAF:XSS・SQL・PHP等の6項目を確認したが、REST APIの権限制御とは無関係

最終確認として、両プラグインを再有効化した状態で get_taxonomies を実行したところ正常に動作しました。環境は最初から正常だったのです。

一番の失敗:Claudeの思い込みに振り回された

今回最大の問題は、Claudeが「wp_health = 接続確認ツール」「403 = 接続失敗」と思い込み、その前提を疑わなかったことです。

その結果、ユーザーは本来まったく不要だった以下の作業をさせられました。

  • プラグインの無効化・再有効化
  • WAFの各項目調査
  • アプリケーションパスワードの再生成
  • Claude Desktopの複数回再起動
  • .htaccessの内容確認

「低権限エンドポイントから順に確認する」という基本的なデバッグ手順を踏んでいれば、これらの作業のほとんどは不要でした。

正しいMCP接続確認の手順

今後の再発防止のために、正しいデバッグ手順をまとめます。

Step 1:低権限エンドポイントで疎通確認

get_taxonomies  ← 認証不要・公開情報。まずここから。

✅ 通る → ネットワーク・サーバーは正常

Step 2:編集者権限エンドポイントで認証確認

get_posts または create_post(下書き)← 認証が必要。

✅ 通る → 認証(アプリケーションパスワード)も正常
❌ 失敗 → パスワードの確認、保存忘れがないか確認

wp_health系は使わない

管理者権限が必要なため、編集者権限の環境では常に403が返ります。接続確認には使用しないこと。

読者・ユーザーへの教訓

MCP連携でトラブルが発生したとき、最初にClaudeに伝えるべき情報があります。

「このサイトのMCPユーザーは編集者権限です。接続確認は get_taxonomies など低権限エンドポイントから順に試してください。wp_health系は使わないでください。」

この一言をセッション冒頭に伝えるだけで、今回のような無駄なデバッグを防ぐことができます。AIは間違った前提で動き続けることがあります。ユーザーが正しい制約条件を最初に伝えることが、AI活用の重要なスキルです。

まとめ

項目内容
真の原因①アプリケーションパスワードの保存ボタン押し忘れ
真の原因②wp_healthは管理者権限が必要(編集者権限では使えない)
Claudeのミス403=接続失敗と思い込み、低権限エンドポイントから試さなかった
無関係だったものWP Fastest Cache・CloudSecure・Xserver WAF・.htaccess
再発防止策接続確認はget_taxonomiesから。セッション冒頭に権限を明示する

MCP連携は非常に便利な仕組みですが、AIの思い込みに振り回されないためには、ユーザー側からの適切な制約条件の提示が重要です。この記録が同じ環境で構築する方の参考になれば幸いです。

コメント

このパターンにはまった場合、初心者はAIに振り回されて数日間を棒に振る可能性があります。最悪の場合、放棄するかもしれません。いあー。まだまだ、MCPはエンジニアレベルの絶賛開発中ツールでしょうかね。 このようなトラブルをサクッと解決できる人しか生き残れないのか?。。。 厳しいな。

関連記事

Google Nest Hub で YouTube ライブが再生できない不具合(2026年3月)— 原因・範囲・対処法


2026年3月28日より、Google Nest Hub / Nest Hub Max で YouTube のライブ配信が正常に再生できない不具合を確認した。同じ症状が多数報告されているようです。本記事では、症状・影響範囲・原因の考察・対処法をまとめます。また、hsBox をご利用の方向けに、復旧まで の代替手段についても案内します。
2026年3月31日午前6時50分時点で復旧していました。対処は何もしていません。追加調査は別途します。

症状

報告されている症状は主に以下の2パターンです。発生タイミングにより段階的に変化しています。

フェーズ症状
フェーズ1(発生初期)同じ1〜3秒の映像がループして繰り返し再生される
フェーズ2(現在)「このコンテンツはご利用いただけません。後でもう一度お試しください」と表示される

影響範囲

この不具合は WNI(ウェザーニュース)固有の問題ではなく、YouTube ライブ全般に影響しています。

コンテンツ状況
WNI(ウェザーニュース)ライブ再生不可
その他の YouTube ライブ配信全般再生不可
YouTube の通常動画(録画済み)正常
スマートフォンでの YouTube ライブ 正常
Nest Hub 以外のデバイスへのキャスト 正常

操作方法(音声操作・スマホからキャスト)による違いはなく、どちらでも同じ症状が発生します。影響を受けるデバイスは Nest Hub / Nest Hub Max など Nest Hub シリーズ全般です。

原因の考察

Google Nest Community への報告によると、「まだファームウェアがアップデートされていない Nest Hub では正常動作している」という証言があります。これはNest Hub の最新ファームウェアと YouTube ライブの配信方式との相性問題である可能性を示しています。

なお、現時点での参考ファームウェアバージョン(Nest Hub Max)は以下の通りです。

  • システムファームウェア:29.20251023.103.2201 ←(2026/3/31GoogleHomeで確認)
  • キャストファームウェア:3.78.508739 ← 同上
  • Fuchsiaバージョン 29.20251023.103.2102100   ←(2026/4/2実機設定で確認)
  • ソフトバージョン 70.94.11.871942728 ← 同上
  • Chromecastファームウェアバージョン 3.78.523914 ← 同上

※追加情報:2026/3/30時点

Chromecast Ultra では発生していない

Google Pixel Tab でも発生を確認。
  ただし、発生はライブをキャストした場合、YouTubeアプリで、
手動でライブを再生する場合は正常に再生できる。

Google はすでにシニアチームにエスカレーションして調査中とのことです。また、2026年1月にも同様の問題が数週間継続した後に自然解消した前例があります。

ファームウェアバージョンの確認方法

お使いの Nest Hub のファームウェアバージョンは以下の手順で確認できます。

Google Home アプリから確認する方法

  1. Google Home アプリを開く
  2. 対象の Nest Hub のタイルを長押し
  3. 右上の歯車アイコン(設定)をタップ
  4. 「デバイス情報」→「技術情報」でバージョンを確認

Nest Hub 本体から確認する方法

  1. 画面を上から下にスワイプ
  2. 歯車アイコン(設定)をタップ
  3. 「デバイス情報」でバージョンを確認

他サイトでの情報

次のサイトで関連する情報が公開されていました。

以下のリンクから、現在進行中の議論や最新のアップデート状況を確認できます。

現時点での対処法

残念ながら、ファクトリーリセット・Wi-Fi 再接続・アプリ再インストールなど、ユーザー側でできる操作では解決しないことが確認されています。Google 側の修正を待つのが現実的な対応です。

  • Google Nest Community のスレッドに「同様の問題あり」と投稿することで、修正の優先度が上がる可能性があります
  • 1月の前例では数週間後に自然解消しています

hsBox への強化提案:復旧までの代替手段

hsBox で WNI ライブや YouTube ライブをテレビ・スマートディスプレイに表示している場合、Google 側の修正が完了するまでの間、以下の代替手段の活用をご検討ください。

  • 別のキャスト先への変更:Chromecast built-in 対応の Android TV / Google TV へのキャストは正常に動作しています。Nest Hub 以外のデバイスが利用可能であれば、そちらへの振り替えが有効です
  • hsBox のメニュー・スケジュール機能で切り替え設定を追加:復旧情報を受け取り次第、元の Nest Hub へのキャストに戻す運用も可能です
  • 復旧の確認方法:Google Nest Community の該当スレッドを定期的に確認するか、本記事の更新をご確認ください

まとめ

今回の不具合は Google Nest Hub と YouTube ライブの組み合わせに特有のバグであり、hsBox 側の実装に問題はありません。Google の修正対応を待ちながら、必要に応じて代替手段を活用してください。

復旧情報が判明次第、本記事を更新します。

参考:hsBox で YouTube ライブをテレビにキャスト(hoscm.com)

関連記事

IT駆使(hsBox1.3活用)、テクノロジー駆使で水濡れ原因を謎解き! メカニズム新説へ?

以前に書いた「映像監視への、漏水状況の追加監視について2026/1/12」の記事で、示した漏水の謎についてほぼ事象を確認できたのでここでまとめておく。

写真の上部の中央やや右よりに、先の記事で書いた「水分検知シート」をテープ状に切って張り付けた。張り付けたのは昨年末で、上の画像の通り1/30にはまだ白色で水濡れは発生していなかった。
 しかし、先日確認したところ、明らかな水濡れが発生したことを確認した。

tape20260319

seat
水検知シート

赤色に変色しているところが、水で濡れたところである。この変色の状況から、いくつかの状況が読み取れる。それについては後で整理することにする。


水濡れ原因の検証・推定

さて、今回水濡れが発生した原因は、先に推定した漏水・吐水だったのだろうか?それを確認するため、水濡れが発生した時間を特定し、そこで何か起こっていたのかを確認しよう。

目視で、水濡れが発生していなかった記憶は、1月末くらいである。そこで、3月以降の画像記録をたどってみた。3月13-14日を除いて3月1日から3月19日まで、欠落なく10分毎の画像キャプチャができているようだ。3月13日13:40から3月14日18:20の間はキャプチャが欠損している。(※キャプチャ失敗に1日程度気が付かなかった。そこで対策としてhsBoxのステータスモニター機能を使うことにした)

3月14日18:30時点の画像では、水濡れが発生していたようである。3月13日13:30時点の画像はカメラが横倒しで対象個所を撮影できていない。遡るとカメラが横倒しになったのは3月13日10:20から10:30の間であった。 そして、3月13日10:20時点画像ですでに水濡れが発生していたと判断できた。どうも、水濡れが発生したのは2月の何処かのようだ。

2/1 ◎ 2/7◎ 2/9◎ 2/10 17:00〇 2/11 8:00× 2/11x 2/12 12:30× 2/15x 3/1×

確認の結果、2/10 17:00と2/11 7:10の間に発生したようだ。

つぎは、2/11 20:00時点の画像である。

yoru
2/11 20:00

この時点で、水濡れはすでに発生しているにもかかわらず、この画像では確認できない。暗視状態(白黒)の画像では、赤外光で撮像するため赤くなっていても暗くうつることはない。つまり、暗がりでは水濡れを検知テープの状態から判別することができないのである。

遡って、暗視画像を確認すると、2/10 5:50時点では撮影範囲内には特に変化は見られなかった。しかし6:00時点で上部に水のシミが映り込み、7:00まで1時間かけてじわじわ広がっていく様子が確認できた。そのシミの範囲と、変色部分の位置は一致しており、このシミが水であったことを確認できた。

2/10 6:00ころの天気が何であったか確認してみよう。気象庁記録では、前日夜から午前10時ころまで雨であった。気温は7度前後、風速は2m/sである。この場所は、上にベランダが張り出しているので雨がかからないので、これまでコンクリート奥から漏れ出てきたと推定していた。しかし、他の仮説も立てる必要があるかもしれない。

また、画像:tape20260319 これは、2/11時点の濡れ状態から、さらに1回ほど濡れが追加されているように見える。
 その1つは、小さな霧状の水滴がついたように見えることによる。この小さな点は、上から貼り付けたメンディングテープの部分には発生しておらず。霧吹きのように振りかけられたように見える。上と同様に、発生した日時と、その時の天候を確認した。

3/16◎ 3/17◎ 3/18◎ 3/19×

こちらも夜間に発生したようだ。3/18 17:00から3/19 7:00の間で、細かい赤い点が発生し、メンディングテープの位置がくっきりと見えるようになっている。
この日も3/18から3/19にかけて雨が降っており気温は11℃程度、風速は3m/sちょっとだった。2/11とは風向きが逆で吹き込んでくる方向だった。霧雨状の水滴がついたと考える。

この状況から、一見濡れなさそうなこの面も雨の降り方と風速と風向きしだいで濡れることがあることが確認できた。

水濡れの原因調査は、水検知シート+hsBoxで

水検知シートだけだと濡れたことを確認できただろうが、いつ濡れたか、その原因の特定までは難しかったかもしれない。定点観測的に監視カメラでキャプチャし続けたことで、濡れたタイミングを特定して、ほぼ確実な原因を推定できた。

▼新説:構築 → 次の分析へ

残念ながら新たに確認できたのは、一見濡れないと思われた場所も状況によっては濡れる可能性があることが示されたことにとどまる。新しい仮説を組み立てるほどの状況にはない。とにかく、今年の秋から冬にかけては雨が少なかった。これが、今回の調査が進まなかった、つまり問題事象が発生しにくかったことに効いているかもしれない。


関連記事

なぜ壁は膨らんだのか?IT駆使で迫るコンクリート劣化の原因調査 ~2から6週間分 中間まとめ ~

昨年12月に本格着手して、さまざまな角度でITを駆使しながら進めてきています。以下は、ここまでに確認できた結果の要点の書き出してまとめます。 当初計画した調査環境の整備が整ってから2週間ほどしか経っていませんが、当初の仮説とは少し異なる新たな仮説を立てています。

ATOMCAM2撮影、画像キャプチャ(コンクリート劣化)


カメラでの定点観測は2025/12/23より運用開始: 上のとおり、キャプチャ開始時点から、後述のAEセンサー、温度センサー(熱電対)を追加しています。また、上右よりの2本のテープ状のものは水濡れ検知シールです。水に濡れると下の写真のように赤色に変わり乾いても赤のままなので、水が垂れてきたことがあったかどうか分かります。今のところ、水は出てきていません。同様に熱電対を入れた塩ビ管内にも。このシールを入れたので、壁の内側で結露が発生したかどうかを判別できるでしょう。

mizu
水検知シール

MCR-4TCでの温度測定

温度測定
温度測定

今のところ気温が一瞬0℃になりましたが、コンクリート裏はそこまでは下がっていません。気温が下がってコンクリート内の温度が連動するところもあれば、連動しないところもあります。単純に外気温だけがコンクリート裏側の温度に効いているわけではないようです。

 また、場所によって外気温の影響が異なるように見えます。

AE測定

[ EEPROM Data Analysis Report ]
Type | Date Time (UTC/Local) | Millis (raw) | Details
--------------------------------------------------------------------------------
SYNC | 2026-01-14 13:25:51 | 325120 | Time Synchronized (Unix:1768364751)
DATA | 2026-01-14 14:25:45 | 3919360 | CH0:0, CH1:19, CH2:0, CH3:0
DATA | 2026-01-15 06:45:30 | 62704128 | CH0:0, CH1:8, CH2:0, CH3:0
DATA | 2026-01-16 00:26:07 | 126341632 | CH0:0, CH1:8, CH2:0, CH3:1
DATA | 2026-01-16 06:11:56 | 147090432 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-01-16 07:11:10 | 150644736 | CH0:0, CH1:0, CH2:3, CH3:7
DATA | 2026-01-16 10:10:08 | 161382912 | CH0:0, CH1:16, CH2:0, CH3:0
DATA | 2026-01-16 10:16:08 | 161742848 | CH0:0, CH1:7, CH2:0, CH3:0
DATA | 2026-01-16 10:57:17 | 164211968 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-01-16 12:33:41 | 169995520 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-01-16 12:47:02 | 170796544 | CH0:0, CH1:7, CH2:0, CH3:0
DATA | 2026-01-17 16:21:30 | 270064640 | CH0:0, CH1:11, CH2:1, CH3:1
DATA | 2026-01-18 01:01:31 | 301265664 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-01-18 05:01:11 | 315645696 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-01-18 12:22:00 | 342094336 | CH0:0, CH1:1, CH2:6, CH3:6
DATA | 2026-01-19 00:38:54 | 386308608 | CH0:0, CH1:45, CH2:0, CH3:0
DATA | 2026-01-19 06:01:51 | 405686016 | CH0:0, CH1:8, CH2:0, CH3:0
DATA | 2026-01-20 12:54:55 | 516869376 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-01-20 18:41:19 | 537653504 | CH0:0, CH1:7, CH2:0, CH3:0
DATA | 2026-01-22 01:14:26 | 647640576 | CH0:0, CH1:7, CH2:0, CH3:3
DATA | 2026-01-25 12:50:54 | 948628992 | CH0:0, CH1:9, CH2:0, CH3:2
DATA | 2026-01-29 15:48:20 | 1304874752 | CH0:0, CH1:23, CH2:3, CH3:4
RSET | 2026-01-30 12:55:41 | 0 | System Boot / Reset Detected
SYNC | 2026-01-30 12:58:24 | 162304 | Time Synchronized (Unix:1769745504)
--------------------------------------------------------------------------------
Analysis Finished.

顕著なAE信号検出はなさそうで、たまに何かを検出してはいますが、ほとんど発生していないようです。1/16がちょっと多い感じがしますが、今のところ顕著な問題は起きていなさそうです。

コンクリート壁穿孔工事関連

熱電対を設置した状況からそれぞれの場所ごとにコンクリート壁と、壁内の土の間に隙間があり、場所によってその隙間が、約5mmから約48mmと大きなばらつきがあるように見えます。

中間まとめ 

 今のところ、新たに見えた事象は、コンクリート裏に隙間があるようにみえるということです。その隙間と、コンクリート奥の温度に関連性があるように見えます。つまり、隙間が大きいほど、外気温が下がっても温度が下がりにくそうということです。

 それとは別に隙間に関係なく、タイミングによってどの面の温度が低くなるのかが変わりそうです。

温度測定が終わる4月頃に、熱電対をとおした塩ビパイプを取り出して、内視鏡カメラで壁の裏側の隙間の状態を調査しようと考えています。

今年はほとんど雨降っておらず、乾ききっている感じなので問題事象は発生しにくそうです。

新たな仮説

これまでの仮説はすべての面が均等にアイスレンズが成長するように考えていましたが、片面だけ発生するケースもありそうな感触です。つまり、東面と南面で交互に発生し隙間が広がったり、逆に押されてほとんどなくなったりすることが繰り返されたのかもしれません。

さらにここまでの仮説で将来発生することが予想されていた西面北寄りでの事象発生ですが、下の写真のように新たに発生していることを確認しました。

crack
ひび割れ

ここまでの仮説を補強する材料と言ってよいでしょう。 

関連記事

ATOM CAM2のカメラ画像キャプチャをルーター越えの別セグメントからhsBox1.3でトライ

ルーターの向こう側にあるATOM CAM2の画像をキャプチャしたかったのですが、これまでツールではできていませんでした。今回トライした結果を考慮して、以前に公開したツールの今後の強化項目にしていきます。

cam
cam

どうやるか、これまでの課題も踏まえて、検討してみましょう。
スマホで、rtspでのアクセスURLを確認できるので、これにアクセスできるように環境を整えてみます。

方法1 ルーティングでATOMCAM2にアクセスできるようにする

hsBoxや PC側の設定(ルーティング設定)で、ATOM CAM2に向けてつなげ、ルーターで対象のパケットを通すように許可する。
※hsBox1.3にはシステム設定に「ルーティング設定」機能があり、ルーティングの制御支援機能があるので、これを利用できます。

確認したルーターには。指定したパケットを許可する機能がなく、この方法での動作確認はできていません。
このパターンの場合、ツールの強化ポイントはIP指定できるようにすることです。
また、ルーターのDHCPでの割り当てIP固定化機能もあったほうがよいですね。

方法2 ルーターのDMZ機能を利用してアクセスできるようにする

確認したルーターには。DMZ指定する機能はありますが、1つのIPしか指定できませんでした。すでにスマートスピーカにこのIPを割り当て済みだったので、この方法での動作確認はできていません。
このパターンの場合、ツールの強化ポイントはIP指定できるようにすることも挙げられますが、MACアドレスにルータのMACを指定すれば既存実装でも操作するはずです。

方法3 ルーターのポートオープン機能を使ってアクセスできるようにする

確認したルーターにはこの機能があったので、試してみました。
暫定的に既存のツールを、指定したIPの画像キャプチャーをするように改造して動作確認してみました。IPにルーターのIPを指定することで、難なく画像キャプチャーに成功しました。

複数のATOM CAM2がこのルーターの向こう側にある場合は、ポート番号が被らないように調整する必要が出てくるので、IP指定に加えてポート番号指定機能もあったほうが良いですね。ただ、IP指定を IP:PORTの形式で指定できるように拡張しするだけで対応できるでしょう。
また、ルーターのDHCPでの割り当てIP固定化機能もあったほうがよいですね。

関連記事

温度測定点設置壁裏の温度測定準備完了。見えてきた「隙間」を内視鏡カメラ「YPC99」でどう捉えるか?

これまでにコンクリート劣化の原因調査に関して様々な調査の準備をしてきましたが、2026/1/14、1/21にコンクリート壁への穿孔と温度測定定点設置を行い最終的な調査準備が完了しました。

コンクリート壁の3面に穴をあけ壁の裏側の土の温度を測定できるように熱電対を設置しました。設置後の外観は次の通り。

東面

南面

西面

塩ビ管を奥まで通して、先端にわずかに出した熱電対の先が、その先の土にあたるように設置しています。ぱっと見で、塩ビ管の出方に違いがあることが分かるでしょう。それぞれの準備した塩ビ管の長さと出っ張り具合から、それぞれの場所でコンクリート壁の内側での塩ビ管の出っ張り具合を検討してみました。壁の厚みは設計値では未確認ですが270mmとされています。

場所塩ビ管長さ
切断時測定
それぞれの管の出っ張り長壁裏突出長(推定値)
東側約350mm
32mm
約48mm
南側約350mm
60mm
約20mm
西側約300mm
25mm
約5mm

推定ですが、少なくとも東面については、コンクリート壁内面と、土の間にはある程度の隙間がありそうです。 熱電対設置前に事前確認しておけばよかったのですが、温度測定観測が終了した後に調査してみましょう。 以前に別の調査のために用意した内視鏡カメラYPC99があるので、これで確認することにします。

YPC99
YPC99 内視鏡カメラ

カメラの先は100mmくらい棒状で自由度は低いのですが、線の長さを合わせると450mmほどはあるので、コンクリート壁の穴を通して、隙間の具合がどんな感じなのかは見ることができると思います。

関連記事

hsBoxで、ATOM Cam 2の映像をキャプチャで発生した問題と課題と対処策について

約1か月連続キャプチャできていましたが、キャプチャできなくなる事象が発生したのでその原因調査と対策をしていきます。そして恒久対策に向けた対策案も検討して、以前に公開したツールの今後の強化項目にしていきます。

cam
cam

調査 その1

まず、状況整理ですが、キャプチャは、1回のcron起動で、3つのATOM CAM2を順にキャプチャしてファイル保存するように実装していました。一番最初にキャプチャするカメラ画像は10:00にキャプチャしたものが最後で、そのほかの2つは、14:40が最後でした。つまり、1つ目のキャプチャに失敗しても2つめ以降のキャプチャはできていましたが、その後3つともキャプチャできなくなっています。運用点検のため、hsBoxを再起動したタイミングあたりでキャプチャできなくなっていたようです。
 まずは、切り分けしていくためウォークスルー方式で問題となりそうなところを順にチェックしていきます。まずは、NASのマウント状況を確認しました。マウントはできており問題ありませんでした。
次に、ATOM CAM2のIP探索の確認です。 スマホでATOM CAM2のIPを確認して、そのIPが取れているかを、arpコマンドで確認します。 すると、3台のカメラともにMACが取れていないことが判明した。

暫定対処 その1

それぞれの、IPにpingを打ってみます。 それぞれ、反応がありMACがとれました。これにより、14:40が最後だった2台のカメラのキャプチャが復旧しました。
 残りの1台は、NAS上へのフォルダ作成には成功したものの、画像ファイルがまだ置かれていない状況になっています。

根本対策 その1

 今後の強化策です。 既存実装でもブロードキャストでpingを打つ実装を入れていますが、ブロードキャストではarpに反映されないのが問題のようです。そこで、MACが取れなかったとき、DHCPで割り振られる範囲に対して明示的に個別にpingを打つ実装を追加することにします。

調査 その2

まだ復旧できていない1台分のカメラについて調査を行います。

実装を、最後にキャプチャできたタイミングで何かあったかを確認してみましたが、特に問題はないようです。手動で、FFMPEGコマンドを実行すると、次の結果が返ってきました。

> python3 .\cap_once.py
FFmpeg failed: Command '['ffmpeg', '-rtsp_transport', 'tcp', '-i', 'rtsp://**:***@192.168.*.*/live', '-ss', '00:00:01', '-vframes', '1', '-q:v', '2', '-y', '\\\\192.168.*.*\\***\\2026-01-25\\20260125_124510.jpg']' timed out after 20 seconds

タイムアウトしていますが、pingは通っている。 前のセッションが残っていて接続待ちの状態になっている?のかという説はあるが、 スマホからの確認では動作している。 スマホでの画像表示と、rtspは別動作なので、rtsp側だけの問題(セッション残留?)の可能性がある。

暫定対処 その2

セッション残留の問題だと仮定して、rtspの再起動での復旧を試みる。スマホでの操作で一度「PCで再生」をオフにして再起動してみる。
 この操作を行うとrtsp用のユーザとパスワードが更新された。新たなユーザとパスワードを反映すると、キャプチャに成功し、 自動キャプチャは復旧した。

問題の原因は、残留セッションとみてよいようだ。 これは、ATOM CAM2側で何とかしてほしいが、 録画の都合(解像度の高い録画をしたい)から古いバージョンのファームウェアを使用している。このため最新パッチを適用することができず、ATOM CAM2側での”残留セッション”の改善は望めない。そこで、hsBox側での別の改善策を取ることにする。

その2の問題の 改善策案

”残留セッション”問題の対処方針は、上の”暫定対処”の問題を早期検知し、できるだけ手間をかけずに復旧できるようにするというものである。

 復旧手順を明記した内容での問題検知通知を出し、スマホ操作で「PCで再生」を再起動し、あらたなユーザ名・パスワードをGUI設定画面で更新するというものである。
とりあえず今時点での簡便な復旧策はこの辺でしょう。

他に良い案があれば、コメント投稿をお願いします。


関連記事

https://mic.or.jp/info/2026/01/30/cam-4/

hsBox1.3で、太陽光発電機器故障を検知して通知してみよう

2025年12月22日で太陽光発電 通知メールがなくなる件。 代替として自前で収集した情報をLINEに通知してみた」をさらに高度化を検討してみた。
 過去の実装(太陽光発電システムの故障判断アルゴリズム(その1))で、故障検知を高精度(6年間で5回検知・誤検知なし。1件はパワコンブレーカーダウン、4件はデータアップロードネットワークのダウン)で実装できていましたが、さきのソーラーフロンティアのサービス終了でこの検知システムが使えなくなりました。そこで、新たな検知システムの実装を、先に公開してシステムを強化して、検討してみます。

 ちなみに、公開済みの発電量収集代替実装では、従来のソーラーフロンティアの発電量との誤差は±2%程度なので、3か所ともに発電量収集代替実装を導入して、既存の検知システムにデータを流し込めば高精度での判定を継続できるようになります。しかし、通常、太陽光発電システムを複数保有しているほぼないので、この方式はほぼ使えません。そこで、ここでは1システムだけであっても判定することができる仕組みを検討してみます。

SolarAlert_
太陽光発電システム 故障通知

故障検知実現の設計方針

最終的には、人が判断するが、できるだけ判定精度を上げたい。過去の高精度判定システム構築での知見を反映して設計する。ポイントは次の通り。
・快晴時の発電量は安定しており、きれいなカーブを描く。
   →判定はこの部分のデータを使う。
・雲がある晴れの日のデータは変化が激しい。
・発電量の小さい日の発電量のばらつきが大きい。
   →判定には使用せず、参考値として通知する。
・四季の変化での発電量の補正が必要
→過去実装では、実績のピークデータをもとに関数化して組み込み
想定発電量と比較し、判定するかどうかを切り分けした。
・外部情報として最も近い気象庁観測点のデータを使用する。
・太陽光パネルの様々な設置場所ごとの違いによる想定発電量を単純な計算式ではなく学習方式を採用する。

使用するデータは、以前に公開したParquet形式で保存したものとする。

実装例 


import pandas as pd
import numpy as np
from datetime import datetime, timedelta
import os
import sys
import argparse
import requests
from bs4 import BeautifulSoup

# ==================== 設定エリア ====================
NAS_PATH = r"/mnt/nas/PowerData" #★
MODEL_PATH = os.path.join(NAS_PATH, "learning_model.parquet") # 学習データ保存先
IFTTT_WEBHOOK_URL0 = "https://maker.ifttt.com/trigger/{event}/with/key/{your_key}"
IFTTT_EVENT_NAME = "message_to_myline" #★
your_key = "************" #★
IFTTT_WEBHOOK_URL = IFTTT_WEBHOOK_URL0.replace("{your_key}", your_key)

# 判定しきい値 (期待値の50%以下が2時間続いたら故障疑いなど)
THRESHOLD_RATIO = 0.5 #★
# ====================================================

def send_line_message(title: str, body: str, timestamp: str = "-"):
payload = {"value1": title, "value2": body, "value3": timestamp}
url = IFTTT_WEBHOOK_URL.replace("{event}", IFTTT_EVENT_NAME)
try:
response = requests.post(url, json=payload, timeout=10)
return response.status_code == 200
except Exception as e:
print(f"LINE通知失敗: {e}")
return False

def get_jma_sunshine_hourly(target_date: datetime):
"""気象庁HPから10分ごとの日照時間を取得し1時間単位(0.0-1.0)で返す"""
url = (f"https://www.data.jma.go.jp/stats/etrn/view/10min_s1.php?"
f"prec_no=**&block_no=****&year={target_date.year}&month={target_date.month}&day={target_date.day}&view=p2") #★
try:
res = requests.get(url, timeout=10)
res.encoding = res.apparent_encoding
soup = BeautifulSoup(res.text, 'html.parser')
rows = soup.find_all('tr', class_='mtx')
sunshine_10min = []
for row in rows:
cols = row.find_all('td')
if len(cols) > 10:
val = cols[9].text.strip() # 日照時間の列
sunshine_10min.append(float(val) if val else 0.0)
# 1時間(6個)ごとに合計(最大1.0)
return [sum(sunshine_10min[i:i+6]) for i in range(0, len(sunshine_10min), 6)]
except Exception as e:
print(f"気象庁データ取得失敗: {e}")
return [None] * 24

def update_learning_model(target_date: datetime, hourly_actual: list, hourly_sun: list):
"""日照が良い時のデータを『快晴時の正解』として学習モデルを更新"""
month = target_date.month
try:
if os.path.exists(MODEL_PATH):
model_df = pd.read_parquet(MODEL_PATH)
else:
# 初期モデル: 全月0で作成
model_df = pd.DataFrame(0.0, index=range(1, 13), columns=[f"h_{i}" for i in range(24)])

updated = False
for h in range(7, 18): # 発電時間帯のみ
# 日照率が0.9以上かつ、これまでの学習値より高い(または初データ)場合に更新
if hourly_sun[h] and hourly_sun[h] >= 0.9:
current_val = model_df.loc[month, f"h_{h}"]
if hourly_actual[h] > current_val:
model_df.loc[month, f"h_{h}"] = hourly_actual[h]
updated = True

if updated:
model_df.to_parquet(MODEL_PATH)
print("学習モデルを更新しました。")
except Exception as e:
print(f"学習モデル更新失敗: {e}")

def load_day_data(target_date: datetime) -> pd.DataFrame:
date_str = target_date.strftime("%Y%m%d")
file_path = fr"{NAS_PATH}/power_{date_str}.parquet"
if not os.path.exists(file_path):
raise FileNotFoundError(f"データが見つかりません: {file_path}")
return pd.read_parquet(file_path)

def main():
parser = argparse.ArgumentParser()
parser.add_argument("--da", type=int, default=0)
args = parser.parse_args()

base_date = datetime.now() + timedelta(days=args.da)
date_label = base_date.strftime("%Y/%m/%d")

try:
df = load_day_data(base_date)
# 1時間ごとの発電量(value1)リスト作成
df['hour'] = pd.to_datetime(df['timestamp']).dt.hour # timestamp列があると想定
hourly_actual = df.groupby('hour')['value1'].mean().reindex(range(24), fill_value=0.0).tolist()
except Exception as e:
print(f"データ読み込みエラー: {e}")
return

# 気象庁データ取得
hourly_sun = get_jma_sunshine_hourly(base_date)

# 学習モデルの更新
update_learning_model(base_date, hourly_actual, hourly_sun)

# 故障検知
is_anomaly = False
anomaly_details = []
if os.path.exists(MODEL_PATH):
model_df = pd.read_parquet(MODEL_PATH)
month = base_date.month

for h in range(8, 17): # 影の影響が少ない時間帯を重点チェック
sun = hourly_sun[h]
if sun and sun > 0.3: # ある程度の日照がある場合
expected = model_df.loc[month, f"h_{h}"] * sun
actual = hourly_actual[h]
if actual < expected * THRESHOLD_RATIO:
is_anomaly = True
anomaly_details.append(f"{h}時(実測{actual:.1f}kW/期待{expected:.1f}kW)")

# メッセージ作成
total_gen = sum(hourly_actual) * (10/60) # 10分データの場合の概算
status_msg = "✅ 正常" if not is_anomaly else "⚠️ 故障の疑い"

message = f"⚡️ {date_label} 発電実績 ({status_msg})\n" \
f"総発電量:{total_gen:.2f} kWh\n"

if is_anomaly:
message += "\n【異常検知】\n" + "\n".join(anomaly_details)
send_line_message("太陽光発電アラート", message, "ALERT")
else:
send_line_message("太陽光発電データ", message, "OK")

print(message)

if __name__ == "__main__":
main()

上の実装は、あくまでもサンプルです。 特に”★”印のある行は環境に合わせて修正してください。

このコードで検証していますが、かなり過敏で誤検知が多いです。
閾値調整で、精度を上げることになると思いますが、過去実装での故障判定ロジックを超える精度にはならなさそうです。 誤検知をゼロにするには、十分に学習させたうえで、1日中快晴だった日のデータでのみで判定する必要がありそうです。

他に改善案などあればコメントをお願いします。

関連記事