【ITニュース解説】VAT Number Regex Isn't Validation: What Format Checks Miss

VAT番号の検証は、システム開発において非常に重要な機能の一つだ。顧客が入力したVAT番号が本当に有効なものかをチェックすることは、税務処理の正確性やビジネスの信頼性に直結する。しかし、「VAT番号の検証」という言葉が指す内容は一つではなく、その違いを理解しないと、誤ったシステムができてしまう可能性がある。システムエンジニアを目指すなら、この区別をしっかり把握しておくことが大切だ。

一般的に「VAT番号の検証」と呼ばれるものには、主に三つの異なる側面がある。一つ目は「形式のチェック」、二つ目は「内部的な整合性のチェック」、そして三つ目は「登録状況のチェック」だ。それぞれが何を確認しているのか、そしてどの方法でチェックできるのかを詳しく見ていこう。

まず「形式のチェック」について説明する。これは、入力された文字列がVAT番号の「見た目の形」として正しいかどうかを確認する作業だ。例えば、ドイツのVAT番号であれば「DE」で始まり、その後に9桁の数字が続くというような、国ごとの決まったパターンがある。正規表現（Regex）というツールは、この形式チェックに非常に強力だ。正規表現を使えば、「DE」というプレフィックスがあるか、その後に数字が9文字続いているか、といった文字列のパターンを高速に確認できる。もし文字列が「DE」で始まっていなかったり、数字が足りなかったりすれば、正規表現はそれを「不正な形式（Malformed）」として弾き出す。これはネットワークへの接続なしでローカルに実行できるため、非常に安価で効率的な最初のゲートとして機能する。しかし、正規表現ができるのはここまでだ。文字列が「見た目の形」として正しいことしか証明できない。

次に「内部的な整合性のチェック」についてだが、これは少し複雑だ。一部の国では、VAT番号の内部に「チェックデジット」という仕組みを取り入れている。これは、番号の残りの部分から特定の計算（算術演算）によって導き出される一文字（数字または文字）のことだ。例えば、番号の各桁を特定の数で割った余りが、最後の桁と一致するかどうか、といったルールがある。もし、VAT番号の途中に誤って一文字入力ミスがあったとしても、このチェックデジットの計算が合わなくなるため、その番号は「内部的に整合性がない」と判断される。正規表現は、あくまで「その位置に数字があるか」「その位置に文字があるか」といった文字の種類や位置はチェックできるが、このような算術的な計算までは行えない。そのため、たとえ形式的には正しく見えても、チェックデジットが誤っている番号を正規表現だけで見つけることはできないのだ。このような番号は、形は整っているが、実際には誰も発行されていない偽りの番号となる。

そして最も重要なのが「登録状況のチェック」だ。これは、形式的に正しく、内部的な整合性も取れているように見えるVAT番号が、本当にその国の税務当局に登録されている有効な番号なのかを確認する作業だ。例えば、架空の「DE123456789」という番号が形式的に正しくても、それが実際にドイツの税務データベースに登録されていなければ、有効なVAT番号とは言えない。このチェックは、正規表現やローカルでの算術計算だけでは不可能だ。必ず、VIES（VAT Information Exchange System）のような、税務当局が提供するライブAPI（アプリケーション・プログラミング・インターフェース）に問い合わせる必要がある。VIESは、EU加盟国間でVAT番号の有効性を確認するためのシステムで、これに問い合わせることで、そのVAT番号が現在登録されているか、あるいは以前は登録されていたが現在はキャンセルされているかといった、最新の正確な情報を得られる。実際の取引で意味を持つのは、この「形式が正しく、かつVIESによって登録が確認された」という結果だけだ。

このように、「VAT検証」には三つの異なる側面があるため、これらの区別をせずに正規表現だけで全てを「検証済み」と見なしてしまうと、大きな問題を引き起こす。例えば、顧客が入力した「形は正しいが登録されていない」偽のVAT番号を、システムが正規表現だけで「有効」と判断して受け入れてしまうと、税務上のトラブルにつながる可能性がある。逆に、正規表現だけでは判別できない微妙な形式（例えば、ギリシャのVAT番号プレフィックスはISOコードのGRではなくVIESではELが使われるなど）を誤って不正と判断し、本来通るべき顧客をブロックしてしまうこともある。EUのVAT番号は、国によって独自のプレフィックス、長さ、文字の組み合わせがあり、単一の正規表現では対応できない。各国ごとの異なるパターンを網羅したデータセット（例えば eu-vat-rates-data というオープンソースのパッケージ）をシステムに取り込む必要がある。

したがって、VAT番号の検証を行う際のベストプラクティスは、これらのチェックを段階的に組み合わせることだ。最初のステップとして、正規表現による「形式のチェック」を行うべきだ。これにより、明らかにタイプミスや不正な形式の入力値を、ネットワーク通信なしで迅速に排除できる。これは「安価な最初の門番」のようなもので、リソースの無駄遣いを防ぐ。このローカルチェックを通過したものは、「ネットワークコールに値する」と判断できるが、それ以上ではない。まだ、その番号が本当に登録されているか、チェックデジットが正しいかは不明な状態だ。

次に、このローカルチェックを通過したVAT番号に対して、VIESのようなライブAPIへの問い合わせを行う。このAPIコールによって初めて、そのVAT番号が「登録されているか」「登録されていないか」という最終的な答えが得られる。ライブAPIからの応答は、いくつかのパターンに分かれることを理解しておく必要がある。

一つ目のパターンは、APIにリクエストが送られる前に、ローカルの形式チェックで弾かれた場合だ。例えば、プレフィックスが間違っていたり、桁数が足りなかったりする明らかな不正な入力は、API側がVIESに問い合わせる前に「不正な形式（INVALID_FORMAT）」としてHTTPステータスコード400（Bad Request）で拒否される。この場合、VIESへのネットワークコールは発生せず、API利用のクォータ（利用回数制限）も消費されない。

二つ目のパターンは、ローカルの形式チェックは通過したものの、VIES自体がその入力を不正と判断した場合だ。これは稀なケースで、例えば前述の「チェックデジットが誤っている」といった、より高度な内部整合性チェックにVIESが引っかかった場合に起こり得る。この場合もHTTP 400が返されるが、「viesCode: "INVALID_INPUT"」のような情報が含まれることで、VIES側の判断であることが示される。

そして三つ目の、最も重要なパターンは、形式も正しく、VIESへの問い合わせも行われたが、結果として「そのVAT番号は現在登録されていない」とVIESが回答した場合だ。このとき、APIはHTTPステータスコード200（OK）を返すにもかかわらず、応答のボディには「valid: false」という情報が含まれる。これは「エラー」ではない。VIESが実際に情報を調べて「登録されていない」という「正しい答え」を返した、という明確な判断結果であり、正規の（課金対象の）応答だ。システム開発では、HTTP 200以外のステータスコードを全てエラーとして処理してしまうことがよくあるが、「valid: false」という200応答をエラーとして扱ってしまうと、本来「登録されていない」と判明した有効な情報を、システム上のバグとして誤って記録してしまうことになる。この違いを理解し、適切に処理を分岐させる必要がある。

まとめると、VAT番号の検証は「形が正しいか（正規表現）」「内部的に整合性があるか（チェックデジット、VIES）」「実際に登録されているか（VIES）」という三段階の確認が必要であり、正規表現は最初の安価なゲートとして非常に有用だが、それだけで全ての検証を完了することはできない。VIESのようなライブAPIへの問い合わせが、最終的な「有効性の判断」には不可欠であり、その応答内容も細かく理解してシステムに組み込むことが、正確で信頼性の高いシステムを構築するための鍵となる。システムエンジニアとして、このような詳細な違いを理解し、適切なツールと手法を選択する能力は非常に重要だ。