画像のサイズを先に決めてから、QRコードを配置する

まず架空のキャンペーンURLを12個用意しました。リンク先はワークショップ、クリエイターの書籍、商品、写真教室の4種類です。それぞれに短いURL、キャンペーンパラメータを付けたURL、さらにパラメータを加えた長いURLを用意しました。2つの手順を比べる際は、URL全体を同一に保ちました。

各URLを2種類の誤り訂正レベルで符号化し、2種類の形式で保存しました。これにより、画像サイズごとに各手順で48ファイルができました。これは12個のURLを条件を変えて繰り返し試した結果であり、48人の顧客、48件のキャンペーン、48回の独立した試行ではありません。書き出し比較を始める前に、大きな元画像24ファイルすべてを両ソフトで読み取れることを確認しました。^[1]

差が最もはっきり出たのは540 × 540ピクセルでした。完成画像を縮小した場合、両ソフトが元のURLを完全に復元できたのは48ファイル中16ファイルです。背景を縮小した後、最終サイズでQRコードを配置すると、48ファイルすべてで復元できました。改善は両方の誤り訂正レベルで見られ、PNGでもJPEGでも見られました。

比較する各組で、QRコード用に確保した枠は同じ90 × 90ピクセルの正方形です。後から配置する方法では、コードを構成する小さな正方形を整数個のピクセルで描き、この枠内に収めました。リンクを短くしたり、キャンペーンパラメータを削ったり、リンク先を変えたりはしていません。表では12ファイルずつの4条件を示しています。

制作を依頼する企業にとって、この違いは納品時に求める確認内容に関わります。元ファイルが正しく開き、大きな画像のQRコードが読めることは有用な確認です。ただし、小さくした画像も別途確認する必要があります。承認の対象は元画像だけで終わらせず、実際の納品寸法とファイルまで指定するべきです。

QRコードは、モジュールと呼ばれる小さな正方形を並べた格子です。格子の構成は、リンクの内容と符号化の設定で決まります。QRコードを開発したデンソーウェーブは、データ量や誤り訂正の設定によって、より大きな格子が必要になると説明しています。また、通常のQRコードには、四辺それぞれに4モジュール幅の余白が必要です。この余白をクワイエットゾーンと呼びます。^[2][3]

実務で必要なのは、この格子全体と余白を納品画像に収めることです。1つ目の手順では、2,160 × 2,160ピクセルの画像にQRコードを含めた状態で全体を縮小しました。再サンプリングによって境界の色が混ざったり、格子の境界が最終画像のピクセル間に来たりする可能性があります。2つ目では背景を縮小し、元のQR格子を整数個のピクセルで直接描きました。

実測した1例で違いを見てみましょう。長いワークショップURLは199バイトでした。誤り訂正レベルMで符号化すると、57 × 57モジュールの格子になりました。余白を含めると幅は65モジュールです。元画像では1モジュールに5ピクセルを割り当てたため、余白込みの幅は325ピクセルでした。

画像を幅540ピクセルまで縮小すると、この幅は計算上81.25ピクセルとなり、モジュール境界の間隔は1.25ピクセルになります。できあがったPNGからは、両ソフトともURLを復元できませんでした。同じ格子を最終サイズで直接描くと、1モジュールは1ピクセル、余白込みの幅はより小さい65ピクセルになりました。こちらでは両ソフトとも完全なURLを復元できました。

比較しているのは、2つの書き出し手順全体です。コードの占有サイズ、位置、フィルタリングが一緒に変わるため、原因を1つに切り分けた実験ではありません。それでも「元画像のQRコードを大きくする」だけでは制作指示として不十分な理由が分かります。この例では、最終画像でより小さかったコードのほうを読み取れました。

書き出し方法を調整するときも、意図したURLは省略せずに保ちます。キャンペーンパラメータは、合意済みの効果測定計画の一部かもしれません。削除すれば納品するリンクが変わります。後から管理型リダイレクトや短いリンク先を検討する場合は、それ自体を別の判断として、リンク先とアトリビューションを確認する必要があります。今回の実験では、その代替案は試していません。

全サイズの比較を見ると、主な結果をどこまで適用できるかが分かります。幅1,080、720、540ピクセルでは、最後にQRコードを配置した全ファイルを両ソフトで読み取れました。完成画像を縮小した場合は異なり、各サイズ48ファイル中、両ソフトで読み取れたのは順に32、37、16ファイルでした。

画像が小さくなるほど成績が下がる、という単調な変化ではありませんでした。幅720ピクセルの画像は、1,080ピクセルよりも両ソフトで読み取れたファイルが多かったのです。縮小率と生成されるピクセルが違えば、読み取りソフトの結果も変わることがあります。この実験から、あらゆるQRコードに通じる最小ピクセルサイズは決められません。

幅360ピクセルでは、QRコード用の枠は60 × 60ピクセルしかありませんでした。余白込みで幅65モジュールや85モジュールが必要な格子もあり、1モジュールに1ピクセルを割り当てることすらできません。この24条件は、最後に配置する手順では作成できないと記録しました。読み取りソフトの失敗としては扱っていません。

そのため、幅360ピクセルの表では、残る24組だけを比較しています。両ソフトで読み取れたのは、完成画像を縮小した側で6ファイル、最後に配置した側で18ファイルでした。作成できた後者のファイルでも6ファイルは両ソフトでの読み取りに成功していません。この小さな範囲では改善しましたが、小さい画像がすべて読めるようになったわけではありません。

小型のキャンペーン画像では、次に決めるべきなのはコードと余白に割く場所です。空いている正方形ならどれでも同じように使えると考える前に、必要な場所を確保します。枠の寸法、完全なURL、符号化、最終出力を制作指示に含めてください。この対照実験で読み取れた1ピクセルのモジュールは、スマートフォンのカメラや印刷物に推奨するサイズではありません。

誤り訂正は、情報の一部が損なわれたときに、読み取り側が符号化されたデータを復元する助けになります。レベルを上げると、同じ内容でも必要な格子が大きくなることがあります。そのため、今回のMとHの比較には、限られた枠内でのトレードオフがありました。高い設定は、同一画像に保護機能だけを追加するものではありません。^[7]

幅540ピクセルで完成画像を縮小した場合、両ソフトで読み取れたのは、どちらのファイル形式でもMでは12ファイル中5、Hでは3でした。しかし別の対応比較ではHが上回りました。長いURLを使った1,080ピクセルでの8組と、キャンペーンパラメータ付きURLの720ピクセルPNGでの2組です。「常に低い設定を選ぶ」という助言では結果を正しく伝えられません。

ファイル形式にも単純な優劣はありませんでした。幅720ピクセル、レベルMで完成画像を縮小した場合、両ソフトで読めたのはPNGで10ファイル、JPEGで12ファイルでした。だからといってJPEGのほうが一般に安全とは言えません。ある保存形式の結果を、別の形式にもそのまま当てはめるべきでないことが分かります。

生成した360ファイル中54ファイルでは、ソフトによって結果が分かれました。幅1,080と720ピクセルでは、ZXing-C++はすべてを読み取れました。両ソフトでの成功数が少なくなったのはquirc側の結果によります。幅540ピクセルでは、最後にQRを配置すると、それぞれのソフトで個別に見ても改善しました。主な結果は両ソフトの一致で示し、個別の結果もダウンロード資料に残しています。

クライアントへファイルを渡すクリエイターが実践できるのは、予定する形式を指定し、実際に納品するリンクを完全に確認することです。ソフトウェアでの復号は画像ファイルの確認です。予定するスマートフォン、画面、印刷物での別途確認は、実際の利用体験の別の部分を確かめます。今回測定したのは前者なので、後者は画像を利用するチームが行う実務上の確認として残ります。

次の項目を制作指示書や納品メモにコピーし、必要な出力サイズごとに記入してください。事業側が決めるリンク先、デザイナーの書き出し設定、完成物を確認する担当者をつなぐための項目です。ダウンロード版は登録不要で、普段の制作手順に合わせて使えます。

キャンペーンと用途：[キャンペーン名、QRからつなげたい行動、画像の掲載先を記入。] リンク承認者：[リンク先とパラメータを承認できる担当者を記入。] 承認済みの完全なURL：[必要な全パラメータとパーセントエスケープを含め、文字列をそのまま貼り付け。]

最終画像：[幅 × 高さをピクセルで記入。] QR用の枠：[位置と、確保した幅 × 高さを記入。] クワイエットゾーン：[四辺すべてに空白の余白があることを確認。] 格子と配置：[生成ツールや書き出し工程で分かる場合は、モジュール数と、各モジュールに割り当てた整数のピクセル数を記録。]

符号化と書き出し：[生成ツール、誤り訂正設定、関連オプションを記入。] 作成順序：[最終寸法でQRを配置したかどうかを記入。] 保存形式：[PNGまたはJPEGと、その設定を記入。] 納品ファイル：[ファイル名など、対象を一意に特定できる情報を記録。]

ファイル確認：[使った読み取りソフト、確認したファイル、結果を記入。] 復元されたURL：[返された文字列全体を、承認済みURLと照合。] 未解決の結果：[失敗、ソフト間の不一致、枠に収まらない問題と、解決担当者を記録。] 未確認の結果にチェックマークを付けないでください。

利用時の確認：[予定する画面または印刷物、使用したスマートフォンなどの読み取り機器、担当者、確認日を記入。] リンク先の確認：[承認済みリンクが目的のページに届き、必要なキャンペーンパラメータが予定する経路で保たれることを確認。] これらは今回の画像ファイル比較とは別に行う確認です。

担当分担も分かりやすくします。キャンペーン担当者がリンクを承認し、デザイナーが指定の出力を作り、確認担当者が実際のファイルと用途をチェックします。その後、リンク、寸法、書き出し設定のどれかを変更したら、指示書を更新し、影響する出力を再確認してください。

企業が秋のワークショップを告知するため、クリエイターに制作を依頼する場面を考えます。必要なのは会場の画面に表示する正方形のデジタルカードと、キャンペーンメッセージに使う小さい版です。企業は参照元、メディア、キャンペーン、パートナーの情報を含むリンクを承認済みです。架空の制作場面ですが、引き継ぎを具体的にするため、実測したテストURLの1つを使います。

承認済みURLは、ダウンロード資料にある199バイトのワークショップ用URLです。キャンペーン名はautumn_2026、メディアはqrで、content項目は架空のクリエイターパートナーを示します。どちらの出力でも、この情報をURLに残します。コード内の情報を減らすためにクリエイターが削除することはありません。

納品メモの例では、540 × 540ピクセルのPNGを指定し、x=378、y=378を起点とする90 × 90ピクセルのQR用領域を設けます。実測したレベルMの符号化を使い、57モジュールの格子、4モジュール幅の余白、1モジュール当たり整数1ピクセルで配置します。余白込みの最終サイズは65 × 65ピクセルで、確保した領域の中央に置きます。

デザイナーは背景を先に縮小し、その後に格子を配置します。メモには保存ファイルを特定する情報と、ZXing-C++、quircの両方が元のURLを完全に返した実測結果を記録します。比較対象の結果も記録します。完成済みの元画像を縮小した対応するPNGからは、どちらもURLを復元できませんでした。この2つの結果は今回の実験によるもので、実際の顧客キャンペーンの結果ではありません。

企業側は、実際の会場画面と、想定するスマートフォンでの利用経路を引き続き確認する必要があります。小さい版が別サービスで再圧縮または再縮小されるなら、その結果のファイルや表示も確認します。そのサービスは今回測定しておらず、元の確認に合格しても、追加の変換後の挙動までは分かりません。

後から制作指示に幅360ピクセルのカードが追加され、QR用領域の相対的な大きさは変えないとします。枠は幅60ピクセルになりますが、このコードは余白込みで65モジュール必要です。整数ピクセルで描く今回の手順では作成できません。デザイナーは、実際には作れない出力を成功と報告するのではなく、配置上の問題を伝え、場所を広げるか、別の納品方法にするかを相談します。

これが具体的な引き継ぎの価値です。画像をまだ変更できる段階で相談できます。承認済みリンクを保ちながら、対応が必要な出力を特定し、大きなモックアップでの成功を、その後のすべてのファイルの承認と取り違えずに済みます。

テスト画像を読み取る前に、架空のURL12個、画像の配置、寸法、設定を固定しました。URLはexample.comを使用し、アクセスしていません。リンク先4種類にそれぞれ3種類のURLを用意し、長さは39～203バイトでした。誤り訂正MとH、正方形画像の幅4種類、保存形式2種類を試し、2つの手順を合わせて384のファイル条件を計画しました。^[1]

Segno 1.6.6で通常のQRコードをバイトモードで生成し、誤り訂正レベルの自動引き上げは無効にしました。各URLと訂正レベルの組み合わせは1回だけ符号化し、両手順で同一の行列を再利用しました。元画像は2,160ピクセル四方です。Pillow 13.0.0でLANCZOSによるリサイズを1回行い、JPEGは品質85、クロマサブサンプリング無効で保存しました。コードはすべて白地に黒で、4モジュール幅の余白を付けています。^[4]

保存画像全体を8ビットのグレースケールに変換し、同じ画像を両ソフトに渡しました。ZXing-C++ 3.1.1と、設定を固定した特定ビルドのquircを使用しました。完全復元と判定するには元のURLのバイト列と一致し、別の内容を成功結果として返していないことを必要としました。追加の切り抜き、拡大画像での再試行、手作業による救済は行っていません。読み取り設定、各ファイルの配置情報、結果はパッケージに収録しています。^[5]

元画像24ファイルはすべて両ソフトで読み取れました。予定した384の書き出し条件のうち360ファイルを生成でき、24条件は最後に配置する手順では作成できませんでした。比較できた手順の組は168組です。ソフト間の不一致、作成できても読めなかったファイル、どちらかの誤り訂正レベルが上回った比較も含め、すべての条件を残しています。結果が示すのは、これらの人工的なファイルとソフトウェアビルドの挙動であり、消費者のスキャン成功率ではありません。

場所の確保、クワイエットゾーン、画質の重要性は、既存のガイダンスでも説明されています。QRottoは、拡縮とぼかしを加えた後の元画像の解像度比較も公開しています。今回の貢献はもっと限定的です。各組の完全なURLと符号化した行列を保ちながら、画像の書き出し工程のどの段階でQRコードを置くかを、固定した手順で比べました。全表と作成条件は以下から入手できます。^[6]