チェックデジットとは｜計算方法と各規格の違い

更新日：2026年9月16日

チェックデジットとは

チェックデジットとは、コード本体から決まった計算で求める検査用の1文字です。日本語では検査数字とも呼ばれます。番号を発行する側が計算して末尾に付け、受け取る側が同じ計算をやり直して一致するかを確かめます。一致しなければ、どこかで1桁が変わったか、桁が抜けたか、順序が入れ替わった可能性が高いと判断できます。

大事なのは、チェックデジットが番号の正しさを保証するものではなく、番号の壊れ方を検出するものだという点です。商品を一意に識別する役割は本体部分が担っており、チェックデジットはそこに何も情報を足しません。「計算が合った＝正しい商品の番号である」とは言えない、と理解しておくと運用の判断を間違えにくくなります。

バーコードの世界でチェックデジットが重視されるのは、読み取りが物理現象だからです。印刷のかすれ、汚れ、斜めからの読み取り、光の反射によって、スキャナは本来と違うバーを読むことがあります。そこで規格側にあらかじめ検査の仕組みを埋め込み、誤読をその場で弾けるようにしています。手入力の場面でも同じ理屈が働き、電話口で伝えられた番号を打ち間違えたときに気付けます。

チェックデジットで防げるミス・防げないミス

どんな誤りを検出できるのかを具体的に整理します。モジュラス10ウェイト3（JAN／EAN）の場合、次のようになります。

• 検出できる：1桁だけが別の数字に変わった誤り。これはすべて検出できます。
• 多くは検出できる：隣り合う2桁を入れ替えた誤り（例：45→54）。重みが3と1で異なるため、大半の組み合わせで合計が変わります。
• 検出できないことがある：離れた2桁が同時に変わった場合。合計が偶然10の倍数ぶんだけずれると一致してしまいます。
• 原理的に検出できない：計算上正しい「別の商品」の番号を入力した場合。番号として整合している以上、検査では区別できません。

隣接桁の入れ替えについては例外があります。重みが3と1なので差は2倍。入れ替えた2桁の差が5のとき（例：1と6、2と7、3と8、4と9）は合計の変化が10の倍数になり、検出をすり抜けます。つまり「16」と「61」のような入れ替えは、チェックデジットでは気付けません。実務では、チェックデジットを通ったあとにも商品名との突き合わせを残しておくべき理由がここにあります。

主な計算方式の違い

方式が違うのは、扱える文字の種類が違うからです。数字だけを扱うJANは10で割れば足りますが、43文字を扱うCODE39は43で、ASCII全体を扱うCODE128は103で割ります。「法（モジュラス）の数＝その規格が区別すべき値の数」と考えると覚えやすくなります。

モジュラス10ウェイト3の計算方法（JANコード）

JANコード（EAN-13）とEAN-8、ITF-14で使われる方式です。手順は4つです。

1. チェックデジットを除いた本体を、右端から1桁ずつ見る。
2. 右端に3、その左に1、さらに左に3……と重みを交互に掛ける。
3. 積をすべて足して合計を出す。
4. 合計を10で割った余りを、10から引く。余りが0なら結果も0。

右端を起点にするのがポイントです。「奇数番目と偶数番目」という左起点の説明もよく見かけますが、本体の桁数が奇数か偶数かで対応が入れ替わるため、規格をまたいで覚えるなら右端起点のほうが安全です。

計算例：本体12桁 123456789012

右端の2から始めて、重みを3、1、3、1……と掛けていきます。

合計は 6＋1＋0＋9＋24＋7＋18＋5＋12＋3＋6＋1＝92。92を10で割った余りは2で、10−2＝8 がチェックデジットです。完成する13桁は 1234567890128 になります。

余りが0になる場合の扱いだけ注意してください。10−0＝10では2桁になってしまうため、このときチェックデジットは0とします。数式で書くなら (10 − 合計 mod 10) mod 10 とすれば、例外を含めて1つの式で表せます。

入力済みのコードを検証する手順

すでに13桁がある場合は、末尾1桁を取り除いた12桁に対して同じ計算をし、結果が取り除いた1桁と一致するかを見ます。一致しなければ、その13桁はどこかが誤っています。ただし前述のとおり、一致したからといって「この番号がその商品のものである」ことまでは確認できません。

EAN-8（本体7桁）の計算例

EAN-8も同じ方式ですが、本体が7桁で奇数のため、左から数えたときの重みの並びがEAN-13と逆になります。本体 9638507 で確認します。右端の7から、7×3＝21、0×1＝0、5×3＝15、8×1＝8、3×3＝9、6×1＝6、9×3＝27。合計は86、余りは6、チェックデジットは10−6＝4。完成形は 96385074 です。

ITF-14の場合

集合包装用のITF-14も、13桁の本体に対して同じモジュラス10ウェイト3でチェックデジットを求めます。ただし本ツールのITF-14は14桁の数字をそのまま受け取る仕様で、13桁からの自動補完は行いません。14桁の完成形を入力してください。

Excelでの計算式

本体12桁がセルA2に文字列として入っている場合、次の数式でチェックデジットが得られます。SUMPRODUCT を使うので、配列数式として確定する必要はありません。

=MOD(10-MOD(SUMPRODUCT(MID(A2,ROW(INDIRECT("1:12")),1)*1,{1;3;1;3;1;3;1;3;1;3;1;3}),10),10)

本体7桁（EAN-8）なら、重みの並びを反転させます。

=MOD(10-MOD(SUMPRODUCT(MID(A2,ROW(INDIRECT("1:7")),1)*1,{3;1;3;1;3;1;3}),10),10)

先頭ゼロのある番号を扱う列は、必ず表示形式を「文字列」にしてから貼り付けてください。標準のままだと先頭ゼロが落ち、桁数が変わって計算結果が狂います。すでに数値として入ってしまった列は TEXT(A2,"000000000000") で桁を戻してから MID に渡します。

モジュラス43：CODE39のチェックデジット

CODE39は43種類の文字を扱うため、各文字に0〜42の値を割り当て、その合計を43で割った余りに対応する文字をチェック文字として末尾に追加します。付けるかどうかは任意で、規格として必須ではありません。

計算例：ABC-001

1文字ずつ値に置き換えます。A＝10、B＝11、C＝12、−＝36、0＝0、0＝0、1＝1。合計は 10＋11＋12＋36＋0＋0＋1＝70 です。70を43で割ると商が1、余りが27。値27に対応する文字は、10がAなので27はそこから17個進んだ R になります。

したがってチェック文字付きのデータは ABC-001R となり、start/stopのアスタリスクを含めたバーコードの表現は *ABC-001R* です。start/stopのアスタリスク自体は値の合計に含めません。

チェック文字を付けると、当然ながらバーコードに含まれる文字列が1文字増えます。読み取り側が「チェック文字あり」の設定になっていれば、スキャナは検証したうえでチェック文字を取り除いた ABC-001 をシステムへ渡します。設定が食い違っていると、末尾のRが付いたままアプリケーションへ流れ込むので、必ず送り手と受け手で揃えてください。文字種やstart/stopの詳細はCODE39の解説にあります。

モジュラス103：CODE128のチェックデジット

CODE128はASCIIの128文字を高密度に表せる形式で、サブセットA・B・Cを切り替えて使います。チェック文字は必須で、しかも人が読む文字としては表示されません。バーコードの中にだけ存在する値です。

計算は、開始コードの値を起点として、データ文字の値に1から順の位置番号を掛けて足し、合計を103で割った余りを取ります。サブセットBの開始コードは値104、サブセットBでの文字の値は「ASCIIコード − 32」です。

計算例：サブセットBでABCを表す場合

A、B、CのASCIIコードは65、66、67なので、値はそれぞれ33、34、35です。位置番号は先頭のAが1、Bが2、Cが3。

• 開始コード（Code B）：104
• A：33 × 1 ＝ 33
• B：34 × 2 ＝ 68
• C：35 × 3 ＝ 105

合計は 104＋33＋68＋105＝310。310を103で割ると商が3（103×3＝309）で、余りは1。よってチェック文字の値は1です。サブセットBで値1にあたるのはASCII 33、つまり「!」ですが、この文字が画面や印字の文字列に現れることはありません。

このように計算が複雑で、しかもサブセットの切り替え位置によって値が変わるため、利用者が手で組み立てる場面はまずありません。本ツールでも描画処理が自動で構成します。入力時に確認すべきなのは、渡す文字列そのものが受け側の仕様と一致しているかどうかです。

NW-7（Codabar）のチェックデジット

NW-7には規格として必須のチェックデジットがありません。宅配便の送り状や図書館の利用者カードなど、運用ごとにモジュラス16などの方式を独自に定めている例はありますが、どの方式を使うかは発行元が決めています。したがって「NW-7のチェックデジットの計算方法」という一般解は存在しません。

本ツールもNW-7のチェックデジットを自動付加しません。必要な場合は、発行元の規約に従って計算した完成形の文字列を入力してください。start/stop文字（A〜D）は自動で補われます。詳細はNW-7の解説をご覧ください。

本ツールでの自動計算と検証

バーコードシートの挙動は次のとおりです。

• EAN-13で12桁を入力し自動計算がオンなら、チェックデジットを計算して13桁に補完します。
• EAN-8で7桁を入力し自動計算がオンなら、8桁へ補完します。
• 13桁または8桁を入力した場合は末尾を検証し、一致しなければ入力値を書き換えずに警告を表示します。
• 自動計算をオフにすると補完を行わず、完成桁数での入力が必要になります。
• ITF-14は14桁をそのまま受け取ります。CODE39のモジュラス43とNW-7の任意チェック文字は自動付加しません。

警告が出た行を自動で書き換えない設計にしているのは、元データのどれが誤っているかを人が判断すべきだからです。勝手に末尾を直すと、誤った番号が「正しい形」になって流通してしまいます。

チェックデジットが合わないときの原因

実務で遭遇する不一致は、番号そのものよりデータの受け渡しに原因があることがほとんどです。多い順に挙げます。

1. 先頭ゼロの消失。表計算ソフトが数値として解釈し、049… が 49… になっている。桁数を数えればすぐ分かります。
2. 指数表記への変換。13桁が 4.90123E+12 のように化け、末尾が丸められている。
3. 全角数字や空白の混入。見た目では判別しづらく、コピー元がWordやPDFのときに起きます。
4. 桁の取り違え。12桁の本体に、さらにチェックデジットを付けた13桁を重ねて入力している、あるいは13桁から末尾を落とし忘れている。
5. 元資料の誤り。手入力された台帳や、OCRで取り込んだリストは、ここまでの確認をすべて通っても合わないことがあります。

切り分けは、まず桁数を数える、次に先頭ゼロを確認する、最後に元資料と1桁ずつ突き合わせる、という順が早道です。

入力時の確認リスト

• 先頭ゼロを含む桁数が保たれているか。
• 方式に合わない英字や記号、全角文字が混ざっていないか。
• 完成桁を入力した場合、警告が出ていないか。
• チェック文字を付ける運用かどうか、受け側へ確認したか（CODE39・NW-7）。
• 保存・印刷後に、元データと実機での読み取り結果を照合したか。

よくある質問

チェックデジットとは何ですか？

コード本体から決まった計算で求める検査用の1文字です。受け取った側が同じ計算をやり直し、末尾の値と一致するかを見ることで、読み取りミスや入力ミスに気付けます。商品を識別する番号そのものではなく、番号が壊れていないかを確かめるための仕組みです。

JANコードのチェックデジットの計算方法を教えてください。

先頭12桁を右端から見て、3と1の重みを交互に掛けて合計します。合計を10で割った余りを10から引いた値がチェックデジットです。余りが0のときは0になります。例えば本体が 123456789012 なら合計は92、余りは2、チェックデジットは8です。

余りが0のときチェックデジットは10になりますか？

なりません。チェックデジットは1桁なので、余りが0のときは0にします。計算式では (10 − 合計 mod 10) mod 10 とすると、この例外を含めて1つの式で表せます。

チェックデジットが一致しないと表示されたらどうすればよいですか？

まず元データの桁数と先頭ゼロを確認してください。表計算で先頭ゼロが落ちている、指数表記に化けている、全角数字が混ざっている、といった原因が大半です。本ツールは不一致でも入力値を書き換えず、警告付きでそのまま表示します。

CODE39にチェックデジットは必須ですか？

必須ではありません。モジュラス43のチェック文字を付けるかどうかは運用側で決めます。付ける場合と付けない場合でバーコードの内容が変わるため、読み取り側の設定と合わせる必要があります。

CODE128のチェックデジットは自分で入力しますか？

入力しません。モジュラス103のチェック文字は必須ですが、人が読む文字としては表示されず、バーコードを描く処理が自動で組み込みます。利用者は本来のデータだけを入力します。

チェックデジットがあれば番号の間違いは必ず見つかりますか？

見つかりません。1桁の誤りや多くの隣接桁の入れ替えは検出できますが、複数箇所が同時に変わった場合は偶然一致することがあります。また、計算上正しい別の商品の番号を入力してしまった場合は検出できません。