オンデバイス OCR はどう動くのか：Apple Vision Framework 解説

「オンデバイス」とは具体的に何を意味するのか

「オンデバイス OCR」という言葉はマーケティングコピーで気軽に使われがちなので、Apple Vision の文脈で何を意味するのかを正確に整理します。macOS 上のアプリが Vision に画像内のテキスト認識を依頼すると、画像の前処理から、字形を検出・デコードする CNN や Transformer、曖昧性を解消する言語モデルまで、パイプライン全体がお手元の Mac の中の物理的なハードウェアで動きます。CPU、内蔵 GPU、そして Apple Silicon なら Neural Engine — これらが分担して計算を行います。1 バイトもマシンの外には出ません。

クラウド OCR は完全に別の話です。Google Cloud Vision・AWS Textract・Azure Computer Vision はいずれも、画像を base64 で HTTPS 上にアップロードする前提で設計されています。画像はベンダーのデータセンターに着地し、そこのモデルを通って、認識結果が返ってきます。この往復には光速・自分のネットワーク・ベンダー側のキューという下限があります。さらに、その画像は短時間とはいえ他人のディスクに乗り、そのベンダーのその時点のログ保管・モデル学習ポリシーの対象になります。

オンデバイスはこれを丸ごと回避します。アップロードのステップが無く、アプリにネットワーク権限が要らず、API キーの管理も、利用上限の監視も、コール毎の課金も、読むべきプライバシーポリシーも存在しません。代わりに、OS が出荷するモデルと、自分が買ったシリコンに縛られます。スクリーンショット OCR においては、ほとんどの Mac ユーザーがこのトレードオフを受け入れやすいと思います。

Apple Vision Framework の歴史を簡単に

Apple Vision は 2017 年 WWDC で iOS 11 / macOS 10.13 High Sierra と一緒に登場しました。最初のバージョンは顔検出・矩形検出・バーコード読み取りどまりで、まだ OCR はありませんでした。本格的なテキスト認識が来たのは 2019 年の iOS 13 / macOS 10.15 Catalina で、ここで Apple は VNRecognizeTextRequest を追加しました。「Vision がテキストを読める」が宣伝文句から、Swift 数行で呼べる API へと変わった瞬間です。

多くの人が Apple のオンデバイス OCR を体感する Live Text（テキスト認識表示）が出たのはその 2 年後、iOS 15 / macOS Monterey でした。Live Text はフレームワークを置き換えたわけではなく、その上に UI をかぶせたものです。「メッセージ」で写真を長押ししても、Safari でテキストの上をホバーしても、Cheese! OCR のようなサードパーティアプリを使っても、内部で動いているのは同じ VNRecognizeTextRequest です。Ventura・Sonoma・Sequoia と世代を重ねるごとに、Apple は認識モデルを継続的に改善し、対応言語を増やしてきました。

2026 年時点で、フレームワークは数十言語に対応しています。歴史的に OCR エンジンを苦しめてきた中日韓の三系統文字も含まれます。Vision は今や「写真」検索（「テキストを含む写真を見せて」）、VoiceOver の画像説明、ビジュアルルックアップなどの土台にもなっています。

VNRecognizeTextRequest API の中身

開発者が実際に呼ぶクラスは VNRecognizeTextRequest です。入力画像と設定、completion handler を取り、VNRecognizedTextObservation の配列を返します。各要素には認識候補とバウンディングボックスが入っています。

重要な設定は 2 つ。1 つ目は recognitionLevel で、2 つのモードがあります。.fast は速度に最適化された小さめのモデルで、ライブカメラやスクロール中の動画フレーム向け。.accurate は大きめのモデルで、静止スクリーンショットや PDF ページに向きます。Cheese! OCR を含む大半の Mac OCR ツールはデフォルトで .accurate を選びます。ユーザーが見ているのは静止画 1 枚で、数百ミリ秒の差は人間には分からないからです。

2 つ目は recognitionLanguages。BCP-47 形式の言語タグを優先順に並べた配列で、たとえば "en-US"・"zh-Hans"・"ja-JP"・"ko-KR"。順番は曖昧な字形を解決するときに言語モデルへのヒントとして使われます。たとえば、ラテン文字の「o」と数字の「0」とキリル文字の「о」を見分けるのに効きます。LINE のスクショから漫画のコマ、英語の論文 PDF まで何でも放り込まれる可能性のある汎用ツールなら、CJK + 英語の 4 つを既定で有効にしておくのが妥当です。

もう一つ usesLanguageCorrection という Bool 設定があり、認識後の言語モデル補正をオン/オフできます。オンにすると「teh」が「the」に直り、語彙統計に沿って結果がならされます。オフにすればピクセル通りに返ってくるので、コードやナンバープレート、製品 SKU には便利です。

最小構成の Swift コード例

以下は CGImage に対して Apple Vision の OCR を走らせ、結果を出力する最小限の Swift コードです。Cheese! OCR が内部で使っている呼び出し経路から、エラー処理と UI 周りを取り除いたものです。

import Vision

func recognizeText(in cgImage: CGImage) {
    let request = VNRecognizeTextRequest { request, error in
        guard let observations = request.results as? [VNRecognizedTextObservation] else {
            return
        }
        let lines = observations.compactMap { $0.topCandidates(1).first?.string }
        print(lines.joined(separator: "\n"))
    }

    request.recognitionLevel = .accurate
    request.recognitionLanguages = ["en-US", "zh-Hans", "ja-JP", "ko-KR"]
    request.usesLanguageCorrection = true

    let handler = VNImageRequestHandler(cgImage: cgImage, options: [:])
    try? handler.perform([request])
}

注意点をいくつか。completion handler はバックグラウンドキューで動くので、UI アプリならクリップボード更新やトースト表示の前にメインスレッドへ戻します。topCandidates(1) は最有力候補だけを返しますが、引数を増やせば複数候補をユーザーに見せることもできます。ここでは VNImageRequestHandler に CGImage を渡していますが、CVPixelBuffer・CIImage・ファイル URL も受け付けます。動画フレームや PDF ページから流すときに便利です。

普通のユースケースで触る API はこれで全部です。SDK のインストールも、モデルファイルの同梱も、認証フローも、利用ダッシュボードもありません。OS がモデルを提供し、シリコンが実行し、アプリは関数を 1 つ呼ぶだけです。

Apple Silicon で Neural Engine が効く理由

Neural Engine は Apple Silicon の各チップに載っている専用の機械学習アクセラレータです。M1 で 16 コアからスタートし、M2・M3 もそのコア数を維持、M4 でスループットと共有メモリ帯域に手が入りました。Apple Silicon Mac では、Vision のテキスト認識モデルは既定で Neural Engine 向けにコンパイルされて動き、Neural Engine で処理できない部分は GPU がフォールバックします。

体感できる効果は 2 つ。1 つ目は速度。ホットキーを押して画面の一部を切り取ると、ほぼ即時に結果が返ってきます。2 つ目は省電力性。Neural Engine は推論あたりの消費電力が CPU や GPU より大幅に低く、何百枚もの OCR を続けても MacBook のバッテリーが目に見えて減りません。同じハードは Siri、写真検索、ボイスメモの文字起こし、Apple Intelligence などにも使われていて、Vision はその多くのテナントの一つです。

Intel Mac でもフレームワークは動きます。CPU と GPU の経路にフォールバックするのでやや遅くなりますが、スクリーンショット程度の画像サイズなら人間が違和感を覚えるほどの差は出ません。Vision は最新ハードだけでなく、Mac ラインナップ全体で使えるよう意図的に設計されています。

プライバシー：オンデバイスである意義

オンデバイス OCR の中で最も流されがちなのが、実はプライバシーの話です。技術的な主張はシンプルです。Apple Vision でスクリーンショットを OCR したとき、その画像のバイトはあなたの Mac の外には出ていません。Apple は見られない。あなたのネットワークも見られない。Vision を呼んでいるサードパーティのアプリでさえ、画像そのものは見ていません。

最後の点が大事なのは、「オンデバイス OCR」という言葉が時にゆるく使われるからです。アプリが Apple Vision を使いつつ、認識結果やテレメトリ、あるいはスクリーンショットを「学習用に」自社サーバーに送ることは技術的に可能です。それを検証する手段が、App Store サンドボックスのネットワーク権限です。Mac App Store 経由で配信されるアプリは、使うネットワーク機能をすべて宣言する必要があります。ネットワーク権限を一切持たないアプリは、カーネルレベルで HTTP 通信が不可能です。例外はありません。

Cheese! OCR はその後者です。ネットワーク権限を持たず、テレメトリ SDK も、解析サービスも、外部にデータを送るクラッシュレポーター類もありません。Vision 呼び出しは OS に渡し、認識結果は OS のクリップボードに置く — データフローはこれで完結します。社内の機密文書、Slack のスレッド、個人的なやり取りといったスクリーンショットを OCR する用途では、これは大きな差になります。

Apple Vision とクラウド OCR の比較表

トレードオフを 1 か所に集めると次のとおりです。クラウドの価格はベンダーが定期的に料金体系を組み替えるため幅で示しています。実際の単価はボリューム・リージョン・機能フラグで変わります。あくまで桁感として参照し、正確な数字はベンダーの料金ページを見てください。

エンドユーザー向けの Mac アプリにとっての結論はシンプルです。コスト・レイテンシー・プライバシーの 3 点では Apple Vision に分があります。サーバーサイドのバッチ処理・構造化フォーム解析・Apple が出荷していない言語が必要な場面ではクラウド API に分があります。

Apple Vision がまだ苦手なもの

Apple Vision を完璧と書くのは正直ではありません。OCR 戦略を選ぶときに知っておく価値のある制限を挙げます。

続け書きの手書き。整った活字風の手書きならある程度読めますが、続け書きの英語、自由なメモ、手書きの漢字や仮名は当たり外れがあります。手書きノートを取り込むワークフローが中心なら、Apple Vision 単体では足りません。マルチモーダル LLM か専用の手書き認識エンジンの方が向いています。

縦書きの CJK テキスト。日本の書籍、漢籍、伝統的なポスターは縦書き・右から左の組版が多いです。Vision のテキスト検出器は左から右への横書きに強く偏っており、縦書き列を分断したり、読み順を取り違えたりすることがしばしばあります。「縦書きだよ」と教えるための公開フラグはありません。

強い傾きや歪み。本の綴じ際で曲がったページ、急角度で撮った看板、遠近変換のかかったスクリーンショットなどは検出器を惑わせます。Vision にも一定の補正は入っていますが、一部のクラウドサービスほど積極的ではありません。

装飾フォント。ゲーム UI の装飾文字、書道、レトロな看板、極端なカーニングのロゴは精度が落ちます。モデルは一般的な書体で学習されており、装飾フォントのロングテールは既知の弱点です。

数式・化学式の記法。方程式、積分記号、化学構造式、読み順に並ばない 2 次元レイアウトは平坦な文字列に潰れます。LaTeX や MathML 出力が必要なら専用モデルの出番で、Mathpix が存在する理由はまさにここにあります。

これらの制限は、オンデバイス OCR が一般的な用途に向かないことを意味しません。万能ではないというだけです。

Cheese! OCR のようなツールにとっての意味

こうした基盤の話が Mac の OCR ユーティリティに関係するのは、フレームワーク選びがそのアプリに約束できることの上限と下限を決めてしまうからです。クラウド前提の OCR アプリが「爆速 OCR」と謳っても、ネットワークレイテンシーという床と、消えないプライバシーの注釈は付いて回ります。Apple Vision を使う完全ローカルの OCR アプリは、フレームワークの床（とても速い）と天井（Apple が出荷する言語と精度）の両方を引き継ぎます。

Cheese! OCR は Apple Vision の上に直接組み立てられています。ホットキーを押し、画面の領域をドラッグで選ぶと、得られた CGImage が VNRecognizeTextRequest に渡されます。デフォルトで CJK + 英語の 4 言語を有効にした構成です。一瞬後にはクリップボードに認識結果が入り、ローカルの SQLite 履歴 DB に書き込まれます。サーバーは無く、ネットワーク権限は無く、テレメトリも無し。Live Text と同じモデルを、別の — 率直に言ってより使いやすい — UI で動かしているだけです。

この設計は実利として効きます。飛行機の機内でも動きます。インターネットの半分を遮断する社内 VPN でも動きます。Google サービスにアクセスできない地域でも動きます。家の Wi-Fi が不安定でも遅くなりません。機密契約書や個人的なメッセージのスクリーンショットを OCR するときに、「今この画像を誰が見たか」と気を揉む必要もありません。

自分の Mac で使う OCR を選ぶときに、最初に話すべきはフレームワークのレイヤーです。クラウドにもローカルにも正当な使いどころがあります。個人の Mac で日常のスクリーンショット OCR をする限り、オンデバイスの Apple Vision を超えるのは難しい — そして、よく聞かれる疑問は次の FAQ にまとめてあります。