Core MLによるオンデバイス推論：実際にプロダクションで使えるパターン

Core MLは、最新のすべてのAppleデバイスに搭載されているオンデバイス推論エンジンです。このフレームワークは、モデルとハードウェアに基づいて最速のパスを自動的に選択し、利用可能であればNeural Engineへ、そうでなければGPUへ、最後の手段としてCPUへとディスパッチします¹。最新のiPhoneでの結果として、ほとんどのプロダクションモデルサイズに対してサブミリ秒から十数ミリ秒程度のレイテンシで推論が実行され、呼び出しごとのコストはゼロ、ネットワークラウンドトリップもなく、サードパーティへのデータ流出もありません。

「無名の配管設備」というこのフレームワークの評判はもはや時代遅れです。Core MLは現在、Apple IntelligenceのオンデバイスLLM、Photosアプリのセマンティック検索、Cameraアプリのシーン認識、そしてローカルMLを搭載するほとんどのサードパーティアプリの基盤となっています。「自分のMacでは動く」レベルではなく、Core MLのデプロイメントを実際にプロダクションで動作させるパターンは、ごく小さなセットに集約されます。モデル変換、ディスパッチのヒント指定、レイテンシ予算、量子化です。本記事では、これらのそれぞれをAppleのドキュメントに沿って解説していきます。

TL;DR

• Core MLは.mlpackageおよび.mlmodelファイルを、Apple SiliconのNeural Engine、GPU、CPU上で実行します。ディスパッチは自動的に行われますが、MLModelConfiguration.computeUnitsを介してヒントを指定することもできます²。
• モデル変換はcoremltools（PyTorch、TensorFlow、ONNX → Core ML）を介して行われます。変換はツーリングのタスクであり、ランタイムのタスクではありません。一度モデルが変換されてバンドルされれば、アプリはそれを読み込んで実行するだけです。
• Apple Siliconのユニファイドメモリアーキテクチャでは、モデルの重みがCPU、GPU、NEの間でコピーされることはなく、同じメモリが3つすべてを支えています³。このアーキテクチャ上の特性こそが、サブミリ秒の推論を可能にしているのです。
• 量子化（最近のCore MLバージョンではINT8、INT4）はモデルサイズを縮小し、Neural Engine上での推論を高速化しますが、モデルに依存する測定可能な精度コストを伴います。
• エージェントワークフローとの結びつき：Foundation Models（Apple IntelligenceのオンデバイスLLM）は、高レベルのSwift APIの背後にあるCore MLモデルとして提供されます。同じディスパッチおよび量子化のパターンが適用されます。

メンタルモデル：3つのコンピュートパス、1つのメモリ

Apple Silicon（A12 Bionic以降のM系列MacおよびA系列iPhone）には、3つの推論ターゲットが搭載されています。

Neural Engine。 低精度の行列乗算に特化したアクセラレータです。最新のMLモデルが依存する演算（畳み込み、アテンション、エンベディング）に対して最速で動作します。消費電力も最小です。サポートされる演算タイプとテンソル形状は限られており、サポートされていない演算はレイヤーごとにGPUまたはCPUにフォールバックします。

GPU。 Metalを介した汎用並列コンピュートです。MLライクなワークロードに対してはNeural Engineより低速ですが、CPUよりは高速です。Neural Engineがサポートしない演算を処理します。

CPU。 フォールバックです。ML推論には低速ですが、常に利用可能で、すべての演算をサポートし、予測可能です。

ユニファイドメモリアーキテクチャは、同じ物理RAMがこれら3つすべてを支えていることを意味します³。一度読み込まれたモデルの重みは、ディスパッチがターゲット間で切り替わってもコピーされません。このアーキテクチャ上の事実こそが、マルチターゲットディスパッチをレイヤーごとのコピーコストから、レイヤーごとのスケジューリング判断へと変えているのです。

MLModelConfiguration.computeUnitsがディスパッチを制御します。

let config = MLModelConfiguration()
config.computeUnits = .all          // default: NE, GPU, CPU
// Other options:
// .cpuAndGPU
// .cpuAndNeuralEngine
// .cpuOnly
let model = try MyModel(configuration: config)

.allがデフォルトであり、ほぼすべてのアプリにとって正しい選択です。フレームワークは演算ごとに最速のパスを選択し、その演算ごとの判断は、開発者が書くであろうあらゆるヒューリスティックよりも高速です。これをオーバーライドする稀な理由としては、テストで動作の一致を確認するために.cpuOnlyを強制する場合（モデルがパスごとに異なる挙動を示し、テストが決定論的なパスを必要とする場合）、または別の並行タスクのためにNeural Engineを解放するために.cpuAndGPUを強制する場合などが挙げられます。

モデル変換：ツーリングのタスク

ほとんどのMLモデルは、PyTorch、TensorFlow、またはAppleのCreate MLを直接使ってトレーニングされます。Core MLは、Xcode 13で導入され、古い.mlmodelに取って代わるモダンなフォーマットである.mlpackageファイルを受け付けます⁴。変換はAppleのオープンソースPythonパッケージであるcoremltoolsを介して行われます⁵。

典型的なPyTorchからCore MLへの変換は、3つのステップに従います。

1. トレーニング済みのPyTorchモデルを読み込み、推論モードに設定する。
2. プロダクションの入力形状と一致する入力テンソルの例を使ってモデルをトレースする。
3. 対象のデプロイメント先iOSバージョンに対して、トレース済みモデルをcoremltoolsで変換する。

import torch
import coremltools as ct

model = MyTrainedModel()
model.load_state_dict(torch.load("weights.pth"))

example_input = torch.rand(1, 3, 224, 224)
traced_model = torch.jit.trace(model, example_input)

mlmodel = ct.convert(
    traced_model,
    inputs=[ct.ImageType(name="image", shape=example_input.shape)],
    minimum_deployment_target=ct.target.iOS18,
    compute_units=ct.ComputeUnit.ALL,
)
mlmodel.save("MyModel.mlpackage")

変換は、対象のデプロイメント先iOSバージョン（minimum_deployment_target）に対して、開発環境で一度だけ行われます。出力された.mlpackageが、Xcodeプロジェクトに追加されるものです。ランタイムのアプリはcoremltoolsを実行しません。

変換における実用的な落とし穴は2つあります。1つ目は、動的形状の入力にはct.RangeDimによる明示的な処理が必要だということです。なぜなら、Core MLの静的形状デフォルトは、プロダクションアプリが可変サイズの入力を渡したときに役に立たないエラーを発生させるからです。2つ目は、Core MLに同等のものがないPyTorchのカスタム演算には、Core MLカスタムレイヤー（不足している演算を実行するSwiftコード）か、変換前に演算を取り除くためのモデルアーキテクチャの変更のいずれかが必要だということです。どちらも十分にドキュメント化されています⁵。

実際に適用されるレイテンシ予算

実際にアプリをプロダクションで動かす上で重要なレイテンシ予算は3つあります。

16 ms（60 fpsのライブUI）。 リアルタイムのカメラフィルター、フレームごとに更新されるARシーン、ライブオーディオアナライザーなど。この予算には画像の前処理、モデル推論、後処理、UI更新といったすべてが含まれます。これに収まるモデルは典型的には小さく（MobileNetV3クラス、1億パラメータ未満）、Neural Engine上で実行されます。

100 ms（インタラクティブUI）。 ユーザーがアクションを取り、結果を待つケースです。タップして識別、描画して認識、口述して書き起こしなど。この予算はより寛容で、より大きなモデルにも対応できます。10億パラメータ未満の言語モデル、小さなビジョントランスフォーマー、そしてほとんどのプロダクショングレードの分類器が余裕を持って収まります。

1秒以上（バックグラウンドまたはバッチ）。 フォトライブラリのインデックス作成、ドキュメント解析、アプリ起動時のモデルウォームアップなど。より大きなモデルでも動作しますが、進捗インジケータでユーザーの期待値を設定する必要があります。Foundation ModelsのオンデバイスLLMは、より大きなコンテキストウィンドウの操作についてはここに位置します。

これらの予算はガイドラインであり、絶対的な制限ではありません。正しいアプローチは、別のマシンの理論的な数値を信用するのではなく、os_signpostまたはInstrumentsのCore MLテンプレート⁶を使ってターゲットデバイス上で計測することです。

量子化：小さい方が速いとき

Core MLはいくつかの量子化レベルをサポートしています⁷。

• Float32（フル精度）。 トレーニングのデフォルトです。最大、最も正確、最も低速。
• Float16。 半精度です。GPUとNE上ではより小さく高速で、適切に条件付けされたモデルでは精度損失は通常無視できる程度です。
• INT8。 キャリブレーションを伴う8ビット整数量子化です。Float32より約4倍小さく、NE上ではしばしば2〜4倍高速になります。精度損失はさまざまですが、ビジョンモデルの場合、量子化対応トレーニングを使えばトップ1精度の損失を1%未満に抑えることが可能です。
• INT4以下。 最近のCore MLバージョンが特定のモデルアーキテクチャ（LLM、大規模ビジョンモデル）向けにサポートする積極的な量子化です。トレードオフとして大幅な精度損失が伴います。この技術は、モデル対応の量子化対応トレーニングと組み合わせると最も効果的です。

coremltools.optimize.coreml.linear_quantize_weightsによる線形量子化の設定では、量子化モード（linear_symmetricまたはlinear）を選択するグローバル演算設定と、それを下回る場合に重みをフル精度のままにする重みサイズの閾値を受け付けます。変換は既存の.mlpackageに対して実行され、新しい量子化されたパッケージを生成します。デバイスクラスに基づいてアプリがどちらを読み込むかを選択することで、両方を同じバンドル内に並べて出荷することもできます。

量子化の判断はモデルごとです。小さな分類器はそのコンピュートがすでに安価であるため恩恵を受けないかもしれません。一方、大規模言語モデルは、そのコンピュートが量子化された重み上の行列乗算によって支配されるため、大きな恩恵を受けます。正しいアプローチは、量子化し、ホールドアウトしたテストセットで精度を計測し、ユースケースにとって精度の低下が許容範囲内であれば出荷することです。

ドロップインで使えるApple組み込みのモデル

AppleはCore ML Modelsページを通じて、いくつかのトレーニング済みCore MLモデルを提供しています⁸。知っておく価値のあるカテゴリは以下の通りです。

• 画像分類： MobileNetV2、ResNet50、SqueezeNetのバリアントなど。すべてバンドル済みで、VisionフレームワークのVNCoreMLRequestにすぐにドロップインできます。
• 物体検出： YOLOv3、MNIST、CenterNetのバリアント。
• 姿勢推定： ボディポーズ用のPoseNet（VisionのVNDetectHumanBodyPoseRequestに対するベースラインの代替）。
• セマンティックセグメンテーション： 画像セグメンテーション用のDeepLabV3。
• テキスト認識： Vision組み込みに代わるMLベースのOCR代替手段。

ほとんどのアプリにとって、Appleのトレーニング済みモデルは、カスタムトレーニングを必要とせずに知覚プリミティブ（分類、検出、セグメンテーション）をカバーします。Foundation ModelsのオンデバイスLLM（Foundation Models on-device LLMで扱っています）は最大の例です。数十億パラメータのLLMが、高レベルのSwift APIの背後にあるCore MLモデルとして提供され、Neural Engine上でディスパッチされ、オフラインで利用可能です。

モデル暗号化とApp Storeに関する考慮事項

アプリバンドル内の.mlpackageは、IPAを展開した者であれば誰でも読み取ることができます。意味のある知的財産を表すモデルについては、AppleはEncrypt your Core ML modelワークフローを通じてモデル暗号化をサポートしています⁹。Xcodeを介して暗号化キーが生成され、CloudKitを介して管理されます。バンドル内のモデルは暗号化されており、Core MLが読み込み時に復号します。

ほとんどのアプリにとって、暗号化はやり過ぎです。汎用的なImageNetデータでトレーニングされたモデルは競争上の差別化要因にはならず、それを暗号化しても価値あるものを保護することなく、運用上の複雑さを増すだけです。暗号化は、本物のトレーニングデータへの投資や競争優位性を表すモデルのためにとっておきましょう。

オンデバイスのプライバシー：アーキテクチャ上の勝利

プライバシーに関するストーリーは明快です。Core MLの推論は完全にデバイス上で行われます。入力データ（画像、音声、テキスト）はデバイスを離れません。モデルファイルはローカルにあり、推論はローカルで行われ、結果もローカルに残ります。

規制された業界（医療、金融、教育）のアプリにとって、このアーキテクチャ上の事実は一連のコンプライアンス作業を不要にします。プライバシーポリシーに追加すべきサードパーティのデータプロセッサーが存在しません。セキュリティ面で精査すべきモデルAPIエンドポイントもありません。データそのものが移動しないため、データレジデンシーの問題も生じません。

Privacy Manifest形式¹⁰は、App Store提出時のプライバシーストーリーを成文化します。オンデバイス推論にCore MLを使用し、それ以外には何も使用しないアプリは、推論パスについてサードパーティとのデータ共有がゼロであることを宣言できます。提出プロセスはより速く、プライバシーレビューはより短く、ユーザーに表示されるプライバシー栄養成分表示もより簡潔になります。

エージェントワークフローとのつながり

Core MLは、このクラスタですでに扱った3つのパターンと組み合わさります。

VisionフレームワークのVNCoreMLRequest。 カスタムCore MLモデルは、自動的な前処理を伴うVisionパイプラインを通じて実行されます。このパターン（Vision Frameworkで扱っています）は、iOSアプリ内でカスタム画像分類器または検出器を出荷する正しい方法です。

Foundation ModelsのオンデバイスLLM。 Apple IntelligenceのLLMは、高レベルのSwift APIの背後にあるCore MLモデルです。同じディスパッチ（Neural Engineを優先）、量子化（LLMの重みにINT4を使用）、そしてレイテンシ予算（短い生成に対して1秒未満）のパターンが適用されます。Foundation Modelsに関する記事ではAPIを扱い、本記事ではその基盤となるエンジンを扱っています。

ローカルMLを使用するApp Intentsツール。 ローカルの画像分類器またはテキスト分類器を実行するAppIntentは、ネットワークラウンドトリップなしで構造化された結果をApple Intelligenceに返します。この組み合わせこそが、「エージェント的なApple」を実際にプライベートなものにします。フレームワークがそれをサポートしているからこそ、エージェントのツールはローカルで動作するのです。

クラウド推論が正しい選択となる場合

Core MLの上限はデバイスのコンピュートです。クラウドが正しいケースは3つあります。

バンドルにシッピングするには大きすぎるモデル。 700億パラメータのLLMはアプリバンドルに収まりません。このスケールのワークロードでは、クラウド推論（または重みのストリーミングによるオンデバイス推論という別のパターン）が正しいツールです。

推論中にデバイス間で共有される状態。 推論中に共有データベースを読み書きする必要があるモデル（数十億のレコードに対する協調フィルタリングを伴うレコメンデーションシステムなど）。Core MLの純粋にローカルなモデルは適合しません。

迅速なモデルの反復。 毎日モデルアップデートをシッピングするチームは、ロールアウトにApp Storeのレビューサイクルが不要なため、サーバーサイド推論の恩恵を受けます。Core MLのモデルをアプリにバンドルするパターンは、モデルのリビジョンサイクルに摩擦を加えます。このトレードオフは現実のものです。

このパターンとして、クラウドはスケールと反復速度で勝り、Core MLはレイテンシ、コスト、プライバシーで勝ります。

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

3つの要点があります。

1. バンドルに収まり、ユーザーがアクションを取れる呼び出しごとの結果を生成するモデルには、Core MLをデフォルトで使うこと。 画像分類、物体検出、音声分類、ジェスチャー認識、エンベディング生成、小〜中規模の言語タスクなど。フレームワークの自動ディスパッチとApple SiliconのNPUは、無料でサブミリ秒から十数ミリ秒の推論を生み出します。

2. 精度の低下が許容範囲内であれば、積極的に量子化すること。 INT8は通常安全です。INT4はサイズの節約が重要な大規模モデルに適しています。量子化が普遍的に安全だと信じるのではなく、ホールドアウトしたセットで精度を計測しましょう。

3. 完全なローカルパイプラインのために、VisionおよびFoundation Modelsと組み合わせること。 Core MLはエンジンであり、Visionはその上にある知覚API、Foundation Modelsはその上にあるLLMです。クラスタのVision記事とFoundation Models記事が、より高レベルの表面を扱っています。

Apple Ecosystemクラスタの全体：型付きのApp Intents、MCPサーバー、ルーティングの問題、Foundation Models、ランタイム対ツーリングのLLMの区別、3つの表面、単一の真実の源パターン、2つのMCPサーバー、Apple開発のためのhooks、Live Activities、watchOSランタイム、SwiftUIの内部、RealityKitの空間メンタルモデル、SwiftDataのスキーマ規律、Liquid Glassパターン、マルチプラットフォームシッピング、プラットフォームマトリックス、Visionフレームワーク、Symbol Effects、私が書くことを拒むもの。ハブはApple Ecosystem Seriesにあります。AIエージェントを伴うより広いiOSのコンテキストについては、iOS Agent Developmentガイドをご覧ください。

FAQ

Core MLはNeural Engine、GPU、CPUのどれを選ぶかをどう決めるのですか？

Core MLはモデルグラフ内の各演算を検査し、その演算をサポートする最速のターゲットにディスパッチします。Neural Engineは、サポートされている演算（ほとんどの行列乗算、畳み込み、アテンション）を最も低いレイテンシと電力で処理します。GPUはNEがサポートしない演算を処理します。CPUは残りを処理します。この判断は演算ごとに自動的に行われ、手書きのヒューリスティックよりも高速です。

常に.computeUnits = .allを使うべきですか？

ほぼ常にそうです。フレームワークの自動ディスパッチはよく調整されています。出力の一致をテストする場合（同じモデルでも浮動小数点の丸めにより、NEとCPUでわずかに異なる結果を返す）には.cpuOnlyにオーバーライドし、並行タスクのためにNeural Engineを解放するには.cpuAndGPUにオーバーライドしましょう。

.mlpackageと.mlmodelの実用的な違いは何ですか？

.mlpackageはXcode 13で導入されたモダンなフォーマットです。保存されたメタデータ、ML Program（mlprogram）コンパイル用の複数のモデルバリアント、iOS 13以降のツールチェーンをサポートしています。.mlmodelはレガシーフォーマットです。どちらも依然としてMLModelを介して読み込まれます。新規開発では.mlpackageを使うべきです。

アプリバンドル内のCore MLモデルはどれくらいの大きさにできますか？

固定の上限はありませんが、App Storeのバンドルサイズはダウンロードで4 GBまでに制限されており、無線インストールには実用上の制限があります。Foundation ModelsのオンデバイスLLMは約3 GBで、アプリバンドルではなくOSによって配布されます。アプリにバンドルされるモデルとしては、100 MB未満が快適、100〜500 MBは起動時の読み込み戦略を伴えば実現可能、500 MB以上はBGProcessingTaskによるバックグラウンドダウンロードまたはオンデマンドリソースを通じて扱うのがベストです。

量子化が私のモデルの精度を損ねたかどうかをどうやって知ればよいですか？

テストセットをホールドアウトし、オリジナルのFloat32モデルと量子化されたモデルで推論を実行し、メトリクス（分類器ならトップ1精度、検出器ならF1、言語モデルならパープレキシティ、翻訳ならBLEUなど）を比較し、アプリケーションの精度要件に基づいて判断しましょう。量子化対応トレーニング（損失関数で量子化をシミュレートしてモデルをトレーニングする）を使えば、通常は精度損失のほとんどを回復できます。

参考文献