QRコードのセキュリティ落とし穴:動的QRのリスクと短縮URLの罠

2026-04-13公開 7分で読了

要約 (TL;DR)

少し前、あるカフェでメニューのQRをスキャンしたら、見慣れない ql.st の短縮サービスに飛ばされた。よく見ると、元のQRの上に新しいシールが貼られていた。店主は数週間その事実に気づいていなかったという。QRを「攻撃」する高度な脆弱性は珍しい。実際の事件はたいてい、こうしたシール1枚から始まる。

QRコードは「ただの画像」ではなく、URLやテキストを視覚的にエンコードしたフォーマットだ。だからQRそのものにセキュリティ機能はなく、スキャンした人が辿り着く到達先URLの安全性と、QRを作った方法がセキュリティのほぼ全てを決める。静的QRはURLがコード内にそのまま刻まれており、発行後は内容を変えられない。動的QRは内容変更が可能だが、リダイレクタサーバーに依存するため、サービスが終了したり所有者が変わったりすると、スキャン結果がまったく別ページになり得る。短縮URLも同じで、失効・乗っ取り・トラッキングの問題があり、公共印刷物・長期保管物・オフライン資料には不向きな場合がある。一番安全な既定は自社ドメインの静的URLを静的QRにすることで、キャンペーン上トラッキングが必要なら信頼できる提供者の動的QRを使い、終了後のリダイレクト計画も一緒に立てておく。

背景・コンセプト

QRコードの正式仕様はISO/IEC 18004で、1から40までのバージョンがあり、バージョンが上がるほどモジュール(格子)数が増え、より多くのデータを入れられる。一方で全てのQRは一定量の誤り訂正(Reed-Solomon)データを持つ。レベルは4つ。

  • L:データ破損およそ7%まで復元
  • M:約15%まで復元
  • Q:約25%まで復元
  • H:約30%まで復元

訂正レベルを上げると、印刷物が汚れたりロゴで覆われたりしてもスキャンできるが、モジュール密度が上がるので小さく印刷すると逆に読みにくくなる。名刺やポスターはMが既定で、ロゴを中央に載せるならQ・Hを検討する、という設計になる。

静的QRはURLがそのままモジュールに入るのでスキャン結果が永続的だ。動的QRは「短いリダイレクトURL」を入れ、サービス提供者が到達先を差し替えられる構造だ。便利だが、その柔軟性こそが長期リスクの源になる。

比較・データ

観点静的QR動的QR
エンコードされるURL最終到達先URLそのままリダイレクタの短縮URL
スキャン計測原則として不可標準機能として提供
失効リスクドメインを維持する限りなし提供者の契約・料金・廃業に依存
第三者依存なしリダイレクタ提供者
フィッシングの露出面到達先URLのみ点検すればよいリダイレクタがハック・譲渡されると到達先が変わりうる
変更可否不可(再発行必要)可(柔軟)

「短縮URLにするときれい」は便利さであると同時に弱点にもなる。人が目視でURLを検証できなくなるからだ。

実践シナリオ

シナリオ1 — 名刺・ポスターのようなオフライン印刷物。 2019年の名刺を最近出してきたら、記載されていた bit.ly の短縮リンクがすでに404を返していた。当時のトラッキング契約が切れたようだ。静的QRに自社ドメインの正規URLをそのままエンコードするのが一番長持ちする。サイズが小さいほど、訂正レベルを低めてモジュール数を減らすことでスキャン認識率が上がる。

シナリオ2 — マーケティングキャンペーンの効果測定。 あるスタートアップが展示会のブースで動的QRを使い、3ヶ月後にサービスが無料機能を有料化したため「プラン失効」ページにリダイレクトされたケースを見た。可能なら yourdomain.com/go/summer-2026 のような自社ドメインの短縮パス + UTMの組み合わせを選びたい。ドメインを自分で握っている限り期限がないからだ。

シナリオ3 — 文書の完全性・認証。 QRにURLではなく文書ハッシュや署名付きURLパラメータ(?d=abc123&sig=...)を入れ、スキャン後に原本との一致を確認する方式。ある認証プロジェクトでSHA-256の先頭16文字とHMAC署名を入れたら、QRバージョンが10以上に上がり、印刷サイズとの再調整が必要になった。契約書・認証書・製品ラベルのような資料に適用すると改ざん検出に役立つ。

よくある誤解

「QR自体をハッキングできる」。 QRは単なるデータエンコード規格なので、「QRを破る」攻撃は稀だ。実際のリスクはQRに入っているURLがフィッシング・マルウェアの経路であったり、既存QRの上にシールを貼って到達先を変える物理的改ざんであったりする。公共の場のQRはシールの有無を目視で確認するのが基本だ。

「短縮URLを使う方が見た目が綺麗で良い」。 見た目はそうだが、ユーザーがURLを検証できず、短縮サービスが停止・売却・ハッキングされれば全印刷物の結果が変わる。長期保管物ほど自社ドメインの長いURLが安全だ。

「訂正はHが常に最強」。 Hはロゴ挿入に有利だがモジュール数が増えるので、小さな印刷サイズでは逆に認識率が下がる。名刺のような小面積にはMが一般的な既定値だ。

「QRを見れば飛び先がわかる」。 iOS 17・18の標準カメラはURLバナーを出すが、一部のAndroid OEMカメラやサードパーティスキャナはタップ1つでブラウザをそのまま開く。公共Wi-Fiログイン用QRを装ったフィッシングはこの自動起動を狙う。自動実行をオフにし、スキャン後にドメインを先に確認する習慣が安全だ。

チェックリスト

  1. 寿命はどれくらいか?
    • 数年以上 → 静的QR + 自社ドメインURL推奨。
    • 短期キャンペーン → 動的QRまたはUTMパラメータ。
  2. トラッキングは本当に必要か?
    • いいえ → 静的QRで十分。
    • はい → 信頼できる提供者の動的QR。代替リダイレクト計画も。
  3. 出力サイズは?
    • 非常に小さい → データ量を減らし訂正はM程度に。
    • 中〜大 → ロゴを入れたいならQ・H。
  4. 公共の場に貼られるか?
    • はい → 定期的に上貼りシールの有無を点検。
  5. スキャン先URLは安全か?
    • HTTPS・自社ドメイン・現在有効か確認。
  6. 作成は?
    • 可能ならオフライン・ブラウザ内で生成し、URLを外部サーバーのログに残さない。

関連ツール

Patrache Studioの QRコード生成ツール はブラウザ内でQRを作るため、入力URLが外部サーバーへ送られない。QRを載せた画像をWeb公開するなら 画像圧縮の完全ガイド でフォーマット選びの基準を揃え、QRを文書に差し込んで渡すなら ブラウザ内PDF結合・分割のセキュリティ上の利点 のフローで束ねると、プライバシー境界を一貫させやすい。

参考文献

関連ツール

tools.patrache.studio/qr/generator/