Core MLのオンデバイス推論：実際に出荷まで到達するパターン

Core MLは、現代のAppleデバイスすべてに搭載されているオンデバイス推論エンジンです。このフレームワークは、利用できるならNeural Engineへ、そうでなければGPUへ、最後の手段としてCPUへと処理を振り分け、モデルとハードウェアに応じて最速の経路を自動的に選びます¹。その結果、最近のiPhoneであれば、本番で使われるほとんどのモデルサイズについてサブミリ秒から数十ミリ秒程度のレイテンシで推論が完了します。呼び出しごとの費用はゼロで、ネットワークの往復もなく、サードパーティにデータが渡ることもありません。

「地味な配管」というこのフレームワークの評判は、すでに時代遅れです。Core MLは10年近くにわたってオンデバイス機能を支えてきました。写真アプリのセマンティック検索から、ローカルMLを載せた大半のサードパーティ製アプリまでがその例です。そしてiOS 11まで遡るすべてのOSにおいて、変換済みの固定されたモデルを動かす本番の実行面であり続けています。ただし、スタックの中での位置づけはWWDC 2026で変わりました。AppleはオンデバイスのApple Intelligenceを支える低レベルフレームワークとしてCore AIを発表し、新しいニューラルネットワーク開発が進むべき方向だと位置づけたのです¹¹¹²。一方で、Core MLのデプロイを「自分のMacでは動く」で終わらせず実際に出荷まで到達させるパターンは変わっておらず、いまも数は少ないままです。モデル変換、ディスパッチのヒント指定、レイテンシ予算、そして量子化の4つとなります。本記事では、それぞれをAppleのドキュメントに照らして見ていき、最後にWWDC26以降のスタックの中でCore MLがどこに位置するのかを整理します。

TL;DR

• Core MLは、Apple SiliconのNeural Engine、GPU、CPU上で.mlpackageと.mlmodelのファイルを実行します。ディスパッチは自動ですが、MLModelConfiguration.computeUnitsでヒントを与えられます²。
• モデル変換はcoremltoolsで行います（PyTorch、TensorFlow、ONNX → Core ML）。変換はランタイムの仕事ではなく、ツーリングの仕事です。いったん変換してバンドルに同梱してしまえば、アプリはそれを読み込んで実行するだけとなります。
• Apple Siliconのユニファイドメモリアーキテクチャにより、モデルの重みがCPU、GPU、NEのあいだでコピーされることはありません。3つとも同じメモリに支えられています³。このアーキテクチャ上の細部こそが、サブミリ秒の推論を可能にしているのです。
• 量子化（近年のCore MLではINT8やINT4）はモデルサイズを縮小し、Neural Engine上の推論を高速化します。その代わり、モデル次第で計測可能な精度の低下を伴います。coremltools 9.0（2025年11月）では、iOS 26のデプロイメントターゲット、モデルステートの読み書き、int8のモデル入出力が追加されました¹³。
• スタックはWWDC 2026で変わりました。AppleはCore AIを、オンデバイスのApple Intelligenceを支える推論フレームワークであり、新しいニューラルネットワーク開発の受け皿でもあると位置づけています。Core MLのほうは、変換済みの固定されたモデルと従来型MLのための本番レイヤーとして残ります¹¹¹²。

メンタルモデル：3つの計算経路と1つのメモリ

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

Neural Engine。 低精度の行列積に特化したアクセラレータです。畳み込み、アテンション、埋め込みといった、現代のMLモデルが依存する演算に対して最速で、消費電力も最小となります。ただし対応する演算の種類とテンソル形状は限られており、サポートされない演算はレイヤー単位でGPUやCPUにフォールバックします。

GPU。 Metalを通じた汎用の並列計算です。MLらしい形の処理ではNeural Engineより遅いものの、CPUよりは高速です。Neural Engineがサポートしない演算を引き受けます。

CPU。 フォールバック先です。ML推論では遅いのですが、常に利用でき、あらゆる演算をサポートし、挙動が読めます。

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

ディスパッチは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が受け付けるのは.mlpackageファイルで、これはXcode 13で導入され、旧来の.mlmodelを置き換えるモダンな形式です⁴。変換は、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.iOS26,
    compute_units=ct.ComputeUnit.ALL,
)
mlmodel.save("MyModel.mlpackage")

変換は開発環境で一度だけ、ターゲットとするiOSのデプロイバージョン（minimum_deployment_target）に対して実行します。出力された.mlpackageが、Xcodeプロジェクトに投入する成果物です。ランタイムのアプリがcoremltoolsを実行することはありません。最新リリースのcoremltools 9.0では、iOS 26までのデプロイメントターゲット、モデルステートの読み書き（KVキャッシュを持つTransformerデコーダのようなステートフルモデル向け）、int8のモデル入出力、そしてPython 3.13とPyTorch 2.7のサポートが追加されました¹³。

変換における実務上の落とし穴は2つあります。1つ目は、動的な形状の入力です。Core MLの既定は静的な形状であり、本番のアプリがさまざまな入力サイズを渡すと分かりにくいエラーになるため、ct.RangeDimで明示的に扱う必要があります。2つ目は、Core MLに相当する演算がないPyTorchのカスタムopです。この場合は、Core MLのカスタムレイヤー（欠けている演算を実行するSwiftコード）を用意するか、変換前にモデルのアーキテクチャを変更してその演算を取り除くかのどちらかになります。いずれもドキュメントは十分に整っています⁵。

実際に効いてくるレイテンシ予算

出荷するアプリで効いてくるレイテンシ予算は3つです。

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

100 ms（インタラクティブUI）。 ユーザーが操作をして、結果を待つ場面です。タップして識別する、描いて認識させる、話して文字起こしする、といったものが該当します。予算に余裕がある分、より大きなモデルにも対応できます。パラメータ数10億未満の言語モデル、小型のVision Transformer、そして本番品質の分類器の多くが余裕をもって収まります。

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

これらの予算は目安であって、絶対的な上限ではありません。正しいやり方は、別のマシンで得られた理論値を信じることではなく、os_signpostやInstrumentsのCore MLテンプレートを使ってターゲット端末で実測することです⁶。

量子化：小さいほうが速くなるとき

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

• Float32（完全精度）。 学習時のデフォルトです。最も大きく、最も正確で、最も遅い選択肢となります。
• Float16。 半精度です。GPUとNEではより小さく高速になり、条件のよいモデルであれば精度の低下はたいてい無視できます。
• INT8。 キャリブレーションを伴う8ビット整数の量子化です。Float32のおよそ4分の1のサイズになり、NE上では2〜4倍高速になることも珍しくありません。精度の低下は場合によりますが、ビジョンモデルであれば、量子化を考慮した学習によりtop-1精度の低下を1%未満に抑えられます。
• INT4以下。 近年のCore MLが特定のモデルアーキテクチャ（LLMや大規模なビジョンモデル）向けにサポートする、積極的な量子化です。引き換えに精度の低下は大きくなります。この手法は、モデルの性質を踏まえた量子化考慮学習と組み合わせたときに最も効果を発揮します。

coremltools.optimize.coreml.linear_quantize_weightsによる線形量子化の設定では、量子化モード（linear_symmetricまたはlinear）と、それを下回る重みは完全精度のまま残すというサイズのしきい値を、グローバルなop設定として指定します。変換は既存の.mlpackageに対して実行され、量子化された新しいパッケージが生成されます。両方をバンドルに同梱し、デバイスのクラスに応じてどちらを読み込むかアプリ側で選ぶこともできます。

量子化するかどうかはモデルごとの判断です。小さな分類器は、もともと計算が軽いので恩恵が薄いかもしれません。逆に大規模言語モデルは、計算の大半が量子化された重みとの行列積で占められるため、非常に大きな恩恵を受けます。正しい進め方は、量子化し、取り分けておいたテストセットで精度を測り、その用途にとって許容できる劣化であれば出荷する、という順序です。

そのまま組み込めるApple公式のモデル

AppleはCore ML Modelsのページを通じて、学習済みのCore MLモデルをいくつか提供しています⁸。知っておく価値のあるカテゴリは次のとおりです。

• 画像分類： MobileNetV2、ResNet50、SqueezeNetの各バリアント。いずれもバンドル済みで、VisionフレームワークのVNCoreMLRequestにそのまま投入できます。
• 物体検出： YOLOv3、MNIST、CenterNetの各バリアント。
• 姿勢推定： 身体の姿勢を扱うPoseNet（VisionのVNDetectHumanBodyPoseRequestに対するベースラインの代替）。
• セマンティックセグメンテーション： 画像のセグメンテーション向けのDeepLabV3。
• テキスト認識： Vision組み込みのものに代わる、MLベースのOCR。

多くのアプリでは、Appleの学習済みモデルだけで知覚のプリミティブ（分類、検出、セグメンテーション）を独自学習なしに賄えます。言語タスクについては、システムのオンデバイスLLMがこのレイヤーの完全に上に位置します。Foundation Modelsフレームワークが高レベルのSwift APIとしてそれを公開しており、オフラインかつ無料で、自分でバンドルしたり変換したりするモデルファイルはありません。

モデルの暗号化とApp Storeでの考慮点

アプリバンドル内の.mlpackageは、IPAを展開すれば誰でも読めます。意味のある知的財産に当たるモデルについては、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はFoundation Modelsフレームワークの背後にあり、WWDC 2026の時点で、Appleはそれを動かす推論フレームワークがCore AIであると明言しています¹¹。それでも本記事の考え方はそのまま通用します。コンピュートユニットのディスパッチ、量子化された重み、レイテンシ予算は、自分で変換したモデルを支配するのと同じようにシステムLLMも支配するからです。フレームワークの記事がLLMのAPIを扱い、本記事はその下にある推論のパターンを扱います。

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

クラウド推論が正解になるとき

Core MLの上限は、デバイスの計算能力です。クラウドが正しい選択になるケースは3つあります。

バンドルに載せるには大きすぎるモデル。 70BパラメータのLLMはアプリバンドルに収まりません。この規模のワークロードでは、クラウド推論（あるいは重みをストリーミングしてオンデバイスで動かすという、別種のパターン）が適切な道具です。

推論中にデバイス間で共有する状態が必要な場合。 推論の最中に共有データベースを読み書きする必要のあるモデル（数十億件のレコードに対する協調フィルタリングを使うレコメンドシステムなど）です。完全にローカルというCore MLのモデルでは噛み合いません。

モデルの高速なイテレーション。 モデルの更新を毎日出しているチームは、サーバーサイド推論の恩恵を受けます。ロールアウトにApp Storeの審査サイクルを挟まずに済むからです。モデルをアプリに同梱するCore MLのやり方は、モデル更新のテンポに摩擦を持ち込みます。このトレードオフは現実のものです。

パターンとしてはこうなります。スケールとイテレーションの速さではクラウドが勝ち、レイテンシ、コスト、プライバシーではCore MLが勝ちます。

WWDC 2026以降、Core MLはどこに位置するのか

WWDC 2026は、本記事の土台にある地図を描き直しました。ただし、記事の内容を無効にしたわけではありません。Appleは、要旨に「Run AI models in your app on Apple silicon」と掲げるiOS 27のフレームワーク、Core AIを発表し、セッション324では、Core AIがオンデバイスのApple Intelligenceを動かしている推論フレームワークであり、サードパーティ製アプリにも開放されたと述べました¹¹。Core MLのコンバータがハードウェアと最適化の判断を肩代わりしてくれるのに対し、Core AIは操作レバーを開発者に手渡します。明示的なモデルのスペシャライゼーション、管理されたアーティファクトのキャッシュ、コンピュートユニットの指定、そして非同期の計算ストリームです。詳細な分解はCore AI：Apple siliconでモデルを実行するにまとめています。

進む方向を示すシグナルは、ドキュメントだけから読み取れるものより強いものでした。WWDC 2026の機械学習グループラボで、Core AIのエンジニアは、ニューラルネットワークを扱う人には今後Core AIへ移ってほしいとAppleが求めており、Core MLは残るものの決定木のような従来型の機械学習に焦点を移す、と語っています¹²。この発言は公表されたポリシーではなくラボでの言い換えですが、今回のリリースの形とは符合します。新しいツーリングも、新しいフォーマットも、Apple Intelligenceのワークロードも、Core AIが手にしたからです。

いま出荷するアプリにとっての実務的な読み方は、次のとおりです。

• 既存のCore MLのデプロイはそのまま動き続けます。 iOS 27で.mlpackageの経路が非推奨になった点はありませんし、coremltools 9.0は2025年11月という直近に、新しい機能（iOS 26ターゲット、ステートフルモデル、int8のIO）を出しています¹³。
• iOS 27より前ではCore MLが唯一の選択肢であり、変換済みの固定されたモデルでコンバータの既定値が望みどおりなら、現実的な選択肢でもあります。
• iOS 27以降を狙う新しいニューラルネットワークの案件では、まずCore AIを検討すべきです。 とりわけ、必要なスペシャライゼーション、キャッシュ、スケジューリングの制御を具体的に挙げられる場合はそうです。
• 他のレイヤーは動きません。 システムLLMはFoundation Modelsの背後に留まり、MLXは、自分で持つオープンウェイトのモデルやファインチューンのための組み込み可能な配列フレームワークであり続けます。Core MLとCore AIの比較は、自分のモデルをどの実行レイヤーで動かすかという問いであって、これらについての問いではありません。

このパターンが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シリーズにあります。AIエージェントを伴うiOS開発のより広い文脈については、iOS Agent Developmentガイドをご覧ください。

よくある質問

Core MLはNeural Engine、GPU、CPUをどのように選び分けるのですか？

Core MLはモデルのグラフに含まれる演算を1つずつ調べ、その演算をサポートする最速のターゲットへ割り当てます。Neural Engineは、サポート対象の演算（多くの行列積、畳み込み、アテンション）を最小のレイテンシと電力で処理します。NEが対応しない演算はGPUが引き受け、残りを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が上限であり、OTA（無線経由）インストールにも実務上の制約があります。システムのオンデバイスLLMは、この問題を丸ごと回避します。OSが配布し、アプリは何も同梱せずにFoundation Models経由で利用できるからです。アプリに同梱するモデルであれば、100 MB未満なら余裕があり、100〜500 MBは起動時の読み込み戦略があれば実現可能で、500 MB超はBGProcessingTaskによるバックグラウンドダウンロードやオンデマンドリソースで扱うのが最善です。

新しいモデルにはCore MLとCore AIのどちらを使うべきですか？

iOS 27より前では、Core MLが唯一の選択肢です。iOS 27以降について、Appleが示している方向性は、ニューラルネットワークにはCore AI、従来型の機械学習と既存のデプロイにはCore MLの継続、というものです¹¹¹²。変換済みの固定されたモデルがあり、コンバータの既定値で用が足りるなら、Core MLでも問題なく出荷できます。スペシャライゼーション、キャッシュ、スケジューリングを明示的に制御したいのであれば、その制御こそCore AIが提供するために存在するものです。

量子化がモデルの精度を損なったかどうかは、どう判断すればよいですか？

テストセットを取り分けておき、元のFloat32モデルと量子化したモデルの両方で推論を実行し、指標を比較します（分類器ならtop-1精度、検出器ならF1、言語モデルならperplexity、翻訳ならBLEUなど）。そのうえで、アプリケーションが求める精度の要件に照らして判断してください。量子化を損失関数の中でシミュレートしながら学習する量子化考慮学習を使えば、精度の低下の多くはたいてい回復できます。

参考文献