知識マップ: 業務システムのコード設計 ── 商品コード・顧客コードの決め方とチェックディジット

記事「業務システムのコード設計 ── 商品コード・顧客コードの決め方とチェックディジット」の主張を、概念と関係(エッジ)に分解した知識グラフの全体です。各関係には根拠・確認日・確度が付いています。

業務システムの商品コードや顧客コードは、部門や分類などの意味を桁に埋め込む有意コードを避け、識別に徹した無意味連番か種別接頭辞付きのハイブリッド構成にするのが本記事の推奨である。マイナンバーも住民票コードを変換した意味を持たない番号として設計されており、検査用数字としてモジュラス11のチェックディジットを持つ。人の手や目を通るコードにはチェックディジットを付けるべきで、入力ミスの実態は1桁誤りと隣接する2桁の転置がほとんどを占めるため、JANコードのGS1標準やLuhnアルゴリズムはこの2類型をほぼ検出でき、法人番号のモジュラス9は0と9の取り違えを見逃し、VerhoeffやDammの方式は両方の誤りを完全に検出する。実装ではExcelが業務コードを数値として解釈すると先頭ゼロや15桁を超える桁が失われるため、コードは文字列として一貫して扱うことが実務上の要点になる。

flowchart LR
    accTitle: 業務コード設計とチェックディジットの知識マップ
    accDescr: 業務コードを識別に徹して設計する原則と、人手を通るコードにチェックディジットを付ける理由、JAN・Luhn・モジュラス11・モジュラス9・Verhoeff・Dammなど各方式の1桁誤りと隣接転置の検出力の違いを示す図
    business_code["業務コード(商品コード・顧客コードなど)"]
    check_digit["チェックディジット(検査用数字)"]
    significant_code["有意コード"]
    sequential_code["無意味連番"]
    excel_numeric_coercion["Excelの数値変換による0落ち・15桁丸め"]
    mynumber["マイナンバー(個人番号)"]
    modulus_11_check["モジュラス11のチェックディジット"]
    corporate_number["法人番号"]
    modulus_9_check["モジュラス9のチェックディジット"]
    jan_code["JANコード(GTIN)"]
    gs1_standard["GS1標準(モジュラス10 ウェイト3-1)"]
    luhn_algorithm["Luhnアルゴリズム(モジュラス10)"]
    verhoeff_algorithm["Verhoeff法"]
    damm_algorithm["Damm法"]
    single_digit_input_error["1桁誤り(打ち間違い)"]
    adjacent_transposition_error["隣接転置の誤り"]
    crockford_base32["Crockford Base32"]
    significant_code -.->|"用いるのは非推奨"| business_code
    sequential_code -->|"推奨される対応"| business_code
    check_digit -.->|"推奨される対応"| business_code
    business_code -.->|"両立しない"| excel_numeric_coercion
    mynumber -->|"利用する"| sequential_code
    mynumber -->|"利用する"| modulus_11_check
    corporate_number -->|"利用する"| modulus_9_check
    jan_code -->|"前提とする"| gs1_standard
    jan_code -->|"利用する"| check_digit
    luhn_algorithm -->|"実装を担う"| check_digit
    modulus_11_check -->|"実装を担う"| check_digit
    modulus_9_check -->|"実装を担う"| check_digit
    gs1_standard -->|"実装を担う"| check_digit
    verhoeff_algorithm -->|"実装を担う"| check_digit
    damm_algorithm -->|"実装を担う"| check_digit
    single_digit_input_error -->|"で確認できる"| check_digit
    adjacent_transposition_error -->|"で確認できる"| check_digit
    luhn_algorithm -->|"防止する"| single_digit_input_error
    luhn_algorithm -.->|"防止する"| adjacent_transposition_error
    gs1_standard -->|"防止する"| single_digit_input_error
    gs1_standard -.->|"防止する"| adjacent_transposition_error
    modulus_11_check -.->|"防止する"| adjacent_transposition_error
    modulus_9_check -.->|"防止する"| single_digit_input_error
    verhoeff_algorithm -->|"防止する"| adjacent_transposition_error
    damm_algorithm -->|"防止する"| adjacent_transposition_error
    crockford_base32 -.->|"推奨される対応"| business_code

概念間の関係(全26件)

図と同じ関係を文章でも列挙します。表示している文と機械可読な意味データ(RDFa)は同じ要素に載っています。確度が「確立した関係」のものは直接の関係として、「条件付きの関係」のものは成立条件つきの言明(rdf:Statement)として表現しています。

有意コードを業務コード(商品コード・顧客コードなど)に用いることは推奨されません。部門・分類・年度をコードの桁に埋め込む有意コードは、組織改編・分類変更・部分的な桁枯渇で振り直しが必要になるため、業務コードの設計として推奨されない / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
無意味連番は業務コード(商品コード・顧客コードなど)に対する本記事の推奨です。属性を持たせない無意味連番は何が変わっても壊れにくく、業務コードの設計として本記事が推奨する選択肢である / 確度: 確立した関係 / 確認日: 2026-08-01 出典
チェックディジット(検査用数字)は業務コード(商品コード・顧客コードなど)に対する本記事の推奨です。紙の帳票からの入力や電話での伝達など人の手と目を通る業務コードには、入力誤りをその場で検出できるチェックディジットを付けることが推奨される / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
業務コード(商品コード・顧客コードなど)はExcelの数値変換による0落ち・15桁丸めと両立しません。先頭ゼロの保持や16桁以上の桁を必要とする業務コードは、Excelがセルを数値として解釈する挙動と両立せず、全経路で文字列として扱う必要がある / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
マイナンバー(個人番号)は無意味連番を利用します。マイナンバーは住民票コードを作為が加わらない方法で変換して生成される、意味を持たない番号として設計されている / 確度: 確立した関係 / 確認日: 2026-08-01 出典
マイナンバー(個人番号)はモジュラス11のチェックディジットを利用します。マイナンバーの検査用数字はモジュラス11の算式(重みを掛けた合計を11で除し、余りが1以下なら0とする)で算出される / 確度: 確立した関係 / 確認日: 2026-08-01 出典
法人番号はモジュラス9のチェックディジットを利用します。法人番号の検査用数字は基礎番号に奇数桁×1・偶数桁×2の重みを掛けた合計を9で除した余りから算出される / 確度: 確立した関係 / 確認日: 2026-08-01 出典
JANコード(GTIN)はGS1標準(モジュラス10 ウェイト3-1)を前提とします。JANコードの利用にはGS1事業者コードの貸与を受ける登録手続きが必要で、自社で勝手に決めることはできない / 確度: 確立した関係 / 確認日: 2026-08-01 出典
JANコード(GTIN)はチェックディジット(検査用数字)を利用します。JANコード(GTIN-13)のチェックデジットの計算方法もGS1標準で定められている / 確度: 確立した関係 / 確認日: 2026-08-01 出典
Luhnアルゴリズム(モジュラス10)はチェックディジット(検査用数字)の実装を担います。Luhnアルゴリズムは1つおきの桁を2倍し9を超えたら9を引いて合計する計算でチェックディジットを実装する / 確度: 確立した関係 / 確認日: 2026-08-01 出典
モジュラス11のチェックディジットはチェックディジット(検査用数字)の実装を担います。モジュラス11のチェックディジットは重みを掛けた合計を11で割った余りからマイナンバーの検査用数字を実装する / 確度: 確立した関係 / 確認日: 2026-08-01 出典
モジュラス9のチェックディジットはチェックディジット(検査用数字)の実装を担います。モジュラス9のチェックディジットは重みを掛けた合計を9で割った余りから法人番号の検査用数字を実装する / 確度: 確立した関係 / 確認日: 2026-08-01 出典
GS1標準(モジュラス10 ウェイト3-1)はチェックディジット(検査用数字)の実装を担います。GS1標準はモジュラス10ウェイト3-1の計算でJANコード・ISBN-13のチェックディジットを実装する / 確度: 確立した関係 / 確認日: 2026-08-01 出典
Verhoeff法はチェックディジット(検査用数字)の実装を担います。Verhoeff法は群演算の表引きでチェックディジットを実装する / 確度: 確立した関係 / 確認日: 2026-08-01 出典
Damm法はチェックディジット(検査用数字)の実装を担います。Damm法は準群の演算表を1枚引くだけでチェックディジットを実装する / 確度: 確立した関係 / 確認日: 2026-08-01 出典
1桁誤り(打ち間違い)はチェックディジット(検査用数字)で確認できます。コードの1桁だけの打ち間違いは、正しく設計されたチェックディジットで確認できる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
隣接転置の誤りはチェックディジット(検査用数字)で確認できます。隣接する2桁の入れ替えは、正しく設計されたチェックディジットで確認できる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
Luhnアルゴリズム(モジュラス10)は1桁誤り(打ち間違い)を防ぎます。Luhnアルゴリズムはすべての1桁誤りを検出できる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
Luhnアルゴリズム(モジュラス10)は隣接転置の誤りを防ぎます。Luhnアルゴリズムは隣接転置のうち09↔90の1組だけを見逃し、それ以外は検出できる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
GS1標準(モジュラス10 ウェイト3-1)は1桁誤り(打ち間違い)を防ぎます。GS1標準(モジュラス10ウェイト3-1)はすべての1桁誤りを検出できる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
GS1標準(モジュラス10 ウェイト3-1)は隣接転置の誤りを防ぎます。GS1標準は隣接転置のうち差が5の組(05↔50など)だけを見逃し、それ以外は検出できる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
モジュラス11のチェックディジットは隣接転置の誤りを防ぎます。モジュラス11のチェックディジットは隣接転置をほぼすべて検出できるが、余りが0または1に畳み込まれる2クラス間の誤りは検出できない / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
モジュラス9のチェックディジットは1桁誤り(打ち間違い)を防ぎます。モジュラス9のチェックディジットは9で割った余りを使うため0と9が合同になり、この2つの打ち間違いだけは検出できない / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
Verhoeff法は隣接転置の誤りを防ぎます。Verhoeff法はすべての1桁誤りとすべての隣接転置を検出する / 確度: 確立した関係 / 確認日: 2026-08-01 出典
Damm法は隣接転置の誤りを防ぎます。Damm法はすべての1桁誤りとすべての隣接転置を検出する / 確度: 確立した関係 / 確認日: 2026-08-01 出典
Crockford Base32は業務コード(商品コード・顧客コードなど)に対する本記事の推奨です。電話や手書きでの伝達がなく桁数を圧縮したい業務コードには、誤読対策済みのCrockford Base32のような設計済みアルファベットの採用が推奨される / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典

主要概念の定義

業務コード(商品コード・顧客コードなど): 業務システムで対象を一意に識別するために付与する商品コード・顧客コード・伝票番号などの記号。
チェックディジット(検査用数字): コードの末尾(または先頭)に、他の桁から計算で導けるよう付ける1桁で、入力されたコードの誤りをその場で検出する仕組み。
有意コード: 部門・分類・年度など対象の属性の意味を桁に埋め込むコード体系。読めば属性が分かる一方、組織改編や分類変更で振り直しが必要になりやすい。
無意味連番: 属性の意味を持たせず、対象を一意に指すためだけに振る連番のコード体系。何が変わっても壊れにくい。
マイナンバー(個人番号): 住民票コードを作為が加わらない方法で変換して生成される、意味を持たない11桁の番号と、その後に付された1桁の検査用数字からなる番号。
法人番号: 12桁の基礎番号とその前に付された1桁の検査用数字で構成される、法人に指定される番号。
JANコード(GTIN): 商品にバーコードとして印字して社外(小売・EC・物流)に流通させるための、GS1標準に基づく商品識別コード。
Luhnアルゴリズム(モジュラス10): 1954年にIBMのH. P. Luhnが特許出願した、1つおきの桁を2倍し9を超えたら9を引いて合計するチェックディジット方式。クレジットカード番号で使われる。
モジュラス11のチェックディジット: 各桁に重みを掛けた合計を11で割った余りから検査用数字を導く方式。マイナンバーで使われ、余りが0または1のときは検査用数字を一律0とする畳み込みを持つ。
モジュラス9のチェックディジット: 基礎番号の各桁に奇数桁×1・偶数桁×2の重みを掛けた合計を9で割った余りから検査用数字を導く方式。法人番号で使われ、9で割る都合上0と9を区別できない。
GS1標準(モジュラス10 ウェイト3-1): GTIN・GS1アプリケーション識別子(AI)・SSCC・GLNなどの識別コード体系や、バーコードのシンボル品質・配置要件を定めるGS1の標準規格群。JANコードやISBN-13のチェックディジットは、右端の桁から3倍・1倍を交互に掛けた合計から「10から合計を10で割った余りを引く」方式(モジュラス10 ウェイト3-1)で算出する。
Verhoeff法: 群演算による表引きで、すべての1桁誤りとすべての隣接転置を検出する十進コードを初めて構成したチェックディジット方式。
Damm法: 準群(quasigroup)の演算表を1枚引くだけで、すべての1桁誤りとすべての隣接転置を検出できるチェックディジット方式。
1桁誤り(打ち間違い): コードの1桁だけを別の数字に打ち間違える入力ミスの類型。実測では誤りの60〜95%を占める最大の類型とされる。
隣接転置の誤り: 隣り合う2桁を入れ替えてしまう入力ミスの類型。2桁誤り全体(10〜20%)の大部分を占める。
Crockford Base32: 1と紛らわしいI・L、0と紛らわしいOなどを除いた32文字のアルファベットを使い、桁数を圧縮しつつ誤読対策を施した符号化方式。

機械可読データ

JSON-LD / Turtle ── この記事の知識グラフ全体
概念一覧 / 語彙(述語)の定義

このページはサイトの知識グラフ(_data/knowledge/)から自動生成されています。誤りの指摘はお問い合わせからお願いします。