Power BIでCSVが文字化けする原因と対策：UTF-8/Shift-JISを見分け、Power Queryで正しく取り込む設定手順

1. CSVの文字化けが起きる「本当の理由」

Power BIにCSVを取り込んだら、日本語が「???」になったり、記号のような文字が混ざったりして読めなくなる。いわゆる「power bi csv 文字化け」でよくあるトラブルです。結論から言うと、ほとんどのケースはCSVの文字コード（UTF-8、Shift-JISなど）と、Power BI（Power Query）が読み込もうとしている文字コードが一致していないことが原因です。

この記事では、文字化けが起きる理由をできるだけかみ砕いて説明したうえで、Power BI Desktopの取り込み画面とPower Query（Mコード含む）の両方で、正しい文字コードに合わせる具体的な手順をまとめます。フォルダー結合（複数CSVをまとめて取り込み）や、更新で突然文字化けするケースの対策まで一通りカバーします。

2. よくある文字コードのパターン（日本語CSV）

現場でよく見るのは、だいたいこの3つです。

(1) Shift-JIS（CP932）

• 昔からの業務システム、Windowsアプリ、Excelの「CSV（コンマ区切り）」で保存

• 日本語Windowsで「ANSI」扱いになることが多い

• Power BI側がUTF-8前提で読むと崩れることがある

(2) UTF-8（BOMあり）

• Excelの「CSV UTF-8（コンマ区切り）」で保存した場合など

• ファイルの先頭に目印（BOM）が付く

• 読み込み側が自動判定しやすく、比較的事故が少ない

(3) UTF-8（BOMなし）

• Webサービスやプログラム出力で多い

• BOMがないので、読む側が誤判定すると文字化けする

• Power BIの取り込み設定が合っていないと崩れやすい

補足として、UTF-16（Unicode）で出力されるCSVもまれにあります。これは見分けがつきやすい一方で、取り込み側の設定を合わせないとやはり化けます。

3. まず確認：そのCSVはUTF-8？Shift-JIS？

最短で確実なのは、「Power BIのプレビューで文字が正しく見える設定を探す」ことです。とはいえ、事前にあたりを付けるだけでも早く解決できます。

手がかり1：どこで作ったCSVか

• Excelの通常保存（CSV）→ Shift-JISの可能性が高い

• Excelで「CSV UTF-8」を選んだ → UTF-8（BOMあり）の可能性が高い

• Webからダウンロード、API出力、SaaSのエクスポート → UTF-8の可能性が高い

• 昔からある基幹系、会計、販売管理など → Shift-JISの可能性が高い

手がかり2：Power BIの先頭列名だけ変な文字になる

先頭の列名の前に見慣れない文字が混ざったり、列名が微妙におかしい場合は、UTF-8（BOMあり）を別の文字コードで読んでしまっている可能性があります。列名が「名前」みたいになるパターンは典型例です（目印のBOMが変な文字として扱われている状態）。

手がかり3：同じフォルダー内のCSVで、正しいものと化けるものが混在

これは「ファイルごとに文字コードが違う」可能性が高いです。後半で、混在時の回避策も紹介します。

4. 取り込み時に直す（Power BI Desktopのテキスト/CSV）

まず、いちばん簡単で効果が高いのが、取り込み画面で「ファイルの起点（文字コード）」を正しく選ぶ方法です。

手順

1. Power BI Desktopを開く

2. ホーム → データの取得 → テキスト/CSV を選ぶ

3. 対象のCSVファイルを選択

4. プレビュー画面が出たら、「ファイルの起点」または「エンコード/文字コード」を確認

5. 日本語が化けていたら、候補を切り替えてプレビューが正常になるものを選ぶ

   • Unicode (UTF-8)

   • Japanese (Shift-JIS) または 932（環境によって表示が違います）

6. プレビューが正常になったら、読み込み もしくは データの変換 を選ぶ

ポイント

• この段階で正しく表示されるなら、そのまま読み込みでも改善することが多い

• ただし「フォルダー結合」や、後でPower Queryのステップを書き換える場合は、Power Query側の設定も確認が必要です

5. すでに取り込んだ後に直す（Power Queryで設定を修正）

「読み込んだ後に気づいた」「更新したら化けた」という場合は、Power Queryエディターでソース設定を見直します。

手順（基本）

1. Power BI Desktop → 変換データ（Power Queryエディターを開く）

2. 左のクエリ一覧から、文字化けしているテーブルを選択

3. 右側の「適用したステップ」を見る

4. 先頭付近の「ソース」ステップの歯車アイコン（設定）を開く

5. 文字コードの選択肢があれば、UTF-8 / Shift-JISを切り替える

6. プレビューで正しく表示される方に合わせてOK

ここで歯車が出ない、または設定項目に文字コードがない場合があります。そのときは「詳細エディター」でMコードを直接確認します。

6. Mコードで確実に固定する（Encodingの指定）

Power Queryは内部でM言語というコードで処理しています。CSV読み込みがMで書かれている場合、Encoding（文字コード）を明示すると安定します。

代表的な考え方

• UTF-8は Encoding=65001

• Shift-JIS相当（Windows日本語のCP932）は Encoding=932

この指定をしておくと、Power BIが勝手に推測して外す事故を減らせます。

例：UTF-8で読む（65001）

例：Shift-JISで読む（932）

重要ポイント

• Delimiter（区切り文字）がカンマ以外（タブ、セミコロン等）の場合もあるので、文字化けだけでなく列ズレがあるならDelimiterも疑ってください

• QuoteStyleが合っていないと、ダブルクォート内の改行やカンマで崩れることがあります。文字化けと同時に起きると判断が難しいので、まずは文字コードを合わせ、その次に区切りや引用符を疑うのが順序として安全です

7. フォルダー結合（複数CSV）で文字化けする場合の直し方

「フォルダーから」取り込んで複数CSVを結合する運用では、文字化けが特に起きやすいです。理由は、結合処理の中で「サンプルファイル」を元に変換関数が作られ、そこでの文字コード設定が全ファイルに適用されるためです。

症状

• 結合後のテーブルで一部の列だけ日本語が崩れる

• ある月のファイルだけ化ける

• 更新したら急に化ける（新しく入ったファイルの文字コードが違う）

対策の手順（考え方）

1. Power Queryで「フォルダー」取り込みのクエリを確認

2. 「サンプル ファイル」や「サンプル ファイルの変換」「変換されたサンプル ファイル」といった名前のクエリが自動生成されているはずです

3. そのサンプル側のCSV読み込みステップを開き、Encodingを正しい値に直す

4. 可能ならMコードでEncodingを固定する

5. これで、結合時の全ファイル読み込みがその文字コードで統一されます

さらに大事な実務ポイント

• フォルダー内のCSVの文字コードが混在していると、どれかに合わせた瞬間に別のファイルが化けます

• 混在が避けられないなら、次の章の「フォールバック読み込み」を検討してください

8. 文字コードが混在しているときの現実的な回避策

理想は「すべてUTF-8に統一」ですが、現実には、取引先や既存システムの都合でShift-JISが混ざることがあります。その場合は、次のどちらかが現実的です。

回避策A：取り込み前に文字コードを統一する

• フォルダーに入る時点でUTF-8に変換しておく

• 運用として一番安定し、更新事故も減ります

• Power BI側のクエリがシンプルになります

回避策B：Power Queryで「まずUTF-8、ダメならShift-JIS」のように読む

Power QueryのMでは try ... otherwise を使えます。完全自動判定ではありませんが、現場での救済策として機能します。

注意点

• この方法は「読めるけど文字が崩れている」ケースを完全には検知できません（エラーにならずに化ける場合があるため）

• それでも、少なくとも読み込みエラーで止まるケースを減らせるので、混在が疑われるときの応急処置になります

• 最終的には、データ提供側での統一が最も堅いです

9. 更新で突然文字化けする理由と、事故を減らす運用

「昨日まで正常だったのに、今日の更新で化けた」という相談は多いです。典型パターンは次のとおりです。

パターン1：新しく出力されたCSVの文字コードが変わった

• 担当者がExcelの保存形式を変えた

• システム改修でUTF-8になった（またはShift-JISに戻った）

• CSV出力ツールの設定が初期化された

パターン2：同じCSVでも、作り方によって文字コードがぶれる

• Excelで「CSV」と「CSV UTF-8」を使い分けてしまう

• 手作業の変換ツールを挟んで、途中で文字コードが変わる

事故を減らす運用のコツ

• 取り込み側（Power Query）でEncodingを固定しておく（推測に任せない）

• フォルダー運用なら「入れるCSVの形式をルール化」し、文字コードも明記する

• 可能なら「UTF-8（BOMあり）」に統一する（自動判定が効きやすく、人の手戻りが減る）

• 月次・日次でファイルを追加する運用は、追加ファイルが混在しやすいので、投入前チェックを習慣化する

10. 文字化けに見えて、実は別問題なケース（切り分け）

最後に、文字化けと間違えやすい問題を整理します。ここを切り分けると、解決が早くなります。

(1) 列がずれる、改行が変になる

• 原因：区切り文字（Delimiter）が違う、引用符（ダブルクォート）処理が合っていない

• 対策：DelimiterやQuoteStyleを見直す

• 文字化けと同時に起きていると混乱するので、まず文字コード、次に区切りの順で確認

(2) 一部だけ記号になる、特定の人名だけ崩れる

• 原因：機種依存文字、外字、環境依存の文字が含まれている

• 対策：元データで使用文字を制限する、置換ルールを作る、別の表記に統一する

• UTF-8/Shift-JISを合わせても残る場合は、この可能性が高い

(3) Power BI Desktopでは正常、サービス更新後だけ崩れる

• 原因：更新時のファイル参照先が変わっている、あるいは更新対象ファイルが別物

• 対策：更新で読んでいるファイルの実体（場所・ファイル名・生成方法）を確認し、文字コードを固定する

• フォルダー内の最新ファイルだけ読む運用は、想定外の混在が起きやすいので注意

11. まとめ：最短で直すチェックリスト

最後に、現場で迷いにくい順番でまとめます。

1. 取り込み画面のプレビューで、ファイルの起点（文字コード）をUTF-8/Shift-JISで切り替え、正しく見える方を選ぶ

2. すでに取り込んだなら、Power Queryのソース設定（歯車）で文字コードを修正する

3. 歯車がない、または運用を安定させたいなら、MコードでEncodingを明示（UTF-8は65001、Shift-JIS相当は932）

4. フォルダー結合なら、サンプルファイル側の変換クエリでEncodingを直し、全体に適用する

5. 混在が疑われる場合は、取り込み前に文字コード統一が最優先。難しいときだけ try ... otherwise のフォールバックを検討する

CSVの文字化けは、原因が分かれば対処はシンプルです。ポイントは「Power BIに推測させない」「運用で文字コードを統一する」の2つ。これだけで、更新のたびに化けるストレスが大幅に減ります。