チェックディジットがない番号は、世の中に数多くあります。登録機関が順番に割り当てているだけの番号には、計算で確かめられる末尾の位が存在しません。この記事では、そうした番号に対して何ができて何ができないのか、そして画面にどう書くべきかを整理します。
どのような番号に公開されたチェックディジットがないのか？
すべての識別子が検証用の位を持つわけではありません。考え方としては、次の二種類があります。
| 種類 | 中身 | 検証の可否 |
|---|---|---|
| 計算で導かれる位を持つ | 末尾の位が他の位から決まる | つじつまを計算で確かめられる |
| 順番に割り当てられた番号 | 登録機関が順に配るだけ | 桁数と文字種しか確かめられない |
二番目の種類は、欠陥品ではありません。割り当ての目的が識別であって誤り検出ではない、という設計の違いにすぎません。番号の体系を設計する側が、転記の誤りを検出する必要を感じていなければ、検証用の位は付きません。
したがって、「算法が公表されていない」ことと「番号がずさんである」ことは別の話です。ここを混同すると、正しく運用されている制度を不当に低く評価することになります。
算法で確かめられない番号があるのはなぜか
原因はいくつか考えられます。まず、番号を発行する側が、検証の必要性そのものを想定していない場合です。紙の台帳で管理していた時代の番号は、この典型です。次に、検証用の位を持つと桁数が増え、運用の負担になる場合です。そして、検証用の位を持つこと自体が、外部に公開したくない情報を含んでしまう場合もあります。
いずれの場合も、外部から見た結論は同じです。公開された手順が存在しないため、計算で確かめる手段がありません。この状態を「検証に失敗した」と表現するのは誤りです。試していないことを失敗と呼んでいるからです。算法の側の事情はチェックディジットのアルゴリズムで扱っています。
「形式のみ」という結論は何を意味するのか
検証の結論は、二つではなく四つに分けて考えると整理できます。
- 有効。公開された算法に合格し、末尾の位が成立しました。
- 無効。形式は合うものの、末尾の位が成立しませんでした。
- 形式のみ。確認できる形式は合いましたが、算法が存在しないため、それ以上は分かりません。
- 規則なし。そもそも対応する制度が見つかりませんでした。
三番目が本記事の主題です。「形式のみ」は、良いとも悪いとも言っていないという点で、他の三つと性格が異なります。この表現を避けて「有効」と書けば、根拠のない太鼓判を押すことになります。逆に「無効」と書けば、確かめていないことを否定したことになります。
四番目も同じくらい重要です。対応する規則が見つからないことは、番号が偽物であることを意味しません。単に、こちらの側に知識がないというだけです。
形式しか分からない番号はどう扱えばよいのか？
形式だけでも、できることはあります。桁数と文字種を確かめることで、明らかな入力の誤りを相当程度はねられます。桁が一つ足りない、想定外の記号が入っている、全角と半角が混ざっている、といった誤りはこの段階で見つかります。
扱いの手順としては、次の順序が実用的です。
- 区切り記号を取り除き、文字種をそろえる。
- 桁数の範囲を確認する。
- 想定される文字種に収まっているかを確認する。
- 通ったものを、その後の手続きへ回す。
四番目の行き先は、制度によって違います。登録の照会ができる場合はそこへ、できない場合は利用者による確認へ回します。形式の確認は、最終的な判断ではなく分流の装置だと考えると位置づけがはっきりします。
形式の確認に価値がある場面
算法がないからといって、形式の確認を省いてよい理由にはなりません。むしろ、算法という強い手段がない分、形式の段階でできることを丁寧にやる必要があります。
- 入力の誤りを早い段階で止められるため、後工程の負荷が下がります。
- 表示の形式をそろえられるため、一覧や帳票の見た目が安定します。
- 制度ごとに正しい処理へ振り分けられるため、後段の設計が単純になります。
- 利用者に対して、何を確認して何を確認していないかを説明できます。
最後の点は見落とされがちですが、実務では最も効いてきます。確かめていないことを確かめたふりをしないことは、システムへの信頼につながります。
開発者向け：四つの状態と文言の書き分け
実装では、検証の戻り値を真偽値にしないことが出発点です。四つの状態を持つ値として返し、それぞれに異なる文言を割り当てます。
とくに注意したいのは、三番目の状態の文言です。ここで「有効」と出すと、算法がないことを隠したことになります。「形式のみ」と明示し、その理由を添えます。理由の説明があると、利用者は自分で判断できます。
四番目の状態では、対応していないという事実だけを伝えます。番号の真偽には触れません。この二つの状態を実装しないまま、既定値を「無効」にしている例は少なくありません。既定値の選び方が、そのまま利用者への誤った説明になります。
本文で述べたのは番号体系の一般的な性質であり、例として挙げた説明はすべて構成上のものです。実在の番号、利用者、事業者を示すものではなく、真偽の判断材料にはなりません。
次の一手
自分のシステムが、算法を持たない番号をどう表示しているかを確認してください。既定値が「無効」になっている箇所があれば、そこは「形式のみ」か「規則なし」に分ける余地があります。番号検証ツールで実際の表示を確かめ、四つの状態がどのように書き分けられているかを見てください。検証の層の分け方は番号検証の仕組みで、境界での扱いはAPI の境界で検証するで扱っています。