Power QueryでCSVの日本語が文字化けするとき、文字コードと元データを切り分ける

Power QueryのCSV文字化けを元byte・文字コード・区切り・型変換に分け、Sourceの設定と元データを照合して戻せる形で修正します。

確認日 2026年10月23日AIものさし編集部

Power QueryでCSVの日本語が文字化けしたら、元ファイルを上書きせず、読み込み時の文字コードと元データを分けて確認します。文字が崩れる問題、列がずれる問題、日付や先頭ゼロが変わる問題は、同じ修正では直りません。最初にどのstepで変化したかを特定します。

この記事はExcelやPower BIのPower QueryでText/CSVを読む診断手順です。実CSVの取得・保存・再変換、ExcelやPower BIの操作、M engineでの実行は行っていません。文字列やファイル構成は説明用の架空例で、特定のexport元が必ず同じ文字コードを使うという説明ではありません。

元のbyteを保管し、症状を三つに分ける

配布されたCSVを複製し、元ファイル名、出力元、export条件、日時を記録します。Excelで開いて保存し直す前のファイルを保管することが重要です。すでに文字化けした表示から別の文字コードで保存すると、誤って解釈した文字を確定してしまい、元のbyteと比較しにくくなります。

表は横にスクロールできます

症状	最初に見る工程	別に扱うこと
日本語が別の記号や文字になる	binaryから文字へのdecode	日付localeの変更
一行が一列、列数がずれる	delimiter・引用符・改行	文字コードだけの変更
00123が123、日付の意味が違う	型検出・型変換	日本語decodeの修正
一部ファイルだけ崩れる	出力元・ファイルごとの設定	folder全体への一律設定

同じファイルで複数の問題が起きることもあります。その場合も一度に設定を変えず、文字が読める段階、列が正しい段階、型が正しい段階を順に確認します。

出力元の文字コードを確認する

CSVという拡張子だけでは、文字コードは確定しません。export画面の選択肢、出力仕様、担当者の説明、元ファイルのBOMなどを手掛かりにします。日本語CSVだから必ずShift-JIS、Windowsで作ったから必ず同じcode pageという判断を避けます。

MicrosoftのText/CSV connector資料（新しいタブで開く）は、File Originで生成時の文字集合を選べること、自動推定には制約があり、UTF-8はBOMがある場合に推定されることを説明しています。先頭の数行が読めたという理由だけで、ファイル全体のdecodeが正しいとしません。

仕様が不明なら、元ファイルの複製と既知の期待文字列を使い、候補の読取設定を比較します。読めそうな文字を多数決で採用するのではなく、人名・住所・記号など元データを照合できる箇所を確認します。期待値を得られない場合は、完全復元したとは判断せず出力元の確認へ戻ります。

SourceのFile Originを先に変更する

DesktopのGet DataからText/CSVを選び、対象ファイルを開きます。NavigatorまたはSourceの設定でFile Originを確認し、出力元の仕様に合わせます。いきなりLoadせず、Transform Dataで後段の変換を点検できるようにします。画面名や選択肢はhostで異なる場合があるため、現行画面に合わせて操作します。

すでにqueryがある場合は、Applied StepsのSource付近から確認します。見出し昇格、型変更、置換など後段のstepを一つずつたどり、文字がどこから壊れるかを見ます。Source時点で崩れているなら、後段で文字を手で置換する前に読取条件を見直します。

表は横にスクロールできます

確認段階	期待する状態	失敗した場合
Sourceの文字	元データの日本語・記号と一致	File Originと元ファイルへ戻る
列の構造	見出し・列数・引用内改行が適切	delimiter/quote設定を確認
型変換前	コードや日付文字列が保持される	自動型検出を点検
型変換後	数値・日付が業務定義と一致	型とlocaleを別に修正

型検出を無効にしてtextとして読む比較は、decodeの誤りと型変換を分けるために役立ちます。ただしtextで読めることと、最終の集計に必要な型が正しいことは別です。

MのEncodingと、Windowsという名前を区別する

Csv.Documentの公式資料（新しいタブで開く）では、Encodingの既定値は65001、UTF-8です。既定値を、すべての入力CSVがUTF-8である保証にはしません。queryのSourceにEncoding指定があるなら、UIで選んだ値と対応するか確認します。

TextEncoding.Type（新しいタブで開く）のTextEncoding.Windowsは1252です。日本語WindowsのCSVを読むための932と同じ値ではありません。MicrosoftのCode Page一覧（新しいタブで開く）は932をJapanese Shift-JISとして掲載しています。出力仕様が932ならその値を使う判断はできますが、日本語という理由だけで強制しません。

Encodingだけを切り替える関数の形は次のように書けます。sourceBinaryには変換前のbinary、codePageには確認できた値を渡す設計例で、M実行確認済みのコードではありません。

(sourceBinary as binary, codePage as number) as table =>
    Csv.Document(
        sourceBinary,
        [Delimiter = ",", Encoding = codePage, QuoteStyle = QuoteStyle.Csv]
    )

Delimiterがcommaではないファイルなら、その条件も別に合わせます。すでに誤ったdecodeを済ませたtextをこの関数へ入れ替えても、失ったbyteを取り戻す処理にはなりません。binaryを読む最初の境界へ戻ることが必要です。

folder結合ではファイルごとの違いを調べる

サンプルファイルが正しくても、同じfolderの別ファイルが別のexport条件なら、結合全体の正しさは保証されません。変換sampleとhelper queryにどのEncoding・delimiterが適用されるかを確認し、崩れた行の元ファイルへ戻れる列を残します。

複数の文字コードが混在していたら、出力元で統一するか、根拠のあるファイル種別ごとに読取を分けます。ファイル内容を毎回推測して無制御に別decodeへ切り替えると、誤判定を追えなくなります。統一できない場合は、どのファイルに何を適用したかと未判定を記録します。

元データにすでに置換文字や不明な記号が保存されている場合は、Encoding変更だけでは元の文字を確定できません。出力元の再exportや原本との照合が必要か確認し、人名などを推測で復元しないようにします。

修正後は文字と列と型を別々に検証する

既知の漢字、かな、半角文字、記号、引用符付きcommaや改行、先頭ゼロのコードを含むサンプルで確認します。これは読者が行う受入条件で、本稿で実ファイルの変換成功を測定したものではありません。冒頭だけでなく、問題が出たファイルと後半の行も元データへ照合します。

queryの変更前後を保存し、期待した文字・行列構造・型が揃わなければ、今回のEncodingや型変換の差分を戻します。元ファイルは修正せず保持し、保存済みの文字化けファイルを再変換し続ける前に、最初の原本から読み直します。完了記録には、確認した文字コードの根拠、適用したSource設定、照合した文字列、未判定のファイルと実行環境を残します。