「文字化け」はなぜ終わらない？ 日本のITを縛る文字エンコーディングの深い闇
問題の概要
普通のPCユーザーでもExcelでCSVファイルを扱う時「文字化け」を経験したことがあると思います。
この「文字化け」は、Excelが古い文字コードと新しい文字コードを両方扱えるよう作られているが故に起きる不幸と言えます。
Mac や Linux が古い文字コード（レガシーデータ）を切り捨ててきたのに対し、互換性とユーザー資産の維持を重視するMicrosoft社は、古い文字コードを使える環境を温存したまま、新しい文字コードを導入しました。
そのため、Windowsユーザーは古い文字コードと、新しい文字コードを、間違えないように注意して使い分ける必要があるのです。
古い文字コードの問題は、Windows環境だけの問題ではありません。
政府や自治体には、膨大な量の「古い文字コードのデータ」が存在します。
日本中の病院など医療機関にも古くから存在する電子カルテなど「古い文字コードのデータ」が存在します。
これらは、データ量が膨大である上に、個人を特定する高い精度が求められるため、現実的な時間の中で「古い文字コードのデータ」を「新しい文字コード」へ変換できません。
また、組み込み機器に搭載される軽量級プロセッサやメモリの中では、メモリ効率の高い「古い文字コード」を使う方が、今でも合理的である側面があり、組み込みソフトウェアの世界では依然として「古い文字コード」が主流です。
これら「古い文字コード」は日本国内でしか使用できないため、グローバル化の障害になることにより、行政のデジタル化と民間のデジタル・トランスフォーメーション（DX）の足かせとなってしまいます。
日本語文字エンコーディングの簡単な解説
文字エンコーディングとは
「文字コード」という言葉を使用しましたが、情報技術の世界では「文字エンコーディング」という呼び方が正しい表現です。
本来、コンピュータは計算機であり、数値を扱う事を本分とする機械です。
文字を扱うには「文字を番号に置き換えて扱う」必要があります。
「文字を番号に置き換える」には、「文字の並び順」をまず定めて、その「並び順」を具体的にコンピュータが扱う「数値」に割り当てる必要があります。
「文字の並び順」を定めたものを「コードポイント」日本語では「(符号化) 文字集合」と呼び、その「コードポイント」を、具体的な「数値」に割り当てたものを、「文字エンコーディング」と呼び、日本語では「(文字) 符号化方式」と呼びます。
| 俗称(英語) | 技術用語 | 解説 |
|---|---|---|
| コードポイント（Code Point） | (符号化) 文字集合 | 文字の並び順を定めたもの |
| 文字エンコーディング (Character Encoding) | (文字) 符号化方式 | コンピュータが扱う具体的な「数値」に割り当てたもの |
このコードポイントと文字エンコーディングの違いは、先の「新しい文字コード」にしか存在しません。
「古い文字コード」では、文字の並び順がそのまま具体的な文字番号に割り当てられています。
しかし、現代では「古い文字コード」も「文字エンコーディングの一種」として扱われます。
歴史的経緯
ASCIIコードとは
ASCII（American Standard Code for Information Interchange）は、1963年にアメリカで策定された文字コードです。7ビットで128文字を表現し、英数字、記号、制御文字を定義しています。
ASCIIの構成
0〜31番と127番は制御文字です。改行（LF: 10）、キャリッジリターン（CR: 13）、タブ（HT: 9）など、画面に表示されない制御用の文字が割り当てられています。
32番はスペース、33〜126番が印字可能文字です。48〜57に数字の0〜9、65〜90に大文字A〜Z、97〜122に小文字a〜zが配置されています。この配置には意味があり、大文字と小文字は32の差で対応しているため、ビット演算で大文字小文字変換ができます。
ASCIIの限界と拡張
7ビット128文字という設計は、英語圏では十分でしたが、それ以外の言語には全く足りませんでした。そこで8ビット目を使った拡張が各地で行われます。128〜255番の領域に、ヨーロッパではアクセント付き文字を、日本では半角カナを割り当てました。
日本語文字エンコーディングの開発
日本の文字エンコーディングの歴史は、コンピュータで日本語を扱うための試行錯誤の連続でした。
JISコードの登場（1978年）
最初の標準化は JIS C 6226（後のJIS X 0208）です。漢字約6,000字とひらがな・カタカナを定義しましたが、これは文字の「集合」を決めただけで、実際にバイト列としてどう表現するかは別問題でした。
三つ巴の時代（1980〜90年代）
ここから日本特有の混乱が始まります。
Shift_JIS は、マイクロソフトとアスキーが開発し、MS-DOSやWindowsで標準となりました。1バイトのASCII/半角カナと2バイトの漢字を混在できる設計が特徴です。
EUC-JP は、UNIX系システムで採用されました。Shift_JISとは互換性がなく、同じ「あ」でも全く違うバイト列になります。
ISO-2022-JP（通称JISコード）は、電子メールの標準として使われました。エスケープシーケンスで文字集合を切り替える方式です。
この時代、「文字化け」は日常茶飯事でした。Windowsで作ったファイルをUNIXで開くと化ける、メールの添付ファイルが読めない、といった問題が頻発しました。
Unicodeによる統一（2000年代〜）
UTF-8の普及により状況は大きく改善されました。Webでは2008年頃にUTF-8がShift_JISを逆転し、現在ではほぼ100%がUTF-8です。
ただし、日本のレガシーシステムには今もShift_JISが残っています。官公庁のシステムや古い業務アプリケーションでは、依然としてShift_JISが現役で、CSVファイルをExcelで開くためにあえてShift_JISで出力する、といった対応も珍しくありません。
米国と日本の文字エンコーディングの関係
ASCIIと日本語エンコーディングの関係
日本語の文字コードはすべてASCIIとの互換性を意識して設計されています。これは、既存の英語ベースのシステムやプロトコルとの共存が必須だったからです。
Shift_JISの設計思想
Shift_JISは、ASCIIの0〜127番をそのまま保持しています。2バイト文字の1バイト目には129〜159、224〜239という「ASCIIと重ならない」範囲を使いました。
ただし落とし穴があります。2バイト目には64〜126という範囲も使うため、バックスラッシュ（\、92番）やチルダ（~、126番）と衝突します。例えば、「表」「能」「ソ」などの漢字の2バイト目が、偶然にもバックスラッシュと同じ値（92）になってしまうケースがあり、これがファイルパスなどで予期せぬエラーを引き起こしました。
これらの文字がファイルパスやエスケープ処理で問題を起こしました。いわゆる「ダメ文字」問題です。
EUC-JPの設計思想
EUC-JPはより慎重な設計で、日本語文字はすべて128以上のバイトのみで構成されます。そのためASCII領域との衝突は起きませんが、半角カナの扱いが複雑になりました。
UTF-8の巧妙さ
UTF-8はASCII互換性を最優先に設計されています。ASCIIの128文字はそのまま1バイトで表現され、既存のASCIIテキストは一切変更なしにUTF-8として有効です。
マルチバイト文字の先頭バイトは必ず192以上、継続バイトは128〜191という規則があり、どのバイトを見ても「ASCII」「先頭」「継続」が判別できます。これによりShift_JISのような「ダメ文字」問題は原理的に発生しません。
新旧文字エンコーディングとは
先の解説にある「古い文字コード」とは、主に Shift_JIS を意味します。
広義には、EUC-JP と JISコード も「古い文字コード」に含まれますが、現在ではほとんど消滅しています。
Shift_JIS だけが現在でも使用される「古い文字コード」に該当します。
「新しい文字コード」とは、Unicode (ユニコード) の事を示し、PC上では主に UTF-8 が使用されています。
また、ソフトウェアの内部では、UTF-16 が多く活用されています。
Windowsの内部ではUTF-16LEが使用され、Javaの内部やPDFではUTF-16BEが使用されます。
この場合、Unicode (ユニコード) が コードポイント(文字集合) を示し、
UTF-8 と UTF-16LE と UTF-16BE が 文字エンコーディング (符号化方式) を示します。
もう一つの類似問題：改行コードの違い
文字エンコーディングの問題とは次元の異なる問題ですが、
日本のITエンジニアが悩まされる類似問題に「Windows と LinuxOS & MacOS での改行コードの違い」があります。
これは文字エンコーディングとは異なり日本だけの問題では無く、世界的な問題であり、技術的には文字エンコーディング問題とは別次元で対策すべき課題です。
しかし、日本の実務の現場では文字エンコーディング問題と改行コード問題はセットで覚えるべき問題となります。
現在の文字エンコーディング利用状況
ネットワークトラフィックの90%が、UTF-8と言われています。
LinuxOS と Apple社製品、そして Android など Google製品は完全に UTF-8 で統一されています。
しかし、先に説明したように Microsoftの Windows は過去のユーザーのShift_JISデータ資産が膨大なため、今でもShift_JISを扱える機構を多数残しています。
特に Excel などMicrosoft Office データには、今からではUTF-8にコンバージョンすることが不可能なほど膨大なShift_JISのデータ資産があり、Shift_JISを扱える機構を削除することは、不可能に近い状況と思われます。
PC環境だけではなく、銀行や政府や自治体の扱う古いデータ資産も気が遠くなるほど膨大なShift_JISデータを抱えています。
病院など医療機関も同様で、さらに電子カルテなどの情報は、個々人を取り違えると患者の命に関わるため、個人情報の正確さが強く求められる分野です。
ここで Shift_JIS から UTF-8 への文字エンコーディング変換で、一部でも「文字化け」する事が許されない分野です。
これらは、現実的には Shift_JIS から UTF-8 への文字エンコーディング変換を現実的な時間の内には、実現できないと考えるのが妥当です。
家電などの組み込みソフトウェアの分野でも、全ての文字が2バイト以内で済むメモリ効率の良さから、 Shift_JIS が積極的に選択されています。
Shift-JISの障害と優位性と必然性
Shift_JIS の障害と限界
Shift_JIS は先頭から全て評価しなければ、正しく日本語文字を判別できない欠点があります。
データ通信などで、文字列が分断されて送信されたとき、Shift_JIS ではバラバラのパケットを全て受け取って結合した上で、先頭からバイト列を読み取らなければ、文字コードを読み取れません。
UTF-8 や UTF-16 は、その部分が良く考えて設計されており、分断された文字列も、文字列の途中から正しく文字コードを読み取れるように作られています。
Shift_JIS は扱える文字の種類にも制限が多く、全体で 11,391文字しか扱えません。
Unicode の UTF-8 や UTF-16 は、最大 1,112,064 文字が扱えます。世界中の文字を扱える設計なので、文字空間が広大になっています。バイト数が多いのもそのせいです。
Shift_JIS の優位性
Shift_JIS と EUC-JP は、英数字はASCIIコードと同じで1バイト、日本語でも全て2バイトで表せます。
この「古い文字コード」は非常にメモリ効率が良く、必ず1バイトか2バイト単位で検索できるので、検索効率も良いです。
UTF-8 では英数字は1バイト、日本語は多く場合 3バイト、サロゲートペアを含むと4バイトの文字も現れます。メモリ制約の大きい組み込みソフトウェアの世界では、UTF-8 のメモリ効率の悪さは無視できません。
UTF-16 においては、大半の文字は2バイトで表せますが、サロゲートペアを含むと4バイトの文字も現れます。
UTF-16 は必ず2バイトか4バイトのどちらかなので検索がやり易く、OSやデータベースやファイルシステムの内部実装には UTF-16 が採用されることが多いです。
しかし、やはり UTF-8 と同様に最大4バイトになる場合があり、全て2バイトに収まる Shift_JIS にはメモリ効率で劣ります。
UTF-8時代にも引きずるShift-JISの経路依存性
経路依存性（Path Dependence）とは、過去の歴史的経緯や初期の選択が、現在の状況や将来の選択肢に強い影響を与え続け、時に非効率な状態でもその慣習や仕組みから抜け出せなくなる現象です。
日本語の文字エンコーディングが、Shift-JIS が広く使われるようになってから、UTF-8 へ移り変わったことにより、さまざまな経路依存性の障害が残っています。
BOM付きUTF-8問題
Excel の CSVファイルの扱いが代表的ですが、Windows環境においてはユーザーが Shift_JIS データを大量にデータ資産として保有していることから、Microsoft社は過去のユーザー資産を守る観点から、Shift_JISデータとUTF-8データを共存できる環境を構築しています。
Shift_JISとUTF-8を共存する為には、両者を明確に区別できなければなりません。
Windowsでは、テキストファイルを扱う場合、UTF-8テキストの先頭には、BOM(Byte Order Mark)という3バイトの識別コードを付ける事を義務づけています。
先頭にBOMが無ければ、そのテキストファイルは Shift_JIS のテキストファイルと解釈されます。
もし、Excel で 先頭にBOMの付いていない UTF-8 の CSVファイルを読み込むと、Shift_JIS のCSVファイルと解釈され文字化けします。
公式の UTF-8 の仕様では、BOM は付けても付けなくても良く、LinuxOSやMacOS、スマホなどでは、BOMの無いUTF-8テキストが使用されています。
しかし、WindowsではUTF-8テキストファイルの先頭には必ずBOMを付ける必要があります。これは、WindowsとLinuxOSやMacOSとの間でテキストファイルを交換するとき、文字化けやデータ読み込み時のエラーなど、さまざまなシステム障害を起こす要因になっています。
Shift_JISとUTF-8を共存させるから、BOMが必要になるので、Shift_JISの経路依存性の問題なのです。
Shift-JISの膨大なレガシーデータ
Shift_JISは、Windows環境だけではなく、メインフレームや古い業務システムでも広範囲に使用されてきました。
そして、銀行や製造業や医療機関や政府・自治体が数十年に渡って扱っているShift_JISデータは、膨大な量になります。
それらのShift_JISデータを今から急にUTF-8に変換しようとしても、現実的な時間とコストの枠内では不可能なデータ量になります。
また、正確にShift_JISデータをUTF-8に変換するには、いくつか障害があり、正確な変換は難しいのが現状です。
この膨大なShift_JISデータを運用していくには、今のところ、古いデータはShift_JISのまま管理し、新しいデータだけUTF-8で扱う、二重構造のシステムにするしか術はないと考えられます。
古いデータは使う時だけUTF-8に変換して閲覧し、文字化けしたら変換前のデータを閲覧できるようにするのが堅実です。
Shift-JIS「外字」問題
Shift_JIS を UTF-8 へ変換することの最も大きな障害になっているのが、「外字」の存在です。
Shift_JIS が扱える文字数は、11,391文字だけです。
日本語の漢字は異体字も含めると 6万字以上あると言われ、戸籍謄本などさまざまな漢字が使用される行政の日本語環境では、Shift_JIS の扱える文字数では全く足りません。
「外字」とは、標準の文字集合に含まれていない文字を、ユーザーやベンダーが独自に追加したものです。Shift_JISでは、この外字のために特定のコード領域が予約されています。
Shift_JISでは、F040〜F9FC の領域がユーザー定義文字用として確保されています。ここには約1,880文字分の空きがあり、企業や自治体が独自の記号、旧字体、人名漢字などを登録して使っています。
典型的な用途は、戸籍システムにおける異体字、企業ロゴや社内記号、地方自治体の地名に使われる特殊な漢字などです。
外字は作成した環境でしか正しく表示できません。外字を含むデータを他のシステムに持っていくと、文字化けするか「〓」や空白になります。また、検索やソートも正しく機能しません。
日本政府が進める「自治体システム標準化」において、最大の障壁の一つとなっているのが、各自治体が独自に運用してきた「外字（Gaiji）」の処理です。日本の戸籍制度においては、氏名や地名にJIS規格（JIS X 0208/0213）に含まれない特殊な漢字が使用されることが許容されてきました。これに対応するため、各自治体ベンダーは、システムの空き領域（外字領域）に独自のビットマップフォントやコードを割り当てて運用してきました。この結果、A市のシステムで作られたデータがB市のシステムでは全く読めない、あるいは別の文字として表示されるという、深刻な相互運用性の欠如が生じています。
デジタル庁およびIPA（独立行政法人情報処理推進機構）は、各自治体ごとにバラバラの外字を「MJ文字情報基盤」として統一する作業を進めています。
しかし、統一できない文字が15文字にも及び、それらを「実際に戸籍で使用されている文字」などで絞り込みを行った結果、連携に必要な文字数は約6万文字、そのうち戸籍運用上必須な文字は約1万文字にまで圧縮されたそうです。
この絞り込みを経て、MJ文字を拡張した文字セット「MJ+」が策定されました。戸籍副本データ管理システムでは、この「MJ+」を用いることで情報連携を行う方針だそうです。
しかし、約6万文字もの巨大な文字セットを、現場の端末ですべて入力・表示・検索できるようにすることは容易ではないことです。
少し、整理すると、Shift_JIS のデータをUTF-8へ変換するには、まず「外字」をUTF-8で扱う規格を定めなければならず、UTF-8で扱えない「外字」に日本全国の自治体で統一された例外処理を開発して導入しなければなりません。
その上、Shift_JIS のデータは政府や自治体だけでも膨大で、その正確なUTF-8への変換には、人間による目視確認がどうしても必要になります。
今ならAIによる画像確認も可能かもしれませんが、単純なコンバージョン処理では済まない事は分かります。
医療機関のShift_JISデータも社会保険制度の関係から、自治体データと同根の問題があり、こちらも膨大な患者情報を有します。
Shift-JISの組み込みシステムでの優位性
AIの登場で、以前ほど話題に上らなくなった IoT ですが、AIとは次元の違う技術なので、依然として開発と進歩は進んでいます。
IoTと深く関わるのが、組み込みソフトウェアの分野です。
先に少し解説しましたが、組み込みソフトウェアでは、メモリ効率の良さから積極的に Shift_JIS を選択することが多いそうです。
日本語一文字あたり Shift_JIS は 2バイト、UTF-8 は多くの場合 3バイトを消費します。これは単純計算でUTF-8がShift_JISの1.5倍の記憶領域を消費することになります。
メモリ環境が乏しい組み込みソフトウェアの世界では、少しでもメモリ消費の少ない Shift_JIS を使うことも当然の選択と言えます。
また、ほぼ2バイト固定長に近い Shift_JIS の文字列は検索処理が単純になり、演算処理は軽量になるのに対し、UTF-8 はバイト数が可変長(一文字、1バイトから4バイトまで4種類の可変長)なので、演算処理が重くなり検索処理には向いていません。
Windowsでも内部処理は、UTF-16LE を使用しています。
組み込みの世界で将来、Unicodeを使用することになっても、エンコーディングは UTF-16 を使用するでしょう。
フォントレンダリングの問題もあります。
現在のPCやスマホ環境では、アウトラインフォントが主流であり、外字や異体字を扱うために必要な技術です。UTF-8 の採用はアウトラインフォントの利用を前提にすることになります。
しかし、組み込みソフトでは外字や異体字を扱う必然性はない。炊飯器や石油ストーブやPOS端末の液晶パネルに複雑な旧字や異体字を表示する必然性はありません。
つまり、アウトラインフォントを使う必然性がないのです。
むしろ演算処理が重くメモリ効率も最悪のアウトラインフォントなどは、無駄なコンピュータリソースの浪費でしかありません。
組み込みでは Shift_JIS の文字集合(並び順)に対応したビットマップフォントが主流であり、このリソース効率の良いビットマップフォントが使えるのも Shift_JIS の魅力の一つと言えます。
整理すると、組み込みや IoT の世界では、Shift_JIS は非常に優れたソリューションと言え、UTF-8 は将来 IoT 機器などがクラウドなどに直接アクセスするようにならない限り、現状では必然性のあるものではないと言えます。
また、全ての組み込み機器がネットワークやクラウドにアクセスするのか、と問われると、個人的には「繋がらない権利」も必要になる気がします。
将来を見ても IoT機器は、製品によっては、どんどん小さくなる方向へ発展する可能性のある製品群なので、メモリや演算リソースが乏しい条件は変わらない気がします。
Shift-JISは完全には放棄できない
Excel で扱うCSVファイルなど、Windows 環境における膨大な過去の Shift_JISデータの蓄積。
政府・自治体・医療機関の抱える膨大な過去の Shift_JISデータ。
組み込みソフトウェアや IoT機器の開発における Shift_JIS のコンピュータ・リソース節約の優位性。
これらを統合して考えた場合、全ての文字エンコーディングを Unicode (UTF-8, UTF-16) に置き換えるのは、ほぼ不可能に近いと思われます。
もちろん、可能な限りUnicode へ転換すべきなのは間違いありません。
例えば、政府や自治体はグローバル化への対応のために、Unicode 対応が必須です。
特定技能の外国人労働者などに住民票を発行する場合、その外国人の名前をデジタル登録できなければ、受け入れに支障を来します。
それは、Unicode を使用しなければ不可能です。
医療や介護の分野でも、外国人看護師や外国人介護士は絶対に必要です。
組み込みソフトウェアの分野でも、 IoT機器はネットワークに接続して、UTF-8 の REST-APIなどにアクセスする必要があります。
この場合は、IoT機器側で UTF-8 か UTF-16 のエンコード処理が必要になるかも知れません。
Unicode 対応が必要であることは、間違い無いのです。
しかし、現実には全ての文字エンコーディングを Unicode にする事は難しいことが、これまでの解説で理解できると思います。
「2025年の崖」と文字エンコーディング問題
2025年現在、日本国内におけるShift_JIS（以下SJIS）データは、ウェブの世界ではほぼ絶滅（シェア0.1%未満）している一方で、「企業の基幹システム」「金融・行政の内部データ」「Excel主体の現場」という3つの領域において、依然として膨大な量のレガシーデータが残存しています。
そのデータ量は、数ペタバイト級、あるいはそれ以上の規模で静かに眠り、また流通し続けています。
経産省のDXレポートでは、2025年を境にレガシーシステムが技術的負債として日本企業全体で12兆円の負担となり、AIなど新規の「攻めの投資」を毀損すると予言しましたが、ほぼ的中していると思います。
数ペタバイト級の膨大なSJISデータをUnicodeに変換するだけでも大変な労力とコストがかかります。
ここに42万人かそれ以上のITエンジニア不足が重なっています。これもDXレポートで予言されていた通りです。
そもそもシステム内部がブラックボックス化していてマイグレーションすらできなくなっています。
NTTデータやSCCKなどがAIを活用したレガシーシステムのマイグレーションサービスをこれから提供するという報道がありましたが、これからマイグレーションサービスを提供するということは、現時点でマイグレーションできていない証拠でもあります。
数ペタバイト級の膨大なSJISデータの存在は、「2025年の崖」を裏付ける「数ある原因の一つ」でもあります。
クラウドやWebの世界だけしか触れていないと、SJISデータの問題は体感できないと思いますが、日本社会のDX推進において、無視できない大きな障害の一つであることは、ITに関わる全ての人々が常識として認識しておくべき社会問題だと思います。
以上、日本特有のレガシーシステムと文字エンコーディングの問題についての解説でした。