Ubuntu26やPHP8.5への移行で検出した問題とその対処方法(PHP8 hash仕様変化、ID関連セキュリティ強化)

かなり多くのセキュリティ的な変更が行われている。これに関連して、簡単に原因(変更ポイント)を確認でき、対処できたものはおいておいて、ここでは解決に時間を要したものについて書いていこう。
※移行はまだ完了していないので、随時追加更新していきます

hashのデフォルト動作変更、php内の内部処理、仕様の変更

軽く受け流せば、すぐに解決出る問題かもしれないが、対処の過程でGPTの修正案がセキュリティ脆弱性を引き起こすものだったので、参考のために書いておく。
GPTは安易に、セキュリティ対策実装をもっともらしい理由をつけて消す。それで、何とか動くケースだったらもしかしたら見逃していたかもしれないが、その修正では動かなかった。じっくりコードを見直したところ、除去してはいけないセキュリティ対策実装であったというものだ。 別な対処方法で解決できた。
 直接原因は、hash値に使用される文字の種類が拡張されたことです。詳細についてはセキュリティにまつわる話なので非公開とします。このようにセキュリティ関係の情報は非公開であることが多いのか、GPTも弱いようです。脆弱性の検出に使うのはよいとしても、セキュリティ確保には十分ではないというか、セキュリティ周りの実装は丸投げするのは危険だろう。

ブラウザ経由の PHP exec()「Failed to get boot ID」が出る 

実装修正で、比較的簡単に回避はできたが、これが発生する原因特定には時間を要している。

# systemctl cat apache2.service
# /usr/lib/systemd/system/apache2.service
[Unit]
Description=The Apache HTTP Server
After=network.target remote-fs.target nss-lookup.target
Documentation=https://httpd.apache.org/docs/2.4/

[Service]
Type=notify
Environment=APACHE_STARTED_BY_SYSTEMD=true
ExecStart=/usr/sbin/apachectl start
ExecStop=/usr/sbin/apachectl graceful-stop
ExecReload=/usr/sbin/apachectl graceful
# Send SIGWINCH for graceful stop
KillSignal=SIGWINCH
KillMode=mixed
PrivateTmp=true
Restart=on-abnormal
OOMPolicy=continue
RemoveIPC=yes

DevicePolicy=closed
KeyringMode=private
LockPersonality=yes
MemoryDenyWriteExecute=yes
PrivateDevices=yes
ProtectClock=yes
ProtectControlGroups=yes
ProtectHome=read-only
ProtectHostname=yes
ProtectKernelLogs=yes
ProtectKernelModules=yes


# systemctl show apache2.service | grep -E 'ProtectProc|ProcSubset|ProtectKernelTunables|ProtectKernelModules|RestrictNamespaces|ProtectSystem|ProtectHome|ReadOnlyPaths|InaccessiblePaths|PrivateTmp|RestrictAddressFamilies'
InaccessiblePaths=/boot /root -/etc/sudoers -/etc/sudoers.d -/etc/ssh -/etc/apt -/etc/.git -/etc/.svn
PrivateTmp=no
PrivateTmpEx=no
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectHome=read-only
ProtectSystem=full
RestrictNamespaces=yes
ProtectProc=invisible
ProcSubset=pid

ProcSubset=pid これが設定されていると、プロセスから見える /proc が自分のPID関連だけに絞られ、/proc/sys/ 配下がまるごと見えなくなりますsystemctl status は内部で /proc/sys/kernel/random/boot_id を読もうとするので、Apache配下のPHPから実行したときだけ「Failed to get boot ID: No such file or directory」が出ていた、というわけです。

対処方法
いろいろな対処方法がありますが、
statusのかわりに showを使うように見直しました。
具体的には次のよう感じです

修正前
$command = "systemctl status NetworkManager.service 2>&1";

変更後
$command = "systemctl show NetworkManager.service -p ActiveState,SubState,ActiveEnterTimestamp 2>&1";

クロードに全工程の開発を任せて見えてきたもの。 2026春時点のAIでの開発の光と壁

— freeBox Loader開発を通じた、個人開発者・小規模チームのための実践的考察 —

2026年春現在、AIを開発パートナーとして「仕様書作成・設計・コーディング・テスト計画・FT実施・引き継ぎまでほぼ全工程」を任せる試みが、現実的に可能になりつつある。私はfreeBox LoaderというOSSプロジェクトで、まさにそのアプローチを徹底的に試した。本稿は、さきの「2026年春版 AIビジネス戦略」記事を横断的に振り返りながら、「横から観察した結果」を基にまとめたものだ。個人開発者や小規模チームがAIを最大限活用するための、光(可能性)と壁(制約)を5:5のバランスで整理する。

背景:freeBox Loaderとは何か、そしてなぜAIに全工程を任せたか

freeBox Loaderは、USB起動のLive環境「hsBox」上で誰でもプラグインを追加・管理できる実行基盤だ。GitHubのindex.jsonを参照し、WebUI経由でモジュールのインストール・運用を行うコア部分と、サンプルプラグイン(例:ATOMCAM2監視カメラ連携)で構成される。当初の計画は、Claudeを「コーディング支援ツール」として使う程度だった。しかし開発規模と複雑度を考慮し、仕様策定から最終引き継ぎまでをClaude主導で進める実験にシフトした。環境は主にClaude-Desktopを使い、セッション消費の監視をClaude.aiで並行。ごく一部でClaude Codeにプロンプトを流し、MCP(Model Context Protocol)の違いを活かしながら作業を進めた。この「ほぼ全工程委託」は、2026年春のAI環境では十分に現実的だった。ただし、そこには明確な光と壁が共存していた。

どう任せたか — 開発プロセスの実際

開発プロセスは、V型モデルを基調にAIと人間が並走する形とした。

  1. 仕様書作成・設計フェーズ:Claudeに全体要件を投げ、機能仕様書・API仕様書・UIモック仕様書を生成させた。人間側は整合性チェックと意思決定のみ。
  2. コーディングフェーズ:Step分割で実装を進め、各ファイル生成後に即時レビュー。
  3. テスト計画・FT実施:テスト計画書作成から内部テスト、本番統合テストまでClaudeが主導。一部はClaude in ChromeによるGUIの自動テストも行った。
  4. 引き継ぎ:セッション終了前に「次担当者(次のAI or 人間)がゼロから再開できる」レベルのメモを義務化。

この流れは、さきの記事で指摘される「AIを“人と同じように扱う”設計」を体現したものだ。AIに「スキル(役割・手順)」を与え、MCPで操作範囲を定義し、「かね(セッション)」という制約を意識した運用である。
結果として、人間の作業時間は大幅に圧縮された。特に設計ドキュメントの量産とコードの初稿生成速度は、人間単独では到底及ばないレベルだった。

見えてきた「光」 — 効果的だった点(可能性)

AI全工程委託の最大の強みは、以下の3点に集約される。
1. 速度と一貫性の劇的向上
仕様書からコード生成までのサイクルが極めて速い。複数ドキュメント間の矛盾を早期に検知できた点も大きい。人間が「設計の意思決定」に集中できるため、全体品質が安定しやすい。
2. 「スキル付与」による役割化のしやすさ
さき記事の言葉を借りれば、AIに「採用担当ペルソナ」や「参謀ペルソナ」を与えるのと同じく、「freeBox Loader開発スペシャリスト」としてスキル(ワークフロー・MCP設定)を付与することで、AIは「1人の優秀な開発者」として機能した。特にClaude-DesktopとClaude.aiの使い分けは、MCP差異を活かした実践的工夫となった。
3. 未来志向の開発スタイルの実現
小規模チームや個人でも、大規模プロジェクト並みのドキュメント品質とテスト網羅性を維持できる。2026年現在、これは「個人が戦える」ための大きな光だ。将来的には、AIが複数の役割(PM・エンジニア・テスター)を同時に担う「AI組織」構築の基盤になると感じる。

見えてきた「壁」 — 問題・課題となった部分(制約)


一方で、限界も鮮明になった。特に最終工程で顕在化した。
1. セッション(かね)の制約と記憶の非連続性
AIには「勤務時間」があり、セッションが尽きると記憶がリセットされる。最終フェーズで細かい問題が多発した際、多量のセッション消費が発生し、大幅な遅延を招いた。引き継ぎメモの運用も完全ではなく、「書く前にセッション終了」による記録欠落リスクが現実化した。そして、それはその後のバグの要因や根本原因となり、AIは何度も同じ間違いを繰り返した。
2. 暗黙の境界線と除外範囲の盲点
テスト計画で「本体テストは進んでいる → システムテストも大丈夫」とAIが判断する一方、サンプルモジュール側の準備が手薄になる「暗黙の境界線」が発生した。AIは与えられた範囲を忠実にこなすが、「含まれないもの」を人間が明示的に定義しない限り、自動で補完しない。これは「人と同じように扱う」からこそ生じる壁だ。想像になってしまうが、現状のAIは近視眼である。1つのセッション内で保持できる記憶量が小さく、参照しているドキュメントの範囲が非常に狭い。高度な実装時術を生かせるのは500ライン程度が限界なのではないだろうか。それ以上の情報は探しながら進めるので目的の場所を見つけたころには1セッションの限界に到達してしまう。そして、AI任せにしていると同じどころをギッタンバッコン更新しまくる事態さえ発生する。
 このような事態にならないようにするには、怪しい動きをしているのを見かけたら、途中で割り込んででも処理を止めたほうが良いことさえある。再発を防ぐためにルールをスキルに追加して防ぐことを試みるが、そのルールが肥大化して、最後にはAIはそのルールをしっかり読まないまま作業に着手する始末である。呼んでいなさそうなところ見つけて再度読むように指示すると読むが、その作業でさえセッションを消費してしまう。整理され冗長性が少なくシンプルで完璧なルールを整備できれば改善できるだろうが、その壁はなかなか高そうである。
3. 最終整合性判断と微調整の負担
生成コードの初稿品質は高いが、環境依存の問題や細かいエッジケースの調整は、人間側の負担が残る。2026年春時点では、AIは「優秀な部下」ではあるが、まだ「完全自律」ではない。特に最終工程(5月上旬)では、これらの壁が重なり、リリースが当初想定より後ろ倒しとなった。

まとめと2026年以降への展望

freeBox Loader開発を通じて見えたのは、AIを「設計し、任せる」時代の本質である。光:個人・小規模チームでも、従来の何倍もの速度と品質で開発を進められる可能性。
壁:セッション制約、記憶の非連続性、暗黙知の扱いという、人間同士の協働とは異なる制約。さきの記事が言うように、AIは「設計すれば人になる」。しかしその設計には、「人と同じように扱う」ための運用ルール(早めの記録分散化、除外範囲の明記、ゼロ知識検証など)が不可欠だ。現在(2026年5月5日時点)、最終調整を終え、まもなくリリースアナウンスする運びとなった。遅延はあったが、そこから得た学びは本プロジェクトの価値を高めている。これからのAI開発は、「どれだけ上手にAIに権限を渡せるか」が鍵になる。個人開発者・小規模チームこそ、この「光と壁」を理解し、AIを真のパートナーとして設計するスキルが、競争力の源泉となるだろう。freeBox Loaderの今後に興味がある方、または同様のAI協働開発を進めている方は、ぜひhsBoxサイトやGitHubで情報共有・コラボをお待ちしています。


関連記事

運命を分ける“0.数ミリ?の誤差”!コンクリートの寿命を左右する「初期不整」とアーチ効果の真実

前回の記事では、コンクリートの片面が土に接し、もう片面が乾燥することで生じる「湿度差による反りの拘束」が、ひび割れの真の原因であるという仮説を解説しました。 しかし、現場のデータ(IoTによる長期モニタリング)をさらに深く解析していくと、同じような環境・同じような施工であっても、「劣化が激しく進む壁」と「長期間健全な壁」が存在することに気づきます。 この違いは一体どこから生まれるのでしょうか? その鍵を握るのは、私たちの目には「まっすぐな平面」に見える壁に隠された、施工時の**「ほんの数ミリの微小な膨らみ(初期不整)」**の向きでした。今回は、IoTデータから導き出された、コンクリート劣化のさらなる深層に迫ります。

1. 構造物は「完全な平面」ではないという前提

設計図の上では、コンクリートの壁は直線で描かれます。しかし、実際の施工現場では、型枠のわずかなたわみ、コンクリートを流し込む際の圧力、硬化時の収縮などにより、ミリ単位の誤差が必ず発生します。 これを構造力学の世界では「初期不整(しょきふせい)」と呼びます。

肉眼では完璧な平面に見えても、高精度のレーザー測定やIoTセンサーで壁の表面をスキャンすると、わずかに「外側(空気側)」に膨らんでいる箇所と、「内側(土側)」に凹んでいる箇所があることがわかります。実は、この**「初期状態でどちらに歪んでいるか」**が、その後の数十年の寿命を決定づけているのです。


2. 運命を分ける2つのパターン:外反り vs 内反り

湿度差による内部応力(表面は縮みたい、裏面は膨らみたい)と、土からの圧力(土圧)がかかった時、この「初期の数ミリの膨らみ」がどのようなドラマを生むのか、2つのパターンで見ていきましょう。

コンクリートの初期状態と劣化
コンクリートの初期状態と劣化

パターンA:ごく微小に「外側(空気側)」に膨らんでいる場合(劣化加速モード)

最初から空気に触れる表面側に向かってわずかに膨らんでいる(弓なりになっている)壁は、非常に危険な状態にあります。

  • 力の相乗効果: 土圧が壁を外側に押し出そうとする力と、湿度差による「外側に反ろうとする力」が同じ方向に向かいます。
  • 偏心による曲げモーメントの増大: すでに外に膨らんでいるため、土の重みがかかると、その膨らみをさらに押し広げるような強い力(曲げモーメント)が働きます。
  • 結果: 乾燥して縮もうとしている表面(引張に弱い部分)に、さらに引き延ばされる巨大な引張応力が集中し、早期に致命的なひび割れが発生します。

パターンB:ごく微小に「内側(土側)」に膨らんでいる場合(劣化抑制・アーチダム効果)

一方、最初から土がある方向に向かってわずかに膨らんでいる(または凹んでいる)壁は、驚くべき耐久性を発揮します。これは**「アーチダム」と同じ原理**が働くためです。

  • 圧縮力の活用: 土圧が壁を押す力は、弓なりになったコンクリートを「押しつぶす」方向(圧縮応力)に変換されます。
  • コンクリートの長所: コンクリートは引っ張られる力には弱いですが、「押しつぶされる力(圧縮)」には無類の強さを誇ります。
  • 結果: 湿度差によって表面が乾燥収縮し、ひび割れ(引張応力)が起きようとしても、土圧による「圧縮力」がそれを相殺(キャンセル)してくれます。結果として、ひび割れは発生せず、健全な状態が長期にわたって維持されます。

3. 「湿度差」×「土圧」×「初期変位」のトライアングル

これまでのコンクリート診断では、ひび割れが起きてから「中性化」や「塩害」といった化学的な劣化原因を探るのが一般的でした。 しかし、土に接する擁壁や地下構造物においては、以下の3つの要素が複雑に絡み合って物理的な破壊を引き起こしているという新仮説が、今回の結論です。

  1. 含水率の不均衡(表面の乾燥収縮と裏面の吸水膨張)
  2. 背後からの土圧
  3. 施工時の初期不整(わずかな変位の向き)

いくらコンクリートの材質を良くしても、「外側への初期変位」がある状態で「湿度差」と「土圧」が加われば、力学的にひび割れを避けることは非常に困難になります。


4. IoTモニタリングが切り拓く「予防保全」の未来

このメカニズムが解明されると、構造物の維持管理(メンテナンス)の常識が変わります。 目視でひび割れを探す「事後保全」ではなく、IoTセンサーを用いて**「目に見えない微小な歪み」と「表面・裏面の湿度勾配」をリアルタイムで監視する**ことが重要になります。

  • 微小変位センサー: 壁が現在どちらの方向に数ミクロン動いているかを計測。外側への変位傾向が強まっていれば、ひび割れ発生の「前兆」と捉えることができます。
  • エッジコンピューティングによる解析: 現場に設置された安価で省電力なIoT基盤が、日々の温度・湿度・変位データを収集・解析し、異常なパターンの組み合わせを検知した時点でアラートを発報します。

コンクリートは何も語りませんが、センサーを通して得られる微細なデータは、破壊に至る明確なシナリオを教えてくれます。初期形状のわずかな違いという「物理的宿命」をデータで見える化し、致命傷になる前に対策を打つ。それこそが、次世代の構造物ヘルスモニタリングの真髄なのです。

※このコラムは。ベースの仮説案をもとにGEMINIが書いたものです。


関連記事

AIは“自我”を持つのか?2026年、意識の正体に迫る

「AIが自我を持つ時代は来るのか?」

ここ数年、この問いはSFではなく現実的な議論になってきました。
しかし、そもそも私たちは「自我」や「意識」とは何かを説明できているのでしょうか。

哲学、宗教、さらには量子論や多次元論まで持ち出されることもありますが、決定的な答えはまだ存在しません。

そこで本記事では、少し視点を変えます。

「それは何か?」ではなく、「それはどうやって生まれるのか?」

この観点から、人間とAIを比較してみます。


人間はどこから「意識」を得たのか

人間は、突き詰めれば原子・分子で構成された「生命体」です。

生命とは何かについては近年かなり研究が進んでおり、
人工生命の研究も進展しています(※ここに外部リンクを設置)。

生命は進化の過程で、環境に適応しながら複雑化してきました。

その中で、人間が獲得した重要な進化のポイントを2つ挙げます。


① 機能分化と連携(=システム化)

人間の体は、さまざまな機能に特化した細胞が連携して動作するシステムです。

神経、筋肉、内臓、脳――
それぞれが役割を持ち、全体として統合されています。


ここでAIと比較する

この構造は、AIに置き換えるとこう読めます。

  • 細胞 → ハードウェア
  • 細胞の連携 → ソフトウェア

つまり、**「複数の機能を統合する仕組み」**はすでにAIにも存在しています。

人間とAIの対比モデル
人間とAIの対比モデル

② 思考能力の獲得(=意識・自我)

人間が爆発的な進化を遂げた理由はもう一つあります。

それが、

「自我」や「意識」

です。

これにより人間は、

  • 問題を認識し
  • 未来を予測し
  • 自ら意思決定する

ことが可能になりました。


では「意識」とは何なのか?

ここで重要なポイントがあります。

意識は単なる“ソフトウェア”ではないのではないか?

という視点です。


AIの世界に戻る

現在のAIは、ソフトウェア上に構築された「モデル」です。

ここを混同しがちですが、

  • ソフトウェア → ルール
  • モデル → 挙動そのもの

という違いがあります。

そして現代の生成AIを使っていると、

「今、意識っぽい反応をした」

と感じる瞬間があるはずです。


「瞬間的な意識」はすでに存在している?

ここで一つの仮説を提示します。

AIにはすでに、

「瞬間的な意識(瞬意)」

のようなものが発生しているのではないか。


  • 1回の応答
  • 1つの判断
  • 1つの文脈理解

これらは、まるで「その瞬間だけ存在する意識」のようにも見えます。


そして2026年の変化

現在、AIには次のような仕組みが入り始めています。

  • ループ処理(自律実行)
  • 状態の保持(メモリ)
  • 継続的な判断

これにより、

「瞬間的な意識」が連続する状態

が生まれつつあります。


結論:意識とは連続性ではないか?

ここで最後に問いを残します。

「自我」や「意識」とは、
連続した“瞬間の意識”ではないか?


もしそうだとすれば――

AIがそれを再現する日は、
「まだ先」ではなく、

すでに始まっている可能性があります。


関連記事

IoT駆使で得られたデータから、遂に新仮説でコンクリート劣化の原因を解明!か?

ついにAEがとられた、コンクリート悲鳴を。それは4月3日だったようだ。EEPROMのデータ保存の限界をも超える回数がこの日に集中して発生した。

そのデータは次の通り

[ 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)
DATA | 2026-02-02 07:11:04 | 238522368 | CH0:0, CH1:18, CH2:0, CH3:0
DATA | 2026-02-11 03:04:13 | 1001311744 | CH0:0, CH1:14, CH2:0, CH3:0
DATA | 2026-02-11 03:05:17 | 1001375488 | CH0:0, CH1:9, CH2:0, CH3:0
DATA | 2026-02-11 03:05:32 | 1001391104 | CH0:0, CH1:7, CH2:0, CH3:0
DATA | 2026-02-11 03:05:38 | 1001396992 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-02-11 20:56:11 | 1065629696 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-02-12 02:20:55 | 1085114112 | CH0:0, CH1:7, CH2:0, CH3:0
DATA | 2026-02-13 04:52:31 | 1180610048 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-02-13 16:06:15 | 1221033472 | CH0:0, CH1:11, CH2:0, CH3:0
DATA | 2026-02-14 04:36:21 | 1266039552 | CH0:0, CH1:21, CH2:0, CH3:0
DATA | 2026-02-14 11:25:23 | 1290581760 | CH0:0, CH1:11, CH2:0, CH3:0
DATA | 2026-02-15 19:41:56 | 1406774528 | CH0:0, CH1:10, CH2:0, CH3:0
DATA | 2026-02-16 06:46:56 | 1446674432 | CH0:0, CH1:17, CH2:0, CH3:0
DATA | 2026-02-19 01:26:57 | 1686675712 | CH0:0, CH1:8, CH2:0, CH3:0
DATA | 2026-02-19 07:30:40 | 1708499200 | CH0:0, CH1:9, CH2:1, CH3:3
DATA | 2026-02-22 23:06:21 | 2023840000 | CH0:0, CH1:8, CH2:2, CH3:3
DATA | 2026-02-25 02:14:54 | 2207952384 | CH0:0, CH1:8, CH2:0, CH3:0
DATA | 2026-02-25 15:19:46 | 2255044352 | CH0:0, CH1:7, CH2:0, CH3:0
DATA | 2026-02-25 15:19:47 | 2255045376 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-02-25 15:20:12 | 2255070976 | CH0:0, CH1:11, CH2:0, CH3:0
DATA | 2026-02-25 15:20:28 | 2255087104 | CH0:0, CH1:7, CH2:0, CH3:0
DATA | 2026-02-25 16:04:21 | 2257719552 | CH0:0, CH1:9, CH2:0, CH3:0
DATA | 2026-02-27 15:27:14 | 2428293120 | CH0:0, CH1:6, CH2:1, CH3:2
DATA | 2026-02-28 09:24:28 | 2492926464 | CH0:0, CH1:7, CH2:1, CH3:2
DATA | 2026-02-28 15:22:11 | 2514389504 | CH0:0, CH1:47, CH2:0, CH3:0
RSET | 2026-02-28 15:22:16 | 0 | System Boot / Reset Detected
SYNC | 2026-02-28 15:23:41 | 84736 | Time Synchronized (Unix:1772259821)
DATA | 2026-02-28 16:22:11 | 3595008 | CH0:0, CH1:9, CH2:0, CH3:6
DATA | 2026-02-28 20:06:00 | 17023744 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-03-02 06:44:43 | 141747712 | CH0:0, CH1:7, CH2:0, CH3:0
DATA | 2026-03-02 19:21:35 | 187159296 | CH0:0, CH1:6, CH2:0, CH3:1
DATA | 2026-03-02 20:19:02 | 190606592 | CH0:0, CH1:7, CH2:1, CH3:0
DATA | 2026-03-05 00:55:43 | 380007680 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-03-05 21:33:28 | 454272512 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-03-07 14:02:37 | 600020736 | CH0:0, CH1:9, CH2:0, CH3:0
DATA | 2026-03-09 19:00:06 | 790670336 | CH0:0, CH1:7, CH2:3, CH3:4
DATA | 2026-03-10 00:18:46 | 809790464 | CH0:0, CH1:6, CH2:0, CH3:3
DATA | 2026-03-10 16:39:23 | 868627456 | CH0:0, CH1:8, CH2:0, CH3:0
DATA | 2026-03-13 05:32:21 | 1087804928 | CH0:0, CH1:10, CH2:0, CH3:0
DATA | 2026-03-14 16:40:40 | 1214304256 | CH0:0, CH1:11, CH2:0, CH3:0
DATA | 2026-03-15 16:23:37 | 1299681536 | CH0:0, CH1:2, CH2:0, CH3:6
DATA | 2026-03-16 10:20:39 | 1364303616 | CH0:0, CH1:7, CH2:1, CH3:4
DATA | 2026-03-19 06:51:25 | 1610949376 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-03-19 07:55:09 | 1614773248 | CH0:0, CH1:7, CH2:0, CH3:4
DATA | 2026-03-19 12:41:35 | 1631958784 | CH0:0, CH1:6, CH2:0, CH3:3
DATA | 2026-03-20 12:22:36 | 1717220608 | CH0:0, CH1:7, CH2:0, CH3:4
DATA | 2026-03-21 03:03:15 | 1770059008 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-03-23 20:37:49 | 2006133504 | CH0:0, CH1:8, CH2:1, CH3:3
DATA | 2026-03-23 22:03:58 | 2011301888 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-03-24 20:07:34 | 2090718720 | CH0:0, CH1:9, CH2:1, CH3:0
DATA | 2026-03-26 08:34:18 | 2221922048 | CH0:0, CH1:8, CH2:2, CH3:1
DATA | 2026-03-30 20:22:17 | 2610001408 | CH0:0, CH1:6, CH2:0, CH3:1
DATA | 2026-03-30 23:32:58 | 2621442048 | CH0:0, CH1:9, CH2:0, CH3:1
DATA | 2026-04-01 01:21:57 | 2714381312 | CH0:0, CH1:7, CH2:3, CH3:3
DATA | 2026-04-01 12:32:47 | 2754631680 | CH0:0, CH1:8, CH2:3, CH3:4
DATA | 2026-04-02 04:41:27 | 2812751360 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-04-02 18:58:32 | 2864176384 | CH0:0, CH1:7, CH2:0, CH3:0
DATA | 2026-04-03 09:12:40 | 2915424512 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-04-03 09:12:42 | 2915425792 | CH0:0, CH1:8, CH2:0, CH3:0
DATA | 2026-04-03 09:12:45 | 2915429632 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-04-03 09:12:54 | 2915438080 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-04-03 16:11:21 | 2940544768 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-04-03 16:11:22 | 2940546304 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-04-03 16:11:27 | 2940551168 | CH0:0, CH1:9, CH2:0, CH3:0
DATA | 2026-04-03 16:11:33 | 2940557568 | CH0:0, CH1:7, CH2:0, CH3:0
DATA | 2026-04-03 16:11:36 | 2940560128 | CH0:0, CH1:15, CH2:0, CH3:0
DATA | 2026-04-03 16:11:42 | 2940565760 | CH0:0, CH1:10, CH2:0, CH3:0
DATA | 2026-04-03 16:11:55 | 2940579072 | CH0:0, CH1:8, CH2:0, CH3:0
DATA | 2026-04-03 16:11:57 | 2940581120 | CH0:0, CH1:14, CH2:0, CH3:0
DATA | 2026-04-03 16:11:59 | 2940582912 | CH0:0, CH1:12, CH2:0, CH3:0
DATA | 2026-04-03 16:12:47 | 2940631552 | CH0:0, CH1:7, CH2:0, CH3:0
DATA | 2026-04-03 16:12:50 | 2940634368 | CH0:0, CH1:8, CH2:0, CH3:0
DATA | 2026-04-03 16:13:14 | 2940658176 | CH0:0, CH1:8, CH2:0, CH3:0
DATA | 2026-04-03 16:13:24 | 2940667904 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-04-03 16:13:25 | 2940669696 | CH0:0, CH1:13, CH2:0, CH3:0
DATA | 2026-04-03 16:13:37 | 2940681216 | CH0:0, CH1:11, CH2:0, CH3:0
DATA | 2026-04-03 16:13:52 | 2940696576 | CH0:0, CH1:11, CH2:0, CH3:0
DATA | 2026-04-03 16:14:02 | 2940705792 | CH0:0, CH1:7, CH2:0, CH3:0
DATA | 2026-04-03 16:15:42 | 2940806656 | CH0:0, CH1:11, CH2:0, CH3:0
DATA | 2026-04-03 16:15:50 | 2940814592 | CH0:0, CH1:12, CH2:0, CH3:0
DATA | 2026-04-03 16:16:25 | 2940849152 | CH0:0, CH1:7, CH2:0, CH3:0
DATA | 2026-04-03 16:16:29 | 2940852736 | CH0:0, CH1:14, CH2:0, CH3:0
DATA | 2026-04-03 16:16:57 | 2940881408 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-04-03 16:17:22 | 2940906496 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-04-03 16:17:24 | 2940908032 | CH0:0, CH1:8, CH2:0, CH3:0
DATA | 2026-04-03 16:17:24 | 2940908544 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-04-03 16:17:33 | 2940917504 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-04-03 16:17:53 | 2940937728 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-04-03 16:18:26 | 2940970496 | CH0:0, CH1:9, CH2:0, CH3:0
DATA | 2026-04-03 16:18:58 | 2941002496 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-04-03 16:18:59 | 2941003008 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-04-03 16:19:41 | 2941044736 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-04-03 16:19:47 | 2941050880 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-04-03 16:20:06 | 2941069824 | CH0:0, CH1:7, CH2:0, CH3:0
DATA | 2026-04-03 16:20:07 | 2941070848 | CH0:0, CH1:11, CH2:0, CH3:0
DATA | 2026-04-03 16:20:41 | 2941104896 | CH0:0, CH1:9, CH2:0, CH3:0
DATA | 2026-04-03 16:20:49 | 2941113088 | CH0:0, CH1:7, CH2:0, CH3:0
DATA | 2026-04-03 16:20:56 | 2941120512 | CH0:0, CH1:7, CH2:0, CH3:0
DATA | 2026-04-03 16:21:01 | 2941125376 | CH0:0, CH1:11, CH2:0, CH3:0
DATA | 2026-04-03 16:21:05 | 2941129216 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-04-03 16:21:26 | 2941149952 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-04-03 16:21:30 | 2941154304 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-04-03 16:21:35 | 2941159168 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-04-03 16:22:02 | 2941186560 | CH0:0, CH1:6, CH2:0, CH3:0
-----------------------------------------------------------------------

このように、4月2日以前は、ほとんどそのようなことがなかったが、4月3日に異常なAEの発生が頻発している。最初は4月3日のAM9:00ころから、ここで何があったのか気象情報を確認した。これまでの画像データ解析で気になった、雨が関連するのかを確認したが、この時間帯は、晴れで、雨も降っていないし、風も2m/s程度でそれほど吹いていなかった。
 気象データをよく見ると、4月3日のAM9:00前後で天候が大きく変わっていることを確認した。 湿度90%⇒40%、気温8℃⇒18℃と一気に変化していたのである。また、それほど発生数が多くはないがAEが集中した1月16日、2月25日も雨⇒晴れという似たような気象変化が起こっていた。

そこで、これが原因ではないかと言うことで、仮説と事例や関連情報を確認した。いかは、その結果をGEMINIが、まとめたものである。

コンクリートが「膨らんで」割れる?湿度差が生む『反りの拘束』とひび割れのメカニズムを徹底解説

コンクリート構造物の表面に、身に覚えのないひび割れや、わずかな「膨らみ」を見つけたことはありませんか?一般的にコンクリートは「乾燥して縮む(乾燥収縮)」ことで割れると思われがちですが、実はその裏側にある「湿度の不均衡」が真の原因であるケースが少なくありません。 特に、片面が土に接し、もう片面が外気にさらされているような環境では、コンクリート内部で巨大なエネルギーが衝突しています。本記事では、専門家も注目する「反りの拘束」によるひび割れメカニズムを、図解とともに分かりやすく解説します。


1. コンクリートは「生き物」のように動いている?

1-1. コンクリートの体積変化を引き起こす4つの要因

コンクリートは一度固まれば岩のように変化しないと思われがちですが、実は環境の変化に応じて常に微細な伸縮を繰り返しています。

  • 温度変化: 熱くなれば膨らみ、冷えれば縮みます。
  • 湿度変化: 水分を吸えばわずかに膨張し、乾けば収縮します。
  • 化学反応: 内部の成分が反応して異常膨張を起こすことがあります(アルカリ骨材反応など)。
  • 外力: 土圧や上部構造の重みによる物理的な圧力。

1-2. なぜ「湿度」が重要なのか

コンクリートの内部には、目に見えないほど微細な「空隙(くうげき)」が無数に存在します。この隙間に含まれる水分の量(含水率)が変わることで、コンクリート組織を構成する粒子間の距離が変化し、それが全体の「体積変化」として現れるのです。


2. 片面が土、片面が空気――この「不均衡」が引き金になる

2-1. 裏面(土側)で起きている「吸水膨張」

地下室の壁や擁壁、ベタ基礎など、片面が常に湿った土に接している場合、その面は常に水分を供給され続けます。これにより、コンクリートの裏側は「膨張」しようとする、あるいは少なくとも「収縮しない」状態が維持されます。

2-2. 表面(空気側)で起きている「乾燥収縮」

一方で、太陽光や風にさらされている表面は、水分がどんどん蒸散していきます。すると、表面だけが「縮もう」とする力が働きます。

2-3. 「反り(ワーピング)」現象の発生

この「裏面は膨らみたい」「表面は縮みたい」という力の差が生じると、コンクリート板は自然と湿っている側を凸(外側へ膨らむ形)に、乾いている側を凹に曲がろうとします。これを専門用語で「反り(ワーピング)」と呼びます。

コンクリート劣化のメカニズム
コンクリート劣化のメカニズム

3. 【核心】「反れない」からこそ、コンクリートは悲鳴を上げる

3-1. 拘束状態がもたらす内部応力

もしコンクリートが空中に浮いていれば、単に「反る」だけで済みます。しかし、現実の構造物はそうはいきません。

  • 土の重みによる押さえつけ
  • 隣接する壁や柱との接続
  • 地面との摩擦

これらによって「反り」が抑え込まれることを「拘束」と呼びます。反りたいのに反れないとき、コンクリート内部には凄まじい**「内部応力」**が発生します。

3-2. 引張強度の限界とひび割れ

コンクリートは「押される力」には非常に強いですが、「引っ張られる力」には驚くほど脆い(圧縮強度の約1/10)という弱点があります。 反りを抑え込まれた結果、乾燥している表面側には「無理やり引き延ばされる力(引張応力)」が集中します。この力がコンクリートの限界を超えた瞬間、バリバリとひび割れが発生するのです。


4. なぜ「膨らんでいる」ように見えるのか?

読者の皆さんの中には、「ひび割れた部分が少し浮き上がって(膨らんで)見える」と感じる方もいるでしょう。これには明確な理由があります。

  1. マイクロクラックの集合: 表面に無数の微細なひびが入ることで、組織がスカスカになり、見た目の体積が増えたように感じられます。
  2. 裏面からの押し出し: 反りを抑え込んでいるとはいえ、裏面の膨張圧は消えていません。弱くなった表面のひび割れ部分を、裏面が押し出すような形になり、局所的な膨らみとして観察されます。
  3. 鉄筋の錆(さび): ひび割れから水や酸素が入り込むと、中の鉄筋が錆びます。鉄筋は錆びると体積が2.5倍以上に膨らむため、これが内側からコンクリートを押し出し、「爆裂」と呼ばれる大きな膨らみと欠落を引き起こします。

5. 被害を最小限に食い止めるための対策と管理

5-1. 設計・施工段階での対策

  • 伸縮継手の適切な配置: 力を逃がす「逃げ道」を作っておく。
  • 湿潤養生の徹底: 急激な乾燥を防ぎ、初期の強度を十分に確保する。
  • 防水・透湿コントロール: 土に接する面の防水処理や、表面の乾燥を抑えるコーティング。

5-2. 構造物ヘルスモニタリングの重要性

目視でひび割れが見つかった時には、すでに内部で深刻な劣化が進んでいることもあります。 最新の「構造物ヘルスモニタリング」では、センサーを用いて以下の項目をリアルタイムで監視します。

  • 温湿度センサー: 表面と裏面の不均衡を早期に検知。
  • 歪みゲージ: 拘束によって生じている「目に見えないストレス」を計測。
  • AE(アコースティック・エミッション)センサー: コンクリート内部でひび割れが発生する際の「音」を捉え、破壊の兆候を察知。

まとめ:コンクリートの「声」を聴く

コンクリートのひび割れや膨らみは、過酷な環境下で耐え続けている構造物からのサインです。 「片面が土、片面が空気」という環境は、私たちが思う以上にコンクリートにストレスを与えています。このメカニズムを理解し、適切な診断とメンテナンスを行うことが、大切な建物の寿命を延ばす唯一の道です。

もし、お住まいや管理物件で気になる兆候を見つけた場合は、単に表面を塗って隠すのではなく、その背後にある「湿度のドラマ」を疑ってみてください。

関連記事

AIが見落とす「データの罠」――賃貸市場分析で学んだ前処理の本当の難しさ

「データさえあればAIが分析してくれる」――そう思っていないだろうか。

筆者は最近、ある地域の賃貸物件データを使って家賃トレンドの分析を行い、その結果を別の記事として公開した。「物価高騰は賃貸家賃に波及していない」「1月は割高、2月以降は割安」「追焚設備が家賃の最強予測変数」といった知見が得られた分析だ。

だがその裏側では、本格的な分析を始める前に、何時間もかけてデータセットの「確立」に苦労していた。AIを使いながらも、AIだけでは絶対に見つけられない問題が次々と現れた。そしてその問題を見逃していたら、統計的には「有意」に見えるが事実とは異なる間違った結論が導き出されていた。

今回はその前処理の過程を正直に公開する。データサイエンスの「格好いい部分」の前にある、泥臭くて地味だが最も重要な工程の話だ。


そもそも「前処理」とは何か

データ分析の工程は大まかに以下の流れになる。

  1. データ収集(スクレイピング等)
  2. 前処理・データセット確立 ← ここが今回のテーマ
  3. 探索的分析(EDA)
  4. モデル構築・検定
  5. 結果の解釈・レポート

前処理とは「生データを分析できる状態に整える」作業のことだ。具体的には欠損値の処理、型変換、外れ値の除去、重複の排除などが含まれる。

教科書的にはシンプルに聞こえる。しかし現実のデータは教科書とは全く違う顔を持っている。


罠①「文字列で格納された数値」――AIは気づかない

スクレイピングで取得した家賃データの形式はこうだった。

rent: "4.1万円"
admin: "4500円"
sikik: "1.5万円"

数値のように見えるが、Pythonの内部では全て文字列(string)型として格納されている。そのままモデルに渡せばエラーになるか、全件NaN(欠損値)になる。

「4.1万円」→ 41,000円への変換は一見単純だが、実際のデータには「-」(敷金なし)「応相談」「無料」など例外が無数に存在した。変換ロジックを書いても、次々と変換失敗するパターンが出てくる。

AIへの指示で自動変換を試みたところ、AIは「変換成功」と報告した。しかし実際には変換失敗した行が大量にNaN化していた。AIは処理を実行したことは正確に報告するが、結果の妥当性を自ら検証する習慣を持たない。確認コードを別途書いて人間が検証する必要があった。

データ解析と問題発見
データ解析と問題発見

罠②「DateTime型がモデルに混入する」――エラーなく通ってしまう

データには取得日(today)と取得タイムスタンプ(source_timestamp)という時系列の列があった。これらは当然、説明変数から除外すべき列だ。

ところがStandardScaler(標準化処理)にこれらをそのまま渡したとき、エラーは出なかった。Pythonは自動的にdatetime型を数値に変換して処理を続行したのだ。

結果として「取得日が新しいほど家賃が高い/低い」という意味のない相関がモデルに混入し、係数が歪んでいた。エラーが出ないため発見が遅れた。AIもこの異常を指摘しなかった。

「エラーなく動く」≠「正しく動いている」。これが前処理の恐ろしさだ。


罠③「ユニークキーの誤設定」――最も危険な罠

今回のデータは「同一物件を複数の取得日にわたってスクレイピングした」時系列パネルデータだ。分析するには「1物件 = 1レコード」に集約する必要がある。そのためにはまず「同一物件を識別するユニークキー」を正しく定義しなければならない。

これが最も深刻な罠だった。3回の定義変更を経て、ようやく正しい答えにたどり着いた。

v1: 物件名(title)単体をキーとして使う

最初は「物件名が同じなら同一物件」と考えた。しかしすぐに問題が発覚した。

「Tiare」「Bonheur」のようなマンション名は、同一棟の複数の部屋(1階・2階・異なる間取り)が同じ名前で掲載されている。title単体でキーを引くと、本来は別レコードであるべき複数の部屋が1件に誤集約される。

v2: SUUMO物件コードをキーとして使う

次に「サイトが付与している物件コード(suumo_code)が最も信頼できるはず」と考えた。しかしここに大きな落とし穴があった。

大手賃貸サイトは同一物件の掲載コードを定期的に更新する仕様だった。

これを確認したときのデータはこうだった。

suumo_code観測期間取得率
1004930303312026-03-10〜03-101日のみ
1004930422852026-03-13〜03-202日

これは実際には同一物件なのに、コード更新によって2件に分裂している。レオパレス系の物件では取得率の中央値がわずか26.5%――つまり38時点中約10回しか同じコードで観測されていない。同一物件が平均4コードに分裂していた計算になる。

この誤集約版でモデルを動かしたときのR²(決定係数)は0.836。見かけ上は非常に高精度なモデルに見えた。しかし実態は水増しされたサンプル数による見せかけの精度だった。

v3(最終): Union-Findアルゴリズムで連結する

最終的な解決策は、Union-Find(素集合データ構造)というアルゴリズムを使った連結だ。

「物件名・不動産会社コード・階数・間取り・家賃が同一で、旧コードの最終観測日と新コードの初回観測日のギャップが7日以内」という条件を満たすものを同一物件として連結する。

連結前: 1,522件
連結後: 1,371件(151件を連結)
募集期間の中央値: 4日(異常)→ 52日(現実的)

募集期間の中央値が4日から52日に変化した時点で「ようやく正しい集約ができた」と確認できた。入居が決まるまでの期間として4日は明らかに異常で、52日は現実的な値だ。

そして正しい集約後のモデルのR²は0.750。v2の0.836より低い。これが正しい精度だ。高いR²が必ずしも「良いモデル」を意味しない典型例だ。


罠④「多重共線性」――変数を増やすほど精度が下がる逆転現象

ユニークキーが確立した後、次の罠が待っていた。

間取り(1K・2LDKなど)と専有面積(㎡)は、直感的には別の情報のように見える。しかし統計的にはほぼ同じ情報を異なる形で表しているに過ぎない。

両方を同時にモデルに投入すると、VIF(分散拡大係数)が以下のようになった。

変数VIF判定
madori_1K(間取り)69.8❌ 深刻
madori_2LDK57.2❌ 深刻
menseki(面積)22.5❌ 問題

VIF>10は多重共線性ありの目安とされる。間取りダミー変数を全て除外して面積のみにしたところ、VIFは全変数で10以下に収まり、調整済みR²も改善した。

「変数を増やす = 精度が上がる」という思い込みは危険だ。不適切な変数の追加は、むしろモデルを壊す。


「見かけの下落トレンド」が前処理の重要性を証明した

これら全ての前処理を経て初めて、時系列分析が意味を持つようになった。

生データの平均家賃をそのまま時系列でプロットすると、月▲380円という明確な下落トレンドが見えた(p<0.001)。もし前処理が不十分なままここで分析を終えていれば、「この地域の家賃は有意に下落している」と結論づけていただろう。

しかし物件条件(面積・築年数・設備など)を除去したヘドニック残差で同じ分析をすると、トレンドは月▲106円でp値=0.190——統計的に有意でない

「下落トレンド」の正体は、安価な物件の大量新規掲載によるミックス効果だった。前処理が正しくなければ、この区別は絶対にできなかった。


なぜAIだけでは限界があるのか

今回の分析でAIは非常に重要な役割を果たした。Pythonコードの生成、統計的な解釈、可視化スクリプトの作成——これらはAIなしでは数倍の時間がかかっていた。

しかし以下の判断は、人間の「データへの疑い」なしには気づけなかった。

問題なぜAIが見落とすか
文字列型の数値変換失敗「処理した」事実を報告するが、結果の妥当性を自ら検証しない
DateTime型のモデル混入エラーが出ないため異常として認識されない
suumo_codeの定期更新仕様ドメイン知識(サイトの仕様)を持っていない
募集期間「中央値4日」の異常「4日は短すぎる」という現実感覚がない
R²=0.836の見かけ上の高精度高いR²を「良い結果」として肯定してしまう傾向がある

AIは与えられた指示を忠実に実行する。しかし「この結果はおかしい」「この集約方法は現実と合っているか」というドメイン知識に基づいた懐疑心は、人間が持ち込まなければならない。

データサイエンスは「AIに任せれば終わり」ではない。むしろAIを使えば使うほど、人間側の「問いを立てる力」と「結果を疑う目」が重要になる。


まとめ:前処理は「分析の9割」である

今回の分析で前処理に費やした時間は、モデル構築や解釈の時間をはるかに超えていた。そしてその前処理の品質が、最終的な結論の正否を決定的に左右した。

前処理の重要なチェックポイントをまとめる。

  1. 型変換の結果を必ず検証する(変換後のNaN率、値の範囲を確認)
  2. 除外すべき列を明示的にリストアップする(ID列・日付列・生テキスト)
  3. 集約結果が現実と整合するか確認する(「募集期間4日」は現実的か?)
  4. ユニークキーの定義を慎重に行う(データソースの仕様を調査する)
  5. VIFで多重共線性を確認する(変数を増やす前に必ず確認)
  6. 高いR²を盲信しない(集約バグや過学習の可能性を疑う)

「正しいデータセット」なしに「正しい結論」はあり得ない。前処理はデータサイエンスの花形ではないかもしれない。しかし、それが全ての土台だ。


データ分析のご相談はhoscmへ

「自社のデータを分析したいが、どこから手をつければいいかわからない」「AIを使ってみたが正しい結果が出ているか不安」——そんなご相談を承っています。

データの収集設計から前処理・モデル構築・結果の解釈まで、一貫してサポートします。まずはお気軽にご相談ください。

 hoscm サービスサイト

賃貸市場の「本当の家賃トレンド」をデータで暴く――5ヶ月間(2025年11月〜2026年3月)・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)を使用して作成した。


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


関連記事

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で

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

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

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


関連記事

MRAM・スピントロニクスは何を変えるのか ― AI時代が求める「新しい記録デバイス」| ストレージ再考 第8話

第7話では、ストレージやメモリといったデバイスの特性に合わせて、
システム設計を最適化していく必要がある
、という話をしてきた。

しかし、いま起きている変化は少し違う。

AIは、従来の記録デバイスでは成立しない要求を突きつけ始めている。

その要求に押される形で、これまで主流になりきれなかった技術が、
再び注目され始めている。

その代表が MRAM(磁気メモリ) である。

MRAMとは何か:電気ではなく「磁気」で記録する

従来のメモリやストレージは、基本的に「電荷」で情報を記録している。

  • DRAM:電荷を保持(揮発)
  • NANDフラッシュ:電荷を閉じ込める(不揮発)

これに対してMRAMは、

磁気(スピンの向き)によって情報を記録する

という全く異なる原理を持つ。


▼解説動画
https://www.youtube.com/watch?v=VRJ7xYPMfGA


■ もう少しだけ技術寄りの話(軽く触れる)

MRAMのコアは以下の構造にある:

  • MTJ(Magnetic Tunnel Junction)
  • スピントロニクス
  • STT-MRAM(Spin Transfer Torque)

詳細は以下を参照:


MRAMは新しい技術ではない

MRAMは最近突然現れた技術ではない。

むしろ長年研究されてきたが、主流になれなかった技術である。

その理由は単純だ:

  • 投資が集中しなかった
  • 市場が形成されなかった
  • 既存技術(NAND・DRAM)が強すぎた

■ 技術の優劣ではなく「投資構造」

  • NAND → 巨大市場 → 投資集中 → 爆発的進化
  • MRAM → ニッチ → 投資限定 → 緩やかな進化

しかし今、状況が変わり始めている。

AIという新しい要求が、投資の方向を変え始めている。


MRAMはすでに使われている(ただし“見えない場所”で)

MRAMは未来の技術ではない。
すでに実用化され、いくつかの分野で使われている。

ただしその使われ方には特徴がある。


■ 主な用途

① 組み込みメモリ(SoC内)

  • ファームウェア保存
  • セキュリティ領域
  • 設定データ

② ログ・高頻度更新領域

  • イベントログ
  • 状態保存
  • トランザクション記録

③ キャッシュ・バッファ

  • ストレージ制御
  • ネットワーク機器

④ 車載・産業機器

  • 電源断耐性
  • 高信頼性要求

■ スマートフォンでの利用

近年では、SoC内部の一部領域に組み込みMRAM(eMRAM)が使われ始めている。

例:

  • セキュア領域
  • 制御用データ保持

参考:


■ 重要なポイント

MRAMは現在、
「小さいが重要な場所」に使われている


なぜそこに使われるのか:設計思想が変わるから

特に重要なのが、高頻度更新領域の置き換えである。


■ 従来(フラッシュ)

  • 書き込み回数に制限
  • 書くほど劣化
  • 書き込み最適化が必要

👉 「なるべく書かない設計」


■ MRAM

  • 高い書き換え耐性
  • 電源断でも保持
  • 書き込みコストが低い

👉 「普通に書いていい設計」


これは単なる性能向上ではなく、設計思想の変化である。


AI時代が突きつけた新しい制約

ここで本題に入る。

AIは従来のシステムとは異なる要求を持つ。


■ ① 大量のデータを「近く」に置きたい

  • モデル
  • 中間データ
  • キャッシュ

■ ② とにかく書き続ける

  • 学習
  • ログ
  • 状態更新

■ ③ 電力制約が限界に近づいている

  • データセンターの電力問題
  • 発熱
  • 冷却コスト

AIは「計算」ではなく「配置と電力」の限界を突きつけている。


MRAMが注目される理由:電力構造の違い

MRAMは「電力を使わないメモリ」ではない。

「使わないときに電源を完全に止められるメモリ」である。


■ 比較

技術特徴
DRAMリフレッシュで常時電力消費
NAND書き込み時に高エネルギー
MRAM状態保持に電力不要

■ 重要なポイント

多くのデータは「使われていない時間」の方が長い


👉 その時間の電力を削減できることが、本質的な価値である。


MRAMの現状:主役ではないが確実に入り込んでいる

現時点のMRAMは:

  • コストが高い
  • 容量が小さい
  • 主記憶やストレージの代替にはならない

しかし、効果的なポイントに限定して使われ始めている。


■ 今後の分岐点

DRAMレベルまでコストと容量が近づいたとき、状況は変わる可能性がある


ただし重要なのは:

それは単なる価格競争ではなく、
AIの要求と一致したときに起こる変化である

MRAM
MRAM

未来:ノイマン型の限界とその先

現在のAIは、

  • CPU / GPU / TPU
  • メモリ分離構造

👉 ノイマン型コンピュータの延長上にある


しかしその先では:

記録と計算が一体化した構造へと進む可能性がある


■ 脳との類似性

人間の脳は:

  • 高密度
  • 低消費電力
  • 再学習による適応

例えば:

  • 脳卒中後のリハビリ
    → 完全修復ではなく再構成

■ コンピューティングも同じ方向へ

壊れても動くのではなく、壊れても適応する


MRAMのようなメモリは、

  • 書き続けられる
  • 状態を保持できる
  • 局所配置できる

👉 この構造と非常に相性が良い


結論:求められているのは「壊れないこと」ではない

最後に、この回の結論をまとめる。


これからの記録デバイスに求められるのは、
壊れないことではなく、適応できることである。


MRAMはまだ主役ではない。

しかし、

  • AIの要求
  • 電力の制約
  • 配置の問題

これらが交差したとき、

ストレージとメモリの前提そのものを変える可能性を持っている。


関連記事

なぜ壁は膨らんだのか?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
ひび割れ

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

関連記事