LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

端末内ML推論とは何か — Core ML・ML Kitの役割

端末内ML推論（オンデバイス推論）とは、学習済み機械学習モデルをアプリのバイナリに組み込み、スマートフォン本体のプロセッサー上で推論処理を完結させる実装形態です。クラウドサーバーにデータを送信して結果を受け取るクラウドAI方式とは異なり、ネットワーク通信を必要としません。

オンデバイス推論が選ばれる3つの理由

端末内推論がクラウドAIより優位となる場面は3つあります。第一はレイテンシです。ネットワーク通信を介さないため、カメラ映像のリアルタイム処理など応答速度が重要な用途では有利です。

第二はオフライン動作です。圏外の環境でも推論を継続できるため、製造現場の検査アプリや登山・アウトドア向けアプリで採用されています。第三はプライバシーです。顔写真や医療画像など個人に関わるデータをサーバーに送信しないため、個人情報保護の観点から好まれます。

クラウドAI呼び出しとの違い

クラウドAI（OpenAI API・Google Cloud Vision等）はモデルのメンテナンスが不要で最新モデルを即時に利用できる利点があります。一方、通信費・API利用料が発生し、オフライン環境では動作しません。端末内推論はアプリバイナリにモデルが含まれるため配布後のモデル更新が手間ですが、継続的な課金がなく、プライバシー要件を満たしやすいです。

どちらを選ぶかは、レイテンシ要件・オフライン要件・プライバシー要件・モデル更新頻度の4軸で判断します。これらが揃っている場合はオンデバイス推論が適していますが、複雑な条件が少なく頻繁なモデル更新が必要な場合はクラウドAIが向いています。

Core ML（iOS）の仕組みと外注時の前提知識

Core MLはApple公式が提供するiOS向けオンデバイスMLフレームワークです。学習済みモデルをiOSアプリに統合し、iPhone・iPadのSoCに搭載されたNeural EngineやGPUを自動的に活用して高速推論を実現します。外注先への発注時に、変換→組み込み→Swift実装の3ステップを理解しておくと仕様書が書きやすくなります。

.mlpackageへのモデル変換とXcode連携

Core MLで推論を動かすには、PyTorchやTensorFlowで学習したモデルを.mlpackage形式（Core ML形式）に変換する必要があります。変換にはAppleが提供するPythonパッケージ「coremltools」を使います。

変換後の.mlpackageファイルをXcodeプロジェクトにドラッグ＆ドロップすると、Xcodeが入力・出力の型に対応したSwiftコードのインターフェースを自動生成します。実際の推論呼び出しは`model.prediction(input:)`数行で完結するため、Core MLの実装コストはフレームワーク選定後の調整よりもモデル変換と検証に集中します。

Neural Engine・GPUの自動活用とバッテリー

Core MLはApple Silicon（A・Mチップ）に搭載されたNeural Engineを自動で活用します。推論の種類と端末のスペックに応じてNeural Engine・GPU・CPUを自動選択するため、開発者が明示的にハードウェアを指定する必要はありません。

ただし、Neural Engineを効率的に使うためには量子化（float16またはint8）が有効で、モデルサイズ削減とバッテリー消費の両面でメリットがあります。外注先に「量子化対応の確認」を仕様に含めることを推奨します。

ML Kit（iOS/Android共通）の仕組みと外注時の前提知識

ML KitはGoogleが提供するモバイル向けMLフレームワークで、iOS・Android両プラットフォームに対応しています。事前に構築された高精度APIと、開発者が用意したカスタムモデルの両方を組み込めるのが特徴です。全処理がオンデバイスで完結します。

事前構築API（文字認識・顔検出・翻訳等）の活用範囲

ML Kitには、テキスト認識（OCR）・バーコード読み取り・顔検出・顔メッシュ・物体検出・ポーズ検出・セルフィーセグメンテーション・ドキュメントスキャナーなどのVision API、および言語識別・翻訳・スマートリプライ・エンティティ抽出などのNatural Language APIが用意されています。

これらの事前構築APIはGoogleが学習・チューニング済みのモデルを使っており、アプリ開発者がモデル変換や学習を行う必要がありません。標準的なOCRや顔検出であれば、事前構築APIを組み込むだけで動作します。外注先への仕様書に「ML Kit既存APIで要件を満たせるか、カスタムモデルが必要かの判断を含める」と記載しておくと仕様の明確化に役立ちます。

カスタムTensorFlow Liteモデルの組み込み

ML Kitは独自のTensorFlow Lite（TFLite）モデルをアプリに組み込む機能も提供しています。TFLiteはGoogleが開発した軽量な推論ランタイムで、PyTorch Mobile・ONNX Runtimeとともにモバイル端末向けML推論の主要エンジンです。

カスタムモデルを使う場合、学習済みモデルをTFLite形式に変換してアプリバイナリに含めるか、Firebase ML経由でOTA（Over-The-Air）配信する方式を選べます。OTA配信はApp Storeの審査なしにモデルを更新できるため、検出精度を継続的に改善したい場合に向いています。

外注前に整理すべき要件定義の4項目

端末内ML推論の外注を依頼する前に、以下の4項目を整理しておくと見積もり精度が上がり、外注先との認識ズレを防げます。

推論ユースケースとモデル選定

まず「何を推論させたいか」を明確にします。OCR（文字認識）・バーコード読み取り・顔検出など一般的な用途はML Kitの事前構築APIで対応できます。一方、特定の製品外観検査・特定の動作認識など独自の判定が必要な場合はカスタムモデルが必要です。

カスタムモデルを使う場合、事前に学習済みモデルが手元にあるかどうかで外注スコープが変わります。学習データ・学習環境ごと依頼するケースは、実装のみ依頼するケースよりも工数・費用ともに増えます。

モデルサイズ・量子化・端末性能差の考慮

モデルをアプリバイナリに含める場合、App Store Connect（iOS）のアプリサイズ制限を意識する必要があります。大きなモデルをそのまま含めるとダウンロードサイズが増え、ユーザーの離脱につながります。float16やint8への量子化（クオンタイゼーション）でモデルサイズを抑えることが実務上の標準的なアプローチです。

端末性能差も重要です。最新のiPhoneやPixelでは快適に動作するモデルが、3〜4年前の端末ではメモリ不足やOOM（Out of Memory）エラーを起こす場合があります。外注仕様書に「対応最低端末スペック」と「その端末での推論レイテンシ目標値（例：1フレーム50ms以内）」を記載することで、実機テスト基準を明確にできます。

モデル更新（OTA）の配信設計

アプリを再リリースせずにモデルを更新したい場合はOTA（Over-The-Air）配信の設計が必要です。iOSではCore ML Model Deployment（Core ML Serving）やFirebase ML、AndroidではFirebase MLを利用する方法が一般的です。

OTA配信を設計する場合、アプリ起動時にモデルバージョンをチェックし、新しいモデルがあればダウンロードするロジックを組み込みます。初回起動時はバンドル済みモデルを使い、ダウンロード完了後に差し替える設計にするとオフライン時のフォールバックも確保できます。

外注先に求めるスキルセットと体制

端末内ML推論の組み込みは、ML知識とモバイル開発スキルの両方を必要とします。一般的なWebシステム開発会社ではカバーできない場合があり、外注先選定では専門性の確認が欠かせません。

iOS側（Core ML変換・Swift実装）に必要な知識

iOSでCore MLを実装するには、coremintools（Pythonパッケージ）でのモデル変換経験、Xcodeとのモデル統合、Swiftによる推論コード実装、Vision APIとのパイプライン構築などが必要です。

これらを内製でカバーしようとすると、MLエンジニア1名とiOSエンジニア1名の連携が最低限必要になります。変換ミスや型不一致によるエラーはデバッグに時間がかかるため、Core ML変換の実績が確認できるベンダーを選ぶことが手戻り削減につながります。

Android/クロス（TFLite・ML Kit・Kotlin）に必要な知識

AndroidはTFLiteまたはML Kitを使った実装が中心です。TFLiteは軽量な推論ランタイムで、Kotlinからのバインディング生成・GPU Delegate・NNAPIによるハードウェアアクセラレーション設定などのスキルが求められます。ML Kitのカスタムモデル組み込みはTFLiteをラップした形で提供されています。

iOS/Android両対応で依頼する場合、同一のTFLiteモデルを使ってAndroid・iOSそれぞれに実装するか、iOSはCore ML変換・AndroidはTFLiteで別ファイルを用意するかの判断が発生します。この判断は開発工数と推論精度・速度のトレードオフです。

外注先選定チェックリスト

• Core MLもしくはML Kit/TFLiteを使ったモバイルML実装の納品実績があるか
• coremintools・TFLite変換ツールを使ったモデル変換経験があるか
• 量子化（float16/int8）の知識と実装経験があるか
• 実機テスト（複数端末・OS世代）の体制があるか
• OTA配信設計（Firebase ML等）の経験があるか（モデル更新が必要な場合）
• MLエンジニアとiOS/Androidエンジニアが社内連携できるか

これらを事前にヒアリングしておくことで、受け入れ後の「やっぱりできませんでした」という手戻りを防げます。

端末内ML推論を外注する際の典型的な失敗パターン

端末内ML推論の外注では、技術仕様を発注段階で詰め切れないことが失敗の主な原因です。代表的な2パターンを整理します。

モデルサイズ未確認によるアプリサイズ超過

学習済みモデルをそのままアプリに組み込むと、数百MBの重量級モデルが含まれてストアからのダウンロードサイズが肥大化します。App Store Connectは200MBを超えるアプリのWi-Fiダウンロード時の警告表示を義務付けており、ユーザーの離脱率に影響します。

量子化や枝刈り（プルーニング）を行わずに実装を進めてしまい、リリース直前にサイズ超過が判明するケースは実務上よく見られます。仕様書に「モデルサイズの上限（例：アプリ全体の差分で50MB以内）」を明記し、外注先に変換段階での計測・報告を義務付けることで事前に対処できます。

端末性能差の考慮漏れによる低端末クラッシュ

最新の開発用デバイスでのみ動作確認して納品され、リリース後に数世代前の端末でOOMクラッシュが多発するケースがあります。モバイルアプリのユーザーが全員最新端末を使っているわけではなく、複数世代の端末への対応が求められます。

外注仕様書に「対応する最低端末モデルと最低iOSバージョン・Androidバージョン」を明示し、その端末での推論テスト結果（レイテンシ・メモリ使用量）を納品物に含めることを条件にします。検証済み端末リストを納品物として受け取ることで、受け入れ検収の基準が明確になります。

まとめ — 端末内ML推論外注の3つの判断軸

本稿では、端末内ML推論をモバイルアプリに組み込む外注の進め方を整理しました。要点を3つに集約すると次のとおりです。

第一に、フレームワーク選定です。iOS専用はCore ML、iOS/Android共通はML Kitが出発点です。ML Kitの事前構築APIで要件を満たせる場合は外注スコープを最小化できます。カスタムモデルが必要な場合はモデル変換の工数と実績を外注先に確認します。

第二に、要件定義の4項目（ユースケース・対象プラットフォーム・モデル提供方法・更新頻度）を発注前に整理することです。これを曖昧にしたまま発注すると、見積もりのズレや実装後の仕様変更が増えます。

第三に、失敗リスクの明文化です。モデルサイズ上限と対応端末の最低スペックを仕様書に記載し、実機テスト結果を納品物に含める条件にすることで、リリース直前の手戻りを防げます。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Apple「Core ML」（Apple Developer Documentation、2024年）
2. *2　出典：Google「ML Kit for Firebase」（Google Developers、2024年）

Tweet