センサー1万台・1日14億行 — 機器が吐くログの現場4例

1日で、14.4億行。

センサー1万台が1分ごとに100項目を1行ずつ吐くと、この数になります。そのうち異常が出ているのは、1台の、1分間だけです。

探し方を4つの現場で並べます。IoT、医療機器、製造ラインのPLC、研究のシミュレーション出力。分野はまったく違うのに、詰まる場所が同じです。

人が書いたログと違って、機器が吐くログは読まれる前提で書かれていません。だから起きることが共通します。

先に結論: UwView Pro なら、258.68GB・45億行のログでも開いた瞬間から全体を表示・検索でき、行数が機器数×項目数で掛け算になっても分割せずに原本のまま目視で追えます。索引と圧縮は保存されるので、同じログを2回目以降は行番号付きで瞬時に開き直せ、約1/9で保管したまま検索できます（実測は特定環境での測定例で、環境により異なります。詳細は記事末尾）

1. 【IoT】行数は「機器数 × 項目数 × 頻度」で掛け算になる

状況

センサーが1万台。1分ごとに送ってきます。

保存されているのは1レコード1行の縦持ち形式です。1台が1回の送信で温度・湿度・電圧・電流・…と100項目を1行ずつ吐くので、1日で 10,000 × 1,440 × 100 = 14.4億行。1行が短いので容量は数十GBですが、行数だけが桁違いに膨らみます。

現場から「3号棟の1台が、昨日の夕方おかしかった」と言われました。device_id は分かりません。

なぜ起きるか

機器のログは「1行が短く、行数だけが爆発する」形になるからです。人が書くアプリケーションログはその逆で、1行が長く、行数は比較的少ない。同じ「巨大ログ」でも性質が反対です。

ここに縦持ち（long format）が重なります。1行が timestamp,device_id,metric,value の4列しかないので、1台の1回ぶんの状態を見るのに100行を読むことになります。横に並べたければピボットが要りますが、それは異常がどこかを知ったあとの仕事です。

そして異常の出方が厄介です。1万台の平均値を見ても、1台の異常は平均に埋もれて消えます。集計は「全体として正常か」には答えますが、「どの1台か」には答えません。

汎用ツールでの対処と限界

素直にやるなら、絞ってから見る流れになります。

# 時刻で粗く切る（夕方の2時間ぶん）
grep -E '2026-09-11T1[6-7]:' sensor-20260911.csv > evening.csv

# 特定の項目だけを見る
grep ',voltage,' evening.csv | head -50

# 値の外れを機械的に拾う（第4列が数値のとき）
awk -F, '$4+0 > 250 || $4+0 < 180' evening.csv | head

# どの device_id が多く引っかかるか
awk -F, '$4+0 > 250 {print $2}' evening.csv | sort | uniq -c | sort -rn | head

これで当たれば早いです。当たらないとき、限界が3つ出ます。

ひとつめ、しきい値を先に決めなければならないこと。上の例では 180〜250 を正常としましたが、その範囲は「異常がどう出ているか」を知ってから決まるものです。順序が逆です。しきい値を外すと0件か数百万件になり、どちらも役に立ちません。

ふたつめ、絞ると隣が見えなくなること。grep ',voltage,' で電圧だけを抜くと、同じ時刻の電流や温度が視界から消えます。機器の異常は項目どうしの関係に出ることが多いのに、絞った瞬間にその関係が切れます。±N行の文脈を付けても、縦持ちでは「同じ1台の別項目」が必ずしも隣接しません。

みっつめ、行番号が消えること。evening.csv の1行目は原本の何行目でしょうか。ベンダーへ「この行から様子が変わる」と伝えたいときに、その座標がありません（第16回に書いた切り出しの問題が、そのまま出ます）。

2. 【医療】ベンダー任せにせず、自院で一次切り分けをする

状況

検査装置が週に1回、原因不明で止まります。

ベンダーに連絡すると「ログを送ってください」と言われ、送って、返事は1週間後。その間も装置は止まります。装置のサービスモードからエクスポートしたログは12GBありました。

なぜ起きるか

装置のログは、装置を作った人だけが読める前提で書かれているからです。

• 内部コードで書かれる — E-1042 SUBSYS3 STATE=7 のような表記が並びます。意味はサービスマニュアルにしかありません
• 複数系統が1本に混ざる — 制御・搬送・光学・通信が同じファイルへ時刻順に書き込まれます。行は時系列ですが、文脈は系統ごとに別です（第5回のスレッド混線と同じ形です）
• 文字コードが古い — 国内メーカーの装置はShift_JISのまま出力することがあり、UTF-8前提のツールで開くと日本語部分が壊れます（第3回）
• 持ち出しに制約がある — 患者IDや検査IDが混ざっていれば、ファイルをそのままクラウドの解析サービスへ上げるわけにいきません

ここで「ベンダー任せ」になる最大の理由は、実は難しさではありません。12GBを開ける道具が院内にないからです。開けないので中を見られず、見られないので「週1回、何時ごろ」以上の情報を添えられない。情報が薄いから往復が増える——この循環です。

汎用ツールでの対処と限界

自分でできるのは、ここまでです。

# 文字コードを確かめてから変換する（推測で変換しない）
file -i device.log
iconv -f CP932 -t UTF-8 device.log > device-utf8.log

# エラーコードの出現順と回数を見る
grep -oE 'E-[0-9]{4}' device-utf8.log | sort | uniq -c | sort -rn | head -20

# 停止した時刻の前後を切り出す
grep -n -B 200 -A 20 'E-1042' device-utf8.log | head -100

file の判定も iconv の挙動も実装とバージョンで変わるので、手元の man で確認してください。

限界は3つ。

ひとつめ、iconv を通すと中間ファイルが増え、原本と行番号が一致しなくなる可能性があること。特に装置ログは行末が CRLF だったり、末尾がヌル文字で埋められていたりします。

ふたつめ、「何回出たか」は数えられても「何が先か」が分からないこと。uniq -c は順序を捨てます。装置の異常は連鎖するので、知りたいのは最初に崩れた系統です（第2回の因果を遡る話と同じです）。

みっつめ、保守記録としての性質。医療機器の不具合調査ログは、あとで保守記録や報告の根拠になります。原本を加工したファイルしか残っていないと、その根拠が弱くなります（第16回）。

3. 【製造】PLCのアラーム履歴CSVが、専用ソフトで開けない

状況

ラインが止まりました。原因を追うためにPLCのアラーム履歴をエクスポートします。

出てきたのは 3.8GB のCSV。メーカー純正の履歴ビューアに読ませると、しばらく砂時計が回ってから「メモリが不足しています」。表計算ソフトに至っては、104万行の壁でそもそも全部を受け取れません（第1回）。

なぜ起きるか

専用ソフトは「その装置の、想定された量」を前提に作られているからです。

前提が崩れる理由は、だいたい次のどれかです。

• チャタリング — 接点の微振動で同じアラームが秒間数十回記録され、1日で数百万行に膨らむ
• ライン増設 — 収集対象が増えたのに、履歴の保存期間だけが昔のまま
• 全ビット記録 — 「あとで困らないように」と入出力を全点ログに入れた結果、実質的にデータロガーになっている

そして純正ソフトの多くは、ファイルを全部メモリに読み込んでから表示します。3.8GBを読み込もうとした時点で、搭載RAMが上限になります。現場のPCは事務用のノートPCで、増設もできません。

さらに製造現場特有の事情が2つ。アラーム名が日本語でShift_JIS、そして改行コードがCR単独の装置がまだ現役です。CR単独だとツールによって「1行」と数える範囲が変わり、行番号が食い違います。

汎用ツールでの対処と限界

# まず先頭と末尾を見る（列の並びと時刻の範囲を確認する）
head -5 alarm.csv
tail -5 alarm.csv

# 同じアラームの連続を潰して、種類と回数を見る
cut -d, -f3 alarm.csv | uniq -c | sort -rn | head -20

# 止まった時刻の前後だけを取り出す
grep -n '2026/09/11 14:2' alarm.csv | head -40

# どうしても開けないなら分割する
split -l 500000 alarm.csv part_

限界は3つ。

ひとつめ、split は文脈を切ること。境界をまたいだアラームの連鎖が、2つのファイルに分かれます。しかも分割後は行番号がファイルごとに1から振り直され、純正ソフトが表示する行番号と対応しなくなります。

ふたつめ、チャタリングを潰すと、潰した事実まで消えること。uniq -c で1行にまとめると読みやすくなりますが、「この10秒間に480回出た」という情報は、その密度自体が異常の兆候です。読みやすさと証拠性が反比例します。

みっつめ、現場のPCにコマンドラインが無いこと。制御系のPCはソフトの追加インストールが禁止されていることが珍しくありません。「解析用のPCへコピーする」となると、今度は持ち出しの手続きが要ります（第17回の持ち帰りの話です）。

4. 【研究】プロットの前に、生値を見る

状況

シミュレーションが48時間回って、50GBの数値ログが出ました。

読み込んでプロットすると、グラフの一部が不自然に平らです。バグか、物理的にそうなるのか、それとも出力側の問題か。判断するには生の数値を見るしかありません。

なぜ起きるか

数値ログの壊れ方は、集計やプロットを通すと見えなくなるからです。

よくあるのは次の4つです。

• NaN / inf の混入 — 読み込みライブラリが黙って0や欠損に置き換えると、グラフ上は「平ら」に見えます
• 書式の揺れ — 1.0E-05 と 1.0e-05 と 0.00001 が同じファイルに混ざる。パーサによって片方を読み落とします
• 途中で列が増減する — 再起動やチェックポイント復帰の前後で、ヘッダがもう一度出力されたり、列が1つ増えたりします
• 末尾の切れ — ジョブがウォールタイム上限で殺されると、最終行が行の途中で終わります

そして研究のログには、運用ログと決定的に違う性質があります。再現に48時間かかること。「壊れていたのでもう一度回します」の代償が大きいので、まず原本を壊さずに確かめる必要があります（第13回の検品の話と同じ構図です）。

汎用ツールでの対処と限界

# 末尾がきちんと終わっているか（最終行の形を見る）
tail -3 sim-output.dat

# NaN / inf がどこから出るか（最初の1件の行番号）
grep -n -m 1 -E 'NaN|nan|inf' sim-output.dat

# 列数が途中で変わっていないか
awk '{print NF}' sim-output.dat | uniq -c

# ヘッダ行が2回以上出ていないか
grep -c '^#' sim-output.dat

限界は3つ。

ひとつめ、awk '{print NF}' は50GBを全部走査すること。数分から十数分かかり、そのあいだ何も分かりません。しかも結果は「列数が変わった」までで、どこで変わったかを見るには、もう一度走らせることになります。

ふたつめ、grep -n で行番号は分かるが、その周りを読めないこと。「1,203,884,112行目にNaNがある」と分かっても、その前後200行を見るには sed -n で範囲指定して、また頭から走査します（第15回の、パイプ芸が疲れる境界です）。

みっつめ、計算ノードと解析環境が別なこと。計算機センターのストレージに置いたまま ssh 越しに less で見ると、画面の応答が往復ごとに待たされます。手元に落とすなら50GBの転送と空き容量が要ります。

4つに共通していたもの

分野は4つともばらばらです。それでも詰まり方が同じなのは、機器が吐くログには次の3つが揃っているからです。

• 行数が掛け算で増える — 機器数・項目数・頻度のどれかが増えると、他と掛かって桁が上がります。人が書くログの「だんだん増える」とは増え方が違います
• 異常が局所に出る — 全体の集計に現れず、1台の、1分の、1行に出ます。集計は「正常か」に答えても「どこか」には答えません
• 原本を壊せない — 医療は保守記録、製造は品質記録、研究は再現性、IoTは契約上のデータ保持。4つとも、加工した控えでは足りない場面があります

この3つが揃うと、「絞ってから見る」という順序が成立しません。絞る条件は異常を見てから決まるのに、見るために絞れと言われる。ここが4つの現場に共通する行き止まりです。

必要なのは、順序を逆にできる道具です。

• 原本をそのまま、全部開ける — 絞る前に見る。14.4億行でも、3.8GBのCSVでも、50GBの数値ログでも
• 見ながら絞れる — 絞った結果から、さらに別の条件で絞れる。しかも原本の行番号を保ったまま
• 手元で完結する — 患者IDも品質記録も研究データも、ファイルを外へ出さずに済む

冒頭の14.4億行に戻ります。あの数字は「多すぎて読めない」という意味ではありません。1台の1分を見つけるまで、残りの14.4億行を捨てられないという意味です。

使っている道具

私が開発している UwView（無料）は、巨大なテキストを開いた瞬間から表示・スクロール・検索できるビューアです。ファイル全体をメモリへ読み込まないので、RAMより大きいファイルでも開けます。索引はバックグラウンドで作られ、完成すると行番号が付きます。

上の3条件のうち、1つめと3つめは無料版がそのまま満たします。

• 読める大きさがRAMで決まりません。 事務用のノートPCでも数十GBのファイルを開けます（無料版での実測上限は47.73GB・約8.9億行。特定環境での測定例です）。3章の「メモリが不足しています」が起きる前提そのものが消えます
• 原本に書き込まず、分割も切り出しもしません。 3章の split も、4章の中間ファイルも作らずに開けるので、行番号が原本のままです。1章でベンダーへ伝える座標、2章の保守記録、4章の再現性——どれも原本の行番号が根拠になります
• 処理はすべて手元のマシンで完結します。 対象ファイルを外部へ送りません。2章の患者情報を含む装置ログ、3章の持ち出し手続きでは、ここが前提条件になることがあります
• 文字コードは開いたまま切り替えられます（UTF-8 / Shift-JIS(CP932) / EUC-JP / UTF-16 を自動判定）。2章・3章のShift_JIS装置ログを、iconv の中間ファイルを作らずに読めます（第3回）
• ハイライトは行を消さずに色を付けます。 2章の複数系統混在を、系統名で色分けして目で解けます。行が消えないので、混ざっている密度がそのまま見えます（3章のチャタリングは、この密度こそが兆候です）

2つめの「見ながら絞る」と、同じログを何度も開き直す場面は UwView Pro の領分です。

• 多段階検索（ドリルダウン）: 絞り込んだ結果を、さらに別の語で絞れます。原本の行番号は最後の段まで保持されます。1章の「device_id が分からないまま時刻で絞り、そこから項目で絞り、値の桁で絞る」が、原本を切らずにできます（多段階検索の記事）
• ±N は段ごとに独立: 絞る段は±1、読む段は±200。4章の「NaNの行番号は分かったが、その周りを読むのにまた走査する」が消えます（無料版は±1固定、可変の±N は Pro）
• シーケンシャル検索: w1 → w2 → w3 がこの順に現れる箇所だけを拾います。2章の「どの系統が最初に崩れたか」を、コードの並びで条件にできます（実装記事）。正直に書くと、各段は前段の位置から本文を走査するので、所要時間は全文検索と同程度かかります
• 集計（頻度ランキング）: 正規表現に当たった値ごとの件数を出し、行をクリックするとその出現位置へ降ります。2章の uniq -c に相当しますが、数えたあとで現物へ戻れるぶんが違います
• 索引と圧縮を保存する: 一度開いたファイルは2回目以降行番号付きのまま瞬時に開き直せます（47.73GBのテキストで実測0.02〜0.07秒。特定環境での測定例で、環境により異なります）。3章のライン停止のように同じ履歴を何日も参照する調査で効きます
• 約1/9で保管しつつ検索できる: 1章の日次14.4億行、4章の50GB出力を、圧縮したまま検索できます。zgrep のように毎回展開しながら走る必要がありません（第8回）
• より大きなファイルを扱えます: Pro での実測は258.68GB・45億行です（特定環境での測定例で、環境により異なります）

正直な限界

UwView はビューアです。時系列分析ツールでも、データロガーの解析基盤でもありません。

• 数値の統計処理はしません。 平均・合計・標準偏差・移動平均——1章の外れ値判定も4章の検算も、awk や解析環境の仕事です。できるのは「異常の場所を高速に目視で見つける」ところまでです
• グラフは描きません。 4章のプロットは別のツールで行ってください。この記事の位置づけは「プロットの前に生値を確かめる」です
• 縦持ちを横に並べ替える機能はありません。 1章のピボットは扱えません
• CSVの列を理解しません。 3章のアラーム履歴も、テキストとして扱います。「3列目だけを並べる」はできません
• 装置の内部コードは解読できません。 2章の E-1042 の意味はサービスマニュアルにしかありません。できるのは、その出現順と文脈を速く読むことだけです
• リアルタイムの追従監視、アラート、複数ログの自動突き合わせ——いずれもありません
• 対象はテキストです。 バイナリ形式で記録する装置のログは、先にテキストへ書き出す必要があります

参考までに、非破壊の差分編集（Edit Upgrade）は別ライセンスとして存在しますが、この記事の4項目はすべて読み取りだけの仕事です。ここで要るのは View 側です。

そして、ストレージを専有している巨大ログを圧縮して保管し、さらに高速に検索したいなら UwView Pro をどうぞ。永続索引・圧縮キャッシュ検索・約1/9保管で、開き直しも検索も一段速くなります（全OS対応・買い切り／月額プランあり）。

リンク

• 第1回: 巨大ファイルに沈む4つの定番ツールと、その先: https://uvp.y42u.net/blog/uwview-ps01-huge-file-tool-limits/
• 第2回: ログの因果を遡る4つの技法: https://uvp.y42u.net/blog/uwview-ps02-log-causality-tracing/
• 第3回: 文字コード4つの罠と切り分け手順: https://uvp.y42u.net/blog/uwview-ps03-japanese-encoding-traps/
• 第5回: 開発ログとの正しい付き合い方4選: https://uvp.y42u.net/blog/uwview-ps05-debug-log-practices/
• 第8回: 圧縮保管と検索の両立: https://uvp.y42u.net/blog/uwview-ps08-compressed-archive-search/
• 第13回: 巨大データ検品の4技法: https://uvp.y42u.net/blog/uwview-ps13-huge-data-inspection/
• 第15回: コマンドライン職人芸の限界線4本: https://uvp.y42u.net/blog/uwview-ps15-cli-craft-limits/
• 第16回: 保全・切り出し・改ざん対策の4原則: https://uvp.y42u.net/blog/uwview-ps16-log-as-evidence/
• 第17回: 開発環境とログの4つの摩擦: https://uvp.y42u.net/blog/uwview-ps17-dev-env-log-friction/
• 絞り込んだ先からさらに絞り込む（多段階検索）: https://uvp.y42u.net/blog/uvp-drilldown-search/
• その順に現れる箇所だけを探す（シーケンシャル検索）: https://uvp.y42u.net/blog/uvp-sequence-search/
• ソースコード（GitHub）: https://github.com/amru195704/UwView

開発者より: アプリ・Kindle本・オープンソースの一覧は GitHub: amru195704 にまとめています。

お願い
本記事の情報は参考目的で掲載しており、正確性・完全性を保証するものではありません。医療機器・製造設備の不具合調査は、各機器の取扱説明書・サービスマニュアルおよび製造販売業者の指示に従ってください。本記事は自院・自社での一次切り分けを推奨するものであり、メーカー保守の代替を意図するものではありません。患者情報・品質記録・研究データの取り扱いは、各組織の規程および適用される法令に従ってください。行数・容量・エラーコード・ファイル名はすべて説明のための例であり、特定の製品や事案を指すものではありません。grep・awk・cut・split・iconv・file・sort・uniq 等の挙動は実装（GNU/BSD/busybox）・バージョン・ビルドオプションにより異なり、オプション名や既定値も変わります。必ず手元の man および公式ドキュメントで確認してください。実測と明記した数値も特定の1環境での測定例であり、同じ結果を保証するものではありません。誤記・不正確な情報がございましたら、コメント欄よりご指摘いただければ、確認のうえ修正いたします。