BtoB EC移行の文字化けの防ぎ方｜文字コード設計と5ステップ

◆監修・編集責任者　小園 将隆　2026年8月27日

B2B EC-COLUMN

BtoB EC移行の文字化けとは──符号化方式・文字集合・正規化形式の3層のズレ

BtoB EC移行の文字化けとは、移行元と移行先で符号化方式・文字集合・正規化形式のいずれかが一致せず、元の文字が別の字形や置換文字に置き換わる現象です。デジタル庁はシステム間連携の符号化方式をUTF-8とする方針を示しています^*1。

したがって文字化けの防ぎ方は「文字コードをUTF-8にする」だけでは足りません。3層それぞれを設計フェーズで決め、移行テストで検証しておく必要があるでしょう。以下、層ごとに原因を見ていきます。

文字化けの原因切り分けは3層モデルで進める

受発注システムの文字化けを相談されると、原因が符号化方式（エンコーディング。文字をビット列に変換する方式）にあると思い込みがちです。しかし実際には、文字集合（使用可能な文字の範囲）と正規化形式（同じ文字の内部表現の揺れ）のいずれかがずれているケースも珍しくありません。

3層のどこがずれているかを先に切り分けることで、対策の的が絞れます。符号化方式は変換ツールで直せる一方、文字集合の不一致には業務ルールの見直しが必要になります。

第1層＝符号化方式のズレ──Shift_JIS系ラベルと置換文字U+FFFD

符号化方式（エンコーディング）とは、文字をコンピュータが扱うビット列へ変換する規則です。Web標準を策定するWHATWGのEncoding Standardは、新規のプロトコル・フォーマットにはUTF-8のみを使うべきだと規定しています^*3。

移行元の基幹システムは、Shift_JIS系の符号化方式で運用されている場合が多いはずです。shift_jis・sjis・windows-31j といった複数のラベルは、実装上は同一の符号化方式として扱われます^*3。この環境で変換に失敗した文字は置換文字U+FFFDに置き換わり^*3、元の文字情報が失われてしまいます。いったん失われた情報は復元不可能です。だからこそ、変換前の原本を保持しておくことが欠かせません。

第2層＝文字集合のズレ──外字・機種依存文字とJIS X 0213の文字数

文字集合とは、そのシステムが扱える文字の範囲そのものを指します。デジタル庁の資料では、地方公共団体の外字・ベンダ固有外字がおよそ200万文字に達したと報告されています^*1。

比較の目安として、JIS X 0213は10,050文字、常用漢字は2,136文字です^*1。取引先名の「髙」「﨑」のような外字は、移行先の文字集合に含まれていなければ、たとえ符号化方式を揃えても正しく表示できません。

第3層＝正規化形式のズレ──NFCとNFDで変わる「が」の内部表現

正規化形式とは、見た目が同じ文字でも複数通りある内部表現を、比較・検索のために一意な形へ揃える規則です。Unicode Consortiumの規格（UAX #15）では、NFC（正準分解の後に正準合成）とNFD（正準分解のみ）が定義されています^*4。

「が」は「が」という1文字（合成済み）で表現される場合と、「か」＋濁点の2文字（分解形）で表現される場合があります。この違いはNFCで揃えない限り、同じ取引先名でも別レコードとして扱われてしまいます。

BtoB ECで文字化けしやすい5つのデータ

ここまでの3層モデルを踏まえ、BtoB EC移行で実際に文字化けが起きやすいデータを5つに分けて具体化しましょう。抽象論ではなく、自社のどのマスタ・ファイルが対象になるかで確認してください。

取引先マスタの法人名・屋号（髙／﨑／㈱などの環境依存文字）

取引先マスタの法人名・担当者名は、文字集合のズレが最も表面化しやすい箇所です。「髙」「﨑」のような異体字や、㈱・㈲などの機種依存記号は、移行先が対応する文字集合に含まれているかを個別に確認する必要があります。

商品マスタの型番・仕様表記（波ダッシュ、全角チルダ、丸数字、単位記号）

商品マスタの型番や仕様欄には、波ダッシュ・全角チルダ・丸数字・単位記号（㎡・℃等）が使われがちです。これらは正規化形式や文字集合の違いによって、見た目が微妙に異なる別の文字へ置き換わることがあります。

住所・部署・担当者名（自治体システムでの外字報告）

住所・部署・担当者名も外字が集中する領域です。前述のとおり、地方公共団体の外字・ベンダ固有外字はおよそ200万文字に達したと報告されています^*1。民間のBtoB ECでも同種の外字が取引先データに紛れ込んでいる可能性があります。ここは行政システムの報告であり、民間EC一般の統計ではない点に注意が必要です。

CSV・EDIの連携ファイル（charsetパラメータとBOM有無）

CSVファイルの標準仕様であるRFC 4180では、文字コードの指定にIANA登録のcharsetパラメータを用いてよいとされています^*5。一方でMicrosoftの公式サポート文書によれば、BOM（バイトオーダーマーク）付きUTF-8のCSVはExcelで正常に開けます。BOMなしの場合はPower Queryなど別の取込方法が必要になります^*6。EDI連携ファイルも同様に、送信側と受信側でcharsetとBOM有無の取り決めがずれると、CSVを開いた瞬間に文字化けとして発覚します。

帳票・メール添付ファイルの文字化け

受発注確認メールや請求書PDFなど、システム外に出力される帳票・メール添付ファイルも見落とされがちな経路です。デコードに失敗した文字は置換文字（U+FFFD）として表示されるため^*3、取引先へ送付する帳票でこれが発生すると信用問題に直結します。

移行前に決める文字コード設計の4つの決定事項

文字化けを防ぐ核心は、移行テストの場当たり的な確認ではなく、設計フェーズで4つの事項をあらかじめ決めておくことにあります。決める人と成果物を明確にすることで、ベンダーとの認識合わせがスムーズになるでしょう。

決定1：符号化方式はUTF-8に統一する

デジタル庁は標準準拠システム間の連携における符号化方式をUTF-8とする方針を示しています^*1。WHATWGのEncoding Standardも、新規のプロトコル・フォーマットにはUTF-8のみを使うべきだとしています^*3。移行元がShift_JIS系であっても、連携インターフェースはUTF-8へ統一するのが公的な設計方針と整合します。

決定2：正規化形式をNFCに固定し、比較・名寄せの前に正規化する

Unicode Consortiumの規格では、同じ文字でも複数の内部表現があり得ることが定義されています^*4。名寄せや検索の前提として、正規化形式をNFCに固定するルールを移行設計に含める必要があります。

決定3：扱えない文字の縮退ルールを事前に決める

移行先の文字集合に無い文字は、代替字へ「縮退」させる判断が必要になります。一般社団法人 文字情報技術促進協議会が公開するMJ縮退マップは、約6万文字のMJ文字集合と約1万文字のJIS X 0213との対応関係を整理したものです^*7。どの文字をどの代替字に寄せるかを、誰が決裁するかまで含めて事前に合意しておくことが実務の要になります。

決定4：フォント側の制約も設計に含める

行政事務標準文字は約7万字の文字セットです。一般的なシステムで実装可能なフォントファイルの上限は約6万5千字とされ、複数のフォントファイルを組み合わせる必要があると報告されています^*2。これは行政システムの検討会報告であり、民間EC統計ではありません。「文字集合を揃えても表示側のフォント実装が追いつかない」という論点は、BtoB ECのフォント選定でも参考になります。

文字化けの防ぎ方──検証手順5ステップ

4つの決定事項を設計したら、次は移行テストで実際に検証します。以下の5ステップで進めると、抜け漏れなく確認できます。

1. 移行元の文字棚卸し：対象テーブル・カラムに出現する文字を一覧化し、機種依存文字・外字を洗い出します。
2. 変換ルール表の作成：符号化方式（決定1）・正規化形式（決定2）・縮退ルール（決定3）の3点を1枚の表にまとめます。
3. テスト移行と往復変換検査：移行元から移行先へ変換した後、逆方向にも変換し直して元の文字に戻るかを確認します。戻らない文字は不可逆な変換として個別に扱います。
4. 4経路での確認：画面表示・帳票PDF・メール通知・CSV/EDI出力の4つの出力経路それぞれで文字化けの有無を確認します。1つの経路で問題が無くても、他の経路では発生することがあるためです。
5. 本番移行後の差分検査：本番移行の直後に、移行元と移行先のデータを突き合わせて差分を検査し、発見した文字化けの是正手順をあらかじめ決めておきます。

文字化けを放置したときの業務・法令リスク

文字化けは見た目の問題にとどまらず、放置すると業務と法令対応の両面に影響が及びます。

取引先の名寄せ・検索が機能しなくなる

正規化形式がずれたまま移行すると、同一の取引先が別レコードとして扱われることがあります。名寄せができなければ、与信管理や取引実績の集計そのものが崩れかねません。

電子帳簿保存法の検索要件に影響する

国税庁の電子帳簿保存法一問一答（電子取引関係）は、電子取引データの検索機能について要件を挙げています。その一つが「取引年月日その他の日付、取引金額及び取引先を検索の条件として設定することができること」です^*8。取引先名が文字化けしたまま保存されると、この検索要件を満たせなくなるおそれがあります。

誤出荷・請求ミス・与信判断への波及

型番や仕様表記の文字化けは、誤出荷や請求ミスに直結します。取引先名の文字化けによる名寄せの失敗は、与信判断を誤らせる要因にもなりえるでしょう。移行時の文字化けは「表示上の不具合」ではなく「業務判断の前提を崩すリスク」として扱う必要があります。

自社の取引先マスタにどれだけの外字が潜んでいるかは、棚卸しをしてみるまで分かりません。無料相談で移行要件を整理するところから始めるのが近道です。

発注側が持つべき受入チェックリストと体制

発注側とベンダーの分担（誰が縮退を決裁するか）

文字コード設計は、ベンダー任せにも発注側だけの判断にもできません。符号化方式・正規化形式の技術的な実装を担うのはベンダー側でしょう。一方で、扱えない文字をどの代替字に寄せるかという縮退の判断は、業務内容を理解した発注側でなければ決められません。

内製でこの作業を進めるには、文字コードの技術知識に加え、データベースの照合・EDI仕様の理解・自社マスタの業務知識という複数領域の知識が必要になります。専門パートナーに依頼する場合は、これらの領域を横断した設計と検証を一括して任せられる点が内製との差になります。

受入テストのチェックリスト（合否の判定基準つき）

まとめ：文字コード設計を移行計画の初期に決める

本稿ではBtoB EC移行における文字化けの防ぎ方を整理しました。要点を3つに集約すると次のとおりです。第一に、原因は符号化方式・文字集合・正規化形式の3層に分けて切り分けることが出発点になります。第二に、UTF-8統一・NFC固定・縮退ルール・フォント制約という4つの決定事項を設計フェーズで先に決めておくことが肝心です。第三に、棚卸しから本番後の差分検査まで5ステップで検証し、4つの出力経路すべてを確認します。これらを移行計画の初期に組み込むことが、受入テストを迷わず終えるための土台になるはずです。

---

ご不明な点はお問い合わせフォームからもご連絡いただけます。

よくある質問

移行後に文字化けが見つかった場合、後から直せますか。

後から個別に直すことは可能ですが、原因を3層のどこかまで切り分けないと再発を防げません。まず文字棚卸しをやり直し、符号化方式・文字集合・正規化形式のどこがずれているかを特定したうえで、縮退対応表を更新する手順を推奨します。

UTF-8に統一すれば文字化けは起きないのですか。

UTF-8への統一だけでは不足です。デジタル庁は符号化方式をUTF-8とする方針を示しています^*1。それとは別に、文字集合（扱える文字の範囲）と正規化形式（内部表現の揺れ）のズレも文字化けの原因になります。3層すべての設計が必要です。

外字はそのまま新システムへ持ち込めますか。

移行先の文字集合に含まれていない外字は、そのままでは持ち込めません。一般社団法人 文字情報技術促進協議会のMJ縮退マップのように、扱えない文字を代替字に対応づける仕組みを用いて^*7、事前に縮退ルールを決めておく必要があります。

CSVをExcelで開くと化けるのはシステム側の不具合ですか。

システムの不具合とは限りません。Microsoftの公式サポート文書によれば、BOM付きUTF-8のCSVは通常どおり開けますが、BOMなしの場合は別の取込方法が必要です^*6。CSV出力側のBOM有無の設定を確認してください。

1. *1　出典：デジタル庁 デジタル社会共通機能グループ 地方業務システム基盤チーム「文字要件説明資料（地方公共団体情報システムデータ要件・連携要件標準仕様書【第2.0版】）」（2023年6月）
2. *2　出典：地方公共団体情報システムにおける文字要件の運用に関する検討会「地方公共団体情報システムにおける文字要件の運用に関する検討会報告書」（令和6年7月）
3. *3　出典：WHATWG「Encoding Standard」（Living Standard、2026年5月21日更新分を確認）
4. *4　出典：Unicode Consortium「Unicode Standard Annex #15: Unicode Normalization Forms」（Version 17.0.0、2025年7月30日）
5. *5　出典：IETF「RFC 4180: Common Format and MIME Type for Comma-Separated Values (CSV) Files」（2005年10月）
6. *6　出典：Microsoft「Opening CSV UTF-8 files correctly in Excel」（Microsoft Support、2026年8月27日確認）
7. *7　出典：一般社団法人 文字情報技術促進協議会「MJ縮退マップ Ver.1.2.0」（2018年1月26日公開）
8. *8　出典：国税庁「電子帳簿保存法一問一答【電子取引関係】」（令和7年6月）