なぜリトルエンディアンが主流になったか

結論（なぜそうなったのか）

横にスクロール

リトルエンディアンが主流なのは、それが「理論的に優れていた」からではなく、x86 という商業的勝者がそれを採用し、PC 市場を支配したからです。低位バイトを先頭に置く方式には型幅変換や多倍長演算で実装上の小さな利点がありますが、勝敗を決めたのは技術的優劣ではなく市場です。同時に、TCP/IP が定めた「ネットワークバイトオーダー」はビッグエンディアンで固定されたため、世界は「CPU の中はリトル、線の上はビッグ」という分裂を抱えたまま今日に至ります。

当時の状況と競合

エンディアン（endianness）とは、複数バイトからなる数値をメモリ上に並べる順序のことです。32ビット値 0x0A0B0C0D を先頭アドレスから見たとき、次の2流派が対立しました。

「エンディアン」という呼称自体が論争の性格を映しています。語源はジョナサン・スウィフトの『ガリバー旅行記』(1726)で、ゆで卵を丸い端（big end）から割るか尖った端（little end）から割るかで国が二分される風刺でした。この語を計算機用語に持ち込んだのは Danny Cohen の 1980 年の論文 "On Holy Wars and a Plea for Peace" です。Cohen の主眼は「どちらが正しいかを決めることに意味はなく、標準を1つ選んで従うことが重要だ」という点にありました。

ビッグエンディアンには「人間が数字を書く順（大きい桁が左）と一致し読みやすい」という直感的な利点があり、IBM メインフレームや Motorola 68000、初期のインターネット関連 RFC はこちらを採りました。一方リトルエンディアンは、DEC の PDP-11 や Intel の 8080/8086 系が採用しました。

決定打・経緯

リトルエンディアンには、低レイヤ実装で効く実利がありました。

• 型幅変換が容易: 同じ先頭アドレスを指したまま、その値を1バイト・2バイト・4バイト・8バイトのどれとして読むかを選べます。下位バイトが常に先頭にあるため、long を short として読んでもアドレスを補正する必要がありません。ビッグエンディアンでは幅が変わるとオフセットがずれます。
• 多倍長演算の自然さ: 加算は最下位桁から桁上がりしていくので、下位バイトが先頭にある方が「先頭から順に処理する」実装と相性が良い。

ただし現代の CPU ではこれらの差はほぼ無視できる水準で、利点だけでは主流化を説明できません。決定打はビジネスです。Intel 8086 (1978) がリトルエンディアンを採り、IBM PC (1981) がその系譜の 8088 を採用しました。以後 PC 市場は x86 命令セットの後方互換を軸に爆発的に拡大し、エンディアンもその互換性の一部として固定されました。ワークステーションやゲーム機で優勢だったビッグエンディアン勢（SPARC、68k、PowerPC）は市場縮小とともに退場し、Apple ですら 2006 年に PowerPC から x86 へ移行してリトルエンディアンへ転じました。

ARM は興味深い立ち位置です。元々バイエンディアン（両対応、切替可能）として設計されましたが、実運用のエコシステム——Linux ディストリビューション、Android、各種バイナリ——が圧倒的にリトルエンディアンへ寄ったため、事実上リトルエンディアンで運用されるのが標準になりました。RISC-V も既定はリトルエンディアンです。こうして「CPU の中身はリトルエンディアン」がほぼ世界標準になりました。

C 言語ではこの変換を htons / htonl（host to network）と ntohs / ntohl（network to host）で行います。リトルエンディアン機ではバイト入れ替えが走り、ビッグエンディアン機では恒等（何もしない）になります。

uint16_t port = 8080;              // ホスト表現
uint16_t wire = htons(port);       // 線に載せる並び（ビッグエンディアン）へ変換
// リトルエンディアン機では 0x1F90 -> 0x901F にバイトが入れ替わる

今への影響と教訓

この分裂は、今も実務で具体的なコストとして現れます。

• 通信・シリアライズでの明示変換: ソケット通信、独自バイナリプロトコル、ファイルフォーマットでは、バイト順を規約で固定し、読み書き時に変換する必要があります。怠ると、リトルとビッグのマシン間でデータが化けます。
• バグの再現性の低さ: 開発機がリトル、本番の一部がビッグだと、memcpy で整数をそのまま送るような実装は片方でしか壊れず、発見が遅れます。
• ファイル・フォーマットに残る指紋: Unicode の BOM（Byte Order Mark）や、UTF-16／32 に LE/BE の別があるのは、この論争がフォーマット層まで及んでいる証拠です。

普遍の教訓は、標準は「最善」ではなく「最初に十分広まったもの」が勝ち、いったん互換性の制約として凍結されると変換コストが恒久的に残るという点です。Cohen が 1980 年に指摘した「どちらでもよいから1つに揃えよ」は正しかったのですが、CPU 陣営とプロトコル陣営がそれぞれ別々に「1つ」を選んでしまったために、私たちは今も両者を橋渡しし続けています。

CPU がメモリをどう扱うかの土台はOSを、こうした低レイヤ表現がコードにどう現れるかはプログラミングを、ネットワークバイトオーダーが効いてくる通信の仕組みはネットワークを参照してください。