Excelは16桁目を0にする。カード番号1,000件のCSVを上書き保存したら、番号が2通りしか残らなかった

Excelのセルに16桁の数字を数値として入れると、16桁目から先は0になる。1234567890123459と打つと1234567890123450になり、四捨五入ではなく切り捨てで消える。一度0になった桁は、書式を変えても戻らない。

もっと壊れるのはCSVだ。架空のカード番号1,000件が入ったCSVをダブルクリックで開き、そのまま上書き保存すると、1,000件の番号は「9.99912E+15」と「9.99913E+15」の2通りの文字列になった。12桁の番号も同じで、続き番号の100件は1通りに潰れた。

確かめたのはMicrosoft 365のExcel（バージョン16、ビルド20326）で、2026年10月6日。桁数の上限は、MicrosoftのExcelの仕様と制限で「有効桁数」が15桁と書かれているのを同じ日に読んだ。番号はすべて架空で、カード番号は先頭6桁を999912にそろえ、最後の1桁をチェックディジットとして計算して作った。

Excelでカード番号の最後が0になる。16桁目から先は切り捨てで消える

標準の書式のセルに、桁数を変えながら数字を打った。

15桁まではExcelの中で全部の桁が残る。16桁目からは、超えた分の桁がそのまま0に置き換わる。9999999999999999も9999999999999990になった。切り上げて1京にはならない。

見え方は12桁で変わる。標準の書式は11桁までしか並べず、12桁から指数表記にする。列幅を40まで広げても1.23457E+11のままだった。ここで2つを混同しやすい。12桁から15桁は、見た目が崩れていても中身は無事で、書式を「0」にすれば123456789012と全部出る。16桁以上は、見た目も中身も壊れている。

仕組みも書いておく。Excelの数値は64ビットの浮動小数点数で、この形は2の53乗、つまり9,007,199,254,740,992までの整数なら1違いまで区別して持てる。16桁の一部まで入る計算だ。実際、2の53乗を数式で計算させると、セルの中身は9007199254740992だった。それでも表示は9007199254740990で、同じ数を手で打つと最後が0になって入る。0にしているのは数の形の限界ではなく、入力と表示を15桁で切るExcelの決まりのほうだ。

カード番号は16桁のものが多い。決済代行のDGフィナンシャルテクノロジーのFAQは、AMEXなど16桁に満たない番号を例外として扱い、15桁の378282246310005を例に挙げている（2026年10月6日に確認）。16桁ならどのカードも最後の1桁を失い、15桁のものは数値になっても桁は残る。

CSVを開いて上書き保存すると、番号は6桁しか残らない

いちばん起きやすいのは、手で打つときではなくCSVを開くときだ。カード番号1,000件、12桁の番号20件、郵便番号と電話番号を1件ずつ入れたCSVを作り、ダブルクリックと同じ開き方（COMのWorkbooks.Open）で開いた。

開いた直後の時点で、カード番号は1,000件とも数値になり、16桁目が0になった。元と同じだったのは111件。最初から末尾が0だった番号が、ちょうど111件あった。0にされても変わらない番号だけが無事だったことになる。

ここで上書き保存する。CSVに書かれたのは、Excelが持っている値ではなく、標準の書式で見えている文字列だった。

保存前のCSV  9999125774637069
開いた直後   9999125774637060（セルの中身）
保存後のCSV  9.99913E+15

有効数字は6桁。先頭6桁が999912の番号は、7桁目で四捨五入されて9.99912E+15か9.99913E+15のどちらかになる。1,000件の内訳は488件と512件で、番号を区別する手がかりは完全に消えた。

12桁は、開いた直後はまだ無事だ。973505302944はセルの中で973505302944のまま残っていた。ところが保存すると9.73505E+11と書かれ、読み戻すと973505000000になる。上の表の「見え方」の列が、そのままCSVに書かれる文字列だと思えばよい。11桁までは見え方が数字のままなので、保存しても残る。

続き番号の12桁を100件、401234567001から401234567100まで並べて同じことをすると、100件とも4.01235E+11になった。有効数字が6桁なので、先頭6桁と7桁目の四捨五入が同じになる番号は、いくつあっても同じ文字列になる。続き番号は、その条件にいちばん当てはまりやすい。ヤマト運輸のFAQでは、問い合わせに使う送り状番号は「12桁または、11桁の数字」となっていた（2026年10月6日に確認）。12桁のものは、CSVで上書き保存した時点でこうなる。

国税庁の法人番号公表サイトによると法人番号は13桁で（2026年10月6日に確認）、これも12桁から15桁の側に入る。ブックの中では無事なので、壊れたことに気づくのは、そのCSVを別のシステムに取り込んでからになる。

1,000件のうち889件は、カード番号として成り立たなくなる

カード番号の最後の1桁は、ほかの15桁から計算するチェックディジットになっている。右から数えて偶数番目の桁を2倍し、2倍して9を超えたら9を引き、全部足して10で割り切れれば合っている。Luhnと呼ばれる計算だ。Stripeの公開しているテスト用の番号4242424242424242も、上のFAQにある378282246310005も、この計算で割り切れることを確かめた。

16桁目が0になった番号でこの計算をすると、合ったのは111件だった。開いても変わらなかった111件と同じ番号で、残りの889件は計算が合わない。最後の1桁が0に置き換わると、元の最後の桁が0だった場合を除いて合わなくなるからで、10件に9件が外れる。

カード番号の列の末尾がすべて0で、チェックディジットが1割ほどしか合わないなら、その列は一度Excelで数値にされている。打ち間違いなら末尾は0に偏らない。

ただ、計算が合っても正しい番号とは限らない。隣り合う2桁の入れ替えを全部の組み合わせで試すと、09と90の入れ替えだけはこの計算をすり抜けた。

郵便番号や口座番号の先頭の0は、桁数が決まっていれば戻せる

0から始まる数字も、数値にされた時点で0を落とす。CSVの0600001は600001に、0312345678は312345678になった。0から始まる口座番号も同じで、手で打った0123は123になった。4桁の銀行コードも、0から始まれば桁が減る。

こちらは16桁と違って戻せる。郵便番号は7桁と桁数が決まっているので、足りない分だけ前に0を付ければよい。口座番号も、表の中で7桁にそろえているなら同じ考え方で戻る。

=TEXT(A2,"0000000")

この式は数値の600001を、文字列の0600001にして返す。

戻したつもりで戻っていない失敗が2つある。1つは書式だ。セルの書式を「0000000」にすると画面には0600001と出るが、中身は600001のままだった。文字列の0600001と比べると一致しないので、VLOOKUPで探すと#N/Aになる。Microsoftの先頭のゼロおよび大きい数値の保持にも、書式を付ける前に消えた0は戻らないとある。文字列と数値が混ざったときのVLOOKUPの外れ方は、VLOOKUPが合わない原因の記事で200件を数えた。

もう1つは、あとから書式を「文字列」に変えるやり方だ。数値の9999125774637060が入ったセルの書式を文字列にしても、中身は数値のままだった。文字列の書式にした列へ値だけ貼り付けても、やはり数値で入った。文字列の書式が効くのは、そのあとで打つ値と、打ち直した値だけだ。

CSVを壊さずに開くには、列をテキストにして読み込む

元のCSVが残っていれば、読み直せば全部戻る。開き方を変えた4通りを試した。

データタブの「テキストまたはCSVから」はPower Queryで読み込む。このときの列の型で結果が分かれた。型を変えずに読み込むか、テキストにすると、9999125774637069も0600001も元の文字のまま入った。型を整数にした状態をM式で作って読み込むと、9999125774637069は9999125774637068になり、画面には9.99913E+15と出た。こちらは0ではなく1ずれる。2の53乗を超える整数は偶数しか正確に持てないので、奇数の番号は隣の偶数に丸まる。読み込みの画面は列の型を自動で決めるので、プレビューで列の型がテキストになっているかを見てから読み込む。

テキストファイルウィザードで2列目を文字列に指定して開いた場合も、全部の桁が残った。この状態でCSVに上書き保存すると、9999125774637069も0600001もそのまま書かれた。

手で打つなら、先頭にアポストロフィを付けるか、打つ前にセルを文字列の書式にする。どちらも1234567890123456が16桁のまま残った。

Microsoft 365とExcel 2024には、ファイル、オプション、データの「自動データ変換」に、15桁で切り詰める変換と先頭の0を消す変換を止める設定がある。自動データ変換を設定するのページで、CSVを開くときもこの設定が効くと読んだ。私の環境では設定を変えずに試したので、止めたときの動きは見ていない。

文字列で持った番号にも落とし穴が残る。COUNTIFは16桁の文字列を比べるとき15桁までしか見ず、1違いの番号を同じと数える。これは重複の削除で件数が合わない記事で確かめた。番号の列で重複を探すなら、EXACTで比べる。

番号の列を貼ると、壊れた行に色がつく表を作った

配布する表の「1_点検」にA列へ番号を貼り、B列で種類を選ぶと、F列に判定が出る。

判定は上から順に見ている。E+を含む文字列ならE表記、数値で16桁以上なら0になった桁がある、決まった桁数より短ければ先頭の0が消えた、カード番号でLuhnが合わなければ打ち間違いか改変。数値で12桁から15桁のものは「今は無事。CSVで保存すると6桁になる」と橙色にした。中身は正しいので、保存さえしなければ使える。

最初から入れてある12行では、赤が7行、橙が1行、緑が4行になる。先頭の0が消えた3行は、G列に0を補った値が出る。16桁目から先が0になった行には何も出さない。この表に貼った時点で、元の数字はもう無いからだ。

「2_1000件」は、この記事の数を数えたシートだ。CSVの文字列はTEXT関数で指数の形にして作り、実際にCSVへ上書き保存して書かれた文字列と1,000件すべてで一致した。「3_桁数の境目」は7桁から20桁までの一覧になっている。

カード番号の列が目の前にある人は、たぶん多くない。私が気にしているのは、12桁と13桁のほうだ。送り状番号や法人番号は事務のCSVに普通に入っていて、開いた直後は無事なので、保存のときに壊れたことに誰も気づかない。

確かめていないこと

自動データ変換の設定を止めた状態では試していない。私の環境では既定のまま試した。

Power Queryの読み込み画面が、16桁の番号の列にどの型を自動で付けるかは、画面からは試していない。整数の型にした状態をM式で作って確かめた。

Excel 2016や2019、Mac版、Googleスプレッドシートでは試していない。

カード番号がLuhnの計算に合うことは、公開されているテスト用の2つの番号で確かめただけで、カード番号の規格の本文は読んでいない。実在のカード番号は使っていない。