Rork Max で AI 機能を組み込んだアプリを作ろうとすると、遅かれ早かれ「端末上で機械学習モデルを動かしたい」という場面に突き当たります。オンデバイス推論の魅力は、ネットワーク依存がない、レイテンシが圧倒的に低い、プライバシーが守れる、API コストがゼロという 4 点で、これらを兼ね備えるためには Apple の Core ML を使うのが最短ルートです。
しかし Rork Max で生成した SwiftUI アプリに Core ML モデルを入れる作業は、思っているほど直線的ではありません。モデル変換・ターゲット設定・Compute Units の指定・量子化・バッテリー消費の抑制・新旧端末での差異 — これらを一つずつ押さえていかないと、「モデルは動いているが異常に遅い」「特定機種で落ちる」「バッテリー消費が激しくて App Store レビューで指摘される」といった症状に陥ります。
ここで整理するのは私自身が Rork Max で生成した個人アプリに Core ML を統合してきた中で整理した、実装レベルでの最適化手順をまとめます。単なる Core ML 入門ではなく、Rork Max 生成物と組み合わせたときに特有の落とし穴 を含めて深掘りします。
1. Core ML 統合の全体像と Rork Max 特有の前提
Core ML の統合は、大きく 5 つのフェーズに分かれます。①モデルの調達または学習、②Core ML 形式への変換、③Xcode プロジェクトへの追加、④Swift からの推論呼び出し、⑤端末別パフォーマンス調整。Rork Max で生成したプロジェクトの場合、③以降を自分で行うことになります。
Rork Max の現状のテンプレートは、Core ML の統合を前提とした初期コードを生成しないため、後から自分でモデルを追加する形になります。これは一見面倒に見えますが、モデルを差し替えたときにコードが壊れにくい 、という意味ではむしろ健全な構造です。
最初の一歩は、.mlmodel または .mlpackage ファイルを Xcode プロジェクトに追加することです。Rork Max が生成したプロジェクトの場合、ルートの SwiftPackage のような場所にモデルを入れると、Xcode が自動的に <ModelName>.swift という型安全なラッパーコードを生成します。これを Swift コードから呼び出すことで、文字列ベースの入出力ではなく、型付きの入出力で推論を扱えます。
2. モデル変換: PyTorch / TensorFlow から Core ML へ
既存のモデルを使う場合、ほとんどは PyTorch または TensorFlow 形式で手元にあります。Core ML に変換するには coremltools を使います。
import coremltools as ct import torch
# PyTorch モデルを読み込み model = torch.load( "my_model.pt" , map_location = "cpu" ) model.eval()
# トレース example_input = torch.rand( 1 , 3 , 224 , 224 ) traced_model = torch.jit.trace(model, example_input)
# Core ML に変換 mlmodel = ct.convert( traced_model, inputs = [ct.ImageType( name = "input" , shape = ( 1 , 3 , 224 , 224 ), scale = 1 / 255.0 )], convert_to = "mlprogram" , compute_precision = ct.precision. FLOAT16 , minimum_deployment_target = ct.target.iOS17, ) mlmodel.save( "MyModel.mlpackage" ) ここでのポイントは 3 つあります。convert_to="mlprogram" は Core ML の新しい形式（Xcode 13 以降）で、旧来の NeuralNetwork 形式より高速化と柔軟性が向上しています。compute_precision=ct.precision.FLOAT16 は推論時の精度を float32 から float16 に落としてモデルサイズを半分にします。minimum_deployment_target はその iOS バージョンで使える最適化を有効化します。
Rork Max で Deployment Target を iOS 17 以上に設定しているなら、ここでも iOS17 を指定するのが最適です。
3. 量子化: サイズとパフォーマンスのトレードオフ
オンデバイス推論でモデルサイズは重要です。アプリ全体のサイズを App Store の上限（無圧縮で 4GB）に収める必要があり、モデルが 200MB あると更新のたびに大きなダウンロードになります。
量子化の選択肢は実質 3 つあります。
Float16（半精度） : モデルサイズ 1/2、ほぼ精度劣化なし。まずはここから始めるのが安全です。
Int8（8 ビット整数） : モデルサイズ 1/4、精度が 1〜3% 劣化する場合あり。画像分類のような用途なら実用的な劣化幅です。
Palettization（パレット化） : モデルサイズを 1/8 以下にできる新しい手法。iOS 17 以降で有効で、重みの値を限られた「色」（8〜256 個）に量子化します。大幅な圧縮と精度の両立が可能で、2026 年時点で一番推奨される手法です。
import coremltools.optimize as cto
# パレット化（4 ビットモード） op_config = cto.coreml.OpPalettizerConfig( mode = "kmeans" , nbits = 4 ) config = cto.coreml.OptimizationConfig( global_config = op_config) palettized_model = cto.coreml.palettize_weights(mlmodel, config = config) palettized_model.save( "MyModel_palettized.mlpackage" ) 実測では、画像分類モデル（MobileNetV3 相当）で 22MB → 3.5MB にサイズ削減でき、精度の低下は 1% 未満という結果が出ています。
4. Compute Units の指定 — Neural Engine を確実に使う
Apple Silicon 搭載デバイスには CPU、GPU、Neural Engine（ANE）の 3 種類の演算ユニットがあります。Core ML はデフォルトでこの 3 つから最適なものを自動選択しますが、常に Neural Engine を使うわけではない という点に注意が必要です。
推論時の指定は以下のようになります。
import CoreML
let config = MLModelConfiguration () config.computeUnits = .all // CPU + GPU + ANE すべて使用（デフォルト） // config.computeUnits = .cpuOnly // CPU のみ（デバッグ用） // config.computeUnits = .cpuAndGPU // GPU のみ // config.computeUnits = .cpuAndNeuralEngine // ANE 優先 Rork Max で生成したアプリで体感速度が遅いとき、多くの場合は Neural Engine が使われていないことが原因です。実際にどのユニットで動いているかは、Xcode の Instruments で「Core ML」テンプレートを使うと可視化できます。開発中に一度確認しておくのを強くお勧めします。
5. 画像入力の最適化 — 前処理を Core ML 側に寄せる
推論速度を大きく左右するのが、入力の前処理です。画像を渡す前に、リサイズ・正規化・チャンネル変換を Swift 側で行うと、毎フレーム CPU で重い処理をすることになります。
最適化のコツは、前処理を Core ML モデル側に取り込む ことです。coremltools でモデル変換するときに、入力として ct.ImageType を指定すると、リサイズ・スケーリングがモデル内部で行われます。Swift 側では CVPixelBuffer をそのまま渡すだけで済み、速度が顕著に改善します。
// 良い例: CVPixelBuffer を直接渡す let input = MyModelInput ( input : pixelBuffer) let output = try model. prediction ( input : input)
// 悪い例: Swift で前処理してから渡す // (CPU で重い処理になる) 6. バッテリー消費の抑制
オンデバイス推論は計算量が大きいため、継続的に動かすとバッテリーが急速に減ります。App Store のレビューでも、「バッテリー消費が激しい」という理由でリジェクトされるケースが実際にあります。
対策は 3 つあります。
ひとつ目 : 推論を必要なタイミングに絞る。リアルタイムで毎フレーム推論するのではなく、ユーザーが明示的にアクションした時点（シャッターを押した、画面をタップした）に絞ります。連続推論が必要なアプリでも、フレームレートを 30fps から 10fps に落とすだけで消費電力が大幅に下がります。
ふたつ目 : Low Power Mode を検知して推論を間引く。ProcessInfo.processInfo.isLowPowerModeEnabled を確認し、Low Power Mode 中は推論間隔を広げるか、より軽量なモデルに切り替えます。
みっつ目 : 高温時に推論を一時停止します。ProcessInfo.processInfo.thermalState で熱状態を検知し、.serious や .critical のときは推論を止めます。これによりサーマルスロットリングを防ぎ、結果的に持続的なパフォーマンスが向上します。
7. 端末別パフォーマンスの差異
iPhone の世代によって、Core ML のパフォーマンスは大きく違います。特に Neural Engine の性能は世代ごとに約 2 倍ずつ伸びており、古い端末で遅いモデルが新しい端末では十分速いことが多々あります。
実用的な目安として、2026 年時点で:
iPhone 12 以前: 軽量モデル（3MB 未満・入力 224×224 程度）を推奨
iPhone 13〜15: 中規模モデル（20MB 程度・入力 384×384 程度）が快適
iPhone 16 以降: 大規模モデル（100MB 程度・入力 512×512 以上）も実用的
Rork Max で生成したアプリの Deployment Target を iOS 17 以上にし、かつ最新世代の iPhone をメインターゲットにしている場合、かなり大きなモデルでも体感は悪くありません。ただし旧機種でのフォールバックを考えておくのが実務的です。
8. 複数モデルの切り替え戦略
ひとつのアプリで複数のモデルを使う場合、メモリ管理が重要になります。Core ML のモデルはロード時に数百 MB のメモリを消費することがあり、複数モデルを同時に持つと jetsam（メモリ圧迫時の OS による強制終了）の対象になります。
対策は、モデルを必要なときだけロードし、不要になったら明示的に解放する ことです。
class ModelManager { private var currentModel: MLModel ?
func loadModel ( named name: String ) throws { let url = Bundle.main. url ( forResource : name, withExtension : "mlmodelc" ) ! currentModel = try MLModel ( contentsOf : url) }
func unloadModel () { currentModel = nil // ARC で即座に解放 } } このパターンを徹底するだけで、メモリ使用量が 1/3 程度に収まり、旧機種でのクラッシュが劇的に減ります。
9. モデルの A/B テストと差し替え
Core ML モデルはアプリバイナリに含まれるため、モデルを差し替えるにはアプリを再リリースするのが通常です。しかし、Apple は compileModel API を使って、ダウンロード済みのモデルをランタイムでコンパイル・ロードする仕組みを提供しています。
let compiledUrl = try MLModel. compileModel ( at : downloadedMlpackageUrl) let model = try MLModel ( contentsOf : compiledUrl) この仕組みを使えば、サーバー側でモデルを配信し、アプリ側で動的に切り替えられます。A/B テストや、特定ユーザー向けのパーソナライズドモデル配信にも応用できます。Rork Max で生成したアプリに組み込むときは、モデルのダウンロード進捗 UI を用意し、バックグラウンドでコンパイルする設計にすると UX が自然です。
10. デバッグと可視化のコツ
Core ML のパフォーマンスは、静的に分析するよりも実機で計測する方が確実です。Xcode の Instruments に「Core ML」テンプレートがあり、これを使うと各推論のレイテンシ、使用されている Compute Unit、メモリ使用量がリアルタイムで可視化できます。
実機でプロファイルを取るときのポイントは、Release ビルドで測ること、Low Power Mode をオフにすること、アプリを単独で実行すること（他のアプリがバックグラウンドで動いていると数値がブレる）の 3 点です。
個人開発者の視点から（実体験メモ）
最適化の優先順位と設計原則
以上を踏まえて、Rork Max 生成物に Core ML を統合するときの優先順位を整理します。
最優先は モデルを小さくすること 。これは App Store のバイナリサイズ、ダウンロード時間、起動速度、メモリ使用量の全てに影響する、最もレバレッジの大きい作業です。パレット化は 2026 年時点で圧倒的に有効な手法なので、まずここから始めてください。
次に Compute Units を確認すること 。Neural Engine が使えているかを Instruments で確認し、使えていなければモデル変換時のオプションを見直します。多くの場合、convert_to="mlprogram" と minimum_deployment_target の調整で解決します。
最後に バッテリーと熱の管理 。これはユーザー体験の品質に直結します。毎フレーム推論は避け、必要なタイミングだけ動かす設計に徹するだけで、App Store レビューでのリジェクトリスクも下がります。
Rork Max は AI 前提のアプリ生成ツールですが、最終的にユーザーの手元で動くのは Core ML モデルです。Rork で生成した綺麗な SwiftUI コードと、最適化された Core ML モデルを組み合わせることで、ネイティブの iOS アプリとして遜色ない、いえそれ以上のユーザー体験を提供できます。次にモデルを組み込むときは、本ガイドの 10 項目を順に確認しながら進めてみてください。