動的QRコードは必ずしもすべてのスキャナーを同じURLに送る必要がありません。条件付きルーティング（スキャンルーティングまたはルールベースリダイレクトとも呼ばれます）を使えば、1つの印刷されたコードから異なるオーディエンスを異なる宛先に誘導できます。昼間のチラシは営業時間のランチメニュー、夕方の来客は予約フォーム、海外の訪問者はローカライズされたページに自動的に誘導できる機能です。
最も実用的なルーティングシナリオ、セットアップの手順、よくある失敗パターンを解説します。
動的QRコンテキストにおける「ルーティング」の意味
スキャナーが動的QRコードを読み込むとき、そのコードの宛先URLはサーバーに保存されています。コード自体には埋め込まれていません。このサーバー側のリダイレクトがルーティングロジックの置き場所です。単純なリダイレクト（「すべてのスキャン→URL A」）ではなく、条件付きルールを追加します：
- 条件が満たされた場合→URL A に送信
- 条件が満たされなかった場合→URL B（フォールバック）に送信
これをサポートするプラットフォーム（「マルチURL QRコード」または「スマートリダイレクトQRコード」と呼ばれることもあります）は、通常2～3つのルールを層状に設定できます。フォールバックURLは常に必須です。静的QRコードと動的QRコードの完全な比較では、リダイレクトがサーバーに存在する理由とルーティングにおける重要性を詳しく説明しています。
シナリオ1：時間帯ルーティング
ユースケース： カフェが1つのQRコードをテーブルテントに印刷します。朝のスキャナーは朝食メニュー、午後のスキャナーはランチメニュー、夜のスキャナーはドリンクリストを見ることができます。
セットアップ手順：
- 各メニュー時間帯用に3つの宛先URL（またはページセクション）を作成します。
- UTCでタイム・ルールを追加し、現地のタイムゾーンオフセットを考慮します。
- スキャナーが定義された時間外に読み込まれた場合に備えて、最も一般的なケースをフォールバックに設定します。
よくある失敗： チームがスキャン時刻がサーバーではUTCで記録されることを忘れがちです。タイムゾーン設定なしで「11:00～14:00」というルールを設定すると、あなたの都市では間違った時間に発動します。必ずプラットフォームのタイムゾーン処理を確認してから印刷してください。
その他の実用的な例：
- イベント会場：午後7時までは開演前プログラム、午後9時以降はマーチャンダイズへルーティング
- 小売店：プロモーション期間中のみフラッシュセール・ランディングページを表示
- ジム：平日はクラススケジュール、土日は週末の時間割を送信
シナリオ2：国別・言語別ルーティング
ユースケース： 製品が12カ国に出荷されます。1つのQRコードが英語圏をイギリス国旗のサポートページに、フランス語圏をフランス語版に、その他すべてを言語セレクターに誘導します。
セットアップ手順：
- ルーティングエンジンがIPジオロケーションを使ってスキャナーの国を特定します。
- 国コードをマップします（US、GB、CA→英語ページ；FR、BE、CH→フランス語ページ；DE→ドイツ語ページ）。
- 言語セレクターページをグローバルフォールバックに設定します。
社内ドキュメント化すべき注意点：
- IPジオロケーションは国レベルでは95～99％の精度ですが、VPNユーザーは誤ルーティングされます。ほとんどのユースケースではこれは許容範囲です。
- ブラウザから検出した言語設定でルーティングしないでください。QRスキャンリクエストは、すべてのアプリを通じてAccept-Languageヘッダーを信頼できる形で渡しません。
- プラットフォームが宛先URLごと、またはルールごとに課金する場合は、40個の国別リストではなく、国グループにまとめてマップします。
シナリオ3：デバイスタイプ別ルーティング
ユースケース： ソフトウェア企業の印刷広告が業界誌と開発者向けニュースレターの両方に掲載されます。iOSユーザーはApp Storeへ、AndroidユーザーはGoogle Playへ、デスクトップスキャナー（ノートパソコンのカメラで広告を撮影）はWebアプリへルーティングされます。
セットアップ手順：
- プラットフォームはスキャンリクエストのUser-Agentストリングを読み込みます。
iOS→ App Store URL；Android→ Play Store URL；その他/デスクトップ→ Webアプリへルーティング。
なぜこれが重要か： App Storeのリダイレクトページはプラットフォームの自動検出が悪名高いです。AndroidユーザーをApp Storeリンクに送信するとエラーが発生し、コンバージョンが失われます。デバイスルーティングはWebサイトにカスタムスマートバナー実装を必要とせず、これをきれいに解決します。
シナリオ4：ルール結合（マルチ条件ルーティング）
一部のプラットフォームではルールをスタックできます。例えば、国とデバイスの組み合わせです。よくある実装例：
| 優先度 | 条件 | 宛先 |
|---|---|---|
| 1 | 国 = US + デバイス = iOS | US App Store |
| 2 | 国 = US + デバイス = Android | US Play Store |
| 3 | 国 = DE | ドイツ語ランディングページ |
| 4 | フォールバック | グローバル・ランディングページ |
ルールは上から順に評価されるため、順序が重要です。最も具体的な条件を最初に、その次に広い地理的ルール、最後にフォールバックを置きます。これは簡単にシーケンスミスできます。印刷に進む前に、必ず実際のデバイスで、可能であれば該当国のVPNを使用して各条件をテストしてください。
ルート別に追跡できる内容
ルーティングは話の半分です。各宛先URLには、分析プラットフォームでオーディエンスセグメント別のパフォーマンスを分離できるようにUTMパラメータを付与する必要があります。フランス語ページにルーティングされたスキャンは、?utm_source=qr&utm_medium=print&utm_content=fr を発動させて、一般的なスキャンと区別できるようにします。
QRダッシュボードからどのメトリクスを抽出すべきかについては、QRコード分析：意思決定に直結する6つの指標でスキャンからコンバージョンまでの追跡を詳しく説明しています。
ルーティングログを使用して予期しないトラフィックパターンを特定することもできます。「UK限定の印刷実施で40％のスキャンが『非UK フォールバック』をトリガーしている」場合は、支出を拡大する前にジオロケーション設定をチェックする必要があります。
ルーティングを導入する前のプラットフォーム・チェックリスト
すべての動的QRプラットフォームが条件付きルーティングをサポートしているわけではありません。選択する前に、以下を確認してください：
- タイムゾーン選択付きの時間帯ルール（UTCのみではなく）
- 国/地域レベルのジオロケーションルーティング
- デバイスタイプ検出（iOS / Android / その他の最小限）
- ルール・スタックまたはマルチ条件サポート
- ルール別スキャン分析、単なる集計総計ではなく
- フォールバックURLは常に必須かつ編集可能
現在のツールがこれらに対応していない場合は、Super QR Code Generatorが時間・国・デバイスにわたる条件付きルーティングをルール別分析付きでサポートしています。
まとめ
- ルーティングは1つの印刷されたQRコードから異なるスキャナーを異なるURLに送信します。サーバー側のリダイレクトロジックを使用します。
- 時間帯ルーティングには正しいタイムゾーン設定が必要です。UTCのデフォルト設定はほとんどの市場で誤動作します。
- 国別ルーティングはIPジオロケーションを使用し、国レベルでは信頼できますが、VPNユーザーでは失敗します。
- デバイスルーティングはiOSとAndroidの宛先を分離する必要があるアプリダウンロードキャンペーンの最良の解決策です。
- 各ルーティングされたURLにUTMパラメータを追加して、下流の分析がセグメント化されたままになるようにします。
- 大規模印刷に進む前に、実際のデバイス（理想的にはVPN付き）ですべてのルーティングルールをテストしてください。