QRコードのロゴはどのくらい大きくすることができますか？測定しました

「30%エラー訂正」はロゴの予算ではありません。実際のデコーダーが諦めるまであらゆるECレベルでコードに成長する穴を開け、どこで破損したかを記録しました。

Max Čelar·2026年8月31日·印刷とスキャン

このトピックの新機能: QRコードがあらゆるエラー訂正レベルで許容する最大の中央パッチ。実際のシンボルで成長する穴を開けてjsQRでデコードすることで測定—Lで4%、Mで7%、Qで12%、Hで17%—さらに誰も公開しない2つの結果：散在したダメージはコードを4%で破損しますが、1つの連続したblobは17%で生き残り、同じパッチをfinder patternの上に配置すると1%で破損します。

QRコードにロゴを配置するあらゆるガイドは、同じ2つのことを述べています：エラー修正レベルHを使用し、コードの30%を復旧できることを覚えておくこと。この後半は非常に頻繁に繰り返されるため、デザイン仕様になってしまいました - 最大30%をカバーする - しかし、それは数字が意味することではありません。

私たちは実際に、それが何を意味するのかを測定しました。

# 「30%のエラー修正」が実際に意味すること

QRコードは、失う可能性のあるピクセルとしてデータを保存しません。コードワードを保存します：8モジュールのブロック。Reed–Solomonエラー修正によって保護されています。レベルHの主要な数字は、これらのコードワードのうちほぼどのくらいが再構築できるかを示しています。ただし、その容量の一部は、あなたが何かに触れる前にエンコーディング自体のオーバーヘッドで消費されます。

この数字より重要な2つの結果があります：

• ダメージはモジュールごとではなく、コードワードごとにカウントされます。1つのモジュールを破損すると、それが属する完全なコードワードが破損されます。
• ファインダーパターン、タイミングパターン、フォーマット情報は、エラー修正でまったくカバーされていません。これらはデコーダがシンボルを最初に見つける方法であり、それらを再構築する方法がありません。

ですから「30%」は数学についての事実であり、画像についての許可ではありません。 ここが許可です。

# レベル別の測定済みロゴ予算

方法。これを再実行できるようにします：https://mqr.sh/AB12CD をMostlyQRが提供するエンコーダ（buildMatrix、MIT node-qrcode をラップ）でエンコードします。シンボルバージョン3（29モジュール）に固定します。すべてのエラー修正レベルで、ECが唯一の変数になるようにします。モジュールあたり8ピクセルでレンダリングし、完全な4モジュールのクワイエットゾーンを使用します。中央の正方形を白くします。シンボルの面積の1%から始まり、毎回1%ずつ大きくなります。各ステップの後、ピクセルをjsQR 1.4.0に渡します。記録された数字は、最初の失敗の前にデコードされた最後のサイズです。

レベルHはおおよそレベルLの4倍の価値があります - 実際の違いであり、あらゆるガイドがそれを使用するよう勧める理由です。また、30%にはほど遠いです。

これらの数字から経験則として：レベルHでは、コード領域の約15%を占める中央配置ロゴ - コード幅のおおよそ39%の正方形 - は測定済み制限内で余裕があります。レベルMの測定済み制限は7%で、幅のおおよそ26%の正方形です。同じ方法でデレートすると、約5分の1に下がります。

16ピクセル/モジュールで全体を再実行し、同じ結果を得ました。これは予想される結果です：これはシンボルのプロパティであり、レンダリングのプロパティではありません。

# ブロブがコンフェッティより安い理由

ここが予想できなかった結果であり、中央配置ロゴがそもそも機能する理由を説明するものです。

1つの連続パッチの代わりに、個々のデータモジュールをシンボル全体でランダムに反転させました - すべてのファインダー、タイミング、アラインメントパターンは触れずに - そしてデコードが失敗するまでレートを上げました。同じペイロード、同じバージョン、同じデコーダ、5つの異なるランダムシード：

(v3シンボルは841モジュールを持ち、そのうち567はデータを運びます。残りはファインダー、タイミング、アラインメント、フォーマットパターンであり、このテストは無視しました。)

同じレベルで、4%分散対17%のブロブ。

理由はコードワードです。17%の連続正方形は、少数のコードワードを完全に破損させます。同じ量のダメージを均等に散布すると、多くのコードワードの一部が破損されます - そしてモジュールが1つ悪いコードワードは、8つ悪いコードワードと同じくらい壊れています。エラー修正はダメージではなく犠牲をカウントします。

これは通常の直感を反転させます。1つの場所にある1つのきれいな形がエラー修正を使用する最も安い方法です。スペックル、テクスチャ、半透明ウォーターマーク、またはコード全体にわたるフォトフィルタは、ダメージが少なく見えるときでも最も高いものです。

# 触れてはいけない3つのコーナー

同じテスト、同じ成長する正方形、2つの他の位置に移動：

レベルLでは、左上のケースは最初のステップで失敗しました - 1%未満。

これらのコーナーは構造であり、コンテンツではありません。3つの大きな同心正方形はファインダーパターンであり、右下の近くにある小さい正方形はアラインメントパターンです。それらの間で、デコーダはシンボルがどこにあるか、どのくらい大きいか、どのように回転またはスキューされているかを計算します。1つをカバーすると、到達するデコードステップがありません。エラー修正レベルはほとんど違いを作りません。なぜなら、エラー修正は彼らを保護していなかったからです。

これがロゴの安全な場所が中央である理由であり、「単に小さくしてコーナーに配置」が正確に逆である理由です。

# カメラがこのテストに追加するもの

上記のすべては、きれいで、合成的で、最高のケースです：

• 1つのデコーダ。 jsQRは良い、広く使用されているデコーダですが、電話のカメラスタックはjsQRではありません。実際のリーダーは、破損したコードへの試行の積極性が異なります。
• 完璧なピクセル。 ぼかし、眩光、パースペクティブ、プリントはありません。これらのそれぞれが予算を減らします。
• きれいな白い穴。 実際のロゴには、色、エッジ、および下のモジュールに対するアンチエイリアシングがあります。ロゴの後ろの白いプレートは装飾ではありません - それはカバーされた領域を明確にするものです。

テーブルを理想的な条件下で測定された上限として扱い、設計対象ではありません。私たち自身のアドバイスは、それの約3分の2を使用することです。

# これを自分で再実行する

上記のすべての数字は、記事に入力されるのではなく、スクリプトによって出力されます：当社のリポジトリの draft/mostlyqr/seo/benchmarks/logo.js。各レベルでシンボルをレンダリングし、毎回1%ずつ各パッチを拡大し、5つのシード全体で分散ダメージ比較を実行し、2番目のピクセルスケールで全体を再実行します。また、このピースの終わりに引用されている境界について、独自のバリデーターをプローブします。

# 実際にすべきこと

1. ロゴがある場合はエラー修正レベルHを使用してください。 これはおおよそあなたの予算を4倍にします。短いリンクで側面当たり約4つの追加モジュールがかかります。これは推測するのではなくサイズ決定を計算することです。
2. ロゴを中央に配置し、コード領域の約15%以下に保ちます。 これはレベルHでコード幅の約39%の正方形です。
3. ソリッドプレートに配置します。カバーされた領域が曖昧ではなくきれいになるようにします。
4. 3つのコーナー正方形に何も触れないようにします - ロゴではなく、フレームではなく、丸いコーナークロップでもありません。
5. 悪い電話で実際のプリントをテストしてください。 ここのすべての数字は、どの設計がテストする価値があるかを示しています。テストだけが、それが機能するかどうかを示しています。

画像がコードの中央のパッチではなく、コード全体になるようにしたい場合、これは異なるテクニックで異なる予算があります - フォトQRコードを個別に測定しました。彼らはまったくエラー修正を使用しないことが判明しました。そしてただロゴ付きのコードが必要な場合は、MostlyQRのジェネレータロゴが追加された瞬間にエラー修正をレベルHまで強制し、4モジュールのクワイエットゾーンを保持し、ロゴをデフォルトとしてコード幅の22% - 面積の4.8%に設定します。上記で測定されたすべての内側で快適です。

私たち自身のコードについて正直な注記です。数字を公開しているため、オーバーサイズロゴを拒否するガードは名目上の30%回復数字を15%のヘアカットで使用するため、レベルHで領域の約25%をカバーするロゴを受け入れます。私たちの測定は、実際の天井はより近い17%であることを示しています。誰も変更しないデフォルトは大幅に安全ですが、制限は証拠がサポートするより緩いです。これはQRコードの微妙性ではなく、バリデーターのバグであり、修正リストにあります。