QR コードはなぜ同じデータでも模様が変わるのか ― マスクパターンとペナルティ計算

QR コードには、 データ本体、 誤り訂正コード語、 位置検出パターン、 タイミングパターン、 形式情報などが入ります。 しかしこれらをそのまま配置すると、 たまたま黒が固まりすぎたり、 横方向に同じ色が長く続いたり、 位置検出パターンに似た偽の模様ができたりします。

そこで QR コードは、 データ領域に対して白黒を反転する条件式をかけます。 これがマスクパターンです。 反転条件が違えば、 同じデータでも見た目が変わります。

重要なのは、 マスクをかけてもデータが壊れるわけではないこと。 どのマスクを使ったかは形式情報に入るため、 読み取り側は同じマスクを逆に適用して元のデータを復元できます。

QR コードには 0〜7 の 8 種類のマスクパターンがあります。 行を r、 列を c とすると、 条件を満たすデータ領域のセルを反転します。 位置検出パターン、 タイミングパターン、 形式情報などの機能パターンはマスク対象ではありません。

実装は8候補すべてを作り、 後述する評価式でスコアを付けます。 最終的にペナルティが最も小さいマスクが採用されます。 そのため、 生成ライブラリが規格通りに実装されていれば、 選ばれた見た目が違っても読み取り結果は同じです。 サムネイルには、 実際に https://nandemo-tools.com/ をエンコードした QR コードと、 0〜7 の各マスク条件を小さな見本として描いています。

QR コード生成は、 単に文字列を白黒に変換する処理ではありません。 実装上はおおむね次の順で進みます。

1. 入力文字列を数字・英数字・バイトなどのモードに分け、 ビット列へ変換する
2. バージョンと誤り訂正レベルに応じて、 データコード語と誤り訂正コード語を作る
3. 位置検出パターン、 タイミングパターン、 アライメントパターンなどの機能パターンを配置する
4. 残りのデータ領域へコード語をジグザグに配置する
5. マスク 0〜7 をそれぞれ適用し、 ペナルティスコアを計算する
6. 最小スコアのマスク番号を選び、 その番号と誤り訂正レベルを形式情報に書き込む

読み取り側は形式情報からマスク番号を読み、 同じ条件でデータ領域をもう一度反転して元に戻します。 つまりマスク番号は、 見た目を変えるだけでなく復号に必要なメタデータでもあります。

なお、 同じ URL でも誤り訂正レベル、 バージョン選択、 セグメント分割、 マスク選択の細部が違うと見た目が変わることがあります。 これは「どれかが偽物」 という意味ではなく、 複数の正しい表現があり得るということです。

QR コードは白黒の細かい格子ですが、 同じ色が長く連続すると読み取り時の境界判定が難しくなります。 そのため、 行または列に同色セルが 5 個以上続くとペナルティが加算されます。

黒黒黒黒黒      → ペナルティ
黒黒黒黒黒黒    → さらに加算

これは画像処理として自然です。 カメラのピント、 露出、 モーションブラー、 印刷のにじみがあると、 長い帯は境界の位置が曖昧になりやすい。 マスクはその偏りを散らすためにあります。

2×2 の同色ブロックが多い場合もペナルティです。 小さな塊が増えると、 画像の局所的な黒白比が偏ります。

さらに重要なのが、 位置検出パターンに似た並びです。 QR コードの角にある大きな四角は、 読み取り側が QR コードの位置・角度を見つけるための目印です。 データ領域にこれと似た 1:1:3:1:1 の比率の並びが現れると、 偽の目印として誤認される可能性があります。

そのため評価式では、 こうした並びに大きめのペナルティを与えます。 「見た目がきれいか」 ではなく、 スキャナーにとって紛らわしくないかを見ているわけです。

QR コードのマスク評価は、 よく N1〜N4 と呼ばれる4種類の観点で説明されます。 実装資料では細かな点数計算まで定義されていますが、 実務で重要なのは「何を嫌っているか」 です。

この4つは、 単独で完全な読み取り品質を保証するものではありません。 しかし「長い帯」「大きな塊」「偽の目印」「黒白比の偏り」 という、 カメラ読み取りで問題になりやすいパターンをかなりよく捉えています。 だから QR コードの見た目は、 美的なランダム性ではなく、 読み取りやすさのための評価関数で選ばれていると考えると理解しやすいです。

QR コード全体の黒セル比率も評価対象です。 理想はおおむね 50%。 黒が多すぎても白が多すぎても、 画像の二値化が不安定になります。

たとえば黒セルが 70% 近い QR コードは、 暗い印象の塊になりやすく、 低コントラスト環境で白セルが埋もれやすい。 逆に白が多すぎるとデータ密度が視覚的に薄くなり、 欠けや汚れに弱く見えます。

マスク選択はこの比率も見ながら、 長い連続・同色ブロック・偽パターン・黒白比の総合点で決まります。 1つのルールだけでなく、 複数の「読み取りにくさ」を合算するのが肝です。

ロゴ入り QR や装飾 QR では、 マスクパターンよりも先に次の要素が問題になります。

• クワイエットゾーン (周囲の余白) が足りない
• 位置検出パターンや形式情報を覆っている
• 色のコントラストが低い
• 誤り訂正レベルに対してロゴが大きすぎる
• 縮小後にセル境界がぼける

誤り訂正レベル H は強力ですが、 何でも直せる万能保険ではありません。 誤り訂正が直せるのは主にデータ領域の欠損であり、 位置検出や形式情報、 余白、 コントラストが崩れると、 そもそも QR コードとして検出されないことがあります。

QRコード生成ツール で作ったコードは、 実際に QRコード読み取りツール や複数端末のカメラで確認するのが安全です。 最終媒体が印刷なら、 画面上のプレビューだけでなく印刷後のサイズ・紙質・照明でも読み取り確認しましょう。

特にチラシや名刺では、 デザイン上の都合で QR コードを小さくしがちです。 しかしセルの実寸が小さくなりすぎると、 どれだけ良いマスクを選んでもカメラ側でセル境界を分離できません。 マスクは「よいQRを選ぶ」仕組みであって、 低解像度・低コントラスト・余白不足を帳消しにする仕組みではない、 という線引きが大切です。

QR コードの見本を記事やサムネイルに載せるときは、 できるだけ実データを入れるべきです。 QR 風のランダムな格子は、 読者には本物の QR に見えます。 もし読み取れなかったり、 関係のない文字列を指していたりすると、 記事全体の信頼性を落とします。

そのため本記事のサムネイルでは、 左側の QR コードに https://nandemo-tools.com/ を実際にエンコードしています。 右側の小さな8つの格子は、 実データではなくマスク条件 0〜7 のパターン見本です。 役割が違うので、 実QRとマスク見本を分けて表示しています。

技術記事の図版は、 それ自体が小さな仕様説明です。 とくに QR、 Base64、 バーコード、 暗号、 日付時刻のような分野では、 「それっぽいダミー」 が読者の誤解につながります。 本文だけでなくサムネイルも検証対象に含めるのが安全です。