QRコードのサイズ要件：基本
QRコードのサイズ要件は2つの要素で決まります：エンコードするデータ量と読み取り距離です。QRコードは白黒のモジュール（正方形）のグリッドです。最小のQRコード（バージョン1）は21×21モジュールで、最大25文字の英数字を格納できます。最大（バージョン40）は177×177モジュールで、最大4,296文字の英数字を格納できます。データが多い = モジュールが多い = 確実な読み取りに必要な物理サイズが大きい。
確実な読み取りのための最小物理サイズは、モジュールサイズで決まります——各正方形がカメラで解像できる大きさでなければなりません。スマートフォンで腕の長さ（約25cm）から読み取る場合、各モジュールは最低0.33mm必要です。バージョン1のコード（21モジュール + 8モジュールのクワイエットゾーン = 幅29モジュール）は最低10mm × 10mmが必要です。バージョン10のコード（57モジュール）は最低25mm × 25mmが必要です。
印刷物での目安：QRコードは名刺や近距離読み取りで最低2cm × 2cm、商品パッケージで3-4cm、遠距離から読み取るポスターや看板で10cm以上にしましょう。読み取り距離はQRコードの幅の約10倍です——3cmのコードは約30cmの距離から読み取れます。
誤り訂正レベル（L, M, Q, H）
QRコードにはリード・ソロモン符号による誤り訂正が組み込まれています。コードの一部が損傷したり隠れたりしても読み取れるということです。4つのレベルがあります：L（低、7%復元）、M（中、15%復元）、Q（四分位、25%復元）、H（高、30%復元）。誤り訂正が高いほど冗長データが多くなり、モジュールが増え、同じ内容でもコードが大きくなります。
トレードオフは現実的です。"https://example.com/page"のようなURLはレベルLでバージョン2のコード（25×25モジュール）を生成します。同じURLがレベルHではバージョン4のコード（33×33モジュール）になります——同じデータで74%多いモジュールです。きれいで平らな面（画面表示、新しい印刷物）ならレベルLかMで十分です。コードが汚れたり、傷ついたり、部分的に隠れる可能性がある環境（商品パッケージ、屋外看板、倉庫ラベル）ではQかHを使いましょう。
誤り訂正があるからこそ、QRコードの中央にロゴを配置できます。ロゴをコードの上に置くと、そのモジュールを意図的に破壊しています。レベルH（30%復元）なら、コード面積の最大30%を覆っても読み取れます——ただし実際にはロゴは15-20%以下に抑えてください。損傷が均等に分布しないためです。3つの大きな位置検出パターン（角）とアライメントパターンは遮らないでください。
ほとんどの用途での推奨：レベルM（15%）。軽微な印刷の不完全さや若干の損傷に対応しつつ、コードをコンパクトに保ちます。ロゴオーバーレイが必要な場合や物理的損傷が予想される場合のみレベルHを使いましょう。管理された環境での画面間読み取りなど、最小サイズを最適化する場合のみレベルLを使いましょう。
データ容量とコンテンツの制限
レベルLでの最大容量：数字7,089文字、英数字4,296文字、バイナリデータ2,953バイト。レベルHでは数字3,057、英数字1,852、バイナリ1,273バイトに減ります。実際にはこれらの上限に近づくことは稀です。大きなコードは確実に読み取るのが難しくなるためです。
URL（最も一般的なQRコードの内容）は100文字以下に抑えましょう。100文字のURLはレベルMでバージョン7のコード（45×45モジュール）を生成します——まだ十分読み取れます。300文字のURLはバージョン13のコード（69×69モジュール）を生成します——大きくなってきます。URLが長い場合は、短縮URLサービスやリダイレクトを使いましょう。QRコードは遷移先を気にしません——与えられたテキストをエンコードするだけです。
エンコードモードが容量に影響します。QRコードは最も効率的なエンコードを自動選択します：数字モード（0-9のみ、1文字あたり3.3ビット）、英数字モード（0-9, A-Z, スペース, $%*+-./:、1文字あたり5.5ビット）、バイトモード（任意のUTF-8、1文字あたり8ビット）。大文字のURLは英数字モードに収まるため、小文字より効率的にエンコードされます。"HTTPS://EXAMPLE.COM"は"https://example.com"よりモジュールが少ない——サイズ制約のあるコードで知っておくと便利なテクニックです。
注意点：WiFi QRコード（WIFI:T:WPA;S:ネットワーク名;P:パスワード;;）はパスワードが長いと大きくなります。63文字のWPA2パスワードを含むWiFi QRコードはバージョン8を生成します。店舗用のWiFiコードを生成する場合は、パスワードを適度な長さにするか、qr-code-generatorツールで印刷前にサイズをプレビューしましょう。
QRコード バージョン vs 容量（誤り訂正レベルM）：
バージョン モジュール 英数字 典型的な用途
1 21×21 20 短縮URL（bit.ly/abc）
2 25×25 38 中程度のURL
3 29×29 61 フルURL（パラメータなし）
4 33×33 90 短いパラメータ付きURL
5 37×37 122 中程度のパラメータ付きURL
7 45×45 196 長いURLまたはvCard
10 57×57 311 フルvCard
14 73×73 489 大きなテキストブロック
20 97×97 858 非常に大きなペイロード
40 177×177 2,331 最大（ほぼ使わない）
目安：確実な読み取りにはバージョン10以下に抑える。
バージョン15以上は近距離・高解像度カメラが必要。読み取り不能にする設計ミス
ミス1：クワイエットゾーンの不足。QRコードは四辺に最低4モジュール分の白い余白（クワイエットゾーン）が必要です。これによりスキャナーがコードと周囲のコンテンツを区別できます。クワイエットゾーンを切り取ったり、忙しい背景にコードを配置するのが読み取り失敗の第1位の原因です。マーケティングチームが「スペース節約」のために余白を削って、30%のユーザーが読み取れない理由を不思議がるのを見てきました。
ミス2：低コントラスト。QRコードは最大コントラストで最もよく機能します——白背景に黒モジュール。濃い青に薄い青、濃いグレーに中間グレーでは、スキャナーがモジュールを区別する能力が低下します。ISO 18004規格は最小コントラスト比を要求していますが、多くのスマートフォンカメラは40%以下のコントラストで苦戦します。白地に黒、または白地に非常に濃い色を使いましょう。
ミス3：色の反転。黒背景に白モジュール（反転QRコード）は技術的にはほとんどのモダンなスキャナーで動作しますが、古いスマートフォンや一部の専用スキャナーは反転コードで失敗します。暗い背景を使う必要がある場合は、コード自体を反転するのではなく、適切なクワイエットゾーン付きの白い矩形の中にQRコードを配置しましょう。
ミス4：読み取り距離に対して小さすぎる印刷。3メートルから読み取ることを想定したカンファレンスバナーに1.5cmのQRコードは絶対に機能しません。ルール：読み取り距離 ≈ コード幅の10倍。3メートルの読み取り距離には、最低30cm幅のコードが必要です。高速道路の看板（コードが小さすぎ）、レストランのテーブルテント（暗い隅にコード）、イベントバッジ（写真背景の上にコード印刷）でこのミスを見てきました。
用途別のQRコード
URL：最も一般的な用途です。https://を含むフルURLをエンコードしましょう。永続的に管理できない限り、短縮URLサービスのURLをエンコードしないでください——短縮サービスが停止したら、印刷されたすべてのコードが無効になります。トラッキングにはUTMパラメータを追加：https://example.com/page?utm_source=qr&utm_medium=print&utm_campaign=flyer2026。パラメータ内の特殊文字はURLエンコードしましょう（url-encoderツールが役立ちます）。
WiFi認証情報：フォーマットはWIFI:T:WPA;S:ネットワーク名;P:パスワード;H:false;;です。Tはセキュリティタイプ（WPA、WEP、またはnopass）、SはSSID、Pはパスワード、Hは隠しネットワークかどうか。iOSとAndroidの両方がこのフォーマットを認識し、自動接続を提案します。オフィス、ホテル、カフェのゲストネットワークに最適です。
vCard（連絡先情報）：vCardフォーマット（BEGIN:VCARD...END:VCARD）は名前、電話番号、メール、住所、会社をエンコードします。すぐに大きくなります——住所付きのフルvCardは300文字以上になり、バージョン10以上のコードが必要です。最小限に抑えましょう：名前、電話番号、メール。残りは後で調べてもらいましょう。
決済：地域によって異なる規格が使われています。中国はAlipay/WeChat PayのQRフォーマット。ヨーロッパはSEPA送金用のEPC QRコード。インドはUPI QRコード。ブラジルはPIX。日本ではPayPay、LINE Pay、楽天ペイなどが独自のQRフォーマットを使用しています。普遍的な決済QR規格はありません——ターゲットユーザーの決済アプリが期待するフォーマットを生成する必要があります。決済ページへのURLで十分だと思わないでください。ネイティブ決済QRコードは決済フローを直接起動します。
動的QRコード vs 静的QRコード
静的QRコードは最終的なコンテンツを直接エンコードします。遷移先を変更するには新しいコードが必要です。動的QRコードは短いリダイレクトURL（qr.example.com/abc123のような）をエンコードし、印刷後でも任意の場所に転送先を更新できます。QRコード自体は変わりませんが、遷移先は更新可能です。
動的コードはサイズが小さく（短いリダイレクトURL = 少ないモジュール）、トラッキング可能です（リダイレクトサーバーがスキャン数、場所、デバイスを記録）。欠点は：リダイレクトサービスが稼働し続けることに依存すること。サービスがダウンしたり会社が閉鎖されたりすると、印刷されたすべてのコードが壊れます。QRコードサービスがピボットしたり倒産して、何千もの印刷物が一夜にして無効になったケースを見てきました。
推奨：永続的なコンテンツ（WebサイトURL、WiFiパスワード、連絡先情報）には静的コードを使いましょう。印刷後に遷移先を変更する必要が本当にある場合（A/Bテスト、季節のプロモーション、定期的に更新されるコンテンツ）のみ動的コードを使いましょう。動的コードなしでトラッキングするには、静的URLにUTMパラメータを使えば、単一障害点のリスクなしにアナリティクスが得られます。
コストの考慮：ほとんどの動的QRコードサービスは月額料金がかかります（ビジネスプランで月¥2,000-8,000程度）。印刷物に100個のコードがあれば、永久に継続的なコストです。自分のドメインを指す静的コードは印刷後のコストがゼロです。動的な動作が必要なら、自前のリダイレクトサービスをホスティングすることを検討しましょう——ショートコードをURLにマッピングするデータベースという簡単なアプリケーションで、永続的に管理できます。
印刷前のQRコードテスト
印刷に出す前に、必ず3台以上の異なるスマートフォンでテストしましょう。テスト対象：古いスマートフォン（iPhone SEや格安Android——遅いカメラ、低解像度）、現行フラッグシップ（理想的な条件で動作確認）、画面保護フィルムが割れたり汚れたりしたスマートフォン（実環境のシミュレーション）。3台すべてが想定距離で確実に読み取れれば問題ありません。
大量発注する前に、オフィスのプリンターで実寸テスト印刷しましょう。インクジェットとレーザーでは細部の処理が異なり、紙の質感がコントラストに影響します。光沢紙は特定の照明下でグレアを起こし、読み取りを妨げることがあります。QRコードにはマット紙が一般的に安全です。
スキャン可能性だけでなく、エンコードされたコンテンツもテストしましょう。以前、完璧に読み取れるQRコードのチラシを5,000枚印刷したことがあります——しかしURLにタイプミスがありました。コードは正常に機能しましたが、404ページに遷移しました。最終コードをスキャンし、リンクをたどり、モバイルで遷移先が正しく読み込まれることを確認してください。トラッキングパラメータがアナリティクスに正しく記録されることも確認しましょう。
大量印刷（10,000枚以上）の場合は、印刷会社に校正刷りを依頼してテストしましょう。商業印刷プロセス（オフセット、デジタル）はオフィスプリンターとやや異なる結果を生むことがあります。モジュールの端がわずかににじんでコントラストが低下する可能性があります。レーザープリンターで問題なく読み取れるコードが、モジュールが最小限のサイズの場合、商業オフセット印刷で失敗することがあります。