【ITニュース解説】Why LLM-Generated Code Breaks in Production: The Hidden Zero-Width Unicode Bug

近年、AI技術の発展は目覚ましく、大規模言語モデル（LLM）がコードの生成を補助する場面が増えている。しかし、この便利なAIが生成したコードをそのままコピー＆ペーストして利用する際、開発者を悩ませる奇妙な現象が報告されている。それは、コードエディタ上では何の問題もないように見え、インデントも正しく、変数名もクリアでエラー表示も一切ないにもかかわらず、ビルドや実行時に「SyntaxError: Unexpected token '​' (U+200B)」のような不可解なエラーが発生するというものだ。エラーメッセージに示される特定の文字（例：U+200B）を探しても、その場所には何も見えない。しかし、その空白を一度削除して打ち直すと、途端にエラーが消える。この「目に見えないバグ」の正体こそ、Unicodeのゼロ幅文字が引き起こす問題である。

この現象の根本原因は、LLMがテキストやコードブロックを生成する際に、意図せず非表示のUnicode文字をコンテンツに含めてしまうことにある。これらの文字は「ゼロ幅文字」と呼ばれ、例えば\u200B（ゼロ幅スペース）や\uFEFF（バイト順マーク）、\u200C（ゼロ幅非結合子）、\u200D（ゼロ幅結合子）、\u00A0（非改行スペース）といった種類がある。それぞれの文字には、テキストの表現上での特別な目的が割り当てられている。例えば、ゼロ幅スペースは単語の途中に挿入されても表示されず、そこで改行が可能であることを示す役割を持つ。しかし、これらの文字は現代のフォントレンダラーによって幅がゼロピクセルで描画されるため、人間の目には全く見えない。一方で、プログラミング言語のコンパイラやパーサーにとっては、これらはれっきとした「文字」であり、コードの構文解析時に予期せぬトークンとして扱われ、エラーの原因となるのだ。

ゼロ幅文字は、特にいくつかの場所で深刻な問題を引き起こす。まず、JSON形式の設定ファイルが挙げられる。package.jsonやCI/CD（継続的インテグレーション・継続的デリバリー）の設定ファイルなどは、RFC 8259という厳密なルールに基づいて記述される。標準的なJSONパーサーは、キーや値の中にエスケープされていない制御文字や外部のUnicode空白文字を許可しない。そのため、たとえ一つの\u200B文字がGitHub ActionsのYAMLファイルやtsconfig.jsonに紛れ込んだだけでも、ビルドが失敗し、解読困難なパースエラーを引き起こす可能性がある。

次に、正規表現の使用箇所でも問題が生じやすい。プログラムがユーザー名やメールアドレス、URLスラッグなどを検証するために正規表現を用いる際、入力文字列にゼロ幅文字が混入していると、見た目には正しいはずの文字列が正規表現のパターンに合致せず、検証が失敗する。例えば、^[a-zA-Z0-9_]{3,16}$のような正規表現でユーザー名を検証する場合、入力が「kyiron\u200B」であっても、ユーザーの目には「kyiron」としか見えない。しかし、正規表現はこの見えない文字を検出するため、検証結果はfalseとなり、ユーザーがログインできない、フォームが有効な入力を拒否する、といった奇妙なバグが本番環境で発生する可能性がある。

さらに、Gitによる差分管理やコードレビューのプロセスにも影響を及ぼす。ゼロ幅文字を含むコードがコミットされると、Gitは見た目には変化がない行であっても「変更された」と認識する。もし別の開発者のエディタが、保存時に末尾の空白を自動で削除したり、Unicodeの正規化を行ったりする設定になっている場合、両者の間でコードをやり取りするたびに、実際には意味のある変更がないにもかかわらず、Gitの差分（diff）にノイズのような変更が多数表示される「ゴーストディフ」が発生する。これはコードレビューの効率を低下させ、不必要な混乱を招く原因となる。

これらの見えない文字を検出する方法はいくつか存在する。ターミナルでは、cat -v config.jsonのように-vオプションを付けてファイルの内容を表示すると、非表示文字が「M-BM-^K」のような特殊な記号として可視化される。また、grep -P "[\x{200B}\x{FEFF}\x{200C}\x{200D}]" src/index.tsのように、特定のUnicode文字のHEX値を指定して検索することも可能だ。プログラム内で文字列をテストする場合は、JavaScript（Node.js）でconst hasZeroWidth = /[\u200B-\u200D\uFEFF]/.test(copiedCode);のような正規表現を使って、ゼロ幅文字が含まれているかをチェックできる。

この問題への対策として、最も実践的な方法は、AIが生成したコードを直接使用する前に「サニタイズ（浄化）」することである。ブラウザ上で動作する無料のユーティリティ「AI Text Sanitizer & Zero-Width Scrubber」のようなツールは、コピーしたテキストを貼り付けると、含まれているゼロ幅文字を赤くハイライト表示し、そのUnicodeのHEX識別子を示し、きれいに除去した上で、再度コピーできるようにしてくれる。これは、プロプライエタリなコードベースやAPI設定など、機密性の高いテキストを扱う際にも安全に利用できる。

また、開発環境の設定や開発プロセスに組み込むことで、この問題の発生を未然に防ぐことが可能だ。Visual Studio Codeを使用している場合は、設定でeditor.unicodeHighlight.invisibleCharactersをtrueにすることで、ゼロ幅文字が小さな黄色のボックスで強調表示されるようになり、視覚的に認識できるようになる。AIが生成したコードブロックや定型文を共有の設定ファイルに保存する前には、必ずサニタイザーを通すか、cat -vなどのコマンドで確認する習慣をつけることが重要である。さらに、ESLintのようなLinterツールにno-irregular-whitespaceなどのルールを追加することで、プルリクエストの段階で不正な空白文字を自動的に検出し、本番環境に到達する前に修正できる体制を整えることも効果的だ。

このように、AIアシスト開発は非常に強力で効率的な開発手法だが、同時に「目に見えない」という新たな課題も生み出す可能性がある。ゼロ幅Unicode文字による問題は、その典型的な例であり、システムエンジニアを目指す初心者にとっても、その存在と影響、そして対策について理解しておくことは非常に重要である。適切なツールや習慣を取り入れ、このファントムバグを効果的に回避することで、より安全で堅牢なシステム開発を推進していくことができるだろう。