日本語フォルダ名の罠 — NFD正規化でツールがパスを見失う

GeoDiveExa（GDE）・GeoConverterPro（GCVP）・GeoPrism JP（GPRM）の企画資料は「次期アプリ」という日本語フォルダに置いています。ところが、AIツールにこのフォルダ配下のパスを直接指定すると、ファイルが実在するのに「見つからない」というエラーになることがあります。原因は、macOSのファイルシステムが行っている文字の正規化（NFD）でした。

症状 — 存在するのに見つからないパス

現象としては、次のようなことが起きます。

ls で確認すると確かにファイルは存在する
ところが、そのパスを別のツール（AIエージェントのファイル読み込み機能など）へそのまま渡すと、「そのようなファイルはありません」というエラーが返る
原因不明のまま同じ操作を繰り返しても、症状が再現し続ける

英語フォルダ名だけの環境ではまず遭遇しない類のエラーで、原因の見当がつきにくいのが厄介な点です。

原因はUnicodeの正規化形式の違い

日本語の濁点・半濁点を含む文字（「が」「ぱ」など）は、Unicode上で表現する方法が1通りではありません。

正規化形式	表現方法	例（「が」）
NFC（正規結合形式）	濁点付き文字を単一のコードポイントで表現	`が`（1文字分のコード）
NFD（正規分解形式）	基底文字と濁点を別々のコードポイントに分解して表現	`か` + `゛`（2つのコードの組み合わせ）

見た目にはどちらも同じ「が」に見えますが、内部のバイト列は異なります。macOSのファイルシステム（HFS+ / APFS）は、ファイル名をNFD形式で保存する挙動を持っています。 一方、AIツールや多くのプログラミング言語の文字列処理は、NFC形式を前提にしていることが多く、ここに食い違いが生じます。

具体的には、AIとの会話やドキュメントに書かれたフォルダ名の文字列（NFCで入力されることが多い）を、そのままファイルシステムへのパスとして渡すと、ファイルシステム側が保持しているNFD形式の名前と一致せず、「存在しない」と判定されてしまうのです。

回避策 — シェルで実パスを取得してから使う

関連記事：正典ファイル1枚でAIに文脈を渡す

この問題を避けるために、Geoエコシステムの運用では次の手順をルール化しています。

AIツールから直接「次期アプリ/〇〇.md」のようなパスを指定しない
代わりにシェルで ls を実行し、その出力に含まれる実際のパス文字列（ファイルシステムが保持しているNFD形式のバイト列）を取得する
その ls の出力結果をコピーして、以降のファイル操作に使う

ls の出力はファイルシステムが実際に保持している名前をそのまま返すため、NFD/NFCの食い違いを気にせずに済みます。逆に言うと、「見た目が同じ文字列」を人間やAIが手入力・再構成すると、正規化形式が変わってしまうリスクが常にあるということです。

なぜ気づきにくいのか

このズレが厄介なのは、画面上の見た目ではNFCとNFDの違いがまったく分からない点です。ターミナルやエディタで文字を見比べても同じ「が」にしか見えず、バイト単位で比較して初めて違いが分かります。

さらに、ls や cd のようにシェル自身がファイルシステムとやり取りするコマンドは問題なく動くため、「シェルでは触れるのに、別のツールからは触れない」という一見矛盾した状況が生まれます。この非対称性が、原因の切り分けを難しくしている一因です。

英語フォルダ名の環境では表面化しない

この問題は、フォルダ名がASCII文字（英数字）だけで構成されている場合には発生しません。ASCII文字には正規化による表現の分岐がないためです。日本語・韓国語・アクセント記号付きの欧文など、合成可能な文字を含むフォルダ名を使う環境で初めて表面化する、環境依存の落とし穴と言えます。

まとめ

macOSのファイルシステムはファイル名をNFD（正規分解形式）で保持するが、AIツールや多くのプログラム処理はNFC（正規結合形式）を前提にしていることが多い
この食い違いにより、日本語フォルダ名を含むパスをAIツールに直接指定すると「存在するのに見つからない」というエラーになることがある
回避策は、シェルの ls 出力から実際のパス文字列を取得し、それをそのまま以降の操作に使うこと
ASCII文字だけのフォルダ名では発生しない、Unicode正規化に起因する環境依存の問題