Excelのシートを開いて、Ctrlキーを押しながら下矢印を押す。一気に最下段まで飛ぶ。そこに出ている行番号が 1048576 だ。
中途半端な数字に見える。100万でも、120万でもない。なぜここで止まるのか。
調べてみたら、行と列とで、止まっている理由がまったく違った。片方は本当に器の限界で、もう片方は人が引いた線だった。そこがこの話のいちばん面白いところだった。
この記事は育ちます。公開後も、会話パート・トーク・補足を足していきます。
公開 2026-09-24 ／ 最終更新 2026-09-24（公開）
水深 — まず、いまの上限を確認しておく
マイクロソフトが「Excel の仕様および制限」というページで公開している。抜き出すとこうだ。
- 1シートの上限：1,048,576行 × 16,384列
- いちばん右下のセル：XFD1048576
- 1セルに入る文字数：32,767文字
- 列の幅：255文字
- 行の高さ：409ポイント
- 数式の長さ：8,192文字
- 関数のネスト：64レベル
- 1つの関数に渡せる引数：255個
- ブック内のシート数：使用可能メモリによる
最後の1行が少し不気味だ。シート数だけは数字ではなく「メモリ次第」と書いてある。
古い形式（拡張子が .xls だった時代、Excel 97〜2003）はこうだった。
- 65,536行 × 256列
- いちばん右下のセル：IV65536
並べると、全部2の累乗になっている。
- 1,048,576 ＝ 2の20乗
- 16,384 ＝ 2の14乗
- 65,536 ＝ 2の16乗
- 256 ＝ 2の8乗
コンピュータの世界では珍しくない。ただ「2の累乗だから」で終わらせると、いちばん面白いところを取り逃がす。同じ2の累乗でも、そうなっている理由が全然違うからだ。
列の16,384は、ドルマーク2つに食われた数字
先に列の話をする。こちらは理由がはっきりしている。
Excelのファイル形式の内部仕様は公開されていて、そこに列の位置をどう持っているかが書いてある。列は2バイト＝16ビットだ。16ビットあれば65,536通り表現できる。それなのに列は16,384までしかない。4分の1しか使っていない。
16ビットのうち、2ビットが別の用途に取られているからだ。
その2ビットが何かというと、相対参照か絶対参照かのフラグ。数式に書く「$」のことだ。
行に$がついているか。列に$がついているか。この2つの真偽を、列番号と同じ2バイトの中に同居させている。仕様書には col が14ビット、そのあとに1ビットずつフラグが並ぶ、と明記されている。
16 − 2 ＝ 14。残った14ビットで表せるのが、2の14乗＝16,384。
「$A$1」のドルマーク2つを表現するために、列の本数が4分の1になった、ということになる。数式に何気なく打っている$が、シートの横幅を決めていた。
もちろん、$を使わなければ列が増えるわけではない。フラグの場所は使う使わないにかかわらず常に確保されている。使っていなくても場所は取られる。マンションの駐車場みたいなものだ。
昔の256列は、器の問題ですらなかった
では、その前の256列はどうだったのか。
ここで意外なことが分かった。旧形式（.xls）の仕様書を見ると、列のフィールドはすでに2バイトあった。65,536通り表現できる。それなのに仕様書にはこう書いてある。
「0x00FF（＝255）以下でなければならない」。
つまり256列は、器の限界ではなく、仕様上の縛りだった。入るのに入れなかった。
なぜ縛ったのかについては、もっと古い形式（Excel 2.x〜3.0のころ）では列を1バイトで持っていたから、その名残だという説明が一般的だ。ただしこれはマイクロソフトの一次資料では確認できなかった。もっともらしいが、裏は取れていない。
一方で、旧形式の65,536行のほうは、正真正銘のビット幅由来だ。仕様書には、セルのレコードが6バイトで始まり、最初の2バイトが行、次の2バイトが列、最後の2バイトが書式を指す、と書いてある。行が2バイト＝16ビットだから、2の16乗＝65,536。ここは疑う余地がない。
行の1,048,576は、器の限界ではない
では現行の行はどうか。ここが逆だった。
新しい形式の仕様書を見ると、行の位置は4バイト＝32ビットで持っている。32ビットあれば約43億まで表現できる。器としては、43億行入る。
それなのに、同じ仕様書にこう書いてある。「1048576より小さくなければならない」。
つまり1,048,576行は、入れ物の限界ではない。引かれた線だ。列とは性質がまったく違う。
しかもこの線は、Excelというソフトの都合を超えている。ISO/IEC 29500という国際規格に「行番号は1から1048576の範囲の整数」と明記されていて、いちばん右下のセルがXFD1048576であることまで規格文書に書かれている。世界標準として1,048,576という数字が固定されている。
ではなぜ2の20乗で止めたのか。ここは調べても、マイクロソフト自身の説明を見つけられなかった。
「100万を超える最小の2の累乗だから」という推測はもっともらしい。当時のExcel開発チームのブログに書かれている可能性もあるのだが、そのブログサービス自体が終了していて、記事にたどり着けなかった。分からないものは分からない、としておく。
よく「1,048,576行は32ビットの制約だ」と説明している記事を見かけるが、これは違う。32ビット（4バイト）の器に入っているのに、その手前で止めている。制約されているのは列のほうだ。行と列を取り違えている説明が、かなり流通している。
「1,500パーセント増」という言い方
2007年にこの新しいグリッドが出たとき、開発責任者はこう説明していた。
「1,048,576行 × 16,384列。Excel 2003より行が1,500パーセント増、列が6,300パーセント増」。
妙な言い方だが、計算は合っている。1,048,576 ÷ 65,536 ＝ 16倍。16倍は「1,500パーセント増」だ。16,384 ÷ 256 ＝ 64倍で「6,300パーセント増」。「16倍」と言うより「1,500パーセント増」と言うほうが景気がいいという判断だったのだと思う。
ちなみにマイクロソフトはこの新グリッドを社内で「Big Grid」と呼んでいた。俗称ではなく、公式の開発者向けドキュメントにその名前でクォート付きで出てくる。
総セル数で見るともっとすっきりする。
- 新：1,048,576 × 16,384 ＝ 17,179,869,184（2の34乗）
- 旧：65,536 × 256 ＝ 16,777,216（2の24乗）
ちょうど1,024倍。マイクロソフトが当時「1,000倍以上のセル数」と言っていたのは、この数字のことだった。
全部埋めると128ギガバイト
では、そのグリッドを全部埋めたらどうなるのか。
仮に1セルあたり8バイトだとして、171億セル × 8バイト ＝ 約128ギガバイト。実際のExcelは空のセルを持たない作りになっているので本当にこの量を確保するわけではないが、規模感としてはそういう話だ。
メモリ側の事情も公開されている。Excel 2007のとき、数式とピボットに使えるメモリは2ギガバイトまで拡張された。それ以前は、2003が1ギガバイト、2002が128メガバイト、2000が64メガバイト。
64メガバイトの時代に1シート171億セルを用意しても、意味がなかったはずだ。グリッドを広げられたのは、メモリが追いついたからということになる。
そして同じドキュメントに、マイクロソフト自身がこう書いている。
「Big Gridでは、パフォーマンスが本当に重要になる。計算が遅いと利用者は集中しづらくなり、ミスが増える」。
広げた本人が、広げたことの副作用を認めている。ここが「なぜもっと増やさなかったか」の答えに近い気がする。
暗礁① — 列全体参照が、16倍重くなった
ここから実務の話に降ろす。100万行に届くことは、まずない。その前に別のところが壊れる。
マイクロソフトが公式のパフォーマンス解説で、はっきり警告しているものがある。
列全体を参照する数式だ。A:A のような書き方をすると、空のセルまで含めて全部を計算しようとする。ドキュメントの表現をそのまま訳すと「100万行が使えるようになったことで、列全体を参照する配列数式は極端に遅くなる」。
行数を16倍にしたせいで、この書き方は16倍重くなった。広くしたことで、広さを前提にした書き方が自分の首を絞めている。
マイクロソフトが推奨しているのはテーブル（構造化参照）だ。データの増減に合わせて範囲が自動で伸び縮みするので、列全体を指す必要がなくなる。「列全体参照や動的範囲より、パフォーマンス上の不利が少ない」と明記されている。
暗礁② — 使用済み範囲が、勝手に膨らむ
もうひとつが使用済み範囲の肥大化。
列全体を選んで書式を設定する。色を塗る。罫線を引く。それだけでExcelは「ここまで使われている」と記憶する。Ctrl+Endを押すと、何もないはずの右下に飛ぶ、あの現象だ。
中身は空なのに、ファイルサイズだけが膨らむ。マイクロソフトのドキュメントも「編集や書式設定の操作によって、使用済み範囲が現在使っていると考えている範囲をはるかに超えて広がることがある。これはパフォーマンスとファイルサイズの障害になりうる」と書いている。
広いグリッドは、うっかり広く使ってしまえる、ということでもある。
暗礁③ — 揮発性関数
三つめは揮発性関数と呼ばれるものだ。
シートのどこかを1か所いじっただけで、再計算が走る関数がある。名指しで挙げられているのは INDIRECT、OFFSET、CELL（引数によっては）、ピボットを参照するデータベース関数など。
これらを大量に使っていると、1セル直しただけで全体が再計算される。行数が多いほど、この代償が大きくなる。
INDIRECTやOFFSETは便利なので、シートを器用に組もうとするほど使いたくなる。器用に組んだシートほど重いという逆転が、ここで起きる。
暗礁④ — 行数の前に、ファイルサイズで詰む
そして実務でいちばん先に来るのがこれだ。共有できなくなる。
- SharePointに置けるブック：0〜100メガバイト（設定による）
- Outlook Web Appの添付をブラウザで開く：10メガバイト未満
- Excel for the web：合計250メガバイト
- 32ビット版Excelのデータモデル：実質500〜700メガバイト
32ビット版のExcelはそもそも使えるメモリが2ギガバイト（64ビットWindows上では4ギガバイト）に制限されている。64ビット版には「ファイルサイズのハード上限はない」と書かれているが、実際には端末のメモリで頭打ちになる。マイクロソフトの推奨は「32ビット環境なら最低3ギガバイトのRAM」だ。
つまり実務では「100万行に届いた」ではなく「重くて送れない」「ブラウザで開けない」で先に詰まる。
これは以前に書いたExcelが重いのは、1つのファイルに時間を溜めているからと同じ話だ。上限は遠いのに、体感の限界はずっと手前にある。
行数より怖い、15桁の話
行の上限より、実務でよほど怖い制限がある。
Excelは数値を15桁までしか正確に持てない。
16桁以上の数字を数値として入力すると、16桁目以降が黙ってゼロになる。警告は出ない。マイクロソフトのサポート文書も、クレジットカード番号を例に挙げてこの挙動を説明している。
クレジットカード番号。長い取引ID。桁数の多い伝票番号。マイナンバー。見た目は入っているのに、末尾が変わっている。しかも変わったことに気づく手がかりがない。
行が100万行あることより、こちらのほうが実害が出る。
対策は単純だ。計算しない数字は、文字列として持つ。列の書式をあらかじめ文字列にしておくか、先頭にアポストロフィを打つ。CSVから読み込むときは、読み込みウィザードで該当列を「文字列」に指定する。
数字に見えるものを全部数値として入れる癖が、いちばん危ない。
ほかにも、2の累乗が並んでいる
仕様表を眺めていると、ほかにも見覚えのある数字が出てくる。
- 1セルの文字数 32,767 ＝ 2の15乗 − 1（符号ビット1つぶん足りない）
- 非連続で選択できるセル数 2,147,483,648 ＝ 2の31乗
- ハイパーリンク数 65,530（2の16乗の少し手前）
- セル書式の種類 65,490（同上）
3つめが面白い。非連続に選択できるセル数は2の31乗、約21億。ところがグリッド全体は171億セルある。
つまり「全セルを非連続で選択する」ことは、仕様上できない。やろうとする人はいないだろうが、できないことになっている。
もうひとつ、プロセッサのコア数は64までと書かれている。それ以上のコアを積んだマシンを使っても、Excelは64までしか使わない。行を増やしても、並列度はここで頭打ちになる。
毎日ぶつかっているのは、もっと小さい上限のほう
100万行や1万6千列は、一生使い切らない。それより、仕様表の地味な行のほうが実務では効いてくる。
- オートフィルタのドロップダウンに出る項目数：10,000件
- 元に戻す（Undo）の回数：100回
- 関数のネスト：64レベル
- 1つの関数の引数：255個
- セル書式の種類：65,490
ひとつめ。オートフィルタの一覧に出るのは1万件までだ。取引先コードや商品コードで絞ろうとして、一覧に出てこない。「消えた」と思ってデータを疑ったことがあるなら、これが原因かもしれない。1万件を超えると、一覧からは選べず、検索ボックスで探すしかなくなる。
ふたつめ。元に戻せるのは100回まで。しかもExcelのUndoはブック単位ではなくアプリケーション単位で、他のブックでの操作も同じ100回を食う。並行して何冊も開いて作業していると、思ったより早く底をつく。
マクロを実行すると、そこでUndo履歴が消えることもある。「戻せると思っていたのに戻せない」の多くは、行数ではなくこちらの上限に当たっている。
三つめのネスト64レベルは、普通に書いていれば当たらない。ただしIFを延々とつないだ数式は、読めなくなるほうが先に問題になる。上限に当たる前に、人間のほうが限界を迎える。
こうして並べてみると、Excelの上限は「派手な数字ほど遠く、地味な数字ほど近い」という構造になっている。ニュースになるのは100万行のほうだが、実務で手が止まるのは1万件と100回のほうだ。
航路 — 100万行を超えたら、どうするか
CSVを開いて100万行を超えていると、Excelは警告を出す。
「このデータセットはExcelのグリッドに対して大きすぎます。このブックを保存すると、読み込まれなかったデータは失われます」。
黙って切られるわけではない。ただし、警告を読み飛ばして保存すれば同じことだ。会計の実務で、これがいちばん怖いパターンだと思う。データが減ったことに、あとから気づく。
このときの正攻法は、シートに載せないことだ。Excelの「データの取得」（Power Query）で読み込めば、グリッドを経由せずに集計できる。マイクロソフト自身がこの手順を案内している。
そもそもExcelは、20億行を扱える
最後にひとつ。「Excelは100万行までしか扱えない」は、正確には間違いだ。
100万行なのはシート（グリッド）の上限であって、Excelの中にあるデータモデルの上限は違う。
- データモデルの1テーブルの行数：1,999,999,997行（約20億行）
- テーブル数：約21億
- 1テーブルの列数：約21億
- 1列の一意な値：約20億
- 文字列の長さ：536,870,912バイト（512メガバイト）
約20億行。グリッドの2,000倍近く入る。画面に並べられないだけで、集計はできる。
「Excelでは無理だからデータベースを立てましょう」と言われる場面の何割かは、実はExcelのままで足りる。ただし32ビット版では500〜700メガバイトあたりで頭打ちになるので、本気でやるなら64ビット版が要る。
ついでに言うと、ピボットテーブルの1フィールドあたりの一意な項目数も1,048,576だ。グリッドの行数と同じ数字が揃えてある。偶然ではない。
縦と横で、限界の意味が違っていた
30年前、Excel 5.0の1シートは16,384行だったと言われている（ここは二次情報なので断定は避ける）。その数字が、いまは列の本数になっている。1シートまるごとぶんの容量が、横方向に化けた。
Ctrl+↓で飛んだ先の1048576という数字は、ただの区切りではなかった。
列は器の限界。行は引いた線。同じシートの縦と横で、限界の意味がまるで違う。そして実務でぶつかるのはそのどちらでもなく、ファイルサイズと15桁のほうだった。
数字の限界という意味では、〆という字のほうがよほど不確かだった。毎日書いているのに、由来が決着していない。
この記事は、まだ書きかけです
この記事は、公開してから足していく形にしています。調べたことを書いた本文がまず先にあって、あとから「聞き手と話し手の会話」「あとで思い出したこと」「読んだ人から教わった補足」が積もっていきます。
だから、同じURLでも半年後には別のものになっているはずです。もし一度読んだことがある記事なら、下の更新ログだけ見てください。増えたところが分かります。
更新ログ
- 2026-09-24 公開（本文のみ。会話パートはこれから足します）
