LASSIC Media らしくメディア
アプリにVisionKit書類スキャンとライブテキストを実装
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- VisionKitのDataScannerViewControllerは、カメラ映像から書類やテキストをその場で認識するスキャナーで、iOS16以降でオンデバイス動作します。
- AndroidではML KitのText Recognition v2とDocument Scanner APIを組み合わせることで、近い書類スキャン機能を実装できます。
- カメラでのQR/バーコード読取や、サーバー側のAI-OCR帳票電子化システムとは目的が異なるため、実装前に機能の切り分けが必要です。
目次
- VisionKit書類スキャンとは、端末内で書類とテキストを認識する仕組み
- DataScannerViewController・VNRecognizeTextRequest・Live Text——iOSの3つの認識機能
- Android側の選択肢——ML Kit Text Recognition v2とDocument Scanner API
- iOSとAndroidの機能比較——対応言語・オンデバイス処理・機種要件
- 要件定義から後処理連携まで——書類スキャン実装の4ステップ
- 実装で見落としやすい落とし穴——認識精度・対応言語・機種制限
- 内製と外注の分かれ目——OS別実装とチューニングの工数で判断する
- まとめ：アプリへの書類スキャン実装で押さえる3つの判断軸
- よくある質問
VisionKit書類スキャンとは、端末内で書類とテキストを認識する仕組み
VisionKit書類スキャンとは、iOSのVisionKitに含まれるDataScannerViewControllerを使い、カメラ映像上の書類やテキストを端末内でリアルタイムに認識してデータ化する機能を指します*1。対応OSはiOS16.0以降で、処理はすべてオンデバイスで完結します*1。
この機能は、カメラでQRコードやバーコードを読み取る用途とは異なる点に注意が必要です。QR/バーコードスキャンはコード化された固定フォーマットのデータを読む処理であり、本稿が扱う書類・自由テキストの認識とは対象が別になります。
サーバー側で帳票を電子化するAI-OCRシステムとも役割が異なります。AI-OCR帳票電子化システムは、スキャンした帳票をサーバーへ送信し、AIが定型フォーマットを解析して基幹システムへ連携する仕組みです。本稿で扱うのは、その手前の工程にあたる、アプリ内で端末だけで完結するスキャン・認識機能の実装です。
名刺・帳票・領収書などをアプリのカメラで撮影し、その場でテキストを抽出したり、書類を自動でトリミングしてPDF化したりする用途に向いています*1。通信環境に依存せず低遅延で処理できる点が、端末内処理の強みと言えるでしょう*1*3。
DataScannerViewController・VNRecognizeTextRequest・Live Text——iOSの3つの認識機能
iOSには書類・テキストを認識する仕組みが複数用意されており、用途に応じて使い分けます。カメラ映像をリアルタイムに扱うか、静止画を解析するか、写真上のテキストを選択させたいかによって、選ぶAPIが変わってきます。
DataScannerViewController——カメラ映像から書類・バーコードをその場で認識するスキャナー
DataScannerViewControllerは、カメラの映像を継続的に解析し、recognizedDataTypesで指定したテキストやバーコードをその場で認識するビューコントローラーです*1。textContentTypeにfullDocument(書類全体を対象にした認識モード)を指定すると、名刺や帳票のような書類全体を対象にした認識に対応できます*1。
利用にはisSupportedとisAvailableで端末対応とカメラ権限を事前に確認する必要があります*1。対応はiOS16.0以降・iPadOS16.0以降・visionOS1.0以降です*1。
VNRecognizeTextRequest——静止画からテキストを抽出するOCRリクエスト
VNRecognizeTextRequestは、Vision framework(画像解析全般を担うApple公式フレームワーク)が提供するテキスト認識リクエストです*2。撮影済みの1枚の画像からテキストを抽出する処理に向いており、recognitionLevelでfast(速度優先)とaccurate(精度優先)を切り替えられます*2。
recognitionLanguagesで認識対象言語を優先順に指定でき、対応OSはiOS13.0以降と広めです*2。書類スキャンで撮影した画像を後段で再解析し、抽出精度を高める補助として使われることもあります。
ライブテキスト（Live Text）——写真上のテキストをその場で選択・操作できる機能
ライブテキスト（Live Text）は、写真に写ったテキストをタップして選択・コピー・翻訳したり、QRコードのリンク先を開いたりできる機能です*3。ImageAnalyzerが解析を担い、対応するのはA12 Bionicチップ以降を搭載したiOS端末です*3。
この解析もオンデバイスで完結し、画像データが外部サーバーへ送信されることはありません*3。アプリ内の画像ビューにLive Textの操作性をそのまま持ち込みたい場合に適した機能です。
Android側の選択肢——ML Kit Text Recognition v2とDocument Scanner API
Androidでは、GoogleのML KitがiOSのVisionKitに近い役割を担います。テキストの認識にはText Recognition v2、書類全体のスキャンにはDocument Scanner APIを使うのが基本の組み合わせです。
ML Kit Text Recognition v2——中国語・日本語・韓国語・ラテン文字に対応するOCR
Text Recognition v2は、中国語・デバナガリ文字・日本語・韓国語・ラテン文字のテキストを認識できるAPIです*4。幅広い端末でリアルタイムにオンデバイス認識でき、Android・iOSの両方に対応します*4。
認識結果はブロック・行・要素・シンボルの階層構造で返され、各要素の座標や信頼度も取得できます*4。名刺や領収書のように文字が入り混じる書類でも、構造化された形で文字を取り出しやすくなるでしょう。
Document Scanner API——スキャンから編集までのUIをまとめて提供する機能
Document Scanner APIは、書類の自動検出・エッジ検出・傾き補正までを含む、スキャン用のUIフローをまとめて提供するAPIです*6。2024年2月22日にGoogleが公式ブログで発表しました*6。
カメラ権限はGoogle Play servicesが持つ権限を利用するため、アプリ側で新たに申請する必要がありません*5。切り取り・フィルタ・汚れ除去などの編集機能は、SCANNER_MODE_BASE/BASE_WITH_FILTER/FULLの3段階から選べます*5。対応はAndroid APIレベル21以降で、処理はオンデバイスで行われます*6。スキャン結果はPDFまたはJPEG形式で出力できます*6。
iOSとAndroidの機能比較——対応言語・オンデバイス処理・機種要件
iOSとAndroidでは提供元も設計思想も異なるため、実装前に主要な違いを整理しておくと選定がしやすくなります。次の表は、書類スキャンに関わる主要な機能を軸に両者を比較したものです。
| 項目 | iOS（VisionKit / Vision） | Android（ML Kit） |
|---|---|---|
| 主なAPI | DataScannerViewController・VNRecognizeTextRequest*1*2 | Text Recognition v2・Document Scanner API*4*6 |
| 書類全体のスキャンUI | textContentType=fullDocumentで対応*1 | Document Scanner APIが専用UIを提供*6 |
| 処理場所 | オンデバイス*1*3 | オンデバイス*4*6 |
| 主な対応言語 | recognitionLanguagesで指定・多言語対応*2 | 中国語・デバナガリ・日本語・韓国語・ラテン文字*4 |
| 機種・OS要件 | iOS16.0以降（DataScannerViewController）*1 | Android APIレベル21以降*6 |
両者に共通するのは、端末内で処理が完結し、通信環境に依存しない点です*1*4*6。相違点は機種要件とAPIの組み方にあり、iOSはDataScannerViewController一つでスキャンUIとテキスト抽出を兼ねられる一方、Androidはテキスト認識と書類スキャンUIを別のAPIとして組み合わせる設計です*1*6。
要件定義から後処理連携まで——書類スキャン実装の4ステップ
アプリへの書類スキャン機能実装は、AppleとGoogleが提供する各APIを組み合わせる作業になります。ここでは実装の流れを4段階に分けて整理します。
ステップ1は要件定義です。名刺・帳票・領収書のどの書類を対象にするか、テキスト抽出だけで十分か、書類全体をPDF化したいかを最初に決めます。対象を絞ることで、後続のAPI選定がしやすくなるでしょう。
ステップ2は機能選定です。iOSではDataScannerViewControllerとVNRecognizeTextRequestのどちらを軸にするかを決め、Live Textの操作性を持ち込むかも検討します*1*2*3。AndroidではText Recognition v2とDocument Scanner APIの組み合わせ方を決めます*4*6。
ステップ3はスキャン実装です。カメラ映像からのリアルタイム認識と、撮影済み画像からのテキスト抽出は、それぞれ別の実装パターンになります*1*2。UI側では、isSupportedやisAvailableのような対応可否のチェックを組み込み、非対応端末でのクラッシュを防ぐ実装が求められます*1。
ステップ4は後処理連携です。抽出したテキストや画像を、社内システムへの登録用データやPDFファイルへ変換する処理を実装します*6。この段階で既存の基幹システムやDBとの連携仕様を固めておくと、後戻りが少なくなります。
実装で見落としやすい落とし穴——認識精度・対応言語・機種制限
各APIの導入自体は公式ドキュメントに沿えば進められます。ただし、実運用に耐える精度と対応範囲を確保するには、いくつか見落としやすい点があります。
第一に、対応OS・機種の制限です。DataScannerViewControllerはiOS16.0以降が必要で、Live TextはA12 Bionicチップ以降の端末が対象です*1*3。OSを更新していない端末のユーザーが残っている場合、フォールバック(非対応時の代替処理)の設計を誤ると、アプリの主要機能が使えないユーザーが生じます*1。
第二に、認識精度と処理速度のトレードオフです。VNRecognizeTextRequestのrecognitionLevelはfastとaccurateを選べますが、accurateを選ぶほど処理時間は伸びます*2。領収書のような小さな文字が多い書類では、fastのままでは文字の読み取り漏れが発生しやすくなるでしょう。認識漏れが業務データの欠落につながれば、後工程での手入力による確認作業が発生し、書類処理全体の工数がかえって増えるおそれがあります。
第三に、対応言語の設定漏れです。recognitionLanguagesやText Recognition v2の対応文字種を確認せず実装すると、日本語の帳票で認識精度が落ちる場合があります*2*4。多言語の書類を扱う業務では、言語設定を書類の種類ごとに切り替える設計が欠かせません。
内製と外注の分かれ目——OS別実装とチューニングの工数で判断する
書類スキャン機能の実装を内製で担うには、複数領域の知識が必要になります。iOSのVisionKit・Vision framework、AndroidのML Kit、それぞれのAPIの挙動と制約を理解した上で、両OSに一貫した体験を作り込む工数がかかります*1*2*4*6。
具体的には、iOS担当者はDataScannerViewControllerの権限制御とrecognizedDataTypesの設計を、Android担当者はDocument Scanner APIの3段階の編集モードとText Recognition v2の言語設定を、それぞれ検証する必要があります*1*5。加えて、書類の種類ごとに認識精度をチューニングし、実際の帳票・名刺・領収書のサンプルで検証する工程も欠かせません。
専門パートナーに委託する場合は、iOS・Android両方の実装経験と、書類スキャンに特化したチューニングの実績があるかどうかが選定の分かれ目になります。内製では、iOS・Android双方に精通したエンジニアを同時に確保する必要があり、体制構築自体がハードルになる場合があります。
。対象書類の種類や対応OSの範囲によって必要な工数は変わってきます。現状の要件を整理したうえで、内製・外注の切り分けを検討することが実務的です。
まとめ：アプリへの書類スキャン実装で押さえる3つの判断軸
本稿ではアプリへのVisionKit書類スキャンとライブテキストの実装について、Apple・Google公式情報をもとに整理しました。要点は3つに集約できます。第一に、iOSのDataScannerViewController・VNRecognizeTextRequest・Live Textは、リアルタイムスキャン・静止画OCR・写真上の操作性という異なる役割を持ちます*1*2*3。第二に、AndroidではText Recognition v2とDocument Scanner APIを組み合わせることで、近い機能を実装できます*4*6。第三に、対応OS・機種の制限や認識精度のチューニングにかかる工数が、内製と外注の判断材料になります。
よくある質問
DataScannerViewControllerとVNRecognizeTextRequestは、どちらを使えばよいですか。
カメラ映像をその場でリアルタイムに認識したい場合はDataScannerViewControllerが向いています*1。撮影済みの画像からテキストを抽出したい場合はVNRecognizeTextRequestが適しています*2。用途に応じて使い分けるか、両方を組み合わせる実装も可能です。
VisionKitの書類スキャンはiOSの古いバージョンでも使えますか。
DataScannerViewControllerはiOS16.0以降が必要です*1。それより古いバージョンでは、iOS13.0以降に対応するVNRecognizeTextRequestを使った静止画からの認識に切り替える設計を検討します*2。
AndroidでiOSのVisionKitに近い機能を実装するには、何を使いますか。
テキストの認識にはML KitのText Recognition v2、書類全体のスキャンUIにはDocument Scanner APIを組み合わせます*4*6。どちらもオンデバイスで動作し、Document Scanner APIはカメラ権限の申請も不要です*5*6。
書類スキャン機能とQR/バーコードスキャン機能は同時に実装できますか。
iOSのDataScannerViewControllerはrecognizedDataTypesにtextとbarcodeの両方を指定できるため、1つの画面で両方を認識する実装も可能です*1。コード読取に特化した実装については、関連記事で詳しく解説しています。
書類スキャンで抽出したデータを既存の基幹システムに連携するには、どうすればよいですか。
アプリ側で抽出したテキストや画像を、連携用のAPIやファイル形式に変換する後処理の実装が必要です。サーバー側で帳票を電子化する仕組み自体を構築したい場合は、AI-OCR帳票電子化システムの導入を検討する方法もあります。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Apple Developer Documentation「DataScannerViewController」（VisionKit）（https://developer.apple.com/documentation/visionkit/datascannerviewcontroller）
- *2 出典：Apple Developer Documentation「VNRecognizeTextRequest」（Vision）（https://developer.apple.com/documentation/vision/vnrecognizetextrequest）
- *3 出典：Apple Developer Documentation「Enabling Live Text interactions with images」（VisionKit）（https://developer.apple.com/documentation/visionkit/enabling-live-text-interactions-with-images）
- *4 出典：Google for Developers「Text recognition v2」（ML Kit）（https://developers.google.com/ml-kit/vision/text-recognition/v2）
- *5 出典：Google for Developers「Document scanner」（ML Kit）（https://developers.google.com/ml-kit/vision/doc-scanner）
- *6 出典：Android Developers Blog「Easily add document scanning capability to your app with ML Kit Document Scanner API」（2024年2月22日）（https://android-developers.googleblog.com/2024/02/ml-kit-document-scanner-api.html）
