Codex文字化けの直し方｜Windows確認手順と原因の見分け方

Codex文字化けは「4つの場所」に分けて考える

文字化けという同じ見た目でも、原因の場所は一つではありません。Codexが返した文字列自体、文字列を描画する端末、応答を受け取るクリップボード、そしてファイルへ保存されたバイト列は、それぞれ別の層です。たとえば画面では正常な日本語が見えているのに、メモ帳へ貼り付けると崩れるなら、モデルや保存ファイルを疑う前にコピー経路を確認するべきです。逆に、Codexの返答を画面でもファイルでも読めないなら、端末だけを設定し直しても改善しない可能性があります。最初に「どこからどこまで正常か」を決めると、修正範囲を小さくできます。

画面だけが崩れている場合

Codexの返答を別の場所へ保存すると日本語が正常なのに、実行中の端末だけが「縺」や「ã」で表示されるなら、主な確認対象は端末のフォント、出力の解釈、シェルの設定です。この場合、モデルを変更したり同じ質問を何度も送り直したりする前に、英数字と日本語を一行ずつ含む短い返答を同じ端末で表示します。日本語だけが崩れているか、罫線や記号も崩れているかで、文字コードの問題と描画の問題をさらに分けられます。

Windows TerminalはUnicodeとUTF-8文字の表示に対応しています。したがって、古いコンソールでは崩れるがWindows Terminalでは正常という差が出るなら、Codexではなく表示ホストの違いが原因と考えやすくなります。ただし、端末を替えた結果だけを「修正」とせず、どの端末、どのシェル、どのCodex版で再現したかを残しておきます。

コピー後だけ崩れる場合

画面上では日本語が読めるのに、Ctrl+CやCodexのコピー機能を使ってエディターへ貼り付けると崩れる場合は、クリップボードと貼り付け先の組み合わせを調べます。まずメモ帳など単純なアプリへ貼り付け、次にVS CodeやCursorのエディターへ貼り付けます。一方だけが崩れるなら、端末全体ではなく貼り付け先の解釈や、書式付きテキストの受け渡しが関係しています。

2026年9月のCodex 0.154.0には、応答をコピーするときに書式を保持する変更が含まれています。そのため、更新後にMarkdownの見出しやコード枠が期待どおりになったかを確かめる価値があります。ただし書式が保たれても、貼り付け先が異なる文字コードで保存すれば本文は崩れます。表示、コピー、保存を一つの問題として扱わないことが重要です。

ファイルの内容が崩れている場合

エディターでも端末でも同じ箇所が崩れているなら、ファイルへ書き込むときの文字コード、既存ファイルを読み込むときの指定、変換を行った道具の設定を確認します。日本語を含むMarkdownやソースコードを開くときは、エディターが自動判定した結果だけを信頼せず、UTF-8として開き直して見え方を比べます。別名のコピーを作り、元のファイルを残したまま比較すると、誤った再保存で情報を失うリスクを抑えられます。

ファイルの中身を直すときは、見えている文字をそのまま上書きする前に、元ファイルのバイト列がすでに壊れているのか、読み取り方だけが間違っているのかを分けます。UTF-8のファイルを別の文字コードとして読み取っただけなら、正しい指定で再読込すれば戻ります。誤った解釈のまま保存し直した場合は、元のコピーや履歴から復元してから、正しい文字コードで保存し直す必要があります。

ファイル名やパスだけ崩れる場合

本文は正常なのに、日本語のフォルダー名やファイル名だけが崩れるときは、一覧を表示するコマンド、シェル、端末の出力が連携する境界を見ます。ファイル自体をエディターで開けば名前が正常に見えるか、別の端末でも同じ名前が崩れるかを比べてください。ファイル名の表示だけの問題なら、保存データを移動したり名前を変更したりせず、まず表示側の設定を直します。

いまWindowsで確認する理由

CodexのWindows利用では、アプリ、CLI、統合ターミナル、PowerShell、外部エディターが一つの作業に関わります。どれか一つがUTF-8を扱えても、途中の層が別の解釈をすれば日本語は崩れて見えます。2026年9月9日のCodex 0.154.0公式リリースには、Windowsセッションで背景のCodexサーバーを共有する変更、応答のコピーで書式を保持する変更、Windows向けのセッション処理に関する改善が記載されています。版更新で作業の入口が広がった分、どこで文字列を受け渡しているのかを確認する意味も大きくなりました。更新内容は公式のCodex 0.154.0リリースノートで確認できます。

ここで注意したいのは、0.154.0へ更新すれば、過去に誤った文字コードで保存したファイルまで元に戻るわけではないことです。また、同じPCでもWindows Terminal、VS Codeの統合ターミナル、古いコンソールでは表示条件が変わります。版番号を確認した後、端末を一つに固定して短い再現テストを行い、その結果を別の端末と比較するのが安全です。

0.154.0の更新点と文字の扱い

0.154.0の変更は、文字コードを一括で指定する機能の追加ではありません。Windowsセッションを共有する仕組みや、コピーした返答の書式を保つ仕組みが整ったことで、表示と受け渡しの確認点が増えたと捉えるのが適切です。日本語が崩れた場合も、まず「画面の表示」「コピーした内容」「ファイルの内容」を別々に読み、更新点が影響する範囲だけを確認します。

版を固定して比較する

同じ質問を0.153.4と0.154.0で試す場合は、端末やPowerShellの版も同じにします。Codexだけを更新して結果が変わったように見えても、端末を同時に変えていれば原因を特定できません。codex --version、$PSVersionTable.PSVersion、端末名、対象ファイルの保存形式を短く記録し、比較する条件をそろえてください。

最初に行う切り分け

最初から設定ファイルや環境全体を変更すると、何が効いたのか分からなくなります。次の手順では、同じ短文を使い、変更は一つずつにとどめます。結果を「正常」「画面だけ異常」「コピー後に異常」「ファイルも異常」のどれかで記録すれば、後から原因を振り返れます。既存のソースコードを直接書き換えず、テスト用の短いファイルと新しい会話を使うことも大切です。

Step 1: 同じ短文を三つの場所で確認する

まずCodexへ、日本語、英数字、記号を一行ずつ含む短い依頼を送ります。たとえば「東京駅、UTF-8、/src/app.tsをそのまま一行で返して」と依頼し、画面の返答を確認します。次に同じ返答をコピーしてメモ帳へ貼り付け、最後にテスト用のMarkdownへ保存して開きます。三つの結果が同じなら、少なくとも表示から保存までの基本経路は整っています。

Step 2: 端末とシェルの情報を記録する

次に、どの環境で再現したかを確認します。PowerShellでは次の値を読み取り、結果を変更せずに控えます。

codex --version
$PSVersionTable.PSVersion
[Console]::OutputEncoding.WebName
$OutputEncoding.WebName
chcp

[Console]::OutputEncodingは画面へ出す文字の扱い、$OutputEncodingは外部プログラムとの受け渡しに関係します。両者を同じものと決めつけず、Windows PowerShell 5.1かPowerShell 7か、Windows Terminalか統合ターミナルかも一緒に記録します。

Step 3: 入力・返答・ファイルを比べる

入力した日本語がCodexの画面では正しく見え、返答だけが崩れるのか、返答は正常で保存後だけ崩れるのかを分けます。入力欄、返答、保存したファイルを同じ文字列で比べ、異常が最初に現れた場所を「発生点」として記録してください。発生点より前の設定をむやみに変更しないことで、原因の候補が増えません。

Step 4: 新しい短い会話で再現する

長い会話では、過去の表示、コピー、履歴の状態が切り分けを難しくすることがあります。新しい短い会話を開き、同じ最小入力を送り、画面とコピー結果だけを比べます。新しい会話では正常で、特定の長い会話だけが崩れるなら、端末全体ではなくその会話の履歴や受け渡し状態に絞って調べられます。

Windows TerminalとPowerShellの文字コード

WindowsでCodex CLIを使うときに最初に押さえたいのは、PowerShellの版によって文字コードの既定値が異なることです。Microsoftのabout_Character_Encodingによると、Windows PowerShell 5.1では、BOMのないファイルを読み取る際に既定のANSIコードページが使われる場面があり、PowerShell 6以降はUTF-8が基本になります。同じコマンド名でも、読み取りと書き込みの結果が一致するとは限りません。

文字化けを直す場合は、エディター、PowerShell、端末のすべてを同時に変更するのではなく、まず読み取り時の指定を明示します。読み取った文字列が正しければ、表示側へ進みます。読み取り時点ですでに崩れていれば、元ファイルを保管した上で保存形式を確かめます。MicrosoftのWindows Terminal概要も、Windows TerminalがUnicodeとUTF-8を表示できることを説明しています。

Windows PowerShell 5.1の注意

Windows PowerShell 5.1では、BOMのないUTF-8ファイルを、状況によってシステムの既定コードページとして読み取ることがあります。そのため、Codexが生成したMarkdownを確認するときは、読み取りの文字コードを明示して表示を比べます。

Get-Content -LiteralPath .\sample.md -Raw -Encoding UTF8

5.1でUTF-8として書き出す場合も、Set-ContentやOut-Fileの既定値をそのまま使わず、保存形式を指定します。既存ファイルを直接上書きせず、まず別名の確認用ファイルへ書き出してください。なお、Windows PowerShell 5.1のUTF8はBOM付きになるため、Linuxや別の道具と共有するファイルでは、読み手がBOMをどう扱うかも確認します。詳しい既定値の差はMicrosoftの文字コード資料にまとまっています。

PowerShell 7での確認

PowerShell 7では、出力の既定がUTF-8系になっていますが、外部プログラムとの受け渡し、端末表示、ファイル保存は同じ設定ではありません。$OutputEncodingを変更しただけで、Set-Contentの保存形式まで変わるとは限らないため、対象ごとに確認します。まずpwsh --versionで版を確かめ、Get-Content -Encoding utf8で読み取った結果と、エディターで開いた結果を比べます。

pwsh --version
Get-Content -LiteralPath .\sample.md -Raw -Encoding utf8

PowerShellの既定値、BOMの有無、リダイレクト演算子の振る舞いは版によって違います。Microsoftは、ファイル操作の各コマンドに-Encodingを明示する方法と、外部プログラムとの通信に使う$OutputEncodingの役割を分けて説明しています。読み取りと保存を同じ設定だと思い込まないことがポイントです。

Windows Terminalの表示を比べる

Windows Terminalで正常に表示されるかを確認し、VS Codeの統合ターミナルや別のコンソールと結果を比べます。Windows Terminalは多言語のUnicode文字を表示できますが、そこで正常でも、外部コマンドが別のコードページで出力すれば崩れることがあります。chcpの値を変える場合は、既存のコマンドや古いツールの入出力に影響するため、変更前の値を控えてから短いテストだけで確かめます。

Codex CLIの返答を分けて確認する

OpenAIのCodex CLI公式ガイドでは、プロジェクトのディレクトリでcodexを起動し、作業内容を自然な言葉で依頼する基本の流れが案内されています。文字化けの確認でも、いきなり大きなコード変更を頼まず、文字列を返すだけの小さな依頼から始めます。これなら、モデルの出力、端末の表示、ファイルの読み書きを一つずつ比較できます。

Step 5: 日本語を含む最小入力を送る

再現用の依頼は、短く、内容を固定します。たとえば「日本語テスト、C:\\work\\src、{}を同じ順番で返して」と頼み、画面の返答を保存します。長いソースコードや複数のファイルを含めると、表示と保存のどこで崩れたかが見えにくくなるため、最初は一行の文字列に限定します。

Step 6: /copyと貼り付け先を比較する

Codex 0.154.0では、返答のコピー時に書式を保持する変更が公開されています。まず画面上の返答を読み、次に/copyなど利用中のコピー操作でメモ帳へ貼り付け、最後にMarkdownエディターへ貼り付けます。画面は正常でメモ帳も正常、VS Codeだけが崩れるなら、Codexの返答ではなく貼り付け先の受け取り方を調べます。コピー経路を変える前後で、同じ文字列を使ってください。

Step 7: ファイルをUTF-8として読み直す

Codexにファイルを作らせた場合は、エディターの自動判定だけでなく、PowerShellでUTF-8を指定して読みます。ターミナル表示、エディター表示、バイト列の解釈がすべて一致するかを確かめるためです。読み直した内容が正しければ、元ファイルは壊れておらず、エディターの判定や表示設定に原因がある可能性が高まります。

Get-Content -LiteralPath .\codex-output.md -Raw -Encoding UTF8

読み直しても崩れている場合は、元ファイルのコピーを残し、別の名前で正しい形式へ変換します。見えている崩れた文字列を手作業で置換する方法は、元の文字が失われている場合に復元できないため、最初の選択にしません。

原因別に文字化けを直す実践手順

原因が表示側か保存側か分かったら、変更を一つずつ加えます。文字コードを一度に複数へ変換する、端末をいくつも切り替える、元ファイルを上書きするという進め方は、問題を見えにくくします。確認用コピーを作り、変更前と変更後で同じ日本語が読めるかを比べながら進めてください。Codexへ追加の修正を頼む場合も、まず人が読める状態を取り戻してから、対象ファイルと文字コードを明記します。

Step 8: 端末だけなら表示側をそろえる

画面だけが崩れているときは、Windows Terminalで同じ返答を表示し、フォントと端末を比べます。PowerShellの出力設定を確認し、必要ならUTF-8の出力を扱える端末で再現します。設定を変更したら、同じ短文で再確認し、Codexの版やモデルまで同時に変えないようにします。表示が直った後も、ファイル内容が正しいかは別に確認します。

Step 9: 読み取り時にエンコードを明示する

ファイルを開くときにだけ崩れる場合は、Get-Content、エディター、プレビュー画面で同じ保存形式を指定します。UTF-8として読み取った結果が正常なら、その形式をプロジェクトの確認方法として残します。BOM付きかBOMなしかを区別する必要がある場合は、利用するエディターと実行環境の対応を確認し、互換性が分からないまま再保存しません。

Step 10: 書き込み側とエディターをそろえる

Codexが作ったファイルの保存時点で崩れている場合は、書き込みに使ったコマンド、エディターの保存形式、読み取り側の指定を調べます。最初に元ファイルをコピーし、別名のファイルでUTF-8を指定して保存してから開き直します。正常に戻った場合は、以後の保存で同じ形式を選べるよう、プロジェクトの短い説明に記録します。元ファイルの履歴があるなら、手作業の置換より復元と再保存を優先します。

Step 11: 貼り付けだけなら中間保存する

画面とファイルは正常で、特定アプリへ貼り付けたときだけ崩れるなら、いったんUTF-8のテキストファイルへ保存してから対象アプリで開きます。メモ帳、VS Code、Cursorなど二つ以上のアプリで結果を比べると、貼り付け先固有の問題かを確認できます。書式が必要な返答と、純粋なテキストが必要な返答を分けることも、崩れを広げない方法です。

Step 12: WSLや統合ターミナルを分けて試す

Windows上でWSL、PowerShell、VS Codeの統合ターミナルを行き来すると、実行するシェルと表示するホストが変わります。まず一つの端末で再現条件を固定し、次に別環境で同じ短文を試します。WSL側で正常、Windows側で異常なら、Codexの出力よりもシェルと端末の境界を疑います。逆の場合も同じように、正常な地点から異常な地点へ順番に戻って確認します。

症状から原因を見分ける

文字化けの調査では、見た目の種類よりも「どの操作の直後に現れたか」が重要です。次のように症状と発生点を対応させると、モデル変更や再インストールを急がずに済みます。表の「可能性が高い層」を一つずつ確認し、最初から全設定を変えないでください。

直ったかを判断する確認基準

表示が一時的に読めるようになっただけでは、文字化けが解決したとは限りません。Codexの返答をコピーし、保存し、別のアプリで読み直すところまで同じ文字列が保たれるかを確認します。特に日本語、絵文字、全角記号、バックスラッシュを含む入力は、端末表示とファイル保存の差が出やすいため、短い検証材料として役立ちます。

日本語入力と出力が一致する

入力した日本語がCodexの画面、コピーしたテキスト、保存ファイルの三つで一致するかを見ます。句読点、全角スペース、長音記号なども比べ、意味が通るかだけで判断しません。画面上で読めても、文字列の一部が別の文字へ置き換わっていれば、保存前に原因を特定する必要があります。

ファイル名と本文を別々に見る

ファイル名が正常でも本文が崩れる場合と、本文が正常でもファイル名が崩れる場合では、通る仕組みが異なります。Get-ChildItemで一覧を見て、エディターで本文を読み、別々の結果として記録します。一方が直ったからもう一方も直ったと判断せず、それぞれで短い確認を行ってください。

版と環境を記録する

Codexの版、PowerShellの版、端末の種類、保存形式、再現した日時を残します。公式リリースの変更を追うときも、版番号がないと同じ現象を比較できません。更新前後の結果を一行ずつ記録しておけば、次に文字化けが起きたときに、前回と同じ層なのか新しい境界なのかを判断しやすくなります。

Codex文字化けを繰り返さないための運用

文字コードの問題は、一度直しても、別の端末や別の保存方法を使ったときに再発します。そこで、プロジェクトごとに「どの端末でCodexを使うか」「テキストを何として保存するか」「日本語の確認にどの短文を使うか」を短く残します。長い説明や複雑な設定を増やすより、再現条件と確認コマンドを小さく固定する方が、別の人や別のPCでも同じ状態を作りやすくなります。

プロジェクトごとに確認方法を短く残す

READMEや開発メモに、推奨する端末、PowerShellの版、ファイルの保存形式、最初に実行する確認コマンドを書きます。個人の画面だけで分かる設定にせず、別の環境から読める形で残すことが大切です。Codexへ作業を頼むときも、対象ファイルの場所と保存形式を先に伝えると、読み書きの解釈がそろいやすくなります。

変更前後の文字を比べる

Codexにファイルの整形や翻訳を頼む場合は、日本語を含む短いサンプルを変更前後に残します。見出し、パス、記号を含む数行を比較すれば、見た目だけでなく文字の欠落や置き換わりにも気づけます。テスト用の文字列を毎回同じにすると、端末やエディターを替えたときも差を判断しやすくなります。

直らないときの問い合わせ情報をそろえる

自分で解決できない場合は、Codexの版番号、Windowsの版、PowerShellの版、端末名、再現する最小の文字列、画面とファイルのどちらで崩れるかをまとめます。問題のファイルに業務上の情報が含まれるなら、内容そのものではなく、再現用の短文と状態だけを共有します。公式のCodex CLIガイドと、Microsoftの文字コード資料を確認先として添えると、環境の前提をそろえやすくなります。

まとめ

Codexの文字化けを直すときは、モデルやプロジェクト全体の問題と決めつけず、画面表示、コピー、ファイル本文、ファイル名の四つに分けて、最初に崩れた場所を探します。Codex 0.154.0でWindowsセッションやコピーの扱いが更新された現在も、過去のファイルが正しい形式へ戻るわけではありません。版を確認し、同じ短文を同じ端末で試し、変更を一つずつ加えることが近道です。

Windows PowerShell 5.1とPowerShell 7の既定値、Windows Terminalの表示、エディターの保存形式は同じではありません。読み取り時にUTF-8を明示し、元ファイルを残してから別名で確認し、最後にCodexの返答と保存結果を比べます。公式のCodex 0.154.0リリース、Codex CLIガイド、Microsoftの文字コード解説を基準に、使っている版と環境に合わせて切り分けてください。