Astra・CodexでCSVの文字化けを調べる｜元ファイルを残す変換手順

CodexでCSVの文字化けを調べるときは、まず元ファイルを保存し、文字コードの候補を確認します。入力の文字コードが確認できてから別名で変換し、全セルの値と件数が変わっていないか照合します。日本語が読めるようになっただけでは、IDの先頭ゼロやセル内の改行まで保たれたとは限りません。

MakeAIでは、架空のCSVを用意し、CodexでPythonの確認処理を作成・実行しました。この記事では、2026年9月8日にmacOS・Python 3.13.12で確認した手順と結果を紹介します。実際の顧客データや、Excel画面での動作確認、モデル間の性能比較は含みません。

変換前に、表示の問題とデータの欠落を分ける

CSVは文字列をファイルへ保存した形式です。保存時の文字コードと、開く側の読み方が合っていない場合、文字が正しく表示されません。まず出力したシステムの設定や仕様で、UTF-8、CP932などの文字コードを確認します。

見えている状態	最初に確認すること	避けたい処理
日本語が崩れて表示される	元の出力設定、別の文字コードでの読み取り、既知の文字列との一致	読めそうな候補を一つ選んで、元ファイルへ上書きする
日本語は読めるが「0012」が「12」になる	ID列が数値として読み込まれていないか	文字コードの変換だけで直ったと扱う
元ファイルにも「?」や置換文字が保存されている	再出力できる原本があるか	AIに失われた文字を推測させる

今回は変換方法を確かめるため、作成時にCP932を指定したデータを使いました。文字コードが分からない実際のファイルでは、読み取りに成功したという理由だけで確定せず、出力元の仕様と、正しいと分かっている値を照合します。

Astra・Codexへ渡す材料と、最初の依頼

Codexはファイルを扱う作業環境、GPT-6 Astraは利用するモデルの選択肢です。2026年9月8日確認のOpenAI公式のモデル案内を参照し、利用できる環境を確認してください。この手順で必要なのは、対象フォルダーのファイルを読み、確認用の処理を実行できることです。

作業用フォルダーへ、取り扱いが認められたCSVのコピーと、分かっている出力条件を置きます。元の保存場所、入力ファイル名、正しく表示されるはずの文字列、取り込み先が求める文字コードをメモにすると、候補を絞る材料になります。

このCSVの文字コードと内容を確認してください。最初は調査だけを行ってください。

入力：［作業用フォルダー内のCSV］
出力元の設定：［分かっている文字コード。分からなければ未確認］
正しいと分かっている値：［例：ID 0012、担当名 髙橋］
取り込み先が求める形式：［例：UTF-8 BOM付き。未確認なら未確認］

・原本と入力ファイルを上書きしないでください。
・UTF-8などの候補で、文字を捨てたり置き換えたりせず読み取れるか確認してください。
・候補ごとの結果と、確定に足りない情報を報告してください。
・件数はCSVとして解析してください。単純な改行数では数えないでください。
・IDや郵便番号を数値へ変換しないでください。
・入力の文字コードが未確認なら、推測で変換を実行しないでください。

この段階の目的は「自動判定の答えを一つもらうこと」ではなく、何を根拠に読み方を決められるかを確認することです。確認に使う代表値は、AIに新しく考えさせず、出力元や原資料から用意します。

架空CSVで確かめた、読める候補と読めない候補

入力は、見出しを除いて3レコード・4列です。普通の日本語に加え、先頭ゼロ、特殊な漢字、カンマ、セル内改行を入れました。以下は元データを読みやすく表示した表です。

顧客ID	担当名	郵便番号	メモ
0012	髙橋	001-0002	一次確認,次回連絡
0007	佐藤	060-0001	午前確認 午後再連絡
0100	田中	100-0001	プラン①

Pythonで、不正な文字を無視せずに読み取る設定を使いました。確認した候補の結果は次のとおりです。

読み取り候補	今回の結果	判断
UTF-8 / UTF-8 BOM対応	読み取りエラー	この入力には使用しない
Shift_JIS	読み取りエラー	今回の「髙」などを含む入力を読み取れない
CP932	読み取り成功。用意した全セルと一致	作成時の設定とも一致するため採用

CP932とShift_JISは、名前が似ていても、この試験で同じ結果にはなりませんでした。Python公式資料では、CP932の別名にWindows-31Jなどが掲載されています。処理に指定する名前まで記録すると、再実行時の食い違いを追いやすくなります。

なお、英数字だけの別のCSVでは、UTF-8・Shift_JIS・CP932のいずれでも同じ文字列として読めました。これは「どの文字コードで作られたかを、読み取り成功だけでは特定できない」例です。

別名で変換し、文字だけでなく全セルを照合する

入力がCP932と確認できた後、今回の出力条件をUTF-8 BOM付きと決めて、別のCSVへ変換しました。BOMは文字コードを示すために先頭へ付く目印です。すべての取り込み先に必要なものではなく、相手の仕様に合わせて有無を選びます。

今回の処理では、読み取った全文をそのまま出力側の文字コードへ変換しました。列を並べ替えたり、表を作り直したりせず、引用符や改行の形も維持します。変換後は出力を読み直し、入力と同じCSVの表になることを確認しました。

入力の文字コードがCP932であることを確認できました。
別名のCSVをUTF-8 BOM付きで作成してください。

合格条件：
・元ファイルの内容が変わっていない。
・見出しを除くレコード数と列数が同じ。
・すべてのセルの文字列が変換前後で一致する。
・先頭ゼロ、特殊な漢字、カンマ、セル内改行が残る。
・読み取りエラーが起きた場合、文字を無視して続行しない。
・出力先に同名ファイルがある場合も上書きしない。

結果は、出力ファイルの場所と確認項目ごとの合否で報告してください。

CSVのメモ欄には改行があるため、この例の物理的な行数は5行ですが、データは3レコードです。単純に改行で分割せず、引用符を理解するCSVの読み取り処理を使います。Pythonのcsvモジュールの説明に沿い、今回は文字列の値を保ったまま解析しました。

実行結果：通常の変換と、止まるべきケースを確認した

通常の変換に加えて、間違った文字コード、途中で切れた文字、出力先の重複などを含む13項目を確認し、すべて期待した結果になりました。主な確認内容をまとめます。

確認内容	実行結果
元ファイルの保持	変換前後のSHA-256が一致。元のバイト列は変更なし
データの形	3レコード・4列を維持。見出しを含む全セルが一致
文字と値	0012、髙橋、プラン①、セル内のカンマと改行を保持
間違った読み取り・途中で切れた文字	エラーで停止し、変換先を作らない
原本や既存出力への上書き	処理を拒否し、既存の内容を保持
すでにUTF-8の入力	同じUTF-8で保存する試験では、元と同じ内容を維持
失われた文字を含むUTF-8	読み取り自体は成功しても、置換文字は残る

SHA-256は、ファイルの内容から計算する照合用の値です。ここでは原本に変更がないかを確認するために使いました。原本と変換後のファイルは文字コードが異なるため、両者のSHA-256が同じであることを求めているわけではありません。

この試験で分かったのは、用意した架空データを、指定した条件で変換・確認できたことです。どんな文字化けでも直せることや、大量の実データで同じ結果になることは、この小さな検証だけでは判断できません。

Excelや取り込み先で開くところまで、確認をつなぐ

CSVの内容が正しくても、開くアプリがID列を数値として扱えば、先頭ゼロが見えなくなる場合があります。財務省のCSV読み込み案内でも、文字コードの選択と、列をテキスト型にする操作は別に説明されています。

Microsoftの案内には、UTF-8 BOM付きのCSVと、データの取り込み機能を使う方法が示されています。手元のExcelの画面やバージョンに合わせて読み込み方を選び、ID、日付、長い番号などの列を確認します。

今回、Excelの画面で開く試験は行っていません。業務へ戻す際は、取り込み先でもレコード数、文字、IDの形式を確かめてから元の処理へ組み込みます。毎回同じCSVで困る場合は、ファイルごとの修復を続ける前に、出力元と取り込み先の形式を揃えられるかを見直してください。

文字化けの症状から、確認する場所を分ける

CSVの問題がすべて文字コードの変換で解決するわけではありません。日本語が読めない、列がずれる、先頭ゼロが消える、日付が変わるという症状は、確認する工程が異なります。次の表は切り分けのための作業案です。ここにある全症状を、今回の13項目の試験で確認したという意味ではありません。

症状	先に調べること	急いで行わないこと
日本語が別の記号になる	出力元の文字コード、読み込み時の指定、既知の文字	複数の変換を原本へ繰り返す
一つの値が複数列になる	区切り文字と引用符、セル内のカンマ	文字コードだけを変更して解決とする
先頭ゼロが消える	ファイルの値と、取り込み先の列の扱い	欠けた桁数を推測して補う
一つのメモが二行に分かれる	CSVとして解析したレコード数と、セル内改行	物理的な改行数をデータ件数とする
既に置換文字が入っている	変換前の原本や、出力元から再取得できるか	読めたことを元の文字の復元と扱う

問題のある値を一つ選び、出力元の画面、保存ファイル、読み取り後の値、取り込み先の画面の順に比べます。どの段階で変わったかが分かれば、再出力が必要なのか、読み方を変えればよいのか、列の設定を変えるのかを判断しやすくなります。正しい値の根拠がない場合は、見た目が自然な文字列を正解として採用しないようにします。

照合結果を、他の担当者が確認できる形にする

変換後の報告を「文字化けを直しました」の一文で終えると、件数やIDが残ったかを利用者が判断できません。入力と出力の名前、採用した文字コード、レコードと列、代表値、全セル照合の結果、未確認の利用先をまとめます。次は報告の形式を示す例で、新しいファイルを処理した結果ではありません。

変換結果の報告欄
原本：ファイル名、保存場所、変換前後に保持を確かめた方法
読み取り：採用した文字コード、その根拠
出力：別名のファイル、文字コード、BOMの有無
構造：見出しを除くレコード数、列数、見出しの順
値：全セルの比較結果、先頭ゼロ・特殊文字・セル内改行
停止条件：読み取り失敗や既存出力がある場合の扱い
利用先：アプリへの取り込みは確認済みか、未実施か
残件：次に誰が何を照合するか

全セルの文字列を比べることと、ファイルのバイト列が同じことは違います。文字コードを変えれば、同じ文字列でも保存するバイト列は変わります。原本の保持は原本の変換前後で比べ、変換結果の内容は読み取り後のセルで比べる、という二つの目的を分けて記録してください。

CSVとして扱う区切りや引用符も、入力と出力で意図せず変えないようにします。Pythonのcsvモジュールの公式説明は、形式ごとの区切りや引用符の設定を扱っています。今回の変換結果を別のシステムへ渡す場合は、文字コードだけでなく、そのシステムが受け取るCSVの条件も確認します。

読める候補が複数ある場合は、追加の根拠を待つ

英数字だけなら複数の文字コードで同じ文字として読めることがあります。読み取り成功の候補が一つに絞れない場合、「最初に成功したので正解」と決めず、出力元の設定や担当者の情報を確認します。すぐに取り込みが必要なら、どの条件が未確認で、その判断を誰が行うかを記録します。

特殊な漢字が含まれる一件だけを除いて変換すれば成功する場合も、除外した件数と内容を隠さないでください。エラーのある行を消す処理は、文字コードの変換とは別のデータ変更です。除外してよい業務か、元のシステムから正しい形式で出し直せるかを確認する必要があります。

既に文字が失われたファイルは、別の文字コードで保存し直しても元の情報が戻るとは限りません。例えば置換文字の位置が分かっても、そこに何の文字があったかをファイルだけで確定できないことがあります。原本、バックアップ、出力元の記録へ戻り、根拠のある復元ができるかを確認します。AIに自然な名前を補わせて修復済みとしないようにします。

毎回同じデータで起きる場合は、処理手順を残し、出力元の設定、変換条件、取り込み先の指定を一つの作業としてそろえます。担当者が変わっても同じ条件で確認できるよう、正常な小さなサンプルと期待する値を保存します。自動化する前には、途中で失敗した場合に出力を使わない条件と、再実行で既存ファイルを上書きしない条件まで決めてください。