はじめに こんにちは、新規事業部フロントエンドブロックの 大野純平 です。2025年度に新卒入社し、現在のチームに配属されました。チームでFlutter製モバイルアプリを開発する中で、新規プロジェクトの立ち上げを効率化するための社内テンプレートリポジトリの整備を進めています。 このテンプレートを育てる中で、 Flutter 3.44 へのアップデートに伴うCocoaPodsからSPMへの移行対応が積み残しになっていました。あわせて、このタイミングでdev / stg / prdの3環境対応も新規に追加しました（3 flavor化自体はSPM移行の必須要件ではなく、テンプレート整備の一環で同時に着手したものです）。本記事では、 CocoaPodsからSPMへの移行 と、 3 flavorを mise run setup で一括整備する仕組み を紹介します。あわせて、Flutterにおけるビルド構成ファイルを解説します。 目次 はじめに 目次 Flutterプロジェクトのビルド構成 iOS側のしくみ Android側のしくみ Dart側のしくみ 3層を貫く全体像 背景・課題 3環境の設定整合が壊れやすい 解決策の全体像 実装内容と具体的な解決策 1. CocoaPodsを撤去してSPMに移行する CocoaPodsの統合を解除する Crashlytics dSYMのパスを更新する 2. iOS：xcconfigでBuild Configurationを9パターンに整える Firebase plistをBuild Phaseで差し替える 3. Android：productFlavorsとgoogle-services.jsonをflavorごとに配置する 4. Dart：firebase_optionsをセレクタshim化する main.dartでduplicate-appを処理する 5. mise run setupで全flavorを一括生成する まとめ Flutterプロジェクトのビルド構成 Flutterアプリは iOSネイティブ層・Androidネイティブ層・Dart層 の3つが組み合わさっています。環境（flavor）の切り替えとは「3層すべてに、同じflavor用の設定を選ばせること」です。 iOS側のしくみ Xcodeは以下の単位を組み合わせてビルドを定義します。 単位 役割 Flutter デフォルト Project ( .xcodeproj ) プロジェクト全体の定義。実体は project.pbxproj Runner.xcodeproj Target ビルド成果物の単位 Runner Build Configuration ビルド設定値の集合 Debug / Profile / Release の 3 種 Scheme Run / Test / Profile / Analyze / Archive の各アクションで使う Target と Configuration を定義する起動設定 Runner 1 つ xcconfig はBuild Configurationの値をテキストで宣言するファイルです。別のxcconfigを #include で取り込んだとき、同じ変数があれば 後から読み込んだ値が優先 されます。共通値を書いたxcconfigを先に、flavor固有値を書いたxcconfigを後に重ねれば、最終的な値が組み上がります。 Info.plist の CFBundleIdentifier は $(PRODUCT_BUNDLE_IDENTIFIER) を参照しています。そのため、xcconfig側で PRODUCT_BUNDLE_IDENTIFIER を決めればBundle IDが自動的に解決されます。 iOS・macOSで外部ライブラリを使うときの依存管理ツールには、 CocoaPods と Swift Package Manager（SPM） の2つがあります。Flutterプロジェクトでは長らくCocoaPodsが標準でしたが、Flutter 3.44からiOS・macOSの両方でSPMがデフォルトに切り替わりました。両者の違いは以下のとおりです。 CocoaPods Swift Package Manager (SPM) 提供元 OSS（Ruby 製） Apple 公式 設定ファイル Podfile Package.swift （Xcode では Package Dependencies UI から編集） 成果物 Pods/ + .xcworkspace を別管理 Xcode が直接管理 ロックファイル Podfile.lock Package.resolved Flutter での状況 長年の標準 3.44 でデフォルト有効化 Android側のしくみ AndroidのビルドはGradleが android/app/build.gradle.kts を読んで実行します。 概念 役割 buildTypes ビルド種別（ debug / release ） productFlavors 同じアプリのバリアント定義。 applicationId やリソースを分岐できる applicationId / applicationIdSuffix アプリの一意な識別子。iOS の Bundle ID 相当 resValue ビルド時に文字列リソースを生成する Gradle の機能 AndroidManifest.xml アプリのメタデータ宣言。 android:label でアプリ名を指定 Gradleは、flavor別のリソース（ AndroidManifest.xml や res/ 配下など）を source set という仕組みでディレクトリ単位に分けます。Gradleがflavorを選んだときに src/main/ と自動マージします。なお google-services.json は厳密にはsource set mergeの対象ではありません。google-servicesプラグインが src/<flavor>/google-services.json などのパスを優先度順に探索し、1ファイルを選びます。 Dart側のしくみ Dartでflavorを識別するにはコンパイル時定数を使います。 API / オプション 役割 --dart-define-from-file=path/to/x.json .json または .env （ KEY=VALUE 形式）で書いた値をまとめて Dart に渡す flutter コマンドのオプション String.fromEnvironment('KEY') 渡された値をコンパイル時定数として参照する API。 switch の case 値にもできる firebase_options.dart flutterfire configure が生成する Firebase 設定ファイル。通常は 1 ファイル = 1 Firebase プロジェクト 3層を貫く全体像 3層を1枚にまとめると、 app_config.yaml → mise run setup → 各層のファイル群 → flutter run --flavor X という流れです。以降、iOS・Android・Dartの順に、各層内で mise run setup と flutter run --flavor X がどのファイルへつながるかを示します。 iOS層では、xcconfigチェーンが Info.plist を解決します。 project.pbxproj のRun Scriptがflavor別の GoogleService-Info.plist をコピーします。 Android層では、 build.gradle.kts がflavorディレクトリの google-services.json と AndroidManifest.xml を結びつけます。 Dart層では、 flavor/{dev,stg,prd}.json の FLAVOR が起点になります。 firebase_options.dart が FLAVOR に応じて firebase_options_{dev,stg,prd}.dart を切り替えて返すコード（ セレクタ shim ）になります。 flutter run --flavor dev --dart-define-from-file=flavor/dev.json を1回実行したときに、各層で何が起きるかを並べると以下のようになります。 iOS ：Scheme dev → Debug-dev.xcconfig で PRODUCT_BUNDLE_IDENTIFIER が .dev 付きに解決される。Build PhaseのRun Scriptが ios/firebase/dev/ のplistをコピーする。 Android ：productFlavor dev が選ばれて applicationIdSuffix=".dev" が適用される。 src/dev/google-services.json がsource setにマージされる。 Dart ： flavor/dev.json の FLAVOR=dev がコンパイル時定数になる。 firebase_options.dart のセレクタshimが firebase_options_dev.dart を返す。 ここまでがFlutterプロジェクトのビルド構成の概要です。これを踏まえて、本記事で取り組んだ課題と解決策を見ていきます。 背景・課題 3環境の設定整合が壊れやすい dev / stg / prdの3環境を切り替えるには、iOS・Android・Dartの3層を整合させる必要があります。各層の対象は次のとおりです。 iOS：Bundle ID、 GoogleService-Info.plist Android： applicationId 、 google-services.json Dart：Firebase初期化オプション 3層が独立しているため設定漏れによるビルド失敗やFirebase接続不可が繰り返し発生し、原因特定にも時間がかかっていました。 解決策の全体像 以下の5つの取り組みで課題を解決しました。 # 層 取り組み 1 iOS / 基盤 CocoaPods 撤去 → SPM 移行 2 iOS / flavor xcconfig × 9 Build Configuration + flavor 別 Firebase plist 3 Android / flavor productFlavors + flavor 別 google-services.json 4 Dart firebase_options.dart のセレクタ shim 化 5 setup app_config.yaml の per-flavor 化と mise 自動化 1つのflavorを選んで flutter run すると、iOS・Android・Dartの3層でそれぞれ対応する設定が適用されます。 実装内容と具体的な解決策 1. CocoaPodsを撤去してSPMに移行する CocoaPodsはRuby製のAppleプラットフォーム向けパッケージマネージャーで、Swift Package Manager（SPM）はApple公式の代替です。Flutter 3.44では新規プロジェクトでiOS・macOSともにSPMがデフォルトで有効化され、Firebaseをはじめとする主要プラグインもSPM対応を完了しています。 pod install が不要になるため、CIのセットアップも大幅に高速化されます。 CocoaPodsの統合を解除する 既存プロジェクトでは、 Podfile をいきなり削除するのではなく、まず pod deintegrate でXcodeプロジェクトからCocoaPodsの統合を解除します。 cd app/ios pod deintegrate # project.pbxproj から Pods 統合を除去 rm Podfile Podfile.lock # Podfile 本体を削除 rm だけで済ませてはいけません。 Podfile を削除しただけでは project.pbxproj にCocoaPods統合の痕跡が残ります。たとえば [CP] Check Pods Manifest.lock などのBuild Phaseや、 Pods-Runner xcconfigの #include 参照などです。 pod deintegrate はこれらを正しく除去します。 .gitignore も忘れず更新します。 # app/ios/.gitignore -.symlinks/ -Pods/ +# SPM +.build/ SPMが管理する Package.resolved はバージョンを固定するためリポジトリにコミットします。 Crashlytics dSYMのパスを更新する dSYM（Debug Symbols）はクラッシュレポートのスタックトレースを人間が読めるシンボルに復元するためのファイルです。Crashlyticsを使っている場合、そのdSYMをアップロードするBuild PhaseスクリプトをSPM構成のパスに合わせて更新します。このRun Scriptは setup 系スクリプトが自動生成するものではなく、Crashlyticsを利用する場合はプロジェクトごとに手動で追加する手順です。 Firebase公式のApple向けガイド は現在SPM構成を前提としており、Run Scriptに以下を追加するよう記載されています。 # Build Phases > Run Script " ${BUILD_DIR % /Build/* } /SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/run " CocoaPods時の ${PODS_ROOT}/FirebaseCrashlytics/run に相当します。Xcode 15以降は User Script Sandboxing がデフォルトで有効になっています。有効な場合はRun ScriptのInput Filesに以下を列挙する必要があります（ Firebase公式ドキュメント ）。 ${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME} ${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}/Contents/Resources/DWARF/${PRODUCT_NAME} ${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}/Contents/Info.plist $(TARGET_BUILD_DIR)/$(UNLOCALIZED_RESOURCES_FOLDER_PATH)/GoogleService-Info.plist $(TARGET_BUILD_DIR)/$(EXECUTABLE_PATH) # Debug Dylib（DEBUG_DYLIB）が有効な場合は追加で必要 ${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}/Contents/Resources/DWARF/${PRODUCT_NAME}.debug.dylib 2. iOS：xcconfigでBuild Configurationを9パターンに整える iOSのXcodeプロジェクトは「Build Configuration」というビルド設定の単位を持ちます。各Configurationにはxcconfigファイル（テキストでビルド設定を記述する仕組み）を1つ紐付けられます。本テンプレートは、以下の9通りのBuild Configurationを用意しています。 dev stg prd Debug Debug-dev Debug-stg Debug-prd Profile Profile-dev Profile-stg Profile-prd Release Release-dev Release-stg Release-prd これらはあらかじめ project.pbxproj にコミット済みです。あわせて、それらを参照する dev / stg / prd の3 Schemeもコミット済みです。各Schemeは、Run/Test/Analyzeで Debug-<flavor> を参照します。Profileでは Profile-<flavor> 、Archiveでは Release-<flavor> を参照します。3つのSchemeには、Flutter標準の Run Prepare Flutter Framework Script pre-actionも含めて完全な状態で用意されています。このpre-actionは xcode_backend.sh prepare を実行します。これによりSPM統合に必要な FlutterGeneratedPluginSwiftPackage が解決されます。 mise run setup はこのScheme⇔Configurationのマッピングやpre-actionには一切触れません。書き換えるのは、各Configurationに紐づくxcconfigの値（Bundle IDやアプリ名など）だけです。 Flutter/Shared.xcconfig ← 全 Configuration 共通の値 Flutter/flavor-dev.xcconfig ← dev 固有の値（BUNDLE_ID_SUFFIX など） Flutter/flavor-stg.xcconfig Flutter/flavor-prd.xcconfig Flutter/Debug-dev.xcconfig ← #include で連結（9ファイル） Flutter/Debug-stg.xcconfig ... Flutter/Release-prd.xcconfig 後ろの #include が前の値を上書きするため、共通値（ Shared ）→ flavor固有値（ flavor-dev ）の順に重ねることで最終的な値が決まります。 Debug-dev.xcconfig は3行の #include のみで構成されます。 #include "Debug.xcconfig" #include "Shared.xcconfig" #include "flavor-dev.xcconfig" これでビルド時に対応するxcconfigが PRODUCT_BUNDLE_IDENTIFIER を解決します。その値が Info.plist 経由でflavor付きBundle ID（例： jp.testapp.dev ）として適用されます。 Firebase plistをBuild Phaseで差し替える flavor別の GoogleService-Info.plist を使い分けるため、Build PhaseにRun Scriptを追加します。Run Script内の ${FLAVOR} は実行直前にxcconfigの値（ dev / stg / prd ）に置き換えられます。これによりコピー元ディレクトリがflavorごとに切り替わり、該当するplistだけが .app バンドルに入ります。 # Build Phases > Run Script SRC = " ${SRCROOT} /firebase/ ${FLAVOR} /GoogleService-Info.plist " DST = " ${BUILT_PRODUCTS_DIR} / ${PRODUCT_NAME} .app/GoogleService-Info.plist " if [ -f " $SRC " ]; then cp -f " $SRC " " $DST " else echo " warning: $SRC not found, Firebase native init will be skipped " fi plistが存在しないflavorでもビルドが失敗しないよう、存在チェックを入れています。 firebase_project_id を空にしてFirebase設定をスキップした場合がこれに該当します。このRun Scriptは読み書き対象のパスをInput Files / Output Filesとしてあらかじめ宣言しています。そのためUser Script Sandboxingが有効な環境でも安全に動作します。 plistは以下のスロットに配置します（ setup:firebase が生成）。 app/ios/firebase/ ├── dev/GoogleService-Info.plist ├── stg/GoogleService-Info.plist └── prd/GoogleService-Info.plist 3. Android：productFlavorsとgoogle-services.jsonをflavorごとに配置する Androidでは build.gradle.kts に productFlavors を追加し、flavorごとに applicationIdSuffix とアプリ名を設定します。 // app/android/app/build.gradle.kts flavorDimensions + = "env" productFlavors { create( "dev" ) { dimension = "env" applicationIdSuffix = ".dev" resValue( "string" , "app_name" , "Flutter Template App Dev" ) } create( "stg" ) { dimension = "env" applicationIdSuffix = ".stg" resValue( "string" , "app_name" , "Flutter Template App Stg" ) } create( "prd" ) { dimension = "env" resValue( "string" , "app_name" , "Flutter Template App" ) } } google-services.json はAndroid Gradleのflavorソースセット（ src/<flavor>/ ）に配置します。flavor用の設定ファイルはgoogle-servicesプラグインが自動で選択します。 android/app/src/ ├── dev/google-services.json # setup:firebase が生成 ├── stg/google-services.json └── prd/google-services.json 注意点が2つあります。1つ目は google-services.json の package_name です。suffix込みの最終applicationIdに合わせます（例： com.example.app.dev ）。suffixなしの com.example.app だけFirebaseに登録していると、dev / stgビルド時にプラグインが例外を投げてビルドが通りません。Firebase側のアプリ登録もsuffix込みのapplicationIdで行う必要があります。 AndroidManifest.xmlで android:label="@string/app_name" のように参照します。 productFlavors の resValue がflavorごとに生成した文字列が、そのままアプリ名として使われます。 <!-- app/android/app/src/main/AndroidManifest.xml --> <application android : label = "@string/app_name" ...> 2つ目は、 strings.xml との重複です。 resValue("string", "app_name", ...) はビルド時に文字列リソースを生成します。そのため、 res/values/strings.xml に同名の app_name が定義されていると Duplicate resources エラーになります。 app_name は strings.xml には置かず、各flavorの resValue に一本化してください。 4. Dart：firebase_optionsをセレクタshim化する flutterfire configure が生成する firebase_options.dart は単一の設定しか返しません。そこでファイル名とAPIを保ったまま、 セレクタ shim に置き換えます。 まず app/flavor/dev.json に FLAVOR キーを定義し、 --dart-define-from-file で読み込みます。 { " FLAVOR ": " dev " } FLAVOR はDartコード側で String.fromEnvironment('FLAVOR') を使って、コンパイル時定数として参照できます。 // app/lib/firebase_options.dart import 'package:firebase_core/firebase_core.dart' show FirebaseOptions; import 'firebase_options_dev.dart' as dev; import 'firebase_options_prd.dart' as prd; import 'firebase_options_stg.dart' as stg; const _flavor = String .fromEnvironment( 'FLAVOR' ); class DefaultFirebaseOptions { static FirebaseOptions get currentPlatform { switch (_flavor) { case 'dev' : return dev.DefaultFirebaseOptions.currentPlatform; case 'stg' : return stg.DefaultFirebaseOptions.currentPlatform; case 'prd' : return prd.DefaultFirebaseOptions.currentPlatform; default : throw StateError( 'Unknown FLAVOR: "$_flavor". ' 'Run with --dart-define-from-file=flavor/<flavor>.json' , ); } } } 呼び出し側（ main.dart ）は DefaultFirebaseOptions.currentPlatform をそのまま使うだけで、flavorの切り替えを意識する必要がありません。 setup:firebase はこのファイルを上書きせず、本物の firebase_options_<flavor>.dart だけを再生成します。 注意：flavor指定は必須 _flavor が空（ --dart-define-from-file 未指定）だとshimの default が StateError を投げます。 _initializeFirebase はこれをcatchしないため、flavorなしの flutter run は起動時に落ちます。VS Codeのlaunch.jsonや mise run タスクで各flavorを必ず渡す構成にしておくと安全です。 main.dartでduplicate-appを処理する Firebaseには2つの初期化経路があります。ネイティブの自動初期化と、Dart側の Firebase.initializeApp() です。両方が呼ばれると duplicate-app の FirebaseException が発生します。ただし duplicate-app はflavor不整合（ネイティブのplist/jsonが別のFirebaseプロジェクトを指している等）でも発生しうるため、無条件で成功扱いにはできません。ネイティブ初期化済みの options と比較し、一致した場合のみ成功扱いにします。不一致の場合は例外を再throwし、アプリを起動時にクラッシュさせます。例外を握りつぶしてしまうと、不正なAPIキーや設定不整合といった検知したいバグを見逃してしまう可能性があるためです。 // app/lib/main.dart（抜粋） Future< bool > _initializeFirebase() async { try { await Firebase.initializeApp( options: DefaultFirebaseOptions.currentPlatform, ); return true ; } on UnimplementedError { // placeholder（setup:firebase 未実行）の場合は Firebase を無効化して続行 return false ; } on FirebaseException catch (e) { if (e.code == 'duplicate-app' ) { final existing = Firebase.app().options; final expected = DefaultFirebaseOptions.currentPlatform; final matchesNativeConfig = existing.appId == expected.appId && existing.projectId == expected.projectId && existing.apiKey == expected.apiKey; if (matchesNativeConfig) return true ; } rethrow ; } } 5. mise run setupで全flavorを一括生成する mise は、タスク実行とツールのバージョン管理を兼ねるCLIツールです。本テンプレートではセットアップスクリプトの実行に利用しています。手作業の設定漏れを防ぐため、セットアップの入力ファイル app_config.yaml にFirebaseのproject_idをflavorごとに設定できる構造を追加しました。これにより、 mise run setup:firebase で全flavorの設定ファイルを一括生成できます。 flavor : dev : app_name_suffix : " Dev" bundle_id_suffix : ".dev" firebase_project_id : "my-project-dev" # 空文字なら Firebase 設定をスキップ stg : app_name_suffix : " Stg" bundle_id_suffix : ".stg" firebase_project_id : "my-project-stg" prd : app_name_suffix : "" bundle_id_suffix : "" firebase_project_id : "my-project-prd" mise run setup:firebase は app_config.yaml の各flavorの firebase_project_id を読み取ります。読み取った値で flutterfire configure をflavorごとに実行します。 iOSは --ios-out でパスを直接指定すると、plistは出力されるもののproject.pbxprojへの参照は Runner/ 配下を前提に追加されます。配置と参照のズレでビルドが落ちる事例もありました。そこで setup:firebase は flutterfire configure のデフォルト出力（ Runner/ ）を利用し、後処理で配置を整えます。 Build PhaseのRun Scriptがflavorに応じてplistを動的にコピーするので、 project.pbxproj の静的参照は不要です。 setup:firebase は実行のたびに追記される参照を毎回除去し、pbxprojが肥大化しないようにしています。 # クリーンアップ確認（0 であれば OK） grep -c " GoogleService-Info.plist .*PBXBuildFile " \ app/ios/Runner.xcodeproj/project.pbxproj mise run setup:flavor はxcconfigやflavor JSONを app_config.yaml から再生成します。Firebaseの設定ファイルは別途 setup:firebase で更新します。何度実行しても同じ出力になるため、設定変更後に再実行すればxcconfigとflavor JSONが同期されます。 この仕組みにより、新規プロジェクトでは app_config.yaml を編集して mise run setup を実行するだけで済みます。iOS xcconfig・Android productFlavors・Dartセレクタshim・Firebase設定ファイルのすべてが一括でできあがります。 まとめ 本記事では、FlutterプロジェクトにおけるCocoaPodsからSPMへの移行を紹介しました。あわせてdev / stg / prdの3 flavorをiOS・Android・Dartの3層で整合させる仕組みの構築も紹介しました。 CocoaPodsからSPMへの移行自体は pod deintegrate → Podfile削除で思ったよりシンプルです。手間がかかるのはflavorの3層整合で、それぞれが独立した設定体系を持つため一つひとつ繋ぎ込む必要があります。 app_config.yaml → mise run setup という自動化の仕組みを整えました。これにより手動作業による設定漏れのリスクを排除し、チームが本来の開発に集中できる環境を作れました。 ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com

チラシやポスター、商品パッケージ、店頭POPなど、印刷物からWebサイトへ誘導する手段として、QRコードは広く利用されています。 手軽に作成でき、スマートフォンで簡単に読み取れる。その便利さから、 QRコードそのものの品質や確認工程 については、十分に意識されないまま制作が進んでしまうことがあります。 しかし、QRコードは印刷後に不具合が見つかっても、 Webページのようにその場で修正することはできません 。 読み取れないQRコードが印刷されてしまえば、 チラシやパッケージ、販促物の刷り直し が必要になり、印刷費だけでなく、 納期の遅延、廃棄コスト、キャンペーン機会の損失、取引先からの信用低下 につながる可能性があります。 株式会社モンテカンポ では、こうした印刷後のトラブルを防ぐために、 QRコードの作成と実機検証を行うサービス を提供しています。 QRコードのトラブルは、なぜ印刷後に発覚するのか 印刷物の制作現場では、 複数の会社や担当者が関わることが一般的 です。 発注元は「制作会社が確認しているはず」と考え、制作担当者は「自分のスマートフォンで読めたから問題ない」と判断し、印刷会社は「支給されたデータをそのまま印刷する」という立場を取ることがあります。 その結果、QRコードの品質を 誰が最終的に保証するのかが曖昧なまま 、入稿まで進んでしまいます。 パソコンの画面上で問題なく見えていても、実際に印刷すると、サイズや解像度、印刷状態、掲載する素材などの影響によって、読み取りにくくなる場合があります。 一台のスマートフォンで読み取れたとしても、すべての利用者が同じ機種、同じOS、同じカメラを使用するわけではありません。 QRコードは、作成するだけではなく、 実際の利用環境を想定して確認することが重要 です。 無料のQRコード作成ツールに潜むリスク インターネット上には、URLを入力するだけでQRコードを作成できる無料ツールが数多くあります。 一時的な案内や、すぐに差し替えられるWeb上の画像であれば、こうしたツールが便利な場面もあります。 一方、数千部、数万部を印刷するチラシやパッケージに掲載するQRコードでは、「 画面上では読み取れた 」という確認だけで入稿するのは危険です。 QRコードには、コードの位置や向きを認識するための「位置検出パターン」があります。生成した画像を不適切な方法で拡大・縮小したり、デザインデータ上でサイズを変更したりすると、 読み取りに必要な比率が崩れ 、認識に時間がかかったり、読み取れなくなったりする可能性があります。 また、URLが長い場合は QRコードの情報密度が高くなり 、印刷サイズや印刷品質によっては読み取りにくくなることがあります。 問題は、無料ツールそのものだけではありません。 「 誰が、どのツールで、どのような条件で作成し、どの環境で確認したのか 」が管理されていないことが、大きなリスクになります。 一度の確認不足が、大きな損失につながる QRコードの不具合は、一見すると小さな制作ミスに思えるかもしれません。 しかし、キャンペーン用の印刷物がすべて使用できなくなれば、損害は印刷費だけにとどまりません。 たとえば、次のような影響が考えられます。 印刷物の全数廃棄 再印刷費用の発生 納品・配布スケジュールの遅延 キャンペーン開始日の変更 店舗や関係各社への再手配 クライアントからの信用低下 問い合わせやクレーム対応の増加 添付資料では、無料ツールで作成したQRコードを十分に確認せず入稿した結果、印刷後にアクセスできないことが判明し、 1,000万円を超える損害 につながった事例も紹介されています。 大規模な案件ほど、QRコード一つの不具合が、 事業上の大きな事故に発展する可能性 があります。 入稿前に確認したい5つのポイント QRコードを印刷物に掲載する際は、少なくとも次の項目を確認する必要があります。 1．十分な掲載サイズが確保されているか QRコードが小さすぎると、スマートフォンのカメラが認識しにくくなります。 資料では、コード領域として20mm以上を確保することが推奨されており、10mm以下は特に注意が必要とされています。 掲載スペースだけで判断せず、実際に読み取れるサイズであるかを確認することが重要です。 2．埋め込むURLが長すぎないか QRコードは、埋め込む情報量が多くなるほど模様が細かくなります。 長いURLをそのまま使用するとコードの密度が高くなり、小さな印刷物や印刷条件によっては読み取り性能に影響する可能性があります。 3．実際の印刷物で確認したか 制作画面やPDF上で読み取れることと、印刷後に読み取れることは同じではありません。 可能であれば、校正刷りや実際に近い印刷条件で出力し、読み取り確認を行う必要があります。 4．複数の端末で確認したか 一台のスマートフォンだけで確認を終えるのではなく、iPhoneとAndroid、異なる機種やOS、標準カメラなど、複数の環境で検証することが望まれます。 5．作成元と確認責任者が明確か 担当者が個人的に見つけた無料ツールで作成し、誰も生成条件を把握していない状態は避けるべきです。 どのツールを使い、誰が作成し、誰が検証したのかを記録できるフローを整えることで、確認漏れを防ぎやすくなります。 QRコードの事故を防ぐには、個人の注意力に頼らない 繁忙期や納期直前には、どれほど経験のある担当者でも確認漏れを起こす可能性があります。 そのため、組織として次のようなルールを設けることが有効です。 印刷物に使用するQRコードは、担当者個人が無料ツールで作成しない 指定された方法で生成し、実機検証を終えてから入稿する QRコードの作成者と確認者を分ける 校正時のチェック項目にQRコードの読み取り確認を入れる 確認工程をルール化すれば、担当者の経験や忙しさに左右されにくくなり、トラブルを構造的に防ぐことができます。 株式会社モンテカンポの「QRコード作成＆検証サービス」 株式会社モンテカンポは、 ソフトウェアテストと第三者検証を専門とする会社 です。 QRコード作成＆検証サービスでは、正規ツールを使用してQRコードを生成し、実際のスマートフォン端末で読み取り確認を行います。 社内で専門的な確認環境を用意することが難しい場合 や、 大量印刷を伴う重要な案件 、 失敗できないキャンペーン などで、外部の検証サービスを活用できます。 サービス内容 QRコードの作成 正規ツールを使用した生成 スマートフォン実機での読み取り確認 案件規模や予算に応じた検証範囲の調整 キャンペーンサイトを含む外部検証の相談 料金は、 QRコード1個につき20,000円（税別） からです。 大がかりな検証だけでなく、範囲を絞った簡易的な対応についても相談できます。 QRコードを印刷する前に、専門家による確認を チラシ、ポスター、パッケージ、POPなどに掲載するQRコードについて、次のような不安はありませんか。 無料ツールで作成したQRコードを使用している 誰が作成したデータなのか分からない 一台のスマートフォンでしか確認していない 校正刷りで読み取り確認をしていない 大量印刷を予定しており、失敗が許されない クライアントに提出できる確認体制を整えたい 一つでも当てはまる場合は、入稿前に作成方法と検証工程を確認することをおすすめします。 株式会社モンテカンポでは、QRコードの作成・検証に加え、キャンペーンサイトの外部検証についても相談を受け付けています 。 印刷後に後悔する前に、まずは案件の内容や印刷条件、必要な確認範囲をご相談ください。 QRコード作成＆検証サービス 料金：1個20,000円（税別）から 提供：株式会社モンテカンポ 所在地：東京都港区西新橋2-13-6 ミタニビル3階 電話：03-5510-8991 担当：中村 無料相談予約： https://calendar.app.google/S7vdSYCYgvPPh8vL8

キャンペーンサイトの公開前に必要なのは、 制作担当者による最終確認だけではありません。 数百万円から1,000万円規模のキャンペーンで、応募フォームやLINE連携、QRコードなどに不具合が起きれば、サイトを修正するだけでは済まないことがあります。 応募できなかった利用者は戻らず、発注元の担当者は社内から、代理店や制作会社の責任者はクライアントから、「 なぜ公開前に見つけられなかったのか 」と問われる可能性があります。 そこで検討したいのが、 制作に関わっていない第三者によるサイト検証。 第三者検証は、代理店や制作会社の仕事を疑うためのものではありません。 担当者や制作チームだけでは確認しきれない 端末、OS、画面サイズ、外部サービスとの連携部分を、公開前に別の視点で確認するための「保険」です。 特に、次のような案件では検討する価値があります。 複数のスマートフォンから応募されるキャンペーン LINE、本人認証、OCR、レシート読み取りなどの外部サービスを使う施策 QRコードを紙DM、店頭POP、商品パッケージなどに印刷する案件 公開後の障害がブランドやクライアントとの関係に影響する案件 数百万円以上の予算が動き、担当者が品質について説明責任を負う案件 「これまで大きな事故がなかったから、今回も大丈夫」と考えるのではなく、 事故が起きた場合の影響から逆算して、どこまで確認するかを決める必要があります。 キャンペーンサイトの品質は、なぜ誰の責任か曖昧になるのか 公開後のトラブルが起きる背景には、 品質確認の最終責任者が決まっていない という構造があります。 発注元のマーケティング担当者は、「代理店や制作会社が確認しているはず」と考えます。 代理店の担当者は、関係者のスマートフォンやパソコンで一通り動くことを確認し、「大きな問題はなさそうだ」と判断します。 制作会社は、指定された仕様を予算と納期の範囲内で実装します。ただし、 見積もりや契約に多機種検証まで含まれていなければ、 すべての端末やOSを確認しない可能性も。 それぞれが自分の担当範囲では確認していても、「 どんな環境でも応募完了まで正常に進められるか 」を最終的に担保する人がいないまま、公開日を迎えることがあります。 この認識のずれが、品質保証の空白です。 問題は、誰かが手を抜いていることではありません。 通常の制作進行の中に、 十分な検証の役割と予算が組み込まれていないこと が問題なのです。 「代理店に任せている」ことと、「全機種で確認されている」ことは別 発注元のマーケティング担当者にとって、代理店や制作会社は重要なパートナーです。 しかし、 代理店に一括して任せているからといって、古いOS、特殊な画面サイズ、複数のブラウザ、LINE内ブラウザまで確認されているとは限りません。 たとえば、担当者のiPhoneで次の操作が問題なくできたとします。 紙DMに印刷されたQRコードを読み取るキャンペーンサイトを開くLINEでログインする応募フォームを入力する送信を完了する この結果から分かるのは、 そのiPhone、そのOS、そのブラウザ、その操作手順では動いたということだけ です。 別のAndroid端末、1世代前のOS、画面の小さい機種、LINE内ブラウザでも同じように動くとは限りません。 この場合、実際には次のような不具合が起こり得ます。 特定の機種で応募ボタンが画面外に隠れる 画面を横向きから縦向きに戻すと表示が崩れる LINE内では動くが、通常のブラウザに移ると処理が止まる 本人認証は完了したのに、応募画面へ戻れない 特定のブラウザでだけボタンが反応しない QRコードは読み取れるが、遷移先が想定と異なる エラーが起きた際に、利用者が最初からやり直せない 「自分の端末で動いた」は、確認の出発点にはなります。しかし、品質を判断する十分な根拠にはなりません。 代理店に任せている案件であっても、「 何台で確認したか 」「 どのOSを対象にしたか 」「 どこまでを通しで確認したか 」は、発注元が別途確認すべき項目です。 不具合は、サイト単体よりも「サービス同士のつなぎ目」で起きやすい 近年のキャンペーンサイトは、1社ですべての機能を開発するのではなく、 複数の外部サービスを組み合わせて構築されるケースが増えています。 代表的な構成には、次のようなものがあります。 キャンペーンサイトと応募管理サービス LINEと応募フォーム 年齢確認や本人確認サービス レシートや商品画像を読み取るOCR シリアルコードやバーコードの認証 SNSアカウントとの連携 それぞれのサービスが単体で正常に動いていても、サービス間の受け渡しで問題が起きることがあります。 たとえば、本人認証サービス側では「認証成功」と記録されていても、 キャンペーンサイト側に結果が正しく返らず 、応募者が先へ進めないことがあります。 こうした問題は、管理画面や機能単体を確認するだけでは見つけにくいものです。利用者と同じ手順で、 入口から応募完了までを通して操作する必要 があります。 弊社が見つけた不具合の事例6つをご紹介 第三者検証で見つかるのは、単純な誤字や表示崩れだけではありません。 外部サービスとの連携、入力制御、ブラウザ操作、画像判定、画面遷移など、 担当者の端末で一度動かしただけでは見落としやすい問題 もあります。 以下は、 弊社の第三者検証サービス で実際に見つかった事例です。案件名は匿名化していますが、案件種別、検証対象、環境数、不具合の内容は、検証の規模感が分かるよう具体的に記載しています。 案件 検証対象・環境 公開前に見つかった不具合 LINEミニアプリを使ったキャンペーン SNSプラットフォーム、スマートフォン8環境 友だち追加後に特定の操作で離脱すると、友だち状態が解除される 物流関連のキャンペーンシステム Webシステム、PC2環境・スマートフォン6環境 応募フォームの入力チェックに不具合がある LIFFブラウザを使った流通関連キャンペーン SNSプラットフォーム、スマートフォン8環境 ブラウザバックによって再抽選できる 診断型キャンペーンサイト PC2環境・スマートフォン6環境 画面が崩れ、次のページへ進むボタンが表示されない シリアル応募キャンペーン Webサイト、バーコード、QRコード、PC2環境・スマートフォン6環境 シリアルコードの桁数制御が正しく働いていない 商品画像をOCRで判定する応募キャンペーン Webサイト、OCR検証環境、スマートフォン10環境 判定が厳しすぎて対象画像がNGになる一方、緩すぎて対象外画像がOKになる LINEミニアプリでは、正常な応募手順だけでは見つからない LINEミニアプリを使ったキャンペーンでは、スマートフォン8環境で検証した結果、 友だち追加後に特定の操作で離脱すると、友だち状態が解除される問題 が見つかりました。 通常の応募手順を1、2回試しただけでは、途中離脱や再アクセス時の挙動までは分かりません。 実際の利用者は、通知を確認するために途中で画面を閉じたり、別のアプリに移動したりします。正常系だけでなく、途中離脱後の状態まで確認することで初めて見つかる問題があります。 応募フォームでは、送信できるだけでは不十分 物流関連のキャンペーンシステムでは、PC2環境、スマートフォン6環境で確認したところ、 応募フォームの入力チェックに不具合 が見つかりました。 フォームが表示され、正しい情報を入力して送信できるだけでは、十分な確認とはいえません。 必須項目を空欄にした場合、文字数を超えた場合、形式の異なる文字を入力した場合なども確認する必要があります。 抽選機能では、公平性に関わる不具合が見つかることもある LIFFブラウザを使った流通関連キャンペーンでは、スマートフォン8環境で検証した結果、 ブラウザバックによって再抽選できる問題 が見つかりました。 見た目には正常でも、利用者の操作によって複数回抽選できる状態であれば、キャンペーンの公平性や運営ルールに影響する可能性があります。 この種の問題は、画面の表示確認だけでは見つかりません。応募後に戻る、再読み込みする、同じ操作を繰り返すといった確認が必要です。 表示崩れは、応募不能に直結することがある 診断型キャンペーンサイトでは、PC2環境、スマートフォン6環境で確認したところ、 特定の環境で画面が崩れ、次のページへ進むボタンが表示されない問題 が見つかりました。 表示崩れというと、見た目だけの軽微な問題に思えるかもしれません。 しかし、重要なボタンが画面外に隠れれば、利用者にとっては「応募できない」「診断を完了できない」という重大な不具合になります。 シリアル応募では、不正な入力への制御も確認が必要 シリアル応募キャンペーンでは、Webサイト、バーコード、QRコードを対象に、PC2環境、スマートフォン6環境で検証した結果、 シリアルコードの桁数制御が正しく働いていないこと が分かりました。 正しいシリアルコードを入力して応募できることだけを確認しても、不正な桁数や形式への対応までは分かりません。 入力値の制御が不十分であれば、後工程のデータ処理や問い合わせ対応にも影響する可能性があります。 OCRは、1台で成功しても安心できない 商品画像をOCRで判定する応募キャンペーンでは、スマートフォン10環境で検証したところ、 正しい画像でも判定が厳しすぎてNGになるケース と、 本来は対象外の画像がOKになるケース が見つかりました。 OCRの結果は、端末のカメラ性能、画像の明るさ、角度、背景、反射などによって変わることがあります。 担当者の端末で一度認識できたとしても、利用者が持つさまざまな端末で同じ結果になるとは限りません。 公開後に直せても、失われた応募機会は戻らない Webサイトの不具合は、公開後でも修正できます。 ただし、 不具合が起きた事実まで消せるわけではありません。 たとえば、3日間の応募期間中に、一部のAndroid端末だけ応募ボタンが表示されなかったとします。 翌日に修正できたとしても、 その間に応募を諦めた人が再度アクセスしてくれる保証はありません。 問い合わせ窓口への連絡、SNS上での指摘、応募期間の延長、景品や運営ルールの再調整が必要になることもあります。 数百万円規模のキャンペーンであれば、問題は修正費用だけではありません。 発注元の担当者には、 社内への説明が求められます。 代理店や制作会社の責任者には、 クライアントに対して経緯と再発防止策を説明する必要 が生じます。 紙DMを数万通、数十万通発送した後にQRコードの遷移先に問題が見つかった場合、Webサイトだけ直せば終わるとは限りません。すでに印刷し、発送した媒体は差し替えられないためです。 ブランド施策では、技術的には小さな不具合でも、利用者から見れば「 応募できないキャンペーン 」です。 だからこそ、 検証費用は単なる追加コストではなく、事故が起きた際の損失や説明負担を抑えるための費用として考える必要があります。 発注元が確認すべきなのは、「誰が、どこまで検証するか」 発注元のマーケティング担当者が、すべての端末や技術仕様を理解する必要はありません。 確認すべきなのは、主に次の3点です。 1．検証範囲が見積もりに含まれているか 「 動作確認込み 」という表現だけでは、範囲が分かりません。 確認対象に、次の項目が含まれているかを具体的に聞く必要があります。 iPhoneとAndroidの両方 新旧のOS Safari、Chrome、LINE内ブラウザ 異なる画面サイズ 縦向きと横向き QRコードからの遷移 外部サービスとの連携 エラー時や途中離脱後の挙動 応募完了までの一連の操作 「確認します」という回答ではなく、「 どの端末で、どの操作を確認するか 」まで明確になっているかが重要です。 2．最終的な品質確認の責任者が誰か 制作会社が実装し、代理店が進行管理をしていても、 最終確認の担当者が決まっているとは限りません。 誰が合格を判断するのか、どのような記録を残すのかを、公開前に決めておく必要があります。 発注元が最終承認者であっても、技術的な検証まで発注元が行う必要はありません。 判断に必要な検証結果を、誰が用意するのか を明確にすることが重要です。 3．問題が見つかったときの判断基準があるか すべての不具合をゼロにしてから公開することが、現実的でない場合もあります。 重要なのは、発見した問題を次のように分類し、判断できる状態にすることです。 応募できないため、公開前に必ず修正する 一部の環境だけで起きるため、影響範囲を確認する 表示上の軽微な問題として、公開後の修正を検討する 仕様上許容するが、判断記録を残す 第三者検証は、公開の可否を勝手に決めるものではありません。 発注元や代理店が、 影響範囲と優先順位を判断するための材料を増やす役割 を担います。 制作・運用側にとっても、第三者検証は責任逃れではなく品質管理 代理店や制作会社の責任者にとって、外部検証を入れることは、自社の技術力不足を認めることではありません。 制作担当者には、作った本人だからこそ見落としやすい部分があります。 仕様を理解している人は 、無意識に「正しい操作」をします 。ボタンの場所も、入力すべき内容も、画面遷移も知っています。 一方、実際の応募者は 想定外の操作をします 。 入力途中でページを閉じる ブラウザの戻るボタンを押す 通信が不安定な状態で送信する QRコードをLINEや別のアプリから開く 画面を横向きにする 古い端末を使う 同じボタンを何度も押す 必須項目を空欄のまま進もうとする 制作に関わっていない第三者は、仕様を知りすぎていないからこそ、利用者に近い視点で確認できます。 また、社内の担当者だけで多機種検証を行う場合、端末の準備、テスト項目の作成、結果の記録、修正後の再確認に相応の時間がかかります。 複数案件を並行して進める制作・運用責任者にとって、検証を外部に持つことは、品質だけでなく 社内リソースを確保する方法 にもなります。 納品後の事故がクライアントの信頼と担当者自身の評価を直撃する立場であれば、「 最終責任を持つ第三者チェックを外部に持つ」という考え方には合理性があります。 最低限、公開前に確認したいチェック項目 第三者検証を利用するかどうかにかかわらず、キャンペーンサイトの公開前には、少なくとも次の内容を確認しておく必要があります。 端末と表示 iPhoneとAndroidの複数機種で確認したか 新しいOSだけでなく、利用者が一定数いる旧バージョンでも確認したか 画面サイズの小さい端末でも、重要なボタンが表示されるか 縦向きと横向きで表示が崩れないか 文字や画像が重なっていないか 拡大表示や文字サイズ変更で操作不能にならないか 応募の一連の流れ QRコードや広告から正しいページに移動するか 応募開始から完了画面まで、実際に通して操作したか 必須項目や文字数のチェックが正常に働くか 二重送信や重複応募が起きないか エラー後に利用者が操作を再開できるか ブラウザバックや再読み込みで不正な状態にならないか 外部サービスとの連携 LINEからサイトへの遷移を確認したか 認証後に正しい画面へ戻れるか OCRや画像認識を複数の撮影条件で確認したか 外部サービス側で失敗した場合の表示は分かりやすいか 通信が切れた場合や途中離脱後の挙動を確認したか 外部サービスから返されるエラーが適切に処理されるか QRコードと紙媒体 印刷前のデータだけでなく、実際の印刷物でも読み取ったか 小さすぎるサイズや低いコントラストになっていないか iPhoneとAndroidの両方で読み取れるか 読み取り後に正しいURLへ遷移するか URL変更やリダイレクト設定に問題がないか 紙面上の案内と遷移先の内容が一致しているか 確認体制 制作者本人以外が確認したか 確認した端末、OS、日時を記録したか 発見した問題と対応結果を残したか 修正後に再確認したか 誰が公開を承認したかを明確にしたか すべての案件に、大規模な検証が必要なわけではない 第三者検証は、確認項目を増やせば増やすほど費用と期間がかかります。 そのため、 すべてのキャンペーンで最大規模の検証を行う必要はありません。 案件のリスクに応じて範囲を決める のが現実的です。 たとえば、情報を掲載するだけの小規模なページであれば、主要端末での表示確認を中心にする方法があります。 一方、次の条件が重なる案件では、確認範囲を広げる判断が必要です。 応募者数が多い キャンペーン予算が大きい 応募期間が短い テレビ、新聞、店頭、紙DMなど複数媒体で告知する QRコードを大量に印刷する LINE、OCR、本人認証などを利用する 抽選やシリアルコードの仕組みがある 景品金額が大きい 不具合発生時のブランド影響が大きい 問い合わせ窓口への負担が大きい キャンペーンサイトの外部検証は、内容によって異なりますが、 1案件30万円から50万円程度 が一つの目安です。予算に応じて、端末数や確認範囲を絞った簡易的な検証を選択することもできます。 重要なのは、「30万円かかるから高い」「1,000万円の案件だから必ず必要」と一律に判断することではありません。 事故が起きたときに失う金額、応募機会、社内評価、クライアントとの信頼を考え、 検証費用とのバランスを取ること です。 たとえば、1,000万円規模のキャンペーンで30万円の検証を入れる場合、 検証費用は全体予算の3％です。 その3％を、単なる追加費用と見るか、 公開後の事故を減らし、説明責任を果たすための保険と見るか で、判断は変わります。 トラブルを防ぐために、現場で取れる3つの方法 キャンペーンサイトの品質リスクに対して、実務上は次の3つの方法があります。 1．社内ルールを決める たとえば、次のようなルールです。 QRコードを担当者個人の判断だけで作成しない 公開前に必ず制作者以外が確認する 応募完了までの画面録画を残す 確認した端末とOSを一覧化する 一定金額以上の案件は第三者検証を入れる LINE、OCR、本人認証を使う案件は連携部分を通しで確認する ルールがあれば、担当者の経験や忙しさに左右されにくくなります。 案件ごとに判断するのではなく、「 予算500万円以上 」「 紙媒体へのQR印刷あり 」「 外部サービス連携あり 」といった条件で基準を設ける方法もあります。 2．制作に関わっていない第三者が検証する 第三者が、 多機種、外部連携、途中離脱、エラー操作まで含めて確認します。 制作者の思い込みを避けられるほか、社内担当者が端末を集めて確認する負担も減らせます。 すべてを外部に任せる必要はありません。 表示確認は社内で行い、 LINE連携、OCR、応募完了までのシナリオだけを第三者に依頼する など、リスクの高い部分に絞る方法もあります。 3．結果を証拠として残す 検証は、実施するだけでなく記録を残すことが重要です。 どの端末で確認したか どのOSを使ったか どの操作を試したか 何が見つかったか どの問題を修正したか 何を許容して公開したか 修正後に誰が再確認したか 公開後に問い合わせがあった際も、「確認したはずです」ではなく、実施内容を説明できます。 これは責任を他社に移すためのものではありません。 関係者が合理的な判断をしたことを示すための記録 です。 QRコードの事故は、公開後ではなく印刷後に発覚する キャンペーンサイトの中でも、 QRコードは特に注意が必要 です。 Webサイトの表示崩れは公開後でも修正できますが、 紙DM、店頭POP、商品パッケージなどに印刷したQRコードは、簡単には差し替えられません。 よくあるリスクには、次のようなものがあります。 QRコードに設定したURLが間違っている テスト環境のURLが入ったままになっている 公開前には動いたが、リダイレクト設定の変更後に遷移しなくなった 印刷サイズが小さく、端末によって読み取れない 背景色とのコントラストが弱く、読み取りに失敗する 紙面の折り目や光沢によって読み取りにくい 短縮URLや転送サービスの設定に問題がある QRコード先のページがスマートフォンで正しく表示されない QRコードそのものを読み取れることと、その先で応募を完了できることは別です。 印刷前のデータだけでなく、実物に近い状態でQRコードを読み取り、そのまま応募完了まで進めるかを確認する必要があります。 一度QRコード事故を経験した担当者ほど、次の案件では「同じことを起こさないために、どこまで確認すべきか」を考えます。 第三者検証は、その再発防止策の一つです。 第三者検証は、事故が起きてから探すサービスではない キャンペーンサイトの検証サービスは、 必要性が分かりやすいサービスではありません 。 担当者が自分から「第三者検証が必要だ」と検索するケースは多くありません。多くの場合、代理店や制作会社が確認していると考えているためです。 必要性を強く意識するのは、一度事故を経験した後です。 紙DMのQRコードから正しいページへ遷移しなかった 一部のスマートフォンで応募ボタンが表示されなかった LINE認証後に応募画面へ戻れなかった 応募フォームの制御に問題があった OCRの判定で問い合わせが相次いだ こうした経験をすると、「次回はどうすれば防げるか」を考えるようになります。 しかし、 本来は事故の後ではなく、公開前に検討すべきものです。 数百万円から1,000万円規模の施策で、30万円から50万円程度の検証を入れるかどうかは、単なる制作費の追加ではありません。 その金額ですべての事故を防げるとは限りません。一方で、 担当者の端末だけでは見つからなかった問題を、公開前に発見できる可能性 があります。 「 代理店に任せているから大丈夫 」ではなく、代理店や制作会社と協力しながら、最後に別の目を入れる。 それが、大型キャンペーンを運営する担当者にとっての現実的な保険になります。 キャンペーン公開前に、まず確認しておきたいこと 現在進行中の案件がある場合は、代理店や制作会社に次のように聞いてみてください。 今回の案件では、どの端末とOSで、誰が、どこまで確認しますか。 LINEや認証サービスとの連携も、応募完了まで通して確認しますか。 QRコードは実際の印刷物で読み取りますか。 確認結果は、記録として残りますか。 明確な回答が得られるなら、必要な体制が整っている可能性があります。 一方で、「担当者のスマートフォンで確認します」「制作会社が見ています」といった回答だけであれば、 検証範囲をもう一段具体化した方がよい かもしれません。 すべてを完璧に確認することが目的ではありません。 案件の規模と影響に応じて、 見落としてはいけない部分を決めること。誰が最終確認を担うのかを明確にすること。 そして、 確認した結果を証拠として残すこと。 それが、公開後のトラブルを減らすための第一歩です。 監修・お問い合わせ 本資料は、 ソフトウェアテスト・第三者検証を専門とする株式会社モンテカンポ が監修、作成しました。 当社では、 QRコードの作成・検証、キャンペーンサイトの外部検証 について、ご相談を承っています。ご予算や案件の規模に応じて、範囲を絞った簡易な対応から可能です。 サービス キャンペーンサイト・外部連携検証 概要 多機種・連携のシナリオ検証。価格は検証内容により都度見積。1案件30万円〜50万円程度。簡易版も含め予算に応じて対応。 株式会社モンテカンポ 東京都港区西新橋2-13-6 ミタニビル3階 TEL：03-5510-8991 担当：中村 以下から無料相談のご予約が可能です。 https://calendar.app.google/S7vdSYCYgvPPh8vL8