LASSIC Media らしくメディア
アプリのAI翻訳、Apple純正とML Kitで実装を外注
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- アプリ内で生成される動的なテキストをその場で翻訳する機能は、事前に翻訳データを用意する多言語対応(i18n)とは異なる実装が必要です。
- AppleはiOS 17.4以降でTranslation frameworkを提供し、Google はML KitでAndroid・iOS向けのオンデバイス翻訳を提供しています。
- 対応言語やオフライン性、実装コストの違いを踏まえ、クラウド翻訳APIとの使い分けも検討の対象になります。
目次
- アプリ内AI翻訳とは、動くコンテンツをその場で訳す機能
- Apple Translation framework——iOS 17.4以降のオンデバイス翻訳API
- Google ML Kit on-device translation——Android/iOSのオフライン翻訳SDK
- 対応言語・オフライン性・実装コストで比較する2つの選択肢
- DeepL・Google Cloud Translationとのハイブリッド判断
- 実装で見落としやすい落とし穴——プラットフォーム分岐と言語ダウンロードUI
- 内製と外注の分かれ目——オンデバイス翻訳実装の工数で判断する
- まとめ：アプリ内AI翻訳の実装で押さえる3つの判断軸
- よくある質問
アプリ内AI翻訳とは、動くコンテンツをその場で訳す機能
アプリのAI翻訳とは、チャットのメッセージやレビューのようにアプリの中でユーザーが生成する動的なテキストを、実行中にその場で翻訳する機能を指します。Appleは2024年3月にiOS 17.4でTranslation frameworkを提供し、オンデバイスでの翻訳に対応しました*1。
この機能は、UI文言や利用規約のようにあらかじめ用意された静的な文章を翻訳する多言語対応(i18n。国際化。文言をあらかじめ複数言語で用意しておく設計手法)とは異なります。本稿で扱うのは、ユーザー入力やAPIの応答のように実行時に生成される文章を、その場で訳す機能です。
具体的には、チャットやレビュー投稿、カスタマーサポートの入力欄などが対象になります。翻訳をオンデバイスで行うと、テキストを外部サーバーに送らずに処理できるうえ、通信環境が不安定な場面でも動作しやすい点が利点です。クラウド翻訳APIを使う多言語対応開発と組み合わせる判断も検討の対象になり、考え方は後述します。
Apple Translation framework——iOS 17.4以降のオンデバイス翻訳API
Apple純正のTranslation frameworkは、iOS 17.4以降で利用できるオンデバイス翻訳APIです*1。翻訳処理にはTranslate app(Appleの標準翻訳アプリ)と同じ機械学習モデルを使い、一度ダウンロードした言語データはシステム全体で共有されます*1*2。
アプリ側で対象言語の準備ができていない場合、フレームワークが自動的にダウンロードの許可をユーザーに求め、進捗表示も標準で用意します*2。ダウンロードはユーザーがアプリを閉じた後もバックグラウンドで継続する仕組みです*2。
実装方法は2種類あります。1行のSwiftUIモディファイアでシステム標準の翻訳ポップオーバーを表示する方法と、TranslationSessionを使って複数の文字列を非同期でまとめて翻訳する方法です*2。2024年のiOS 18ではヒンディー語が追加され、対応言語は50以上になりました*2。
なお、この機能はiPhoneまたはMacの実機でのみ動作し、シミュレーターには対応していません*2。検証やテストの計画を立てる際は、実機での確認が前提になる点に注意が必要です。
Google ML Kit on-device translation——Android/iOSのオフライン翻訳SDK
Google ML Kitのオンデバイス翻訳は、Android・iOSの両方で使えるSDK(ソフトウェア開発キット。特定機能をアプリに組み込むための開発用の部品一式)です*3。Google翻訳アプリのオフラインモードと同じモデルを使い、50以上の言語間でテキストを動的に翻訳できます*3。
処理はすべて端末内で完結するため、ユーザーの入力テキストを外部サーバーに送信する必要がありません*3。言語モデルは用途に応じて動的にダウンロード・管理する仕組みで、端末のストレージ消費を抑える設計になっています*3。
実装では、翻訳元・翻訳先の言語を指定してTranslatorオブジェクトを作成し、downloadModelIfNeededでモデルの有無を確認したうえでtranslateを呼び出す流れです*4。言語モデルの容量は1言語あたり約30MBで、公式ドキュメントはWi-Fi環境でのダウンロードを推奨しています*4。
英語以外の言語同士を翻訳する場合、内部的に英語を中間言語として経由する構成になっている点も、翻訳精度を検討する際の留意点です*3。
対応言語・オフライン性・実装コストで比較する2つの選択肢
Apple Translation frameworkとGoogle ML Kitは、いずれもオンデバイスで動く翻訳機能です。ただし対応プラットフォームや実装方法には違いがあります。主な違いを整理すると、次の表の通りです。
| 項目 | Apple Translation framework | Google ML Kit |
|---|---|---|
| 対応OS/プラットフォーム | iOS 17.4以降、iPhone・Macの実機のみ*1*2 | Android・iOS両対応*3 |
| 翻訳モデル | Translate appと共有するオンデバイスMLモデル*1 | Google翻訳オフラインモードと同じ専用モデル*3 |
| 対応言語数 | 2024年のヒンディー語追加後で50以上*2 | 50以上の言語間で翻訳可能*3 |
| 言語データの管理 | システム全体で共有・自動DL進捗UIを標準搭載*2 | アプリ単位でダウンロード管理、1言語約30MB*4 |
| 実装の起点 | 1行のSwiftUIモディファイア、またはTranslationSessionの非同期API*2 | Translatorオブジェクト生成とdownloadModelIfNeededの呼び出し*4 |
| 動作要件 | 実機のみ、シミュレーター非対応*2 | 完全オフラインで動作し通信不要*3 |
いずれもクラウドへの送信を伴わない設計のため、プライバシー要件が厳しい業務アプリでも採用しやすい選択肢です。Apple側はApple製デバイスに限られ、ML Kit側はAndroidとiOSの両OSに展開できる点が大きな分岐点になります。
DeepL・Google Cloud Translationとのハイブリッド判断
オンデバイス翻訳は通信不要・低レイテンシーという利点がありますが、対応言語やニュアンスの精度で限界に達する場面もあります。その場合の選択肢が、DeepL APIやGoogle Cloud Translationのようなクラウド翻訳APIです。
クラウド翻訳APIは、文字数や呼び出し件数に応じて利用料が発生する課金モデルが一般的です。そのため、頻繁に呼び出される画面ではオンデバイス翻訳を使い、専門用語が多い契約書や長文コンテンツなど品質要件が高い場面だけクラウドAPIに切り替える、という使い分けが実務では検討されます。
どちらを主軸にするかは、対象言語の組み合わせ、通信環境の前提、そして翻訳品質にどこまでコストをかけられるかによって変わります。オンデバイス実装を前提に設計した画面へ後からクラウドAPIを組み込むと、UI設計や非同期処理の見直しが必要になり、追加の開発工数が生じかねません。
実装で見落としやすい落とし穴——プラットフォーム分岐と言語ダウンロードUI
オンデバイス翻訳の実装は、API呼び出し自体は単純でも、周辺の考慮事項が多くあります。まず言語モデルが端末にない場合のダウンロード体験です。Apple Translation frameworkはシステム標準のダウンロードUIを提供しますが、ML KitはdownloadModelIfNeededの結果をアプリ側でハンドリングし、ダウンロード中の表示を自前で用意する必要があります*2*4。
ダウンロード体験の実装を誤ると、通信環境が不安定な利用者が翻訳機能を使えないまま待たされる、という体験上の問題につながります。オフライン時の代替表示や再試行の設計をあらかじめ組み込むことが欠かせません。
Android・iOSの両OSに展開する場合は、ML Kitの実装をプラットフォームごとに用意する必要があります*3。Apple版を併用するなら、OSごとに異なるAPIを2系統保守する体制も求められます。
内製と外注の分かれ目——オンデバイス翻訳実装の工数で判断する
この実装を内製で担うには、複数の知識が要ります。iOS側ではSwiftUIとTranslationSessionの非同期処理、Android・iOS共通ではML KitのSDK連携とモデルダウンロードのハンドリング、そして両OSでの動作検証です*2*4。
専門パートナーに委託する場合と内製で対応する場合の違いは、複数OS・複数言語の組み合わせを検証する体制にあります。内製では既存の開発担当者が通常業務と並行して対応することになり、実機検証やダウンロード体験の調整に割ける時間が限られる場合があります。
。対象OS・対応言語数・クラウドAPIとの併用要否によって必要な工数は変わるため、要件を整理したうえで内製・外注を切り分けることが実務的です。
まとめ：アプリ内AI翻訳の実装で押さえる3つの判断軸
本稿ではアプリ内で動くコンテンツをその場で翻訳する機能について、Apple Translation frameworkとGoogle ML Kitを中心に整理しました。要点は3つに集約できます。第一に、この機能は静的なUI文言を翻訳する多言語対応(i18n)とは異なり、ユーザー生成テキストを実行時に訳す仕組みです。第二に、AppleはiPhone・Mac向けにiOS 17.4以降でTranslation frameworkを提供し*1、ML KitはAndroid・iOSの両OSでオフライン翻訳を提供しています*3。第三に、対応言語やニュアンスの精度が要件を満たさない場面では、DeepLやGoogle Cloud Translationとの併用も判断材料になります。
よくある質問
アプリ内AI翻訳とアプリの多言語化(ローカライズ)は同じものですか。
同じではありません。多言語化(ローカライズ)はUI文言のようにあらかじめ用意された静的テキストを翻訳する取り組みです。アプリ内AI翻訳は、チャットやレビューのようにユーザーが生成する動的なテキストを、実行中にその場で翻訳する機能を指す点が異なります。
Apple Translation frameworkはどのバージョンのiOSから使えますか。
iOS 17.4以降で利用できます*1。処理はTranslate appと同じオンデバイスのMLモデルを使い、iPhoneまたはMacの実機でのみ動作します*2。
Google ML Kitの翻訳機能はオフラインでも使えますか。
使えます。ML Kitのオンデバイス翻訳は完全にオフラインで動作し、ユーザーの入力テキストを外部サーバーに送信する必要がありません*3。言語モデルは初回利用時にダウンロードしておく必要があります*4。
対応言語が少ない場合、クラウド翻訳APIに切り替えるべきですか。
対象言語の組み合わせによって判断が変わります。オンデバイス翻訳の対応言語に含まれない言語や、専門用語が多い文章を扱う場合は、DeepL APIやGoogle Cloud Translationのようなクラウド翻訳APIとの併用を検討する余地があります。
AndroidとiOSの両方に対応する場合、実装はどう変わりますか。
両OSに展開する場合、ML KitをAndroidとiOSの両方に組み込む方法と、OSごとにApple純正機能とML Kitを使い分ける方法があります*2*3。いずれを選ぶかで検証すべき組み合わせの数が変わるため、要件整理の段階で方針を決めておくことが大切です。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Apple Developer Documentation「Translation」（https://developer.apple.com/documentation/translation）
- *2 出典：Apple「Meet the Translation API」（WWDC24セッション、2024年）（https://developer.apple.com/videos/play/wwdc2024/10117/）
- *3 出典：Google for Developers「Translation | ML Kit」（https://developers.google.com/ml-kit/language/translation）
- *4 出典：Google for Developers「Translate text with ML Kit on Android」（https://developers.google.com/ml-kit/language/translation/android）
