前株・後株でPDF請求書を再発行した日──ExcelじゃわからないUnicodeの罠にはまった話

請求書社名誤記、自動化の闇

受話器の向こうから聞こえる少し不機嫌な声に、背筋を冷たい汗が流れた。月末の多忙な時期を乗り切るため、丹念に組み上げた請求書の自動出力システム。その稼働直後に届いたのは、得意先の経理担当者からのクレームだった。「会社名が間違っていますよ。うちは前株じゃなくて後株です」

法人格である「株式会社」の位置が違うという指摘。ビジネスにおいて、相手の正式名称を間違えるのは致命的なマナー違反に当たる。ましてや、請求書という金銭のやり取りが発生する公式文書での誤記は。そのまま自社の信用問題に直結してしまう。

まず、送付済みのPDFファイルを開くと、確かに宛名が「株式会社〇〇」になっていた。正しい社名は「〇〇株式会社」だ。頭に血が上り、心臓が嫌なリズムで跳ねるのを感じながら。急いで謝罪して再発行の約束をした。電話を切った後。重苦しい胃の痛みとともに「自動化プログラムのどこでバグったんだ」と途方に暮れた。

VLOOKUPを欺く見えない文字の罠

再発行の手続きは、想像以上に精神を削る。元のデータを修正し、PDFを作り直し。経理部長に頭を下げて再承認のハンコをもらう。せっかくPythonやExcelの関数を駆使して残業を減らしたはずなのに。たった一つの文字のズレがすべてを台無しにしてしまった。

見えない文字によるデータ不整合

上司に事情を説明する時の気まずさと、自分の書いたコードに対する自信の喪失。「手作業で確認したほうがマシだったんじゃないか」という言葉が。頭の片隅をかすめる。しかし、ここで逃げるわけにはいかない。二度と同じミスを起こさないために、システムの闇に潜る決意を固めた。

見えない文字とVLOOKUPの罠

慌てて基幹システムから落とした元データと。請求書発行用のExcelマスタを開く。データを確認していくと、奇妙な現象に直面した。顧客IDをキーにしたVLOOKUP関数は、一切のエラーを吐いていなかったのだ。「株式会社〇〇」と「〇〇株式会社」が混在している状況で。なぜかExcelの関数は正常に値を引っ張ってきているように見える。目視で確認する限り、マスタには「株式会社〇〇」と登録されている。

システム連携を阻む不可視文字

次に、

ところが、Pythonのライブラリを使ってPDFを生成する段階で。一部の顧客データだけが後株に変わったり、社名の中に妙な空白が混じったりしていた。Excelが画面上で表示している文字と。プログラムが読み取ってPDFに印字する文字が違う。そんな馬鹿なことがあるはずがない。何度もセルをダブルクリックして中身を覗き込む。画面に顔を近づけても、表示されているテキストはまったく同じです。

VLOOKUP関数は、検索値と完全に一致するデータを探し出す仕組みだ。それが一致していると見なされているということは、データ自体は同一なのだろうか。「N/A」と表示されるべき場所で、涼しい顔をして正しい値を返してくる関数たち。システムから吐き出されたCSVのエンコードを疑ったり。PDF生成ライブラリのフォント設定を疑ったりと。見当違いの場所を数時間も探し回る羽目になった。

見えない文字によるデータ不整合

文字コード不一致の落とし穴

疑心暗鬼に陥りながら、隣の列にLEN関数を打ち込んだ。文字列の長さをカウントして。目に見えない余計なスペースが入っていないかを確かめるためだ。Enterキーを叩いた瞬間、信じられない数字が表示された。目視では同じ10文字に見える社名なのに。LEN関数の結果が10と11で分かれていたのです。

一方で、まったく同じに見える「株式会社〇〇」という文字列。上の行のLEN関数は10を返し、下の行は11を返している。空白を取り除くTRIM関数をかけても、数字は変わらない。制御文字を消すCLEAN関数を通しても、結果はピタリと同じままだった。

どこかに、人間の目には見えない何かが潜んでいる。コピーしてテキストエディタに貼り付けても、やはり見た目の違いは判別できない。「A=B」かどうかを厳密に判定するEXACT関数を使ってみると。無慈悲にも「FALSE」の文字が返ってきた。

システム連携の文字数不一致

文字コード不一致、データ連携の落とし穴

手入力で「株式会社〇〇」と打ち直すと、LEN関数は正しい数字を返した。しかし、システムからエクスポートしたデータを使うと、必ず狂う。数百件のデータを手作業で打ち直すわけにはいかない。マウスを握る手がじっとりと汗ばみ、窓の外が暗くなっていくのを見ながら。帰宅の時間が遠のいていく絶望感を味わった。

そのため、手作業でのコピペなら問題ないが、システム間のデータ連携をすると破綻する。この見えない壁の正体を突き止めない限り、自動化は永遠に使い物にならない。文字が同じなのに長さが違う。この矛盾を抱えたまま、データは容赦なくシステムを流れ。最終的に請求書の宛名という最悪の場所で暴発したのです。

隠れた文字コード不一致

文字コードの地雷原、Pythonでデータ浄化

原因は、文字コードの世界に深く根付いていた。社内システムAと社内システムBで、同じ「・」や「ー」を入力したつもりでも。裏側で割り当てられているUnicodeが違っていたのだ。例えば、「・」（中黒）と「·」（半角中黒）。「－」（全角ハイフン）と「-」（半角ハイフン）。さらに、全角スペースと半角スペースの違い。これらは、人間の目には同じような記号に見えても。コンピュータにとってはまったくの別物として扱われる。

コピー元のシステムや、顧客が直接入力したWebフォームの仕様によって。入力される文字コードはバラバラになる。Macのキーボードで入力された文字とWindowsで入力された文字で。内部的なコードが異なるケースさえある。

見えない文字、データ連携の落とし穴

見えないデータ不一致をPythonでマスタ浄化

しかし、

ExcelのVLOOKUPは。特定の条件下で半角と全角の違いを曖昧に処理してしまうことがある。そのため、Excelの画面上では「一致している」ように見えた。しかし、厳密な文字列処理を行うPythonのプログラムにデータを渡した瞬間。隠れていた不一致が牙を剥く。前株・後株の配置が狂うのも。顧客がWebフォームで社名を入力する際に見えない特殊文字のスペースが混入したり。システム移行時に文字コードが変換されたりしたことが原因だった。「株式会社」の文字列の前に。ゼロ幅スペースと呼ばれる透明な文字が混入していたケースもあった。

データ連携という行為は、文字コードの地雷原を裸足で歩くようなものだったのです。

Python unicodedataでデータ浄化

Pythonでマスタデータ正規化

この地雷を撤去するには。すべての文字を「標準的な形」に強制変換するしかない。ExcelのSUBSTITUTE関数で一つずつ置換していくのは現実的ではない。異体字のパターンは星の数ほどあり。新しい地雷が追加されるたびに数式を修正しなければならないからだ。ここで救世主となったのが。Pythonの標準ライブラリであるunicodedataです。

さらに、unicodedata.normalize('NFKC', text)という一行のコードを書く。これだけで、全角英数字は半角へ、半角カタカナは全角へ。特殊なスペースは通常のスペースへと、一気に標準化される。NFKCと呼ばれる正規化の仕組みが。Unicodeの複雑な異体字を力技で統一してくれる。

会社名マスタ、秒速浄化で得た「正しいマスタ

Pythonでマスタデータ正規化、…

VSCodeを開き。数千件の会社名マスタを読み込んで正規化スクリプトを走らせた。一瞬で処理が終わり、出力されたCSVのLEN関数がすべて綺麗に揃ったのを見た時。思わずモニターの前で「よっしゃ」と声が出た。数日間にわたる胃の重たさが、すっと消えていくのを感じた瞬間だった。

目視確認と手作業での修正にかかっていた時間は月間約15時間。それがスクリプト実行のわずか数秒にまで圧縮された。正規化されたデータを元に、前株と後株の分離や。法人格の統一ルールをPythonのstr.replaceで書き加えていく。「㈱」や「㈲」などの環境依存文字も。「株式会社」「有限会社」へ安全に置換できるようになった。文字コードという根源的なレイヤーでデータを浄化することで。ようやく「正しいマスタ」が手に入ったのだ。もうExcelの曖昧な仕様に騙されることはありません。

Pythonでマスタデータ正規化

マスタデータ品質の肝、Pythonで自動正規化

まず、

人間の目視確認は、文字コードの前では無力だ。そして、日常的に業務で使っているExcelすらも。常に真実を映し出しているわけではない。自動化プログラムが謎のエラーを吐いたとき。私たちはついツールのバグを疑ってしまう。

しかし、本当のボトルネックは往々にしてデータの質そのものに潜んでいる。今回のトラブルを経て。マスタデータを登録する時点でPythonによる正規化を自動で行う仕組みを導入した──見えないノイズを入り口で弾くことで。後工程のシステム連携が劇的に安定したのです。

Excelが見落とす曖昧なズレを、Pythonの厳格な処理が補う。もう二度と。前株と後株の違いで冷や汗をかくことはない──そう心から思えるようになった。システム化を進めるほど、データの潔癖さが求められる。あなたのマスタデータは、今日も正しく保たれているだろうか？その問いを。胃の痛みとともに身をもって学んだ出来事だった。

Pythonスキルアップの次の一歩

関連リンクとチェックリスト

私は藁にもすがる思いで、インターネットの海に飛び込みました。「Excel 見えない文字」「VLOOKUP 判定されない」「LEN 関数 違う」といったキーワードで検索を繰り返しました。すると、あるフォーラムで、私と全く同じ現象に悩まされている人の投稿を見つけました。その投稿には「全角スペースと半角スペースの違い」や「改行コード」といった、見慣れない専門用語が並んでいました。

しかし、私の場合はTRIM関数やCLEAN関数でも解決しなかったので、もっと根深い問題だと直感しました。さらに調べていくと、「文字コード」という言葉が目に留まりました。文字コードとは、コンピューターが文字を認識・表示するために使う、いわば文字の「IDカード」のようなものだと書かれていました。異なる文字コードで保存されたデータは、たとえ見た目が同じでも、コンピューターにとっては全く別の文字として認識されることがある、という説明に、頭の中で点と点が繋がり始めました。

システムから出力されるCSVファイルはUTF-8

システムから出力されるCSVファイルはUTF-8、ExcelはShift_JIS、そしてPythonで扱うデータはまた別の文字コード…といった具合に、データが様々なシステムを経由する中で、文字コードの変換がうまくいっていなかったのかもしれない、と考えました。特に、全角スペースのように見えるけれど、実は普通の全角スペースとは異なる、別の種類のスペース文字が紛れ込んでいる可能性が指摘されていました。これは、いわゆる「幽霊文字」や「不可視文字」と呼ばれるもので、人間の目には見えないけれど、データとしては存在している厄介な存在でした。

この見えない文字の正体を突き止めるために、私はExcelのCHAR関数とCODE関数を使ってみることにしました。CODE関数は、指定した文字の文字コードを数値で返してくれる関数です。問題のセルに入力されている文字を1文字ずつCODE関数で調べていくと、ついにその正体が判明しました。一般的な全角スペースの文字コードは「160」ですが、問題のデータには「127」という、見慣れない数字を返す文字が含まれていたのです。これは、ASCIIコードにおける「DEL（削除）」に相当する制御文字で、まさかこんなものが社名データに紛れ込んでいるとは、夢にも思いませんでした。

この「DEL」文字は

この「DEL」文字は、本来であれば削除されるべき文字ですが、何らかのシステム連携の過程で、データとして残ってしまっていたようでした。そして、VLOOKUP関数やEXACT関数は、この見えない「DEL」文字の存在をしっかりと認識し、一致しないと判断していたのです。一方で、Excelの画面表示やLEN関数の一部では、この文字が無視されたり、別の文字として解釈されたりすることで、目視での確認を困難にしていたのでした。この発見には、まさに目から鱗が落ちる思いでした。まさか、目に見えないたった1文字が、これほどまでに大きなトラブルを引き起こすとは、プログラミングの奥深さと難しさを痛感した瞬間でした。

原因が分かれば、あとは対処するだけです。私はPythonのコードに、データクリーニングの処理を追加しました。具体的には、正規表現を使って、通常の文字以外の制御文字や特殊なスペース文字をすべて削除する処理を組み込みました。また、Excelマスタのデータも、同様の方法でクリーニングし、すべての社名データから不要な文字を徹底的に排除しました。この作業は地味で根気のいるものでしたが、二度と同じミスを繰り返さないという強い決意を持って取り組みました。

そして、修正したプログラムで再度請求書を生成し

そして、修正したプログラムで再度請求書を生成し、念のため目視でも確認しました。今度は、どの社名も正しく表示され、余計な空白や文字のズレも一切ありませんでした。この一件で、私はプログラミングにおけるデータの前処理の重要性、そして目に見えない部分にこそ、落とし穴が潜んでいることを痛感しました。自動化は確かに便利ですが、その裏には、データの品質をいかに保つかという、地道な努力が不可欠なのだと、身をもって知ることができた貴重な経験でした。

学習サービスとアンケート