QRコードを1個作るのは1分の作業です。しかし300個作るとなると、仕組みが必要になります。一括作業がスムーズに終わるか、1週間の再印刷地獄になるか。その分水嶙はほとんどの場合、生成ツールの性能ではなく、ツールに渡すデータの品質と、プロセスの規律です。この記事では、資産ラベル、イベントのバッジ、製品ライン、飲食店のテーブル、チケットなどに使える、QRコード大量作成の完全なワークフローを解説します。
生成ツールではなく、スプレッドシートから始める
最もよくある失敗は、QRコードツールを先に開いて、1個ずつ手入力で作ってしまうことです。数十個を超えるなら、スプレッドシートが唯一の「信頼できる情報源」であり、他のすべてはそこから派生します。生成ツールに触れる前に、まず表を作りましょう。
1行につき1コード。最低限、次の4列を用意します。
- ID — コードそのものを識別する一意の値。ファイル名や管理に使います（例：14番テーブルなら
TBL-014）。 - リンク先 — QRコードに埋め込むURLまたはテキスト。
- ラベル — コードの下や横に印刷する、人間が読めるテキスト（「テーブル14」「資産：ノートPC 032」など）。
- ステータス — 最初は空欄。後から
検証済み、生成済み、印刷済みなどの値を入れます。
列を追加するのは自由です。設置場所、担当者、バッチ番号、印刷日などがあってもよいでしょう。ただし、データベース化しようとする衝動は抑えてください。数百個程度なら、見出しが整理されたシンプルなCSVかスプレッドシートで十分です。
後から何時間も節約になる、データ整理のルール：
- セルの結合をしない。行の途中に空白行を入れない。URLの末尾に余分な空白を残さない。
- 1行につきリンク先は1つ。2行が同じリンク先を指す場合、それが意図的（複数のラベルが同じページを指す）なのか、入力ミスなのかを判断します。
- IDは必ず一意に。ID列で並べ替え、抜けや重複を目視で確認します。
- IDとファイル名には、可能な限り半角英数字を使う。スペースや特殊文字を含むファイル名は、プリンターや共有ドライブで問題を起こしがちです。
生成する前に、すべてのリンクを検証する
QRコードは生成された瞬間に凍結されます。リンク先が間違っていれば、そのコードが入った印刷ラベルはすべて間違いで、顧客が死んだリンクをスキャンしたときに初めて判明します。検証は、このワークフローの中で最も安い保険です。
各行について3点を確認します。
- URLは到達できるか？ リンクのサンプルを手動で開きます。数百件あるなら全部は確認せず、パターンごとに確認します。1〜100行目がすべて
example.com/product/IDを指しているなら、5件テストすればパターンはカバーできます。ユニークなリンク先のタイプは、すべてテストしてください。 - 最終的なURLか？ 「後でリダイレクトを設定するつもり」の中継URLではなく、ユーザーに着地してほしいページを直接指定します。リダイレクトの連鎖はスキャンを遅くし、サイト再構築のたびに壊れます。
- HTTPSか？ 一部のスマートフォンや企業ネットワークは、非セキュアなリンク先を警告表示します。すべて
https://にしましょう。
メニューページ、キャンペーンのランディングページ、イベントのスケジュールなど、リンク先が時間とともに変わる予定があるなら、自分で管理する安定したURL（自ドメインの短縮リンクなど）をコードに埋め込み、そこから現在のリンク先へリダイレクトする方式を検討してください。こうすれば、リンク先が変わってもQRコードの再印刷は不要になります。ただし管理対象が1つ増えるので、リダイレクトを実際に保守し続けられる場合だけ採用してください。
命名規則を決め、それを貫く
命名の一貫性は地味に聞こえます。しかし、qr_final(3).png というファイルが400個並んで、どれがどれだか分からない状態になってからは遅いのです。生成の前にファイル名の形式を決め、スプレッドシートから自動的に導出されるようにします。手作業ではありません。
実用的なパターンは「ID + 用途の短い説明 + 拡張子」。たとえば TBL-014-table.svg、AST-0032-laptop.svg のようになります。バッチで生成するならバッチ接頭辞を追加します：B2-TBL-014.svg。
同じ規律は、コードの中に埋め込むデータにも適用されます。TBL-014 のようなIDをエンコードするなら、接頭辞の意味をどこかに文書化しておきましょう。スプレッドシートの横に短いREADMEを置き、接頭辞の意味を説明しておくだけで十分です。半年後に破損ラベルを再印刷するのは、あなた自身です。そして覚えていません。
デザインテンプレートを1つ決めて、固定する
一括生成するQRコードは、見た目が「家族」であるべきです。スタイルがバラバラだと見た目が雑に映るだけでなく、スキャナー側の慣れも損ないます。次の項目をカバーするテンプレートを1つ選びましょう。
- 誤り訂正レベル。 印刷ラベルは擦れたり汚れたり、一部が隠れたりします。高い誤り訂正レベル（レベルQまたはH）なら、破損しても読み取れる可能性が高まります。ただしレベルが高いほどコードは密度が上がるので、印刷サイズとのバランスを取ってください。
- 色。 必ず「濃い色のモジュールを淡い背景に」。コントラストは高く。反転（淡いモジュールを濃い背景に）したコードは、多くのスキャナーで読み取れません。
- クワイエットゾーン。 コードの周囲の余白です。必ず確保します。4モジュール分の余白が慣例的な最小値です。コードの縁までぎっしり詰めたラベルは、読み取りが悪くなります。
- ロゴの配置（入れる場合のみ）。中央のロゴは誤り訂正が高い場合にのみ安全で、それでも破損への耐性は下がります。資産ラベルやチケットには入れない方が無難です。
テンプレートを一度固定したら、バッチ全体に適用し、個別のコードを調整することはしません。テンプレートに収まらないコードがあれば、直すのはデザインではなく、ラベルのサイズです。
ベクターで書き出し、実環境のサイズに合わせる
プリンターに回すもの、さまざまなサイズで再現するものは、SVGで書き出します（印刷所が指定するならEPS/PDF）。ベクターファイルは画質を落とさずに拡大縮小できます。解像度の合っていないラスター形式のPNGは、にじむか、最悪の場合、印刷が甘くてスキャンに失敗します。
実用的なサイズの目安です。厳密な法則ではありません。
- テーブルテントやバッジで、50cm未満の距離からスキャンする場合：2〜3cm角でたいてい十分です。
- 壁やポスターで、2mの距離からスキャンする場合：辺の長さはスキャン距離の約10分の1が目安。つまり20cm程度です。
- 迷ったら大きく。本番サイズで1枚テスト印刷し、本番投入前に2〜3台の異なるスマートフォンでスキャンして確認します。
QRCodeMax.Vipの一括生成ツールは、リンク先のリストをスプレッドシートから受け取り、全コードを一括で出力します。このワークフローのまさに中盤に必要な機能です。検証済みのCSVを渡し、テンプレートを適用し、ベクターで書き出してください。
サンプルをテストし、重複を確認する
300個のコードをテストせずに印刷へ回してはいけません。サンプルを抽出します。リンク先のパターンごとに1つずつ、加えてランダムに数件。実機でテストします。
- 最低2台の異なるスマートフォンでスキャンする（可能ならiOSとAndroidの両方）。
- 画面上だけでなく、実際の印刷媒体でスキャンする。まず物理的な校正シートを1枚印刷します。
- ユーザーが実際に使う距離と角度でスキャンする。
- リンクを辿り、着地ページがモバイルで正しく表示されるか確認する。
重複チェックは、省略して後悔する人が多い工程です。異なるラベルに同じコードが2つあれば、どちらかが間違いです。テーブル4のテーブルテントがテーブル9の注文ページを開く、バッジが他人のアクセス権を渡す、といった事故になります。スプレッドシートをリンク先列で並べ替え、重複が意図的なものか確認してください。生成ツールに重複警告機能があれば有効にします。なければ、並べ替えと、重複したリンク先を数える表計算の数式で、ほとんどのケースを捕捉できます。
バッチで印刷し、台帳を残す
初回から300個全部を印刷しないでください。まず1バッチ（20〜50枚）印刷して検査します。位置ずれ、コントラスト、読み取り性、用紙の挙動（光沢紙はスキャナーの光を反射しやすく、マットの方がたいてい安定して読み取れます）。問題は50枚の無駄で発見する方が、500枚の無駄よりはるかに安い。
そして台帳を残します。これは華やかさのない工程ですが、プロと混乱の境界線です。台帳は、同じスプレッドシートに列を追加するだけで構いません。
- バッチ番号と印刷日。
- 印刷枚数。
- 複数使うなら、プリンター／用紙の種類。
- ステータス：
印刷済み、設置済み、破損・再印刷。
台帳は、必ず後から来る質問に答えてくれます。「どのテーブルにシールが貼られていない？」「どのバッチが旧URLを使った？」「AST-0032のラベルを以前とまったく同じように再印刷できる？」サイト全体でリンク先を変更する場合も、台帳があれば影響を受けるコードを正確に特定できます。
最終版のスプレッドシート、テンプレート設定、書き出したファイルは、1つのフォルダにまとめて保管します。再現できないバッチは、遅かれ早かれ手作業で作り直すことになります。
よくある失敗
実際の再印刷談義に必ず登場するものなので、あえて名指しします。
- 検証前に生成する。 コードが存在した後でリンク先が変わる。全部再印刷。
- 移動する予定のページをエンコードする。 キャンペーンURL、日付入りのイベントページ、季節限定のもの。安定したURLか、自前のリダイレクトを使う。
- IDの不統一。 同じバッチに
table14、TBL-14、t-014が混在すると、ラベルと記録の照合がほぼ不可能になります。 - 低コントラスト、反転色。 白地に淡いグレー、黒地に白、パステル調のブランドカラー。スキャナーにはコントラストが必要です。
- 距離に対して小さすぎる。 ポスター上の1cmのコードは、飾りであってQRコードではありません。
- 物理テストの省略。 画面上で読めるコードでも、湾曲した面、光沢面、テクスチャ付きの面では失敗することがあります。
- 台帳なし。 半年後、何を印刷し、どこに設置し、どこを指していたのか、誰も分からない。
- 印刷用にラスター書き出し。 低解像度のPNGは、紙の上で不安定にしか読み取れないコードになります。
- 個別にコードを編集する。 デザイン変更が必要なら、テンプレートを変えてスプレッドシートからバッチ全体を再生成します。個別ファイルを手で直すことは決してしません。
最終チェックリスト
印刷に投入する前に、これを一通り確認してください。
- スプレッドシート完成：1行1コード、一意のID、リンク先、ラベル、ステータス列。
- すべてのユニークなリンク先パターンをテスト済み。サンプル行を実機で開いた。
- URLは最終版、HTTPS、リダイレクト連鎖なし。
- 命名規則を文書化済み。ファイル名はIDから自動導出。
- デザインテンプレート1つ：高コントラスト、濃色を淡色地に、十分なクワイエットゾーン、環境に合った誤り訂正レベル。
- SVGまたは同等のベクター形式で書き出し済み。
- 重複するリンク先を確認済み。意図的なものは記録済み。
- 物理校正を印刷し、実際の距離で複数のスマートフォンからスキャン済み。
- 全量印刷の前に、最初のバッチを印刷して検査済み。
- 台帳更新済み：バッチ、日付、枚数、コードごとのステータス。
まとめ
QRコードの大量作成は、デザインプロジェクトではなく、データプロジェクトです。整理されたスプレッドシートを作り、すべてのリンク先パターンを検証し、テンプレートを1つ固定し、ベクターで書き出し、物理サンプルをテストし、印刷記録を残す。この6つを守れば、300個のバッチは1日午後の作業で終わります。省略すれば、再印刷サイクルになります。要点はこうです。QRジェネレーターは簡単な部分。台帳と検証こそが、数百個のコードを一度で成功させるものです。