スマホでAIをオフライン実行する方法｜2026年版ガイド

スマホでAIをオフライン実行する場合、最初から万能なチャットAIを目指すのではなく、ツール呼び出し、分類、要約、情報抽出などへ仕事を絞るのが現実的です。本記事では、Needle Tiny LLMを含むモデル選定、iOS・Androidへの組み込み、Macでの変換、実機のメモリ・電池・温度・権限検証まで、開発者向けの判断基準を整理します。

Needleの公開リポジトリには、14MB、2600万パラメータ、モバイルなどで毎秒1,000〜6,000トークンというモデル情報が掲載されています。ただし、これはプロジェクトが示すモデル概要であり、すべてのスマートフォンで同じ速度や電池持ちになるという意味ではありません。(Needleの公式リポジトリ)

判断：スマホでAIをオフライン実行する構成は適しています。 ただし、最初から万能なチャットAIを載せるのではなく、ツール呼び出し、分類、要約、情報抽出などに仕事を絞る場合に限ります。Macで変換や自動化を進めても、最終判断は実機のメモリ、電池、温度、権限、失敗時の動作で行います。

このページは、iOSまたはAndroidアプリへオフラインAIを組み込みたい開発者向けです。機密データや弱い通信環境を扱う製品チーム、純粋な端側処理と端クラウド構成を比較する技術責任者にも役立つ内容です。

最終更新：2026年8月14日。モデル形式と実行環境は、AppleのCore ML公式ドキュメント と AndroidのLiteRT公式ドキュメント を基準に確認しています。

まず、端末側AIで失敗しやすい制約を分けます

オフライン実行の難しさは、モデルファイルの大きさだけではありません。開発現場では、少なくとも次の制約を別々に管理する必要があります。

• メモリの制約：モデル本体、KVキャッシュ、入力テキスト、画像バッファ、音声バッファが同時にメモリを使います。モデルが小さくても、長い入力や高解像度画像でアプリが終了することがあります。
• 電池と発熱：連続推論、マイク入力、カメラ処理を重ねると、応答速度より先に温度上昇や電池消費が問題になります。Appleも高負荷処理では、仕事量を減らし、効率化し、APIの使い方を見直す順序を示しています。Appleの電池使用量最適化ガイド
• 権限と安全性：ローカルモデルがカメラ、位置情報、ファイル、スマートホーム機器を操作する場合、推論結果をそのまま実行してはいけません。許可されたコマンドか、確認画面を出すべき操作か、拒否すべき操作かをアプリ側で判定します。
• 端末差：同じAndroidアプリでも、SoC、GPU、NPU、ドライバー、Google Play servicesの状態が異なります。iPhoneでも世代によってメモリや推論経路が変わるため、机上のベンチマークをそのまま製品保証に使えません。
• 配布サイズと更新：モデルをアプリへ同梱すると初回インストールが重くなります。iOSではXcodeのApp Thinning Size Reportで圧縮後と展開後のサイズを確認できます。Appleのアプリサイズ計測ガイド

作業内容ごとの向き不向き

シナリオ別にモデルを選びます

オフラインのツール呼び出しと端末操作

端末操作では、自然な会話能力よりも「どのコマンドに分類するか」と「安全なJSONを返せるか」が重要です。Needle Tiny LLMのような小型モデルは、許可済みのツール集合、少数の引数、限定された出力形式に向いています。公式リポジトリの説明でも、スマートフォン、ウェアラブル、スマートホーム、ロボットなどの小型機器向けモデルとして位置づけられています。Needleのモデル説明

実装では、モデルに「照明を消す」と言わせるのではなく、{"tool":"light_off","room":"bedroom"}のような許可済みスキーマへ変換させます。その後にアプリ側で、対象機器、ユーザー権限、確認の要否を検査します。モデルが意図を判定できない場合は、実行せず「操作内容を確認してください」と返す設計にします。

経験上の注意：工具名を自由生成させる設計は避けます。ツール一覧を固定し、引数の型、値の範囲、実行権限をコード側で検査しない限り、オフライン化しても安全性は上がりません。

オフライン要約とテキスト処理

要約、言い換え、情報抽出は、汎用チャットより端側へ移しやすい領域です。ただし、入力ファイルを読み込む段階で別の問題が発生します。

PDFや画像から文字を取り出す場合、OCRや画像前処理が必要です。音声要約では音声認識モデルとテキストモデルが必要です。長文を一定の長さで分割する場合は、見出し、表、箇条書きが途中で切れないようにし、最後に重複を除去します。

iOSではCore MLがCPU、GPU、Neural Engineを利用して端末上で推論できます。外部ライブラリで作ったモデルは、Core ML Toolsによる変換可否と、変換後の入力・出力仕様を確認します。Core MLのモデル統合ガイド

オフラインチャットと個人アシスタント

個人アシスタントは、端側AIの中でも要求が重い用途です。会話履歴、検索、音声認識、読み上げ、ツール実行を同時に扱うため、単一のモデルファイルだけを見ても判断できません。

「どのスマートフォンでも同じ体験」を目標にすると、対応端末を狭めるか、機能を段階的に落とす必要があります。最初は、端側モデルが信頼度の低い回答を返した場合だけ、ユーザーの同意を得てクラウドへ回す方式が扱いやすいです。

画像、音声、マルチモーダルは部品全体を測ります

画像処理では、モデル本体に加えて画像のリサイズ、色変換、カメラ入力、テンソル化が発生します。音声処理では、録音、サンプリングレート変換、無音区間の検出、音声認識、テキスト処理が連続します。

そのため、「言語モデルが小さいから軽い」という判断は危険です。実際の負荷は次の合計で測ります。

1. 入力メディアの読み込み。
2. 前処理と形式変換。
3. エンコーダーまたは音声認識。
4. 言語モデルや分類モデル。
5. 出力の後処理。
6. 画面表示、保存、同期。

ウェアラブルでは常時マイクやセンサーを動かす設計が電池へ影響します。Androidの公式資料でも、Android vitalsはクラッシュ、ANR、電池使用、権限問題などを確認する指標として扱われています。Android vitals公式ガイド

iOSとAndroidへの組み込み方を分けます

iOS向けは、Mac上でモデルを変換し、Xcodeへ追加し、入力と出力を固定してから実機へ入れます。Appleの公式チュートリアルでも、モデルをXcodeプロジェクトへ追加し、アプリから推論を呼び出す流れが示されています。Core MLモデル統合チュートリアル

Android向けは、LiteRTのランタイムとアクセラレーション経路を確認します。LiteRTではGPUなどのDelegateを利用できますが、端末側のハードウェアやドライバーの違いを吸収できるとは限りません。公式のサンプルを対象端末で動かし、CPU経路へ戻したときの機能と品質も残します。AndroidでLiteRTを使う方法

Macで準備し、スマホで合格判定します

Macは、学習データの整理、モデル変換、iOSビルド、テスト自動化に向いています。特にiOS開発では、XcodeとCore MLの作業環境が必要になるため、短期間の検証ではクラウドMacのiOS開発環境を使う選択肢があります。

ただし、Mac上での推論結果はスマートフォンの合格証明にはなりません。実機では、次の順で確認します。

1. タスクを固定する：分類、抽出、要約、ツール呼び出しのどれかに絞り、成功条件をJSONや正解ラベルで定義します。
2. モデル形式を決める：iOSはCore ML、AndroidはLiteRTなど、対象プラットフォームの公式ランタイムに合わせます。
3. Macで変換する：変換前後の入力名、出力型、量子化、トークナイザー、特殊トークンを比較します。
4. 最小アプリへ組み込む：画面、モデル、入力処理、エラー処理だけの構成で起動確認します。
5. 実機で負荷を測る：冷却状態と通常状態を分け、起動、連続実行、画面ロック後の復帰を記録します。
6. 失敗時を検証する：通信なし、権限拒否、ファイル破損、入力超過、メモリ不足、未認識コマンドを試します。
7. 対象端末を決める：すべての端末へ同じモデルを配るのか、性能条件で機能を切り替えるのかを決めます。

スマートフォンの組み込み検証を繰り返す場合、Macのビルド環境、実機接続、ログ収集を分けて管理すると、手元のMacだけに依存しにくくなります。iOSとAndroidの両方を扱うチームでは、Mac開発環境に関する情報を確認しながら、ビルド環境と実機検証環境を別々に計画するほうが、モデル変換の失敗原因を追いやすくなります。

端側AIを選ぶ条件分岐

• 入力が機密で、通信なしでも動かす必要があるなら、端側AIを第一候補にします。
• 処理が分類、短文要約、定型抽出に限られるなら、小型の移動端モデルを優先します。
• 複雑な推論や長文生成が中心なら、端側だけに限定せず、ユーザー同意付きのクラウド回退を設計します。
• 対応端末が広く、古い端末も含むなら、端側モデルを小さくするか、AI機能を無効化する回退経路を用意します。
• カメラ、音声、検索を同時に使うなら、各部品を分割して測定し、合計の電池・温度条件が満たせない場合は処理をサーバー側へ移します。
• 物理デバイス制御が含まれるなら、モデルの出力だけで実行せず、権限確認と明示的なユーザー承認を必須にします。

FAQ：開発前に確認したい5つの判断

端末の性能条件はモデル容量だけで決められますか？

決められません。モデル本体のほか、入力長、KVキャッシュ、画像や音声のバッファ、アプリ本体のメモリが同時に動きます。最小対応端末で起動、連続実行、画面復帰を確認し、条件を満たさない場合はモデル縮小かクラウド回退を選びます。

iPhoneではどのようなモデルが扱いやすいですか？

Core MLへ変換でき、入力と出力が明確なモデルが扱いやすいです。分類、埋め込み、短文処理、画像認識、音声認識から始めると、アプリ側の制御を組みやすくなります。大規模チャットモデルを先に入れるより、タスク専用モデルで品質と負荷を確認するほうが安全です。

AndroidへTiny LLMを導入するとき、最初に何を見ますか？

最初に見るのはモデル形式、LiteRT対応、Delegateの可否、Google Play servicesの利用条件です。次に、対象メーカーの端末でCPU実行とアクセラレーター実行を比較します。片方だけで動く設計にせず、速度が落ちても機能を維持できる経路を残します。

端側AIとクラウドAIは、どちらがアプリに向いていますか？

単純な処理と高いプライバシーを重視するなら端側AIが向いています。複雑な推論や頻繁なモデル更新ではクラウドが有利です。実務では、個人情報の抽出や検索を端末で行い、必要な場合だけ匿名化した要約をクラウドへ渡す混合構成が現実的です。

メモリと電池の検証で最低限そろえる記録は何ですか？

端末型番、OS、モデル形式、モデル容量、入力長、実行回数、起動時間、ピークメモリ、温度変化、電池残量、クラッシュ、ANR、権限拒否を記録します。iOSとAndroidで同じ入力シナリオを使い、冷却直後と連続実行後を分けると比較しやすくなります。

実機の合格基準を先に決めます

数値を一律に決めるのではなく、製品のタスクごとに合否条件を設定します。Appleの資料では、XcodeやInstrumentsを使ってメモリや電池使用量を分析する手順が示されています。AndroidではAndroid vitalsでクラッシュ、ANR、電池、権限などを継続的に確認できます。

ここで重要なのは、Mac上の速度や開発用端末の結果を、対応端末全体の性能として宣伝しないことです。移動端AIでは、モデルファイルの容量よりも、タスクの狭さ、入力処理、実行頻度、温度制御、失敗回退のほうが製品品質を左右します。

現在の構成とMac開発環境を比較します

手元のWindowsやLinux、共有クラウド環境だけでiOS・Android・複数端末の検証を続けると、iOSビルドの実行環境、物理端末との接続、モデル変換ツールの管理、夜間テストの自動化で詰まりやすくなります。特にiOSのビルドと実機検証を並行する場合、開発機の空き時間やOS更新の影響がボトルネックになります。

一方、Macをレンタルする構成なら、必要な期間だけiOSビルド、Core ML変換、テスト自動化の環境を確保できます。ただし、実機そのものが不要になるわけではありません。長期的な高負荷運用、物理ポートへの常時接続、専用端末の手元管理が必要なら、自社Macや専用の実機ラボのほうが適しています。

端側AIの原型を作り、モデル変換と多端末ビルドを短期間で回したい場合は、クラウドMacの開発環境を開発工程の一部として検討できます。モデルの合否は必ず実際のiPhone、Android端末、ウェアラブルで確認し、Mac上の結果をそのまま製品仕様にしないことが条件です。