parameter/使い分けの軸を定義する──データとデバイスの分析パラメータ|ストレージ再考 第4話

ストレージはデバイスではなくデータの性質で選ぶ時代へ。
重要度・更新頻度・レイテンシ感度などの観点から、
HDD・SSD・NASの使い分けを整理する「ストレージ再考」第4話。

前回は、さまざまな記憶装置や媒体が生まれては消えながら、多様な記憶デバイスが存在してきたこと、そしてそれらを組み合わせてシステムが構築されてきたことを振り返った。
そして、それらをいかに使いこなすかという点において、「うまく使い分ける」という発想が重要であることを確認した。

では、その使い分けは、何を基準に行えばよいのだろうか。

記憶デバイスの選択は、どうやって行われてきたのか。
基本的な方向性は、「安い」「速い」の二つの軸であろう。

この二つの指標は、長い時間をかけて記憶装置の進化を方向づけてきた。
容量単価は下がり、速度は向上し、それに合わせてシステムの構成も変わってきた。
「より安く、より速く」という判断は、きわめて合理的だったと言える。

しかし実際の運用の現場では、この二軸だけでは説明できない選択が数多く存在する。

storages1

高速ではない媒体に、あえて重要なデータを置く。
コストが高くなるにもかかわらず、冗長化を行う。
頻繁に使うわけではないのに、低遅延の領域に配置する。

「安い」「速い」という基準だけでは、これらの判断は説明できない。

では、何が判断を分けているのか。

その起点は、デバイスではなく、データそのものにある。


データの性質からしか説明できない選択がある

同じ容量のデータであっても、扱い方がまったく異なることがある。
それは、データごとに「性質」が異なるからだ。

業務のためのデータ。
記録として残すデータ。
分析のために蓄積されるデータ。
残すこと自体が目的となるデータ。

同じ「ファイル」という形をしていても、その意味は同じではない。
意味が違えば、置き方も変わる。

ここで初めて、ストレージの選択は「速度」や「容量」だけでは決められないものになる。


データは、それぞれ違う目的で存在している

データは、単に保存されるために存在しているわけではない。
必ず「何に使うか」という目的を持っている。

日々の業務を動かすためのもの。
あとから参照するための記録。
将来の分析に備える素材。
長く残し続けること自体が意味になるもの。

目的が変われば、求められるストレージの姿も変わる。

ここで、選択の起点はデバイスから離れ、
「どのようなデータなのか」という問いへと移っていく。


データごとに“待てる時間”が違う

すぐに取り出せなければならないデータがある。
多少待っても問題のないデータがある。
今すぐ使う予定はないが、いつか必要になるかもしれないデータもある。

速度は、単なる性能指標ではない。
そのデータが「どれだけ待てるか」という性質の表れでもある。

ここで初めて、「速いこと」の意味が定まる。
すべてを高速にする必要はない。
必要な場所にだけ速さが求められる。


変わり続けるデータ、変わらないデータ

書き換えられ続けるデータがある。
追記されながら成長していくデータがある。
一度書いたら、そのまま動かないデータもある。

この違いは、見た目には分かりにくい。
しかし、ストレージとの相性を大きく左右する。

頻繁に更新されるデータは、書き込み性能や耐久性を必要とする。
ほとんど変化しないデータは、安定した保管が優先される。

データの「変化の仕方」が、置き場所を決めていく。


失えないデータがある

ここで、もう一つの視点が現れる。

失っても問題のないデータと、失ってはならないデータがある。

この違いは、容量や速度では測れない。
それは「価値」の問題である。

重要なデータほど、守るための仕組みが必要になる。
冗長化やバックアップは、コストの問題ではなく、価値に対する設計になる。

ここに至って、ストレージの選択は、
単なる性能比較から「守るための構成」へと変わっていく。


データは時間の中に存在している

データには寿命がある。

短期間だけ使われて消えていくもの。
数年にわたって参照されるもの。
長く残し続けることが前提となるもの。

時間が変われば、データの価値の形も変わる。
役割が終わったあとに、記録として残る場合もある。

ここでストレージは、「保管場所」という意味を越え、
時間の中でデータを支える器としての役割を持ち始める。


ここまで見てくると、ストレージの選択は、
「どのデバイスを使うか」という問題ではなくなっている。

データがどのような目的を持ち、
どれだけ待てるのか、
どれほど変化し、
どれほどの価値を持ち、
どのくらいの時間の中に存在するのか。

その性質の組み合わせによって、置き場所が決まっていく。

ストレージは「デバイスで選ぶ」のではない。
「データの性質から設計される」のである。


関連記事

関連外部リンク

https://aws.amazon.com/jp/s3/storage-classes/intelligent-tiering

https://cloud.google.com/blog/ja/products/databases/introducing-bigtable-tiered-storage

https://qiita.com/tomozilla/items/152b76195e9ced933efb

https://docs.aws.amazon.com/ja_jp/msk/latest/developerguide/msk-enable-cluster-tiered-storage-cli.html

記憶方式は階層ではない──すみ分けと多様性という考え方|ストレージ再考  第3話

ここで扱うのは「記憶や記録、データ」です。 昔は、メモリと外部記憶装置は、上下の関係となるように階層モデルとして定義され、別な階層に位置づけられてきた。それはCPUに近い順に上に配置する構成である。
 CPU内 ⇒ RAM ⇒ I/Oを通して、HDD、磁気テープ といった具合である。

時は経て、MD、CD-R、DVD-RW、Flash、SSD、クラウド(実態はHDDやSSD)とさまざまなタイプの記憶メディアが登場しては消えていった。そのような中でもHDDはSASI⇒SCSI⇒Fire。。。 と進化し続けている。

最近では、SSD(Flash)への依存が急速に進んできた。その弊害にはあまり着目されないまま。

「速いほど上、遅いほど下」なのか?

コンピュータの記憶装置は、よく「階層」で説明される。
上には速いもの、下には遅いもの。
上は高価で、下は安価。
そして、上ほど“優れている”と無意識に感じてしまう。

RAMがあり、SSDがあり、HDDがあり、そのさらに下にアーカイブ用の媒体がある。
この並びを見たとき、多くの人は「上位」「下位」という言葉を自然に当てはめる。

しかし、本当にそれらは、上下の関係なのだろうか。

storage_image
storage_image

“メモリの序列”という説明は、現実を表しているのか

たとえば、速い装置が“上”だとする。
では、速いものだけを選び続ければ、最も良い構成になるのだろうか。

すべてを高速な媒体に置けば、それで問題は解決するのか。
現実は、どうもそうではない。

あるものは長く残る。
あるものはすぐ消える。
あるものは書き換え続けられる。
あるものは、書き換えないこと自体に意味がある。

それらは単純な序列で並べられるものではない。
それぞれが、異なる役割を持って存在している。

記憶は「優劣」ではなく「役割」で存在する

記憶装置を「優れているかどうか」で見ると、比較は単純になる。
速いか、遅いか。
高いか、安いか。
新しいか、古いか。

しかし、現実の運用はその軸だけでは説明できない。

頻繁に書き換えられるもの。
長期間そのまま残されるもの。
すぐに取り出されるもの。
ほとんど触れられないもの。

同じ“記憶”という言葉の中に、まったく異なる性質の役割が共存している。
それは、上下ではなく、並び立つ関係に近い。

RAM → SSD → HDD → テープ…は本当に“階段”なのか 

教科書的な図では、記憶装置は階段状に描かれる。
上に行くほど速く、小さく、下に行くほど遅く、大きくなる。

しかし、その図は「理解しやすい説明」であって、
必ずしも現実の姿をそのまま表しているわけではない。

階段として見ると、「どれを選ぶか」という発想になる。
だが実際には、「どれをどう組み合わせるか」という判断が求められる。

階段の一段を選ぶのではなく、
複数の段を同時に使うことができるものである。

すみ分けによって成立する全体速さ・容量・寿命・コストが共存する構造

記憶方式を、上下ではなく「すみ分け」で捉えてみる。
すると、見え方が変わってくる。

すぐに使われるものが置かれる場所。
長く残されることを目的とする場所。
書き換え続けられることが前提の場所。
触れられないこと自体に意味がある場所。

それぞれは、別の条件で存在している。
どれかが優れているのではなく、
役割が違うだけなのだ。

多様性 単一の装置ですべて賄えるものはいまのところ存在しない 目的次第で「なにが最適か」は変わる

もし、記憶方式がひとつしかなければ、
世界はもっと単純だったかもしれない。

しかし現実には、多様な方式が同時に存在している。
それは、過渡期だからではない。
役割が違うから、消えないのだ。

速さが必要な場面。
長く残すことが必要な場面。
書き換えられることが重要な場面。
変わらないことが重要な場面。

それぞれの要求が異なる以上、
ひとつに集約されることはない。

“速い=正義”という直感の危うさ

新しいものは速い。
速いものは便利だ。
だから、それに置き換えていけばよい。

そう考えるのは自然だ。
しかし、その直感だけで進むと、見えなくなるものがある。

速いことと、残ること。
便利なことと、失われないこと。
それらは必ずしも同じ方向を向いていない。

速くて大容量で安ければ「全部これにすればよい」という発想の落とし穴

ある方式が登場すると、「これで統一すればよい」という声が必ず現れる。

だが、統一は単純化であり、
同時に、役割の切り捨てでもある。

すべてを一種類に寄せた瞬間、
満たせなくなる条件がどこかに生まれる。

記憶は、単一の正解に収束するものではない。


記憶方式は並列に存在する

上下ではなく、横に広がる関係。
優劣ではなく、役割の違い。
選択ではなく、組み合わせ。

記憶方式をそのように捉えたとき、
はじめて全体像が見え始める。

どれが正しいかではなく、
どこに置くか。
どう組み合わせるか。

その問いが、ようやく意味を持ち始める。

関連記事

SSDは本当に速くなったのか?- 3年後に感じる“あの重さ”の正体 –

同じデータでも──意味や価値が違えば、別物になる |ストレージ再考 第2話

見た目が同じでも、意味は同じではない

スマートフォンの中にある一枚の画像。
それはただの「写真」かもしれないし、二度と取り戻せない記録かもしれない。

画素数も、ファイル形式も、見た目も同じ。
それでも、その扱いはまったく変わる。

例えば──
・たまたま撮れた風景
・仕事の記録
・家族の思い出
・証拠として残す必要のある写真

どれも「画像データ」であることに違いはない。
しかし、同じ扱いでよいとは、誰も思わないはずだ。

ここで起きているのは、技術の違いではない。
意味と価値の違いだ。


use
use

画像は「データ」ではなく「位置づけ」で価値が変わる

画像という形式だけを見れば、それは単なるデータだ。
だが、人がそこに意味を与えた瞬間、別の存在になる。

同じ構図の写真でも、

  • 落書きの記録
  • 美術作品の記録
  • 事故の記録
  • 成長の記録

それぞれの立場によって、役割はまるで違う。

画像の本質は「ピクセルの集合」ではない。
どの位置づけで存在しているかが、その正体を決めている。


use2
useB

媒体が変われば、意味も変わる

同じ「画像」でも、残され方はさまざまだ。

洞窟の壁に描かれたもの。
紙に描かれた絵。
油絵。
版画。
写真。

それぞれの時代、それぞれの方法で、
「残す」という行為は繰り返されてきた。

そして、残されたものの中には、
意味がはっきりしているものもあれば、
何のために描かれたのか分からないものもある。

それでも共通しているのは、
“残った”という事実そのものに価値が生まれることがあるという点だ。


極端な例で考えてみる

同じ「絵」でも、価値は極端に変わる。

子どもの落書き。
名画。

どちらも画像であり、どちらも記録だ。
しかし、扱いはまったく違う。

捨てられることもあれば、守られることもある。
複製されることもあれば、唯一のものとして扱われることもある。

ここで起きているのは、
媒体の違いでも、画質の違いでもない。

“何として存在しているか”の違いだ。


画像は、使われ方で別物になる

同じ画像でも、状況によって意味が変わる。

・個人的な記録
・共有される情報
・作品
・資料

そして、その扱いは自然に分かれていく。

気軽に消されるもの。
いつの間にか残り続けるもの。
意図して守られるもの。

人は無意識のうちに、
画像を「同じもの」として扱っていない。


しかし、私たちは深く考えていない

日常の中で、画像は大量に生まれる。
保存され、共有され、忘れられていく。

その一つひとつが、
どのような意味を持ち、
どのような価値を持ち、
どのように扱われるべきなのか。

そこまで意識していることは、ほとんどない。

同じように保存され、
同じように並び、
同じように消えていく。

けれど本当は、
同じであるはずがない。


同じ扱いのままでいいのか

同じ形式。
同じ見た目。
同じ保存先。

それでも、意味は違う。
価値も違う。
置かれている位置も違う。

本当は、全部同じ扱いでいいはずがない。

でも、どう違うのかは、
まだ整理されていない。

だから一度、
考えないといけない。


関連記事

SSDは本当に速くなったのか?- 3年後に感じる“あの重さ”の正体 –

https://mic.or.jp/info/2026/02/05/3-reasons-systems-feel-slower/

「星芋がほひいの」 訳アリのあまっているサツマイモの活用レシピ

人気がなく?余っている紫芋を活用して何かできないかレシピを考えてみました。

murasakiimo
紫芋

星芋の作り方

余り気味の甘さ控えめ芋でも、軽いおやつに仕上げる星芋レシピ。
先に薄く切り、元の形に戻して加熱し、夜の冷却と翌日の干しで完成させる。

星芋(イメージ)
星芋(イメージ)

材料

  • さつまいも(紫芋想定)…1本(約300g)
  • グラニュー糖 … 少量
  • バター … ごく少量

下準備

  1. 芋は軽く洗い、土だけ落とす
  2. 皮付きのまま縦に3〜4mmへスライス
  3. 切った順に元の形へ重ねて戻す

※ 完全一致でなくてOK
※ 少し空気層がある方が蒸気が回る


加熱(半生防止・確認最小設計)

  1. 重ねた芋を
     湿らせたクッキングシートで包む
  2. さらにラップで軽く固定
  3. 電子レンジ600W

加熱時間(300g)

  • 600W 5分
  • そのまま余熱 5分
  • 600W 3分

合計:約8〜10分相当

※ 芯チェックは竹串が通ればOK


バラし・夜工程

  1. 加熱直後にスライスをばらす
  2. 網・ザルに並べる
  3. 窓辺など空気が動く場所で自然冷却

時間:夜〜翌朝

murasakiimo
★芋

目的:

  • 水分の再分配
  • 放射冷却
  • 星に当てる工程

ここで初めて「星芋」になる


翌日:干し

  • 日中、風通しの良い場所で干す
  • 片面が乾いたら裏返す

目安:半日〜1日

仕上がり:

  • 表面乾燥
  • 中は柔らかい
  • 薄く軽い食感

仕上げ

完全乾燥前〜直後に:

  • バターをほんの少量絡める
  • グラニューを軽くひとつまみ

→ 甘さ不足の芋でも「おやつ」になる
→ 星屑のような見た目になる

ほしいも 完成品(実物)
ほしいも 完成品(実物)

まだまだ、改善の余地はありそうですね。 もう少しなんとかしてみましょう

データとは何か──「意味」と「価値」から始める記憶の話|ストレージ再考 第1話

ロゼッタ・ストーン ── 読めた記録

記録は、残るだけではデータにならない。
そこに刻まれたものが、誰かに解釈され、意味を持った瞬間、初めて「使えるもの」になる。

ロゼッタ・ストーンは、まさにその象徴だった。
同じ内容が異なる文字で刻まれていたことで、人は古代の文字を読み解く手がかりを得た。
石そのものはただの記録だったが、「読めた」ことでデータになった。

それは、理解された記録だった。

rosetta
Rosetta Stone

チバニアン ── 残った記録

人が残そうとしなくても、痕跡は残る。
地層に刻まれた磁気の向きは、遥かな時間を超えてそのまま保存されていた。
意図も目的もなく、ただ存在し続けることで記録となったもの。

人の手によらない記憶も、この世界には確かにある。

それは、意図せず残った記録だった。


洞窟壁画 ── 残された記録

洞窟の壁に描かれた絵の多くは、その目的が明確には分かっていない。
祈りだったのか、記録だったのか、ただの表現だったのか。

それでも、数万年の時間を越えて残っている。
意味が分からなくても、残存そのものが価値を帯びる。

それは、理由が分からなくても残った記録だった。
第1話 同じデータでも──意味や価値が違えば、別物になる


粘土板 ── 使われた記録

やがて人は、残すために記録を作るようになる。
交易、約束、数量、出来事。
日々の営みの中で、記録は「使うもの」になった。

そこには、残るだけではない役割があった。
読み、参照し、必要に応じて書き直される。

それは、役割を持って使われた記録だった。

第3話 記憶方式は階層ではない──すみ分けと多様性という考え方|ストレージ再考


石碑・金属刻印 ── 変わらない記録

一方で、書き換えないこと自体に価値が置かれる記録も生まれる。
石に刻まれた文字、金属に残された印。
そこには「変えてはならない」という意思が込められていた。

変わらないことで、信頼が生まれる。
時間が経っても同じであることが、意味を支える。

それは、変えないことに価値がある記録だった。


paper
paper

巻物・書物 ── 蓄えられた記録

知識は、単発の記録から連なりへと変わっていく。
巻物や書物は、断片ではなく「蓄積」を前提とした形だった。

一つひとつの記録が、積み重なり、つながり、参照される。
知識は保存されるだけでなく、増えていく。

それは、積み重ねられていく記録だった。


図書館 ── 集められた記録

記録は、単体ではなく集合として扱われるようになる。
書物が集められ、分類され、共有される場所が生まれる。

そこでは一つの記録ではなく、全体としての知識が意味を持つ。
記録は「個」から「群」へと変わった。

それは、体系として集められた記録だった。


口承 ── 人が担った記録

記録媒体が整う以前、人そのものが記憶の担い手だった。
語り継ぐことで知識は残り、世代を越えて伝えられた。

しかし、人がいなくなれば、それも消える。
記録は人の存在と切り離せなかった。

それは、人が背負っていた記録だった。


焼失した図書館 ── 失われた記録

集められた記録であっても、永遠に残るとは限らない。
火災や戦乱によって、多くの書物が失われてきた。

残したはずのものが、ある日突然消える。
保存されていることと、安全であることは同じではない。

それは、残したはずの記録だった。


未解読文字 ── 読めない記録

記録は存在していても、読めなければ使えない。
文字が残っていても、解釈の手がかりが失われれば、意味は閉ざされる。

そこに情報はある。
しかし、それを取り出す方法がない。

それは、存在していても使えない記録だった。

nazo
不解読文字

関連記事

https://mic.or.jp/info/2026/02/05/3-reasons-systems-feel-slower/

SSDは本当に速くなったのか?- 3年後に感じる“あの重さ”の正体 –

速くなった、という確信

私たちはいつから、
「ストレージは速くなった」と疑わなくなったのだろう。

HDDからSSDへ。
OSの起動は明らかに短くなり、
アプリケーションは即座に立ち上がる。
ファイル検索やコピーも、
体感できるほど速くなった。

ベンチマークの数値を見れば、
その差はさらに明白だ。
SSD化は成功した。
少なくとも、多くの人がそう感じている。

いまや「遅いならSSDにすればいい」という言葉は、
何の違和感もなく使われている。
速くなった、という認識は、
すでに前提条件になっている。

HDD_SSD
HDD_SSD

使い続けたあとに現れる、あの感覚

ところが、しばらく使い続けていると、
多くの人が似たような違和感を口にする。

「最近、少し重い気がする」
「前はもっとキビキビしていた」

再起動すると、一時的に戻る。
初期化すれば、確かに速くなる。
だが、しばらくすると、
また同じ感覚が戻ってくる。

この現象は、もはや珍しいものではない。
それでも私たちは、
深く考えないまま受け入れてきた。


重くなる理由として語られてきたもの

遅くなった理由はいくつも語られてきた。

データが増えたから。
設定が複雑になったから。
そして、もっとも納得しやすい説明がこうだ。

「アップデートで機能が増えたから」

確かに、アップデートのたびに
新しい機能が追加され、
画面は華やかになり、
内部処理も増えていく。

それなら、多少重くなるのは仕方がない。
多くの人が、そう考えている。


本当に増えたのは「機能」なのか

だが、ここで一度立ち止まってみたい。

アップデートとは、
実際には何をしている行為なのだろう。

大量のファイルが書き換えられ、
差分や履歴が保存され、
ロールバックのための情報が積み重なっていく。
ログやキャッシュも増え続ける。

アップデートとは、
極めて書き込みの多い作業だ。

機能が増えたことによる負荷は、確かに存在する。
しかし、その裏で起きている
「書き換えられた量」は、
どれほど意識されてきただろうか。


「速さ」は、何を測っているのか

ストレージの速さは、
多くの場合、数値で語られる。

シーケンシャルリード。
ランダムアクセス。
IOPS。

それらは確かに重要だ。
だが、そこで測られているのは
ある瞬間の性能でしかない。

時間の経過は考慮されているだろうか。
使い方の違いは反映されているだろうか。
書き込みが積み重なったあとの状態は、
どこまで想定されているのだろう。

速さとは、
初速のことなのか。
それとも、
使い続けた先まで含めた性質なのか。


過去の常識が、いまも残っている

かつて、性能低下の代名詞だったものがある。
断片化だ。

HDDの時代、
データが物理的に散らばることは、
確かに速度低下の大きな原因だった。

だが、少なくともSSDにおいて、
それが支配的な要因であった時代は
すでに終わっている。

それでもなお、
私たちは説明しやすい物語を
手放せずにいる。


本当に、そうなのか

データが増えたから、遅くなった。
本当にそうなのか。

アップデートで機能が増えたから、重くなった。
本当にそうなのか。

古くなったから、仕方がない。
環境が汚れたから、仕方がない。
本当に、そうなのか。

私たちは、
何が起きているのかを理解した上で
「遅くなった」と言っているのだろうか。

それとも、
もっと見えにくい原因から
目をそらしているだけなのだろうか。


再スタート

さあ、はじまりました。久しぶりのストレージネタです。張り切っていきましょう。ストレージといえば、以前のMIC-NETの主要コンテンツで、読者の多いネタでした。そのネタを新らたな角度から見直してみましょう。過去コンテンツに興味のある方はヒストリ検索とかしてみてください。再度取り上げてほしいものがあればコメントください。

第1話 データとは何か──「意味」と「価値」から始める記憶の話


関連記事

なぜ壁は膨らんだのか?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/