LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

QR・バーコードスキャン機能の外注とは

モバイルアプリへのQR・バーコードスキャン機能の外注とは、スマートフォンのカメラを使って商品コードや入場券QRコードを読み取る機能を、専門のモバイル開発パートナーに委託して実装・納品してもらう開発形態です。

在庫管理・受付チェックイン・決済・クーポン配布といった業務では、QRコードやJANコード（EAN-13）のスキャンがアプリの中核機能になります。読み取りの速度や精度は業務効率に直結するため、「とりあえずカメラを開くだけ」では通用しません。

外注を検討する企業の多くは、モバイルネイティブのカメラ制御やOSアップデート追従の知見を社内に持っておらず、開発リソース不足から外部パートナーに委ねるケースが大半です。本記事では、発注側の担当者が押さえるべき技術的な論点と、プロジェクトを円滑に進めるための進め方を整理します。

iOS・Androidそれぞれの標準API — VisionKit・AVFoundation・ML Kit

スキャン機能の実装方式は、OSごとに複数の選択肢があります。発注前に方式の概要を把握しておくと、パートナーとの技術的な認識合わせがスムーズになります。

iOSの2つのアプローチ

iOS向けには、大きく分けて「VisionKit（VisonKit）フレームワークのDataScannerViewController」と「AVFoundationのAVCaptureMetadataOutput」の2系統があります。

DataScannerViewControllerはiOS 16以降で利用できる高レベルAPIで、カメラプレビュー・ハイライト表示・テキスト認識をまとめて提供します。^*1 UIの構築コストを低く抑えられるため、スキャン機能が主体の画面では採用しやすい選択肢です。

一方、AVCaptureMetadataOutputはiOS 6から提供される低レベルAPIで、カメラセッションを細かく制御したい場合や、iOS 15以前をサポートする必要がある場合に適しています。処理の自由度が高い分、実装工数は増加します。

Androidの標準的な組み合わせ

AndroidではGoogleのML Kit Barcode Scanning^*2が広く採用されています。1D・2D合わせてCodabar/Code39/Code93/Code128/EAN-8/EAN-13/ITF/UPC-A/UPC-E（1D）とAztec/Data Matrix/PDF417/QRコード（2D）に対応し、ネットワーク接続なしでデバイス内処理が完結します。

カメラ制御にはCameraXライブラリとML Kit Analyzerを組み合わせるのが現在の主流です。CameraXはAndroid Jetpackの一部であり、機種・OSバージョン間の差異を吸収しながらカメラパイプラインを統合できます。

カメラ権限不要のGoogle Code Scanner API

ML Kitと同じスキャンモデルを使いながら、カメラ権限をアプリが直接取得せずにGoogle Play Servicesへ処理を委譲する「Google Code Scanner API」も選択肢の一つです。^*3 「Google doesn’t store the results or image data」とドキュメントに明記されており、スキャン結果のみがアプリに返却されます。Android API レベル23以上が必要で、カスタムUIを設けず読み取り結果だけを受け取ればよいシンプルな用途に向いています。

クロスプラットフォームフレームワーク利用時の注意

React NativeやFlutterで開発する場合は、上記のネイティブAPIをラップしたサードパーティライブラリを使うのが一般的です。ライブラリのメンテナンス状況・OSバージョン対応・ライセンスを発注前に確認することが大切です。特にネイティブAPIのバージョンアップ追従遅延は、OSアップデート後に読み取り不具合が発生する原因になります。

要件定義で押さえる5つの論点 — フォーマット/暗所/複数同時/権限/業務連携

スキャン機能の要件定義で論点を整理しておかないと、開発中盤での仕様変更が工数を大幅に増やします。以下の5点を発注前に明確にすることをお勧めします。

論点1：対応するコードフォーマットの特定

業務で使うコードが何かを先に確認します。商品バーコードであればJANコード（EAN-13）、倉庫ロケーションラベルであればCode128、入場券や電子クーポンであればQRコードが多いです。

ML Kit Barcode Scanningはデフォルトで全フォーマットを検出しますが、対象フォーマットを絞り込むと処理速度が向上します。複数のフォーマットが混在する環境（例：商品コード＋QRクーポン）では、読み取り後にフォーマット種別を判定して業務ルートを分岐させる処理が必要になります。

論点2：暗所・歪み・反射への耐性

倉庫や小売現場では照明が不均一なケースが多く、ラベルが折れていたり缶・ボトルに貼られていたりすることもあります。ML Kit バージョン17.2.0以降では自動ズーム機能（zoomCallback）が追加されており、遠距離のコードも認識精度を補えます。^*2

受け入れテストでは「暗所でのEAN-13読み取り」「反射するシュリンクパックのバーコード読み取り」など実業務のシナリオで検証することが大切です。机上のデモでは見えにくい問題が現場では頻発します。

論点3：複数コードの同時・連続読み取り

棚卸しや入荷検品では1画面に複数のバーコードが映り込む場面があります。ML Kitの1回の処理あたりの検出上限は10バーコードですが、同一コードの重複カウントを防ぐデバウンス処理や、連続スキャンのフロー設計は開発側の実装判断に委ねられます。仕様書に「1スキャンで複数コードを同時検出するか」を明記しておかないと、後から追加工数が発生します。

論点4：カメラ権限とプライバシーポリシー

iOSではカメラへのアクセスに用途説明（NSCameraUsageDescription）が必須です。App Store審査でも用途の妥当性が確認されます。Androidの場合、Google Code Scanner APIを使えばアプリ側でCAMERA権限を宣言せずに済みますが、UIのカスタマイズに制約があります。

プライバシーポリシーにもカメラ取得データの用途を記載する必要があります。法務・コンプライアンス部門との連携を開発着手前に済ませておかないと、ストア申請直前に差し戻しが発生します。

論点5：読み取り後の業務システム連携

スキャン機能の価値は「コードを読んだ後」にあります。読み取ったコードを在庫管理システムのAPIに送信して在庫を引き当てる、受付システムに照合して入場を許可する、決済APIを呼び出してクーポンを消化する——こうした業務連携の仕様が固まっていないと、バックエンド側の改修が後追いになります。外注スコープを「スキャンUI＋業務API呼び出しまで」にするのか「UI実装のみ」にするのかを最初に決めることが重要です。

内製vs外注の判断基準 — 必要スキルと工数から考える

スキャン機能を内製で開発するには、複数の専門知識が必要です。具体的には、iOSであればAVFoundationまたはVisionKitの知識・SwiftUIまたはUIKitでのカメラUI実装スキル・App Storeのプライバシー審査対応の理解が求められます。

Androidではカメラライフサイクル管理（CameraXのProcessCameraProviderやImageAnalysis）・ML Kit APIの統合・Jetpackコンポーネントとの組み合わせ実装が必要です。クロスプラットフォームフレームワーク（React Native/Flutter）を採用する場合はさらにネイティブブリッジの知識が加わります。

工数の目安として、基本的なQRコード読み取りUIの実装は経験者1名で数日程度ですが、業務API連携・複数フォーマット対応・暗所対応チューニング・テスト・リリース対応を含めると、数週間から1か月超になるケースがあります。社内にiOS/Androidエンジニアが不在か兼務状態の場合、リリース遅延や品質リスクが高まります。

外注を選択した場合の利点は、OS追従対応（メジャーバージョンアップ時のAPI非推奨への対応など）やスキャン精度チューニングのノウハウを即戦力で得られる点です。一方で、業務要件の伝達と仕様書の精度が成否を左右します。

外注先の選定と発注時に確認すべきこと

スキャン機能の外注先を選ぶ際は、以下の点を確認することをお勧めします。

iOS・Android両対応実績とネイティブ開発力

クロスプラットフォームフレームワークのみでの対応実績しかない場合、カメラAPIのネイティブ挙動に起因する問題の対処が難しいことがあります。特に「iOS 17でのAVCaptureSession挙動変更への対応」「Android端末固有のカメラ遅延問題のトラブルシュート」のような実績を確認するとベンダーの実力が見えやすくなります。

業務システム連携の開発経験

スキャン機能単体ではなく、在庫管理システムや受付APIとの結合開発の経験があるかどうかを確認します。バックエンドAPI仕様が外注先とのやり取りの中で変わりやすいため、フロントエンド側でエラーハンドリングや再試行処理を適切に実装できるかが重要です。

発注時に渡すべきドキュメント

以下の資料を発注時に準備すると認識齟齬を防げます。

• 対応するコードフォーマット一覧（形式・読み取り後の処理内容）
• 対象OSバージョンとデバイス（iOS/Android・最低サポートバージョン）
• スキャン後に呼び出すAPIのエンドポイント・リクエスト/レスポンス仕様
• UIデザインモックまたはワイヤーフレーム
• 受け入れテストシナリオ（業務シナリオベース）

契約形態の選択

機能要件が固まっている場合は請負契約が適しています。要件が段階的に決まる場合や、既存アプリへの組み込みで影響範囲が読みにくい場合は、準委任契約（時間単価型）の方が柔軟に対応できます。スコープが明確であれば請負で単価を抑えつつ品質責任を明確にすることが選択肢になります。

受け入れテストと業務連携システムへの接続

開発完了後の受け入れテストは、実際に使う業務環境を再現して実施することが大切です。

テスト環境の準備

スキャン機能のテストは実機でなければ意味をなしません。iOSシミュレーターはカメラを持たず、Androidエミュレーターもカメラ動作に制約があります。発注時に「実機テストを何台で行うか」「テスト用のコードラベルを誰が用意するか」を明記しておくことが重要です。

検証すべきシナリオ例

• 暗所（照度100lux以下相当）でのEAN-13・QRコード読み取り
• 缶・ボトル曲面に貼られたバーコードの読み取り
• 折れ・汚れのあるラベルへの耐性
• 業務API呼び出し時のネットワーク遅延・タイムアウト時のエラー表示
• 同一コードの連続誤読を防ぐデバウンス動作の確認

業務連携の結合テスト

スキャン後に在庫APIや受付システムを呼び出す場合、バックエンド側のステージング環境と結合してテストします。「APIがエラーを返したときにアプリ上でどのメッセージを表示するか」まで確認することが大切です。業務担当者が実際に操作するユーザー受け入れテスト（UAT）を最終工程に設けることで、現場のオペレーション齟齬を事前に解消できます。

リリース後の運用体制

iOSはApple・AndroidはGoogleが毎年秋にメジャーOSアップデートを実施します。VisionKitやML Kitのバージョンアップ、非推奨APIへの対応が必要になることがあり、リリース後の保守契約またはスポット対応の枠組みを発注先と取り決めておくことをお勧めします。

まとめ：スキャン機能外注で失敗しない3つの判断軸

本稿では、モバイルアプリへのQR・バーコードスキャン機能の外注に際して押さえるべき論点を整理しました。要点を3つにまとめると次の通りです。

第一に、iOS（VisionKit/AVFoundation）とAndroid（ML Kit/CameraX・Google Code Scanner API）の標準APIをおおまかに把握したうえで、対応フォーマット・カメラ権限方針・業務連携スコープを要件定義で明文化することです。

第二に、内製には複数のネイティブ開発スキルと相応の工数が必要で、社内リソースが限られる場合は外注が現実的な選択になります。外注先には業務システム連携の実績と実機テスト環境を確認することが大切です。

第三に、受け入れテストは暗所・曲面・歪みなど実業務シナリオで実施し、リリース後の保守体制（OSアップデート追従）を発注段階で合意しておくことがプロジェクト完了後のリスクを抑えます。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Apple Developer Documentation「DataScannerViewController — VisionKit」（2023年・iOS 16以降対応）
2. *2　出典：Google for Developers「Barcode scanning | ML Kit」（2024年確認）
3. *3　出典：Google for Developers「Google Code Scanner API | ML Kit」（2024年確認）

Tweet