Apple Vision Framework：開発者が見落としているオンデバイスCV

Appleの「OS」が付かない方のVisionフレームワークには、20種類以上のオンデバイスコンピュータビジョン処理が用意されています。しかし多くのiOS開発者は、デバイス上のNeural Engineがミリ秒で完了させられるタスクに対しても、OpenAI Vision API、Google Cloud Vision、AWS Rekognitionをまず選んでしまいます。これは検討の結果というより、思い込みの反映です。クラウドAPIは「最新のAI」に感じられ、Visionは「プラットフォームの基盤」に見えるため、プラットフォームが素通りされてしまうのです。この思い込みは、現在のプラットフォームの中身を読み違えています。

Visionはローカルファースト型のCVフレームワークです。利用可能であればNeural Engineで動き、なければGPUへ、最終的にはCPUへとフォールバックします。ほとんどの処理は数ミリ秒で推論が完了します。呼び出しごとのコストはゼロ。データはデバイスから外に出ません。APIキーが存在しないのは、そもそもAPIが存在しないからです。iOSアプリが扱うコンピュータビジョン作業の大半において、これが正しい選択肢となります。

TL;DR

• Apple Visionは20種類以上のオンデバイスCV処理を提供しています。テキスト認識、顔検出とランドマーク、身体・手のポーズ推定、バーコード読み取り、ドキュメントセグメンテーション、画像埋め込み、サリエンシー、動物検出、輪郭、軌道、オプティカルフロー、そして任意のCore MLモデルを実行するランナーまで揃っています。
• 各処理はNeural Engine上でミリ秒単位で動作し、呼び出しコストゼロ、ネットワーク不要、第三者へのテレメトリも一切発生しません。
• クラウドAPIが勝つのは、画像に対する複雑な意味論的推論という特定のケースのみです（マルチモーダルLLMがチャート、ミーム、ドキュメントの意図を理解するような場合）。ピクセルレベルの処理（顔の検出、テキストの読み取り、手の検出）であれば、コスト・レイテンシ・プライバシーのいずれにおいてもVisionに分があります。
• エージェントワークフローとの接続点：Visionの結果は、ネットワーク往復なしにApp IntentsやFoundation ModelsのオンデバイスLLM呼び出しへ直接渡せます。パイプライン全体がローカルで完結するのです。

Visionが実際に提供しているもの

Visionは各処理をVNRequest型としてグループ化しています。リクエストを生成し、パラメータを設定し、画像（またはCVPixelBuffer、CIImage、CGImage、URL）を渡して実行します。結果はリクエストに紐づく観測値として返ってきます。以下のカテゴリは、iOS 26時点でフレームワークがカバーする領域を網羅しています。

テキスト認識

VNRecognizeTextRequestはOCRを実行します。recognitionLevel（ライブカメラストリームには.fast、ドキュメントスキャンには.accurate）、言語ヒント、カスタム単語リスト、バウンディングボックスの信頼度をサポートしています。iOS 18以降の.accurateパスは、領収書、看板、ドキュメントなどの印刷テキストを高精度に処理します。手書き認識は一部の言語でサポートされています（Appleの認識対応言語リスト³を参照）。

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.usesLanguageCorrection = true
request.recognitionLanguages = ["en-US"]

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

同じ処理をOpenAI Vision API経由で行うと、低詳細モードで1呼び出しあたり1セント未満、高詳細モードでは大幅に高コストとなり、往復1〜3秒かかったうえで画像はOpenAIのサーバーへ送信されます。Visionはローカルで100〜300ミリ秒、無料、データ流出なしで結果を返します。

顔検出とランドマーク

Visionには3階層の顔解析が用意されています。

• VNDetectFaceRectanglesRequestはフレーム内のすべての顔のバウンディングボックスを返します。
• VNDetectFaceLandmarksRequestは顔ごとに構造化されたランドマーク領域（顎のライン、口、目、眉、鼻、瞳）を、それぞれ複数のキーポイントとともに返します。
• VNDetectFaceCaptureQualityRequestは顔ごとの品質スコア（0〜1）を返し、照明、シャープネス、構図中心性を反映します。アプリではセルフィー撮影のゲートや、連写から最良フレームを自動選別する用途に使えます。

顔の検出、顔への切り抜き、顔のぼかし、顔のカウントが必要なほとんどのアプリには、矩形リクエストが正解です。ユーザーの顔に何かをアニメーションさせるアプリ（フィルター、マスク、トラッキング）には、ランドマークと瞳トラッキングが正解となります。いずれもモデルファイルやネットワーク呼び出しは不要です。

身体と手のポーズ

VNDetectHumanBodyPoseRequestは、VNHumanBodyPoseObservation.JointName⁴で命名された19の関節（鼻、首、肩、肘、手首、腰、膝、足首、耳、目、ルート）を、2D座標と関節ごとの信頼度とともに返します。VNDetectHumanBodyPose3DRequestはトポロジを3D空間へ拡張し、VNHumanBodyPose3DObservationの結果を返します。デバイスが深度データ（AVDepthData）を露出している場合は精度向上のためにそれを利用しますが、LiDARスキャナは必須ではありません。⁴ VNDetectHumanHandPoseRequestは指関節の解像度で21の手のランドマークを返します。

身体ポーズは、ウェアラブルなしでレップ数を数えるフィットネスアプリ、ユーザーの手にバーチャルコンテンツを取り付けるARアプリ、フォーム評価を行う姿勢アプリに使われます。手のポーズはジェスチャー認識を駆動します（ユーザーが2本指を立てると、アプリが2本指を認識する）。いずれも近年のiPhoneでビデオフレームレートで動作するため、ライブARやジェスチャー入力に十分です。クラウド側の同等機能はGoogle MediaPipeや独自のフィットネステックAPIですが、フレームワークがその役割を置き換えます。

バーコードとQR

VNDetectBarcodesRequestは、小売や在庫管理ワークフローで必要となる主要シンボロジー（QR、PDF417、Aztec、Code 128、Code 39、EAN-13、ITF14、Data Matrix、GS1 DataBarなど）を読み取り、生のペイロードとバウンディング矩形を返します。検出はミリ秒で動作し、Apple純正のCameraアプリで実証済みの低照度条件でも機能します。

ドキュメントセグメンテーション

VNDetectDocumentSegmentationRequestはフレーム内の矩形ドキュメントを見つけ、遠近感を考慮したコーナーポイントを返します。これがドキュメントスキャナアプリでドキュメントを切り抜き、平面画像へ補正する処理の正体です。Apple純正のVisionKitフレームワークはこのリクエストとUIをラップしていますが、カスタムUIが必要なアプリは基となる処理を直接呼び出せます。

サリエンシーと美的スコア

VNGenerateAttentionBasedSaliencyImageRequestは、画像内で観察者の注意が集まりやすい場所を示すヒートマップを返します。VNGenerateObjectnessBasedSaliencyImageRequestはオブジェクトが存在する場所のヒートマップを返します。iOS 18でパブリックAPIとして追加されたVNCalculateImageAestheticsScoresRequest¹は、ユーティリティ分類（メモ、スクリーンショット）と美的価値を含む美的品質スコアを返します。これらのスコアは、Photosが「メモリー」候補を浮上させるためや、自動切り抜き判定の入力に使われています。

画像分類と埋め込み

VNClassifyImageRequestは、数百種類の一般的なオブジェクトカテゴリをカバーする組み込み分類器を用いて、画像のトップNカテゴリラベルを返します。⁵ VNGenerateImageFeaturePrintRequestは、画像類似度検索に適した特徴ベクトル（モデルの埋め込み）を返します。

埋め込みは、Photosアプリ、レシピアプリの「似た料理を探す」、ムードボードアプリの類似度ベース重複排除を実際に機能させているものです。クラウド側の同等機能はOpenAI CLIP埋め込みやGoogleのVertex AIですが、Visionはこれをローカルで無料に返します。

オブジェクトトラッキングと軌道

VNDetectTrajectoriesRequestは、フレーム間で動くオブジェクトを追跡し、放物線軌道のフィッティング（投げられたボール、放たれた矢）を返します。VNTrackObjectRequestは、ビデオシーケンス全体にわたって手動指定したオブジェクトを追跡します。

軌道はスポーツアプリの基盤プリミティブです（野球ボール、バスケットボール、テニスボールの追跡）。検出はライブのAVFoundationストリームで動作し、結果をリアルタイムで返します。

VNCoreMLRequestによるカスタムモデル

VNCoreMLRequestは、任意のCore MLモデルをVisionパイプラインで実行します。リクエストはモデルの入力記述に基づき、前処理（画像リサイズ、色空間変換、正規化）を自動的に処理してくれます。アプリ側はCreate MLでカスタム分類器を学習させるか（数カテゴリ、カテゴリあたり100枚のサンプル画像、10分の学習時間）、公開済みモデルをダウンロードし、.mlpackageをアプリバンドルに入れて、わずか3行のコードでVisionから実行します。

let model = try VNCoreMLModel(for: MyClassifier(configuration: .init()).model)
let request = VNCoreMLRequest(model: model) { request, error in
    let results = request.results as? [VNClassificationObservation]
    print(results?.first?.identifier, results?.first?.confidence)
}
let handler = VNImageRequestHandler(cgImage: image, options: [:])
try handler.perform([request])

カスタム分類器のクラウド側同等手段は、モデルをサーバーにホストし、推論コンピュートにお金を払い、APIを運用し、ネットワークレイテンシを受け入れることです。Visionなら、それがアプリバンドル内の.mlpackageとリクエストハンドラに置き換わります。

クラウドAPIが実際に勝つ場面

Visionの領域はピクセルレベルの処理です。これを見つける、この画像を分類する、このテキストを認識する、といった作業です。フレームワークは画像の意味に対する複雑な意味論的推論は提供しません。クラウドAPIが正解となる3つのケースを挙げます。

マルチモーダルLLMによる理解。「この人物は画像で何をしているか？」「このチャートはミスリーディングか？」「このメニューを翻訳して、どれがベジタリアンか教えて」。いずれもピクセルレベルの問いではありません。視覚的知覚と世界知識、言語を組み合わせる大規模マルチモーダルモデルが必要です。Appleのファウンデーションモデル（オンデバイスLLM、Foundation Models on-device LLMで扱っています）はこの一部をオンデバイスで処理し始めていますが、複雑な推論ではGPT-4o、Claude Sonnet、Geminiが依然優勢です。

学習データなしのワンショットなカスタムタスク。 Visionの分類モデルは固定であり、カスタムCore MLモデルには学習データが必要です。マルチモーダルLLMは、ラベル付き学習例を一切見ずに「これは蝶ネクタイをした猫の写真か？」に答えられます。プロトタイプや、学習データ収集が割に合わない単発タスクには、クラウドLLMが正解となります。

OCRを超えるドキュメントインテリジェンス。 VisionのOCRはテキストを返します。ドキュメントインテリジェンスAPI（AWS Textract、Google Document AI、Azure Form Recognizer）は構造化されたフィールド（請求書番号、日付、明細項目、合計）を返します。価値は構造化にあり、OCR部分ではありません。高価値なドキュメントワークフローでは通常クラウドAPIが正解、「このレシートを読んでテキストを吐き出して」程度ならVisionが正解です。

パターンとしては、クラウドは推論や高度に専門化された業種別APIで勝ち、Visionは知覚プリミティブで勝ちます。

正直なレイテンシとコストの比較

iPhone 16 Pro（A18 Proチップ）で動作する代表的な推論パイプラインを示します。

上記の数値は、Appleの公開ベンチマークと開発者報告の計測結果から導いたものです。重要なのは正確な値ではなくオーダーです。Visionが勝つのはコスト（呼び出しごとゼロ）、テールレイテンシ（ネットワークジッタなし）、プライバシー（データがデバイスを離れない）の3点です。

アプリがビジョン処理を頻繁に呼び出すと、コストはどんどん積み上がります。1セッションで100枚の画像を処理する写真編集アプリは、クラウドAPI経由ならセッションあたり数ドル単位、Vision経由ならゼロです。

エージェントワークフローとの接続点

Visionは、すでに公開済みの2つのクラスタアイデアと相性良く組み合わせられます。

Apple IntelligenceのためのApp Intentsツール。 アプリが「写真から顔を見つける」や「スクリーンショットからテキストを読む」といった機能をAppIntent経由で公開すると、インテントのperformメソッドがVisionをローカルで実行し、構造化された結果を返します。Apple Intelligenceのオーケストレータは、ユーザーの写真をサーバーに送らずにインテントを呼び出せます。App Intentsの記事では、この表面契約について詳しく解説しています。

Foundation ModelsのオンデバイスLLM。 知覚と推論の両方を必要とするパイプラインでは、Visionをまず実行し（テキスト抽出、顔検出、オブジェクト位置特定）、続いてFoundation Modelsを実行します（見つかったものについて推論し、要約を生成）。両ステージともオンデバイスで動作します。総ネットワーク呼び出し数：ゼロ。Foundation Modelsの記事ではLLMの呼び出し方を説明しています。本記事では、Visionがクラウド往復なしにそれへ入力を供給する役割を担うことを示します。

let textRequest = VNRecognizeTextRequest()
textRequest.recognitionLevel = .accurate

let handler = VNImageRequestHandler(cgImage: receiptImage, options: [:])
try handler.perform([textRequest])

let extractedText = (textRequest.results ?? [])
    .compactMap { ($0 as? VNRecognizedTextObservation)?.topCandidates(1).first?.string }
    .joined(separator: "\n")

let llmResponse = await foundationModel.generate(
    "Summarize this receipt as JSON with merchant, total, and date fields:\n\(extractedText)"
)

パイプライン全体がデバイス上で完結します。APIキー不要。ネットワーク呼び出しなし。第三者へのデータ流出もありません。

直近2リリースで成熟したもの

Appleのリリースノート²に対して保守的に日付を当てたうえで、特筆すべき追加が3つあります。

パブリックAPIとしての美的スコアリング（iOS 18）。 VNCalculateImageAestheticsScoresRequestはユーティリティ分類と美的価値を含むスコアを返し、これまで写真キュレーション系アプリがカスタムCore MLモデルで近似せざるを得なかった処理を置き換えます。

多言語OCRの改善。 VNRecognizeTextRequestは近年のリリースで非ラテン文字のサポートを拡充し、歴史的に多言語対応が強かったクラウドOCRサービスとの差を縮めています。Appleのテキスト認識ドキュメントには現在の言語サポートが掲載されています³。

VisionKit統合のドキュメントセグメンテーション。 VNDetectDocumentSegmentationRequestは矩形ドキュメントを見つけてコーナーポイントを返します。VisionKitのVNDocumentCameraViewControllerはユーザー向けの整ったUIでドキュメント撮影をラップし、DataScannerViewController（iOS 16以降）はライブテキストと機械可読コードのスキャンをカバーします。⁶

フレームワークの主要機能（顔、テキスト、ポーズ、バーコード、埋め込み）は、いくつものiOSリリースで成熟してきました。パターンは明確です。再発明ではなく、拡張するというスタンスです。

なぜ大半の開発者がVisionを素通りするのか

これだけ説得力ある場面が揃っているのに、フレームワークが素通りされる理由は3つあります。

クラウドファーストの習慣。 現代のAI開発の大半は、まずクラウドAPIに対して行われます。開発者はOpenAIの呼び方を知っています。VNRecognizeTextRequest＋VNImageRequestHandler＋VNRecognizedTextObservationという表面積は、新たに学ぶべきAPIが多いように感じられますが、行数で見ればOpenAI Visionを呼び出すより少ないのです（認証なし、HTTPなし、リトライなし、JSONパースなし）。

機能の見誤り。 最近フレームワークを確認していない開発者は、OCRとバーコードしかカバーしていないと思い込んでいます。上記カテゴリリストは20種類以上の機能を含み、いくつかにはクラウドネイティブな同等品が存在せず、いくつかは商用APIに匹敵する性能をコストなしで実現します。

プロトタイプと本番の乖離。 クラウドAPIは初期プロトタイピングで勝ちます（curl 1コマンドで結果が得られる）。そしてプロトタイプは再評価なしに本番パイプラインへ転用されてしまいます。正しい動きは、最速の手段でプロトタイプを作り、ワークフローが現実になったら知覚レイヤーを再評価することです。

修正策はクラウドAPIを拒むことではありません。プラットフォームが何を持っているかを知り、選択を本当の選択として行うことです。

このパターンがiOS 26+アプリに意味すること

3つのテイクアウェイがあります。

1. 知覚プリミティブにはVisionをデフォルトに。 顔検出、テキスト読み取り、バーコード検出、ポーズ推定、画像埋め込みの取得。フレームワークはNeural Engine上でミリ秒で動き、コストゼロ、第三者データの痕跡を残しません。ピクセルレベルのCV処理にはフレームワークが正しい出発点となります。

2. クラウドAPIは推論に使い、知覚には使わない。 画像の意味を理解するマルチモーダルLLM、構造化フィールドを抽出する業種別ドキュメントインテリジェンスAPI、学習データなしのワンショットなカスタムタスク。これらはクラウドの領分であり、譲るのが正解です。

3. 完全オンデバイスのパイプラインにはVisionとFoundation Modelsを組み合わせる。 知覚（Vision）が推論（オンデバイスLLM）に入力を渡します。パイプラインはエンドツーエンドでローカルに動作し、APIキーなし、ネットワークジッタなし、デバイスから出るテレメトリもありません。クラスタのFoundation Models記事がLLM側を扱っており、Visionが入力側を担います。

Apple Ecosystemクラスタの全体構成：型付きApp Intents、MCPサーバー、ルーティングの問い、Foundation Models、ランタイムとツーリングLLMの区別、3つの表面、単一情報源パターン、2つのMCPサーバー、Apple開発のためのhooks、Live Activities、watchOSランタイム、SwiftUIの内側、RealityKitの空間メンタルモデル、SwiftDataスキーマ規律、Liquid Glassパターン、マルチプラットフォーム出荷、プラットフォームマトリクス、書かないと決めているもの。ハブはApple Ecosystem Seriesにあります。AIエージェントを伴うiOS開発の広い文脈は、iOS Agent Development guideを参照してください。

FAQ

Apple VisionとvisionOSの違いは？

VisionフレームワークはiOS、macOS、visionOS向けのオンデバイスコンピュータビジョンAPIです。一方、visionOSはApple Vision Pro用のオペレーティングシステムです。命名の重複は不運といえます。Vision（フレームワーク）はあらゆる現代Appleデバイスで動作し、visionOS（OS）はVision Proハードウェア専用です。

OpenAI Vision APIやGoogle Cloud Visionの代わりにVisionを使うべきタイミングは？

ピクセルレベルの知覚タスク（顔検出、テキスト読み取り、オブジェクト検出、項目カウント、ポーズ推定、画像埋め込みの生成）であれば、ほぼ常にVisionが正解です。ミリ秒で動作し、推論ごとのコストはなく、ユーザーデータをデバイス上に保ちます。クラウドAPIが正解となるのは、画像の意味に対する複雑な意味論的推論を要する場合や、業種別ドキュメントインテリジェンスAPIがテキスト抽出を超える構造化フィールドを提供する場合です。

自前のCore MLモデルをVision経由で実行できる？

可能です。VNCoreMLRequestは任意のCore MLモデルをラップし、前処理を自動的に処理します。.mlpackageファイルをアプリバンドルに入れ、モデルをインスタンス化し、VNCoreMLModelでラップして、リクエストハンドラから実行します。同じハンドラで複数のリクエストを並列実行でき、組み込みのVisionリクエストとカスタムCore MLモデルを同時に動かせます。

Apple Silicon上でVisionのディスパッチはどう動く？

Vision（およびそれが実行するCore MLモデル）は、利用可能ならNeural Engineへ自動ディスパッチし、なければGPUへフォールバックし、最終的にはCPUへ落ちます。フレームワークがデバイスと処理に応じて最速のパスを選びます。近年のiPhone（A12 Bionic以降）では、Neural Engineが推論の大部分を担い、開発者がディスパッチを手動設定する必要はありません。

iOS 18とiOS 26で新しくなったものは？

Appleのリリースノートに対して保守的にまとめると、VNCalculateImageAestheticsScoresRequestはiOS 18でパブリックAPIとして追加されました。VNRecognizeTextRequestは近年のリリースで多言語サポートを拡充しています。VisionKitのDataScannerViewController（iOS 16以降）はライブテキストと機械可読コードをカバーし、VNDocumentCameraViewControllerはドキュメント撮影をカバーします。主要機能（テキスト、顔、ポーズ、バーコード、埋め込み）は、いくつものiOSリリースで成熟してきました。

References