アートQRコードが読み取れる理由:ハーフトーンという考え方
アートQRコードが読み取れるのは、一部のデコーダーが各モジュールを全体として判定しないからです。オープンソースのデコーダーZXingは、各モジュールの計算上の中心にある1ピクセルを読み取ります。Chuらが2013年に発表したハーフトーンの手法はこれを利用したもので、各モジュールの中心に正しい色のドットを残し、その周りに絵を透かして見せます。ぼけや重ねたものが中心に届くとこの仕組みは失敗するので、どのデザインもデコードテストと印刷した試し刷りが必要です。
2026年10月17日に事実確認。
スキャナーが見るところ、見ないところ
以下の構造はISO/IEC 18004の2006年版によるものです。第4版が2024年8月に発行されましたが、全文は読んでいません。QRコードには同じ形の位置検出パターンが3つあり、暗い7×7、明るい5×5、暗い3×3のモジュールから成り、比率は1:1:3:1:1です。3つすべてを見つけると、リーダーはシンボルの位置と回転を把握できます。次に、タイミングパターンとアライメントパターンがモジュールの格子を配置する手助けをします。
格子が決まると、デコーダーは各モジュールをサンプリングします。2022年のEUSIPCOの論文は、各モジュールの中心ピクセルだけがサンプリングされるという前提に立っていますが、サンプリング格子の推定に誤差があると近くのピクセルがサンプリングされることもあると補足しています。iPhoneやAndroidの標準カメラがどうデコードしているかは確認していないので、ZXingは1つの例であって、すべてのスマートフォンに当てはまるわけではないと考えてください。
ハーフトーンの考え方
Chu、Chang、Lee、Mitraは2013年11月、ACM Transactions on Graphicsに「Halftone QR Codes」を発表しました。論文のモデルは各モジュールを3×3のサブモジュールに分け、モジュールの色を中央の1つに結び付け、残りの8つはハーフトーン画像に合わせて自由にします。理想的な条件では、中心の色が正しければどんな模様でもモジュールは読めるはずだと彼らは述べています。変更するのはデータモジュールだけです。
モジュールごとの約束と考えてください。中心は常に正しく、残りは絵を見せてよい、というものです。デコーダーがちょうど中心をサンプリングするなら、絵はどのコード語も壊さないので、誤り訂正は予備として残ります(これは私たちの解釈で、論文の主張ではありません)。実際のサンプリングは完璧ではなく、予備が使われるのはそこです。著者らは、テストで訂正能力の最大半分を意図的に使う任意の手順も説明しています。
論文はその代償を率直に述べています。データを運ぶ中心ピクセルは隣のピクセルに汚されやすいため、縮小によるぼけを限界として挙げています。5つのコード、3人の利用者、スマートフォンのバーコードリーダー4種によるテストでは、ハーフトーンのコードはガウスぼかしの半径2ピクセル、視野角40度で読めなくなり、対応する通常のコードは6ピクセル、60度まで読めました。同じ論文は、既定の設定で作った100個のコードのうち、91個が4種すべてのリーダーで読めたと報告しています。テストは800万画素のスマートフォン1台とモニターに表示したコードで行われたので、今のスマートフォンの予測ではなく、傾向として読んでください。
アートコードが壊れるところ
各行は、中心サンプリングの前提を崩すか、誤り訂正の能力を使ってしまうものです。最後の列は、どれが私たち自身の推論かを示しています。
| やること | 起きる問題 | 根拠 |
|---|---|---|
| 暗い背景に明るいモジュールを置く | 2006年版は暗い背景に明るいシンボルを認めていますが、反転画像を試すかどうかは各デコーダー次第です。ZXingは呼び出し側がヒントを設定したときだけ試します。jsQRは既定で両方を試し、速度は約50%落ちます。 | 規格、2つのデコーダー。スマートフォンのカメラは未確認 |
| 3つの角のパターンの上に絵を描く | これらはシンボルの位置と向きを決めるもので、Chuらもデータモジュールしか変更していません。 | 2006年版、Chuら |
| 余白を4モジュール未満にする | 2006年版は4モジュール幅のクワイエットゾーンを求めています。DENSO WAVEは、コードの周りに文字や絵があると必要な余白を確保できないとしています。 | 2006年版、DENSO WAVE |
| 絵を見せるために中心のドットを小さくする | サンプリング格子が少しずれたときの余裕が減ります。2013年のテストでも、ハーフトーンのコードは許容できるぼけと角度が小さくなりました。 | EUSIPCO 2022、Chuら。ドットの大きさとの関係は私たちの推論 |
| ドットを絵の色で着色する | 明暗の差が縮むことがあります。ZXingの二値化処理は、最も明るいピクセルと最も暗いピクセルの差が24段階以下(0〜255の尺度)の8×8ピクセルのブロックを、明るいピクセルだけか暗いピクセルだけを含むものとして扱い、しきい値を別の方法で推定します。 | ZXingのソースコード。着色との関係は私たちの推論 |
「30%の誤り訂正」が面積の30%ではない理由
2006年版は、レベルL、M、Q、Hのおおよその復元能力を、シンボルのコード語に占める割合で7%、15%、25%、30%としています。DENSO WAVEも、訂正率を全コード語に対する割合で表しています。規格はさらに、1つのモジュールが反転すると、その文字は一見有効だが異なるコード語としてデコードされ、それを直すには訂正用のコード語が2つ必要だと述べています。例として、バージョン6-Hのシンボルには172個のコード語があり、そのうち112個が訂正用で、56個の誤デコード、つまり能力の32.6%を直せるとしています。
ですから、面積の割合はどれも推測にすぎません。規格のビット配置の図を私たちが読む限り、通常のシンボルでは1つのコード語が幅2モジュール、高さ4モジュールの列に収まっているので、私たちの推論では、散らばった小さな点は、同じ面積の1つの塊よりも多くのコード語に触れる可能性があります。デザインがどれだけの面積を覆ってよいかについて、私たちは何も主張しません。レベルの選び方は誤り訂正レベルの解説を、完成した例は業種別のデザインアイデアをご覧ください。
印刷前にアートコードを確認する方法
- レベルHと、できるだけ短い内容から始める。 同じ印刷サイズなら、内容が長いほどモジュールは小さくなり、DENSO WAVEはモジュールが大きいほど安定して読みやすいとしています。シンボルがどれだけ早く大きくなるかはデータ容量のガイドで確認できます。
- あらゆる場所で明暗を確認する。 デザインをグレースケールに変換します。絵の明るい部分でも暗い部分でも、暗いドットはすべて隣の明るいドットよりはっきり暗くなければなりません。
- 複数のサイズでデジタルにデコードする。 無料のQRコードチェッカーは画像をアップロードせずにブラウザ内で動作し、コントラストとクワイエットゾーンをテストし、縮小したサイズで再テストし、反転しないとデコードできないコードを指摘します。
- 試し刷りをして、異なるスマートフォンでスキャンする。 規格の参考附属書は、「上掛け、裏抜け、曲面や不規則な表面はいずれもシンボルの読み取りやすさに影響しうる」ので、最終的なラベルやパッケージの形でシンボルを検証するよう述べています。Chuらは1台のスマートフォン上の4種のバーコードリーダーで結果が違うことを確認しているので、少なくとも2台のスマートフォンを使い、実際の距離と明るさで試してください。最小幅は印刷サイズのガイドをご覧ください。
- 失敗したら、一度に1つだけ変える。 中心のドットを大きくする、絵のコントラストを下げる、大きく印刷する、内容を削る、のいずれかを行い、手順3と4を繰り返します。
内蔵チェックで分かること、分からないこと
QR Maker AIのエディターでは、季節のテーマや「福」の字のような図柄のハーフトーンは無料で、画像の融合(自分の画像をドットの下に敷くこと)は2026年10月時点でProの機能です(料金をご覧ください)。図柄のハーフトーンと画像の融合では、エディターは各モジュールに中心のドットだけを描き、角のパターン、アライメントパターン、ロゴの領域の下には明るい無地のブロックを敷き、誤り訂正をレベルHに設定します。
エディターのScan Guardチェックは、描画したコードを通常のサイズといくつかの小さいサイズでブラウザ内でデコードします。使うのはオープンソースのデコーダーで、明るい地に暗いコードのモードだけです。暗い地に明るいコード、紙、インク、曲面、スマートフォンのカメラはテストできないので、手順4の試し刷りは省けません。デザインはエディターで試せます。
よくある質問
アートQRコードはどういう仕組み?
ハーフトーン型のコードは、各モジュールの中心に正しい色のドットを残し、その周りに絵を描きます。ZXingなどのデコーダーはモジュールの中心付近をサンプリングするからです。誤り訂正はその上に乗る安全マージンです。
QRコードの背後に写真を置いても読み取れる?
ドットが周囲よりはっきり暗いか明るいままで、角と余白がきれいに保たれ、誤り訂正がHなら、うまくいく可能性があります。必ず読めるデザインはないので、試し刷りでテストしてください。
暗い背景に白いドットを使ってよい?
規格は暗い背景に明るいシンボルを認めていますが、対応はアプリ次第です。ZXingは指示されたときだけ反転画像を試します。明るい地に暗いコードのほうが安全です。反転したデザインは、対象の人が使うスマートフォンで必ずテストしてください。
QRコードのどれくらいをデザインで覆ってよい?
レベルは面積の割合に換算できません。誤り訂正レベルはコード語の割合として定義されており、1つのモジュールが反転するだけでそのコード語全体が損なわれます。実際のファイルでテストしてください。
デザインしたQRコードが読み取れないのはなぜ?
色の反転、角が隠れている、余白が4モジュール未満、暗いドットと明るいドットのコントラスト不足、小さすぎる印刷を確認してください。その他の原因はトラブルシューティングの一覧にまとめています。
出典
- ZXing project — DefaultGridSampler.java. Undated source file. Accessed 17 October 2026.
- Chu, H.-K., et al. — Halftone QR Codes. ACM Transactions on Graphics 32(6), Article 217, SIGGRAPH Asia 2013 (author-hosted PDF, National Tsing Hua University; publisher record: ACM Digital Library). Published 1 November 2013. Accessed 17 October 2026.
- ISO/IEC — ISO/IEC 18004:2006, QR Code 2005 bar code symbology specification. Second edition, published 1 September 2006 (copy hosted by Public.Resource.Org). Accessed 17 October 2026.
- ISO — ISO/IEC 18004:2024 standard page. Fourth edition, published August 2024. Accessed 17 October 2026.
- Pena-Pena, K., Lau, D. L., Arce, G. R. — Colored-QRNet: Fast QR Code Color Image Embedding. EUSIPCO 2022 proceedings. Published 2022. Accessed 17 October 2026.
- ZXing project — DecodeHintType.java. Undated source file. Accessed 17 October 2026.
- jsQR project — README. Undated. Accessed 17 October 2026.
- DENSO WAVE — Examples of problems encountered in reading a code. QRcode.com, undated. Accessed 17 October 2026.
- ZXing project — HybridBinarizer.java. Undated source file. Accessed 17 October 2026.
- DENSO WAVE — Error correction feature. QRcode.com, undated. Accessed 17 October 2026.
- DENSO WAVE — Point for setting the module size. QRcode.com, undated. Accessed 17 October 2026.