TensorFlow Lite という名前で検索して公式ドキュメントへ飛ぶと、いまは LiteRT というページに着きます。改称しただけで中身は同じ、と読み流すと、2026年に入って本番化したアクセラレーション周りの実装方針をまるごと取り逃がします。この記事では、端末側でモデルを動かす実行環境としての LiteRT を、改称後のスタック構成、TensorFlow と PyTorch からの変換手順、INT8量子化3方式の使い分け、NNAPI が非推奨になった後のアクセラレータ選択、そして ONNX Runtime との線引きまで、公式ドキュメントとリリース情報の実測に沿って整理しました。
まとめ｜LiteRTへの改称で変わった点と2026年時点の構成の選び方
先に結論を書きます。押さえるべきは4点です。第1に、TensorFlow Lite は LiteRT へ改称され、変換元は TensorFlow だけでなく PyTorch と JAX を含む形へ広がりました。第2に、配布するファイルは .tflite のままで、既存の資産をそのまま持ち込めます。
第3が実装に効きます。2026年1月28日にGPUとNPUのアクセラレーションが本番スタックへ移り、新しい CompiledModel API から呼び分ける形になりました。従来の Interpreter API は後方互換として残るため、既存コードが即座に動かなくなるわけではありません。第4に、Android 15 で NNAPI が非推奨になったので、これから書くコードで NNAPI デリゲートを前提にするのは避けたほうが無難でしょう。
選び方の軸は単純です。配布先が Android と iOS のアプリで、端末のNPUまで使い切りたいなら LiteRT を採る。逆に、x86のサーバとエッジ機器で同じ実行環境を揃えたい、あるいは学習側が PyTorch 中心ですでに ONNX を中間形式にしているなら、ONNX Runtime のほうが手数が減ります。以下、改称の経緯・変換・量子化・アクセラレータ・選択基準の順に根拠を示します。
TensorFlow LiteからLiteRTへ｜改称の経緯と現行スタックの位置づけ
改称は単なる名前替えではなく、対象範囲の宣言でした。ここを読み違えると、TensorFlow で学習していないから関係ない、という誤った切り捨てが起こります。
2024年の改称と2026年1月の本番化｜名前とスタックの両方が変わった
Google Developers Blog の改称告知では、LiteRT という名称がマルチフレームワーク構想を表すものだと説明されています。PyTorch・JAX・Keras で作ったモデルでも同じランタイムで性能を出す、という位置づけです。
そのうえで2026年1月28日の告知が実装に直結します。アクセラレーション機能が本番スタックへ移り、GPU は TFLite 比で1.4倍と示されました。非同期実行とゼロコピーを組み合わせたセグメンテーションのサンプルアプリでは最大2倍、NPU に至ってはCPU比で最大100倍・GPU比で10倍という数字が挙がっています。Gemma 3 1B のprefill処理ではNPUがGPUの3倍という測定も公開されました。数字はいずれもGoogle側の測定条件によるもので、手元のモデルでそのまま再現する前提では扱わないほうがよいでしょう。
配布形式は.tfliteのまま｜移転したドキュメントとpipパッケージ
実務で助かるのは、配布形式が .tflite のまま据え置かれた点です。既存の変換済みモデルを作り直す必要はありません。メタデータを埋め込む仕組みも継続しています。
一方でドキュメントの所在は動きました。旧URLの ai.google.dev 配下は developers.google.com 配下へ301で転送されます（2026年8月23日実測）。社内Wikiに古いリンクを貼ったままにしていると、転送は効くものの目次構造が変わっているため目的のページに辿り着きにくくなります。Python側のパッケージは ai-edge-litert で、PyPI上の最新は 2.2.0 系（2026年8月12日公開）。公式リポジトリは安定版を6〜8週間の間隔で出す方針を示しており、nightly も並行配布されています。端末側の実装をどこまで自前で持つかという上位の判断は、エッジAIとクラウドAIの分担を扱った記事で整理しているため、本記事ではランタイム側に絞ります。
モデル変換の実装｜TensorFlow・PyTorch・JAXから.tfliteを作る
公式が示す工程は Obtain・Optimize・Run の3段です。学習済みの .tflite をそのまま使うか、手元のモデルを変換するかで入口が分かれます。
TFLiteConverterでTensorFlowモデルを変換する最小手順
TensorFlow や Keras で学習したモデルは、SavedModel を経由してコンバータへ渡すのが素直な流れです。変換そのものは数行で終わります。
converter = tf.lite.TFLiteConverter.from_saved_model(saved_model_dir)
tflite_model = converter.convert()
open("model.tflite", "wb").write(tflite_model)詰まるのは変換後です。対応していない演算が混じっていると、変換は通ってもランタイムで落ちるか、CPUへ落ちて速度が出ません。学習側のモデル構成そのものの話はTensorFlow本体の使い方をまとめた記事に譲り、ここでは変換後に必ず推論を1回通して出力を突き合わせる、という手順だけ強調しておきます。
PyTorchはlitert-torch経由｜旧ai-edge-torchからの移行
PyTorch からの変換は専用ライブラリを使います。ここで注意が要るのが、このライブラリ自体が改称された点です。ai-edge-torch は litert-torch へ名前を変え、旧パッケージは非推奨になりました。ネット上のサンプルは旧名のものが多く残っています。
import litert_torch
edge_model = litert_torch.convert(model.eval(), sample_inputs)
edge_model.export("model.tflite")前提条件がひとつあります。変換元のモデルが torch.export に準拠していることです。torch.export は PyTorch 2.1.0 で入った仕組みで、動的な制御フローを多用したモデルはここで弾かれます。変換前に torch.export 単体を通してみて、そこで落ちるならモデル側で必要な書き換えが先です。ONNX を挟む経路と比べたときの違いは、ONNXという交換フォーマットの仕組みを解説した記事と合わせて読むと輪郭がはっきりします。
INT8量子化の効きどころ｜3方式の圧縮率と代表データセットの要否
端末側で効く軽量化の中心は学習後量子化です。方式が3つあり、必要な手間と使えるハードが違います。
動的範囲・完全整数・Float16で変わるサイズと対応ハードウェア
公式ドキュメントが示す比較は次のとおりです。
| 方式 | サイズ | 速度 | 対応ハード | 代表データ |
|---|---|---|---|---|
| 動的範囲量子化 | 4分の1 | 2〜3倍 | CPU | 不要 |
| 完全整数量子化 | 4分の1 | 3倍以上 | CPU・Edge TPU・マイコン | 必要 |
| Float16量子化 | 2分の1 | GPUで加速 | CPU・GPU | 不要 |
選び分けの基準はハード側から決まります。マイコンや Edge TPU のように整数演算しか持たない実行先を狙うなら、完全整数量子化以外に選択肢はありません。GPUデリゲートに載せたいだけなら Float16 で足ります。とりあえず手軽に縮めたい段階なら、代表データを用意せずに済む動的範囲から試すのが速いでしょう。
代表データセットの作り方と、量子化後の精度劣化を実測する判定手順
完全整数量子化だけは representative_dataset が要ります。これは学習データそのものではなく、入力の分布を代表する少量のサンプルです。数百件程度で足りることが多く、前処理は本番の推論と完全に揃えます。
converter.optimizations = [tf.lite.Optimize.DEFAULT]
converter.representative_dataset = representative_dataset
converter.target_spec.supported_ops = [tf.lite.OpsSet.TFLITE_BUILTINS_INT8]
converter.inference_input_type = tf.int8
converter.inference_output_type = tf.int8入出力の型まで int8 に固定すると、浮動小数の演算を一切持たない厳格な形になります。整数演算しか受け付けないアクセラレータへ載せるときはこの指定が必要です。ただし、アプリ側で渡す入力の量子化パラメータを自前で合わせる手間が増えます。
精度の確認は目視では済ませません。公式も、小さいネットワークほど精度低下が出やすいと明記しています。量子化前後で同じ検証セットを流し、指標の差分を数値で出したうえで許容範囲を決めるのが実務の手順です。学習時に量子化を織り込むQATとの使い分けなど理論面は、モデル量子化の仕組みとPTQ・QATの違いを扱った記事で整理しています。
アクセラレータの選び方｜CPUとGPUとNPUをどう切り替えるか
2026年に実装方針が変わったのがこの領域です。古い記事のとおりに書くと、非推奨のAPIを新規コードに埋め込むことになります。
NNAPIの非推奨化で変わった前提｜Android 15以降の実装方針
NNAPI は Android 8.1（API level 27）以降で提供されてきた、ハードウェア推論の統一インタフェースでした。それが Android 15 で非推奨になっています。Android Developers の移行ガイドは、オンデバイス機械学習の進み方が速く、更新頻度の高い基盤が要るようになったことを理由に挙げ、移行先として Google Play services 上の TensorFlow Lite と GPU デリゲートを案内しています。
実装上の帰結ははっきりしています。新規に書くコードで NNAPI デリゲートを既定の加速経路に据えるのはやめる。既存アプリで使っている場合も、次の大きな改修のタイミングで CompiledModel 経由へ寄せる計画を持っておく。この2点です。
NPUベンダー5系統とAOTコンパイル・JITコンパイルの使い分け
NPU へ載せる経路は、公式ドキュメント上で5系統が示されています。Google Tensor、Qualcomm AI Engine Direct、MediaTek NeuroPilot、Intel OpenVino、Samsung Exynos AI LiteCore です。このうち Google Tensor は現時点で端末上のJITコンパイルに対応せず、AOT実行のみとなっています。残る4系統はAOTとJITの両方を CompiledModel API から扱えます。
使い分けの基準は、対象SoCが事前に分かっているかどうかです。対象SoCが確定していて大きいモデルを載せるならAOTで、初期化コストとメモリ使用量が下がります。配布先の端末を絞れず、モデルが小さいならJITで、端末側の初期化時にコンパイルさせます。
制約も先に見ておく必要があります。NPU を使うには Android の API level 31 以上が要求され、対応するABIは arm64-v8a のみです。古い端末や32ビットABIを配布対象に含めている場合、NPU 経路は使えないため、CPU と GPU へのフォールバックを必ず設計に入れます。
iOSとデスクトップ｜Core MLとML Driftが担う実行範囲
GPU 側は ML Drift というエンジンが担い、OpenCL・OpenGL・Metal・WebGPU をバックエンドとして持ちます。対応プラットフォームは Android・iOS・macOS・Windows・Linux・Web に及ぶため、モバイル専用という従来のイメージとはずれてきました。
iOS と macOS では、これに加えて Core ML デリゲートが用意されています。Apple 製SoCのNeural Engineを使う経路であり、Android側のNPU経路とは別系統として扱います。クロスプラットフォームで1つのコードに寄せたい場合でも、加速経路の設定だけはプラットフォーム別に分岐が残る、と見積もっておくのが現実的です。
ONNX Runtimeとの選択基準｜端末側の実行環境をどちらに寄せるか
端末側の実行環境として現実的な対抗馬は ONNX Runtime です。どちらでも動くケースは多いので、決め手になる差だけを挙げます。
実行環境として比べる3点｜変換経路とハード対応と配布サイズの差
第1が変換経路です。LiteRT は TensorFlow・PyTorch・JAX から .tflite へ落とす形で、PyTorch は litert-torch という専用ライブラリを挟みます。ONNX Runtime は ONNX という中間形式が入口で、PyTorch からの書き出しは標準機能として備わっています。
第2がハード対応の広さです。ONNX Runtime のモバイル・エッジ向け実行プロバイダには、Intel OpenVINO・NNAPI・Qualcomm QNN・XNNPACK に加え、Arm Compute Library、Arm NN、CoreML、Rockchip RKNPU、Xilinx Vitis-AI が並びます。ただし後者の多くはプレビュー扱いです。LiteRT 側は対象ベンダーを絞る代わりに、本番運用を前提とした統合を進めている、という構図になります。
第3が配布サイズと導線です。LiteRT は Android アプリへの組み込みを想定した配布が整っており、Google Play services 経由でランタイムを更新する経路も持ちます。アプリのAPKサイズを抑えたい要件があるなら、この差は無視できません。
LiteRTを採用する条件と、ONNX Runtimeへ寄せるべき場面
採用条件を言い切ります。次の3つのうち2つ以上が当てはまるなら LiteRT を選んでください。①配布先が Android と iOS のモバイルアプリで、端末のNPUまで使い切りたい。②載せるモデルが Gemma 3 や Gemma 3n のようなオンデバイス向け生成AIモデルである。③配布要件として API level 31以上と arm64-v8a を切れる。
逆に、次の場面では ONNX Runtime へ寄せたほうが総手数が減ります。①x86のサーバ側とエッジ機器で同じ実行環境を揃え、コードの分岐を減らしたい。②学習側が PyTorch 中心で、すでに ONNX を成果物の標準にしている。③対象ハードが Rockchip や Xilinx など、LiteRT が正面から扱っていないベンダーである。
見送るべき場面も明記しておきます。対象端末に32ビットABIの古い機種が残っていて、しかもNPU前提の速度要件を出されている案件では、LiteRT を入れても要件を満たせません。この場合はモデル側を小さくするか、処理の一部をサーバへ戻す設計変更が先です。
端末側の実装をどこから外部に委ねるかの線引きと発注時の判断材料
自社で持つべきなのは、モデルの精度要件と検証セットの定義です。ここは業務知識そのものなので外注できません。反対に、量子化の詰めやNPU経路の端末別検証は、対象SoCごとの実機を揃える必要があり、内製の負荷が跳ね上がります。
判断の目安を出すと、対象端末が3機種を超えるあたりから実機検証の工数が設計工数を上回ってきます。そこを外へ出すかどうかが分岐点になるでしょう。端末側に推論を載せる構成をどう組むか、実機検証まで含めて相談したい場合は、AI/IoTソリューションの開発支援で受け付けています。
よくある質問
TensorFlow Lite と LiteRT は別物ですか？
別物ではありません。TensorFlow Lite が LiteRT へ改称されたもので、配布形式の .tflite も従来のまま据え置かれています。既存の変換済みモデルは作り直さずに使えます。
既存の Interpreter API のコードは動かなくなりますか？
すぐに動かなくなるわけではありません。CompiledModel API が新しいインタフェースとして導入された一方で、Interpreter API は後方互換のために残されています。ただし新機能は新API側に載るため、改修の機会に寄せていくのが妥当です。
PyTorch のモデルでも LiteRT で動かせますか？
はい、対応可能です。litert-torch（旧 ai-edge-torch）で .tflite へ変換します。前提として、変換元モデルが torch.export に準拠している必要があります。
NPU を使うのに必要な条件は何ですか？
Android では API level 31 以上が要求され、対応ABIは arm64-v8a のみです。加えて、対象SoCのベンダーがLiteRTの対応系統に含まれている必要があります。条件を外れる端末向けにはCPUとGPUへのフォールバックを用意します。
量子化するとどれくらい小さくなりますか？
公式の比較では、動的範囲量子化と完全整数量子化がおよそ4分の1、Float16量子化がおよそ2分の1です。速度はCPUで2〜3倍から3倍以上とされていますが、モデル構造によって幅があるため手元で実測してください。
