データ整形｜右寄せは数値とは限らない

2026年2月27日 12:08

以前の記事でデータ整形に触れてきましたが、今回はあらためて「基本の確認」として温湿度ログのCSVを見直してみました。そこで「見た目」と「中身」のギャップに直面しました。

Excelとスプレッドシートの「自動変換」

CSV上の「YYYY-MM-DD」という表記を、Excelは見た目を「YYYY/MM/DD」に整えて表示しました。一方でスプレッドシートは「YYYY-MM-DD」のまま表示されました。同じCSVでも「表示のされ方」が変わるのがまず意外でした。

最初は「Excelの方が賢くて楽だな」と思ったのですが、これには注意が必要だと気づきました。Excelが「形を整えてくれた」だけで、CSVとして保存し直せば元に戻ってしまう可能性もあります。「ツールが勝手にやってくれたこと」を「整形完了」だと思い込むのは、少し危ういなと感じました。

データの不足をどう埋めるかでも、自分の考えの甘さが出ました。湿度の欄に空欄があったとき、空欄のままだとグラフ化しづらいだろうと思い、深く考えずに「0」を入れてみたのです。

でも、これは良くなかったですね。空欄は「データがない」ことを示しますが、「0」にすると「湿度が0%だった」という誤った記録になってしまいます。見た目を整えるために、事実と違うデータを作ってしまっては本末転倒でした。わからないものは、空欄のままにしておくのが正解だったようです。

今回、一番「そうだったのか」と思ったのが、「ISNUMBER関数」での確認です。私はこれまで、セルの中で数字が「右寄せ」になっていれば、それは数値として認識されているものだと思っていました。今まで「数値かどうかを確認する」という発想自体がなかったのです。

実際にこの関数を使ってみると、面白い結果が出ました。

「見た目は数字なのに、中身は文字」という状態は、最初あまりピンときていなかったのですが、実際に関数で判定されると驚きがありました。誰かがルール設定で「文字列も右寄せ」にしていたら、見た目だけでは一生気づけません。

ちなみに、日付の列も同じように確認してみたところ、こちらは両方ともTRUEでした（表示は違っても、中身としては日付として扱われていました）。
つまり私が引っかかったのは「-」か「/」かそのものではなく、見た目の変化を“処理完了”だと思い込みそうになる点でした。

今回の件で、表示が揃っているからといって整形できているとは限らない、と気づきました。

これからはデータの整形を始めるとき、安易に右寄せを信じるのはやめようと思います。まずは「ISNUMBER関数を使って、そもそもこれは数値なのか？」を確認する。

見た目の綺麗さに惑わされず、まずは中身の正体を確かめるところから始めてみたいと思います。

ExcelデータをCSVに変換した、データ整形の出発点
Vol.16：Excelは「人のため」、CSVは「AIのため」。Makeで挑むデータ整形の第一歩
https://note.com/toto_automake/n/n00eb4d37ff68

整形したデータをAI分析につなげた回
Vol.19：整えたデータに「意味」を吹き込む。AI分析で見えてきた、一歩先のデータ活用
https://note.com/toto_automake/n/nc8d2d77126bb

空欄と「0」は同じではない？欠損データの扱いを考える
Vol.26：データ整形｜空欄と「0」の違いを見落とすと何が起きるか
https://note.com/toto_automake/n/nb5ea69a08677

Xでは、データ整形や自動化の作業中に出てきた疑問や判断の分岐を、短いメモとして残しています。
記事になる前の思考の断片です。
https://x.com/toto_automake