AppleのVisionフレームワーク：多くの開発者がクラウドAPIに頼っているが、実は標準搭載されている機能

Appleの「Vision」フレームワーク（「OS」が付かない方）には、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）を渡し、実行します。結果はリクエストに紐づいた観測オブジェクト（observation）として返ってきます。以下のカテゴリは、iOS 26時点でのフレームワークがカバーする領域を網羅しています。

テキスト認識

VNRecognizeTextRequestはOCRを実行します。このリクエストはrecognitionLevel（ライブカメラストリーム向けの.fast、ドキュメントスキャン向けの.accurate）、言語ヒント、カスタム単語リスト、バウンディングボックスの信頼度をサポートします。iOS 18以降の.accurateパスは、レシート、看板、印刷ドキュメントにおいて商用OCR APIに匹敵します。手書き認識も多くの言語でサポートされています。

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〜300msで結果を返し、無料で、データの外部流出もありません。

顔検出とランドマーク

Visionには顔分析の3つのレイヤーが搭載されています：

• VNDetectFaceRectanglesRequestは、フレーム内のすべての顔のバウンディングボックスを返します。
• VNDetectFaceLandmarksRequestは、顔ごとに構造化されたランドマーク領域（あごの輪郭、口、目、眉、鼻、瞳孔）を返し、それぞれが複数のキーポイントを持ちます。
• VNDetectFaceCaptureQualityRequestは、Cameraアプリがセルフィー撮影のタイミングに使う品質スコアを返します。

顔の検出、顔へのクロップ、顔のぼかし、顔の数え上げが必要なほとんどのアプリでは、矩形リクエストが正しいツールとなります。ユーザーの顔に何かをアニメーション表示するアプリ（フィルター、マスク、トラッキング）では、ランドマークと瞳孔トラッキングが正しいツールです。これらすべてにモデルファイルもネットワーク呼び出しも不要です。

ボディおよびハンドポーズ

VNDetectHumanBodyPoseRequestは、VNHumanBodyPoseObservation.JointName⁴で名前付けされた19個の関節（鼻、首、肩、肘、手首、腰、膝、足首、耳、目、ルート）を、2D座標と関節ごとの信頼度とともに返します。VNDetectHumanBodyPose3DRequestは、LiDARスキャナーを搭載したデバイスでこのトポロジーを3D空間に拡張します。VNDetectHumanHandPoseRequestは、指関節レベルの解像度で21個のハンドランドマークを返します。

ボディポーズは、ウェアラブルなしでレップを数えるフィットネスアプリ、仮想コンテンツをユーザーの手に取り付けるARアプリ、フォームを評価する姿勢アプリで使われています。ハンドポーズはジェスチャー認識を駆動します（ユーザーが指を2本立てるとアプリが2本の指を認識する）。どちらも最近のiPhoneのNeural Engine上で60fpsで動作します。クラウド版の同等品は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は、組み込みの分類器（Web規模のデータで訓練されたモデルから1,000以上のカテゴリ）を使って画像のトップ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のFoundation Models（オンデバイスLLM、Foundation ModelsオンデバイスLLMで扱っています）は、この一部をオンデバイスで処理し始めていますが、複雑な推論については、依然としてGPT-4o、Claude Sonnet、Geminiに軍配が上がります。

訓練データなしのワンショットカスタムタスク。 Visionの分類モデルは固定であり、カスタムCore MLモデルには訓練データが必要です。マルチモーダルLLMは、ラベル付き訓練例を1つも見ていなくても「これは蝶ネクタイをした猫の写真ですか？」に答えられます。プロトタイピングや、訓練データの収集が高コストすぎるワンオフタスクには、クラウド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の強みはコスト（呼び出しごとにゼロ）、テールレイテンシ（ネットワークジッターなし）、プライバシー（データがデバイスから出ない）にあります。

アプリがビジョン処理を頻繁に呼び出す場合、コストは累積していきます。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のDataScannerViewControllerは、このリクエストをライブドキュメントスキャン用に設計されたUIでラップしています。

フレームワークの主力機能（顔、テキスト、ポーズ、バーコード、埋め込み）はすでに数回のiOSリリースを経て成熟しています。パターンは、再発明ではなく拡張です。

なぜ多くの開発者がVisionをスキップするのか

ケースが明確なのにフレームワークがスキップされる、3つの理由があります：

クラウドファーストの習慣。 最新のAI開発のほとんどは、まずクラウドAPIに対して行われます。開発者はOpenAIの呼び出し方を知っています。VNRecognizeTextRequest、VNImageRequestHandler、VNRecognizedTextObservationの表面積は、実際にはより少ないコード行数で済むにもかかわらず、覚えるべきAPIが多く感じられます。

機能への誤った見積もり。 最近フレームワークを確認していない開発者は、OCRとバーコードしかカバーしていないと思い込んでいます。上記のカテゴリリストは10種類以上の機能を含んでおり、その中にはクラウドネイティブ版の同等品が存在しないものも、コストなしで商用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；ランタイム vs ツーリングLLMの区別；3つのサーフェス；単一情報源パターン；2つのMCPサーバー；Apple開発のためのフック；Live Activities；watchOSランタイム；SwiftUI内部；RealityKitの空間メンタルモデル；SwiftDataスキーマ規律；Liquid Glassパターン；マルチプラットフォーム出荷；プラットフォームマトリックス；書くことを拒否するもの。ハブはApple Ecosystem Seriesにあります。より広いiOS×AIエージェントの文脈については、iOS Agent開発ガイドをご覧ください。

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が推論の大半を処理しますが、開発者がディスパッチを手動で設定することはありません。

最近何が追加されましたか？

Appleのリリースノートに対して保守的にまとめると次の通りです：VNCalculateImageAestheticsScoresRequestはiOS 18でパブリックAPIとして追加されました；VNRecognizeTextRequestは最近のリリースで多言語対応を拡大しています；VisionKitのDataScannerViewControllerはドキュメントスキャンを設計されたUIでラップします。主力機能（テキスト、顔、ポーズ、バーコード、埋め込み）は数回のiOSリリースを経て成熟しています。

参考文献