Japanese Windowsでacli rovodev runが動かない原因は文字コードか cp932 codec can't decode byte 0x94エラーの正体と現実的な対処法
日本語Windows環境でAtlassian系CLIを使っていると、インストールや設定に問題がないように見えるのに、起動直後に不可解な文字コードエラーへぶつかることがあります。今回のケースは、acli rovodev run実行時にcp932 codec can't decode byte 0x94が発生し、Rovo Dev本体が立ち上がる前の段階で処理が止まるというものです。再インストールや設定削除を試しても改善しない場合、この問題はユーザー操作ではなく、CLI内部のエンコーディング処理に起因している可能性が高いです。本記事では、ノイズを取り除いたうえで、エラーの意味、なぜ日本語Windowsで起きやすいのか、そしてOS全体を変更せずに現場で取れる対処法を整理して解説します。
発生している問題の核心は「日本語Windowsの既定文字コード」と「UTF-8前提の処理」の衝突
今回の症状は、Failed to start Rovo Dev CLIに続いて、'cp932' codec can't decode byte 0x94というエラーが出る点に特徴があります。これは単純に言えば、アプリケーションのどこかがUTF-8など別の文字コードで作られたデータを、日本語Windowsで一般的に使われるcp932として読み込もうとして失敗している状態です。
cp932は日本語Windowsで広く使われてきたコードページですが、近年のCLIツールやクラウド連携ツールの多くは、内部的にUTF-8を前提として設計されています。そのため、構成ファイル、キャッシュ、ユーザープロファイル情報、リモートから取得したメタデータのいずれかに、cp932で正しく解釈できないバイト列が含まれると、起動前の初期化段階で停止することがあります。
特に今回のように「beta customer site selection」の処理中に止まる場合、Rovo Devそのものの実行ロジック以前に、アカウント情報やサイト選択情報、あるいはリモートから取得した設定データをローカルで読んでいる最中に失敗していると考えるのが自然です。つまり、コマンド入力が間違っているのではなく、内部初期化のどこかで文字コードの扱いが噛み合っていない可能性が高いのです。
再インストールや設定削除で直らない理由
この種の不具合で厄介なのは、ユーザー側で思いつく基本的な対処をしても改善しにくい点です。CLI本体を入れ直しても、問題の本質が実行ファイルの破損ではなく、読み込み対象データの文字コード解釈にあるなら、再インストールだけでは解決しません。
また、関連ディレクトリを削除しても直らない場合があります。これは、削除した場所とは別の場所にキャッシュや認証情報、環境依存の一時データが残っている可能性もありますが、それ以上に、CLIが起動時に外部から取得する情報自体をローカル既定エンコーディングで誤って解釈しているケースも考えられます。その場合、どれだけローカル設定を消しても、再取得した瞬間に同じ失敗が再現します。
PowerShellのクリーンセッションで試しても変わらない点も重要です。これは、シェル固有の表示上の文字化けではなく、CLI内部で発生しているデコード例外であることを示唆しています。つまり、見えているのは端末の問題ではなく、アプリケーションロジックの問題です。
PYTHONUTF8=1で改善しないなら、表層ではなく内部処理の問題
セッション単位でUTF-8を有効にする方法は、Python系ツールでは有効な場面があります。実際、PYTHONUTF8=1は環境によって入出力やファイル読み込みの挙動を改善することがあります。しかし、それでも同じエラーが出るなら、次のどちらかの可能性が高まります。
ひとつは、問題の処理がその環境変数の影響を受けない箇所で行われていることです。たとえばラッパーやサブプロセス、埋め込みランタイム、あるいは別実装の部分で既定ロケールを参照していれば、表側でUTF-8を指定しても届きません。
もうひとつは、そもそもファイルやレスポンスを開く処理に明示的なエンコーディング指定がなく、OS既定値へフォールバックしていることです。この場合、ユーザーができる回避策には限界があります。つまり、今回の症状は「UTF-8化を試したが直らない」こと自体が、内部実装側の改善余地を示しているとも言えます。
OS全体をUTF-8へ切り替えずに試したい現実的な回避策
OS全体やシステムロケールを変更したくない場合でも、いくつか試す価値のある回避策はあります。ただし、どれも根本修正ではなく、環境差によって効果が分かれる点には注意が必要です。
まず有力なのは、起動前に端末側の入出力コードページをUTF-8寄りへ寄せる方法です。PowerShellやWindows Terminalで実行する場合、セッション内の出力エンコーディング設定を見直すことで挙動が変わることがあります。これは内部例外を完全に防ぐ保証はありませんが、起動時の受け渡しや表示系に依存する処理が絡む場合には一定の効果が見込めます。
次に、ユーザープロファイルや環境変数の中に日本語や機種依存文字が含まれていないか確認することです。たとえばユーザー名、作業ディレクトリ、関連パスにCLIが想定していない文字が含まれていると、初期化で落ちることがあります。英数字のみの短いパスへ移し、最小構成の環境で試すと、症状の切り分けがしやすくなります。
さらに、初回セットアップに近い処理を別環境で通してから同一アカウントで再試行する方法もあります。もし問題が「beta customer site selection」の段階に集中しているなら、その選択済み状態やメタデータ取得済み状態を別環境で作っておくことで、日本語Windows側の失敗地点を回避できる可能性があります。
これは既知の制限か、それともバグか
提示されている症状だけを見る限り、かなり高い確率で非UTF-8ロケール環境における互換性不足、もしくは明確なバグとみてよいでしょう。理由は、ユーザーが実施した切り分けがかなり妥当だからです。再インストール、関連ディレクトリ削除、クリーンセッション、UTF-8有効化を試しても、同じ処理地点で同じデコードエラーが再現している以上、ローカル設定の汚染よりも実装上の前提ミスを疑う方が自然です。
特に、現代のクロスプラットフォームCLIで内部データをOS既定エンコーディングに任せる実装は、国際環境で不具合を起こしやすい典型例です。本来は、ファイルもAPIレスポンスもログもUTF-8を明示して扱うべきで、少なくとも起動不能になるほどの例外を未処理で表に出すべきではありません。したがって、利用者視点では「自分の設定が悪い」と考えすぎる必要はなく、製品側へ報告する価値が高い事象です。
いま必要なのは「環境依存の回避」と「再現条件の整理」
この問題に向き合ううえで重要なのは、むやみに環境を壊して試行錯誤することではありません。再現条件を整理し、どの段階で落ちるのかを絞ることです。今回のケースでは、Rovo Dev本体の起動前、しかもサイト選択フェーズで失敗している点が大きなヒントになります。
そのため、実務上は「日本語Windowsの既定cp932環境で、初期化時にUTF-8前提データを誤読している可能性が高い」と整理しておくのが最も有益です。OS全体をUTF-8へ変えなくても動く正式サポートがない限り、ユーザー側の小手先の設定では限界があります。一方で、英数字のみの簡素な環境、UTF-8寄りの端末設定、別環境での初期処理通過といった回避策にはまだ試す余地があります。
まとめ
acli rovodev runが日本語Windowsでcp932 codec can't decode byte 0x94を出して停止する場合、原因は高い確率で文字コード処理の不整合です。再インストールや設定削除で直らないのは、CLI内部がOS既定エンコーディングに依存しているか、起動前に取得するデータをUTF-8として安全に扱えていないためと考えられます。
重要なのは、この現象が単なる操作ミスではなく、非UTF-8ロケール環境での互換性不足を示すサインであることです。現場で取れる対策としては、端末側のUTF-8化、英数字のみの最小環境での再検証、初期選択処理の切り分けが有力です。ただし根本解決には、Rovo Devまたはacli側が内部処理でUTF-8を明示的に扱う修正が必要になる可能性が高いでしょう。日本語Windowsで同様の症状に悩んでいるなら、これは個別環境の偶然ではなく、再現性のある実装上の問題として捉えるのが正解です。
